Software rewrite : la mauvaise question qui tombe sur le fondateur non-technique au pire moment

Un guide de terrain pour les fondateurs à qui l'on propose de financer une réécriture logicielle : ce que la question veut vraiment dire, pourquoi elle échoue presque toujours, et les quatre questions à poser avant de signer quoi que ce soit.

Camila était CEO depuis dix-neuf mois quand son dev lead est entré en 1:1 et a prononcé la phrase que tout fondateur non-technique finit par entendre : « Il faut tout réécrire. » Le produit avait de vrais clients, du revenu mensuel, et un chèque d’investisseur tombé en février. La codebase avait dix-huit mois, construite vite pendant le pre-seed, et portait l’empreinte des quatre contractors qui y avaient touché. Le dev voulait six mois et une page blanche. L’investisseur attendait de nouvelles features. Camila n’avait aucun moyen de savoir si c’était une décision sérieuse d’ingénierie ou l’allergie d’un dev junior au code hérité.

Un software rewrite, c’est la décision de jeter une codebase existante et d’en construire un remplaçant à partir de zéro, en général parce que l’équipe pense que le système actuel ne peut plus évoluer à la vitesse exigée par le business. Voilà la définition manuelle. La définition honnête est plus rêche : la réécriture, c’est ce qu’on propose quand quelqu’un dans l’équipe a perdu foi dans le code et n’arrive plus à séparer le problème technique du problème émotionnel.

Pour un fondateur non-technique, la question de la réécriture n’est presque jamais la question à laquelle il faudrait répondre. Ce sont trois questions empilées, et répondre à la mauvaise, c’est comme ça qu’une entreprise en stade précoce brûle un an de runway à reconstruire ce qu’elle avait déjà.

Pourquoi « est-ce qu’on réécrit ? » est la mauvaise question

Le cadre que le dev vous tend est binaire. Garder l’ancien code, ou repartir de zéro. C’est ce cadre qui fait que la réécriture est validée, parce que les deux réponses ont l’air de décisions et que l’une d’elles sonne comme un progrès.

En pratique, aucune des deux n’est ce dont le business a besoin. Le business a besoin de savoir ce qui lui fait mal. La codebase est une cause possible. En général il y en a quatre : le système ne peut véritablement pas faire ce que le client demande (architecture) ; l’équipe ne peut pas livrer en sécurité (opérationnel) ; les ingénieurs ne veulent plus travailler sur le code (culturel) ; ou le fondateur ne voit pas ce qui se passe (visibilité). Chacune appelle une intervention différente, et une seule est une réécriture.

Si vous acceptez le binaire, vous avez déjà perdu la conversation. La question n’est pas « on garde ou on repart de zéro ». La question est : quel résultat business précis le code actuel empêche-t-il, et quel est le plus petit changement qui le résout ?

Les trois problèmes cachés dans la question de la réécriture

Quand un dev dit « il faut tout réécrire », il mélange presque toujours trois problèmes distincts. Séparez-les avant de décider quoi que ce soit.

Le problème business

Commencez ici. Avant la moindre conversation sur le code, nommez le résultat business que le système actuel rend impossible. Est-ce livrer la prochaine feature sans casser la précédente ? Est-ce la latence qui vous coûte un client flagship ? Est-ce lancer une nouvelle tier de prix ? Est-ce un audit sécurité que vous devez passer pour signer un grand compte ? Est-ce aucun de ces points, et le vrai problème est que le dev s’ennuie ?

Nous avons vu des fondateurs financer des réécritures de six mois parce que la vélocité avait baissé, pour découvrir six mois plus tard que la vélocité restait basse sur la nouvelle codebase. Le problème d’origine était un environnement de staging absent et un processus de déploiement non documenté. Aucun des deux n’exigeait une réécriture.

Si vous ne pouvez pas finir la phrase « si on fait cette réécriture, l’entreprise pourra faire X d’ici la date Y et Z sera mesurablement différent », vous n’avez pas un problème business. Vous avez une préférence d’ingénierie déguisée en problème business.

L’hypothèse technique

