En 1992, Ward Cunningham, futur inventeur du wiki et cosignataire du manifeste Agile, introduit une analogie qui deviendra célèbre, la dette technique.
L'idée est simple. Quand tu empruntes de l'argent, tu gagnes du temps maintenant mais tu devras rembourser plus tard, avec des intérêts. En développement, c'est pareil. Prendre un raccourci technique permet de livrer plus vite aujourd'hui, mais il faudra "rembourser" plus tard en retravaillant le code. Et plus on attend, plus les intérêts s'accumulent.
L'analogie a une limite qu'il faut poser tout de suite. Un emprunt se contracte en connaissance de cause. Une bonne partie de la dette technique, elle, est subie, c'est du code mal conçu sans que personne ne l'ait su, ou un choix qui était bon il y a cinq ans et qui ne l'est plus. Distinguer la dette choisie, celle qu'on a décidée, documentée et datée, de la dette subie, celle qu'on découvre, change tout à la façon de la traiter.
Comment la dette s'accumule
La dette technique ne vient pas d'un seul coup. Elle s'installe progressivement, pour des raisons souvent compréhensibles :
- La pression du temps : "on n'a pas le temps de bien faire, le client attend". Le développeur prend un raccourci en se disant qu'il reviendra corriger plus tard. Spoiler : il ne revient presque jamais.
- L'évolution du produit : une fonctionnalité conçue pour 100 utilisateurs se retrouve utilisée par 100 000. Le code n'a pas été pensé pour ça, mais personne ne prend le temps de le retravailler.
- La rotation des équipes : les développeurs qui ont conçu le système partent. Les nouveaux ne comprennent pas toutes les subtilités et ajoutent du code par-dessus sans oser toucher à l'existant.
- Les technologies qui vieillissent : un framework à la pointe il y a 5 ans n'est plus maintenu aujourd'hui. Les failles de sécurité ne sont plus corrigées, les développeurs compétents sur cette technologie se font rares.
- Les demandes elles-mêmes : l'urgence permanente, le périmètre qui bouge en cours de route, et surtout l'exception accordée à un client puis à un deuxième. Chaque "juste pour cette fois" laisse une branche de plus dans le code, et c'est le poste de dette sur lequel tu as le plus de prise.
La dette n'est d'ailleurs pas que du code. Une documentation absente, une infrastructure jamais mise à jour, des données incohérentes accumulées depuis des années sont de la dette au même titre. Et il en existe une forme qui t'appartient entièrement, la dette fonctionnelle, ces options que plus personne n'utilise mais qu'il faut continuer à faire fonctionner, tester et maintenir à chaque évolution. Retirer une fonctionnalité morte est le remboursement le moins cher qui existe, et le plus rarement décidé.
L'IA générative a ajouté un chapitre récent à cette histoire. Produire du code n'a jamais été aussi rapide, le relire, le comprendre et l'entretenir non. Une équipe qui génère en une semaine ce qu'elle mettait un mois à écrire accumule aussi la dette plus vite, surtout quand personne n'a vraiment lu ce qui a été livré.
Les symptômes
Comment savoir si un projet a accumulé de la dette technique ? Les signes sont souvent les mêmes :
- Les développements ralentissent : une fonctionnalité qui aurait pris 2 jours il y a un an en prend maintenant 2 semaines. Chaque modification nécessite de comprendre et de contourner des couches de complexité accumulée.
- Les bugs se multiplient : corriger un bug en crée deux nouveaux. Le code est tellement entremêlé qu'il est impossible de toucher à une partie sans casser autre chose.
- Les mises en production sont stressantes : personne n'est vraiment sûr que tout va fonctionner. Les tests sont insuffisants ou inexistants.
- Le recrutement devient difficile : les bons développeurs fuient les projets sur des technologies obsolètes ou du code ingérable.
Le refactoring : rembourser la dette
Refactorer, c'est réécrire du code existant pour l'améliorer sans changer ce qu'il fait. L'utilisateur ne voit aucune différence, mais en interne, le code est plus propre, plus rapide, plus facile à faire évoluer.
C'est l'équivalent de rénover les fondations d'une maison. De l'extérieur, rien ne change. Mais sans cette rénovation, la maison finira par s'effondrer.
"Et si on refaisait tout ?"
C'est la question que finit par poser toute direction face à un système endetté, et la réponse des équipes
expérimentées est presque toujours non. La réécriture complète prend deux fois plus de temps que prévu,
pendant lequel l'ancien système continue de vivre et d'évoluer, et le nouveau doit reproduire quinze ans de
règles métier dont la moitié n'est écrite nulle part. Beaucoup de ces projets s'arrêtent avant la fin, et les
autres livrent un système qui a déjà sa propre dette le jour de la mise en ligne.
La stratégie qui fonctionne consiste à remplacer morceau par morceau. On extrait une fonctionnalité, on la
réécrit, on bascule le trafic dessus, on la stabilise, et on passe à la suivante, l'ancien système
rétrécissant jusqu'à disparaître. C'est plus long, beaucoup moins risqué, et ça produit de la valeur en
continu au lieu de tout promettre pour dans deux ans. Le chapitre sur les
microservices raconte comment ça se passe concrètement.
Le refactoring se prépare et se vérifie. Sans les tests automatiques du chapitre précédent pour confirmer que le comportement n'a pas bougé, réécrire du code revient à jouer à la roulette, et c'est précisément ce qui dissuade les équipes de toucher aux modules les plus douteux.
Autre difficulté, le refactoring est invisible pour les non-techniques. Un chef de produit voit un développeur passer deux semaines sur du code sans qu'aucune fonctionnalité visible n'apparaisse. C'est frustrant. C'est pourtant l'un des investissements les plus rentables sur le long terme.
Gérer la dette : un équilibre permanent
La dette technique zéro n'existe pas. Et ce n'est même pas souhaitable. Parfois, prendre un raccourci est la bonne décision : lancer vite un prototype pour valider une idée, livrer une fonctionnalité critique avant un événement commercial...
Le vrai problème, c'est la dette non maîtrisée, celle qu'on accumule sans en avoir conscience ni plan pour la rembourser.
Les équipes matures traitent la dette technique comme un budget :
- Elles la rendent visible : un registre, même sommaire, qui liste ce qui est connu, et deux ou trois indicateurs suivis dans le temps. Le temps qu'il faut pour livrer une modification banale, le nombre de bugs en production, la durée et le stress d'une mise en ligne. Sans chiffres, l'arbitrage se joue toujours contre la dette, parce que les fonctionnalités, elles, ont des chiffres.
- Elles remboursent en continu : une part fixe de chaque cycle de développement, plutôt qu'un grand "sprint de nettoyage" annuel qui ne survit jamais à la première urgence commerciale. Beaucoup d'équipes appliquent la règle du campeur, on laisse le code un peu plus propre qu'on ne l'a trouvé, à chaque passage.
- Elles décident explicitement : "on prend ce raccourci, mais on planifie le remboursement dans le prochain trimestre". La dette choisie se note, la dette subie se découvre.
De mon expérience, la dette technique est le sujet de friction n°1 entre les équipes produit et les développeurs. Les premiers veulent des fonctionnalités, les seconds veulent du temps pour "nettoyer". La clé, c'est la transparence. Expliquer concrètement l'impact de la dette sur la vitesse de livraison et la stabilité du produit. Les chiffres parlent mieux que les discours : "cette fonctionnalité prend 3 semaines au lieu de 3 jours parce qu'on n'a jamais refactoré ce module".