Alors que le Brésil possèderait le plus important écosystème de finance ouverte au monde, le nombre d'entreprises qui en profitent activement est ridiculement faible. Estimant que la complexité de mise en œuvre constitue le principal obstacle à l'adoption, deux acteurs du marché lancent une initiative exceptionnelle pour la rendre accessible.

Entre les exigences et autres préconisations réglementaires d'un côté et les sites destinés aux développeurs de l'autre, le recours aux API qui donnent accès aux services bancaires pour le compte de tiers (avec leur autorisation) paraît rapidement au-dessus des moyens de beaucoup d'organisations, qui préfèrent abandonner la partie plutôt que de risquer de perdre une énergie conséquente à décrypter les mécanismes nécessaires puis à tâtonner dans l'implémentation d'une application opérationnelle.

Ces difficultés expliqueraient en grande partie pourquoi le Brésil – dont plus de 100 millions de consommateurs ont à ce jour accepté 154 millions de connexions à leurs comptes, qui génèrent 5 milliards de transactions entre établissements par semaine – n'enregistre que 3% de firmes exploitant activement l'option d'« open banking » (pour leurs paiements), contre, par exemple, 20% au Royaume-Uni, où, bien entendu, la maturité, de l'industrie comme de la population, est considérablement plus avancée.

Pour des firmes telles que Juspay, spécialiste des paiements, et Cumbuca, premier agrégateur de services du pays, l'opportunité est immense, aussi joignent-elles leurs forces afin de créer une plate-forme qui prend par la main leurs clients potentiels et leur montre pas à pas comment construire une intégration en quelques étapes, grâce à laquelle ils pourront très facilement accepter les règlements via un transfert bancaire ou, dans un mode spécifique, à travers la solution locale incontournable Pix.

L'approche pédagogique retenue avec ce « Playground » est simplement renversante. Sur un côté de l'écran, le visiteur découvre une simulation de parcours d'achat dans une application mobile (dont il peut même ajuster les détails de l'interface). Sur la partie droite, chacune des étapes qu'il exécute au fil de ses clics de validation d'une commande est matérialisée par les interactions correspondantes avec les API, les exemples d'appels et de réponses, contextualisés, étant décrits en détail.

Avec ces explications, n'importe qui (ou presque) devient capable d'apprendre rapidement à bâtir un processus complet de paiement, en faisant directement le lien entre les actions requises de la part de l'acheteur au sein d'une application d'e-commerce et les échanges techniques à orchestrer avec le fournisseur de services, dont tous les aspects sont couverts, y compris, entre autres, l'authentification entre machines, la protection des secrets, les consentements…, en parfaite conformité réglementaire.

Les deux partenaires à l'origine du « Playground », soutenus par l'association brésilienne de la finance ouverte, ont choisi de partager leur travail sous licence libre et ils invitent la communauté à contribuer à l'extension de la plate-forme, notamment pour l'intégration des particularités des différents fournisseurs. Plus largement, ce genre d'outil pourrait inspirer toutes les organisations distribuant leurs fonctions sous forme d'API, dont la prise en main s'avère hélas fréquemment difficile à appréhender.

Avec son « Design Assistant », U.S. Bank exploite l'intelligence artificielle dans un domaine inattendu et inédit mais qui éclaire singulièrement ses choix de priorités et sa stratégie « digitale », quand cette dernière ne se réduit pas aux seules technologies (le « numérique ») mais veut agir en profondeur sur l'expérience client.

La nouvelle solution, qui a été conçue et développée grâce à une collaboration entre l'équipe spécialisée dans l'IA et celle qui comprend les utilisateurs cibles, est déployée depuis décembre dernier – intégrée au cœur de leurs plates-formes habituelles – et a été tout de suite massivement adoptée par tous les collaborateurs dont le rôle consiste à dessiner les parcours ou les interfaces des sites et applications web et mobiles de l'entreprise ou encore à développer des maquettes et prototypes de logiciels.

L'assistant prend en charge, en particulier, les exigences réglementaires, par exemple en termes d'accessibilité, de conformité aux standards internes, de respect de la charte graphique maison… Concrètement, il suit le travail effectué et émet des alertes lorsqu'il détecte des écarts ou anomalies, assorties de recommandations de correction. Dans tous les cas, la personne qui est au commande garde le contrôle et peut accepter ou non les suggestions, ces décisions enrichissant l'intelligence du système en continu.

Comme dans la plupart des initiatives à base d'IA, U.S. Bank met en avant les bénéfices pour ses employés, qui seraient de la sorte libérés de tâches à faible valeur ajoutée et dégageraient donc plus de temps pour exprimer leur créativité et se concentrer sur la partie noble de leur mission. On ne peut toutefois s'empêcher de penser que, du point de vue de l'établissement, ces gains se traduisent directement sur la productivité des intéressés et lui permettent de projeter des réductions d'effectifs en conséquence.

La mise en place de l'assistant n'en est pas moins une avancée importante pour l'institution financière. En contraignant, en amont, l'alignement du design avec un jeu de normes prédéfinies, la suite de la production logicielle est également rationalisée, facilitant la réutilisation de composants existants et limitant les besoins d'aller-retour entre les équipes. Et aux utilisateurs finaux, clients ou salariés, il offre en outre une garantie de cohérence et d'homogénéité qui facilite la prise en main et l'efficacité.

C'est ce dernier point qui retient le plus mon attention dans la démarche d'U.S. Bank, même s'il peut paraître anecdotique. Il n'est pas si courant pour une entreprise, surtout de cette dimension, de créer ses propres outils dans la chaîne de développement informatique, alors que le marché est pléthorique et propose des capacités de personnalisation sans fin. J'estime, peut-être naïvement, que ce choix reflète l'importance fondamentale que constitue l'expérience client dans l'esprit de ses décideurs et la nécessité d'en maîtriser tous les aspects afin d'atteindre l'excellence.

Avec la mode du « vibe coding », le recours à l'intelligence artificielle pour le développement logiciel est fréquemment associé à la création d'applications à partir de zéro, notamment pour des prototypes. Les « minions » propriétaires de Stripe, en revanche, sont chargés d'œuvrer en totale autonomie sur sa vaste base de code existante.

Naturellement, l'enjeu est considérable pour le processeur de paiements car il vise, comme la majorité des entreprises attirées par les promesses de l'IA, à optimiser son efficacité opérationnelle, ici dans la maintenance logicielle (corrective et évolutive), qui implique de naviguer et intervenir dans des centaines de millions de lignes de programme déployées en production, sans mettre en péril la fiabilité de systèmes qui gèrent plus de 1 000 milliards de dollars de transactions chaque année.

