📖 Manuel

Technical Debt Manager

1. Inventaire — recensement des sources

Commencer par une collecte structurée. Sources classiques :

Commandes utiles pour l'inventaire rapide :

# Dépendances obsolètes Node
npx npm-check-updates --format group

# Audit de sécurité npm
npm audit --json | jq '.vulnerabilities | to_entries[] | select(.value.severity=="critical")'

# Complexité cyclomatique Python
radon cc src/ -s -n C   # affiche les fonctions complexité >= C

# Duplication de code
jscpd --min-lines 10 --reporters json src/

# .NET : packages obsolètes
dotnet list package --outdated --format json

# Couverture de tests .NET
dotnet test --collect:"XPlat Code Coverage" && reportgenerator -reports:coverage.xml -targetdir:report

2. Classification — Quadrant de Fowler

Positionner chaque élément sur deux axes :

                    PRUDENT              IMPRUDENT
DÉLIBÉRÉ    "On sait qu'on doit     "On déploie vite,
             refacto plus tard"      on verra après"
             → OK si tracé (ADR)     → Éviter

INADVERTANT "On a appris un         "On ne savait pas
             meilleur pattern         qu'on faisait mal"
             depuis"                 → Former l'équipe
             → Refacto planifiée

Associer à chaque item : type, auteur/équipe, date de création, ADR ou ticket existant.

3. Évaluation de l'impact — score de priorité

Pour chaque élément de dette, noter sur 5 :

• P : probabilité d'incident ou de ralentissement (1=faible, 5=certain)
• I : impact si le problème survient (1=cosmétique, 5=production down)
• C : coût de remboursement (1=< 1 jour, 5=sprint entier)

Score de priorité = (P × I) / C → plus le score est élevé, plus c'est urgent.

Exemple de tableau :

4. Priorisation — critères de décision

Traiter en priorité si :

• La dette ralentit activement une feature en cours (couplage, tests flaky).
• CVE critique ou dépendance EOL dans les 3 mois.
• Score (P×I)/C ≥ 8.
• L'item bloque le recrutement ou la montée en compétence.

Différer si :

• Le module est en voie d'être remplacé (<6 mois).
• Score < 3 et aucun développeur ne touche ce code.
• Le remboursement nécessite un arrêt service non planifiable.

Quick wins à ne jamais rater :

• Mettre à jour une dépendance avec 0 breaking change.
• Ajouter un test sur un bug qu'on vient de corriger.
• Supprimer du code mort (feature flags désactivés, endpoints dépréciés).

5. Stratégies de remboursement

Template ADR pour dette intentionnelle :

## ADR-042 : Workaround authentification JWT

**Statut** : Accepted / To Refactor
**Date** : 2026-06-24
**Contexte** : Deadline J+3, pas le temps d'implémenter le refresh token.
**Décision** : Token valide 24h, session expirée = re-login.
**Conséquences** : UX dégradée. Refacto planifiée sprint S+4.
**Ticket** : PROJ-1234

6. Métriques de suivi (avant/après obligatoire)

Mesurer avant de commencer, après chaque remboursement :

# Couverture de tests (Jest)
jest --coverage --coverageReporters=json-summary
cat coverage/coverage-summary.json | jq '.total.lines.pct'

# Complexité moyenne (Python)
radon mi src/ -s | awk '{sum+=$NF; count++} END {print sum/count}'

# Taille du bundle (webpack)
npx webpack-bundle-analyzer stats.json --mode=json | jq '.assets[].size' | paste -sd+ | bc

KPIs à suivre en dashboard (Jira, ADO, Notion) :

• % couverture de tests (cible : ≥ 70%)
• Nombre de dépendances avec CVE critique (cible : 0)
• Vélocité sprint (avant/après refacto)
• Temps moyen résolution bug (MTTR)
• Score SonarQube / Code Climate GPA
• Nombre de TODO/FIXME en production (grep -r "TODO\|FIXME\|HACK" src/ | wc -l)

7. Communication business

Traduire la dette en langage décisionnel :

• "Ce module prend 3× plus de temps à modifier" → "Chaque feature dans ce périmètre coûte 2 jours de plus."
• "Dépendance EOL fin 2026" → "Risque de 0 patch de sécurité après décembre, exposition CVE permanente."
• "Pas de tests" → "Chaque déploiement est un pari. Incident toutes les N semaines = X heures de prod perdues."

Template slide PO/PM :

Dette actuelle : 12 items → 8 jours/sprint perdus (estimation)
Investissement remboursement : 3 sprints × 1 jour = 3 jours
ROI attendu : -3 jours perdus/sprint à partir de S+3

Garde-fous & anti-patterns

• "On refactore tout d'un coup" : non. Strangler Fig ou par module. Le big bang échoue.
• Refacto sans tests : toujours écrire les tests caractéristiques AVANT de changer le code (Golden Master Testing).
• Planifier sans métriques : impossible de prouver le ROI. Mesurer avant/après systématiquement.
• Cacher la dette au PO : la dette non visible n'est jamais remboursée. La rendre explicite dans le backlog.
• Viser 0 dette : objectif irréaliste et contre-productif. Viser un niveau stable et gérable.
• Refacto = réécriture : préférer l'amélioration incrémentale. Réécrire = risque de régression + perte de connaissance implicite.
• Ignorer la dette de test : c'est souvent la plus coûteuse. Un code non testé = refacto risquée.