Réécrire ou refactoriser votre produit : la tentation du "on repart de zéro" qui a déjà tué des startups

Un matin, votre lead dev pose la phrase que tout fondateur redoute : « Le code est devenu ingérable, il faut tout réécrire. » L’équipe acquiesce, soulagée à l’idée de repartir sur une base propre. Six mois plus tard, la nouvelle version n’est toujours pas en prod, l’ancienne accumule les bugs que plus personne ne veut corriger, et vos concurrents ont sorti trois features pendant que vous rejouiez votre propre passé.

La réécriture totale — le fameux rewrite from scratch — est l’une des décisions les plus lourdes de conséquences dans la vie d’un produit. Et c’est presque toujours la mauvaise, non pas parce qu’elle est techniquement infaisable, mais parce qu’elle est prise pour de mauvaises raisons, au mauvais moment, sur la base d’une émotion plutôt que d’une analyse.

Pourquoi tout le monde veut réécrire (et pourquoi c’est un piège)

Le désir de réécrire naît rarement d’un calcul froid. Il naît d’une frustration. Le code existant a été écrit vite, sous pression, par des gens qui apprenaient le domaine en même temps qu’ils le codaient. Il porte les cicatrices de tous les pivots, de tous les « on verra plus tard », de tous les hacks qui ont permis de signer un client. Le lire, c’est déprimant. Le modifier, c’est risqué. Alors l’idée de la page blanche devient irrésistible.

Le problème, c’est que ce code moche contient quelque chose que la nouvelle version n’aura pas : des années de connaissance métier implicite. Chaque if bizarre, chaque cas particulier apparemment absurde, correspond souvent à un bug réel rencontré en production, à une exigence d’un gros client, à une règle réglementaire découverte à la dure. Joel Spolsky l’écrivait déjà il y a vingt ans, et ça reste vrai : réécrire de zéro, c’est jeter cette connaissance et s’engager à la réapprendre entièrement, un bug à la fois.

Pour une startup, l’addition est brutale. Pendant que vous réécrivez, vous devez continuer à maintenir l’ancien système — sinon vos clients partent. Vous payez donc deux fois : une équipe qui construit le futur, une équipe (ou les mêmes personnes, épuisées) qui rustine le présent. Votre roadmap produit est gelée. Vos commerciaux n’ont rien de nouveau à vendre. Et le jour du basculement, vous découvrez que la nouvelle version ne fait pas tout à fait ce que faisait l’ancienne — il manque toujours ces 5 % de fonctionnalités que personne n’avait documentées.

La vraie question n’est pas « le code est-il moche »

Un code moche n’est pas une raison de réécrire. Un code moche qui ralentit chaque livraison, qui multiplie les incidents, qui fait fuir les développeurs et qui vous empêche de tenir vos promesses commerciales — ça, c’est un problème business. La distinction est cruciale, parce qu’elle change complètement l’arbitrage.

Posez-vous les bonnes questions. Est-ce que la dette technique vous coûte réellement en vélocité mesurable, ou est-ce juste inconfortable ? Combien de temps votre équipe passe-t-elle à corriger des régressions par rapport à construire ? Un incident de production sur deux vient-il toujours du même module ? Si vous ne pouvez pas répondre avec des chiffres, vous êtes en train de justifier une décision émotionnelle a posteriori.

Il y a aussi une question de cause. Beaucoup d’équipes veulent réécrire parce qu’elles ont fait un mauvais choix de stack initial — un framework no-code qui ne scale plus, une base de données mal modélisée, un monolithe devenu ingérable. Mais le plus souvent, ce n’est pas la stack le problème : c’est l’absence de frontières claires dans le code, l’accumulation de logique métier dispersée, le manque de tests qui rend tout changement effrayant. Réécrire avec les mêmes pratiques vous ramènera au même endroit en dix-huit mois. Vous n’aurez pas soldé la dette, vous l’aurez juste rembrassée à taux neuf.

Le refactoring progressif, ou l’art de réparer l’avion en vol

L’alternative sérieuse au rewrite s’appelle le refactoring incrémental, et sa version la plus robuste porte un nom : le Strangler Fig Pattern, popularisé par Martin Fowler. L’idée est simple et redoutablement efficace. Plutôt que de tout reconstruire à côté puis de basculer d’un coup — le fameux big bang qui n’atterrit jamais —, vous étranglez progressivement l’ancien système. Vous identifiez un module, vous le réécrivez proprement derrière une même interface, vous le mettez en prod, vous mesurez, puis vous passez au suivant.

