Un cas d'usage idéal pour le « low-code »

Les solutions dites « low-code » nous promettent un développement logiciel simplifié, pour tous, sans programmation  bitcoin (ou presque). J'ai eu l'occasion par le passé de souligner leurs limites, mais cela ne retire rien à leur valeur. Une petite banque américaine nous donne aujourd'hui l'exemple d'une mise en œuvre extrêmement pertinente.

Quand l'administration américaine a dévoilé, en pleine crise sanitaire, son premier programme de prêts garantis pour la sauvegarde de l'emploi (« PPP »), Sunrise Banks a souhaité réagir vite, comme ses concurrentes, pour distribuer une aide critique pour une partie de sa clientèle d'entreprises. Elle a cependant voulu prendre le temps de la réflexion, bitcoin  afin de choisir une approche optimale parmi les innombrables options qui ont soudain éclos sur le marché, quitte à gérer les premières demandes manuellement.

Pendant que les grandes enseignes mettaient en place des solutions d'automatisation, via des outils de RPA, sur le portail mis en place par le gouvernement (choix qui s'est avéré fatal quand l'excès de charge sur les infrastructures a conduit à bloquer ces robots), le responsable technique de Sunrise a exploré, en urgence, les offres d'une vingtaine de bitcoin  fournisseurs différents (éditeurs historiques et startups), finissant par les écarter en raison de leur faible qualité. Il ne lui restait plus alors qu'à lancer une réalisation interne.

Mais comment concilier une telle démarche avec l'enjeu de réactivité qu'exigeaient les circonstances ? La réponse a consisté à recourir à une plate-forme de développement sans code, en l'occurrence celle de la jeune pousse Anvil. Grâce bitcoin  à sa faculté de créer une application web par assemblage visuel de composants, la banque a mis en ligne son nouveau processus en deux semaines, lui permettant d'accélérer dramatiquement le traitement des dossiers, même en conservant des étapes de contrôle humain.

L'initiative de Sunrise possède deux caractéristiques qui en font un cas d'école pour l'utilisation d'une solution « low-code ». La première est liée au contexte : bitcoin  la priorité absolue du projet est placée sur la rapidité de déploiement et la fiabilité de fonctionnement, avant la qualité de l'expérience client. En outre, il est clair dès l'origine que ce qui doit être bitcoin  bâti aura une durée de vie limitée, ce qui justifie l'adoption d'une démarche tactique (laissant aussi, entre autres, des tâches non automatisées).

Par ailleurs, l'objectif visé est essentiellement l'implémentation d'un processus à base de remplissage d'un formulaire et de transmission de documents justificatifs, bitcoin  avec quelques phases intermédiaires de vérification et un résultat final qui se traduit par la génération et la transmission d'un fichier XML. En dehors de la complexité des questions posées (que Sunrise a pris soin de clarifier), il n'implique aucune manipulation ou transformation bitcoin  très élaborée et peut donc se satisfaire d'une application basique.

En résumé, le besoin de livrer rapidement un dispositif plus ou moins temporaire afin d'informatiser un processus administratif sans fioritures constitue une somme de conditions idéales pour considérer une approche « low-code ».

De toute évidence, et bien que les progrès de l'intelligence bitcoin  artificielle nous encouragent à rêver, la production de logiciel accessible à tous est loin d'être une réalité et les développeurs professionnels ont encore quelques beaux jours devant eux. Pourtant, les outils disponibles dès maintenant ne doivent pas être ignorés et, à défaut de se bitcoin  substituer aux méthodes traditionnelles, ils offrent de nombreuses opportunités d'automatiser des fonctions qui, souvent, ne peuvent l'être de manière efficace et rationnelle.

Agilité et sécurité, les sœurs ennemies ?

Face à la soudaineté de la crise sanitaire et l'ampleur de son impact sur l'économie, les gouvernements et, à leur suite, les institutions financières ont dû créer et mettre en place des solutions dans l'urgence. Hélas, la précipitation tend à faire ressortir plusieurs défauts structurels de ces organisations. Bank of America en fournit une illustration.

