« On repart de zéro, ce sera plus propre. » C'est tentant, surtout quand le produit actuel agace au quotidien. Mais la refonte totale est l'une des décisions les plus coûteuses qu'un fondateur puisse prendre, et l'une des plus souvent regrettées. Avant de jeter le code existant, il faut être sûr que le problème est bien le code, et pas autre chose.
Dans la grande majorité des cas, non, il ne faut pas refaire son MVP de zéro. Une refonte totale recrée la même dette avec un an de retard, pendant que vous arrêtez d'avancer. La bonne réponse est presque toujours un refactor module par module sur la base existante. Le rebuild ne se justifie que face à des signaux structurels précis, pas à une simple gêne.
Si vous cherchez d'abord à cadrer ce que doit contenir votre produit avant d'en parler de refonte, c'est dans le guide du MVP au PMF. Ici, on tranche une seule question : faut-il reconstruire, ou réparer ?
Pourquoi la refonte totale est un piège
L'erreur de raisonnement est toujours la même. On regarde le code actuel, on le trouve sale, et on en conclut qu'un code neuf serait sain. Mais ce qui a produit la dette du premier MVP n'a pas disparu : c'est la pression du temps, le périmètre flou, les décisions prises vite faute de recul. Reconstruisez dans les mêmes conditions, et vous obtiendrez la même dette, juste plus tard.
Le coût caché d'un rebuild, ce n'est pas le temps de développement. C'est l'arrêt de la livraison. Pendant que vous reconstruisez à l'identique ce qui existe déjà, vos concurrents ajoutent des fonctionnalités, vos clients attendent, et votre produit n'avance pas. Vous payez deux fois : le coût de la réécriture, et le coût d'opportunité de tout ce que vous n'avez pas construit pendant ce temps.
Il y a aussi un piège psychologique. Le code qu'on n'a pas écrit soi-même paraît toujours pire qu'il ne l'est. Une bonne partie de ce qu'on prend pour de la dette technique n'est en fait que du code qu'on ne comprend pas encore, ou qu'on aborde sans la documentation qui en explique les choix.
Refactor module par module : la voie par défaut
La vraie alternative à la refonte totale, ce n'est pas « ne rien faire ». C'est améliorer le produit là où ça fait mal, un morceau à la fois, sans jamais arrêter de livrer. On isole le module qui pose problème, on le réécrit proprement derrière une interface stable, on le remplace, et on passe au suivant. Le produit reste vivant et utilisable à chaque étape.
Cette approche a un autre mérite : elle force à comprendre ce qui ne va vraiment pas. Souvent, en isolant le premier module, on découvre que le problème était concentré sur 20 % du code, et que les 80 % restants étaient parfaitement sains. On vient d'éviter une réécriture intégrale en réparant un cinquième du produit.
Les vrais signaux qui justifient un rebuild
Soyons justes : il existe des situations où repartir de zéro est la bonne décision. Mais ce sont des signaux structurels, pas une question de confort. La gêne quotidienne n'en fait pas partie. Voici ce qui justifie réellement un rebuild.
| Signal | Pourquoi il justifie un rebuild | Ce qui ne le justifie PAS |
|---|---|---|
| Stack obsolète ou abandonnée | Plus de mises à jour de sécurité, recrutement impossible | « Ce n'est pas la techno que j'aurais choisie » |
| Modèle de données fondamentalement faux | Le produit a pivoté, l'architecture ne porte plus le métier | Quelques tables mal nommées |
| Aucun module isolable | Tout est si couplé qu'on ne peut rien réparer séparément | Du code peu commenté mais structuré |
| Coût de maintenance > coût de rebuild | Chaque correction en casse trois autres, durablement | Un bug récurrent identifié |
La règle de décision tient en une phrase : on reconstruit quand la base existante empêche structurellement d'avancer, pas quand elle ralentit. Un produit qu'on peut encore faire évoluer, même péniblement, mérite presque toujours un refactor plutôt qu'un rebuild. Si votre budget a déjà dérivé sur ce produit, les leviers pour le reprendre sans tout jeter sont dans MVP qui coûte trop cher.
La question à se poser avant de décider
Avant de trancher, posez-vous la vraie question : « qu'est-ce qui m'empêche d'avancer, exactement ? ». Si la réponse est « le code est moche », ce n'est pas un motif de rebuild. Si la réponse est « je ne peux ajouter aucune fonctionnalité sans tout casser, et ça dure depuis des mois malgré les corrections », alors on est peut-être dans un vrai cas de reconstruction.
Le rebuild se décide sur des faits, pas sur une impression
Avant de valider une refonte totale, exigez une cartographie honnête : quels modules sont sains, lesquels sont
réellement bloquants, et combien de temps un refactor ciblé prendrait par rapport à un rebuild complet. Si personne ne
peut produire cette carte, le problème n'est pas le code : c'est qu'il manque quelqu'un capable de le lire.
Dans la plupart des cas, le diagnostic révèle qu'on n'avait pas besoin de tout refaire. On avait besoin de comprendre le produit existant, d'isoler ce qui posait vraiment problème, et de le réparer méthodiquement. C'est moins spectaculaire qu'un grand rebuild, mais c'est ce qui garde l'entreprise en mouvement.
On regarde votre produit ensemble avant de tout jeter ?
J'interviens comme CTO fractional armé d'IA pour poser le bon diagnostic : ce qui est sain, ce qui est bloquant, et le
chemin le moins coûteux pour reprendre la main. Découvrez l'accompagnement CTO, ou
réservons 30 minutes pour trancher refactor ou rebuild.
Top comments (0)