L’avantage est décisif pour une startup : vous livrez de la valeur en continu. Chaque morceau réécrit est en production, testé par de vrais utilisateurs, générateur de feedback immédiat. Votre roadmap n’est jamais totalement gelée. Vous pouvez arrêter à tout moment si les priorités business changent — et en startup, elles changent tout le temps. Vous ne pariez pas six mois de runway sur un basculement qui, statistiquement, dérapera.

Concrètement, ça commence par mettre le système existant sous filet de sécurité : ajouter des tests de caractérisation autour des parties que vous voulez toucher, même moches, pour figer leur comportement actuel avant de le modifier. Ensuite vous isolez les frontières — souvent en introduisant une couche d’abstraction qui vous laisse remplacer l’implémentation sans casser les appelants. Puis vous attaquez d’abord ce qui vous fait le plus mal : le module qui génère 40 % de vos incidents, pas celui qui est le plus laid mais qui n’a pas bougé depuis deux ans et ne casse jamais. La dette qui dort tranquillement n’est pas prioritaire, quoi qu’en dise votre instinct d’esthète.

Les rares cas où réécrire est le bon choix

Soyons honnêtes : il existe des situations où la réécriture est justifiée. Quand la technologie sous-jacente est réellement en fin de vie — un langage ou un framework non maintenu, une faille de sécurité structurelle impossible à corriger sans refonte. Quand la stack initiale a été choisie pour valider une hypothèse (un prototype no-code, un MVP monté en deux semaines) et qu’elle a rempli son rôle : là, réécrire n’est pas jeter de la connaissance, c’est diplômer d’une phase à l’autre, avec un ICP désormais validé et des besoins clairs.

C’est aussi parfois défendable quand le périmètre est petit et bien compris. Réécrire un microservice de 3 000 lignes dont vous maîtrisez chaque comportement, ce n’est pas le même pari que réécrire un monolithe de 200 000 lignes truffé de règles métier oubliées. Plus le système est petit et documenté, plus le rewrite devient une option raisonnable plutôt qu’un saut dans le vide.

Enfin, le stade compte. Une startup pre-seed avec dix utilisateurs et un prototype peut légitimement tout jeter : elle n’a presque rien à préserver, la connaissance métier tient dans la tête des deux fondateurs, et le coût d’opportunité d’un gel de roadmap est faible puisqu’il n’y a pas encore de traction à protéger. La même décision en série A, avec des centaines de clients payants et des engagements contractuels, relève de la roulette russe. Ce qui est prudent à un stade est suicidaire à un autre.

Ce qu’il faut vraiment faire

Avant toute chose, refusez de trancher à chaud. La demande de réécriture arrive souvent après un incident douloureux ou un sprint frustrant — le pire moment pour engager six mois de runway. Laissez retomber, puis exigez des chiffres : temps passé en maintenance corrective, fréquence des incidents par module, vélocité réelle sur les derniers trimestres. Une décision de cette ampleur mérite un mini business case, pas un vote émotionnel en rétrospective.

Ensuite, faites l’hypothèse du refactoring progressif par défaut. Le rewrite doit prouver qu’il est nécessaire, pas l’inverse. Découpez le système, mettez en place le filet de tests, et attaquez le module qui vous coûte le plus cher en argent réel — incidents, churn, deals bloqués. Vous serez souvent surpris de constater qu’en assainissant 20 % du code, vous réglez 80 % de la douleur, sans jamais avoir gelé votre roadmap.

Et si vous concluez malgré tout qu’il faut réécrire, imposez-vous des garde-fous : un périmètre borné, un basculement par tranches et non en big bang, une équipe qui n’a pas aussi la charge de maintenir l’ancien à bout de bras, et une date de réévaluation. Si au bout de deux mois la nouvelle version ne remplace pas déjà un morceau réel de production, vous êtes probablement en train de reconstruire un cimetière plus propre.

Le vrai coût n’est pas technique, il est stratégique

La question « réécrire ou refactoriser » a l’air d’un débat d’ingénieurs. C’est en réalité une décision de dirigeant, parce qu’elle arbitre entre du temps de développement consacré à votre passé et du temps consacré à votre futur. Chaque semaine passée à reconstruire ce qui existe déjà est une semaine non passée à conquérir un marché, à répondre à un besoin client, à creuser votre avantage. Dans un environnement où le runway se compte en mois, c’est peut-être l’arbitrage le plus stratégique que vous prendrez cette année.

Alors avant d’approuver le grand chantier, posez-vous la seule question qui compte vraiment : dans dix-huit mois, qu’est-ce qui aura le plus fait avancer votre entreprise — un code plus élégant, ou un produit que vos clients n’auraient jamais lâché ? La réponse n’est pas toujours celle que votre instinct d’ingénieur souhaiterait entendre.