Baptisés minions (ce qui paraît un peu surprenant au vu de l'image bête et méchante de ces créatures de fiction), les agents intelligents de Stripe sont généralement interpellés à travers des demandes de changement qui leur sont spécifiquement adressées sur l'outil collaboratif Slack. À partir d'une description relativement précise de la tâche à effectuer, rédigée par un ingénieur, ils créent une version dédiée de la section affectée et implémentent la modification souhaitée, sans la moindre contribution humaine.

Ce n'est que lorsque le travail est terminé qu'un collaborateur – distinct de celui qui était à l'origine de la requête, par sécurité – passe le résultat en revue et l'intègre dans la chaîne « DevOps » habituelle pour son déploiement ultérieur. Cette approche, déjà instanciée mille fois par semaine, autorise une forte parallélisation des opérations, pour des besoins plus ou moins élémentaires qui consomment en temps normal de précieuses ressources mieux employées sur des fonctions sophistiquées.

Le dispositif, plutôt impressionnant, repose sur une conception et une réalisation maison, indispensables pour espérer mettre au point des agents très spécialisés et surtout capables d'appréhender le contexte de l'entreprise, à savoir, entre autres, son patrimoine logiciel, sa panoplie technologique (comportant quelques originalités notables), ses pratiques de développement… que les minions doivent impérativement respecter pour la cohérence d'ensemble et garantir la pérennité des composants.

J'imagine que la solution est bien accueillie par les ingénieurs de Stripe, qui voient ainsi retirer de leurs responsabilités des tâches à faible valeur ajoutée et peu exigeantes intellectuellement. Mais la démarche présente tout de même deux risques. D'une part, les étapes de contrôles, pourtant essentielles, pourraient être négligées car tout aussi peu passionnantes. D'autre part, les nouvelles recrues n'auront plus dans leur périmètre ces petites actions qui leur permettent de se familiariser avec leur mission. Il faut espérer que l'organisation a prévu des mécanismes dédiés afin d'éviter ces dangers…

La programmation logicielle est aujourd'hui un des domaines où le recours à l'intelligence artificielle générative est le plus courant et considéré le plus productif. Pourtant, une étude, certes imparfaite, du fournisseur de solutions de revue de code informatique CodeRabbit inciterait à relativiser son efficacité, en particulier en termes de qualité.

Pour beaucoup d'entreprises, l'IA est devenue une réalité incontournable d'abord et avant tout dans leur direction des systèmes d'information, où elle permet aux débutants de développer des applications plus rapidement et aux collaborateurs plus expérimentés de se concentrer sur les algorithmes les plus complexes. Avec ce qu'on nomme désormais le « vibe coding », encore rare mais qui se propage rapidement, elle offre même la possibilité à ceux qui ignorent tout du métier de créer des logiciels.

Malheureusement, alors qu'on imagine aisément (moi le premier) que la nature mathématique de la discipline se prête idéalement à son automatisation, l'analyse par CodeRabbit d'un échantillon de sources en licence libre révèle que les modules écrits avec l'assistance de l'IA (selon les déclarations volontaires des contributeurs impliqués) comportent beaucoup plus d'erreurs que ceux qui sont composés exclusivement par des humains, 70% de plus pour être précis, dans tous les registres considérés.

Au-delà du nombre, les anomalies introduites avec l'intelligence artificielle s'avèrent également plus critiques. Et quand on découvre que, outre les problèmes de logique, de maintenabilité, de performance…, les failles de sécurité prolifèrent – mauvaise gestion des mots de passe multipliée par presque deux, tout comme certains défauts techniques classiques, vulnérabilité bien connues de type « cross-site scripting » multipliées par trois… –, la circonspection et la prudence semblent de mise.

Ces résultats donnent d'autant plus à réfléchir que les perceptions de gains de temps grâce aux outils d'assistance semblent aussi démenties par la réalité. Une expérimentation scientifique aurait ainsi démontré que les professionnels estimant avoir travaillé 20% plus rapidement avec l'IA sont en fait plus lents d'autant, en moyenne. Une fois intégrée la durée nécessaire aux contrôles et aux corrections des bogues, sans même parler de ceux qui traverseront les mailles du filet, le bilan devient très négatif.

L'évolution augure mal de l'avenir du logiciel. Entre la liberté de création que procure l'intelligence artificielle, la propension historique des équipes à négliger les tests (et, parfois, à ne pas savoir les organiser correctement) et la tendance à accorder une confiance aveugle à la machine, la multiplication des incidents pourrait déboucher sur des crises majeures, soit à cause de défaillances directes, soit par l'exploitation malicieuse des faiblesses non détectées… qui, elle, est en croissance exponentielle.

Malgré des progrès sensibles au cours de la décennie écoulée, peu d'institutions financières ont développé – et encore moins industrialisé – leurs catalogues de services permettant à leurs partenaires une intégration transparente dans leurs offres. Avec son portail Avvance, dédié au crédit à la consommation, U.S. Bank montre l'exemple.

Dans le monde ultra-connecté d'aujourd'hui, les anciennes méthodes de distribution – remplissage manuel de dossier, transmission de justificatifs imprimés, attente d'un accord pendant plusieurs jours… – ne sont plus viables. La FinTech, entre autres, est passée par là, entre trublions spécialisés et explosion du paiement fractionné (BNPL), avec ses nouvelles pratiques : dorénavant, l'acheteur attend de pouvoir demander un financement sur le point de vente et d'obtenir une décision instantanément.

Pour les acteur historiques, cette révolution des habitudes impose un alignement des processus et des solutions technologiques sur l'état de l'art. Concrètement, il s'agit à la fois d'exploiter des approches différentes en matière de connaissance du client et d'évaluation des risques, de manière à émettre une réponse en quelques secondes, et de permettre aux commerçants, ou à leurs fournisseurs de terminaux d'encaissement, d'embarquer nativement les options de crédit adaptées à leur contexte et leurs besoins.

Le portail d'U.S. Bank présente tout ce qui leur est nécessaire aux entreprises qui veulent se lancer – avec un produit de prêt personnel de 300 à 25 000 dollars, sur 3 à 60 mois, porté par une enseigne réputée. Moyennant une simple inscription, elles ont tout loisir d'accéder à l'ensemble de la documentation, de consulter des exemples d'utilisation, d'interroger les équipes de support de la banque, d'expérimenter leur future implémentation au sein d'un bac à sable…, sans frais et sans engagement.

Si le cœur de la plate-forme est occupé par un jeu d'API complet, avec lequel les partenaires les plus mûrs pourront construire leur solution et l'insérer dans leurs propres parcours avec le maximum de liberté, deux autres possibilités sont proposées, aux capacités de personnalisation plus limitées mais requérant un effort réduit pour leur mise en place : une connexion directe du système du marchand à l'interface graphique d'U.S. Bank, avec identification et authentification transparente (SSO), ou un mécanisme de renvoi du client lui-même vers son application de dépôt d'un dossier.

Dans tous les cas, le parcours de souscription, classique, reste identique. Il commence par la création d'une demande, partagée avec le consommateur, qui doit (bien sûr) remplir quelques informations essentielles, puis envoyée à l'établissement pour pré-accord. Dans l'hypothèse favorable, une requête de paiement est émise, sur laquelle l'emprunteur, s'il confirme son choix, doit finaliser les formalités, jusqu'à la signature. Dès lors, Avvance paye le commerçant et le client commence à rembourser.

Au-delà de la richesse des fonctions qu'elle met à la disposition de ses partenaires (et je n'ai pas parlé des tableaux de bord de suivi, par exemple), U.S. Bank se distingue ici par une maturité encore relativement rare sur le plan de la communication. En effet, une palette d'API ne suffit pas à satisfaire les attentes des adeptes de services financiers enfouis, représentés aussi bien par des décideurs métier que par des développeurs, encore faut-il leur procurer le matériel qui leur est indispensable pour l'exploiter.

À l'occasion de la célébration de son quinzième anniversaire, lors de son sommet annuel, eToro dévoile une nouvelle plate-forme – combinant API, « vibe coding » et App Store – destinée, peut-être, à réinventer (une nouvelle fois !) sa vision originelle du trading social pour l'ère émergente de la programmabilité et de l'intelligence artificielle.

D'emblée, la démarche détonne dans un contexte où toutes les entreprises se précipitent dans le déploiement de l'IA, en général sans véritablement s'inquiéter de son utilité réelle. Ici, et je ne peux qu'en applaudir le pragmatisme et la pertinence, la priorité est mise exclusivement sur les fondations indispensables à des applications vraiment génératrices de valeur. Second exploit, ce socle est construit pour l'ensemble de la communauté rassemblée par la jeune pousse, non pour ses seuls besoins.

La fusée comporte trois étages. Au plus bas niveau, les API constituent les briques sans lesquelles rien ne peut fonctionner de manière fiable, flexible et performante… et que la plupart des organisations qui rêvent d'automatiser leurs processus oublient de mettre en place. Pour eToro, tous ses services seront exposés de la sorte, de manière à permettre aux futurs agents virtuels de piloter et orchestrer toutes les activités disponibles dans son offre : accès aux données de marché, aux portefeuilles, exécution de transactions, gestion des capacités sociales qui sont sa marque de fabrique…

Au-dessus de cette boîte à outils, les clients disposeront de facilités de « vibe coding », qui autorisent, grâce à l'intelligence artificielle, la création d'applications logicielles complètes sans coder, par une simple description en langage naturel. L'objectif est de donner le pouvoir à tous les investisseurs de concevoir et développer, simplement et rapidement, les automatismes dont ils rêvent en profitant de toute la puissance des services existants d'eToro, mise à leur portée à travers les API pré-câblées.

Enfin, au dernier niveau, la firme déploiera un App Store, sur lequel ses utilisateurs auront la faculté de distribuer leurs réalisations, des plus triviales au plus complexes. Il représente de la sorte une autre déclinaison de la culture de collaboration inscrite dans son ADN, initialisée avec le partage de stratégies de trading et maintenant étendue à l'outillage. Au-delà du levier d'accompagnement qu'elle peut procurer aux clients (notamment débutants), une telle ouverture est également un catalyseur d'innovation.

Aussi séduisant soit le modèle imaginé par eToro, il est peu probable (malheureusement) qu'il conquière l'ensemble de l'industrie financière à brève échéance. En revanche, il pourrait tout de même inspirer les grands groupes qui installent des plates-formes d'IA à tort et à travers pour leurs employés et se désolent de leur faible rentabilité. Et si, au lieu de ces initiatives hasardeuses, elles commençaient par mettre en place le même genre de socle technologique, à usage uniquement interne ? Les opportunités d'optimisation et d'innovation seraient certainement décuplées…

Cette jeune pousse d'origine finlandaise a commencé son existence avec un compte de paiement dédié aux entreprises. Puis, capitalisant sur sa technologie propriétaire, elle s'est mise à commercialiser sa plate-forme de banque en API, autorisant toute entreprise à créer sa propre offre. Aujourd'hui, Narvi franchit une nouvelle étape avec une version en marque blanche, pour une adoption accélérée.

