Dette technique

La dette technique s’accumule chaque fois qu’on choisit la solution rapide plutôt que la solution propre : une correction bricolée, un morceau de code copié-collé, un test qu’on n’écrit pas, une brique jamais mise à jour. Sur le moment, on gagne du temps. Plus tard, on le rembourse avec des intérêts : chaque modification prend plus longtemps et casse plus souvent autre chose. La métaphore vient du développeur américain Ward Cunningham, au début des années 1990.

Une dette n’est pas forcément une faute. Prendre des raccourcis pour un prototype est raisonnable, à condition de les rembourser avant de confier l’outil à toute l’équipe.

Avec l’IA, le phénomène va plus vite. Chaque prompt ajoute du code, souvent sans remettre de l’ordre dans l’existant. Après des dizaines de demandes, l’outil peut devenir fragile et l’IA elle-même finit par s’y perdre. Trois signes doivent alerter :

• une petite demande prend de plus en plus de temps ;
• des bugs déjà corrigés reviennent ;
• chaque correction en provoque une autre ailleurs.

Le remède existe : demandez régulièrement à l’IA de faire le ménage dans le code sans changer le comportement de l’outil, puis retestez. Les développeurs appellent cela la refactorisation. Des tests automatisés rendent ce nettoyage beaucoup plus sûr et un fichier qui rappelle les règles de l’outil, comme CLAUDE.md, aide à éviter que l’IA réinvente à chaque séance ce qui existe déjà.

Exemple. Après trois mois de corrections rapides, l’outil de gestion des salons de Céline, à l’événementiel, devient difficile à modifier : chaque ajout casse autre chose, signe d’une dette technique à rembourser.