Dette technique, la reconnaître, la mesurer, la réduire

L'expression a été proposée par le développeur Ward Cunningham au début des années 1990. Elle désigne les raccourcis pris lors du développement, qui font gagner du temps sur le moment, mais qu'il faudra rembourser plus tard, avec des intérêts.

Elle prend des formes très concrètes.

• Du code copié à plusieurs endroits au lieu d'être factorisé.
• Des dépendances jamais mises à jour, parfois plus maintenues par leurs auteurs.
• Des tests automatisés abandonnés, ou jamais écrits.
• Une documentation absente, qui fait dépendre le projet d'une seule personne.

Côté métier, la dette technique se reconnaît sans lire une ligne de code.

• Les évolutions simples prennent de plus en plus de temps.
• Chaque correction en provoque une autre ailleurs.
• Plus personne n'ose mettre à jour certaines parties de l'application.
• Le déploiement ne fonctionne que depuis un poste, ou que par une personne.

Un état des lieux commence par l'inventaire des dépendances et de leur âge, la part du code couverte par des tests, et les zones qui concentrent les incidents. On y ajoute le temps réellement passé sur les dernières évolutions. Le résultat se traduit en langage métier, ce qui est fragile, ce qui presse, ce qui peut attendre.

Tout réécrire est rarement la bonne réponse. Une application qui rend service porte des années de décisions métier, qu'une réécriture risque de perdre.

La réduction se fait par étapes.

• Sécuriser d'abord, sauvegardes vérifiées, dépendances critiques mises à jour, tests sur les parties sensibles.
• Profiter de chaque évolution pour assainir la zone de code concernée.
• Réserver une part régulière du temps de maintenance à la dette elle-même.
• Ne réécrire une partie que lorsque l'on peut expliquer pourquoi.