À l'heure où de plus en plus de firmes de tous secteurs explorent l'opportunité de fournir des services financiers à leurs clients, afin de leur procurer une expérience intégrée, deux options sont en général disponibles : la construction en propre (avec ou sans progiciel), qui présente l'avantage de l'autonomie et de la flexibilité totales au prix d'un coût élevé et d'un délai de mise en œuvre long, mesuré en années, démarches réglementaires comprises, ou le recours à un socle de banque en services, laissant une certaine liberté de conception tout en étant plus simple et plus rapide à implémenter.

Cependant, dans ce dernier cas, il faut tout de même prévoir des développements informatiques, qui représentent un budget significatif et requièrent un projet de quelques mois, au minimum. Voilà pourquoi Narvi décline maintenant une troisième possibilité, à l'intention des structures désireuses de déployer un produit en quelques semaines afin de répondre aux besoins de leur audience sans investissement lourd.

Les capacités de personnalisation sont certes plus limitées. Dans la tradition du principe de marque blanche, outre un tableau de bord d'administration des utilisateurs et de leur équipement, elles se réduisent essentiellement à l'adaptation de la charte graphique de la plate-forme web (celle-ci étant également destinée à l'usage sur smartphone, en l'absence d'app spécifique), sans exiger de compétences de programmation. Pour mieux faire passer la pilule, Narvi vante toutefois la qualité de son design scandinave.

Notons que, à ce stade, le catalogue de la startup, qui détient une licence d'établissement de monnaie électronique, comprend uniquement des fonctions élémentaires, de gestion de compte courant, à IBAN multiples (pour faciliter les réconciliations), et de virement, SEPA et SWIFT. La faculté d'émettre des cartes, physiques ou virtuelles, sera bientôt ajoutée à sa nouvelle offre, via une collaboration avec Mastercard, tandis que les comptes multi-devises sont annoncés pour plus tard.

Ce niveau de service restreint correspond parfaitement à la cible potentielle du dispositif. Il n'est en effet pas question de viser des acteurs cherchant à bâtir une néo-banque (qui entrerait en concurrence avec celle de Narvi) mais plutôt des entreprises – par exemple dans le reste de la FinTech, dans l'AssurTech ou dans l'e-commerce – qui souhaitent compléter leur panoplie avec un compte de paiement relativement basique. En rendant ce genre de solutions extrêmement accessible, nous sommes d'ailleurs peut-être en train d'assister aux prémices d'une future petite révolution des habitudes bancaires.

Entre ses annonces de restructuration massive, en cours, et de l'introduction de l'intelligence artificielle « agentique » au cœur de ses offres infonuagiques, des analystes estiment qu'Oracle est peut-être en voie de réinventer radicalement la manière dont ses progiciels seront distribués et mis en œuvre chez ses clients dans un avenir proche.

Le point de départ des conjectures est une estimation – élaborée à partir d'une promesse précédente d'un plan de restructuration – à une dizaine de milliers le nombre de postes supprimés chez le géant du logiciel d'ici décembre (sur un total d'environ 160 000 salariés). Les observateurs s'accordent sur les fonctions qui seront visées par ces mesures : il devrait s'agir, en grande partie, des divisions en charge des évolutions des progiciels, laissant place à une stratégie centrée sur le « cloud » et l'IA.

Or ce segment de son catalogue est une importante source de profits – souvent qualifiée de vache à lait chez les éditeurs qui ont réussi à s'imposer – qu'aucune menace sérieuse ne justifierait de sacrifier à court ou moyen terme. L'hypothèse que formule donc Akshara Naik Lopez pour Forrester est que les personnes qui vont être licenciées le seraient parce que leur rôle est voué à la disparition pure et simple grâce à ce nouveau pilier de l'avenir rêvé de l'entreprise qu'est désormais l'intelligence artificielle.

