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.
| Poste de dépense | Ce qu'il recouvre | Ce que montrent les données |
|---|---|---|
| 1. Cadrage | Comprendre le problème, spécifier, prioriser, aligner les parties prenantes. | Un SME qui construit directement fait l'impasse sur la spécification. Un développeur en vibe coding n'économise rien sur ce poste : les besoins doivent quand même être formalisés et partagés. |
| 2. Le développement lui-même | Temps de développement (assisté par IA ou non), outillage, et les reprises après la première version fonctionnelle. | Les grands projets IT dépassent leur budget de 45 % en moyenne (McKinsey–Oxford, plus de 5 400 projets). Les sociétés de gestion commencent à réduire leurs budgets IA, car ceux-ci explosent (Mercer). |
| 3. Vérification & QA | Revue par des ingénieurs du code généré par IA, tests, jalons de mise en production. | 45 % du code généré par IA comportent des vulnérabilités du Top 10 OWASP (Veracode) ; la revue et l'AQ restent les maillons les moins automatisés. |
| 4. Maintenance et sécurité | Correction de bugs, mises à jour de dépendances, correctifs de sécurité, supervision. | 60 à 80 % du coût du cycle de vie survient après le lancement (IEEE ; règle des 60/60 de Glass). L'IA peut réduire ce coût, mais le SME ne peut pas en assumer la responsabilité. |
| 5. Évolutions et mise à niveau | Changements réglementaires, intégrations, demandes utilisateurs. Suivre le rythme qu'un éditeur imposerait. Se prémunir contre le décrochage. | Les évolutions post-lancement coûtent en général 3 à 4 fois le développement initial. Construire dans un secteur aussi mouvant que la finance durable aggrave ce constat. |
| 6. Propriété et continuité | Un responsable désigné, de la documentation, une succession en cas de départ du bâtisseur, un plan de reprise. | (Retool) ; Gartner prévoit que 40 % des projets de développement assisté par IA seront abandonnés d'ici 2027. |
| 7. Périmètre réglementaire | Classification des actifs DORA, éléments de preuve des tests, revue de code, revues annuelles ; validation de modèle SS1/23. | S'applique à chaque outil, y compris ceux développés en dehors de la DSI (DORA RTS, art. 16(9)). |
| 8. Exposition aux incidents | Contrôle des accès, fuites de données, surprime liée aux outils non gouvernés. | Les violations de données dans le secteur financier coûtent en moyenne 5,56 M$ (IBM, 2025) ; l'IA non déclarée (« shadow AI ») ajoute 670 000 $ ; les manquements aux licences de données se terminent en audits fournisseurs et en facturations rétroactives (Bloomberg c. UBS, 2020). |
| 9. Absorption organisationnelle | Formation, support, documentation, conduite du changement à chaque livraison. | Ce coût baisse à peine avec l'IA, et peut même augmenter avec le nombre de changements livrés. Un SME qui construit pour lui-même, c'est simple. Construire un outil avec un plan de déploiement et un CSM comme partenaire de formation, c'est un tout autre métier. |
| 10. Coût d'opportunité | Ce que vos ingénieurs et experts métier n'ont pas construit pendant qu'ils possédaient cet outil. | Un phénomène courant avec le vibe coding est que tout le monde se sent habilité à construire. Mais les problèmes ne reçoivent souvent que des demi-solutions. Nous observons du temps perdu et une explosion des coûts d'opportunité. |
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.
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)