L'IA ne crée pas de dette technique. Elle la crée plus vite.

Aug 27, 2026 min read
L'IA ne crée pas de dette technique. Elle la crée plus vite.

Une accusation revient souvent : l’IA produirait du mauvais code. Je ne crois pas que ce soit vrai, et surtout je crois que c’est à côté du sujet.

Le code généré est souvent correct. Il compile, il passe les tests, il fait ce qu’on lui a demandé. Le problème n’est pas sa qualité prise ligne à ligne. Il est dans ce qu’il devient une fois empilé, et là, les chiffres sont sans appel.

Ce que montrent les mesures

L’analyse la plus sérieuse dont on dispose porte sur 211 millions de lignes de code et suit les mêmes indicateurs depuis 2020. Quatre résultats, à lire ensemble.

  • Le nombre de blocs contenant cinq lignes dupliquées ou plus a été multiplié par huit au cours de la seule année 2024 ;
  • la part de lignes modifiées relevant du refactoring est tombée de 25 % en 2021 à moins de 10 % en 2024 ;
  • les lignes classées comme copiées-collées sont passées de 8,3 % à 12,3 % sur la même période ;
  • et 2024 est la première année où le nombre de lignes copiées-collées a dépassé le nombre de lignes déplacées.

Ce dernier point mérite qu’on s’arrête, parce qu’il n’est pas intuitif si on ne fait pas ce métier.

Déplacer du code, c’est le signe qu’on réorganise : on extrait une fonction, on met en commun, on range. C’est le geste d’entretien par excellence. Copier-coller, c’est le signe qu’on ajoute sans ranger.

Pendant vingt ans, on a déplacé plus qu’on n’a copié. Depuis 2024, c’est l’inverse. La tendance ne s’est pas inversée depuis : la duplication de blocs a continué de grimper et se situe au plus haut niveau jamais mesuré.

Ce que ça veut dire concrètement

Une duplication, ce n’est pas grave en soi. C’est même parfois le bon choix — deux morceaux qui se ressemblent aujourd’hui n’évolueront pas forcément ensemble, et une abstraction prématurée coûte souvent plus cher que la répétition.

Ce qui est grave, c’est la duplication qu’on ne sait pas qu’on a.

Combien de fois la même fonction existe-t-elle dans votre dépôt, là, maintenant ? Personne ne peut répondre, et c’est bien le problème.

Quand vous copiez-collez vous-même un bloc, vous le savez. Vous vous en souvenez, ou au moins vous vous en méfiez. Quand un assistant vous génère pour la quatrième fois une variante d’une fonction qui existe déjà trois fois ailleurs dans le dépôt, personne ne le sait. Ni lui, qui n’a aucun souvenir des trois premières. Ni vous, qui n’avez pas lu le reste du dépôt.

Et le jour où il faut corriger le comportement, vous corrigez un exemplaire sur quatre. Les trois autres continuent tranquillement.

C’est le mécanisme exact que je décrivais dans l’article sur la dette technique : la dette qui coûte le plus cher n’est pas la plus laide, c’est la plus invisible. Sauf qu’ici, on a trouvé le moyen d’en produire beaucoup plus vite, et de la rendre encore moins visible.

La partie qui manque, c’est l’entretien

L’effondrement du refactoring est le chiffre qui m’inquiète le plus, davantage que la duplication.

Passer de 25 % à moins de 10 % de lignes consacrées à réorganiser, ça veut dire qu’on a arrêté de ranger. On ajoute, on ajoute, et plus personne ne repasse derrière.

Pourquoi est-ce qu’on a arrêté ? Franchement, je ne pense pas que ce soit de la paresse. Je vois trois raisons, et aucune n’est un défaut de caractère.

D’abord, produire est devenu beaucoup moins cher que comprendre. Face à un module tordu, vous avez le choix entre passer une demi-journée à le lire pour l’améliorer, ou obtenir en quatre minutes quelque chose qui marche à côté. Le calcul se fait tout seul, et il se fait dans le mauvais sens.

Ensuite, on refactorise ce qu’on connaît. On ne réorganise pas du code qu’on n’a jamais lu attentivement. Or c’est de plus en plus le cas, pour les raisons que j’exposais dans l’article sur la revue.

Enfin, le refactoring n’a jamais été récompensé, et l’IA a rendu ce déséquilibre insupportable. Une fonctionnalité se démontre, un rangement ne se démontre pas. Quand livrer devenait cher, l’écart restait tolérable. Maintenant que livrer est presque gratuit, l’entretien ne pèse plus rien face à la production.

Ce n’est pas la faute de l’outil

Je veux être clair, parce que ce genre d’article dérape vite vers le procès en technophobie.

Rien de tout ça n’est causé par l’IA au sens strict. La duplication et l’absence d’entretien existaient largement avant, et j’ai vu des dépôts catastrophiques écrits entièrement à la main par des gens très compétents mais très pressés.

Ce que fait l’IA, c’est lever la seule limite qui restait : le temps qu’il fallait pour produire du code. Cette lenteur était pénible, et elle jouait discrètement un rôle de garde-fou — écrire pour la quatrième fois la même chose finissait par agacer suffisamment pour qu’on range.

C’est exactement ce que j’écrivais à propos du cloud, il y a trois ans, puis à propos de l’infrastructure as code : on n’a pas ajouté un problème, on a retiré un frein. Ce qui prenait trois semaines à naître prend maintenant trois ans à mourir, et là c’est pareil en accéléré.

Alors on fait quoi

Trois choses, et aucune n’est spectaculaire.

Mesurez la duplication, et affichez le chiffre. C’est probablement déjà dans votre analyse statique et personne ne le regarde. Mettez-le sur le tableau de bord de l’équipe, au même endroit que la couverture de tests. Ce qu’on ne mesure pas ne se corrige jamais, c’est le refrain de tout ce que j’écris depuis six mois et je ne vais pas m’excuser de le répéter.

Cherchez avant de générer. C’est un réflexe à réapprendre, et honnêtement je l’ai perdu moi aussi : avant de demander une fonction, chercher si elle existe. Dans un dépôt bien indexé, c’est plus rapide que de la faire écrire. Et c’est le seul geste qui casse la boucle de duplication à la source.

Réservez un budget d’entretien, et défendez-le. Un pourcentage du temps, inscrit dans le même tableau que les fonctionnalités, pas dans un chantier annexe qui sera arbitré en dernier. Si vous ne le réservez pas, il ne se prendra pas — et maintenant que la production est presque gratuite, il ne se prendra vraiment plus jamais.

En conclusion

L’IA n’a pas dégradé la qualité du code. Elle a supprimé le coût qui nous forçait à nous en occuper.

Ce qui reste, c’est un choix que les équipes doivent faire consciemment, parce qu’il ne se fera plus tout seul : est-ce qu’on continue d’entretenir ce qu’on écrit, maintenant que plus rien ne nous y oblige ?

Et vous, vous l’avez prise, cette décision, ou elle s’est prise toute seule ?

La réponse par défaut est non. Elle se lit dans les chiffres, et elle se lira dans vos incidents dans deux ans.

On n'a jamais eu autant de code, et jamais aussi peu de gens capables de dire pourquoi il est là.

Sources

-|