7 min lecture • Guide 65 of 877
Gérer la Dette Technique Stratégiquement
La dette technique est inévitable en développement logiciel, mais une dette non gérée accumule des intérêts qui ralentissent les équipes. La gestion stratégique de dette signifie prendre des décisions éclairées sur quand contracter de la dette, la suivre explicitement, et la rembourser systématiquement. GitScrum fournit la visibilité et les outils de planification pour gérer la dette technique comme préoccupation de première classe.
Comprendre la Dette Technique
Types et impact de la dette technique:
| Type Dette | Cause | Impact | Taux Intérêt |
|---|---|---|---|
| Délibérée-Prudente | Trade-off conscient pour deadline | Connu, contenu | Bas-Moyen |
| Délibérée-Imprudente | "Pas de temps pour le design" | Accumule vite | Élevé |
| Inadvertante-Prudente | "On ne savait pas mieux alors" | Découvert avec temps | Moyen |
| Inadvertante-Imprudente | "C'est quoi l'architecture?" | Problèmes système entier | Très Élevé |
Rendre la Dette Visible
Suivi dans GitScrum
STRUCTURE TÂCHE DETTE TECHNIQUE:
┌─────────────────────────────────────────────────────────────┐
│ SYSTÈME VISIBILITÉ DETTE │
├─────────────────────────────────────────────────────────────┤
│ │
│ LABELS POUR CATÉGORISATION: │
│ ├── "type:tech-debt" - Tous items dette technique │
│ ├── "debt:architecture" - Problèmes design/structure │
│ ├── "debt:code-quality" - Code désordonné, duplication │
│ ├── "debt:testing" - Tests manquants/inadéquats │
│ ├── "debt:dependencies" - Bibliothèques obsolètes │
│ ├── "debt:documentation" - Docs manquantes/obsolètes │
│ └── "debt:infrastructure" - Build, deploy, monitoring │
│ │
│ LABELS PRIORITÉ/URGENCE: │
│ ├── "debt-priority:critical" - Bloquant développement │
│ ├── "debt-priority:high" - Causant ralentissement signif. │
│ ├── "debt-priority:medium" - Inconvénient mais gérable │
│ └── "debt-priority:low" - Bon à corriger un jour │
│ │
│ EXEMPLE TÂCHE DETTE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Titre: Refactoriser module traitement paiements ││
│ │ ││
│ │ Labels: type:tech-debt, debt:architecture, ││
│ │ debt-priority:high ││
│ │ ││
│ │ Description: ││
│ │ État Actuel: ││
│ │ Logique traitement paiements dispersée dans 5 services ││
│ │ avec validation dupliquée et gestion erreurs incohérente.││
│ │ ││
│ │ Impact: ││
│ │ - Chaque feature paiements prend 2x plus ││
│ │ - 3 bugs paiements dernier trimestre par incohérence ││
│ │ ││
│ │ Effort: 13 points (1 sprint avec testing) ││
│ │ ROI: Réduit temps feature paiements 50% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Registre de Dette
INVENTAIRE DETTE TECHNIQUE:
┌─────────────────────────────────────────────────────────────┐
│ TABLEAU DE BORD SUIVI DETTE │
├─────────────────────────────────────────────────────────────┤
│ │
│ DETTE PAR CATÉGORIE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Architecture ████████████████ 42 pts (8 items) ││
│ │ Qualité Code ██████████████ 35 pts (12 items) ││
│ │ Tests ████████████ 28 pts (6 items) ││
│ │ Dépendances ████████ 18 pts (4 items) ││
│ │ Documentation ██████ 15 pts (5 items) ││
│ │ Infrastructure █████ 12 pts (3 items) ││
│ │ ││
│ │ TOTAL: 150 points sur 38 items ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DETTE PAR PRIORITÉ: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🔴 Critique: 3 items (25 pts) - Adresser immédiatement ││
│ │ 🟠 Haute: 8 items (48 pts) - Planifier ce trimestre ││
│ │ 🟡 Moyenne: 15 items (52 pts) - Surveiller, opportuniste││
│ │ 🟢 Basse: 12 items (25 pts) - Backlog ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Framework de Priorisation
Évaluer Items de Dette
MATRICE PRIORISATION DETTE:
┌─────────────────────────────────────────────────────────────┐
│ CRITÈRES DE SCORING │
├─────────────────────────────────────────────────────────────┤
│ │
│ SCORE IMPACT (1-5): │
│ ├── 5: Bloquant nouvelles features ou causant pannes │
│ ├── 4: Ralentissant développement significativement │
│ ├── 3: Friction notable, bugs occasionnels │
│ ├── 2: Inconvénient mineur, code smell │
│ └── 1: Cosmétique, pas d'impact réel │
│ │
│ SCORE EFFORT (1-5): │
│ ├── 1: Correction rapide (< 4 heures) │
│ ├── 2: Petite tâche (1-2 jours) │
│ ├── 3: Tâche moyenne (3-5 jours) │
│ ├── 4: Grande tâche (1-2 sprints) │
│ └── 5: Effort majeur (> 2 sprints) │
│ │
│ SCORE CONTAGION (1-5): │
│ ├── 5: Se propageant vite, infectant nouveau code │
│ ├── 4: Équipe copie mauvais patterns │
│ ├── 3: Contenu mais grandit lentement │
│ ├── 2: Isolé à une zone │
│ └── 1: Statique, ne se propage pas │
│ │
│ PRIORITÉ = (Impact × 2 + Contagion) / Effort │
│ │
└─────────────────────────────────────────────────────────────┘
Allocation de Capacité
Équilibrer Dette avec Features
MODÈLE CAPACITÉ SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ ALLOCATION TYPE TRAVAIL │
├─────────────────────────────────────────────────────────────┤
│ │
│ BASELINE RECOMMANDÉ: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Features ──────────────────── 70% ││
│ │ ██████████████████████████████████████████████████████ ││
│ │ ││
│ │ Correction Bugs ───────────── 15% ││
│ │ ██████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ││
│ │ ││
│ │ Dette Technique ───────────── 10% ││
│ │ █████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ││
│ │ ││
│ │ Innovation/Spikes ─────────── 5% ││
│ │ █████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AJUSTER PAR NIVEAUX DETTE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DETTE BASSE (< 50 pts): ││
│ │ Features: 75%, Bugs: 15%, Dette: 5%, Innovation: 5% ││
│ │ ││
│ │ DETTE MODÉRÉE (50-150 pts): ││
│ │ Features: 70%, Bugs: 15%, Dette: 10%, Innovation: 5% ││
│ │ ││
│ │ DETTE HAUTE (150-300 pts): ││
│ │ Features: 60%, Bugs: 15%, Dette: 20%, Innovation: 5% ││
│ │ ││
│ │ DETTE CRITIQUE (> 300 pts): ││
│ │ Features: 40%, Bugs: 10%, Dette: 40%, Innovation: 10% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Prévenir Nouvelle Dette
Standards Développement
PRATIQUES PRÉVENTION DETTE:
┌─────────────────────────────────────────────────────────────┐
│ ARRÊTER DETTE À LA SOURCE │
├─────────────────────────────────────────────────────────────┤
│ │
│ PORTES CODE REVIEW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Checklist Review: ││
│ │ ├── [ ] Pas de code dupliqué introduit ││
│ │ ├── [ ] Tests couvrent nouvelle fonctionnalité ││
│ │ ├── [ ] Documentation mise à jour ││
│ │ ├── [ ] Pas de TODO sans tâche liée ││
│ │ ├── [ ] Suit patterns établis ││
│ │ └── [ ] Pas nouveaux warnings linter/type ││
│ │ ││
│ │ Dette Ajoutée? Doit être: ││
│ │ ├── Suivie explicitement (créer tâche dette) ││
│ │ ├── Justifiée dans description PR ││
│ │ └── Approuvée par tech lead ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DÉFINITION DE FAIT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Feature est "Faite" quand: ││
│ │ ├── Fonctionnalité complète ││
│ │ ├── Tests écrits et passent ││
│ │ ├── Code revu et approuvé ││
│ │ ├── Documentation mise à jour ││
│ │ └── Pas nouvelle dette (ou tâche dette créée) ││
│ │ ││
│ │ Raccourcis = Incomplet, pas Fait ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Meilleures Pratiques
Faire
GESTION STRATÉGIQUE DETTE:
✓ RENDRE DETTE VISIBLE
Chaque item dette suivi dans GitScrum avec labels
✓ ALLOUER CAPACITÉ
10-20% de chaque sprint pour travail dette
✓ PRIORISER PAR IMPACT
Focus sur dette bloquant travail actuel
✓ SUIVRE TENDANCES
Surveiller niveaux dette au fil temps
✓ PRÉVENIR NOUVELLE DETTE
Quality gates et standards code review
Ne Pas Faire
PIÈGES GESTION DETTE:
✗ IGNORER DETTE
"On corrigera plus tard" sans suivi
✗ TOUT OU RIEN
Attendre sprints dédiés à dette
✗ CONVERSATIONS TECHNIQUES SEULEMENT
Stakeholders ne comprennent pas impact
✗ GOLD PLATING
Corriger code sans impact "parce que c'est moche"