Quand refaire son MVP de zéro (ou pas)

« 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.

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.

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.