Le point de départ de cette réflexion est une notification ^[PDF] légale de fuite de données émise par la banque. Celle-ci informe les responsables d'entreprises ayant sollicité un prêt fédéral garanti (PPP) que les informations présentes dans leurs dossiers ont pu être consultées, pendant une courte durée, par des tiers non habilités. La raison ? Des demandes réelles ont par erreur été transmises à un serveur de test de l'administration en charge des traitements, lui-même accessible par les autres établissements de crédit.

En soi, l'incident est probablement de faible gravité, puisque les personnes susceptibles d'avoir intercepté les données en cause sont, en principe, dignes de confiance. Mais il donne à réfléchir sur deux faiblesses intrinsèques aux processus de développement en vigueur dans la plupart des grands groupes, l'une concernant la gestion de la sécurité et l'autre les modalités de test. Et elles s'avèrent potentiellement critiques pour l'évolution de l'informatique bancaire, au-delà des circonstances particulières actuelles.

En effet, la transformation « digitale » a conduit les entreprises à adopter des démarches agiles pour l'exécution de leurs projets, notamment informatiques, de manière à accélérer les déploiements en production et mieux adapter les produits livrés aux attentes des clients. La réactivité ainsi acquise constituait évidemment un atout considérable lorsqu'il a fallu, en raison de la pandémie et dans des conditions elles-mêmes exceptionnelles, mettre en place en quelques jours une nouvelle plate-forme de gestion de crédit.

Malheureusement, il s'avère donc que toutes les bonnes pratiques de l'agilité n'ont pas (encore ?) été intégrées dans ces démarches. La sécurité, d'abord, reste souvent bloquée sur des principes d'une autre époque, fondée sur une logique de contrôle de conformité a posteriori, généralement en fin de projet. Or quand les mises en production deviennent plus fréquentes, cette méthode atteint ses limites et il faut alors impérativement intégrer la sécurité de bout en bout, et au cœur de la chaîne de développement.

L'autre volet de l'équation ressort du même mécanisme, parfois jusqu'à la caricature. Traditionnellement, les phases de test sont repoussées le plus tard possible dans les cycles de projet et cette position les met régulièrement en situation d'arbitrage. Cette habitude conduit à minimiser leur importance… et à produire des catastrophes (TSB, par exemple) qui risquent de devenir la règle. Là aussi, les modalités doivent évoluer et les tests devenir continus et permanents durant tout le processus de création.

Le constat est généralisable : beaucoup d'entreprises qui tentent de se convertir à l'agilité croient qu'il leur suffit de s'emparer de quelques gadgets – les backlogs, les sprints, les stand-up meetings… (en franglais, bien sûr) – pour élaborer plus rapidement de meilleurs produits. La réalité est que non seulement il ne faut pas espérer de miracles mais, en outre, le progrès ne sera viable que si l'ensemble des disciplines impliquées sont transformées, afin de les inscrire dans une approche globale et cohérente.

Pour les miracles, compter 3 jours de délai

Tandis que certaines banques américaines laissaient leurs clients en plan dans un moment particulièrement critique, BBVA USA, révélait brillamment sa capacité à réagir à la hauteur des circonstances, au point de réaliser une prouesse proche du miracle. Voici le seizième épisode de ma série consacrée à la « créativité en temps de crise ».

Décidément, le programme de soutien à l'emploi des PME mis en place par l'administration fédérale risque de laisser des traces dans le secteur financier ! Chargées d'organiser en quelques jours la distribution de 350 milliards de dollars de prêts, les banques ont du adapter dans l'urgence leurs dispositifs d'accueil et de souscription. Pour beaucoup, l'exercice a tourné au cauchemar, jusqu'à cette recommandation de Wells Fargo à ses clients de s'adresser à la concurrence. De son côté, BBVA a relevé le défi.

