Comment créer un programme de refactoring approuvé par le business
Comment créer un programme de refactoring approuvé par le business
Il y a quelques années, j'accompagnais le CTO d'une société de gestion d'épargne, avec une équipe de 20 développeurs. Il venait de se faire refuser pour la troisième fois un programme de refactoring sur leur module de calcul de rendement. Sa présentation était techniquement parfaite : complexité cyclomatique, taux de duplication, nombre de hotspots SonarQube. Le CPO l'avait écouté poliment puis avait dit : "Je comprends que c'est important pour toi, mais on a la roadmap à tenir." Ce n'était pas un refus du business face à la technique. C'était un professionnel qui ne voyait pas son problème dans ce que l'autre lui présentait.
"On a besoin de 3 mois pour refactoriser le core." Réponse du CPO : "Pas maintenant, on a la roadmap feature à tenir." Cette conversation se joue dans 80% des entreprises tech. Et dans 80% des cas, c'est l'équipe technique qui présente mal, pas le business qui refuse mal.
Le business ne comprend pas "refactoring". Il comprend "coût", "risque", "délai", et "avantage concurrentiel". Tant que vous présentez un projet technique dans un langage technique, vous demandez au business de vous faire confiance sur un sujet qu'il ne maîtrise pas. Ce n'est pas raisonnable, et ce n'est pas sa faute.
Avant de commencer : les prérequis
- Vous avez identifié le périmètre du refactoring (module, couche, ou composant spécifique, si ce n'est pas encore fait, commencez par évaluer le risque du code legacy
- Vous avez une estimation grossière de l'effort technique (order of magnitude : semaines, pas jours)
- Vous avez accès aux métriques de base : lead time, taux de bugs, temps passé en maintenance
Étape 1 : Quantifier le coût actuel, pas l'effort de refactoring
Durée estimée : 4 heures Qui : Tech Lead + 1 développeur senior
C'est l'étape que la plupart des équipes sautent. Elles présentent l'effort du refactoring sans jamais quantifier le coût de l'inaction.
Questions à chiffrer :
- Quel pourcentage du temps de l'équipe est consacré à la maintenance de ce module ?
- Combien d'incidents de prod ce module a-t-il causés les 6 derniers mois ?
- Quel est le lead time pour une modification simple dans ce module vs un module sain ?
- Combien de développeurs ont quitté l'équipe en citant "la dette technique" dans leur entretien de sortie ?
Calcul type :
- Équipe de 20 développeurs × 40% d'absorption sur ce module × 450€/jour × 220 jours = 792 000€/an
- 3 incidents P1 × 80 000€ d'impact moyen = 240 000€/an
- Coût total de l'inaction : ~1 000 000€/an
Ce chiffre est le fondement du business case. Sans lui, vous demandez un investissement sans montrer le retour. Avec lui, vous parlez la même langue que votre interlocuteur.
Résultat attendu : un tableur avec les coûts actuels quantifiés, prêt à être présenté.
Étape 2 : Construire le ROI en langage business
Durée estimée : 3 heures Qui : CTO + Tech Lead
Le ROI d'un programme de refactoring a deux composantes :
Composante 1 : Réduction des coûts : si le refactoring réduit l'absorption de 40% à 20%, vous récupérez 50% du coût de l'inaction. Sur l'exemple précédent : 500 000€/an récupérés.
Composante 2 : Accélération business : le lead time divisé par 2 ou 3 signifie que les features arrivent plus vite sur le marché. Chiffrez-le en termes de features livrées par trimestre ou de time-to-market sur vos initiatives stratégiques.
Format de présentation pour le board :
| Scénario actuel | Après refactoring | |
|---|---|---|
| Absorption maintenance | 40% | 20% |
| Lead time moyen | 4 semaines | 2 semaines |
| Incidents P1/an | 6 | 1-2 |
| Coût annuel estimé | 1 000 000€ | 400 000€ |
| Économie annuelle | 600 000€ |
Investissement programme : 200 000€ (3 mois, 4 développeurs). ROI : 3 mois.
Résultat attendu : un slide ou un tableau de 1 page qui montre le ROI clairement.
Votre programme de refactoring est bloqué faute de budget approuvé ?
Vous avez la conviction technique, vous voyez le coût s'accumuler chaque mois, mais vous n'arrivez pas à obtenir le feu vert. Ce n'est pas un problème de légitimité, c'est un problème de présentation. En 30 minutes, je vous aide à construire les chiffres clés et la structure de présentation qui débloque le budget dans votre contexte.
Étape 3 : Proposer un plan en 3 phases avec quick wins
Le business est rassuré par les quick wins. Un programme de 6 mois qui ne livre rien de visible pendant 6 mois est un programme à haut risque perçu.
Structure recommandée en 3 phases :
Phase 1 (4-6 semaines) : Stabilisation et quick wins :
- Objectif : réduire les incidents de prod immédiats
- Livrable visible : réduction du taux d'incidents de 50%
- Investissement : 20% de la capacité de l'équipe
Phase 2 (6-8 semaines) : Refactoring structurel :
- Objectif : réduire l'absorption de la dette
- Livrable visible : le lead time sur le module cible commence à baisser
- Investissement : 30-40% de la capacité
Phase 3 (4-6 semaines) : Consolidation et transfert :
- Objectif : documenter, tester, former l'équipe sur les nouveaux patterns
- Livrable visible : les autres équipes peuvent modifier le module sans accompagnement
- Investissement : 20% de la capacité
L'argument clé : les features continuent de sortir pendant tout le programme. Ce n'est pas un arrêt, c'est une réallocation partielle et temporaire. C'est précisément ce que la théorie des contraintes de Goldratt préconise : traiter le goulot d'étranglement en maintenant le flux global.
Résultat attendu : un plan de 3 phases avec les livrables visibles à chaque étape.
Étape 4 : Le pitch de 10 minutes qui obtient le budget
Structure du pitch :
- L'enjeu (2 min) : "Notre module X nous coûte 1M€/an. Voici les chiffres."
- Le diagnostic (2 min) : "Voici pourquoi il coûte autant et pourquoi ça va empirer."
- La solution (2 min) : "Un programme de 3 mois, 3 phases, qui continue à livrer des features."
- Le ROI (2 min) : "Investissement : 200K€. Économie annuelle : 600K€. Retour en 3 mois."
- La décision demandée (2 min) : "On a besoin de votre feu vert pour allouer 30% de la capacité de l'équipe pendant 3 mois, à partir du date."
Ce qu'il ne faut surtout pas dire : "On a besoin de payer la dette technique." C'est une phrase technique sans signification financière. Remplacez-la par : "On a besoin de réduire notre coût opérationnel de 600K€/an." Ce n'est pas du spin, c'est la même réalité exprimée dans la langue de votre interlocuteur.
Le piège à éviter
Ne promettre jamais une réduction de 100% de la dette. Je promets des améliorations mesurables sur des métriques spécifiques. Un programme qui promet "tout refactoriser" ne sera jamais terminé et perdra la confiance du business. Un programme qui promet "réduire les incidents P1 de 6 à 2 par an sur le module X en 3 mois" est vérifiable et crédible.
En résumé
| Étape | Action | Résultat |
|---|---|---|
| 1 | Quantifier le coût actuel de l'inaction | Chiffres prêts pour le business case |
| 2 | Construire le ROI en langage financier | Slide de ROI en 1 page |
| 3 | Plan en 3 phases avec quick wins visibles | Programme crédible sans arrêt des features |
| 4 | Pitch de 10 minutes structuré | Feu vert et budget alloué |
FAQ sur le business case du refactoring
1. Que faire si le business accepte mais réduit le budget de moitié ?
Ne pas accepter un programme sous-dimensionné qui ne peut pas atteindre ses objectifs. C'est pire qu'un refus : il consomme de la capacité sans produire de résultats, et détruit la crédibilité pour les prochaines demandes. Il vaut mieux replanifier sur un périmètre plus restreint (un module au lieu de trois) avec le budget disponible, et livrer des résultats mesurables avant de demander la suite.
2. Comment mesurer l'impact du programme une fois démarré ?
Je définis les métriques de succès avant de commencer : lead time cible, taux d'incidents cible, absorption de maintenance cible. Je mesure ces métriques à J0, J30, J60, J90. Un tableau de bord visible par le business tous les 15 jours. La transparence sur les progrès maintient le soutien et prévient les remises en question en cours de route.
3. Le business peut-il comprendre les concepts techniques comme la "dette technique" ?
Oui, mais pas dans le vocabulaire technique. L'analogie financière fonctionne très bien : "La dette technique est exactement comme une dette financière. Elle a un principal (le travail à faire pour la rembourser) et des intérêts (le surcoût de travail que vous payez chaque jour parce qu'elle existe). Nous payons actuellement 1M€/an d'intérêts. Ce programme rembourse une partie du principal et réduit les intérêts de 60%."
4. Comment gérer la pression de maintenir la roadmap feature pendant le programme ?
Je négocie explicitement le "budget technique" avant de commencer : X% de la capacité de l'équipe est allouée au programme pendant Y semaines. Ce n'est pas du temps volé aux features, c'est un investissement planifié. Je présente chaque sprint les features livrées ET l'avancement du programme. La co-existence est possible à condition que les règles soient claires dès le départ.
Ressource gratuite : Engineering Maturity Self-Assessment
L'assessment inclut une section dédiée à la gestion de la dette technique et vous aide à quantifier votre niveau d'absorption actuel : le premier chiffre dont vous avez besoin pour votre business case.
