Stratégies du livre “Être ou ne pas être CTO”, chapitre “Gérer la dette technique”.

“On doit refactoriser tout le code !” Non. Voici comment gérer tech debt sans paralyser business.

Comprendre la dette technique

Définition réaliste

Tech debt ≠ Code moche

Tech debt =
  Écart entre architecture actuelle
  et architecture idéale pour besoins futurs

Exemples :
✅ Monolithe qui ralentit features → Dette
✅ Tests manquants sur code critique → Dette
✅ Dépendances EOL avec risque sécu → Dette

❌ "J'aime pas ce framework" → Pas dette
❌ "Code pas assez elegant" → Pas dette

Types de dette

Dette stratégique (intentionnelle) :

Exemple :
"On ship MVP en 2 semaines avec quick & dirty
 pour valider marché.

 On sait qu'on devra refacto après."

✅ Acceptable si :
- Conscient et documenté
- Deadline business critique
- Plan remboursement existe

Dette accidentelle (subie) :

Causes :
- Turnover (context perdu)
- Manque expertise (junior team)
- Requirements changés
- Tech evoluée (framework deprecated)

❌ S'accumule silencieusement
→ Nécessite audit régulier

Mesurer la dette

Métriques objectives

1. Code complexity (Cyclomatic)
   Tool : SonarQube, CodeClimate
   Red flag : >15 complexity

2. Test coverage
   Target : 70-80% sur code critique
   Red flag : <40%

3. Dependency freshness
   Tool : Dependabot, Renovate
   Red flag : Deps >2 ans, EOL, CVE

4. Build/Deploy time
   Red flag : >15min build, >1h deploy

5. Bug rate
   Red flag : >10% features avec bugs production

Inventaire dette (template)

Debt Item: Monolithe ralentit features
Category: Architecture
Impact: High (blocks 30% roadmap)
Effort: 6 mois, 3 devs
Risk if ignored: Team velocity -50%
Priority: High
Plan: Extract 3 services Q1 2025

---

Debt Item: Tests coverage 20%
Category: Quality
Impact: Medium (bugs production)
Effort: 3 mois, 1 dev
Risk: Customer churn
Priority: Medium
Plan: 40% → 70% Q2 2025

Prioriser intelligemment

Framework : Impact × Effort

High Impact, Low Effort : DO NOW
- Fix CI/CD lent (2 semaines)
- Update deps critiques (1 semaine)
- Add monitoring (1 semaine)

High Impact, High Effort : PLAN
- Microservices migration (6 mois)
- Rewrite legacy module (4 mois)
- Multi-region infra (12 mois)

Low Impact, Low Effort : FILL GAPS
- Refactor non-critical code
- Improve logs
- Update docs

Low Impact, High Effort : AVOID
- Rewrite parfait
- Over-engineering
- Tech debt "nice to have"

La règle 70/20/10

Budget temps équipe :

70% : Features produit (business value)
20% : Dette technique (sustainability)
10% : Innovation/R&D (future)

Exemple 10 devs :
- 7 devs features
- 2 devs tech debt
- 1 dev exploration

⚠️ Si 0% tech debt → Accumulation dangereuse
⚠️ Si >30% tech debt → Business frustré

Communiquer avec non-tech

CEO veut features, pas refacto

❌ Mauvais :

CTO: "On doit refactoriser le monolithe."
CEO: "Ça apporte quoi au business ?"
CTO: "C'est technique, code plus clean."
CEO: "Pas prioritaire."

→ Tech debt ignorée
→ Crise 6 mois après

✅ Bon :

CTO: "Notre monolithe ralentit delivery features 50%.

      Features prennent 8 semaines au lieu de 4.

      Si on extrait 3 services (3 mois),
      on revient à 4 semaines par feature.

      ROI : 6 mois après refacto, on livre 2× plus."

CEO: "OK, go."

→ Business case clair
→ Budget approuvé

Template communication

Problème :
[Impact business mesurable]

Cause technique :
[Explication simple]

Solution :
[Investment temps/cost]

Bénéfice :
[ROI chiffré]

Risque si ignoré :
[Conséquences business]

Stratégies de remboursement

Approche 1 : Big Bang Rewrite

Quand :
- Legacy complètement unmaintainable
- Business model pivot complet
- Tech stack obsolète totale

Risque :
❌ 12-24 mois sans features
❌ Team frustration
❌ Bugs migration massive

Success rate : 20%

→ À éviter sauf cas extrême

Approche 2 : Strangler Fig (recommandé)

Principe :
Remplacer progressivement ancien par nouveau

Exemple microservices :
1. Identifier service à extraire (Auth)
2. Créer nouveau service
3. Router traffic progressivement
4. Monitorer + rollback possible
5. Deprecate ancien code

Timeline : 3-6 mois par service
Success rate : 80%

→ Business value continue
→ Risque limité

Approche 3 : Boy Scout Rule

"Leave code better than you found it"

Chaque feature = mini refacto zone touchée

Exemple :
Feature dans module legacy
→ Ajouter tests sur fichiers modifiés
→ Refacto fonction touchée
→ Update deps si possible

Effort : +10-15% par feature
Impact : Dette réduite progressivement

→ Pas de "tech debt sprint" dédié
→ Amélioration continue

Pièges à éviter

Piège 1 : Perfect is enemy of good

❌ "On refactorise tout parfaitement"
→ 12 mois, 0 business value
→ CEO furious

✅ "On améliore zone critique 80/20"
→ 2 mois, impact mesuré
→ CEO content

Piège 2 : Tech debt sprint

❌ "Sprint dédié tech debt tous les 3 mois"
→ Business bloqué 2 semaines
→ Patterns pas changés
→ Dette revient

✅ 20% capacity continue
→ Sustainable
→ Pas de disruption

Piège 3 : Ignorer complètement

❌ "100% features, 0% tech debt"
→ Velocity ralentit
→ Bugs augmentent
→ Devs frustré → Turnover
→ Crise forced rewrite

✅ Balance 70/20/10
→ Sustainable long-terme

Prévenir l’accumulation

Standards et guidelines

1. Code review obligatoire
   - 2 approvals minimum
   - Checklist (tests, docs, etc.)

2. Definition of Done
   - Tests passent
   - Coverage >70%
   - Docs à jour
   - No new warnings

3. Architecture Decision Records
   - Documenter choix tech
   - Rationale explicite
   - Facilite maintenance future

Monitoring continu

Dashboard tech health :

✅ Test coverage : 78% (target 75%)
✅ Build time : 8min (target <10min)
⚠️ Dependencies : 3 outdated (update Q1)
❌ Bug rate : 12% (target <8%)

→ Review mensuel avec exec
→ Ajuster priorities

Conclusion

Dette technique = Outil stratégique, pas tabou

Acceptable quand :

  • Intentionnelle et documentée
  • Plan remboursement existe
  • ROI business justifie

Dangereuse quand :

  • Ignorée et accumulée
  • Pas mesurée
  • Bloque innovation

Règle d’or : 70% features / 20% tech debt / 10% innovation

“Être ou ne pas être CTO” inclut templates d’inventaire dette, frameworks de priorisation, et cas réels de migrations réussies.