Gestion de la Dette Technique : taxonomie, priorisation et communication
#architecture#technical-debt#management#engineering
La dette technique n'est pas inherement mauvaise. Comme la dette financière, elle devient dangereuse quand elle est invisible, non mesurée, et que les intérêts s'accumulent plus vite qu'on ne peut les rembourser. L'objectif n'est pas zéro dette mais une dette consciente et gérée.
Taxonomie des types de dette
Dette Technique
├── Deliberee
│ ├── Stratégique ("livrer maintenant, refactorer ensuite" avec un plan)
│ └── Tactique ("on connait ce raccourci, la deadline est demain")
├── Accidentelle
│ ├── Lacune de connaissances (ne savait pas qu'une meilleure approche existait)
│ └── Erosion (dependances obsoletes, patterns devenus anti-patterns)
├── Environnementale
│ ├── Derive de plateforme (le provider cloud a deprecie un service)
│ └── Changement d'écosystème (framework EOL, version de langage)
└── Architecturale
├── Mauvaise abstraction (generalisation prematuree)
├── Abstraction manquante (proliferation du copier-coller)
└── Violations de frontieres (couplage fort entre services)
Matrice de priorisation : Impact vs Effort
Impact ▲
(douleur)│
│ ┌─────────────┐ ┌─────────────┐
HAUT │ │ PLANIFIER │ │ FAIRE EN │
│ │ (haute │ │ PREMIER │
│ │ douleur, │ │ (haute │
│ │ coût eleve)│ │ douleur, │
│ └─────────────┘ │ coût faible)│
│ └─────────────┘
│ ┌─────────────┐ ┌─────────────┐
BAS │ │ PROBABLEMENT│ │ FAIRE SI │
│ │ JAMAIS │ │ A PROXIMITE│
│ └─────────────┘ └─────────────┘
└─────────────────────────────────────►
EFFORT eleve EFFORT faible
Cadre de mesure
| Métrique | Ce qu'elle mesuré | Outil / Source | Cible |
|---|---|---|---|
| Augmentation du cycle time | Ralentissement de la livraison | Jira/Linear, métriques DORA | < 10% d'augmentation par trimestre |
| Densite de bugs par zone | Zones de code fragiles | Bug tracker, hotspots | Tendance a la baisse |
| Age des dependances | Bibliotheques obsolètes | Dependabot, Renovate | Aucune dep > 2 versions majeures |
| Delta couverture tests | Zones de dette non testées | Outils de couverture | Couverture stable ou croissante |
| Enquete friction dev | Points de douleur percus | Enquete trimestrielle (1-5) | Moyenne > 3.5 |
| Tendance temps de build | Sante du pipeline CI/CD | Métriques CI | < 10min pour tests unitaires |
Template de communication pour les parties prenantes
| Element de dette | Impact métier | Coût du retard | Effort de remediation | Calendrier proposé |
|---|---|---|---|---|
| Couplage déploiement monolithe | Releases prennent 2 jours au lieu de 2h | Chaque feature retardée de 1.5 jours | 3 sprints (extraire service) | T2 2026 |
| Bibliotheque auth obsolète | Exposition aux vulnérabilités | Risque de breche, non-conformité | 1 sprint | Immediat |
| Pas de tests d'intégration paiements | 2 bugs paiement/mois en moyenne | Attrition clients, coût support | 2 sprints | T2 2026 |
Formule qui resonne : "Cette dette nous coute X heures-developpeur par semaine. La corriger coute Y semaines-developpeur. Le retour sur investissement est de Z semaines."
Modèle de budget dette
| Categorie | Allocation | Cadence | Decideur |
|---|---|---|---|
| Dette sécurité | Immediat (hors budget) | A la decouverte | Équipe sécurité |
| Dette a fort impact | 20% de la capacité sprint | Chaque sprint | Tech lead + PM |
| Dette maintenance | 1 sprint dedie par trimestre | Trimestriel | Engineering manager |
| Dette architecturale | Initiative dediee | Planification semestrielle | CTO / Équipe architecture |
| Opportuniste | Règle du Boy Scout | Chaque PR | Developpeur individuel |