Une fois le problème business nommé, la question suivante est : quel changement technique le résout effectivement ? Une réécriture est une option. C’est rarement la moins chère. C’est presque toujours la plus lente. Et elle porte un risque spécifique que les changements incrémentaux ne portent pas : le nouveau code doit atteindre la parité fonctionnelle avec l’ancien avant que qui que ce soit puisse l’utiliser. Ce travail est invisible pour les clients et les investisseurs. Six mois à construire des choses qui existent déjà, c’est l’une des formes les plus coûteuses qu’une roadmap de startup puisse prendre.

Pour la plupart des codebases en stade précoce, les hypothèses moins chères sont : des refactors ciblés sur deux ou trois modules ; un nouveau service qui prend en charge la pièce cassée pendant que l’ancien système continue de tourner ; une réécriture d’une seule couche (couche d’accès aux données, couche d’auth) plutôt que tout le stack ; ou la réparation du déploiement, du monitoring et des tests pour que le code existant soit plus sûr à modifier. Presque aucun fondateur n’entend ces options parce que le dev qui a proposé la réécriture a déjà décidé la réponse.

Le pari falsifiable

Le troisième problème, c’est celui qu’on n’articule presque jamais, et c’est celui qui sépare les vraies décisions d’ingénierie des décisions de désir. Toute proposition de réécriture est un pari. Les paris ont une condition de falsification : un moyen de savoir, avant de commencer, ce qui voudrait dire que le pari a échoué.

Quelle est la métrique qui dit que cette réécriture a marché ? Fréquence de déploiement ? Taux de bugs par release ? Temps d’onboarding d’un nouvel ingénieur ? Temps pour livrer une feature qui touche trois modules ? Latence visible côté client ? Quelle qu’elle soit, elle doit être mesurable aujourd’hui, mesurable sur le système réécrit, et fiable depuis le siège du fondateur, sans avoir à demander au dev. Si le pari est « tu te sentiras mieux avec le code », vous financez une thérapie, pas de l’ingénierie. C’est la même logique que nous utilisons pour définir ce qu’un MVP est vraiment : sans condition de falsification, vous avez un projet, pas un pari.

La règle de Joel Spolsky, 25 ans plus tard

En 2000, Joel Spolsky a écrit ce qui reste l’essai le plus cité sur le sujet, Things You Should Never Do, Part I. Sa thèse : réécrire à partir de zéro est la pire erreur stratégique qu’une entreprise de logiciel puisse commettre. Netscape a perdu la guerre des navigateurs face à Microsoft parce qu’elle a passé trois ans à réécrire Communicator pendant qu’IE livrait. La phrase que tout fondateur devrait retenir : « vous jetez votre leadership de marché. »

Vingt-cinq ans après, la règle tient encore pour le cas que Spolsky protégeait : un produit en production, avec de vrais clients, un modèle d’affaires qui fonctionne, et une codebase mûrie par des années de cas particuliers. Ne réécrivez pas ça. Refactorez-le.

Ce qui a changé, c’est la situation que Spolsky ne traitait pas. Il écrivait sur Netscape. La codebase qui franchit la porte de Pixel Breeders en 2026 est plus souvent un MVP de dix-huit mois, construit par deux contractors et un stack no-code, jamais conçu pour durer. Ce n’est pas un système éprouvé. C’est un prototype qui a survécu au contact des clients, et les motifs que Spolsky défendait ne s’appliquent pas tous.

Pour cette codebase, la question se déplace. Ce n’est pas « faut-il réécrire Netscape ? » C’est « le prototype a atteint le product-market fit avant que l’ingénierie ne le rattrape. Et maintenant ? » Cette question a une autre réponse, et elle implique généralement de reconstruire des morceaux du système en parallèle pendant que l’original continue de tourner. Pas une réécriture complète. Pas un refactor. Quelque chose entre les deux, avec la même discipline de falsification qu’un vrai pari.

Cinq questions à poser avant de financer une réécriture

Quand la proposition de réécriture atterrit sur votre bureau, parcourez-les dans l’ordre. La plupart des réécritures tombent sur les questions 1, 2 ou 3.

1. Quelle est la perte business concrète que cette codebase est en train de créer ? Forcez un chiffre ou une date. Revenu perdu, clients ratés, un deal à risque, une échéance réglementaire. « On n’arrive plus à bouger vite » n’est pas une réponse. « Acme a refusé de renouveler parce que l’endpoint d’export tombe en timeout sur des fichiers de plus de 50 Mo, et ça représente 180 K$ d’ARR » est une réponse.

