Code généré et dette technique : les chiffres et la parade

Oui, le code généré par IA produit de la dette technique mesurable, et les chiffres sont maintenant assez solides pour cesser d’en débattre. Mais le diagnostic honnête est moins confortable pour tout le monde : la dette ne vient pas de l’outil, elle vient du process qui l’entoure. Une équipe disciplinée produit du code assisté propre. Une équipe sans guardrails produit de la dette à la vitesse de l’agent, ce qui est une vitesse remarquable.

Voici ce que disent les données, puis la parade que nous installons chez nos clients en ingénierie agentique.

Ce que les études mesurent sur la dette du code généré

La référence sur le sujet reste la recherche de GitClear sur la qualité du code assisté, publiée début 2025 sur l’analyse de 211 millions de lignes de code. Trois résultats méritent d’être retenus. Les blocs de code dupliqués de cinq lignes ou plus ont été multipliés par huit au cours de 2024. La part de code déplacé, le marqueur du refactoring, est tombée d’environ 24 % des lignes modifiées en 2020 à moins de 10 % en 2024. Et pour la première fois dans leur jeu de données, le copier-coller a dépassé le refactoring.

Le tableau est cohérent avec ce que mesure Google côté delivery : le rapport DORA associe l’adoption de l’IA à un débit en hausse mais aussi à une instabilité en hausse. Plus de code, plus vite, moins consolidé.

C’est très exactement la définition de la dette technique : un gain de vitesse immédiat financé par un coût futur de maintenance. La duplication en est la forme la plus chère, parce qu’un bug copié huit fois se corrige huit fois, et se corrige sept fois en pratique.

Pourquoi la dette vient du process, pas de l’outil

Un agent optimise ce qu’on lui demande : que ça marche, maintenant. Réutiliser une fonction existante suppose de la trouver, ce que son contexte limité rend incertain ; régénérer un bloc équivalent est toujours possible. Sans consigne contraire, il choisira la seconde option à chaque fois. Rien de moral là-dedans : il manque simplement une exigence dans la boucle.

Le second mécanisme est humain. Le refactoring a toujours été un sous-produit de l’écriture : on nettoie ce qu’on traverse. Quand on délègue l’écriture, ce nettoyage opportuniste disparaît avec elle, sauf à le réintroduire délibérément. Et la revue, saturée par le volume, glisse vers l’approbation de code plausible que personne n’a vraiment lu. La dette de code devient alors une dette de compréhension, la plus grave des deux : au moment de la panne, personne ne connaît le système.

La parade : guardrails, revue, budget de refactoring

Le premier volet est mécanique : des guardrails en CI qui rendent la dette visible et bloquante au moment du merge. Détection de duplication et seuils de complexité dans l’analyse statique, exigence de tests sur les lignes modifiées, audit des dépendances. Une règle appliquée par le pipeline vaut cent rappels en rétrospective, et elle a une vertu supplémentaire : l’agent la lit comme une consigne et s’y conforme.

Le deuxième volet est la discipline de revue. Des diffs plafonnés en taille, un relecteur qui répond de ce qu’il approuve, et une règle simple : du code que personne ne peut expliquer ne se merge pas. La revue est devenue le goulot d’étranglement des équipes qui délèguent, et c’est pourtant elle qui décide si le volume produit devient un actif ou un passif.

Le troisième volet est budgétaire : une part explicite de chaque sprint consacrée au refactoring, précisément parce qu’il ne se produit plus tout seul. La bonne nouvelle, c’est que les agents excellent à ce travail quand on le leur confie : dédupliquer, extraire, renommer, sous la protection des tests. L’outil qui crée la dette est aussi le moins cher des outils pour la rembourser, à condition de planifier le remboursement.

Pilotez la tendance, pas l’anecdote

Suivez trois courbes par trimestre : le taux de duplication, la part de refactoring dans les commits, et le taux de défaut en production. Si les trois dérivent ensemble, votre vitesse est un emprunt. Et cet emprunt finit toujours par être chiffré, au plus tard le jour où un acquéreur regarde votre code : nous le voyons régulièrement de l’autre côté de la table, quand la dette technique entre dans une valorisation.