Refactor ou rewrite : comment décider ?

Votre MVP tourne, les premiers clients sont là, mais chaque évolution devient plus lente que prévu. Une fonctionnalité simple prend deux semaines. Un bug corrigé en crée un autre. L'équipe commence à parler de réécrire l'application "proprement". Sur le papier, c'est séduisant : repartir de zéro, effacer les choix faits dans l'urgence, retrouver de la vitesse. Dans les faits, c'est souvent le moment où une startup brûle six mois de roadmap pour résoudre un problème mal cadré.

Réécrire rassure. Refactorer rapporte souvent plus vite.

Le sujet n'est donc pas de choisir entre code propre et code sale. Le sujet, c'est de savoir quel risque vous essayez vraiment de réduire.

Les symptômes qui donnent envie de tout réécrire

Le besoin de rewrite arrive rarement par surprise. Il s'installe par accumulation.

Au début, l'équipe compense. Elle connaît les fichiers dangereux, les modules à ne pas toucher un vendredi, les raccourcis pris pour signer le premier client. Tant que l'équipe est petite, cette mémoire informelle suffit. Puis le produit grandit, les anciens choix remontent à la surface et chaque nouvelle demande devient une négociation avec le passé.

Les signaux sont assez faciles à reconnaître :

• une fonctionnalité estimée à deux jours en prend dix ;
• les bugs reviennent toujours dans les mêmes zones ;
• les développeurs refusent de modifier certains modules sans "tout revoir" ;
• l'onboarding d'un nouveau profil senior prend plusieurs semaines ;
• les tests, quand ils existent, ne donnent plus confiance ;
• la roadmap produit est ralentie par des sujets que personne côté business ne voit.

À ce stade, la phrase "il faudrait tout réécrire" devient tentante. Elle donne une explication simple à une douleur diffuse. Le problème, c'est qu'elle mélange souvent trois réalités différentes : une dette technique localisée, une architecture devenue insuffisante, ou une équipe qui ne comprend plus vraiment le produit.

Ces trois problèmes ne se traitent pas de la même manière.

Une dette localisée se refactore. Une architecture incompatible avec le business peut justifier une refonte. Une perte de compréhension demande d'abord de la documentation, des tests et du découpage. Si vous confondez les trois, vous risquez de choisir le chantier le plus cher par défaut.

J'ai vu des équipes vouloir réécrire une application entière parce que le module de facturation était devenu ingérable. Le vrai problème tenait dans 12% du code. Réécrire les 88% restants n'aurait pas créé de valeur. Ça aurait juste déplacé le risque.

Quand un rewrite est vraiment justifié

Un rewrite complet n'est pas toujours une erreur. Parfois, c'est même la décision la plus saine.

Le cas le plus clair : le produit actuel ne correspond plus au produit que vous vendez. Votre MVP validait une hypothèse. Votre SaaS vend maintenant du multi-tenant, des permissions fines, des intégrations critiques ou des exigences de conformité qui n'existaient pas au départ. Si les fondations empêchent structurellement ces usages, le refactor peut devenir une suite de contorsions.

Un rewrite peut aussi se défendre quand la technologie bloque la reprise. Pas parce qu'elle n'est plus à la mode, mais parce qu'elle vous empêche de recruter, de maintenir ou de sécuriser le produit. Une stack exotique tenue par un seul développeur parti depuis six mois n'est pas un choix technique neutre. C'est un risque opérationnel.

Autre cas : le coût de compatibilité dépasse le coût de reconstruction. Si chaque correction oblige à préserver des comportements historiques que personne n'utilise, vous entretenez un musée. Là, réécrire une partie du produit avec des règles métier clarifiées peut coûter moins cher que continuer à patcher.

Mais un rewrite doit répondre à une question précise :

Quel risque disparaît quand la nouvelle version est en production ?

