Ce qu'est la dette technique
C'est l'écart entre ce qui existe et ce qu'il faudrait pour que cela reste maintenable. Copier-coller au lieu d'écrire une fonction, le test jamais écrit, la vieille version d'une dépendance, le nom qui ne dit plus ce qu'il fait. Chaque raccourci se paie plus tard, en heures de celui qui suit.
Toute dette n'est pas mauvaise. Celle qu'on prend sciemment et qu'on note se rembourse ; celle que personne n'a notée se découvre le jour où quelque chose casse et où personne ne sait pourquoi.
Les types de dette technique
La classification la plus citée est celle de Martin Fowler, qui croise deux questions : la dette a-t-elle été prise sciemment ou sans s'en rendre compte, et était-elle prudente ou imprudente. La dette délibérée et prudente est un raccourci noté pour être remboursé ; l'involontaire et imprudente apparaît quand personne ne savait qu'on pouvait faire autrement.
Selon l'endroit où elle vit, on la voit dans le code (duplication, fonctions énormes), dans l'architecture (des parties trop dépendantes les unes des autres), dans les tests absents, les dépendances anciennes, la documentation et l'infrastructure, comme le serveur que personne ne sait remonter.
Exemples de dette technique
La même règle métier copiée à trois endroits, modifiée à deux et oubliée au troisième. Une bibliothèque avec une vulnérabilité connue qu'on ne met pas à jour parce que ça casse quelque chose. Une requête qui tourne bien avec mille lignes et prend des secondes avec un million. Un mot de passe écrit dans le code parce que c'était un test.
Et la plus chère, celle qu'on ne voit pas : un traitement qui échoue sans prévenir et laisse des données à moitié écrites. On la réduit comme toute dette : on la mesure d'abord, on rembourse ce qui coûte le plus d'intérêts, et on cesse de prendre de la dette nouvelle sans la noter.
Pourquoi elle grossit plus vite avec l'IA
L'IA écrit beaucoup de code en peu de temps, et ce code arrive sans le contexte de pourquoi il est ainsi. On duplique l'existant, on répète des motifs différents pour la même chose, et des dépendances que personne n'a choisies s'ajoutent. En laboratoire, 45% du code généré par IA présentait des vulnérabilités connues sans consigne de sécurité.
L'effet ne se voit pas la première semaine : il se voit quand il faut changer quelque chose et que chaque changement touche cinq endroits.
Comment on la mesure et par où commencer
On la mesure avec le code sous les yeux : duplication, dépendances périmées et vulnérables, tests absents, routes non protégées, requêtes qui ne tiennent pas le volume réel et endroits où le système casse sans prévenir. Chacun avec sa preuve, pas avec un avis.
Et on l'ordonne selon ce que ça coûte si ça casse, pas selon ce qui gêne à la lecture. Nous livrons cette liste et l'ordre ; la réparation est un second niveau : votre équipe l'applique, ou nous la faisons si vous nous la confiez.