2. Le dev peut-il nommer le seul changement qui résoudrait 80 % de la perte ? Demandez-lui de décrire la plus petite intervention qui adresse le problème nommé. S’il peut la décrire en un paragraphe, la réécriture est probablement la mauvaise réponse, et c’est ce changement que vous devriez financer. S’il ne peut pas, c’est votre signal : la réécriture est proposée par défaut, pas comme une décision.

3. Qui recommande la réécriture, et depuis combien de temps est-il sur le code ? Les devs qui héritent d’une codebase atteignent le moment « il faudrait tout réécrire » au bout de trois mois environ. C’est un motif psychologique connu, pas nécessairement technique. Les ingénieurs seniors qui vivent avec une codebase depuis deux ans proposent rarement des réécritures. Ils proposent des refactors ciblés. Si la réécriture est recommandée par quelqu’un qui est arrivé il y a six semaines et n’a touché qu’un seul module, pondérez la recommandation en conséquence.

4. Est-ce une date de livraison unique, ou un système parallèle qui doit converger avec la production ? La réponse honnête, c’est presque toujours la seconde. Les réécritures menées comme « on arrête de construire des features pendant six mois et on bascule » ont, d’après notre expérience, un taux de succès d’environ 10 %. Celles menées comme « on construit le nouveau à côté de l’ancien, on migre feature par feature, et on éteint l’ancien quand la migration est complète » montent autour de 60 %. Le premier plan est ce que les ingénieurs disent. Le second est ce qu’ils livrent.

5. À quoi ressemble « terminé », et est-ce mesurable depuis le siège du fondateur ? Terminé, ce n’est pas « le nouveau code est à parité fonctionnelle ». Terminé, c’est « on livre la feature X en N jours au lieu de M, et le client Y utilise le nouveau système en production avec la métrique Z ». Si le dev ne peut pas définir terminé d’une manière qu’un fondateur non-technique puisse vérifier, la réécriture n’a pas de condition de fin. Un projet sans condition de fin ne se termine pas. Il embauche plus de devs.

Quand une réécriture est vraiment la bonne réponse

Cela arrive. Quatre motifs précis valent l’investissement.

Le premier, c’est le MVP vibe-coded qui a trouvé son product-market fit. On voit ça tous les mois. Un fondateur a livré quelque chose en huit semaines avec un backend hébergé, trois APIs SaaS et une poignée de features assistées par LLM qu’il ne comprend pas entièrement. Ça marche. Le client paie. Et chaque nouvelle feature en casse une autre, parce que le système n’a jamais été conçu pour faire ce qu’il doit maintenant faire. Dans ce cas, la « réécriture » ressemble davantage à une première vraie construction. La règle de Spolsky ne s’applique pas, parce qu’il n’y a pas d’ingénierie fonctionnelle à jeter ; il y a un prototype qui doit maintenant être ingénié. Le cadre que nous utilisons avec les fondateurs non-techniques face à cette décision exacte traite cela comme la transition naturelle entre « ce qu’on a construit pour apprendre » et « ce qu’on construit pour passer à l’échelle ».

Le deuxième, c’est le changement de plateforme que le modèle d’affaires exige maintenant. Vous avez lancé une app web ; vous avez besoin d’un produit mobile-first parce que la base clients a bougé. Vous avez construit sur une base de données qui ne supporte pas l’ordre de grandeur suivant. Vous avez choisi un stack no-code et la tier de prix supérieure coûte plus cher que reconstruire. Ce ne sont pas des réécritures de préférence. Ce sont des réécritures d’adéquation.

Le troisième, c’est la barrière sécurité ou conformité. SOC 2, HIPAA, PCI, RGPD, LGPD. Certains régimes de conformité sont atteignables depuis le code existant avec un effort auditable. D’autres non. Quand l’architecture en place ne peut pas passer l’audit sans des changements plus profonds que ce que la conception d’origine supporte, la réécriture est réelle, et le coût est le coût de faire le métier que vous faites maintenant.

Le quatrième, c’est l’ingénieur irremplaçable qui a démissionné, laissant une codebase que plus personne ne sait lire. C’est le cas le plus controversé, parce que le bon mouvement est souvent d’embaucher un nouvel ingénieur pour apprendre le code plutôt que de réécrire. Mais il y a un seuil. Quand la codebase est suffisamment petite, la documentation suffisamment mauvaise, et que tous ceux qui savaient la lire sont partis, parfois le coût d’apprendre dépasse le coût de reconstruire avec une équipe capable de maintenir la nouvelle version. C’est rare. Si cela ressemble à votre situation, prenez un second avis auprès de quelqu’un qui ne facturera pas la réécriture.