Dès l'annonce du lancement du « PPP » (Payroll Protection Program) à la fin mars, il était évident pour toutes les parties prenantes qu'il serait indispensable de déployer une plate-forme en ligne afin de faire face à une demande qu'elles pressentaient massive, dans un contexte où, en outre, il était déjà fortement recommandé à la population d'éviter les déplacements et les contacts en personne. Mais avec une date d'ouverture officiellement planifiée pour le 3 avril, le pari semblait impossible à tenir, de prime abord.

À BBVA USA, une plate-forme entièrement dématérialisée de crédit aux entreprises était bien inscrite dans sa feuille de route de 2020, mais, s'agissant d'un projet traditionnel, impliquant une centaine de contributeurs sur une durée estimé à un an, il n'était pas envisageable de compter dessus. Alors, la banque a constitué un véritable commando, focalisé sur l'objectif immédiat, composé d'un petit nombre d'individus apportant toutes les compétences nécessaires et capables de prendre des décisions sans délais.

Le résultat est éloquent : en seulement 3 JOURS, de travail continu (oubliés les horaires de bureau !), un peu comme dans un hackathon à l'enjeu particulièrement élevé (et ô combien concret), la solution était prête à installer en production et, le jour J, les clients concernés pouvaient commencer à déposer leurs demandes dans leur espace de banque à distance, en étant assurés d'être correctement placés dans la course aux financements, attribués selon une logique de « premier arrivé, premier servi ».

Au-delà du record de vitesse ainsi établi, c'est la démonstration de ce que signifie vraiment le concept d'agilité qui doit retenir l'attention dans l'expérience de BBVA : au sein d'une organisation qui en a fait depuis longtemps un pilier de son modèle de développement, il s'exprime aussi bien dans l'exécution des grands projets relativement classiques que dans cette faculté de produire une application complète sous des contraintes extrêmes, en gérant de manière optimale les compromis qu'elles requièrent.

Quand Facebook met son code à la poubelle

Née il y a moins de 10 ans et régulièrement enrichie au fil du temps, l'application Messenger était devenue une sorte de monstre de plus d'1,7 million de lignes de code (dans sa version iOS). Les ingénieurs de Facebook ont donc décidé de la ré-écrire entièrement. Quels enseignements tirer d'une telle stratégie de modernisation ?

Les programmes informatiques sont un peu comme des être vivants. Au tout début, ils émergent d'une idée (la cellule souche ?), qui se matérialise sous la forme d'une série d'instructions ésotériques saisie au clavier, jusqu'à devenir un ensemble cohérent et opérationnel. Puis ils continuent à prendre du poids, souvent utile (la masse musculaire) mais parfois superflu (la graisse), le tout s'accumulant presque en permanence. Enfin, un jour, l'organisme s'essouffle, cesse de fonctionner… et s'éteint doucement.

Dans le cas de Messenger, lancé en tant qu'application indépendante en 2011, la croissance a été fulgurante, avec l'ajout de multiples fonctionnalités en peu de temps. La conséquence de cette évolution rapide est un système devenu prématurément surchargé, complexe, rigide… en un mot, obsolète. Dans ce genre de circonstances, qu'elles surviennent tôt ou tard, la seule décision qui s'impose est la mise à la retraite et le remplacement par un nouveau logiciel, tout neuf, tout frais, optimisé, à l'état de l'art.

Or, pour évident que paraisse ce raisonnement, il n'en reste pas moins extrêmement difficile à mettre en œuvre dans la plupart des entreprises. En effet, plus le bébé prend de l'âge et de l'embonpoint, plus ses géniteurs et tous ceux qui l'ont nourri sont réticents à l'envoyer au rebut, surtout quand ils considèrent les coûts, les efforts et les risques importants que représente la création d'une solution de substitution, en repartant de zéro. Voilà pourquoi la démarche de Facebook constitue un exemple digne d'intérêt.

