Un développeur veut tout refaire pour 15 000€ — est-ce justifié ?

Tu as lancé ton MVP avec Lovable, Bolt ou Cursor. Ça a marché. Ton produit a des utilisateurs, du traction. Puis arrive un développeur qui te dit : "C'est sympa, mais c'est du vibe-code. Faut tout refaire. 15 000€. Minimum."

Panique. Tu te demandes : est-ce vraiment vrai ?

Spoiler : dans la majorité des cas, non. Mais dans certains cas, oui.

Pourquoi les devs disent "faut tout refaire"

Les développeurs traditionnels ont une certaine vision du "code propre". Ils voient du HTML en ligne, des fonctions qui font plusieurs choses, pas de tests unitaires, des fichiers qui font 2000 lignes. Pour eux, c'est un chaos organisé.

Mais voici le truc important : c'est pas forcément un problème. Un code "sale" qui fonctionne, qui scale, et sur lequel tu peux itérer n'est pas un crime. C'est juste un code écrit rapidement pour valider une idée.

Ce qu'ils appellent "mauvais code" est souvent simplement de la dette technique. Pour comprendre vraiment la notion et comment l'évaluer, consulte notre guide complet sur [la dette technique et le vibecoding](/blog/dette-technique-vibecoding-eviter), qui t'explique comment la gérer avant qu'elle ne te bloque à la croissance.

Le problème, c'est quand un dev dit "faut refaire" sans évaluation réelle. Sans audit. Sans avoir regardé le code. Juste parce que c'est du vibe-code. Ça, c'est suspect.

Les vraies raisons d'un rebuild

1. Tes fondations sont cassées

Ton app accumule les bugs bizarres ? Des features qui se cassent mutuellement ? Des perfs qui dégradent exponentiellement ? C'est le signe que l'architecture a un problème structurel.

Questions à poser : "Peux-tu me montrer 3 exemples spécifiques de bugs causés par l'architecture ?"

2. Tu as un volume que l'infra ne supporte pas

Ton app a 10 000 utilisateurs et crashe 5 fois par jour. Même là, c'est souvent un problème de configuration ou d'optimisation, pas de code.

3. Tu dois pivoter techniquement

Tu es en React et tu dois aller sur mobile natif. Tu es en monolith et tu dois passer en microservices. Là, un refactor peut pas suffire.

4. Personne ne peut maintenir le code

Ton unique dev part. Personne ne peut lire le code. C'est un vrai problème, mais la solution n'est pas forcément un rebuild.

Les fausses raisons

"C'est du vibe-code, donc c'est pas bon" — Non. Du vibe-code qui fonctionne, c'est bon. Point.

"Y a pas de tests" — Tu peux ajouter des tests sans tout refaire.

"Ça scalera jamais" — À moins qu'il ait mesuré, c'est du blabla.

Comment décider : le framework

1. Y a des bugs récurrents causés par l'architecture ? Non → probable que tu dois pas refaire

2. Est-ce que refactorer progressivement réglerait ça ? Oui → refactor (budget 2000-5000€)

3. Tes données/logique métier sont trop entrelacées avec l'UI ? Oui → ça peut justifier un rebuild

4. C'est urgent pour ton business ? Oui → rebuild (faster path) / Non → refactor progressif

Les 5 questions à poser au dev

1. "Montre-moi les 3 problèmes spécifiques qui justifient un rebuild, pas juste 'c'est du vibe-code'"

2. "Si on refactorise les parties problématiques, qu'est-ce qu'on sauve ?"

3. "Combien ça coûterait de migrer progressivement ?" (souvent 30-40% plus cher mais 95% moins risqué)

4. "Pendant le rebuild, on arrête les nouvelles features combien de temps ?"

5. "Quel est ton niveau de confiance que c'est mieux après ? En pourcent."

Si il peut pas répondre précisément, c'est un red flag.

L'audit comme arbitre neutre

Un audit externe, c'est un tiers impartial qui regarde le code réellement, te dit où sont les problèmes, évalue les risques de rebuild vs refactor, et te protège d'un rebuild inutile.

Chez AJ Ventures, on a vu 100+ apps vibecodées. Moins de 15% avaient vraiment besoin d'un rebuild complet. Les autres ? Refactor smart + quelques corrections ciblées = 70% du résultat pour 20% du coût.

*Tu hésites sur un devis de rebuild ? [Réserve un audit →](/). On te dit si c'est justifié ou non en 48h.*

Un développeur veut tout refaire pour 15 000€ — est-ce justifié ?