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

Situation réelle

“On doit refactoriser tout le code !” Cette injonction revient régulièrement dans les équipes techniques. Elle traduit souvent une frustration légitime face à un code qui ralentit le développement, mais elle masque une question plus fondamentale : qu’est-ce qui est vraiment de la dette technique, et qu’est-ce qui est simplement du code qu’on n’aime pas ?

Ce que j’ai observé : la dette technique est souvent utilisée comme argument pour justifier des refactorisations massives, alors qu’elle devrait être un outil de décision stratégique. Le vrai défi n’est pas d’éliminer toute dette, mais de comprendre quand elle devient un problème réel et comment la gérer sans paralyser l’innovation.

Le faux problème

Le faux problème serait de croire que toute dette technique est mauvaise et doit être éliminée. En réalité, la dette technique peut être intentionnelle et stratégique : ship un MVP rapidement pour valider un marché, puis rembourser la dette une fois la validation obtenue. Cette dette-là n’est pas un problème, c’est un choix conscient.

Un autre faux problème : confondre dette technique et code qu’on n’aime pas. “J’aime pas ce framework” ou “Ce code n’est pas assez élégant” ne sont pas de la dette technique. La dette technique, c’est l’écart entre l’architecture actuelle et l’architecture idéale pour répondre aux besoins futurs. Si un monolithe ralentit réellement le développement de nouvelles features, c’est de la dette. Si vous préférez simplement une autre architecture, ce n’est pas de la dette.

Le vrai enjeu CTO

Le vrai enjeu est triple :

Distinguer dette stratégique et dette accidentelle : La dette stratégique est intentionnelle, documentée, avec un plan de remboursement. La dette accidentelle s’accumule silencieusement : turnover qui fait perdre le contexte, manque d’expertise dans l’équipe, requirements qui changent, technologies qui évoluent. Cette dette-là nécessite un audit régulier et une gestion proactive.

Équilibrer innovation et maintenance : Si vous consacrez 100% de votre temps aux features, la dette s’accumule et finit par bloquer l’innovation. Si vous consacrez 50% de votre temps à rembourser la dette, le business se frustre. L’équilibre est délicat et dépend du contexte.

Communiquer la valeur de la dette technique au business : Le CEO veut des features, pas des refactorisations. Si vous ne savez pas expliquer pourquoi rembourser la dette technique est nécessaire pour le business, vous n’obtiendrez jamais le budget. La communication doit être en termes d’impact business, pas en termes techniques.

Cadre de décision

Voici les principes qui m’ont aidé à naviguer cette question :

1. Mesurer avant de décider
Avant de qualifier quelque chose de dette technique, mesurer son impact réel. Code complexity élevée ? Test coverage faible ? Build time qui explose ? Bug rate qui augmente ? Ces métriques objectives permettent de distinguer la vraie dette de la préférence esthétique. Sans mesure, vous risquez de traiter des symptômes plutôt que des causes.

2. Prioriser selon Impact × Effort
Toutes les dettes ne se valent pas. Une dette à fort impact business et faible effort doit être traitée immédiatement. Une dette à fort impact mais fort effort doit être planifiée. Une dette à faible impact et fort effort peut être ignorée. Ce cadre simple évite de se disperser sur des refactorisations qui n’apportent pas de valeur.

3. Allouer 20% de capacité à la dette technique
Une règle empirique : 70% de capacité pour les features produit, 20% pour la dette technique, 10% pour l’innovation/R&D. Cette répartition n’est pas une vérité absolue, mais un point de départ. Si vous êtes à 0% de dette technique, vous accumulez des problèmes futurs. Si vous êtes à 50%, le business se frustre. Ajustez selon votre contexte.

4. Communiquer en termes d’impact business
Quand vous demandez du budget pour rembourser la dette, ne parlez pas de “code plus clean” ou de “meilleure architecture”. Parlez d’impact mesurable : “Notre monolithe ralentit le développement de 50%. Les features prennent 8 semaines au lieu de 4. Si on extrait 3 services en 3 mois, on revient à 4 semaines par feature. ROI : 6 mois après, on livre 2× plus.” Le business comprend les chiffres, pas les détails techniques.

5. Choisir la bonne stratégie de remboursement
Trois approches possibles : Big Bang Rewrite (tout refaire d’un coup, risqué, taux de succès faible), Strangler Fig (remplacer progressivement, plus sûr, taux de succès élevé), Boy Scout Rule (améliorer progressivement à chaque feature, effort continu). Le choix dépend de l’urgence, du risque acceptable, et de la capacité de l’équipe.

