Réécriture complète ou refactoring progressif : le piège du « grand soir technique » qui fige votre startup pendant six mois

Un jour, votre lead dev arrive avec cette phrase : « On ne peut plus rien construire sur ce code, il faut tout réécrire. » Le ton est grave, l’argument technique semble solide, et vous n’avez pas les moyens de le contredire. C’est exactement là que beaucoup de startups prennent la décision qui va les paralyser pour les deux prochains trimestres.

La réécriture complète — le fameux rewrite from scratch — est l’une des tentations les plus dangereuses en startup, précisément parce qu’elle se déguise en décision de bon sens. Refuser de la voir comme un arbitrage business, et pas seulement technique, c’est laisser une équipe geler votre time-to-market pendant six mois pour livrer, au mieux, ce que vous aviez déjà.

Pourquoi le rewrite séduit toujours (et pourquoi c’est un signal, pas une solution)

La demande de réécriture ne sort jamais de nulle part. Elle traduit une souffrance réelle : chaque nouvelle feature prend trois fois plus de temps qu’avant, les bugs reviennent en boucle, personne n’ose toucher à certains modules. L’équipe est épuisée par un code qu’elle subit plus qu’elle ne le maîtrise. À ce stade, tout recommencer sur une base propre paraît libérateur.

Le problème, c’est que ce raisonnement confond la douleur avec sa cause. Le code existant est laid, oui — mais il est aussi le seul endroit où sont encodées des centaines de décisions métier que plus personne ne documente : le cas particulier du client qui paie en fin de mois, la règle de calcul de TVA pour les prestations intracommunautaires, le workaround mis en place un vendredi soir pour débloquer un gros deal. Joel Spolsky écrivait il y a vingt ans que « le vieux code n’est pas rouillé, il est éprouvé ». Chaque ligne bizarre est souvent un bug corrigé que vous vous apprêtez à réintroduire.

Un rewrite ne supprime pas cette complexité. Il la remet à zéro. Et pendant que votre équipe reconstruit ce que vous aviez déjà, vos concurrents, eux, expédient de nouvelles fonctionnalités.

Le vrai coût : ce n’est pas six mois de dev, c’est six mois d’immobilité

Faisons le calcul honnête. Une réécriture « propre » d’un produit early-stage n’est presque jamais terminée dans le délai annoncé — la règle empirique veut qu’on double l’estimation, et encore. Mais le coût direct n’est pas le pire.

Le vrai coût, c’est le gel de la roadmap. Pendant la réécriture, vous devez maintenir deux réalités en parallèle : l’ancien produit, qui tourne en production et doit continuer à recevoir des correctifs, et le nouveau, qui n’existe pas encore. Chaque bug urgent corrigé sur l’ancien doit être reporté sur le nouveau, sinon vous accumulez une dette de synchronisation. Vos commerciaux, eux, ne peuvent plus promettre de nouveautés. Votre discours produit se fige à « on refait la fondation ». Pour une seed qui doit prouver sa traction avant la prochaine levée, six mois sans nouvelle feature significative, c’est une courbe de croissance qui s’aplatit au pire moment.

Et il y a le risque humain. Le rewrite démarre dans l’enthousiasme, puis se heurte aux mêmes arbitrages sales qui avaient produit l’ancien code : le deadline qui approche, le client qui exige un cas particulier, la feature qu’on bricole « juste pour cette fois ». Six mois plus tard, vous avez un nouveau code déjà en train de pourrir — sauf que vous avez perdu la connaissance accumulée dans l’ancien. Beaucoup de startups ne survivent pas à ce trou d’air : la trésorerie a fondu, la traction s’est éteinte, et le produit « propre » n’a jamais atteint la parité fonctionnelle.

Le refactoring progressif : moins héroïque, beaucoup plus efficace

L’alternative n’est pas de subir le code pourri éternellement. C’est de le réparer sans jamais arrêter la production — ce que Martin Fowler appelle le refactoring, et Michael Feathers, dans un livre entier, « travailler efficacement avec du code hérité ».

