Perdre la Trace de la Dette Technique

La dette technique s'accumule silencieusement jusqu'à paralyser la vélocité de développement. GitScrum fournit un suivi structuré avec labels, priorisation et allocation de sprint pour gérer la dette systématiquement avant qu'elle devienne une urgence.

Le Problème de la Dette Technique

Une dette non suivie crée des problèmes composés:

• Accumulation invisible — Pas de visibilité sur la croissance de la dette
• Reportée indéfiniment — Toujours déprioritisée pour les features
• Crises soudaines — Petits problèmes deviennent grands incidents
• Déclin de vélocité — Tout prend plus de temps avec le temps
• Frustration développeurs — Travailler dans des codebases dégradées
• Erreurs d'estimation — La dette rend le nouveau travail imprévisible

Solution de Suivi de Dette GitScrum

Gestion systématique de dette dans GitScrum:

Fonctionnalités Clés

Configurer le Suivi de Dette

Créer Labels de Dette

Labels pour Dette Technique:
├── tech-debt          (catégorie parente)
├── debt-architecture  (problèmes structurels)
├── debt-performance   (vitesse/efficacité)
├── debt-security      (préoccupations sécurité)
├── debt-testing       (gaps couverture tests)
├── debt-documentation (docs manquants)
└── debt-dependencies  (packages obsolètes)

Niveaux de Priorité

Matrice de Priorité pour Dette:
├── Critique — Bloque features ou cause incidents
├── Haute    — Ralentit significativement développement
├── Moyenne  — Friction notable, gérable
└── Basse    — Nettoyage, nice to have

Créer Template de Dette

Template de Tâche: Item de Dette Technique

Titre: [DEBT] Brève description
Description:
  - Quoi: État problématique actuel
  - Pourquoi: Comment c'est devenu dette
  - Impact: Effet sur développement/produit
  - Solution: Approche de fix proposée
  - Effort: Temps estimé pour résoudre
  - Risque: Conséquences si non adressé

Labels: tech-debt, [type-dette]
Priorité: [Critique/Haute/Moyenne/Basse]

Capturer la Dette Technique

Quand Enregistrer de la Dette

Enregistrer dette quand:
├── Implémentation de workarounds pour livrer features
├── Sauter tests pour respecter deadlines
├── Copier-coller au lieu de refactoriser
├── Ignorer avertissements de dépréciation
├── Hardcoder valeurs qui devraient être config
├── Laisser commentaires TODO dans le code
└── Découvrir connaissance tribale non documentée

Exemple de Tâche de Dette

[DEBT] Module paiement utilise API Stripe dépréciée

Quoi: Traitement paiement utilise Stripe API v1, 
dépréciée depuis 2023. Le code actuel fonctionne encore 
mais ne reçoit pas de mises à jour sécurité.

Pourquoi: Implémentation originale en 2021, pas de 
capacité pour migration pendant pushes de features.

Impact: 
- Risque sécurité par API non maintenue
- Nouvelles features paiement manquantes
- Cassera quand v1 sunset (Jan 2025)

Solution: Migrer vers Stripe API v3
- Mettre à jour dépendance SDK
- Refactoriser service paiement
- Mettre à jour handlers webhook
- Tester tous les flux paiement

Effort: 3-5 jours pour développeur senior
Risque: Haut - service échouera après date sunset

Labels: tech-debt, debt-security, debt-dependencies
Priorité: Critique
Deadline: Avant Jan 2025

Priorisation de Dette

Matrice Impact/Effort

                    Effort Bas      Effort Haut
                   ┌───────────────┬───────────────┐
Impact Haut        │ FAIRE D'ABORD │ PLANIFIER     │
                   │ Quick wins    │ Travail majeur│
                   ├───────────────┼───────────────┤
Impact Bas         │ COMBLER GAPS  │ REPORTER      │
                   │ Nettoyage     │ Pas rentable  │
                   │ facile        │               │
                   └───────────────┴───────────────┘

Critères de Priorisation

Allocation de Sprint pour Dette

La Règle des 20%

Réserver capacité pour travail de dette:

Capacité Sprint: 100 points
├── Features: 80 points (80%)
└── Tech Debt: 20 points (20%)

Allocation consistante prévient:
- Accumulation de dette
- Variance sprint-à-sprint
- "Sprints dette" qui frustrent stakeholders

Planification Sprint pour Dette

Planification Sprint pour Dette:

1. Revoir backlog dette
2. Vérifier items critiques/haute priorité
3. Matcher à capacité disponible (20%)
4. Sélectionner items qui:
   - S'associent bien avec features planifiées
   - Adressent points de douleur actuels
   - Ont critères de complétion clairs
5. Assigner à développeurs avec contexte

Lier Dette aux Features

Connecter Travail Lié

Tâche Feature #234: Ajouter facturation abonnement
├── Tâches Dette Liées:
│   ├── #198: [DEBT] Migrer vers Stripe API v3
│   │   └── Raison: Requis pour features abonnement
│   ├── #210: [DEBT] Ajouter logique retry paiement
│   │   └── Raison: Abonnements ont besoin auto-retry
│   └── #215: [DEBT] Améliorer gestion erreurs paiement
│       └── Raison: Meilleure UX pour échecs récurrents

