Qu'est-ce que la dette technique ?
La dette technique est une metaphore financiere introduite par Ward Cunningham (co-createur du Manifeste Agile) pour decrire le cout futur induit par des choix techniques rapides ou sous-optimaux. Comme une dette financiere, la dette technique genere des "interets" : plus elle s'accumule, plus chaque modification future coutera cher en temps et en effort. Le code devient difficile a comprendre, a modifier et a tester.
Types de dette technique
La dette deliberee est un choix conscient : livrer rapidement un MVP avec du code imparfait, sachant qu'on devra refactorer. C'est souvent justifie par des contraintes business. La dette accidentelle resulte de l'ignorance ou de la negligence : mauvaises pratiques, manque de tests, architecture inadaptee. La dette d'obsolescence apparait naturellement quand les technologies evoluent : dependances depassees, versions de langage anciennes, patterns obsoletes.
Causes courantes
Les causes principales sont : les deadlines serrees (couper les coins pour livrer a temps), l'absence de tests automatises (modifications risquees), le manque de documentation (connaissance perdue quand un developpeur part), l'absence de code reviews (mauvaises pratiques non detectees), le turnover (chaque nouveau developpeur ajoute son style), et la croissance organique (l'architecture initiale ne supporte plus la taille du projet).
Mesurer et gerer la dette
Des outils comme SonarQube, Code Climate et CodeScene mesurent la dette technique via des metriques : complexite cyclomatique, duplication, couverture de tests, code smells, et estimation du temps de remediation. La gestion passe par : allouer un pourcentage du sprint au remboursement (typiquement 15-20%), appliquer la regle du Boy Scout, maintenir un registre de dette (documenter les compromis), et prioriser par impact (la dette dans le code modifie frequemment est plus couteuse).
Metaphore et communication
La metaphore de la dette est puissante pour communiquer avec les parties prenantes non-techniques. "Nous pouvons livrer en 2 semaines avec de la dette technique, mais chaque fonctionnalite future prendra 30% plus longtemps" est plus parlant que "le code a besoin de refactoring". La dette technique n'est pas toujours mauvaise : c'est un outil strategique quand elle est deliberee, mesuree et remboursee.