Y'a un chiffre que les finances voient chaque mois. Dix-neuf piastres par licence, fois combien de développeurs on a, fois combien d'outils on a dans la pile. Copilot. Cursor. Kiro. Peut-être encore Tabnine sur quelques machines. La facture est propre, concrète, compréhensible pour n'importe qui qui a ouvert un tableur de sa vie. Ce qui n'apparaît pas sur cette facture, par contre, c'est le chiffre qui détermine vraiment si l'investissement IA rapporte quelque chose. Et ce chiffre-là, je ne l'ai jamais vu dans un seul tableau de bord.
La refonte. Plus précisément: la refonte composée par le fait que l'équipe produit maintenant des fonctionnalités deux fois plus vite sur des exigences qui sont toujours aussi floues qu'avant l'achat de la première licence. C'est ça, le coût caché. Pas compliqué comme concept. Mais après 25 ans à voir des projets logiciels d'entreprise de l'intérieur, je veux parler des mathématiques derrière ça, parce que l'écart entre "ce qu'on croit obtenir" et "ce qui se passe vraiment" a empiré de façon significative depuis que les outils de codage IA sont devenus ordinaires.
Quel est le coût caché que les calculs de ROI IA manquent?
La plupart des calculs de ROI pour les outils de codage IA mesurent une moitié de l'équation. La moitié exécution. Temps pour écrire une fonction. Volume de pull requests. Fréquence de déploiement. Ces métriques sont réelles et les outils les bougent vraiment. Pantoute de dispute là-dessus. Ce que je dis, c'est que mesurer seulement la moitié exécution, c'est comme mesurer à quelle vitesse quelqu'un conduit sans demander s'il va dans la bonne direction.
L'autre moitié de l'équation, c'est la qualité des exigences. Chaque projet a un taux de base d'échecs liés aux exigences: un certain pourcentage de stories qui vont nécessiter une refonte importante parce que la spec était fausse, les cas limites manquaient, la partie prenante a dit une chose et en voulait une autre. Personne ne suit ce chiffre explicitement, mais il est là, incrusté dans les rétros de sprint et les moments "c'est pas ce que j'avais demandé" et les demandes de changement post-lancement. Avant les outils IA, ce taux d'échec générait de la refonte à un certain rythme. Avec les outils IA, il génère de la refonte à un rythme beaucoup plus élevé. Même taux d'échec. Vélocité plus haute. Plus de code livré avant que le problème remonte à la surface.
Ce chiffre, on devrait s'y arrêter. Les développeurs se sentaient plus rapides. Les données agrégées montraient qu'ils étaient plus lents. L'écart de perception, où les ingénieurs estimaient être 20% plus productifs alors que les mesures réelles montraient 19% de recul, c'est pas un hasard. C'est une caractéristique structurelle de ce qui arrive quand on optimise une partie d'un système qui dépend de tout le pipeline. Le goulot n'a pas disparu. Il s'est déplacé.
Comment la vélocité IA devient-elle un multiplicateur de dette d'exigences?
La version la plus simple des maths. Disons que l'équipe livre une fonctionnalité par semaine. De ces fonctionnalités, 20%, soit une sur cinq, finit par nécessiter une refonte importante parce que les exigences étaient désaligniées ou incomplètes. Donc une fois toutes les cinq semaines, on mange un sprint de refonte. C'est la ligne de base. Maintenant, on adopte Copilot et le débit double. On livre deux fonctionnalités par semaine. Le taux de refonte est inchangé, parce que Copilot n'a pas d'opinion sur la qualité des exigences. Donc on a maintenant un sprint de refonte toutes les deux semaines et demie au lieu de cinq. Deux fois plus de refonte dans le même trimestre.
En fait, c'est pire que ça. Quand le débit double, la quantité de code livré avant que quelqu'un attrape un échec d'exigences double aussi. Plus de code à défaire. Plus de tests à refaire. Plus de points d'intégration à revisiter. La refonte elle-même devient plus chère avant même de tenir compte de l'augmentation de fréquence.
Voilà ce que je veux dire par multiplicateur de vélocité. Les outils IA ne changent pas la probabilité de tomber sur un échec d'exigences. Ils changent la vitesse à laquelle on y arrive et ce qu'on a construit quand on débarque. Le coût caché, c'est pas la licence mensuelle. C'est la licence mensuelle fois le multiple que la vélocité IA applique à la dette d'exigences existante.
"Les PRs assistés par IA ont 1,7 fois plus de problèmes que les PRs écrits par des humains, les incidents par pull request ont bondi de 23,5%, et les temps de révision ont augmenté de 91% d'une année à l'autre."
LinearB 2026 Software Engineering Benchmarks Report
Ce 91% sur les temps de révision, ça dit quelque chose. Quand le code est généré plus vite mais a besoin de plus de scrutin, on a transféré l'effort de l'écriture vers la révision. L'effort total ne diminue pas. Il se déplace, et il se déplace vers une partie du processus qui n'apparaît pas dans le narratif "l'IA nous rend plus rapides" qui sert à justifier les dépenses.
Que disent les données sur les outils IA et les résultats de livraison?
GitClear. Des vraies données, pas des sondages. Dans leur analyse 2025 de 211 millions de lignes modifiées dans des dépôts de Google, Microsoft, Meta et des entreprises, ils ont trouvé que le churn de code (nouveau code révisé dans les deux semaines suivant son premier commit) a presque doublé, passant de 3,1% en 2020 à 5,7% en 2024. Le code copié-collé a augmenté de 8x dans la même période. Et la part des lignes "déplacées", c'est-à-dire le refactoring, ce qui garde une base de code cohérente dans le temps, est passée de 24,1% à 9,5%. Moins de refactoring. Plus de duplication. Plus de churn. Pantoute les signatures d'un système qui s'améliore sur l'alignement des exigences.
Puis, l'Étude Sonar 2026 sur l'état du code a révélé que 38% des développeurs rapportent que la révision du code IA demand plus d'effort que la révision du code humain. Vingt à quarante pourcent de la capacité de sprint était consommée par de la refonte dans les équipes affectées. Et la partie qui devrait trouble tout leader en ingénierie: le temps passé sur les tâches ingrates était à peu près identique (23 à 25%) pour les développeurs qui utilisent les outils IA fréquemment et ceux qui les utilisent moins souvent. Les outils n'ont pas réduit la corvette. Ils l'ont déplacée.
Sur le terrain: quand la promesse de vélocité rencontre la réalité
Quand Augment Code a analysé les tendances dans les équipes d'ingénierie qui ont adopté les outils de codage IA massivement en 2024 et 2025, ils ont documenté ce qu'ils ont appelé la "dette de spécification composée": les équipes qui ont adopté les outils sans cadres de gouvernance ont vu une augmentation de 4x de la duplication de code en 18 mois, et la couverture de tests dans les projets assistés par IA était en moyenne de 12%, contre 68% dans les bases de code développées traditionnellement. Le coût de maintenance de ce code a explosé de 300% dans la même fenêtre.
Le pattern était constant d'une industrie à l'autre: gains de vélocité initiaux au premier trimestre, suivis d'un point d'inflexion vers la barre des 25 000 lignes où le coût d'ajout de nouvelles fonctionnalités commençait à dépasser le coût du développement manuel. Pas parce que les outils ont arrêté de fonctionner. Mais parce que les exigences qu'ils exécutaient n'ont jamais été validées. Source: Augment Code: AI Technical Debt Compounds
C'est le pattern que j'observe dans les équipes enterprise depuis deux ans. Les outils fonctionnent exactement comme annoncé. Le problème, c'est que l'annonce couvre seulement la moitié du système.
L'argument économique central
Les outils de codage IA mesurent leur valeur au niveau de l'exécution: code plus rapide, plus de PRs, plus de déploiements. Ces métriques sont réelles. Mais incomplètes.
La couche des exigences est en amont. Elle détermine ce qui se construit. Quand cette couche a des lacunes, des ambiguités, ou des hypothèses non validées, ces problèmes se propagent en aval à chaque sprint. La vélocité IA ne filtre pas ces problèmes. Elle les accélère.
Le vrai coût de votre pile de codage IA, c'est: le coût d'abonnement, plus (taux d'échec des exigences x multiplicateur de vélocité x coût par sprint de refonte). La plupart des équipes ne suivent que le premier chiffre. Le deuxième est presque toujours plus grand.
Comment mesurer les deux faces de l'équation IA?
Voilà ce que j'ai dit à des leaders en ingénierie dans peut-être une quarantaine de conversations l'année passée: vos outils IA ne sont pas le problème. Le problème, c'est que vous mesurez une face d'une équation à deux faces et vous appelez ça un calcul de ROI. Des maths incomplets. Ça ressemble à de la comptabilité. C'en est pas.
Le côté visible, c'est ce que la plupart des équipes suivent déjà: coût d'abonnement par licence par mois, volume de pull requests, fréquence de déploiement, peut-être le cycle time du commit à la production. Parfait. Continuez. Maintenant ajoutez l'autre côté, que la plupart des équipes ne suivent pas du tout. Combien de stories reviennent du QA ou de la staging pour des raisons d'exigences, pas de qualité de code? Quel pourcentage des demandes de changement post-lancement remonte à des specs floues au départ? Combien de sprint reviews se terminent avec quelqu'un qui dit "c'est pas tout à fait ce que je voulais" et génère du travail supplémentaire?
Ces chiffres existent dans votre outil de gestion de projets en ce moment même, sous forme de tickets réouverts et d'états "refusé" et de fils de commentaires que personne n'a regardés depuis des mois. Extrayez-les. Le ratio de ces chiffres par rapport au total du sprint, c'est votre taux d'échec des exigences. Multipliez-le par le multiple de vélocité que vos outils IA ont créé. Ce produit, c'est votre exposition composée à la refonte, et c'est le chiffre qui détermine si votre investissement IA est vraiment rentable ou si vous allez juste plus vite vers le même mur.
Y'a une version de cette histoire où les outils IA sont neutres sur le problème des exigences, voire légèrement utiles, parce que des boucles de rétroaction plus rapides donnent plus de chances d'attraper les désalignements avant qu'ils se composent trop loin. On voit cette version fonctionner pour des équipes qui ont déjà de vraiment bonnes pratiques d'exigences en place. Pour elles, la vélocité IA est additive. Pour tout le monde d'autre, et d'après ce que j'observe, "tout le monde d'autre" représente peut-être quatre-vingts ou quatre-vingt-dix pourcent des équipes, les outils accélèrent l'arrivée au problème sans rien faire pour l'empêcher.
Le correctif, c'est pas d'arrêter d'utiliser les outils. Le correctif, c'est de traiter la qualité des exigences comme une entrée de première classe dans le calcul de ROI, au même titre que le nombre de licences et la fréquence de déploiement. Mesurez votre taux d'échec des exigences. Suivez quelle fraction de la refonte remonte à de l'ambiguité en amont. Si ce chiffre monte après l'adoption de l'IA, vous savez exactement ce qui se passe: le multiplicateur de vélocité joue contre vous.
La facture est visible. Le coût composé ne l'est pas. Cette asymétrie, c'est ce qui rend le problème persistant. Les finances voient un chiffre. Le leadership en ingénierie en voit un autre. Le vrai chiffre, c'est le produit des deux, et personne ne fait ce calcul-là.
Questions fréquentes sur les coûts cachés du codage IA
Quel est le coût caché que la plupart des calculs de ROI IA manquent?
L'abonnement à des outils comme Copilot apparaît sur une facture. Ce qui n'apparaît pas, c'est le coût de refonte que ces outils composent lorsqu'ils accélèrent le développement sur des exigences ambigües ou incomplètes. La vélocité IA ne réduit pas le taux d'échecs liés aux exigences. Elle fait juste arriver plus vite à ces échecs, avec plus de code livré quand le problème se manifeste.
Pourquoi la vitesse de codage IA rend les problèmes d'exigences plus coûteux?
Quand une équipe code plus vite, elle livre plus de lignes avant que quelqu'un ne détecte un désalignement d'exigences. Plus une erreur d'exigence avance dans le développement, plus elle coûte cher à corriger: plus de code à réécrire, plus de tests à refaire, plus d'intégrations à démêler. Les outils IA accélèrent l'arrivée au point d'échec sans rien changer à la qualité des exigences de départ.
Que dit le rapport LinearB 2026 sur la livraison avec les outils IA?
Le rapport LinearB 2026, issu de 8,1 millions de pull requests sur 4 800 équipes dans 42 pays, a conclu que la livraison de bout en bout est 19% plus lente quand on tient compte du flux complet, même si le volume de PRs individuels a augmenté. Les incidents par pull request ont bondi de 23,5% et les temps de révision ont augmenté de 91%. Les développeurs se sentaient plus rapides. Les données montraient le contraire.
C'est quoi concrètement le multiplicateur de vélocité sur la dette d'exigences?
Chaque équipe a un taux de base d'échecs liés aux exigences: un pourcentage de stories qui auront besoin de refonte importante parce que la spec était fausse ou incomplète. Les outils IA ne changent pas ce taux. Ils changent le volume de code produit par unité de temps. Donc si 20% des exigences mènent à de la refonte et que l'équipe livre deux fois plus vite, on atteint ces moments de refonte deux fois plus vite, avec deux fois plus de code déjà écrit. C'est le multiplicateur de vélocité.
Comment mesurer si votre investissement en outils de codage IA rapporte vraiment?
Suivez les deux faces. Le côté visible: coûts d'abonnement, volume de PRs, fréquence de déploiement. Le côté caché: taux de refontes de sprint, stories qui reviennent du QA pour des raisons d'exigences, demandes de changement post-lancement qui remontent à des specs floues. Si votre volume de PRs a doublé mais que votre taux de refonte est resté stable, vous n'êtes pas en avance. Vous payez plus sur le côté caché.
Quelle est la différence entre cet article et celui sur la gueule de bois Copilot?
L'article sur la gueule de bois Copilot établissait la première: les outils de codage IA aggravent les problèmes d'exigences. Cet article va plus loin sur le mécanisme économique. Le multiplicateur de vélocité explique que la dette d'exigences fois la vélocité égale le vrai coût composé qui n'apparaît sur aucune facture ni aucun tableau de bord.
