Dette technique : dix signaux qu'il est temps d'auditer.

La dette technique, c'est le coût caché des raccourcis d'hier : du code écrit vite, des mises à jour repoussées, des tests jamais écrits. Comme une dette financière, elle se rembourse avec des intérêts : chaque évolution coûte un peu plus cher que la précédente. Toute application en porte ; le problème commence quand personne ne la mesure.

Les dix signaux

1. Chaque correctif casse autre chose. Les régressions s'enchaînent, les mêmes bugs reviennent.
2. Les mises en production font peur. On déploie tard le soir, ou on ne déploie plus, faute de procédure fiable.
3. Une seule personne sait comment ça marche. Son absence bloque tout ; son départ serait un risque majeur.
4. Les dépendances ne sont plus à jour. Langage, framework ou bibliothèques en fin de support : plus de correctifs de sécurité.
5. Les tests automatisés manquent. Chaque modification se vérifie à la main, quand on y pense.
6. Les estimations dérapent. Une évolution « simple » prend bien plus longtemps que prévu, à chaque fois.
7. La documentation est absente ou périmée. Un nouvel arrivant met des semaines à devenir autonome.
8. Les performances se dégradent. Pages lentes, traitements qui débordent, serveurs gonflés pour compenser.
9. Les coûts d'hébergement grimpent sans raison claire : ressources inutilisées, architecture qui suit mal la charge.
10. La feuille de route recule. Les projets attendus glissent d'un trimestre à l'autre, faute de temps pour autre chose que la maintenance.

Trois signaux ou plus ? Un audit vous dira où se concentre la dette et ce qu'elle vous coûte.

Ce que coûte la dette technique

Elle se paie rarement d'un coup. Elle se paie en temps perdu à chaque évolution, en incidents, en risques de sécurité. Son coût le plus lourd est souvent invisible : les projets que l'équipe n'a jamais le temps de lancer.

• Du temps : chaque évolution demande de comprendre, contourner, retester.
• De la sécurité : des composants sans correctifs exposent l'application et les données.
• Des recrutements : les bons développeurs fuient les bases de code ingérables.
• Des opportunités : les projets qui créent de la valeur restent dans le backlog.

Ce que contient un audit

• Architecture et qualité du code
• Dépendances obsolètes et failles connues
• Tests et chaîne de déploiement
• Sécurité applicative et données personnelles
• Performances et coûts d'hébergement
• Documentation : une autre équipe pourrait-elle reprendre demain ?

Le livrable doit être lisible par un dirigeant : la dette classée par zone et par risque, et un plan de remboursement chiffré. Voir notre audit de code.

Rembourser sans tout arrêter

Une refonte complète est rarement la bonne réponse. Le plus efficace : sécuriser d'abord, automatiser ensuite, rembourser au fil des évolutions.

1. Sécuriser : mettre à jour ce qui expose l'application, sauvegarder, superviser.
2. Automatiser : tests sur les parcours critiques, déploiement continu, environnement de recette.
3. Rembourser par zones : à chaque évolution, assainir le code touché.
4. Mesurer : suivre quelques indicateurs dans le temps (incidents, délais de livraison, dépendances obsolètes).

Une règle simple : réserver une part de chaque itération au remboursement, plutôt que d'attendre une hypothétique « grande refonte ».