Depuis que des assistants et des agents IA codent aux côtés des équipes Produit et Tech, celles-ci produisent bien plus de code qu'avant. Mais une partie de ce code part en production sans que personne l'ait vraiment compris, et laisse derrière lui une dette d'un genre nouveau : la dette technique IA. Le rapport DORA 2024 de Google associe déjà l'adoption de l'IA à des livraisons moins stables. Décryptage d'une dette qui s'accumule en silence, et que les organisations ont tout intérêt à garder sous contrôle.
Quelque part dans votre backlog, il y a sûrement un ticket « refacto » qui attend son tour depuis plusieurs sprints (et qui l'attendra sans doute encore un peu). C'est la dette technique telle qu'on la connaît : on la voit très bien, et on la repousse quand même. Le code généré par l'IA en fabrique une autre, plus discrète, qui ne laisse en général aucun ticket derrière elle. Elle ne se présente pas tout à fait pareil selon qu'on part de zéro ou d'un code existant (on a détaillé cet écart en comparant greenfield ou brownfield avec l'IA), mais le mécanisme de fond reste le même.
Sommaire
- Qu'est-ce que la dette technique ?
- Qu'est-ce que la dette technique IA ?
- Pourquoi le code généré par l'IA crée-t-il de la dette technique ?
- L'IA peut-elle aussi rembourser la dette technique ?
- Comment gérer la dette technique quand des agents écrivent le code ?
- Le Product Manager doit-il se préoccuper de la dette technique IA ?
- Qui paie les intérêts, au final ?
- FAQ
Qu'est-ce que la dette technique ?
La dette technique est le coût futur d'un raccourci pris aujourd'hui dans un logiciel, du code écrit trop vite à l'architecture provisoire qui finit par durer. Comme un emprunt, elle a un capital (ce qu'il faudra reprendre un jour) et des intérêts (le temps perdu à chaque évolution tant qu'on ne l'a pas fait). Contractée en connaissance de cause, elle peut même être un très bon calcul.
On doit l'expression à Ward Cunningham, le développeur qui a inventé le wiki et signé, quelques années plus tard, le Manifeste agile. En 1992, il explique que livrer du code pas tout à fait abouti revient à emprunter : un peu de dette fait gagner du temps, à condition de rembourser vite en reprenant le code. Le problème vient quand on laisse courir, puisque chaque minute passée à bricoler autour d'un code bancal compte alors comme un intérêt.
L'image a d'autant mieux pris qu'elle parle à ceux qui ne codent pas, un atout que Martin Fowler, l'auteur de Refactoring, met en avant. Vous avez peut-être déjà tenté de défendre « une refonte du module de paiement » devant un comité qui regardait sa montre… Présenté comme « on paie des intérêts sur ce module à chaque sprint », le même sujet passe nettement mieux.
Les 4 types de dette technique : le quadrant de Fowler
Fowler classe la dette dans un quadrant de la dette technique à partir de deux questions : l'équipe savait-elle qu'elle s'endettait, et ce choix était-il réfléchi ? Chacune des quatre cases a sa phrase type, que la plupart des équipes ont déjà entendue.
| Imprudente | Prudente | |
|---|---|---|
| Délibérée | « On n'a pas le temps de faire propre. » | « On livre maintenant, et on assumera la reprise. » |
| Involontaire | « Une architecture en couches, c'est quoi ? » | « Maintenant, on sait comment on aurait dû faire. » |
La dette délibérée et prudente est celle qu'on prend en connaissance de cause, en mettant en balance une sortie plus rapide et le coût de la reprise. Fowler ajoute qu'une dette qui dort dans un coin du code que personne ne touche ne vaut pas forcément la peine d'être remboursée, puisque ses intérêts sont quasi nuls. La dette prudente et involontaire est la plus frustrante : l'équipe la découvre au moment où elle comprend enfin comment le système aurait dû être conçu.
Causes et symptômes de la dette technique
La pression des délais en est la cause la plus courante. Un module peut aussi devenir une dette simplement parce que la seule personne qui le comprenait est partie. On la repère surtout quand chaque évolution demande un peu plus de temps que la précédente, au point que certains modules finissent contournés par tout le monde.
À ne pas confondre avec la dette produit, que notre Dico du Produit décrit comme les conséquences, pour un produit, de l'absence d'une vraie équipe Produit : elle porte sur les choix faits sur le produit, et non sur son code.
Qu'est-ce que la dette technique IA ?
La dette technique IA, c'est la dette créée par du code qu'une IA, assistant de code ou agent, a généré et que l'équipe a intégré sans en maîtriser la structure ou le fonctionnement. Le mécanisme est celui décrit par Cunningham, avec deux différences : la dette s'accumule beaucoup plus vite, et l'équipe a plus de mal à la repérer.
L'expression sème d'ailleurs un peu la confusion, parce qu'on l'emploie dans deux autres sens. Le premier désigne la dette des systèmes d'IA eux-mêmes. En 2015, une équipe de chercheurs de Google montrait dans un article resté célèbre (Hidden Technical Debt in Machine Learning Systems) que le code du modèle ne pèse pas grand-chose dans un système de machine learning, et que la dette s'accumule surtout dans tout ce qui l'entoure, les données et les pipelines en tête. Ce sens concerne surtout les équipes qui conçoivent des produits d'IA. Le second désigne l'IA utilisée pour rembourser la dette, et on y revient plus bas. Ici, on s'intéresse d'abord à la dette que les agents créent en écrivant du code, parce qu'elle touche toutes les équipes qui les utilisent.
| Dette technique classique | Dette technique IA | |
|---|---|---|
| D'où elle vient | Un raccourci pris par l'équipe, souvent sous la pression des délais | Du code généré plus vite qu'il n'est relu et compris |
| Comment elle se voit | Assez vite : builds lents, modules qu'on évite | Mal : le code a l'air propre et les tests passent |
| À quelle vitesse elle grossit | Au rythme où l'équipe écrit | Au rythme où les agents produisent |
| Qui sait qu'elle existe | Ceux qui ont pris le raccourci, en général | Parfois personne, puisque personne n'a décidé de s'endetter |
La dernière ligne pose le plus de problèmes, parce que personne ne planifie le remboursement d'une dette qu'il ne sait pas avoir prise.
Pourquoi le code généré par l'IA crée-t-il de la dette technique ?
Le code généré par l'IA crée de la dette parce qu'un agent produit du code bien plus vite qu'une équipe ne peut le relire, et qu'il ajoute souvent du code neuf au lieu de réutiliser ou de restructurer l'existant. Les premières mesures montrent des bases de code qui grossissent par copier-coller, et des livraisons moins stables à mesure que l'IA s'installe.
Code généré par l'IA : plus de duplication, moins de refactoring
GitClear, qui édite des outils d'analyse du code, a étudié 211 millions de lignes modifiées entre 2020 et 2024 pour son rapport 2025 sur la qualité du code assisté par IA. Entre 2021 et 2024, la part des lignes « déplacées », qui signalent du code réorganisé et réutilisé, est passée de 25 % à moins de 10 % des lignes modifiées. Celle des lignes copiées-collées est montée de 8,3 % à 12,3 %, au point de passer devant pour la première fois en 2024.
Ces chiffres demandent un peu de recul, puisque GitClear vend des outils qui mesurent précisément ce genre de dérive. Son étude montre aussi une évolution qui coïncide avec l'arrivée des assistants de code, sans prouver que chaque bloc dupliqué sort d'une IA ni qu'il s'agit d'une erreur : une copie se justifie quand deux usages qui se ressemblent ont vocation à diverger.
Le rapport DORA 2024 de Google, qu'on peut difficilement soupçonner de vouloir freiner l'IA, va dans la même direction pour la livraison. Il estime qu'une hausse de 25 % de l'adoption de l'IA s'accompagne d'une baisse de 7,2 % de la stabilité des livraisons et de 1,5 % de leur débit, alors même que les développeurs se disent plus productifs. De quoi rire jaune : le temps gagné à l'écriture se reperd en production, ce qui ressemble beaucoup au fonctionnement d'une dette. Le rapport rappelle au passage que ces gains ne se retrouvent dans la livraison qu'avec les bons vieux fondamentaux : des petits lots et des tests solides.
Pourquoi la revue de code ne suffit plus
La revue de code repose sur une hypothèse qui ne tient plus tout à fait : celui qui a écrit le code sait où il a coupé court. Un développeur qui prend un raccourci le sait, et il laisse souvent une trace derrière lui, un ticket ou un « on reviendra dessus » glissé en daily. Un agent ne laisse rien de tel : son code a l'air propre et passe les tests. Le raccourci se cache ailleurs : une fonction réécrite alors qu'elle existait déjà trois dossiers plus loin, par exemple.
Côté relecture, vous connaissez sans doute la scène : une pull request de plusieurs centaines de lignes, approuvée d'un « LGTM » (« looks good to me ») sans avoir vraiment été lue. Les tests ne rattrapent pas forcément le coup. Quand le même agent écrit le code et les tests, les deux reposent sur sa compréhension de la demande : si elle est fausse, tout passe au vert quand même.
La dette de compréhension (comprehension debt)
Une partie de cette dette ne se trouve même pas dans le code. L'ingénieur Addy Osmani l'appelle la dette de compréhension (on parle aussi de dette cognitive) : l'écart qui se creuse entre la quantité de code d'un système et la part de ce code que quelqu'un comprend vraiment. La dette technique classique finit par se faire sentir, avec des builds qui traînent et des modules qu'on redoute de toucher. Celle-ci donne au contraire une fausse impression de confiance, puisque la couverture de tests reste au vert et que les indicateurs habituels ne la mesurent pas.
C'est la forme de dette qui nous inquiète le plus, parce qu'elle devient vite un problème d'organisation. Lors d'un incident à corriger en urgence, ou quand la personne qui avait relu un module quitte l'équipe, plus personne ne sait expliquer ce que fait le code.
L'IA peut-elle aussi rembourser la dette technique ?
Oui, en partie. Un agent sait lire du code ancien et écrire les tests qui figent son comportement, deux corvées que les équipes repoussent volontiers de sprint en sprint. Il peut aussi créer de la dette en la remboursant : sans cadre, il remplace une dette connue par une dette neuve que personne ne comprend.
Même chez les dirigeants, c'est presque du moitié-moitié. Dans une étude du cabinet HFS Research relayée par Le Monde Informatique, 55 % des 123 dirigeants interrogés, issus des 2 000 plus grandes entreprises mondiales, s'attendent à ce que l'IA allège leur dette à long terme, et 45 % à ce qu'elle l'aggrave. Ils sont 43 % à prévoir que l'IA créera sa propre dette technique. Pour l'instant, le code généré par l'IA n'arrive pourtant qu'au septième rang des causes de dette citées, derrière, entre autres, la pénurie de compétences et les architectures legacy.
Ces chiffres restent ceux d'un sondage d'opinion, financé par Unqork, un éditeur de plateforme de développement. Le Monde Informatique note que ce financement n'est probablement pas étranger au dernier conseil de l'étude.
Le remboursement par des agents marche bien quand il est cadré : on fige d'abord le comportement existant avec des tests, avant de migrer par petits morceaux. On a détaillé cette méthode dans notre article sur la façon de confier la modernisation du legacy à des agents.
Comment gérer la dette technique quand des agents écrivent le code ?
On gère la dette technique IA comme un sujet d'organisation, au même titre que la livraison : des garde-fous automatiques limitent la dette qui entre, et chaque partie du code a un responsable humain qui la comprend. Le budget de remboursement s'arbitre comme avant, sur un volume plus important.
Comment mesurer la dette technique
La duplication, le code réécrit peu après sa livraison, la taille des pull requests, le taux d'échec des mises en production ou la part du temps passée sur la maintenance se mesurent sans trop de galère. Suivre ces indicateurs avant et après l'arrivée des agents donne déjà une bonne idée de la pente.
La dette de compréhension n'apparaît dans aucun tableau de bord. Pour la repérer, on ne connaît pas mieux que de poser la question module par module : qui, dans l'équipe, saurait expliquer ce code sans le relire ? Si la réponse est « personne », la dette est là, quels que soient les indicateurs.
Bloquer la dette à l'entrée grâce au harness engineering
Le moyen le plus efficace reste d'empêcher la dette d'entrer, avec ce qu'on appelle le harness engineering : l'ensemble de ce qui entoure l'agent pour le rendre fiable. On y trouve des contrôles automatiques qui bloquent le code non conforme, et des règles d'architecture inscrites dans les fichiers que l'agent charge à chaque session. Une erreur corrigée deux fois à la main mérite de devenir une règle, sinon l'agent la refera la semaine suivante avec le même aplomb.
Écrire la spécification avant de lancer l'agent, comme le propose le spec-driven development, aide aussi : l'agent a moins d'hypothèses à inventer, et l'équipe dispose d'une intention écrite à comparer avec le code produit.
Revoir la revue de code et la Definition of Done
Relire chaque ligne produite par des agents n'est pas tenable à grande échelle, et faire semblant mène tout droit au « LGTM » sans lecture. Mieux vaut des lots plus petits, relus d'abord pour leur intention et leur architecture. La Definition of Done peut aussi gagner une condition toute simple : quelqu'un dans l'équipe sait expliquer ce qui a été livré.
Qui paie la dette technique : responsabilité et budget
Pour qu'une dette soit remboursée, il faut d'abord que quelqu'un en réponde. Chaque partie du code a donc besoin d'un responsable humain, qui la comprend, même quand ce sont des agents qui l'écrivent. Pour le budget, une part de chaque sprint réservée au remboursement tient mieux que le grand sprint de refacto qu'on promet chaque trimestre et qu'on repousse au suivant. Avec les agents, le volume de dette augmente, et l'arbitrage remonte au niveau de l'organisation, en plus du backlog de chaque équipe.
(Aider les entreprises à revoir leurs rôles et leur gouvernance pour produire avec des agents, c'est justement notre métier.)
Votre organisation est-elle prête à produire avec des agents ? Le Product Operating Model AI (POM-AI) de Thiga aide les équipes Produit et Tech à adapter leurs rôles et leur gouvernance au développement agentique. Découvrir le POM-AI.
Le Product Manager doit-il se préoccuper de la dette technique IA ?
Oui, parce que c'est sa roadmap qui paie les intérêts. Une fonctionnalité qui prend deux fois plus de temps que prévu ou un bug qui revient toujours au même endroit, c'est de la dette qui se rembourse sur le temps de l'équipe. Et l'arbitrage entre nouvelles fonctionnalités et remboursement passe, au moins en partie, par le Product Manager.
L'IA ajoute un cas que beaucoup de PM connaissent désormais : le prototype généré en quelques heures pour tester une idée, qui plaît tellement qu'on le met en production tel quel (le fameux prototype « jetable » qui fête ensuite ses deux ans). C'est une dette délibérée, et elle peut tout à fait être prudente, à condition de le savoir et de prévoir la reprise avec l'équipe avant que le prototype ne devienne le produit.
Qui paie les intérêts, au final ?
Tant que les humains écrivaient tout le code, la réponse était assez simple : l'équipe qui avait pris le raccourci payait, en sprints de plus en plus lents. Une dette contractée par des agents se voit moins vite, et c'est souvent quelqu'un d'autre qui la découvre, en production ou au départ de la personne qui comprenait le code.
Une organisation qui veut produire avec des agents sans s'endetter à son insu doit donc savoir, module par module, qui comprend le code et qui décide de le rembourser.
FAQ
La dette technique est-elle toujours une mauvaise chose ?
Non. Une dette prise en connaissance de cause, pour sortir une fonctionnalité plus tôt ou tester une idée, peut être un bon calcul. Elle devient un problème quand personne ne sait qu'elle existe ou que personne ne prévoit de la rembourser, ce qui arrive plus souvent avec du code généré par l'IA.
Quelle différence entre dette technique et code legacy ?
Le code legacy, c'est du code ancien que l'entreprise continue d'exploiter. Il porte en général beaucoup de dette technique, mais les deux notions ne se confondent pas : un code généré hier par un agent peut déjà être lourdement endetté.
Qui gère la dette technique dans une équipe Scrum ?
La dette se gère dans le backlog, comme le reste du travail. Les développeurs la repèrent, et le Product Owner arbitre sa priorité avec eux face aux nouvelles fonctionnalités. Une pratique répandue consiste à réserver une part fixe de chaque sprint à son remboursement.
Le vibe coding crée-t-il de la dette technique ?
Oui, dès que le code obtenu en décrivant simplement ce qu'on veut à une IA sort du prototype sans être relu ni compris. Pour explorer une idée, cette dette est souvent acceptable. Elle devient coûteuse quand le prototype part en production tel quel.
Quel est un exemple courant de dette technique ?
La même règle métier écrite à plusieurs endroits du code. Le jour où elle change, il suffit d'oublier un de ces endroits pour créer un bug. C'est ce type de duplication qui progresse quand des assistants de code ajoutent du code neuf au lieu de réutiliser l'existant.
Garder la dette technique sous contrôle, sprint après sprint. La formation « Améliorer son produit en continu » de Thiga Academy apprend à gérer la dette technique et à structurer une mise en production fluide. Voir la formation.