Si la réponse est "on aura une base plus propre", c'est trop vague. Si la réponse est "on pourra isoler les comptes clients, passer une due diligence technique, recruter sur une stack standard et livrer les intégrations demandées par nos trois plus gros prospects", la discussion devient sérieuse.

Réécrire une application n'est pas une opération de ménage. C'est un investissement produit. Il doit avoir un périmètre, un coût d'opportunité et une date de retour visible.

Quand le refactor gagne

Dans beaucoup de startups, le refactor est moins spectaculaire, mais plus rentable.

Il gagne quand le produit fonctionne, que les clients paient, et que la douleur se concentre dans quelques zones. Vous n'avez pas besoin d'une nouvelle application. Vous avez besoin de rendre certaines parties moins chères à faire évoluer.

C'est le lien direct avec la gestion de la dette technique : il ne s'agit pas de nettoyer tout le code. Il s'agit d'identifier les modules qui ralentissent vraiment l'équipe et de les traiter dans l'ordre.

Le refactor gagne aussi quand le risque business d'une double vie produit est trop élevé. Pendant un rewrite, vous devez souvent maintenir l'ancien produit, construire le nouveau, synchroniser les données et expliquer aux clients pourquoi certaines évolutions attendent. Pour une petite équipe, c'est lourd. Très lourd.

Un refactor progressif permet de garder le produit vivant. Vous améliorez une zone, vous mesurez l'effet, puis vous passez à la suivante. Le client ne voit pas forcément le chantier, mais il ressent moins de bugs, des livraisons plus régulières et une équipe moins crispée.

Le bon refactor a trois caractéristiques :

• il cible une zone qui ralentit réellement la roadmap ;
• il améliore un flux métier concret, pas une abstraction théorique ;
• il peut être livré sans immobiliser toute l'équipe.

Par exemple, refactorer le système de permissions avant de vendre à des comptes entreprise peut être une vraie décision business. Refactorer tous les noms de dossiers parce qu'ils ne plaisent plus à l'équipe, beaucoup moins.

La qualité logicielle n'est pas une quête esthétique. Elle sert à garder le produit modifiable. Si le refactor ne rend rien plus rapide, plus sûr ou plus transmissible, il mérite d'être challengé.

La matrice risque, coût, délai

Pour trancher, j'utilise une matrice simple. Pas besoin d'un audit de 80 pages pour commencer.

Regardez chaque option selon quatre critères.

Le premier critère, c'est le risque produit. Que se passe-t-il pour vos clients pendant le chantier ? Un rewrite qui bloque les évolutions pendant six mois coûte cher si vous êtes en train de signer vos premiers grands comptes. Un refactor mal isolé peut aussi créer des régressions si vous touchez au coeur du produit sans tests.

Le deuxième critère, c'est le coût d'opportunité. Pendant que l'équipe réécrit, elle ne livre pas autre chose. Cette phrase paraît évidente, mais elle est souvent oubliée au moment de décider. Six mois de rewrite, c'est aussi six mois de features non livrées, de feedback non intégré et parfois de prospects refroidis.

Le troisième critère, c'est le délai avant valeur. Un refactor bien ciblé peut produire un gain en quelques semaines : une zone moins fragile, un onboarding plus simple, une feature enfin débloquée. Un rewrite complet reporte souvent la valeur à la fin du tunnel. Plus le tunnel est long, plus le risque augmente.

Le quatrième critère, c'est la réversibilité. Pouvez-vous arrêter le chantier si le contexte change ? Un refactor par module est souvent réversible. Un rewrite qui remplace toute l'application l'est beaucoup moins.

Une règle pratique :

• si la douleur est localisée, commencez par refactorer ;
• si les fondations bloquent le business cible, envisagez une réécriture partielle ;
• si l'équipe ne sait pas expliquer où est le problème, commencez par un diagnostic ;
• si le rewrite n'a pas de jalon livrable en moins de six semaines, redécoupez.

