8 min lecture • Guide 32 of 877
Gérer la Dette Technique Pendant le Développement Actif
La dette technique s'accumule naturellement pendant le développement actif—fixes rapides, solutions temporaires, patterns obsolètes. Le défi n'est pas d'éliminer la dette entièrement mais de la gérer stratégiquement pour qu'elle ne devienne pas une crise. GitScrum fournit les outils de visibilité et workflow pour tracker, prioriser et aborder systématiquement la dette technique tout en maintenant la vélocité des features.
Pourquoi la Dette Technique Compte
La dette non gérée crée des problèmes composés:
| Niveau Dette | Impact |
|---|---|
| Faible | Ralentissements mineurs, facile à aborder |
| Moyen | Friction notable, affecte vélocité |
| Élevé | Retards significatifs, changements risqués |
| Critique | Paralysie développement, taux échec élevé |
Types de Dette Technique
Framework de Catégorisation
Catégories Dette Technique:
DETTE DÉLIBÉRÉE
───────────────
Faite consciemment pour vitesse/deadlines
Exemples:
├── Fix rapide pour bug urgent
├── Valeurs hardcodées pour démo
├── Tests sautés pour deadline
├── Raccourcis temporaires architecture
└── Solution connue comme sous-optimale
Tracking: Doit documenter avec plan remboursement
DETTE ACCIDENTELLE
──────────────────
Découverte après, pas intentionnelle
Exemples:
├── Design n'a pas scalé comme prévu
├── Exigences changées post-implémentation
├── Meilleurs patterns découverts après
├── Bibliothèque dépréciée inopinément
└── Problèmes performance sous charge réelle
Tracking: Capturer quand découverte, évaluer impact
DETTE OBSOLÈTE
──────────────
Était bonne, devenue problématique
Exemples:
├── Anciennes versions framework
├── APIs dépréciées encore utilisées
├── Patterns legacy dans nouveau codebase
├── Code copy-paste accumulé
└── Dépendances obsolètes avec vulnérabilités
Tracking: Audits réguliers, détection automatisée
Tracker Dette Technique dans GitScrum
Board Dédié Dette
Configuration Board Dette Technique:
COLONNES:
┌─────────────────────────────────────────────────────────────┐
│ Identifiée │ Évaluée │ Planifiée │ En Cours │ Résolue │
├─────────────────────────────────────────────────────────────┤
│ │ │ │ │ │
│ [Items │ [Sized & │ [Prévue │ [Nettoyage│ [Fait & │
│ dette raw]│ rated] │ travail] │ actif] │ vérifié] │
│ │ │ │ │ │
└─────────────────────────────────────────────────────────────┘
Labels pour Catégorisation:
├── debt/deliberate
├── debt/accidental
├── debt/outdated
├── debt/security
├── debt/performance
├── debt/architecture
├── debt/testing
└── debt/documentation
Labels Priorité:
├── impact/critical (bloque développement)
├── impact/high (ralentissement significatif)
├── impact/medium (friction notable)
└── impact/low (inconvénient mineur)
Template Tâche Dette
Template Item Dette Technique:
┌─────────────────────────────────────────────────────────────┐
│ DETTE: [Description brève] │
├─────────────────────────────────────────────────────────────┤
│ ## Quoi │
│ [Description de la dette] │
│ │
│ ## Pourquoi Elle Existe │
│ [Contexte: deadline, ne savions pas mieux, exigences │
│ changées, etc.] │
│ │
│ ## Impact │
│ - Coût actuel: [temps perdu par semaine/mois] │
│ - Niveau risque: [Faible/Moyen/Élevé/Critique] │
│ - Zones affectées: [lister composants/features] │
│ │
│ ## Solution Proposée │
│ [Comment corriger] │
│ │
│ ## Estimation Effort │
│ - Temps fix: [X story points / heures] │
│ - Temps testing: [Y story points / heures] │
│ - Risque du fix: [Faible/Moyen/Élevé] │
│ │
│ ## Taux d'Intérêt │
│ [Vitesse de croissance de cette dette?] │
│ - Statique: Même coût au fil du temps │
│ - Croissante: Empire avec croissance codebase │
│ - Composée: Bloque autres améliorations │
└─────────────────────────────────────────────────────────────┘
Framework de Priorisation
Analyse Coût-Bénéfice
Matrice Priorisation Dette:
FAIBLE EFFORT EFFORT ÉLEVÉ
┌─────────────────┬─────────────────┐
IMPACT │ │ │
ÉLEVÉ │ FAIRE D'ABORD │ PLANIFIER BIEN│
│ Quick wins │ Refactor majeur│
│ ROI élevé │ Nécessite sprint│
├─────────────────┼─────────────────┤
IMPACT │ │ │
FAIBLE │ FAIRE SI FACILE│ PROBABLEMENT │
│ Quand à côté │ SAUTER │
│ Règle scout │ Documenter seul│
└─────────────────┴─────────────────┘
Modèle Scoring:
SCORE IMPACT (1-5):
├── 5: Bloque multiples features ou cause pannes
├── 4: Ralentit significativement tout développement
├── 3: Affecte une équipe ou zone feature
├── 2: Inconvénient mineur, contournements existent
└── 1: Cosmétique, best-practice seulement
SCORE EFFORT (1-5):
├── 5: Refactor majeur, semaines travail
├── 4: Plusieurs jours, testing significatif
├── 3: Journée entière, testing modéré
├── 2: Quelques heures, testing limité
└── 1: Fix rapide, risque minimal
PRIORITÉ = IMPACT ÷ EFFORT
Considération Taux d'Intérêt
Évaluation Taux Intérêt Dette:
DETTE STATIQUE (Faible urgence)
───────────────────────────────
Coût reste même au fil du temps
Exemples:
├── Conventions nommage inconsistantes
├── Documentation manquante
├── Schema DB sous-optimal (tables stables)
└── Anciens patterns code (modules isolés)
Stratégie: Aborder opportunistiquement
DETTE CROISSANTE (Urgence moyenne)
──────────────────────────────────
Coût augmente avec croissance codebase
Exemples:
├── Pas couverture tests sur code actif
├── Code dupliqué entre features
├── Structures données inefficaces
└── Abstractions manquantes
Stratégie: Aborder avant prochaine feature majeure
DETTE COMPOSÉE (Urgence élevée)
───────────────────────────────
Bloque autres améliorations, se propage
Exemples:
├── Dépendances circulaires
├── Objets/classes god
├── Pipeline CI/CD cassé
├── Vulnérabilités sécurité
└── Dépendances dépréciées sans chemin upgrade
Stratégie: Aborder immédiatement, peut nécessiter sprint dédié
Stratégies d'Intégration
Règle Boy Scout
Approche Boy Scout:
"Laissez le code mieux que vous l'avez trouvé"
En travaillant sur une feature:
├── Identifier dette proche en codant
├── Corriger petits problèmes (< 30 min)
├── Logger problèmes plus grands pour après
├── Ne pas élargir scope de la feature
└── Tracker améliorations faites
Implémentation GitScrum:
1. Tâche feature a checklist:
□ Feature complète
□ Tests passent
□ Dette proche abordée?
□ Corrigée: [décrire]
□ Loggée: DEBT-XXX
2. Vélocité sprint inclut:
└── ~10% buffer pour améliorations scout
Sprints Dette
Sprint Dédié Nettoyage:
QUAND EXÉCUTER:
├── Après release majeure (stabilisation)
├── Avant changement architectural
├── Quand vélocité baisse significativement
├── Cycle maintenance trimestriel
└── Quand ratio dette dépasse seuil
STRUCTURE SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ SPRINT NETTOYAGE: Dette Technique Q1 │
├─────────────────────────────────────────────────────────────┤
│ Durée: 1 semaine (ou 1 sprint) │
│ Objectif: Réduire dette critique/haute de 50% │
├─────────────────────────────────────────────────────────────┤
│ Jour 1: Triage │
│ ├── Revoir toute dette identifiée │
│ ├── Ré-évaluer priorités │
│ ├── Choisir scope sprint │
│ └── Assigner ownership │
├─────────────────────────────────────────────────────────────┤
│ Jours 2-4: Exécution │
│ ├── Travailler sur items dette │
│ ├── Code review comme d'habitude │
│ ├── Emphase testing │
│ └── Démos quotidiennes améliorations │
├─────────────────────────────────────────────────────────────┤
│ Jour 5: Clôture │
│ ├── Compléter items en cours │
│ ├── Documenter ce qui a été corrigé │
│ ├── Mesurer amélioration │
│ └── Célébrer victoires │
└─────────────────────────────────────────────────────────────┘
Allocation Continue
Budget Continu Dette:
MODÈLE ALLOCATION VÉLOCITÉ:
┌─────────────────────────────────────────────────────────────┐
│ CAPACITÉ SPRINT: 50 Story Points │
├─────────────────────────────────────────────────────────────┤
│ │
│ Features: 40 pts (80%) ████████████████████ │
│ Dette Tech: 8 pts (16%) ████ │
│ Buffer: 2 pts (4%) █ │
│ │
└─────────────────────────────────────────────────────────────┘
IMPLÉMENTATION:
├── Chaque sprint inclut items dette
├── Équipe choisit du backlog priorisé
├── Items dette traités comme features
├── Trackés dans métriques vélocité
└── Visibles aux parties prenantes
Visibilité et Reporting
Dashboard Dette
Dashboard Dette Technique:
┌─────────────────────────────────────────────────────────────┐
│ APERÇU DETTE TECHNIQUE [Sprint 23 ▼] │
├─────────────────────────────────────────────────────────────┤
│ │
│ Total Items Dette: 47 Tendance: ↓ 3 du dernier sprint │
│ │
│ Par Priorité: │
│ │ Critique ████ 4 │
│ │ Haute ████████████ 12 │
│ │ Moyenne ████████████████████ 19 │
│ │ Basse ████████████ 12 │
│ │
│ Ratio Dette: 12% du backlog total │
│ Seuil sain: < 15% │
│ Statut: ✓ SAIN │
└─────────────────────────────────────────────────────────────┘
Stratégies Prévention
Définition de Terminé
Définition Terminé Mise à Jour:
AVANT FUSION:
□ Feature complète selon critères acceptation
□ Tests unitaires écrits (>80% couverture)
□ Tests intégration pour chemins critiques
□ Pas nouvelles erreurs linting
□ Pas nouveaux warnings sécurité
□ Documentation mise à jour
□ Performance acceptable (<200ms API)
□ Accessibilité vérifiée
□ Code review par pair
□ PAS NOUVELLE DETTE TECHNIQUE INTRODUITE
└── Si inévitable, item dette créé avec:
□ Raison documentée
□ Impact évalué
□ Plan remboursement défini
□ Timeline engagé
Meilleures Pratiques
À Faire
- Tracker toute dette — Dette invisible est ingérable
- Prioriser impitoyablement — Pas toute dette nécessite correction
- Allouer budget — Investissement consistant bat nettoyage crise
- Célébrer fixes — Rendre travail dette visible et valorisé
- Prévenir accumulation — Definition of Done forte
À Ne Pas Faire
- Ignorer dette — Elle se compose avec intérêts
- Tout corriger — Certaine dette ne vaut pas l'effort
- Blâmer développeurs — Dette est souvent compromis rationnel
- Cacher aux parties prenantes — Ils doivent comprendre vélocité
- Déprioriser indéfiniment — Planifier ou accepter explicitement