En mai 2026, une étude du National Bureau of Economic Research (NBER) menée auprès de plus de 100 000 développeurs expose les métriques les plus net à ce jour sur l'IA et les logiciels: grâce aux agents d'IA, l'activité de codage a bondi jusqu'à 180 %, tandis que les mises en production, elles, n'ont progressé que de 30 %. Le code est désormais écrit par d’avantage de personnes, plus vite que jamais, y compris par des personnes qui n'auraient pas su l'écrire il y a deux ans. Ce qui n'a en revanche pas accéléré, c'est tout ce qui entoure le code : la revue, l'assurance qualité, la synchronisation, la responsabilité.
L'IA a changé le coût de l'écriture du logiciel. Elle n'a pas changé le coût de sa livraison, ni celui de sa possession. Et elle n'a pas changé le niveau d'exigence avec lequel un régulateur examine vos solutions de finance durable.
Si vous ne devez lire qu'une seule section de cet article, alors lisez celle-ci.
Le tableau ci-dessous résume l'ensemble des besoins à couvrir pour qu'un logiciel destiné aux institutions financières soit un succès. Le vibe coding donne l'impression que les deux premières lignes de ce tableau sont gratuites. Pour un expert métier (SME) qui construit directement, la première peut effectivement l'être. Mais dès lors que vous internalisez un développement, c'est sur les dix lignes que vous vous engagez et dont vous assumez la responsabilité. Une responsabilité qu'un Responsable d’Investissement Durable ne peut, en général, pas endosser.
Une enquête Team8 menée en 2026 révèle que 81 % des banques nord-américaines ont revu leur position sur le build-versus-buy à cause de l'IA. Et selon l'enquête menée par Mercer en février 2026 auprès de 131 sociétés de gestion, 91 % prévoient d'accroître leur usage de l'IA cette année. Cette tendance s'appuie aussi sur une véritable expérience de prototypage : les recherches de Stanford chiffrent les gains de productivité liés à l'IA à 35-40 % sur des tâches simples développées « from scratch ». Sur du code legacy complexe, en revanche, le gain tombe à 10 % ou moins. Or un logiciel dédié à la finance durable relève le plus souvent de cette base legacy déjà établie.
Nous en avons fait l'expérience chez WeeFin en mettant des outils de développement par IA entre les mains de toute l'entreprise. Résultat : L'activité de codage a augmenté exactement comme le décrivent les données du NBER, la majeure partie venant de contributeurs qui n'auraient pas pu écrire ce code auparavant. Des chefs de produit livrent des maquettes fonctionnelles au lieu de spécifications, des développeurs front-end passent au back-end (et inversement), les équipes commerciales et clients construisent leurs propres assistants et automatisations. Certains de ces développements auraient consommé un quart de la roadmap il y a cinq ans, et il n’est pas question de revenir en arrière. Nous avons aussi constaté qu'il est plus facile de construire à partir de zéro que de s'appuyer sur un système déjà complexe : un point souvent négligé au démarrage d'un projet et qui peut s'avérer difficile même pour les outils d'IA.
Mais les limites sont arrivées comme prévu : les premiers outils ont commencé à tomber en panne de façons que leurs créateurs ne savaient pas diagnostiquer. Des prototypes sont restés en place bien après leur usage initial, chaque outil un peu important a fini par atterrir sur le bureau de l'ingénierie pour être révisé, certains éléments se sont cassés sans prévenir dès que les modèles de données changeaient, et personne n'avait posé les questions de sécurité au moment de la construction. Nous avons identifié ces problèmes tôt et avons pu les résoudre. Ne pas les résoudre revient à laisser un risque non maîtrisé. Mais, comme prévu, la solution a un coût, et la pression retombe finalement sur les experts de l'équipe de développement.
À long terme, des problèmes plus importants encore finissent par apparaître. Cela renvoie à un principe fondamental du développement logiciel : l'intégrité du système, notion popularisée par Brooks (1975) dans « The Mythical Man-Month. Quelques développeurs travaillant sur un système cohérent peuvent créer plus de valeur qu'une équipe pléthorique. C'est précisément là que les solutions vibe codées échouent aujourd'hui : chaque brique logicielle est solide prise isolément, mais ne tient pas compte du reste de l'architecture, contrairement à ce que ferait un développeur ou un architecte. Dans des domaines complexes comme la finance durable, cela crée une limitation considérable et un risque à moyen terme difficilement maîtrisable.
La maintenance représente 60 à 80 % du coût du cycle de vie d'un système (analyses IEEE ; règle des 60/60 de Robert Glass), et environ les trois quarts du coût total de possession sont générés après le lancement. Les banques consacrent jusqu'à 70 % de leur budget informatique à la seule maintenance des systèmes legacy (McKinsey, 2024).
Lorsque les institutions financières construisent, elles dépassent leur budget de 45 % en moyenne, tout en livrant 56 % de valeur en moins que promis (McKinsey-Oxford, plus de 5 400 projets). Le code écrit par IA, lui, coûte plus cher à posséder, pas moins : le code dupliqué a augmenté de 81 % depuis 2023 tandis que le refactoring a chuté de 70 % (GitClear), et 25 à 45 % du code généré par IA introduit des vulnérabilités du Top 10 OWASP (Veracode et AppSecSanta). Gartner prévoit d'ailleurs que 40 % des projets de développement augmenté par IA seront abandonnés d'ici 2027.
Et notre propre organisation autour du produit le confirme. Sur un produit complexe, le trajet entre l'idée et la fonctionnalité livrée est dominé par la spécification, la priorisation, les tests et la validation : écrire le code a toujours été la dernière étape, celle que l'IA a compressée, en laissant le reste largement inchangé. Nous expérimentons beaucoup avec différents modèles, et ce que nous observons est clair : un SME peut aujourd'hui construire un outil vibe codé à partir de zéro sans écrire de spécifications, tout simplement parce qu'il sait ce qui est requis. Mais dès qu'il s'agit de rendre cet outil prêt pour le marché, en particulier sur des besoins riches en données, une équipe de développement devient nécessaire. Car si la partie « écriture du code » de ce processus d'industrialisation va aujourd'hui plus vite, elle nécessite toujours une revue, une assurance qualité et l'ensemble des processus de suivi indispensables pour garantir une qualité à la hauteur des exigences du secteur financier.
Dans l'enquête 2026 de Retool menée auprès de 307 dirigeants technologiques, 44 % n'avaient aucune responsabilité clairement établie pour les incidents causés par des outils construits par IA, et seuls 8 % qualifiaient de solide la gouvernance de leurs outils internes.
Ce n'est pas la première fois que la finance vit ce genre d'épisode.
Plus de 90 % des feuilles de calcul contiennent des erreurs. Certains se souviennent peut-être encore du modèle de VaR censé détecter la perte de 6,2 milliards de dollars de JPMorgan, la fameuse « baleine de Londres ». Il tournait sur un fichier Excel copié-collé, dont une formule divisait par deux la volatilité rapportée (selon le rapport du groupe de travail interne mis en place par la banque en 2013), ce qui a conduit à une mauvaise appréciation du risque sous-jacent. Les suites de l'ère IA se manifestent déjà : un agent IA a supprimé une base de données de production malgré un gel des développements (Replit, 2025) ; 38 millions d'enregistrements ont été exposés via des permissions par défaut d'outils low-code ; et les violations liées à l'IA non déclarée (« shadow AI ») coûtent en moyenne 670 000 $ de plus (IBM, 2025).
Dans la finance, c'est le régulateur qui tranche la question de la responsabilité. Les normes techniques de DORA imposent des obligations de développement, de test et de revue du code source aux systèmes « développés ou gérés par des utilisateurs en dehors de la fonction informatique ». L'application développée par IA d'un expert métier entre donc explicitement dans ce champ et doit, par obligation réglementaire, suivre les principes de gouvernance requis. Un effet de volume mérite d'ailleurs plus d'attention qu'il n'en reçoit habituellement : chaque outil interne ajoute un actif TIC à identifier, classifier et documenter, des éléments de preuve à produire, et une revue annuelle à mener. En multipliant le nombre d'outils internes, l'IA multiplie donc le périmètre DORA avec eux : ces outils sont bon marché à construire, coûteux à maintenir. Au Royaume-Uni, la norme SS1/23 de la PRA couvre tous les modèles, « qu'ils soient développés en interne ou en externe », avec un responsable désigné personnellement redevable. Acheter ne transfère pas cette responsabilité, mais transfère la charge de la preuve, amortie sur des centaines de clients. Construire, à l'inverse, signifie que l'ensemble de la pile technique retombe sur vous, outil par outil, indéfiniment.
À cette réglementation s'ajoute un point tout aussi important : la confiance. Les régulateurs ne sont pas en mesure de revoir chaque solution construite en interne, mais ils bâtissent une relation de confiance avec certains fournisseurs au fil du temps. Dans un domaine hautement réglementé comme la finance durable, où la réglementation change très fréquemment, cette confiance devient un élément déterminant de la décision entre construire sa propre solution ou externaliser. Et comme les réglementations de ce secteur sont souvent d'origine politique et ambiguës, c'est l'expertise humaine qui permet de pondérer les critères de décision nécessaires.
Chez WeeFin, nous avons décidé que tout outil initié par un SME doit répondre au même standard de qualité : chaque outil est transféré vers une équipe capable d'en comprendre le code sous-jacent. Sans ce transfert de propriété, les modèles et outils développés ne résisteraient pas à un audit au titre des règles de la PRA ou de DORA.
Tout ceci nous ramène à la fameuse question : faut-il construire sa propre solution ou externaliser ?
Dans les domaines les moins riches en données et où votre nouveau développement est complémentaire, démarrer avec une solution vibe codée fonctionne bien. Cela aide à construire une compréhension solide de ce qui est réellement nécessaire et de ce qui ne l'est pas. Mais cela crée aussi le risque de créer des fonctionnalités et des solutions qui, dans la réalité, ne fonctionneront jamais. Pour des domaines complexes, fortement réglementés et dépendants de la donnée comme la finance durable, vous risquez de vous retrouver dans un projet d'autoconstruction qui pourrait facilement durer plusieurs années, pendant que le régulateur pourrait douter du résultat final. Être spécialisé en finance durable nous donne une visibilité sur ce qui fonctionne d'un point de vue technique et sur la manière d'éviter des erreurs coûteuses et chronophages.
Ainsi, l'IA ne change pas la décision de fond : construisez là où vos données et vos flux de travail propriétaires se combinent en un avantage que personne d'autre ne peut reproduire. Achetez là où le fournisseur profite d'une échelle qu'aucune entreprise ne peut atteindre seule : plus de transactions, plus de cas limites, plus de changements réglementaires suivis au fil du temps. Et n'achetez que si vous pouvez ensuite construire, en interne, sur ce que vous avez acheté.
Chez WeeFin, nos équipes construisent librement au niveau du prototype, l'ingénierie possède tout ce qui touche aux données clients ou à un processus réglementé, et nous achetons ce qui n'est pas notre cœur d'excellence. Avant d'écrire le moindre prompt, posez-vous six questions :
Une correction honnête à apporter au discours à la mode, tirée de notre propre expérience : l'IA réduit véritablement le coût d'écriture du code, et ce pour chaque version, pas seulement la première. Ce qu'elle ne crée pas, c'est la continuité.
Les produits sont faits de cohérence : un seul modèle de données, une seule roadmap, un seul responsable par décision. L'IA produit de la productivité tout en multipliant les initiatives qui se disputent cette cohérence, et le poste de coût véritablement onéreux et jamais mesuré n'a jamais été le code, mais la réactivation de l'organisation à chaque changement. Revue, AQ, formation, documentation, support, preuves réglementaires : ce coût d'absorption baisse à peine avec l'IA, et il croît avec le nombre de changements. Livrez deux fois plus de versions, et vous le payez deux fois plus. L'écart observé par le NBER, activité de codage en hausse de 180 %, mises en production en hausse de 30 % seulement, c'est cette file d'attente d'absorption rendue visible. Un fournisseur vous facture exactement une chose : maintenir un produit cohérent afin que votre organisation n'ait à l'absorber qu'une seule fois.
Une institution financière doit aujourd'hui se poser la même question de construire ou d'acheter qu'il y a quelques années. Mais les hypothèses sous-jacentes ont changé. Cela ne signifie pas pour autant que chaque projet de construction est aujourd'hui plus facile. Au contraire, cela crée des exigences totalement différentes en matière de gouvernance et de gestion des risques, ainsi que de nouveaux défis.
L'IA a rendu chaque version moins coûteuse à écrire. Elle a fait de la cohérence : un seul produit, un seul responsable, une seule roadmap ; la chose la plus coûteuse en matière de logiciel. C'est ce qu'une licence achète réellement.
.webp)
.webp)