Dette technique : la quantifier pour convaincre votre direction

« On a de la dette technique. » Combien de fois avez-vous prononcé cette phrase en réunion ? Et combien de fois la direction vous a-t-elle répondu par un silence poli avant de passer au sujet suivant ? Le problème n’est pas la dette elle-même — c’est que personne ne la quantifie. Sans chiffres, pas de budget. Sans budget, pas de résolution.

Pourquoi « on a de la dette technique » ne fonctionne pas

La direction raisonne en termes de coût, de risque et de ROI. « Dette technique » est un concept flou pour un non-technique. C’est comme dire « la voiture fait un bruit bizarre » à votre garagiste. Il va vous demander : quel bruit ? depuis quand ? dans quelles conditions ? Pour convaincre, vous devez parler le même langage que la direction : des chiffres, des risques, et un plan d’action chiffré.

Les 6 axes de mesure de la santé d’une codebase

Une codebase se mesure sur six axes complémentaires. Chacun apporte une perspective différente et des métriques objectivables :

• Qualité du code (25%) — Complexité cyclomatique, duplication, violations PSR. Outils : PHPStan, PHPMD, PHPCPD.
• Sécurité (20%) — Vulnérabilités CVE, failles OWASP, secrets exposés. Outils : composer audit, Psalm taint analysis.
• Architecture (20%) — Couplage, cohésion, dépendances circulaires. Outils : Deptrac, PhpMetrics.
• Testabilité (15%) — Couverture, ratio tests/classes, qualité des assertions.
• Performance (10%) — Requêtes N+1, SELECT *, absence de cache.
• Maintenabilité (10%) — Versions des dépendances, APIs dépréciées, documentation.

Le système de scoring A-F

Traduire des métriques en un score global de A à F rend la situation immédiatement compréhensible pour un non-technique. C’est le même principe que la notation énergétique d’un logement : tout le monde comprend qu’un F est problématique.

• A (85-100) — Codebase saine. Maintenance standard.
• B (70-84) — Bon état. Quelques améliorations ciblées.
• C (55-69) — Dette modérée. Plan d’action recommandé.
• D (40-54) — Dette significative. Intervention prioritaire, budget à prévoir.
• E (25-39) — État critique. Refactoring majeur urgent.
• F (0-24) — État alarmant. Réécriture potentiellement plus rentable.

Traduire les métriques en impact business

C’est là que la magie opère. Chaque métrique technique doit être traduite en conséquence business :

• Complexité cyclomatique élevée → Chaque feature prend 2 à 3 fois plus de temps à développer
• Taux de duplication > 15% → Chaque correction de bug doit être répliquée dans N endroits (risque de régression)
• Dépendances obsolètes → Vulnérabilités de sécurité non patchées (risque RGPD)
• Couverture de tests < 20% → Chaque déploiement est une roulette russe
• Couplage fort → Impossible de faire évoluer un module sans casser les autres

La roadmap priorisée par ROI

Présenter un diagnostic sans plan d’action, c’est comme un médecin qui donne un diagnostic sans prescrire de traitement. Chaque problème identifié doit être transformé en action chiffrée avec trois attributs : l’effort estimé (en heures), l’impact (en points de score récupérés), et le ROI (impact/effort).

Triez ensuite par ROI décroissant. La direction voit immédiatement les « quick wins » — les actions à fort impact et faible effort — et peut décider d’un budget incrémental. Par exemple : corriger 8 failles XSS (4 heures, +8 points) a un ROI de 2 pts/h, tandis que refactorer une God class (6 heures, +3 points) a un ROI de 0.5 pts/h. Le choix de priorisation devient évident.

Le framework de présentation

Voici la structure qui fonctionne en comité de direction :

• Slide 1 — Le score : Un chiffre, une lettre, une couleur. « Notre codebase est à D (47/100). »
• Slide 2 — Les risques : 3 risques business concrets (sécurité, vélocité, turnover).
• Slide 3 — Le coût de l’inaction : Combien coûte chaque mois sans intervention.
• Slide 4 — Le plan : Top 5 actions priorisées par ROI, avec coût et impact.
• Slide 5 — La trajectoire : Score projeté après chaque vague d’actions.

Automatiser le diagnostic

Collecter manuellement ces métriques sur un projet de 500 fichiers, c’est plusieurs jours de travail. C’est exactement ce que fait Bear Scan : un audit de code PHP complet qui analyse automatiquement les 6 axes, génère un score A-F, et produit une roadmap d’actions priorisées par ROI. Le rapport est conçu pour être présenté tel quel à la direction — avec des métriques objectives, un chiffrage par action, et une trajectoire d’amélioration claire.