La dette technique n'est pas toujours mauvaise,parfois on la contracte intentionnellement pour livrer plus vite. Le problème c'est la dette non intentionnelle, invisible, qui ralentit silencieusement chaque sprint. L'objectif n'est pas zéro dette, mais une dette gérée et visible.

Comment la mesurer

• ✓Analyse statique : des outils comme PHPStan, ESLint, SonarQube donnent un score quantifié. Les intégrer en CI.
• ✓Couverture de tests : en dessous de 60% c'est un signal de risque. La couverture seule ne garantit pas la qualité, mais zéro couverture est toujours un problème.
• ✓Complexité cyclomatique : les fonctions avec complexité > 10 sont difficiles à tester et maintenir. Les refactorer.
• ✓Temps d'onboarding : combien de temps faut-il à un nouveau développeur pour faire sa première PR significative ? Haute dette = onboarding long.
• ✓Taux de récurrence des bugs : le même module qui casse régulièrement signale des problèmes structurels.

Priorisation : la matrice effort/impact

Toute la dette ne vaut pas d'être corrigée maintenant. Prioriser selon deux axes : impact métier (cette zone affecte-t-elle les chemins critiques ?) et effort de correction (à quel point c'est difficile à corriger ?). Les corrections à fort impact et faible effort passent en premier. Les corrections à fort effort et faible impact attendent,ou sont supprimées.

Rendre la dette visible pour les parties prenantes

Les parties prenantes ne financent pas le "refactoring",elles financent des résultats. Formuler la réduction de dette en termes de vélocité de livraison ("corriger ceci réduira notre cycle de release de 30%") et de réduction de risque ("ce module n'a pas de tests et représente 40% de nos incidents"). C'est un langage qui obtient des budgets.

• ✓Ajouter les items de dette au backlog avec des estimations d'impact métier
• ✓Suivre un "ratio de dette" : nombre de tickets dette vs tickets fonctionnalité par sprint
• ✓Établir une politique : 20% de chaque sprint va à la dette,la protéger