Le syndrome du refactoring permanent
Je vais vous dire un truc que personne n’ose dire dans les conférences tech : la majorité des refactorings que vous lancez ne servent à rien.
Pas parce que le code est propre. Il ne l’est pas. Mais parce que vous refactorez les mauvaises choses, au mauvais moment, pour les mauvaises raisons.
En 15 ans de consulting en architecture digitale, j’ai vu des dizaines d’équipes s’enliser dans des “grands refactorings” qui devaient durer 3 mois et qui, 18 mois plus tard, n’étaient toujours pas terminés. Pendant ce temps, les concurrents livraient des features.
Le refactoring est un outil. Pas une religion.
Les 3 mensonges du refactoring
Mensonge n°1 : “On ira plus vite après”
C’est l’argument massue. Et c’est souvent faux. Une étude de Microsoft Research sur des projets internes montre que seulement 38% des grands refactorings ont effectivement accéléré la vélocité dans les 6 mois suivants. Les autres ? Vélocité identique, voire en baisse.
Pourquoi ? Parce que le refactoring introduit de nouveaux bugs, nécessite de re-tester massivement, et que l’équipe perd le contexte métier pendant qu’elle réécrit de la plomberie.
Mensonge n°2 : “Le code actuel est inmaintenable”
Vraiment ? Ou c’est juste que le nouveau dev n’a pas pris le temps de comprendre les choix historiques ?
80% des demandes de refactoring que je vois en audit viennent de développeurs arrivés depuis moins de 6 mois dans l’équipe. Ils ne comprennent pas le code, donc ils veulent le réécrire. C’est humain. Mais c’est rarement la bonne réponse.
Mensonge n°3 : “On va moderniser la stack”
Migrer de Express à Fastify. Passer de REST à GraphQL. Remplacer Redux par Zustand. Ces migrations ont un coût réel et un bénéfice souvent marginal.
Posez-vous la question : quel problème business cette migration résout-elle ? Si la réponse est “aucun directement”, c’est du refactoring cosmétique.
Le framework RICE pour arbitrer un refactoring
Avant de lancer un refactoring, passez-le au crible de ce framework :
- R — Reach : Combien de développeurs sont impactés quotidiennement par le problème ?
- I — Impact : Quel est le coût concret (temps perdu, bugs en prod, incidents) ?
- C — Confidence : À quel point êtes-vous sûrs que le refactoring résoudra le problème ?
- E — Effort : Combien de jours/semaines le refactoring prendra-t-il ?
Score = (R × I × C) / E
Un refactoring avec un score RICE inférieur à 5 ne devrait jamais passer devant une feature business. Point.
Quand refactorer (vraiment)
Il y a 4 situations où le refactoring est non-négociable :
1. Le code bloque une livraison business critique
Vous devez livrer le checkout multi-devises, mais l’architecture du panier est tellement couplée qu’il faut toucher 47 fichiers. Là, oui, refactorez. Mais uniquement la partie qui bloque.
2. Les incidents de production sont récurrents
Si le même module cause des incidents toutes les 2 semaines, le coût de ne pas refactorer dépasse le coût du refactoring. Mesurez-le. Montrez les chiffres au management.
3. L’onboarding des nouveaux devs dépasse 3 mois
Si chaque nouveau développeur met 3 mois avant d’être productif sur un module, c’est un signal fort. Mais attention : la solution n’est pas toujours de réécrire. Parfois, c’est documenter.
4. La sécurité est compromise
Dépendances obsolètes avec des CVE critiques, patterns d’authentification vulnérables, données sensibles en clair. Là, on ne discute pas, on refactore.
La règle des 20% qui change tout
Voici ce que je recommande à toutes les équipes que j’accompagne : 20% du temps de dev maximum consacré au refactoring, intégré dans chaque sprint.
Pas de “sprint de refactoring”. Pas de “trimestre technique”. Du refactoring continu, incrémental, ciblé.
Concrètement :
- Chaque PR peut inclure un petit refactoring du code touché (boy scout rule)
- Un ticket technique max par sprint, priorisé avec le framework RICE
- Jamais de refactoring sans test automatisé qui prouve le problème avant et la solution après
Le refactoring invisible : celui qui rapporte le plus
Les meilleurs refactorings sont ceux que personne ne voit :
- Ajouter des tests sur un module critique non testé
- Extraire une configuration hardcodée en variable d’environnement
- Simplifier une requête SQL qui ralentit une page
- Supprimer du code mort (oui, supprimer du code est un refactoring)
- Renommer une fonction de
processData()àcalculateOrderTotal()
Ces micro-refactorings prennent 30 minutes chacun. Ils ne nécessitent pas de ticket Jira. Et ils améliorent réellement la base de code.
Ce que les équipes matures font différemment
Les équipes les plus performantes que j’observe ont 3 pratiques en commun :
1. Elles mesurent avant de refactorer. Pas de feeling, des métriques. Temps de cycle, taux de bugs par module, temps d’onboarding, couverture de tests.
2. Elles fixent un budget. Le refactoring consomme du temps. Ce temps a un coût. Les équipes matures négocient un budget avec le product management et s’y tiennent.
3. Elles documentent les décisions. Pourquoi ce module est-il structuré ainsi ? Quelles alternatives ont été envisagées ? Un ADR (Architecture Decision Record) de 10 lignes évite 3 semaines de refactoring inutile par le prochain dev qui arrive.
Le mot de la fin
Le meilleur code n’est pas le plus propre. C’est celui qui fonctionne en production, que l’équipe comprend, et qui permet de livrer de la valeur business.
Arrêtez de chercher la perfection technique. Cherchez l’efficacité pragmatique.
Et la prochaine fois qu’un dev vous dit “il faut tout refactorer”, demandez-lui : “Quel problème business ça résout, et combien ça coûte ?”
Si la réponse est floue, vous avez votre réponse.
FAQ
Faut-il dédier des sprints entiers au refactoring ?
Non. Les “sprints techniques” sont un anti-pattern. Ils créent une opposition artificielle entre tech et business. Intégrez le refactoring dans chaque sprint à hauteur de 15-20% du temps disponible. C’est plus durable, plus efficace, et ça maintient l’alignement avec le product management.
Comment convaincre le management qu’un refactoring est nécessaire ?
Avec des chiffres, jamais avec des arguments techniques. Montrez le coût des incidents (en heures perdues et en chiffre d’affaires impacté), le temps d’onboarding des nouveaux devs, ou le nombre de bugs par module. Un graphique vaut mille arguments sur la “qualité du code”.
Le refactoring est-il compatible avec une deadline serrée ?
Paradoxalement, oui, mais uniquement le micro-refactoring ciblé. Si vous devez livrer dans 2 semaines, vous ne lancez pas une migration d’ORM. Mais vous pouvez extraire une méthode, renommer une variable, ou ajouter un test sur le chemin critique. Ces petits gestes accélèrent la livraison au lieu de la ralentir.
Quelle est la différence entre dette technique et code “pas propre” ?
La dette technique a un coût mesurable : bugs récurrents, temps de développement rallongé, incidents en production. Le code “pas propre” est un jugement esthétique. Refactorez la dette technique. Laissez le code “pas propre” tranquille tant qu’il fonctionne et que l’équipe le comprend.