La dette technique n'est pas toujours mauvaise. Parfois vous la contractez délibérément pour livrer plus vite et la rembourser ensuite. Le problème, c'est la dette non intentionnelle et invisible, que personne ne suit et qui ralentit silencieusement chaque sprint. L'objectif n'est pas zéro dette, c'est une dette que vous pouvez voir, chiffrer, et arbitrer. Voici comment la mesurer avec de vrais chiffres, la prioriser, et la réduire sans arrêter la livraison.

Qu'est-ce que la dette technique, précisément ?

Ward Cunningham a forgé le terme comme une métaphore : livrer du code, c'est comme contracter un prêt. Ça vous achète de la vitesse maintenant, et vous payez des intérêts, des changements plus lents et plus de bugs, jusqu'à ce que vous refactoriez. Martin Fowler l'a découpé en un quadrant utile : la dette peut être délibérée ou par inadvertance, et prudente ou imprudente. Délibérée et prudente, on sait que c'est un raccourci et on corrigera après le lancement, est un compromis normal. Par inadvertance et imprudente, on ne savait pas qu'il y avait une meilleure façon de faire, est celle qui fait mal, et celle que la mesure sert à attraper.

Comment la mesurer

On ne pilote pas ce qu'on ne mesure pas. Trois couches se complètent : les métriques de code automatisées, un ratio unique pour les parties prenantes, et les signaux de livraison au niveau de l'équipe.

Le Technical Debt Ratio

Le chiffre unique sur lequel un non-technique peut agir. Il exprime la dette en pourcentage du coût du codebase lui-même :

Technical Debt Ratio (TDR) = (Coût de remédiation / Coût de développement) x 100

Coût de remédiation  = effort estimé pour corriger toutes les issues connues
Coût de développement = effort estimé pour reconstruire le codebase de zéro
                       (souvent approximé par lignes de code x coût par ligne)

SonarQube le calcule automatiquement avec la méthode SQALE : chaque issue détectée reçoit un temps de remédiation, ils sont additionnés, et le coût de développement est estimé à un taux configurable, 30 minutes par ligne de code par défaut. Il mappe ensuite le ratio sur une note : A jusqu'à 5 pour cent, B jusqu'à 10, C jusqu'à 20, D jusqu'à 50, E au-dessus de 50.

• ✓La tendance compte plus que le nombre : un 8 pour cent stable est plus sain qu'un 4 pour cent qui grimpe chaque mois.
• ✓Comparez des modules, pas des projets entiers : un service greenfield à 3 pour cent et un coeur legacy à 25 pour cent peuvent être tous les deux normaux.
• ✓C'est une estimation, pas un audit. Utilisez-le pour lancer la conversation, pas pour la clore.

Trouver les hotspots, pas juste le score

Un score agrégé cache où est vraiment la douleur. Croisez deux choses : la fréquence à laquelle un fichier change, son churn, et sa complexité. Les fichiers qui à la fois changent constamment et sont difficiles à raisonner sont ceux où la dette vous coûte de l'argent réel, parce que vous payez des intérêts dessus en permanence. Corrigez ceux-là d'abord. CodeScene le visualise ; une commande git d'une ligne vous en donne l'essentiel gratuitement.

# Fichiers les plus modifiés sur la dernière année
git log --since="1 year ago" --name-only --pretty=format: \
  | sort | uniq -c | sort -rn | head -20

Triez cette liste, puis regardez les premières entrées dans votre rapport d'analyse statique. Le recoupement, c'est votre backlog.

Prioriser : la matrice effort et impact

Toute la dette ne vaut pas d'être corrigée maintenant. Notez chaque item sur deux axes : l'impact métier, est-ce que ça touche des chemins critiques ou bloque du travail à venir, et l'effort de correction. Ça donne quatre quadrants.

• ✓Faible effort, fort impact : à faire en premier. Ce sont les quick wins qui construisent la confiance pour le reste.
• ✓Fort effort, fort impact : à planifier comme du vrai travail, séquencé contre la roadmap, souvent derrière un strangler pattern.
• ✓Faible effort, faible impact : à intégrer dans la règle du Boy Scout ci-dessous, sans ticket.
• ✓Fort effort, faible impact : documentez le risque et acceptez-le. Tout ne se rembourse pas.