Plus précisément, les évolutions, adaptations et autres personnalisations auxquelles procèdent les clients – notamment les grands groupes – afin d'ajuster les capacités des solutions qu'ils adoptent à leurs besoins précis pourraient ne plus requérir l'intervention de développeurs et d'intégrateurs (les partenaires d'Oracle risquent donc de souffrir particulièrement), puisque les progiciels embarqueraient maintenant des agents intelligents grâce auxquels chaque entreprise ajouterait ses propres variations.

Si une telle vision se concrétise, il ne faut qu'un soupçon d'imagination pour prédire une révolution dans l'univers du progiciel tel qu'on le connaît depuis sa naissance dans les années 90. Au lieu des produits finis relativement rigides auxquels nous sommes habitués, intégrant tout depuis le cœur de métier considéré jusqu'aux interfaces homme-machine, les fournisseurs livreraient un socle de services – servant de fondation – et une IA agentique permettant au client de gérer ses opérations à sa guise.

Le modèle prédominant du secteur s'en trouverait complètement renversé… et beaucoup plus conforme aux attentes et aux pratiques des utilisateurs. Alors que le principe théorique consistait initialement à proposer une solution unique conçue sur la base de processus supposés optimaux, qui devaient s'imposer aux entreprises avec le logiciel, ces dernières ont presque toujours dépensé des fortunes pour y introduire, à plus ou moins grande échelle, leurs spécificités. Avec la nouvelle génération envisagée, seules seraient offertes des fonctions élémentaires, que les équipes (internes ou externes) adapteraient alors à l'organisation existante, facilement, à moindre coût et avec une flexibilité extrême, par exemple pour des besoins temporaires.

La plate-forme d'assistance aux développeurs Stack Overflow vient de dévoiler les résultats de son enquête annuelle auprès de 49 000 utilisateurs de ses services : ses questions autour de l'utilisation de l'intelligence artificielle, qui devient peu à peu incontournable dans l'exercice de leur métier, révèlent leur incertitude sur ses avantages.

Environ la moitié des professionnels interrogés (représentant plus de 30 000 personnes au sein de l'échantillon global) confirment qu'ils exploitent quotidiennement un outil d'IA dans le cadre de leurs missions, contre seulement 16% qui s'y refusent absolument (les autres y recourent ou envisagent de le faire de manière plus ou moins occasionnelle). Ils hésitent toutefois à confier aux automates des actions critiques.

La première fonction adoptée, pour 54% des répondants, consiste ainsi à obtenir des réponses à des questions, tandis que l'écriture de code n'en concerne que 17% (et la validation et le déploiement encore moins). Entre ces extrêmes, des capacités variées sont mises à contribution, par exemple pour la génération de contenus ou de données synthétiques, l'apprentissage, la documentation, l'aide aux tests et au débogage…

En termes de perception, s'ils persistent à exprimer majoritairement un avis positif sur leur expérience, à 60%, en baisse de 10 points par rapport à l'année précédente, tout de même, ils sont nombreux (46%) à affirmer leur défiance, les plus qualifiés étant les plus prudents. D'autre part, un consensus se dégage (et progresse) pour estimer que l'intelligence artificielle est peu efficace dans la prise en charge de tâches complexes.

Les réserves affichées ne sont pas le fruit du hasard. Elles reflètent directement les frustrations rencontrées par les intéressés dans leurs usages réels. Deux tiers des développeurs considèrent notamment que les résultats restitués sont « presque corrects mais pas tout à fait », ce qui les conduit fréquemment à penser qu'ils perdent du temps supplémentaire lors des phases de test et de mise au point (pour 45% des sondés).

Cette dernière observation correspond en partie à un syndrome connu dans l'univers de la production logicielle, de résistance à s'approprier le code d'un tiers, que celui-ci soit humain ou non. Or, au-delà des incontestables efforts nécessaires afin de comprendre ce qui est écrit par quelqu'un possédant ses propres habitudes, se pose potentiellement la question de l'intelligibilité effective des algorithmes construits par l'IA.

Si je sors maintenant du cadre de l'enquête, ce sujet mérite d'être surveillé de très près car l'intégration dans les systèmes d'information de code difficile à interpréter crée un risque majeur d'accumulation de dette technique, qui se traduira, au fil du temps, par des frais de maintenance élevés et une perte de flexibilité dommageable. Il faudra prendre garde à ce que les (éventuelles) économies réalisées lors de la mise en œuvre ne soient pas submergées à long terme par les coûts opérationnels récurrents.

À l'occasion de sa levée de fonds d'amorçage, la jeune pousse Blok, qui cible prioritairement les secteurs de la finance et de la santé, sort de l'ombre et présente son produit, destiné à simplifier et accélérer le travail de mise au point du design applicatif grâce à sa méthode de test synthétique, à base (évidemment) d'intelligence artificielle.

Dans l'univers du logiciel, l'écriture du code était la première cible des usages de l'IA, ce qui est parfaitement logique dans la mesure où il s'agit d'une discipline quasiment mathématique qui se prête idéalement à une automatisation (au point de se demander pourquoi elle tarde tant à être prise en charge intégralement par des machines). En revanche, les tests, et encore plus quand ils concernent des réactions humaines à une expérience utilisateur (via une interface graphique), sont plus difficiles à « digitaliser ».

C'est pourtant l'ambition de Blok, pionnière sur ce territoire. Son approche se veut à la fois complète, avec une couverture du besoin de bout en bout, et fiable, dans la mesure du possible. Dans cette perspective, le principe qu'elle retient consiste, dans un premier temps, à créer des personas synthétiques correspondant à l'audience actuelle de l'application considérée, puis à soumettre à ceux-ci les évolutions envisagées, de manière à recueillir leurs « avis », par rapport aux objectifs recherchés.

En pratique, les différents profils enrôlés sont d'abord élaborés à partir de l'analyse des journaux conservant classiquement la trace de toutes les interactions sur un site ou un logiciel. La startup leur assigne ensuite des mécanismes comportementaux connus (par exemple des biais), avant de les exposer, à répétition, au problème posé, celui-ci prenant la forme d'une hypothèse, d'un but à atteindre et (en option) d'une maquette de l'écran affecté. Ainsi armée, elle prodigue alors ses conseils opérationnels.

La promesse de Blok devrait attirer l'attention des équipes produit. En effet, avec ou sans intelligence artificielle, les cycles de conception et développement s'accélèrent en permanence et les phases de validation du design constituent de plus en plus souvent un goulet d'étranglement, soit que leur définition repose sur une perception instinctive d'un expert, qui engendre un risque d'erreur dont la mesure prendra du temps (et coûtera des clients), soit que des procédés plus rationnels (de type A/B test, par exemple) soient mis en œuvre, mais leurs résultats ne sont jamais immédiats.

Pour l'instant, la plate-forme de Blok est en expérimentation auprès d'une poignée d'entreprises, une liste d'attente étant ouverte pour les candidats. Ses capacités réelles sont donc en cours de raffinement et il restera à voir, lorsque la commercialisation généralisée aura débuté, si elle est aussi performante que le laisse entrevoir sa présentation. Quoi qu'il en soit, le besoin sous-jacent est avéré et il ne fait aucun doute que, à terme, ce genre d'outil complètera la panoplie technologique des entreprises.

Invité par Florian Graillot à m'exprimer dans son podcast Tonalités InsurTech sur les systèmes d'information vieillissants des institutions financières, je vous propose de prolonger la thématique avec quelques réflexions – de bon sens mais qu'il me semble utile de rappeler – autour de la mise en place d'une stratégie de modernisation.

Commençons donc par les évidences. Comme tout projet, et encore plus quand il est question d’une transformation qui va mobiliser des centaines de personnes et des milliards pendant des années, il est important de respecter quelques jalons impératifs, sur lesquels je reviendrai : établissement de l’état des lieux, définition de la cible désirée, choix d’approche et élaboration du plan de route, qui devront naturellement déboucher ensuite sur des phases de réalisation et de déploiement (que je ne couvrirai pas ici).

Selon moi, la première étape est à la fois la plus importante et la plus négligée, ce qui, incidemment, s’explique aussi parce qu’elle est particulièrement complexe et frustrante. Pour le niveau d’ambition dont il est question, il faut en effet disposer d’une cartographie détaillée du patrimoine informatique. Or celle-ci, quand elle existe (ce qui est loin d’être toujours le cas), est souvent fragmentée et parcellaire, alors que seule une vision d’ensemble permettra d’avancer sereinement, en maîtrisant les risques.

L’exercice auquel je pense porte sur plusieurs dimensions. La première est architecturale, avec un recensement des composants sur les différentes couches d’architecture (matérielle, technique, applicative, fonctionnelle). Sur ce fond de carte, il faut ensuite identifier les relations et dépendances entre éléments, également sur chaque niveau. À ce stade vous devriez avoir un bon aperçu du cauchemar qui vous attend pour la suite (l’exemple, ancien, de Rabobank vous en donnera une idée).

Autre aspect à intégrer, celui de la performance des systèmes. Pour chaque brique, on identifie ses forces et faiblesses (propension aux pannes, limitations connues lors d’évolutions, tensions sur les ressources, besoins de maintenance, inadéquation aux attentes…), de manière à repérer rapidement les point les plus sensibles. En croisant ces données avec les estimations de criticité – directe ou indirecte (par dépendance) –, vous pourrez dégager une vue préliminaire des axes prioritaires de rénovation.

En comparaison, la définition d’une cible est plus aisée. Mais elle recèle aussi ses pièges. En tête de liste, je place l’impossibilité pour beaucoup de personnes, notamment celles qui ont de l’expérience et de l’ancienneté, à qui est fréquemment confiée la tâche, de s’abstraire de l’existant, ce qui les conduit à brider les opportunités. Par exemple, qui pensera à renverser les habitudes afin de mettre enfin le client au centre de la banque… et donc du système d'information (au lieu de la tenue de compte) ?

Dans un autre registre, il paraît généralement difficile de projeter les objectifs à considérer sur ce que sera le marché à une échéance lointaine, ce qui est pourtant indispensable. Même si des ajustements sont toujours possibles (et souhaitables) pendant la vie de la démarche, ce que l'on construit pour les 20 prochaines années, qui ne sera disponible que, au mieux, dans cinq ans, doit être envisagé pour le monde de cette période lointaine, pas celui d'aujourd'hui (et encore moins celui d'hier).

Enfin la sélection de l’approche de modernisation représente un dilemme inextricable. Les travaux précédents donnent normalement les moyens d’évaluer les risques et les coûts des scénarios (y compris celui dans lequel rien n'est fait) avec un minimum de précision, procurant ainsi des critères relativement factuels et objectifs. Mais la décision finale restera toujours délicate à prendre. En me cantonnant à deux options que je tends à privilégier, voici néanmoins quelques suggestions d’orientation.

Si des faiblesses majeures ressortent sur l’expérience client, il peut s’avérer raisonnable de créer une nouvelle banque, par exemple destinée à une population spécifique, qui pourra être conçue en alignement avec la cible, avec le maximum d'indépendance de la structure historique. Lorsqu’elle aura atteint la maturité, elle prendra la place de la solution obsolète. En revanche, si le cœur du système semble être le plus fragile, une première étape d’isolation (via une couche d’interfaces) permettra d’anticiper un remplacement. La difficulté est alors de concevoir ces interfaces sans se préoccuper des contraintes du présent : elles doivent être développées pour le futur cœur.

Ce ne sont là que quelques pistes de réflexion issues de mes observations des manières de travailler dans les départements informatiques des grands groupes, à travers leur propre transformation sur les (environ) quatre dernières décennies. Notez que, quelle que soit votre position par rapport à l'hypothèse d'une modernisation, la réalisation d'un état des lieux exhaustif et détaillé vous sera toujours utile…

Un billet de Janet Worthington (Forrester) attire mon attention sur une loi américaine – promulguée avant l'arrivée de l'administration en place aujourd'hui – imposant aux agences fédérales de partager le code des applications développées par leurs soins. Une bonne idée… qui risque hélas de se heurter aux dures réalités des « vieilles » organisations.

Si Janet rapproche l'initiative de la devise écologique de « réduction, réutilisation, recyclage », je préfère, pour ma part, m'en tenir à l'analogie du modèle du logiciel libre. En l'occurrence, l'objectif du législateur est, à travers l'obligation de distribution des composants créés en interne, de promouvoir leur adoption par d'autres entités dans le but d'optimiser le rendement des investissements associés (représentant 12 milliards de dollars annuels) et améliorer l'efficacité de l'informatique gouvernementale.

Dans cette perspective, le texte exige que tous les artefacts produits par les équipes – non seulement le code mais également la documentation, les modèles de données, les schémas d'architecture, les scripts de configuration, les scénarios de test… – soient mis à disposition sur au moins un dépôt, privé ou public, accessible à l'ensemble du personnel fédéral, et restent activement gérés par l'administration d'origine. Sur l'autre versant, les « clients » potentiels sont encouragés à s'approprier les éléments qui répondent à leurs besoins, en les faisant évoluer à leur convenance si nécessaire.

Sur le principe, on comprend la logique de la démarche : avant de dépenser des fortunes et de longs mois (voire des années) dans la recherche de solutions sur le marché ou la conception et la réalisation d'une nouvelle application, en partant de rien, il est préférable de commencer par regarder ce qui est disponible dans un environnement voisin, et ainsi économiser de l'argent, du temps et quelques frustrations.

Cependant, alors que l'analyste de Forrester enchaîne sur diverses règles à respecter pour la fiabilité du système, du point de vue de ceux qui vont publier leurs travaux de la sorte, je m'interroge d'abord sur les chances de concrétisation de la promesse, sous l'angle des utilisateurs potentiels. En effet, l'accès aux sources des outils exploités dans la structure est un premier pas vers une mutualisation des ressources mais il ne constitue certainement pas l'étape la plus complexe sur ce chemin.

La principale difficulté à résoudre est culturelle : dans des départements informatiques habitués à mettre au point leurs propres logiciels, en général avec le soutien inconditionnel de leurs donneurs d'ordres, le syndrome NIH (pour « Not Invented Here ») de rejet de tout ce qui vient de l'extérieur (aussi proche soit-il), sous prétexte de différences de contexte, par exemple, agit comme un puissant mécanisme de défense immunitaire visant, plus ou moins inconsciemment, à protéger son périmètre.

Des grands groupes privés, entre autres du secteur financier, se sont depuis longtemps essayés à mettre en place des stratégies de distribution libre des logiciels produits en vue de stimuler la réutilisation. Tous ont maintenant compris que ces efforts n'aboutissent qu'à la condition expresse que, en parallèle, un programme pédagogique au long cours soit déployés afin que le premier réflexe dans les nouveaux projets ne soit plus d'énumérer les particularités qui justifient une approche ad hoc et devienne de prendre de la hauteur pour repérer des solutions existantes à des problématiques similaires, puis identifier les adaptations éventuellement nécessaires.

Quand Gartner présente une liste de 12 technologies disruptives émergentes que les entreprises devraient prioriser au cours des 5 prochaines années, mon attention est spécialement attirée par l'une d'entre elles, susceptible de redessiner le paysage du secteur financier : l'application composable (par l'intelligence artificielle).

Le principe, en soi n'est pas totalement nouveau et il se retrouve régulièrement, en particulier, dans les grandes tendances identifiées chaque année par le cabinet. Mais, alors que sa concrétisation peine jusqu'à maintenant à se matérialiser, l'apparition et la progression rapide de l'IA générative lui donne peut-être une nouvelle occasion de s'exprimer…, en fournissant au passage aux entreprises qui s'y intéresseront (enfin !) une opportunité de se différencier dans un monde en pleine mutation.

Bien que le changement n'en soit encore, évidemment, qu'à ses prémices, il commence à se manifester dans les esquisses d'agents intelligents ou bien dans le recours à l'IA pour la création logicielle, expérimentés ici et là. Derrière ces deux orientations, s'impose l'idée de demander à un robot, en langage naturel, d'exécuter une tâche plus ou moins complexe (ponctuellement dans un cas, de manière programmatique dans l'autre) en lui laissant toute latitude de rechercher et assembler les services nécessaires.