Le pire choix, c'est le rewrite flou : gros budget, promesse de propreté, pas de périmètre stable, pas de livraison intermédiaire. C'est là que les startups perdent le plus.

Comment sécuriser une transition progressive

La meilleure décision n'est pas toujours "refactor" ou "rewrite". Très souvent, c'est une transition progressive.

Vous isolez d'abord le domaine qui coûte le plus cher : facturation, permissions, catalogue, synchronisation, moteur de recherche, reporting. Puis vous posez une frontière claire autour de cette zone. L'objectif est de pouvoir l'améliorer sans réécrire le reste.

Ensuite, vous ajoutez les filets de sécurité qui manquent. Des tests sur les flux critiques. Des logs pour comprendre les erreurs. Une documentation courte sur les règles métier. Pas une encyclopédie. Juste ce qu'il faut pour qu'un développeur puisse modifier le module sans deviner.

Enfin, vous migrez par étapes. Une route, un écran, un usage client ou un segment de données à la fois. C'est moins grisant qu'un grand lancement de V2, mais c'est plus facile à piloter.

Cette approche marche bien pour une équipe SaaS post-MVP parce qu'elle respecte la réalité du business. Les clients continuent d'utiliser le produit. La roadmap continue d'avancer. L'équipe réduit la dette au lieu de disparaître dans un chantier invisible.

C'est aussi le genre de sujet à cadrer avant de lancer un devis de refonte. Dans mon accompagnement en développement SaaS freelance, la première étape consiste souvent à séparer ce qui doit être reconstruit, ce qui doit être refactoré et ce qu'il faut simplement laisser tranquille.

Un bon cadrage évite deux erreurs symétriques : réécrire par fatigue, ou refuser de réécrire alors que le produit a changé de nature.

Ce qu'il faut retenir

• Un rewrite se justifie quand les fondations actuelles bloquent le produit cible, la reprise ou un risque business clair.
• Un refactor gagne quand la douleur est localisée et que le produit doit continuer à évoluer pendant le chantier.
• La bonne décision se prend avec une matrice simple : risque produit, coût d'opportunité, délai avant valeur, réversibilité.
• Avant de réécrire, exigez un périmètre, des jalons livrables et une réponse claire à la question : quel risque disparaît ?

Questions fréquentes

Quand faut-il réécrire une application ?

Il faut envisager de réécrire une application quand les fondations empêchent le produit de servir son marché actuel : architecture incompatible, stack impossible à reprendre, contraintes de sécurité ou de scalabilité impossibles à traiter proprement. Si le problème se limite à quelques modules douloureux, un refactor ciblé est souvent plus rationnel.

Comment savoir si un refactor suffit ?

Un refactor suffit si vous pouvez nommer les zones qui ralentissent l'équipe et les améliorer sans reconstruire tout le produit. Le bon test : est-ce qu'un chantier de quelques semaines peut débloquer une partie visible de la roadmap ? Si oui, commencez là plutôt que de lancer une V2 complète.

Combien de temps prévoir pour refactorer un MVP ?

Pour un MVP en production, prévoyez souvent quelques semaines par zone critique, pas un grand chantier indéfini. Le plus sain est d'allouer une capacité régulière au refactor, puis de traiter en priorité les modules qui ralentissent les ventes, l'onboarding ou les évolutions produit.

Conclusion

Refactor ou rewrite n'est pas une question de préférence technique. C'est une décision de risque.

Réécrire peut être courageux quand le produit a changé de nature. Mais réécrire par frustration est dangereux. On croit acheter de la vitesse, on achète parfois une longue période sans valeur livrée.

Avant de lancer une refonte, forcez la décision à devenir concrète : quelles zones posent problème, combien elles coûtent, quel risque elles créent, et quelle livraison intermédiaire prouvera que le chantier avance.

Si vous hésitez entre refactorer, réécrire ou isoler une partie de votre SaaS, on peut cartographier les risques en 30 minutes avant de brûler plusieurs mois de roadmap. Réservez un échange ici.