La réduire sans arrêter la livraison

• ✓Règle du Boy Scout : laissez chaque fichier que vous touchez un peu plus propre. Renommez une variable confuse, extrayez un bloc dupliqué, ajoutez le test manquant. Ça se cumule.
• ✓Strangler pattern pour les grosses réécritures : remplacez l'ancien code morceau par morceau derrière une interface stable, en livrant tout du long, plutôt qu'une réécriture big-bang qui n'aboutit jamais.
• ✓Fixez un budget : un chiffre courant est 15 à 20 pour cent de chaque sprint, tenu et visible. Protégez-le comme n'importe quel autre engagement.
• ✓Liez chaque correction à une raison : une feature qu'elle débloque, un incident qu'elle évite, un coût qu'elle supprime. Le travail de dette sans raison affichée est la première chose coupée.
• ✓Ajoutez une règle à votre definition of done : la nouvelle dette est autorisée, mais seulement avec un ticket qui la nomme.

La rendre visible pour les parties prenantes

Les parties prenantes financent des résultats, pas du refactoring. Traduisez chaque item de dette dans leur langage : ça réduit le cycle de release de deux jours, ça supprime la classe d'incident qui a causé la panne du mois dernier, c'est ce qui bloque la feature paiements. Ensuite, mettez les items de dette dans le même backlog que les features, estimés de la même façon, pour que le compromis soit explicite plutôt que caché.

• ✓Reportez une ligne dette à chaque revue de sprint, à côté du résumé des features.
• ✓Suivez la note TDR dans le temps et montrez la courbe, pas seulement la lettre du moment.
• ✓Fixez une politique de mise en production : aucun module ne passe en prod sous une couverture ou une note convenue.

Erreurs courantes

• ✓Courir après un score parfait au lieu de surveiller la tendance.
• ✓Des réécritures big-bang qui consomment des mois et ne livrent jamais.
• ✓Traiter toute la dette comme équivalente au lieu de prioriser par impact.
• ✓Cacher le travail de dette en "divers" au lieu de le nommer, ce qui le rend invisible à nouveau.
• ✓Ajouter un outil d'analyse statique et ne jamais agir sur sa sortie.

FAQ

Comment calculer la dette technique ?

La métrique standard est le Technical Debt Ratio : le coût estimé pour corriger toutes les issues connues divisé par le coût estimé pour reconstruire le codebase, exprimé en pourcentage. SonarQube le calcule automatiquement en attribuant un temps de remédiation à chaque issue détectée et en divisant par un coût de développement estimé. Sous 5 pour cent est considéré comme sain.

Qu'est-ce qu'un bon ratio de dette technique ?

Sous 5 pour cent est généralement sain, ce que SonarQube note A. Cinq à dix pour cent est gérable. Au-dessus de 20 pour cent, le changement devient cher et la tendance doit s'inverser. Le contexte compte : un système legacy à 25 pour cent qui est stable et en baisse peut être parfaitement acceptable.

Combien de temps consacrer à la dette technique ?

Un budget courant est 15 à 20 pour cent de chaque sprint, tenu dans la durée. C'est en général suffisant pour garder la tendance plate ou en baisse sans dérailler la roadmap. Les sprints dette ponctuels ont tendance à être la première chose coupée quand une deadline bouge.

La dette technique est-elle toujours mauvaise ?

Non. Une dette délibérée et documentée, prise pour tenir une deadline ou valider une idée, est un compromis légitime. Les types dangereux sont la dette par inadvertance que personne ne suit et la dette prudente qui n'est jamais réellement remboursée.

Une dette que vous pouvez voir et chiffrer est une ligne gérable. Celle que vous ne pouvez pas est ce qui tue silencieusement la vélocité. Mesurez le ratio, surveillez la tendance, corrigez les hotspots d'abord, et gardez la conversation avec le métier dans le langage de la livraison.