Cependant, avant d'atteindre un tel objectif, il faudra d'abord remettre en question les pratiques toujours en vigueur à ce jour dans l'ingénierie logicielle, chez les éditeurs de solutions professionnelles, du point de vue des analystes de Gartner, mais également, selon moi, dans tous les grands groupes, notamment de l'industrie de la finance où le système d'information constitue une composante critique de fonctionnement.

Car si les robots (RPA) de première génération peuvent se contenter de piloter les outils existants à travers leur interface graphique, en simulant un utilisateur humain, cette approche se révèlera rapidement trop limitée pour réaliser toute les promesses de la « composabilité ». L'obligation de redéfinir les services de l'organisation sous leur forme élémentaire, en totale indépendance les uns des autres, ne sera alors plus une option à envisager après l'automatisation des processus mais un impératif de survie.

Dans une perspective plus technique, les API ouvertes ne seront plus seulement une exigence réglementaire ou un support d'une stratégie de banque ou d'assurance « enfouie », elles deviendront les briques indispensables pour donner aux clients et aux collaborateurs la faculté de gérer leurs activités comme ils le souhaitent, à travers des commandes simples, à la portée de tous, sans avoir à se conformer aux structures et parcours rigides édictés par des concepteurs à la vision forcément étroite.

Les acteurs qui ont compris, parfois depuis des années (surtout dans la FinTech), que ce genre d'architecture représentait une garantie pour l'avenir, ne serait-ce qu'en raison de sa flexibilité, sont dès aujourd'hui bien positionnés pour se placer en pointe d'une nouvelle ère des services financiers, libérant les clients de contraintes indues. Les autres n'ont que peu de temps devant eux pour tenter de revenir dans la course, tellement l'ampleur du chantier qui les attend, trop longtemps repoussé, est énorme.

La publication par Monzo d'une réactualisation de ses « principes d'ingénierie », dont la première itération datait de 2018, nous offre une occasion d'étudier une démarche qui est non seulement originale (je n'ai jamais vu d'équivalent dans mes diverses expériences) mais également beaucoup plus ambitieuse que son titre ne le laisse croire.

En effet, il n'est définitivement pas question d'un simple jeu de recommandations destinées à améliorer la productivité des équipes informatiques. Certes, une partie des propositions visent explicitement à fiabiliser au maximum les processus de développement, sur la base d'une (vraie) philosophie agile. Mais les fondations de la culture d'entreprise sont tout aussi importantes, avec un accent particulier placé sur l'initiative et la responsabilité personnelles dans un contexte collaboratif.

Dans le premier domaine, les orientations données se veulent surtout pragmatiques, sans s'encombrer de dogmes ni de rituels (qui peuvent avoir leur place, mais à un niveau opérationnel moins critique). Privilégier les petits changements fréquents, faciles à valider… et à annuler en cas de problème. Considérer le rapport effort vs. impact plutôt que de viser la perfection. Investir dans les moyens d'accélérer l'organisation, par exemple avec des automatisations tactiques. Toujours penser aux tests en amont…

Dans le même registre, une série de préceptes prennent déjà un recul stratégique sur la manière de bâtir le système d'information. Comment penser générique (un impératif) sans s'enfermer dans une approche théorique exorbitante ? Il faut faire la différence entre préparer pour l'avenir et intégrer immédiatement toutes les options imaginables. Concevoir des systèmes impossibles à mal utiliser (par erreur ou par malveillance). Anticiper comment on reviendra sur une décision si elle s'avérait mal avisée…

Puis viennent les préconisations d'ordre comportemental, qui reflètent profondément les valeurs internes de Monzo. Aider les autres lorsqu'ils sont bloqués sur une difficulté constitue une utilisation bénéfique du temps de travail. En miroir, assumer pleinement les problèmes identifiés dans son propre périmètre, jusqu'à leur résolution, y compris s'il faut sortir de ses prérogatives habituelles. Ne jamais hésiter à améliorer l'existant dès qu'une faiblesse est détectée, même si elle n'entre pas directement dans le rôle ou le domaine assigné. Ne jamais oublier les humains qui passeront derrière soi et devront être en mesure de lire, comprendre et réparer le code écrit…

La démarche de Monzo devrait inspirer d'autres entreprises, entre autres celles du secteur financier, où les équipes informatiques exercent une mission vitale pour leur fonctionnement. Ses principes peuvent paraître relever du seul bon sens et, à ce titre, superflus. Il n'en est rien : les pratiques individualistes (et parfois compétitives), notamment, sont en général une norme implicite. Rappeler ce qui est autorisé (en fait, recommandé) est donc indispensable, ne serait-ce que pour éviter des frictions.

Si la présentation par BBVA de son utilisation de l'intelligence artificielle laissait un sentiment mitigé, la révélation par OpenAI des résultats obtenus cinq mois après son déploiement de ChatGPT (version entreprise) auprès de 3 000 collaborateurs offre une perspective plus intéressante… quoique pas particulièrement sur ses cas d'usage.

D'emblée la démarche était guidée par une vision assez radicale pour une institution financière, puisqu'il s'agissait de fournir à des utilisateurs non spécialistes les moyens de s'approprier un outil avancé, complémentaire de ce que sont par ailleurs capables de livrer les centres d'expertise existants en analyse de données et IA. Car il n'est pas uniquement question d'une instance interne de l'assistant bien connu mais bien de permettre aux utilisateurs d'en concevoir des déclinaisons personnalisées.

