Dev
Vibe coding en finance : produire le code est-il vraiment le principal enjeu ?
Par La rédaction, publié le 29 septembre 2026
Avec le vibe coding, quelques prompts suffisent désormais pour transformer une idée en application. De quoi donner aux banques et sociétés financières des envies de développement maison. Sauf que produire du code vite et pas cher ne signifie ni exploiter, ni sécuriser, ni maintenir un logiciel à moindre coût.
Par Guillaume Klech, CTO et cofondateur de WeeFin
Le “vibe coding” est sur toutes les lèvres : le mois dernier, Lovable – leader du marché – annonçait une levée de 400 millions de dollars, quelques mois après le rachat de Cursor par SpaceX pour 60 milliards. Avec l’IA générative, on peut désormais construire seul un outil fonctionnel en quelques jours : de quoi alimenter, chez les institutions financières, la tentation de produire ses outils en interne plutôt que de faire appel à un prestataire plus expert… Mais est-ce vraiment une solution viable ? s’interroge Guillaume Klech, CTO de WeeFin.
Une tentation légitime et des gains (en partie) réels
La tendance est assez marquée : 81 % des banques nord-américaines ont revu leur arbitrage entre développement interne et achat (« build or buy ») sous l’effet de l’IA, et 91 % des sociétés de gestion prévoient d’accroître leur usage de l’IA cette année.
Des changements de cap qui s’appuient sur des gains de productivité réels : des travaux de Stanford mettent en lumière une productivité accrue de 35 à 40 % sur des tâches dites « simples » et réalisées à partir d’une base vierge.
Sur le terrain, les entreprises aussi ouvrent ces outils à l’ensemble de leurs équipes. Une trajectoire confirmée par les chercheurs du NBER, qui voient l’activité de programmation augmenter fortement, y compris chez des profils qui n’auraient jamais écrit de code auparavant. Des projets – qui auraient mobilisé jusqu’à un quart de la feuille de route de certaines équipes il y a cinq ans – se règlent aujourd’hui en quelques jours. Un constat s’impose : il n’a jamais paru si simple et bon marché de construire des outils à partir de rien.
Le véritable coût d’un logiciel est ailleurs
Pourtant, juger le coût d’un projet sur la seule écriture du code est une erreur et reflète une méconnaissance profonde du fonctionnement des projets technologiques : sur un cycle de vie logiciel complet, la maintenance représente 60 à 80 % de la dépense totale. Le code produit avec l’aide de l’IA n’échappe pas à cette logique : 25 à 45 % du code généré par le vibe coding comporte une vulnérabilité du Top 10 OWASP.
À cela s’ajoutent des sujets de gouvernance et réglementaires, que la finance connaît bien : 44 % des responsables technologiques n’ont identifié aucun responsable par défaut en cas d’incidents liés à un outil construit avec l’IA. Ce « vide » a par le passé fait perdre 6,2 milliards de dollars à JPMorgan lors de l’affaire « London Whale », causée par un tableur dont une formule divisait par deux la volatilité déclarée…
En Europe, le règlement européen DORA impose désormais des obligations de test, de revue et de documentation à tout système « développé ou géré par des utilisateurs extérieurs à la fonction ICT », ce qui inclut les outils construits par des experts métier. Au Royaume-Uni, la norme SS1/23 de la PRA applique la même logique, avec un senior manager nommé responsable. Là où acheter n’enlève pas cette responsabilité, mais mutualise la charge entre plusieurs parties-prenantes, construire signifie la porter seul.
Autant de limites auxquelles sont confrontés les adeptes du vibe-coding. Et qui expliquent sans doute pourquoi Gartner anticipe l’abandon de 40 % des projets de développement assisté par IA d’ici 2027…
La question du « build or buy » reste intacte
Le développement en interne n’est cependant pas à condamner : il reste pertinent lorsque les données et les processus propres à un acteur financier créent un avantage que l’on trouve nulle part ailleurs. Mais l’achat garde aussi tout son sens, un fournisseur ayant été confronté à davantage de cas d’usage, suivant toutes les évolutions réglementaires, etc. là où un acteur financier ne pourra parfois pas absorber toute cette complexité.
Ce que l’IA change vraiment en réalité, c’est le coût d’écriture du code, mais pas celui de la cohérence : un modèle stable, une feuille de route long-terme et tenue dans la durée, un responsable identifié pour chacune des décisions prises. Si on multiplie les initiatives, alors on multiplie le coût lié à cette cohérence, et cela devient très difficile à maintenir financièrement.
Avant de se lancer dans un premier prompt, les acteurs financiers gagneraient à se poser six questions simples : qui porte la responsabilité produit, quels seront les postes de dépenses dans les années à venir, quel est le coût d’opportunité du projet, qui est responsable face au régulateur, ce qu’il advient du produit si son créateur démissionne, et ce que facturerait un fournisseur pour prendre en charge l’ensemble de ces points.
La question de « build or buy » ne s’est pas donc forcément simplifiée avec l’IA générative : elle s’est recentrée sur ce qui compte vraiment.
Photo : Aerps.com sur Unsplash
À LIRE AUSSI :
À LIRE AUSSI :
