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.
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 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.
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 identifient et documentent la dette existante.
- Elles allouent régulièrement du temps pour la réduire, souvent sous la forme d'une part fixe de chaque cycle de développement.
- Elles font des choix explicites : "on prend ce raccourci, mais on planifie le remboursement dans le prochain trimestre".
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".