Sous le contrôle des départements de risques, de conformité et de cybersécurité et avec un accompagnement assuré par des équipes de champions (plutôt pour l'encouragement à l'adoption) et de « sorciers » (pour l'appui opérationnel), les 3 000 employés retenus pour la phase pilote ont déjà produit quelques 2 900 solutions ad hoc dans des domaines aussi variés que les ressources humaines, les finances, le marketing ou le juridique, dont la plupart visent à accélérer les processus en place.

Les exemples cités comprennent la qualification de crédit pour les entreprises, avec une recherche automatisée des documents appropriés, jusqu'alors manuelle, l'analyse de sentiment sur les commentaires libres des enquêtes de satisfaction, la préparation de réponses aux 40 000 questions juridiques posées annuellement par les conseillers. Comme toujours (pour l'instant, du moins), rien de révolutionnaire dans ces applications, aussi utiles soient-elles. Mais ce n'est peut-être pas le plus important…

La caractéristique la plus notable de la démarche de BBVA est de se positionner dans une logique de « développement citoyen » (ou de démocratisation de la création de composants logiciels), objet de nombreux fantasmes dont la facilité de prise en main de ChatGPT rend aujourd'hui possible la concrétisation, au moins sur un périmètre spécifique. Pleinement assumé par les responsables de la banque, ce choix porte l'ambition de rapprocher la capacité à élaborer des solutions des personnes qui sont aux premières loges pour identifier les besoins, pour plus d'efficacité et de réactivité.

Par ailleurs, BBVA capitalise sur sa stratégie de déploiement unifié de la technologie d'OpenAI pour instaurer les conditions d'une collaboration étendue entre ses plus de 120 000 employées, répartis dans des métiers variés et différents pays, de l'Amérique Latine à la Turquie en passant par l'Espagne, l'Italie et la Suisse. En support de cet objectif, elle a déployé le « GPT Store », bibliothèque ouverte dans laquelle les participants sont invités à partager leurs solutions, pour réutilisation et/ou adaptation par l'ensemble de la communauté. Il compte à ce jour plus de 700 entrées.

La mutualisation des ressources et des moyens que, en dépit de nombreux efforts (et BBVA figure en pointe en la matière, de longue date), ne sont jamais parvenus à matérialiser les responsables de systèmes d'information des grands groupes financiers, en raison de l'hétérogénéité des infrastructures et, souvent, des pratiques et cultures locales, deviendrait-elle une réalité avec l'implémentation de ChatGPT ? L'hypothèse est désormais envisageable : se confirmera-t-elle ? Les collaborateurs en décideront.

Alors que les grandes banques se trouvent aujourd'hui dans une énième vague de réduction des coûts, qui affecte particulièrement, comme toujours, leurs départements informatiques et, par ricochet, leur capacité d'innovation, McKinsey propose de réfléchir à une voie plus prometteuse… consistant à viser l'optimisation de leur productivité.

D'emblée, l'article souligne l'obstacle principal, à savoir que les instruments de mesure nécessaires n'existent pas, dans la plupart des institutions financières. En effet, le niveau de dépense des DSI est parfaitement connu – ce qui explique pourquoi il est ciblé dans les périodes de « rationalisation » – mais, malgré tous les discours traitant de retour sur investissement, celui-ci est considéré en amont des projets, en vue de les valider ou de les rejeter, mais il n'est jamais réellement évalué après déploiement.

Or les rares exemples d'établissements maîtrisant la rentabilité concrète de leur technologie démontrent la possibilité d'autres moyens de réaliser des économies, non pas en coupant des budgets à l'aveugle – puisque, une fois évacuées les fortunes affectées au maintien en condition opérationnelle des systèmes en place, nul ne sait ce qui dégage vraiment de la valeur faute d'indicateur approprié – mais en appliquant quelques recommandations propres à renforcer l'efficacité là ou elle compte.

La première d'entre elles est triviale mais totalement négligée, par méconnaissance de la réalité du terrain par les responsables. Il s'agit tout simplement de développer l'automatisation des tâches : bien que les prétentions soient élevées, il s'avère que les équipes perdent une énergie considérable à provisionner des environnements de travail, à réaliser la partie souvent importante des tests qui restent manuels, à installer les livraisons en production (ne serait-ce qu'en raison des circuits de décision)… Le temps passé à écrire du code est minime (inférieur à 50% du total en moyenne) !

Je ne m'attarderai pas sur la deuxième proposition de McKinsey, d'adopter des outils à base d'intelligence artificielle (générative) afin d'accélérer les projets. Entre la perte de vue de la priorité précédente qu'elle a toutes les chances d'entraîner et son incompatibilité (voire incohérence) avec la dernière préconisation (ci-après, sur l'expertise), elle relève selon moi du syndrome de la peur de rater quelque chose (FOMO en anglais) exacerbé par les cabinets de conseil, que j'ai déjà dénoncé par ailleurs.

La suggestion suivante est à nouveau de celles dont on devrait s'étonner qu'il faille encore la marteler, puisqu'elle correspond à un des piliers des méthodes agiles que les grands groupes se vantent d'avoir mises en œuvre… Pourtant, qui pratique l'intégration des contributeurs métier et informatiques (infrastructure comprise) au sein d'une équipe autonome, avec un objectif commun, simplifiant et rendant plus fluides les interactions, aboutissant ainsi à un résultat idéal dans les meilleurs délais ?

Enfin, le dernier volet concerne le recrutement, avec un constat qui risque de heurter les habitudes mais qui devient de plus en plus actuel avec l'évolution de l'outillage : il vaut mieux, pour le rendement, privilégier des profils de haut niveau, peu nombreux, que des armées de professionnels peu expérimentés, prestataires externes en tête. La difficulté est alors de parvenir à les séduire et de s'assurer leur fidélité, surtout quand des décennies de préférence pour les débutants bon marché ont fait disparaître le vivier de candidats potentiels (reconvertis en managers plus ou moins compétents).

En résumé, les recommandations de McKinsey ne présentent guère d'originalité… mais elles restent essentielles parce qu'elles ne sont pas appliquées dans l'immense majorité des banques, qui ne perçoivent encore leur département informatique que comme un centre de coûts, alors qu'il est désormais le moteur de leur activité.

Depuis les premiers pas de la programmation informatique, quelques visionnaires ont toujours rêvé de la possibilité de créer des logiciels sans compétences particulières. Après les vagues récentes des outils sans code (ou presque) puis des assistants intelligents, GitHub Spark esquisse maintenant la concrétisation de la promesse globale.

D'immenses progrès ont été accomplis au fil des années, par exemple depuis les langages de quatrième génération des années quatre-vingt-dix, mais les plates-formes qui vantent jusqu'à ce jour leur facilité de prise en main n'en restent pas moins destinées à des personnes qui, bien que n'ayant – dans le meilleur des cas – plus nécessairement besoin de maîtriser un langage de programmation, doivent malgré tout adopter un mode de pensée et un certain nombre de réflexes propres à cette discipline.

Dans une large mesure, les pionniers se sont essentiellement attachés à automatiser la génération de code mais pas véritablement la production d'applications en tant que telles. Voilà justement le terrain sur lequel GitHub Spark veut apporter une perspective réellement nouvelle grâce aux avancées de l'intelligence artificielle. Au-delà de l'écriture des instructions qui composent un module capable de traiter un problème, son objectif est de convertir l'énoncé d'une fonction en un service directement opérationnel.

En pratique, vous commencez par décrire ce que vous souhaitez accomplir (maintenir un agenda de groupe, suivre la distribution d'argent de poche à vos enfants, apprendre une langue étrangère…), vous spécifiez quelques éléments de présentation, vous choisissez votre modèle d'IA parmi les quatre proposés (dont l'incontournable ChatGPT)… et c'est tout. Vous disposez instantanément d'une micro-application que vous pouvez utiliser et partager avec vos amis ou une communauté étendue.

Les détails techniques d'implémentation sont totalement masqués (sauf pour ceux qui souhaitent les explorer, bien entendu) : le code lui-même, naturellement, mais également l'organisation et la gestion des données nécessaires, les problématiques de déploiement (via une interface web, qui peut aussi prendre la forme d'une app mobile)… L'utilisateur passe ainsi de la définition de la tâche à remplir, en langage naturel, à l'exécution du logiciel, sans plus de complication, de manière transparente.

Le même mécanisme opère ensuite pour des évolutions, qu'il s'agisse de modifier les comportements obtenus ou d'ajouter de nouvelles options : il suffit d'indiquer ses desiderata au moteur, en anglais, et le résultat est adapté en conséquence, toujours prêt à l'emploi. Si les demandes ne sont pas suffisamment précises, GitHub Spark vous livre entre 3 et 6 variantes parmi lesquelles vous êtes invité à faire votre choix. Et la faculté de revenir à tout moment à une version antérieure encourage l'expérimentation.

Après des décennies de rêves déçus, l'arrivée d'une plate-forme conçue pour transformer une simple idée en un logiciel fini est finalement en train d'émerger (quoique dans une approche de démonstration uniquement, pour l'instant). Il existe une certaine ironie à en voir une de ses premières incarnations émaner d'un fournisseur de solutions dédiées aux développeurs… qui ne craint probablement pas de voir son audience passer d'un cercle restreint de professionnels à l'ensemble du grand public.

Bien qu'il faille la prendre avec un minimum de précautions puisqu'elle est commanditée par un éditeur spécialisé (JFrog), cette enquête d'IDC qui révèle que les développeurs de logiciels passent une partie (trop) importante de leur temps dans des tâches liées à la sécurité devrait probablement interpeller les responsables informatiques.

Par exemple, la moitié de l'échantillon – issu des différents métiers concernés, depuis les product owners jusqu'aux chefs de projet en passant par les professionnels (seniors) du code, dans des entreprises américaines, britanniques, françaises et allemandes – déclarent consacrer 19% de leurs efforts à des contrôles et autres corrections relatifs à la sécurité… souvent en dehors des heures de travail « normales », qui plus est. Cela représenterait un budget d'environ 28 000 dollars annuels par développeur.

Dans un sens, mais l'étude n'aborde pas ce point de vue, ces statistiques constituent une excellente nouvelle. Elles démontrent en effet que les démarches dites « DevSecOps », qui visent à intégrer les considérations de sécurité en continu, au cœur de la chaîne de création du logiciel (avec les exigences de déploiement en production), commencent à s'ancrer dans les habitudes, ce qui profite automatiquement à la qualité des solutions livrées et à la réduction des risques lors de leur utilisation.

En revanche, au vu des estimations avancées, se pose tout de même la question d'un possible excès. Après tout, on peut considérer que le talent des personnes qui sont recrutées, toujours plus difficilement et souvent à prix d'or, pour écrire des applications est quelque peu gaspillé quand il leur faut aussi se préoccuper de problématiques périphériques, certes critiques pour le résultat final mais qui ne requièrent pas, en principe, leur expertise, d'autant que leur prise en charge devrait être automatisée.

Tel est justement le point sur lequel JFrog insiste particulièrement, en imputant l'essentiel de la faute à l'outillage mis en œuvre, soit qu'il soit mal adapté et exige des vérifications manuelles complémentaires inutiles ou redondantes, soit que son hétérogénéité et l’absence d’expérience utilisateur sans coutures engendrent des ruptures régulières dans le flot d’activité normal, au détriment de la productivité. Cette réalité conduit à relativiser le constat de maturité des organisations… et de leurs fournisseurs.

Mais, comme toujours, l’équipement n’est peut-être pas le seul coupable direct. Je soupçonne que le manque de culture de sécurité chez les ingénieurs, quand il ne s’agit pas de leur spécialité officielle, joue également un rôle crucial. D’abord parce que, à l’opposé de la philosophie « DevSecOps », il tend à laisser s’introduire les failles, qui ne sont corrigées qu’a posteriori, lorsqu’elles sont détectées par une sonde. Ensuite parce que la présence même de solutions automatiques encourage la « paresse » : pourquoi faire attention puisque les erreurs seront toujours repérées, plus tard ?

Si mon hypothèse était confirmée, nous aurions ainsi affaire à un effet pervers classique de la technologie : déchargeant les individus de leur responsabilité alors qu'elle est encore incapable de les remplacer totalement – quand bien même elle se gausse d'intelligence artificielle –, elle s'avère finalement plus néfaste que bénéfique.

Quand Open Bank Project – qui développe et promeut ses API bancaires auprès des institutions du monde entier depuis bientôt 15 ans – sacrifie à l'incontournable mode de l'intelligence artificielle, son approche, pragmatique, s'avère à la fois modeste à court terme et ambitieuse à long terme. Elle pourrait certainement inspirer l'industrie.

Dans un premier temps, un classique assistant virtuel, baptisé Opey et propulsé par la technologie d'OpenAI (évidemment…), fait désormais son apparition dans l'espace de découverte et d'expérimentation de la jeune pousse. Sa mission consiste simplement à répondre à toutes les questions que les développeurs (préalablement enregistrés) se posent sur les nombreuses interfaces mises à leur disposition et, plus intéressant, la meilleure manière de les exploiter afin de satisfaire un besoin spécifique.

Deux illustrations élémentaires citées par Simon, le fondateur historique d'OBP, permettent de mieux comprendre son fonctionnement. Il évoque ainsi sa demande des points d'entrée disponibles pour obtenir des informations sur les GAB, qui les lui restitue sous forme d'une liste structurée, puis, dans une requête un peu plus élaborée, son interrogation sur le moyen de trouver le numéro de téléphone d'un client nommé Simon Redfern (sachant qu'il n'existe pas de méthode directe d'accès par le nom).

Les bénéfices de cette implémentation sans prétentions sont notables, entre, par exemple, sa capacité à accompagner les utilisateurs dans leur compréhension des fonctions proposées, selon leur objectif et leur représentation mentale, et la suggestion d'options parfois obscures (qui surprennent jusqu'à Simon lui-même !), en passant par le premier niveau de support offert de la sorte, qui contribue à accélérer les projets et augmenter la productivité des équipes sans exiger un coûteux centre d'assistance.

La vision portée avec Opey ne s'arrête toutefois pas à cette aide personnalisée aux développeurs. Après tout, une fois que le robot est en mesure de décrire comment effectuer telle ou telle tâche, il ne reste qu'un petit pas à franchir pour qu'il exécute celle-ci en toute autonomie. N'importe quelle partie prenante – analyste marketing, conseiller financier, responsable commercial…, voire client – pourrait le solliciter, en langage naturel, de manière à recueillir instantanément une information (ou peut-être, réaliser une opération ?) via les API existantes. La seule contrainte à résoudre avant de concrétiser ce rêve réside dans la gestion des identités et des autorisations.

Au bout du modèle, imaginez une banque entièrement pilotée à travers un assistant virtuel omniscient, capable d'interpréter et de traiter toutes les demandes de ses utilisateurs – après avoir contrôlé leurs accréditations – formulées avec leurs propres mots. Plus besoin d'application monolithique ni de moteur de gestion de processus rigide, l'intelligence artificielle se charge d'orchestrer les différents services nécessaires de bout en bout… Naturellement, cette perspective est encore lointaine, non seulement parce que les technologies d'IA ne sont pas tout à fait mûres mais surtout, hélas, parce qu'il faudrait que l'intégralité du système d'information soit d'abord exposée en API…

Depuis les premiers pas de l'informatique, ses promoteurs ont toujours cherché à en démocratiser l'accès et, en particulier, à rendre la création de logiciel accessible au commun des mortels. Les récents progrès de l'intelligence artificielle nous rapproche de ce rêve et Amazon en offre une esquisse avec son nouvel AWS App Studio.

Étonnamment, dans une période propice aux exagérations les plus éhontées sur le potentiel de l'IA, le géant de l'infonuagique reste relativement modéré dans son discours, qui s'adresse principalement, il est vrai, aux décideurs d'entreprises peu enclins à gober les promesses marketing sans preuves ni vérification. Il se positionne donc « simplement » sur le marché prolifique et de plus en plus populaire des outils « low-code » qu'il espère tout de même faire évoluer vers sa deuxième génération.

Si elles rencontrent aujourd'hui un succès incontestable, ces plates-formes qui autorisent le développement accéléré d'applications en requérant un minimum de compétences spécialisées n'en comportent pas moins quelques défauts gênants, dont les principaux sont leur coût élevé et leur lourde courbe d'apprentissage et de prise en main. En réponse, Amazon propose donc une solution gratuite (seule l'utilisation, dans le cloud, des logiciels produits est facturée) dont l'IA facilite radicalement la mise en œuvre.

En résumé, l'utilisateur est d'abord invité à décrire en langage naturel ce qu'il souhaite construire en précisant les sources d'information à intégrer et le fonctionnement attendu. En quelques secondes, il se voit alors présenter un synopsis détaillé dont il peut ensuite ajuster les différents éléments grâce à des modules de composition interactifs (pour l'interface graphique) et avec l'aide d'assistants virtuels. Une fois satisfait, il ne lui reste qu'à déclencher l'écriture du code et demander son déploiement immédiat.

Forte de sa longue expérience avec AWS, Amazon garantit une capacité de montée en charge incomparable et un niveau de sécurité élevé, sous le contrôle permanent des équipes dédiées de l'organisation cliente (via, entre autres, ses fonctions de gestion fine des politiques de droits et ses options d'administration et de suivi), qui lui permettent de cibler les firmes aux exigences les plus extrêmes, y compris pour des motifs réglementaires. Un des cas d'usage suggérés dans la communication officielle concerne d'ailleurs la gestion de sinistres, dans le secteur de l'assurance.

Outre son adoption plus rapide que la concurrence, les avantages évoqués afin de vanter AWS App Studio sont typiques de sa catégorie, à savoir, notamment, l'opportunité qu'il procure de créer aisément, en évitant le classique goulet d'étranglement des équipes projet surchargées, des applications robustes automatisant les centaines de tâches manuelles répétitives qui encombrent les processus de toutes les entreprises du monde. Le message reste pourtant réaliste : l'outil est destiné à des populations qui, sans avoir de connaissance de la programmation, possèdent néanmoins une maîtrise des principes et des concepts du logiciel (chefs de projet, architectes, analystes de données…). Pour la vraie démocratisation, il faudra attendre encore un peu…

Crucial autant pour de viles raisons réglementaires que pour la satisfaction des utilisateurs (et l'ouverture aux audiences les plus larges possibles), l'accessibilité des applications web et mobiles est souvent reléguée au second rang des préoccupations des concepteurs et développeurs. TestParty propose donc d'en automatiser l'intégration.

La capacité ou la facilité pour les millions de personnes dans le monde qui souffrent d'un handicap – depuis la dyslexie jusqu'à la cécité – de profiter de leurs services en ligne devrait constituer la première motivation des entreprises à s'assurer que leurs plates-formes n'excluent aucune catégorie de population. Et si elle n'était pas suffisante, les législations qui se renforcent constamment, telles que l'Acte Européen sur l'Accessibilité, fournissent en principe un puissant argument supplémentaire.

La situation ne progresse pourtant que très lentement et, à ce jour, les solutions non conformes continuent à proliférer. Au vu du bon sens qui régit la plupart des exigences et des multiples outils de diagnostic qui aident à leur mise en œuvre, on peut se demander ce qui freine tellement l'adoption. Je soupçonne que la coupable est une certaine paresse intellectuelle vis-à-vis de ce qui est considéré avant tout – à tort, bien sûr – comme une contrainte susceptible de nuire à la créativité et à l'esthétique.

Si mon hypothèse est valide, l'approche imaginée par TestParty apporte une réponse optimale au problème. Avec la même logique que les « copilotes » dopés à l'intelligence artificielle qui se répandent rapidement dans les départements informatiques en support à la programmation, ses algorithmes analysent le code rédigé et suggèrent au développeur, en temps réel, les corrections nécessaires en vue de garantir l'accessibilité du résultat final, celles-ci étant évidemment prêtes à intégrer, en un clic.

La jeune pousse, américaine, n'en est qu'à ses débuts – elle vient de conclure sa première ronde de financement – et son produit est donc encore loin d'être complet, autant pour ce qui concerne les environnements qu'il prend en charge que du point de vue des règles contrôlées et implémentées. Son offre n'en est pas moins très prometteuse pour l'amélioration globale de la qualité des applications… et la conformité, dont elle est d'ailleurs capable de fournir une mesure précise, par exemple dans le cadre d'une remédiation imposée à la suite d'une procédure judiciaire.

J'en rêvais depuis longtemps, TestParty concrétise enfin, en partie grâce aux progrès de l'IA, la résolution d'un dilemme complexe pour les organisations qui interagissent de plus en plus avec leurs diverses parties prenantes à travers des médias « digitaux », après même qu'elles aient pris conscience de l'enjeu : l'impossibilité endémique de faire prendre en compte les fondamentaux de l'accessibilité par les équipes projet en place face au coût et à la lourdeur qu'engendre l'intervention systématique d'un spécialiste.

Il s'agit déjà aujourd'hui d'un des cas d'usage les plus populaires de l'intelligence artificielle, au moins sous forme expérimentale. Le cabinet Gartner prédit que, d'ici 2028, trois quarts des développeurs de logiciels l'exploiteront afin d'optimiser leur travail quotidien, dans de multiples dimensions. En attendant d'être entièrement remplacés ?

Bien que moins de 10% des professionnels confirmaient recourir à ce genre d'outils au début de 2023, l'hypothèse des analystes est facile à soutenir puisque, selon une enquête globale datant du troisième trimestre, près de deux tiers (63% précisément) des organisations ont fait au moins un pas dans cette direction. Naturellement, ces statistiques n'ont rien d'étonnant au vu, d'une part, de l'engouement médiatique pour l'IA générative et, d'autre part, de son adéquation particulière à ces usages.

La question qui se pose maintenant chez les responsables de l'ingénierie logicielle n'est donc plus, dans la plupart des cas, de décider le déploiement généralisé, à court ou moyen terme, mais plutôt de formaliser une équation de valeur convaincante auprès des décideurs afin de profiter au plus vite des bénéfices espérés. Car une perspective qui se restreindrait à un traditionnel calcul de ROI, mettant en avant les économies et, peut-être, les gains de temps, raterait une grande partie de la mutation qui se joue.

En effet, les assistants codeurs les plus sophistiqués ne se contentent plus de compléter automatiquement ce qu'écrit le programmeur (évidemment) ni de générer (recopier, en réalité) des modules complets. Ils se transforment progressivement en compagnons attentifs toujours prêts à signaler les erreurs commises, à suggérer des améliorations ou d'autres manières d'aborder un problème, par exemple. De la sorte, ils stimulent la créativité et procurent des opportunités de progresser continuellement.

Appréhendée sous cet angle, l'intelligence artificielle deviendrait alors un facteur de rétention et de satisfaction des collaborateurs concernés, appréciant grâce à elle une expérience utilisateur bonifiée (quand l'outil est parfaitement intégré à l'environnement et aux processus de développement), tout en promettant à leur employeur, outre le surcroît de productivité, une meilleure qualité des produits livrés, autant sur le plan de la fiabilité (et la réduction des risques d'anomalies) que de l'adéquation aux besoins.

Le message positif de Gartner devrait trouver un écho favorable dans les directions informatiques qui peinent à recruter et à conserver les talents nécessaires à la transition « digitale » du monde. Il mérite toutefois d'être tempéré car les premiers intéressés commencent à entendre un refrain lancinant évoquant de manière toujours plus sérieuse et crédible leur remplacement par la machine… à une échéance qui ne relève plus de l'utopie. Pas sûr, dans ces conditions, qu'ils accueillent l'IA avec bienveillance.

Dans ses métiers autour de l'information, Thomson Reuters se place logiquement aux premières loges des opportunités de l'intelligence artificielle. Voilà pourquoi son expérience, en particulier en matière de démocratisation auprès de l'ensemble de ses collaborateurs, revêt un caractère innovant digne d'intérêt pour d'autres secteurs.

Engagée depuis plusieurs décennies (?) dans l'exploitation de l'IA, notamment en vue de faciliter l'exploration de ses montagnes de données, l'agence a immédiatement perçu la valeur qu'elle pouvait tirer de sa variante générative lorsque le lancement public de ChatGPT a démontré la maturité qu'elle avait atteinte. Il lui devenait possible, par exemple, d'aider ses collaborateurs ou ses clients à parcourir, synthétiser et filtrer les contenus restitués par une recherche thématique, jusqu'alors traités manuellement.

En fait, au vu des capacités soudain disponibles, la multitude de cas d'usage envisageables est rapidement apparue comme son problème numéro un. Et parce qu'il était impensable, surtout dans le marché de l'emploi actuel, de trouver et recruter les centaines d'experts dont elle aurait eu besoin, elle a entièrement focalisé ses efforts sur la mise en place d'une approche industrielle des implémentations, capable de répondre dans les meilleurs délais aux attentes et aux demandes des utilisateurs.

La solution retenue consiste donc à permettre à tous les salariés de créer leurs propres applications. Mais, naturellement, une telle ouverture requiert un cadre rigoureux, dans un contexte aussi exigeant que les services aux professionnels du juridique, de la fiscalité, de la comptabilité… En premier lieu, outre le respect d'exigences strictes de sécurité et de confidentialité, la plate-forme de Thomson Reuters manipule exclusivement des données internes, de manière à garantir la qualité des résultats.

Par ailleurs, une stratégie de construction de briques réutilisables à grande échelle a été instaurée. Les spécialistes aguerris consacrent l'essentiel de leurs compétences à la fabrication de ces composants primaires. Ensuite, la faculté de les mettre en œuvre dans différentes situations autorise l'accélération des développements, aussi bien pour les projets d'ampleur destinés à un passage en production que pour les expérimentations et autres initiatives tactiques d'employés lambda.

Les exemples évoqués concernent, entre autres, des éléments conçus dans le but de tester plusieurs modèles de langages (« LLM »), afin de sélectionner facilement le plus efficace pour une tâche donnée, ou encore une sorte de générateur de « prompts » grâce auquel un néophyte est en mesure de formuler une question élaborée dans les règles de l'art pour sa prise en charge par l'IA générative, sans avoir à apprendre au préalable toutes les subtilités et les complexités inhérentes à ce genre d'exercice.

En filigrane, la perspective proposée par Thomson Reuters révèle la profonde limitation des outils d'intelligence artificielle distribués aujourd'hui. Tant que leur exploitation requerra une formation dédiée, sinon une qualification professionnelle extensive, ils ne pourront pas s'imposer (dans les entreprises) avec l'universalité qu'on leur prête généralement. Cependant, les moyens émergent déjà, eux-mêmes à base d'IA, d'éliminer ces barrières. Leur intégration n'est qu'une question de temps.