Dette technique et code IA : ce que montrent les données

La dette technique est le surcroît de travail qu'une solution rapide impose aux modifications futures. Dans le développement assisté par IA, elle croît de façon mesurable plus vite : selon l'analyse de GitClear, la part de blocs de code dupliqués est passée d'une valeur d'indice de 40,3 en 2023 à 73,0 en 2026, tandis que la part de code déplacé, la meilleure approximation disponible d'un véritable nettoyage, est tombée de 21 % (2022) à 3,8 % (2026).

Qu'est-ce que la dette technique ?

La notion vient de Ward Cunningham et décrit un arbitrage délibéré : on livre plus vite en choisissant une solution peu propre, et l'on en paie les intérêts sous forme de surcroît de travail à chaque modification future. Dans l'image d'origine, le mot décisif est délibéré : une dette que l'on contracte, on la connaît.

C'est précisément ce qui a changé. Lorsque du code naît sans que personne l'ait lu, la dette n'est pas contractée, elle est ignorée. Elle n'apparaît que lorsque quelqu'un veut modifier quelque chose.

À quelle vitesse la dette technique croît-elle avec le code IA ?

Plus vite qu'auparavant, et les preuves sont désormais solides. Pour son rapport « The Maintainability Gap », GitClear exploite des centaines de millions de modifications de code. Trois indicateurs sont pertinents pour cette question.

Ces deux mouvements vont ensemble. Pour un modèle de langage, dupliquer est la voie la plus naturelle : il voit l'extrait qu'il doit modifier, pas les trois autres endroits où le même motif existe déjà. Et le refactoring exige de comprendre l'ensemble, précisément ce qui manque quand personne n'a lu l'existant.

Pourquoi le code dupliqué coûte-t-il cher ?

Parce que chaque copie est un endroit où une correction peut être oubliée. Ce n'est pas une question de style, mais d'arithmétique.

Si un contrôle existe quatre fois au lieu d'une, une erreur doit être corrigée quatre fois. Si un endroit est oublié, il en résulte un comportement correct à trois endroits et faux à un : le type d'erreur le plus coûteux, car il n'apparaît que sous certaines conditions et n'est pas reproductible dans les tests.

S'y ajoute l'effort de recherche : qui doit modifier une règle doit d'abord découvrir combien de fois elle apparaît dans l'existant. Quand le taux de doublons augmente, cet effort grandit à chaque modification.

À quoi vois-je que mon projet a accumulé de la dette technique ?

À cinq observations du quotidien qui n'exigent aucune mesure : ce sont des signes avant-coureurs, pas des preuves, mais ils apparaissent rarement sans raison.

• Les estimations deviennent peu fiables. Si une « petite modification » prend régulièrement trois jours, ce n'est pas un problème d'estimation : personne ne sait à l'avance ce qui en dépend.
• Les corrections créent de nouvelles erreurs. Le signe classique des doublons : un endroit a été corrigé, trois ne l'ont pas été.
• On évite certains fichiers. Quand l'équipe sait quel fichier « personne ne touche », c'est une facture impayée qui porte un nom.
• Les nouveaux collègues mettent un temps inhabituel à s'intégrer. Le temps d'intégration est une bonne approximation de la lisibilité.
• Les tests sont ignorés parce qu'ils sont « de toute façon parfois rouges ». Un test peu fiable est pire que pas de test : il consomme une confiance qui fera défaut plus tard.

Ces cinq points se prêtent mieux que n'importe quel indicateur à ouvrir la discussion avec la direction, parce que tout le monde les a déjà vécus.

Comment mesurer la dette technique dans mon projet ?

Avec quatre indicateurs que l'on peut tirer du dépôt et des outils existants, sans nouveau produit.

• Part de doublons. Toute analyse statique courante la fournit. Ce qui compte n'est pas la valeur absolue, mais la tendance sur plusieurs mois.
• Fréquence de modification par rapport à la complexité. Les fichiers souvent modifiés et complexes sont vos points les plus coûteux. Les deux ensemble donnent une liste de priorités sans discussion.
• Part de lignes modifiées non testées. Pas la couverture globale, mais celle du code nouveau. Détails dans l'article sur la couverture de tests.
• Âge et nombre des dépendances. Si la liste grandit plus vite que l'équipe, plus personne ne la maîtrise.

Les autres métriques qui tiennent la route, et celles qui ne font que rassurer, sont traitées dans l'article Mesurer la qualité du code.

Que faire contre la dette technique issue du code IA ?

Trois mesures, dans cet ordre ; la troisième est la seule qui arrête l'afflux.

• Rendre visible. Part de doublons et couverture de tests du code nouveau dans le pipeline, avec historique. Ce qui n'est pas mesuré est contesté.
• Résorber de façon ciblée. Ne pas nettoyer partout, mais là où fréquence de modification et complexité coïncident. Démarche décrite dans l'article Refactoring du code généré par IA.
• Limiter l'afflux. Un seuil dans le pipeline qui rejette les nouveaux doublons et le nouveau code non testé. Sans cette étape, vous écopez face à un robinet ouvert. Voir Quality Gates dans le pipeline.

Questions fréquentes sur la dette technique

La dette technique est-elle toujours mauvaise ?

Non. Une dette contractée délibérément peut être justifiée, par exemple lorsqu'une échéance commerciale pèse plus que la solution propre. Le problème, ce sont les dettes que personne n'a contractées et qui n'apparaissent donc dans aucune planification.

Le recul du refactoring n'est-il pas simplement un artefact de mesure ?

GitClear mesure le code déplacé comme valeur approchée, pas le refactoring directement : c'est une limite réelle. Mais l'ampleur de la baisse, de 21 à 3,8 % en quatre ans, ne s'explique pas par ce seul biais, et la hausse simultanée des doublons va dans le même sens.

L'IA peut-elle aider à réduire la dette technique ?

Oui, et c'est l'un de ses usages les plus solides : trouver les doublons, appliquer les renommages de façon cohérente, compléter les tests manquants. Condition : une couverture de tests qui détecte un faux pas, sinon vous remplacez une dette visible par des erreurs invisibles.

Comment convaincre la direction de prévoir du temps pour cela ?

Avec la fréquence de modification plutôt qu'avec la part de doublons. « Ces cinq fichiers ont été modifiés 200 fois au dernier trimestre et sont les plus complexes » est un argument de coût. « La part de doublons a augmenté » est une discussion de spécialistes.

Résorber la dette ne sert pas à grand-chose tant que l'afflux reste ouvert. C'est pourquoi Code Guardian contrôle chaque modification, dès sa génération, quant à la redondance et aux doublons, avant qu'elle n'entre dans l'existant.

Sources

• GitClear, The Maintainability Gap: 2026 AI Code Quality Research : source de tous les indicateurs du tableau ci-dessus.
• Ward Cunningham, formulation d'origine de la métaphore de la dette (OOPSLA 1992).

Date : 27 juillet 2026. Analyse technique générale, pas une évaluation d'un projet concret.