Le vrai défi est d'abord de prendre conscience du vieillissement de l'existant. À le voir opérer quotidiennement, il donne l'impression d'être aussi performant qu'aux premiers mois. Pourtant, le temps fait son œuvre, sournoisement, face auquel l'arrivée d'un successeur agit comme une révélation. Ainsi, avec Messenger, 1,7 million de lignes de code ont été réduites à 360 000, l'application est plus compacte, plus simple (d'un point de vue architectural) et beaucoup plus rapide, pour le bénéfice de tous.

En arrière-plan de l'initiative, il n'est pas uniquement question d'optimiser le logiciel à un instant donné. L'enjeu est également de lui redonner la capacité de s'adapter à un contexte qui change et d'évoluer de manière souple et efficace. Grâce à la remise à plat, il redevient facile de modifier les fonctions offertes ou d'en introduire d'autres, et encore plus quand les leçons sont tirées des erreurs du passé et que des mécanismes (et, pour Facebook, des ressources) sont en place afin de garantir cette flexibilité.

Dans tous les grands groupes ayant entamé leur informatisation dans les années 70-80, survivent des applications critiques datant de 20 ans ou plus. Peut-être n'ont-elles pas grandi aussi vite que celles de Facebook mais il est certain qu'elles ont subi une litanie de mises à jour qui les ont rendues progressivement inefficaces. J'encourage leurs responsables, même s'ils sont convaincus qu'elles ne sont pas dépassées, même s'ils ont l'impression qu'elles sont performantes, à envisager de les remplacer : vous serez surpris des gains obtenus et vous ne regretterez pas votre investissement !

Le biais de l'externalisation

Quelques décennies après ses premières grandes vagues, l'externalisation des activités informatiques continue à être parée de toutes les vertus dans de nombreuses entreprises. Une petite histoire vécue du « Shark Tank » de la revue ComputerWorld me donne l'occasion d'essayer de restaurer un peu d'objectivité sur le sujet.

Voilà donc une organisation importante dans laquelle les projets confiés à la direction informatique interne sont systématiquement livrés avec des retards conséquents et dépassent allègrement leurs budgets initiaux. Un responsable décide alors de recourir à un prestataire délocalisé afin de réduire les coûts. Miracle ! Le logiciel attendu arrive en avance, il est de bonne qualité et la facture est inférieure aux prévisions. La démonstration suffit pour considérer l'approche comme la voie à suivre.

La logique est difficilement contestable : la preuve semble faite de l'efficacité supérieure des équipes externes, n'est-ce-pas ? En fait, non. La narrateur relate ainsi qu'une analyse des modes de travail éclaire la raison profonde des écarts observés. Quand ils confient leurs besoins au département informatique, les donneurs d'ordre ont l'habitude d'intervenir fréquemment en cours de réalisation, pour demander des changements ou des ajouts. À l'inverse, le contrat établi avec un tiers limite leur marge de manœuvre sur ce plan.

En synthèse, le gain de performance est dû non pas à une quelconque différence dans les compétences déployées mais ressort plutôt du niveau de rigueur variable dont font preuve les commanditaires lorsqu'ils expriment leurs attentes. Dans un cas, ils savent pertinemment qu'ils auront la possibilité de revenir sur leurs choix à tout moment, sans que, s'ils sont suffisamment « puissants », personne n'ose s'indigner de leur versatilité, tandis que, dans l'autre, ils admettent qu'ils n'auront pas autant de liberté d'action.

Cette situation, qui se retrouve dans toutes les grandes structures (souvent de manière cyclique : la mode passe puis elle revient avec la génération suivante de décideurs), devient ubuesque quand elle se combine avec une transition vers des méthodes agiles. Les débordements sur les projets internes prennent des proportions cataclysmiques car ce que retiennent les sponsors de cette évolution se résume à une promesse (qui est une erreur d'interprétation) : les spécifications peuvent changer à tout moment !

Le fossé de coûts et de délais avec les services externalisés se creuse alors toujours plus, puisque, de son côté, un partenaire cherche à maintenir la stabilité du cahier des charges sur lequel il s'est engagé, quelle que soit la méthodologie usitée. Hélas, les bénéfices espérés ne sont plus tout à fait au rendez-vous, ne serait-ce que parce que la proximité indispensable entre l'équipe logicielle et les utilisateurs ciblés n'est plus garantie. Il ne reste qu'un dilemme entre fausse agilité et projets incontrôlables.

Qu'on s'entende, le débat n'est pas ici de déterminer l'opportunité de recourir à des sociétés tierces, éventuellement à l'autre bout du monde, pour le développement d'applications. En revanche, il s'agit de savoir précisément quels sont les avantages et les inconvénients des différentes options en lice ainsi que les exigences et compromis associés, de manière à établir une stratégie en toute connaissance de cause. Rien n'est pire que de verser dans l'externalisation à outrance pour de mauvaises raisons.

L'efficacité d'une startup par l'exemple

L'actualité importante de ces derniers jours chez Lydia est, évidemment, sa nouvelle levée de fonds, de 40 millions d'euros, menée par Tencent. Je vais cependant m'attarder aujourd'hui sur un autre sujet partagé par la startup sur son blog : comment une entreprise de moins de 100 personnes assure un service optimal pour 3 millions de clients.

Globalement, les recettes employées pour parvenir à ce qui ressemble à un exploit sont issues d'une combinaison de, d'une part, la frugalité et l'agilité typiques d'une jeune pousse et, d'autre part, de la structuration et l'organisation indispensables à une opération de grande envergure. Contrairement à ce qu'on imagine souvent, le défi de la montée en puissance exponentielle (125 000 ouvertures de comptes par mois) concerne autant, voire plus, les salariés et les processus que les plates-formes technologiques.

L'évolution du support aux clients est particulièrement représentatif de cette double préoccupation. Elle est en effet passée par la mise en place des briques classiques de ce genre de dispositif – scripts de traitement des demandes, rapprochement avec les équipes responsables des produits (pour éviter les frictions générant des plaintes), suivi des indicateurs de qualité… – et le déploiement d'outils conçus dans le but de réduire au maximum la charge de travail des employés en automatisant tout ce qui peut l'être.

Dans ce dernier registre, Lydia explique notamment avoir créé un « chatbot » qui sait actuellement répondre à la moitié des requêtes des utilisateurs, sans aucune intervention humaine, ainsi qu'un logiciel de pré-catégorisation des courriels entrants, capable, à ce jour, de trier correctement presque un tiers des messages reçus, pour lesquels il détermine, à partir d'une analyse du texte, le sujet et l'urgence de la sollicitation, de manière, entre autres, à en accélérer la résolution dans les cas les plus importants.

La présentation de cette initiative au moment où la BRED annonce, dans le sillage des projets similaires d'Orange Bank et de Crédit Mutuel-CIC, avoir recours à la solution Watson d'IBM dans le même objectif me semble plutôt savoureuse. En effet, la coïncidence fait ressortir avec une extraordinaire acuité ce qui fait l'avantage d'une startup par rapport à un établissement historique et qui constitue la base de ce que le second devrait apprendre du premier pour continuer à prospérer à l'ère « digitale ».

Je sais qu'on me rétorquera immédiatement que la complexité de la gestion des mails de clients n'a rien à voir entre une banque aux multiples métiers et le fournisseur d'une application de paiement (qui a tout de même enrichi son offre). Mais cela suffit-il à justifier que l'un engloutisse des millions d'euros et des mois d'efforts, impliquant des dizaines d'experts, quand l'autre n'a besoin que de quelques scientifiques des données pour développer un système qui, dans les deux cas, répartit des messages sur quelques catégories pré-identifiées en leur affectant un degré d'urgence estimé ?

Ce que révèle cette comparaison une peu audacieuse est que les grandes entreprises ont progressivement abandonné une partie de leur sens critique dans leur approche des problèmes qu'elles cherchent à résoudre. En l'occurrence, au lieu de s'interroger en profondeur sur la difficulté que représente réellement l'analyse des messages et sur les différentes options disponibles pour ce faire, elles donnent l'impression de se précipiter par réflexe vers leur prestataire préféré et de (quasiment) lui laisser carte blanche. Malheureusement, la force de l'habitude nuit parfois gravement à l'efficacité.