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
tadata
- Délibérée
- Stratégique (« livrer maintenant, refactorer ensuite » avec un plan)
- Tactique (« on connaît ce raccourci, la deadline est demain »)
- Accidentelle
- Lacune de connaissances (on ignorait qu'une meilleure approche existait)
- Érosion (dépendances obsolètes, patterns devenus anti-patterns)
- Environnementale
- Dérive de plateforme (le fournisseur cloud a déprécié un service)
- Évolution de l'écosystème (fin de vie d'un framework, version du langage)
- Architecturale
- Mauvaise abstraction (généralisation prématurée)
- Abstraction manquante (prolifération du copier-coller)
- Violations de frontières (couplage fort entre services)
Matrice de priorisation : Impact vs Effort
tadata
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 |
tadata
Extrait de la fiche « AZ-400 Domain 5: Instrumentation Strategy » · Demander la fiche complète
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 |