Retour terrain

Ce que j’ai observé dans différentes organisations :

Ce qui fonctionne : Traiter la dette technique comme un investissement, pas comme un coût. Présenter un business case clair avec ROI mesurable. Allouer une capacité continue (20%) plutôt que des sprints dédiés qui bloquent le business. Mesurer régulièrement pour ajuster les priorités.

Ce qui bloque : Arriver avec “on doit refactoriser” sans expliquer pourquoi c’est nécessaire pour le business. Consacrer trop ou trop peu de temps à la dette. Traiter toutes les dettes de la même manière sans priorisation. Ignorer complètement la dette jusqu’à ce qu’elle devienne critique.

Les erreurs de communication : Parler technique au CEO (“on doit refactoriser le monolithe”) plutôt que business (“notre architecture ralentit le développement de 50%”). Ne pas quantifier l’impact. Ne pas proposer de plan de remboursement avec ROI. Résultat : la dette est ignorée jusqu’à ce qu’elle devienne une crise.

Les stratégies de remboursement : Le Big Bang Rewrite a un taux de succès faible (environ 20%) car il bloque le business pendant 12-24 mois. Le Strangler Fig a un taux de succès élevé (environ 80%) car il permet de continuer à livrer de la valeur pendant la migration. La Boy Scout Rule est la plus durable car elle intègre l’amélioration continue dans le workflow normal.

Erreurs fréquentes

Traiter toute dette de la même manière
Ne pas distinguer dette stratégique (intentionnelle, documentée) et dette accidentelle (accumulée silencieusement). La première peut être acceptable si elle a un plan de remboursement. La seconde nécessite une action immédiate.

Ignorer complètement la dette
Consacrer 100% du temps aux features. Résultat : la dette s’accumule, la vélocité ralentit, les bugs augmentent, l’équipe se frustre, le turnover augmente, et vous finissez par devoir faire un rewrite forcé qui coûte beaucoup plus cher.

Refactoriser parfaitement
Vouloir tout refactoriser parfaitement plutôt que d’améliorer les zones critiques (règle 80/20). Résultat : 12 mois sans valeur business, CEO frustré, équipe démoralisée. Mieux vaut améliorer progressivement les zones qui ont le plus d’impact.

Tech debt sprints dédiés
Bloquer le business pendant 2 semaines tous les 3 mois pour traiter la dette. Résultat : patterns pas changés, dette qui revient, frustration du business. Mieux vaut une capacité continue (20%) qui intègre l’amélioration dans le workflow normal.

Ne pas mesurer
Traiter la dette sans métriques objectives. Résultat : vous ne savez pas si vous progressez, vous ne pouvez pas justifier les investissements, vous traitez peut-être les mauvais problèmes. Mesurer permet de prioriser et de communiquer.

Si c’était à refaire

Avec le recul, voici ce que je ferais différemment :

Mesurer dès le début
Mettre en place des métriques de dette technique dès le jour 1 : code complexity, test coverage, dependency freshness, build time, bug rate. Ces métriques permettent de voir les tendances, de prioriser, et de communiquer l’impact au business.

Communiquer régulièrement
Ne pas attendre d’avoir besoin de budget pour parler de dette technique. Présenter régulièrement (mensuellement) un dashboard de santé technique au exec team. Montrer les tendances, expliquer les risques, proposer des actions. Cette communication continue évite les surprises et facilite l’obtention de budget quand nécessaire.

Intégrer la dette dans le planning
Plutôt que de traiter la dette comme quelque chose de séparé, l’intégrer dans le planning normal. Chaque feature peut inclure un peu de remboursement de dette dans la zone touchée (Boy Scout Rule). Cette approche est plus durable que les sprints dédiés.

Documenter les choix
Quand vous prenez une dette stratégique intentionnelle, la documenter explicitement : pourquoi cette dette, quel est le plan de remboursement, quand sera-t-elle remboursée. Cette documentation évite les malentendus futurs et facilite la communication avec le business.

Pour approfondir

Le livre “Être ou ne pas être CTO” inclut des cas réels de gestion de dette technique, avec des exemples concrets de migrations réussies et d’erreurs à éviter.

Pour approfondir, tu peux aussi consulter les pages piliers du site ou les guides mis à disposition.