Un test de 4 semaines avant de financer la réécriture

Si après les cinq questions vous l’envisagez encore, ne signez pas la réécriture. Lancez d’abord un test de quatre semaines.

Choisissez la feature ou le module unique le plus douloureux, celui qui revient à chaque fois que l’équipe se plaint de la codebase. Choisissez la métrique de falsification que vous avez actée à la question 5. Donnez à l’équipe quatre semaines pour refactorer cette pièce sur place ou l’extraire dans un service parallèle, et démontrer une amélioration mesurable sur la métrique.

Quatre semaines représentent environ 20 K€ à 50 K€ de temps d’ingénierie pour une équipe en stade précoce, selon les tarifs. Une réécriture complète, c’est six à douze mois et 150 K€ à 600 K€ aux mêmes tarifs, et c’est avant le coût de maintenance de la deuxième année que vous héritez sur ce qui sera livré. Le test de quatre semaines est la façon la moins chère possible de savoir si l’équipe peut faire bouger ce système, point.

Si elle le peut : la réécriture est la mauvaise réponse ; continuez à refactorer. Si elle ne le peut pas : maintenant vous avez de la preuve, pas de l’opinion, et la conversation sur la réécriture peut avoir lieu avec tout le monde regardant les mêmes données.

Foire aux questions

Qu’est-ce qu’un software rewrite ? Un software rewrite est la décision d’écarter une codebase existante et de construire un remplaçant à partir de zéro. Il remplace en général le code original dans sa totalité, et non pièce par pièce, et vise à atteindre la parité fonctionnelle avec l’ancien système avant que les clients voient quoi que ce soit de nouveau.

Quand une réécriture est-elle la bonne réponse ? Rarement. Les cas défendables sont : un MVP qui a trouvé le product-market fit et doit être ingénié pour de vrai pour la première fois ; un changement de plateforme exigé par le modèle d’affaires ; un régime de conformité que l’architecture d’origine n’atteint pas ; ou une codebase non maintenable dont les ingénieurs d’origine sont partis. Dans tous les autres cas, un refactor ciblé ou un service parallèle est moins cher et plus rapide.

Combien coûte un software rewrite ? Pour un produit en stade précoce, une vraie réécriture représente en général six à douze mois d’ingénierie, soit environ 150 K€ à 600 K€ en Europe et 150 K$ à 600 K$ aux États-Unis selon la taille et la séniorité de l’équipe. Ce chiffre n’inclut pas le coût récurrent de maintenance d’opérer deux systèmes pendant la migration, ni le coût d’opportunité des features non livrées pendant la réécriture. Le coût caché d’une réécriture, c’est ce que vous arrêtez de construire pendant qu’elle dure.

Réécrire ou refactorer ? Refactorez par défaut. Le refactor est incrémental, vous laisse livrer de la valeur visible côté client pendant le travail, et a un taux de succès bien plus élevé. Choisissez la réécriture seulement quand le code existant ne peut pas atteindre la destination par un chemin incrémental. La « règle des 3 » (refactorez quand vous voyez le même motif trois fois) est une heuristique interne utile, mais elle ne s’étend pas à des codebases entières. Les réécritures complètes ne sont pas des refactors à grande échelle ; ce sont un autre genre de pari, avec d’autres modes de défaillance.

Pourquoi la plupart des software rewrites échouent ? Trois raisons, par ordre de fréquence. Elles ne se terminent pas avant que le runway s’épuise, parce que la parité fonctionnelle représente plus de travail que l’équipe ne l’avait estimé. Elles livrent sans que la métrique de falsification soit atteinte, donc personne ne peut dire si la réécriture a marché. Et elles échangent un ensemble de problèmes contre un autre, parce que l’équipe qui a écrit le code original est souvent celle qui écrit la réécriture, avec les mêmes hypothèses.

Si vous lisez ceci au milieu d’une conversation sur une réécriture, la chose la plus utile que vous puissiez faire demain n’est pas de l’approuver. C’est de poser la question 1 et de refuser d’avancer sans un chiffre.