Bénéfices de Lier

• Justifier travail dette aux stakeholders
• Faire émerger prérequis cachés
• Estimations features précises
• Résolution naturelle dette pendant features

Visibilité de la Dette

Vue Board pour Dette

Kanban Board: Dette Technique
┌──────────────┬──────────────┬──────────────┬──────────────┐
│ Backlog (23) │ Planifié (5) │ En Cours     │ Résolu (8)   │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ [DEBT] Auth  │ [DEBT] API   │ [DEBT] Stripe│ [DEBT] Tests │
│ [DEBT] Cache │ [DEBT] Logs  │ migration    │ [DEBT] Docs  │
│ [DEBT] Tests │ [DEBT] DB    │              │ ...          │
│ ...          │ ...          │              │              │
└──────────────┴──────────────┴──────────────┴──────────────┘

Métriques Dashboard

Suivre santé dette dans le temps:

Dashboard Dette Technique
━━━━━━━━━━━━━━━━━━━━━━━━━━

Total Items Dette: 45
├── Critique: 3 🔴
├── Haute: 12 🟡
├── Moyenne: 18 🟢
└── Basse: 12 ⚪

Ce Sprint:
├── Planifiés: 5 items (23 points)
└── Résolus: 3 items (15 points)

Tendance: ↓ 4% du mois dernier
Item Plus Ancien: 8 mois (migration DB)

Documentation dans NoteVault

Registre de Dette Technique

NoteVault: Registre Dette Technique

## Vue d'Ensemble
Ce document suit les items majeurs de dette technique 
et leur contexte business.

## Dette Active

### Système Paiement
- **Problème**: API Stripe v1 dépréciée
- **Propriétaire**: @backend-team
- **Statut**: Planifié pour Q1
- **Impact Business**: Risque sécurité, features manquantes
- **Plan Résolution**: #198

### Authentification
- **Problème**: Pas de rotation refresh token
- **Propriétaire**: @security-team
- **Statut**: En cours
- **Impact Business**: Gap compliance sécurité
- **Plan Résolution**: #245

## Dette Résolue
| Item | Résolu | Temps Passé | Notes |
|------|--------|-------------|-------|
| Legacy ORM | Nov 2024 | 2 semaines | Migration complète |
| Couverture tests | Oct 2024 | 3 sprints | 40% → 80% |

Revues de Dette

Réunions Régulières de Dette

Revue Mensuelle Dette Technique

Agenda:
1. Revoir métriques dette (15 min)
   - Nouvelle dette enregistrée
   - Dette résolue
   - Direction tendance

2. Triage nouveaux items (20 min)
   - Assigner priorité
   - Estimer effort
   - Identifier quick wins

3. Planifier prochain sprint (15 min)
   - Sélectionner dette pour prochain sprint
   - Assigner propriétaires
   - Lier aux features

4. Discuter blocages (10 min)
   - Items bloqués
   - Besoins ressources
   - Alignement stakeholders

Intégration Rétrospective

Adresser dette en rétros:

Rétrospective Sprint

Qu'est-ce qui nous a ralentis?
├── "Échecs retry paiement ont gaspillé 2 jours debugging"
│   └── Action: Prioriser #210 (dette logique retry)
├── "Tests flaky ont causé fausses alarmes"
│   └── Action: Ajouter #260 (dette stabilité tests)

Prévenir Nouvelle Dette

Définition de Terminé

Définition de Terminé (inclut prévention dette):
☑ Feature complète selon exigences
☑ Tests unitaires écrits (>80% couverture)
☑ Tests intégration passent
☑ Documentation mise à jour
☑ Pas nouveaux commentaires TODO sans ticket
☑ Dépendances mises à jour si touchées
☑ Code review approuvé
☑ Pas d'avertissements sécurité
☑ Performance acceptable

Checklist Code Review

Code Review Conscient de la Dette:

□ Ça introduit nouvelle dette?
  - Si oui, ticket créé?
□ Ça résout dette existante?
  - Si oui, lier et fermer ticket dette
□ Y a-t-il des workarounds?
  - Documenter pourquoi, créer ticket nettoyage
□ Dépendances sont à jour?
  - Vérifier dépréciations
□ Couverture tests maintenue?
  - Pas de régression couverture

Communiquer Dette aux Stakeholders

Traduction Langage Business

Technique → Impact Business

"API est dépréciée"
→ "Risque sécurité: pas de patches après janvier"

"Couverture tests est basse"  
→ "Risque release: bugs plus probables en production"

"Architecture est monolithique"
→ "Vitesse livraison: features prennent 3x plus longtemps"

"Dépendances sont obsolètes"
→ "Risque compliance: vulnérabilités connues"

Rapport Burn-down Dette

Rapport Dette Technique Q4

Début Q4: 52 items dette (312 points)
Résolus: 18 items (98 points)
Ajoutés: 7 items (43 points)
Fin Q4: 41 items (257 points)

Réduction Nette: 11 items (55 points) ↓17%

Points forts:
✓ Migration Stripe complétée (critique)
✓ Couverture tests améliorée 15%
⚠ Migration base de données encore en attente

Solutions Connexes

• Gérer code legacy dans projets actifs
• Métriques qualité code et suivi
• Planification sprint avec travail technique