Refaire from scratch ou reprendre son code IA ? L'arbre de décision
02/07/2026
Votre prototype créé avec Bolt, Lovable ou Cursor fonctionne, mais vous savez qu'il n'est pas prêt pour la production. Arrive alors la question qui bloque beaucoup de fondateurs : faut-il tout reprendre de zéro pour partir sur des bases saines, ou récupérer le code existant et le renforcer ? Le réflexe « je recommence proprement » paraît rassurant. Il est souvent l'erreur la plus coûteuse.
Cet article vous donne un arbre de décision honnête. D'abord le verdict général, ensuite les critères précis qui penchent vers la reprise ou vers la refonte, sans dogmatisme. Car la reprise est le bon choix dans la majorité des cas, mais pas toujours, et savoir reconnaître les exceptions vous évite de mauvaises surprises.
Reprendre ou refaire : la réponse courte
Dans la grande majorité des cas, autour de huit projets sur dix, reprendre le code existant est le meilleur choix. Le code généré par les outils de vibe coding est exportable, et l'interface a généralement déjà été validée par vos premiers utilisateurs. La conserver évite de refaire la conception, le design et les parcours, qui représentent une part importante du travail. On garde donc ce qui fonctionne et on reconstruit les fondations techniques en dessous.
La refonte complète ne se justifie que dans des cas précis, quand le code de départ est inexploitable ou quand un changement structurel rend l'existant caduc. Ces situations existent, mais elles sont minoritaires. Le piège est de choisir la refonte par confort mental, parce que repartir d'une page blanche semble plus simple, alors qu'elle coûte plus cher et prend plus de temps.
Reprendre vs refaire : le comparatif
Le tableau suivant met les deux options face à face sur les critères qui comptent vraiment.
| Critère | Reprendre l'existant | Refaire from scratch |
|---|---|---|
| Coût | Inférieur (on capitalise) | Plus élevé (tout est à recréer) |
| Délai | Plus court | Plus long |
| Risque | Maîtrisé (périmètre connu) | Élevé (on repart de zéro) |
| UX validée | Conservée | Perdue puis à refaire |
| Dette technique de départ | À nettoyer | Nulle |
Le seul avantage réel de la refonte tient à la dernière ligne : on repart sans dette technique. Cet avantage est tentant, mais il se paie cher en temps et en argent, et il fait perdre l'interface que vos utilisateurs connaissent déjà. Dans la plupart des cas, nettoyer la dette d'un code existant coûte moins que tout reconstruire. L'impact précis sur le budget est détaillé dans notre article sur le coût de la finalisation d'un projet vibe coding.
Quand reprendre le code IA (la majorité des cas)
Plusieurs signaux indiquent que votre prototype mérite d'être repris plutôt que jeté.
- L'interface a convaincu vos premiers utilisateurs. Si des gens utilisent déjà votre produit et l'apprécient, son UX a de la valeur. La recréer serait un gaspillage.
- Le code reste lisible et modulaire. Un code organisé en composants clairs, même imparfait, se reprend et se renforce sans difficulté majeure.
- La stack est standard et exportable. Du React ou du Next.js généré par Lovable ou Bolt repose sur des technologies courantes qu'un développeur senior maîtrise et fait évoluer sans repartir de zéro.
- Les problèmes sont localisés. Quand les manques se concentrent sur la sécurité, le backend ou les performances, ils s'isolent et se traitent un par un, sans toucher au reste. La plupart des limites du vibe coding entrent dans cette catégorie.
Quand ces conditions sont réunies, la reprise est nettement plus rentable. On conserve l'acquis et on investit l'argent là où il compte : les fondations qui manquent.
Un exemple parlant. Un fondateur nous contacte persuadé qu'il faut tout refaire son application Lovable, parce qu'elle « bug » et qu'il a perdu confiance dans le code. À l'audit, le diagnostic est plus simple qu'il ne le craignait : l'interface est propre et appréciée de ses clients, et les problèmes se concentrent sur deux points, des données stockées localement et l'absence de contrôle d'accès. Reconstruire aurait coûté plusieurs mois et un budget de développement complet. La reprise a réglé les deux points en quelques semaines, sans toucher à l'interface. Le fondateur avait confondu « mon code a des problèmes » avec « mon code est à jeter », une confusion fréquente et coûteuse.
Quand une refonte s'impose vraiment (les cas rares)
L'honnêteté impose de le dire : parfois, repartir de zéro est le bon choix. Quatre situations nous amènent à le recommander nous-mêmes.
- Le code est illisible et ingérable. Quand la génération a produit un enchevêtrement impossible à suivre, le temps passé à le démêler dépasse celui d'une reconstruction propre.
- Les choix de stack sont structurellement inadaptés. Si l'outil a bâti le projet sur une technologie qui ne tiendra pas vos besoins, aucun refactoring ne corrigera un mauvais socle.
- Vous opérez un pivot produit majeur. Si votre produit change de nature au point que l'existant ne correspond plus à rien, le conserver n'a pas de sens.
- Vos exigences sont incompatibles avec l'existant. Des contraintes fortes, comme l'hébergement de données de santé ou des garanties financières strictes, peuvent imposer une architecture que le prototype n'a jamais été conçu pour porter. Dans ce cas, la refonte des fondations devient incontournable, comme évoqué dans notre guide sur l'ajout d'un vrai backend à un prototype IA.
Reconnaître ces cas est aussi important que défendre la reprise. Une agence honnête vous dira quand votre code ne vaut pas la peine d'être sauvé, plutôt que de facturer un rafistolage voué à l'échec.
Les 3 questions à se poser avant de trancher
Avant même de consulter une agence, trois questions vous orientent vers la bonne décision.
- Mes utilisateurs aiment-ils déjà le produit ? Si oui, l'interface a une valeur qu'il serait absurde de jeter. La reprise protège cet acquis.
- Mes problèmes sont-ils localisés ou diffus ? Des manques précis (sécurité, base de données, lenteurs) se traitent par la reprise. Un code malsain de bout en bout penche vers la refonte.
- Mon besoin a-t-il changé de nature ? Si le produit reste le même mais doit devenir solide, on reprend. S'il pivote radicalement ou doit répondre à des contraintes que l'existant ne peut pas porter, la refonte se justifie.
Si vous répondez « oui, localisés, non » à ces trois questions, votre projet est très probablement à reprendre. Dans le doute, seul un regard technique sur le code tranche pour de bon.
Notre méthode pour trancher
La décision ne se prend pas à l'intuition, mais après avoir lu le code. Notre approche commence toujours par un audit du prototype qui répond à trois questions : qu'est-ce qui est bien fait et réutilisable, qu'est-ce qui doit être corrigé, et qu'est-ce qui manque pour la production. À partir de ce diagnostic, on recommande la reprise ou la refonte, avec un budget et un planning à l'appui.
Notre biais est assumé et vient de notre passé de fondateurs : on cherche d'abord à conserver votre travail, parce qu'on sait ce que coûte un produit et le temps qu'il représente. Quand la reprise est possible, on garde votre interface et on reconstruit le socle technique en dessous. Quand elle ne l'est pas, on vous le dit clairement, quitte à perdre la mission. Une recommandation qui pousse systématiquement vers la solution la plus chère pour l'agence ne mérite pas votre confiance.
Cette transparence a une raison simple. Une reprise réussie repose sur un diagnostic juste, et un diagnostic juste suppose de regarder le code sans préjugé, ni « on garde tout » ni « on jette tout ». C'est ce qui sépare une recommandation utile d'un argumentaire commercial. Dans les deux cas, vous décidez en connaissance de cause, avec les chiffres devant vous.
Questions fréquentes
Reprendre mon code IA, est-ce vraiment moins cher que tout refaire ?
Dans la plupart des cas, oui. On économise la conception, le design et les parcours utilisateur, déjà réalisés dans votre prototype. Le surcoût n'apparaît que si le code est inexploitable, ce qui reste minoritaire. Un audit permet de trancher avec des chiffres précis.
Comment savoir si mon code est récupérable ?
Trois indices : l'interface plaît à vos utilisateurs, le code reste lisible, et les manques sont localisés (sécurité, backend, performances). Si ces conditions sont réunies, la reprise est presque toujours préférable. Seul un audit du code confirme la faisabilité.
Combien de temps prend une reprise par rapport à une refonte ?
Une reprise est généralement plus rapide, puisqu'une partie du travail existe déjà. Une refonte complète repart de zéro, conception comprise, donc prend plus de temps. Le délai exact dépend de l'état du code et du périmètre, et se précise après audit.
Peut-on garder mon interface si on reprend le projet ?
Oui, c'est l'intérêt principal de la reprise. On conserve votre interface, validée par vos utilisateurs, et on reconstruit les fondations techniques en dessous. Vos utilisateurs ne voient aucune rupture, seul le socle change.
Que faire si une agence me pousse à tout refaire ?
Demandez-lui de justifier ce choix sur la base d'un audit du code, pas d'une impression. Tout reconstruire est plus cher et plus long, et ne se justifie que dans des cas précis. Si l'argumentaire repose sur « c'est plus simple pour nous », méfiez-vous.
Conclusion
Face au choix entre refaire et reprendre, le réflexe de la page blanche est rarement le bon. Retenez l'essentiel : dans environ huit cas sur dix, reprendre l'existant coûte moins cher, va plus vite et conserve l'UX validée par vos utilisateurs. La refonte ne s'impose que dans des cas précis, code ingérable, mauvaise stack, pivot majeur ou exigences incompatibles, et une agence honnête saura les reconnaître.
Pour trancher sur votre projet, faites auditer gratuitement votre code : vous saurez s'il est récupérable, ce qu'il faut renforcer, et le chemin le plus court vers une vraie application.
Lectures complémentaires :