Concrètement, cela veut dire remplacer les composants un par un, derrière une interface stable, pendant que le produit continue de livrer de la valeur. Le pattern le plus utile pour une startup s’appelle le strangler fig : au lieu de tout raser, vous entourez progressivement l’ancien système de nouveaux modules qui reprennent ses fonctions, jusqu’à ce que l’ancien devienne inutile et meure de lui-même. Chaque semaine, une part un peu plus grande du produit tourne sur du code neuf, sans jamais qu’un « big bang » ne mette tout en péril.

Cette approche a un avantage décisif pour une jeune entreprise : elle est réversible et pilotable. Si la trésorerie se tend, vous mettez le refactoring en pause et vous continuez à vendre. Si un module s’avère finalement stable, vous ne le touchez pas — on ne réécrit pas ce qui marche par principe esthétique. Vous concentrez l’effort là où ça fait mal : les zones à la fois les plus fragiles et les plus modifiées. Un module horrible que personne ne touche jamais ne coûte rien ; c’est le module horrible qu’on modifie chaque sprint qui saigne votre équipe.

Le prérequis, souvent ignoré, ce sont les tests. On ne refactore pas sans filet. Avant de toucher un module critique, on l’entoure de tests de caractérisation — des tests qui figent le comportement actuel, même bizarre, pour garantir qu’on ne casse rien. C’est fastidieux, mais c’est ce qui transforme une réécriture terrifiante en série de petits pas sûrs.

Quand le rewrite est réellement justifié (les rares cas)

Refuser le rewrite par principe serait aussi dogmatique que de l’accepter par principe. Il existe des situations où repartir de zéro est le bon choix.

Le premier cas : un changement de fondation impossible à faire de manière incrémentale. Passer d’un framework ou d’un langage en fin de vie, sans mainteneur ni recrues disponibles sur le marché, peut justifier une reconstruction — surtout si le produit reste petit. Un MVP de quelques milliers de lignes se réécrit vite ; c’est un produit mûr de plusieurs années qui se réécrit dans la douleur.

Le deuxième cas : un pivot produit réel. Si votre proposition de valeur change fondamentalement, l’ancien code n’encode plus les bonnes décisions métier — il devient un poids, pas un actif. Là, la connaissance à préserver est faible et la table rase se défend.

Le troisième cas, plus subtil : quand vous préparez une due diligence technique de série A et qu’un module central est devenu un risque identifiable — de sécurité, de scalabilité, de dépendance humaine. Encore une fois, la bonne réponse est le plus souvent un rewrite ciblé d’un composant, pas du système entier.

Dans tous les cas, la question n’est jamais « le code est-il moche ? » mais « qu’est-ce que je ne peux fondamentalement pas faire avec l’existant, et combien vaut cette impossibilité ? »

Ce qu’il faut vraiment faire

Quand la demande de rewrite arrive, ne répondez ni oui ni non tout de suite. Traitez-la comme un arbitrage d’investissement.

Commencez par exiger la traduction business : quelles features futures deviennent impossibles ou trop coûteuses avec le code actuel, et quelle valeur ces features représentent ? Une réécriture qui ne débloque rien de concret est un caprice d’ingénieur, pas une décision.

Ensuite, cartographiez la douleur. Identifiez les trois ou quatre modules qui concentrent à la fois les bugs et les modifications fréquentes. C’est là que vous investissez, en refactoring progressif protégé par des tests. Vous obtiendrez 80 % du soulagement pour 20 % de l’effort d’un rewrite complet.

Enfin, si le rewrite reste sur la table, découpez-le. Un rewrite acceptable est un rewrite qu’on peut arrêter à tout moment sans avoir tout cassé — donc composant par composant, avec un produit qui reste vendable à chaque étape. Le « grand soir technique », lui, ne se découpe pas : c’est tout ou rien, et le « rien » tue les startups.

La vraie question n’est pas « faut-il réécrire ? ». C’est : combien de mois de roadmap êtes-vous prêt à échanger contre du code plus propre — et êtes-vous sûr que le marché vous laissera ce temps ?