Qu'est-ce que la dette technique ?
La dette technique est une metaphore financiere introduite par Ward Cunningham (co-createur du Manifeste Agile) pour décrire le coût 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 à comprendre, à modifier et à 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 évoluent : dépendances depassees, versions de langage anciennes, patterns obsolètes.
Causes courantes
Les causes principales sont : les deadlines serrees (couper les coins pour livrer à temps), l'absence de tests automatises (modifications risquees), le manque de documentation (connaissance perdue quand un développeur part), l'absence de code reviews (mauvaises pratiques non détectées), le turnover (chaque nouveau développeur ajoute son style), et la croissance organique (l'architecture initiale ne supporte plus la taille du projet).
Mesurer et gérer la dette
Des outils comme SonarQube, Code Climate et CodeScene mesurent la dette technique via des métriques : complexité 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 règle du Boy Scout, maintenir un registre de dette (documenter les compromis), et prioriser par impact (la dette dans le code modifie fréquemment 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 fonctionnalité 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 stratégique quand elle est deliberee, mesuree et remboursee.