Vous avez sorti une V0 en vibe code. En quelques heures, vous avez un écran, un flow, parfois même un paiement. Puis arrive le moment de “passer en production” et tout se complique.
Le sujet n’est pas “est-ce que ça marche sur mon navigateur”. Le sujet, c’est : est-ce que ça tient avec de vrais utilisateurs, de vraies données, une vraie authentification, et un déploiement propre. C’est là que le coût refonte app devient flou, et que le prix agence web app varie du simple au x10 selon ce qu’il faut reprendre.
Si vous êtes encore en train de comparer les outils avant cette étape, vous pouvez aussi lire notre article sur Lovable vs Bolt pour mieux comprendre les différences entre les deux approches.
L’objectif de cet article : vous donner des fourchettes réalistes, expliquer ce qui fait grimper la facture, et vous montrer une approche simple pour débloquer sans repartir de zéro.
Reprise de projet Lovable/Bolt : de quoi parle-t-on exactement ?
Une reprise, ce n’est pas “refaire l’UI”. C’est remettre une base générée en vibe code sur des rails “production”.
Concrètement, une reprise de projet Lovable/Bolt (et pareil pour v0) peut inclure :
- sécuriser l’auth et les accès
- fiabiliser les données (modèle, migrations, contraintes)
- corriger le déploiement et l’infra (environnement, variables, CI)
- améliorer la performance (temps de chargement, requêtes, cache)
- mettre des garde-fous (logs, monitoring, gestion d’erreurs)
- préparer la suite (roadmap technique, conventions, passage de relais)
C’est rarement un seul point. Souvent, on croit avoir “un bug de déploiement”, mais le vrai blocage vient d’une combinaison : auth fragile + données incohérentes + dépendances qui explosent au build.
Pourquoi un prototype en vibe code bloque au moment de la production
Lovable, Bolt et v0 sont excellents pour aller vite. Leurs modèles économiques vous poussent d’ailleurs à prototyper et itérer vite via des abonnements mensuels.
Le problème, c’est que la “vitesse prototype” s’obtient souvent au prix de compromis qui ressortent plus tard :
1) Un code qui marche, mais pas un code “maintenable”
Le vibe code peut produire des duplications, des composants très couplés, des appels API dispersés, et des logiques métier un peu partout. Tant que vous êtes seul, ça passe. Dès que vous ajoutez un dev, ou que vous corrigez 10 choses, ça devient instable.
2) Auth et rôles : l’endroit où on ne peut pas tricher
Un prototype peut “simuler” la connexion. En prod, vous devez gérer sessions, refresh tokens, reset password, permissions, RGPD, et parfois multi-tenant. C’est souvent là que le coût refonte app apparaît.
3) Données : le prototype tolère le flou, la prod non
En production, une donnée mal définie coûte cher : bugs, support, exports impossibles, erreurs de facturation. La reprise passe souvent par un vrai modèle de données et des migrations.
4) Déploiement et performance : la réalité de l’infra
Localement, tout est rapide. En prod, vous avez du réseau, du cache, des builds, des quotas, des erreurs 500, des variables d’environnement, du monitoring.
Si vous êtes encore au stade où vous cherchez surtout à cadrer la bonne base produit, notre guide comment développer une application web peut aussi vous aider à faire la différence entre prototype rapide et application exploitable.
Les 4 blocs qui font varier le coût refonte app
Si vous cherchez une estimation “au pif”, vous allez vous tromper. Le bon calcul, c’est de mesurer l’effort sur 4 blocs. C’est exactement ce qui explique pourquoi le prix agence web app est parfois très bas, parfois très élevé.
Bloc 1 : Déploiement et environnement
Ce qu’on retrouve souvent en reprise Lovable/Bolt :
- build qui casse selon l’environnement
- variables manquantes, secrets mal gérés
- absence de CI/CD, pas de preview propre
- configuration d’hébergement non stable
Effort typique : 1 à 5 jours si le code est propre, 1 à 3 semaines si l’architecture est incohérente.
Bloc 2 : Authentification et autorisations
Le “ça marche en démo” ne suffit pas. En prod, il faut généralement :
- auth robuste (provider, sessions, gestion d’erreurs)
- rôles et permissions
- protection des routes, des API, et des données
- parcours oubliés (déconnexion, expirations, appareils multiples)
Effort typique : 2 à 10 jours selon le niveau de sécurité attendu.
Bloc 3 : Données et intégrations
C’est le bloc le plus sous-estimé en vibe code.
- modèle de données à stabiliser
- migrations
- règles de validation
- intégrations (CRM, facturation, email, analytics)
- gestion des fichiers, des exports, des sauvegardes
Effort typique : 3 à 15 jours. Ça grimpe vite si les données existent déjà et qu’il faut reprendre sans perdre d’historique.
Bloc 4 : Performance, qualité, observabilité
Ce bloc transforme une app “sympa” en app “fiable”.
- optimisation des requêtes
- cache
- gestion d’erreurs propre
- logs exploitables
- monitoring, alertes
- tests ciblés (pas forcément 100% de couverture, mais les parcours clés)
Effort typique : 2 à 10 jours, plus si l’app a beaucoup d’écrans et de cas limites.
Fourchettes de prix : ce que vous payez vraiment
On va être clair : sans audit, personne ne peut donner “le prix” de votre reprise. Par contre, on peut donner des scénarios qui collent à la réalité du marché.
Un point important : les tarifs dépendent du prestataire. Les TJM observés côté freelances tech en France tournent souvent autour de plusieurs centaines d’euros par jour, et les agences montent plus haut selon séniorité et spécialisation.
Scénario A : Déblocage ciblé (le prototype est sain)
Vous avez un bon socle. Il y a 1 vrai point de friction (déploiement, auth, données ou perf) et on corrige proprement.
- Budget courant : 1 500 à 6 000 euros
- Délai courant : 2 à 10 jours
On voit même des offres “à partir de 1 500 euros” sur des reprises très ciblées, quand le périmètre est net et le socle exploitable.
Scénario B : Passage en production “sérieux” (plusieurs blocs à traiter)
Le cas le plus fréquent en vibe code : ça marche, mais il faut sécuriser 2 à 4 blocs.
- Budget courant : 6 000 à 15 000 euros
- Délai courant : 2 à 4 semaines
C’est souvent le meilleur ratio. Vous gardez la vitesse du prototype, mais vous retirez les risques majeurs.
Scénario C : Rebuild partiel (on garde le produit, on refait des fondations)
Ici, on conserve l’intention produit, parfois l’UI, mais on refait une partie de l’architecture, du modèle de données, ou de l’auth.
- Budget courant : 15 000 à 30 000 euros
- Délai courant : 1 à 2 mois
À ce niveau, on se rapproche des budgets classiques d’app web sur mesure, surtout si votre app devient une vraie application métier ou un mini SaaS.
Scénario D : Rebuild complet (le prototype ne doit pas aller plus loin)
Ça arrive. Le prototype vibe code a prouvé l’idée, mais le code est trop instable, trop couplé, ou trop risqué.
- Budget courant : 30 000 euros et plus
- Délai courant : 2 mois et plus
C’est le scénario qu’on cherche à éviter avec un bon diagnostic, parce qu’il coûte cher et il démoralise.
Ce qui fait exploser le prix agence web app sur une reprise Lovable/Bolt
Si vous recevez deux devis très éloignés, ce n’est pas forcément de l’arnaque. C’est souvent un périmètre implicite différent.
Voici les “multiplicateurs” les plus fréquents :
Il y a déjà des utilisateurs et des données
Reprendre une base vide est simple. Reprendre une base avec historique, droits, et données à ne pas casser, c’est une autre histoire. C’est souvent le vrai cœur du coût refonte app.
Vous avez besoin d’un niveau “production” élevé
B2B, données sensibles, paiements, conformité, SLA. La barre monte vite, surtout sur auth, logs et sécurité.
Le prototype dépend d’intégrations fragiles
Un Zapier bricolé, une API pas stable, un webhook sans retries. En prod, chaque intégration doit être durcie.
Le déploiement doit être industrialisé
C’est souvent là que les équipes se bloquent : build, environnements, secrets, monitoring. Le code n’est pas le seul sujet.
Une méthode simple pour estimer votre coût refonte app en 15 minutes
Sans outil compliqué, vous pouvez cadrer votre reprise avec 6 questions. Répondez honnêtement, vous aurez déjà une idée du scénario A, B, C ou D.
- Est-ce que quelqu’un peut expliquer l’architecture en 5 minutes ?
- L’auth est-elle réelle, avec rôles et parcours complets ?
- Le modèle de données est-il clair, avec des contraintes et une logique métier lisible ?
- Le déploiement est-il reproductible, ou c’est “ça marche sur ma machine” ?
- En cas d’erreur, est-ce qu’on a des logs utiles, ou rien ?
- Si on ajoute 10 fonctionnalités, est-ce que ça tient, ou ça casse partout ?
Si vous répondez “non” à 3 questions ou plus, vous êtes probablement en scénario B ou C.
Dr Lovable : une reprise pensée pour débloquer vite, sans surpayer
Chez Scroll, on a créé Dr Lovable pour répondre exactement à ce moment où tout se joue : entre prototype vibe code et production.
Le principe est volontairement simple :
- Diagnostic : on regarde votre projet, on identifie le vrai blocage, et on vous donne un plan clair.
- Fix ciblé : on intervient uniquement là où ça bloque vraiment, sur l’un des 4 grands sujets : déploiement, auth, données, performance.
- Sortie propre : on vous laisse une base stable, documentée juste ce qu’il faut, et exploitable pour la suite.
Et oui, malgré le nom, ce n’est pas réservé à Lovable : on fait aussi Bolt et v0, parce que les symptômes sont les mêmes quand on passe du vibe code à la prod.
Pour voir à quoi ressemble ce type d’intervention sur un cas concret, vous pouvez aussi lire comment l’Agence Scroll a débloqué un prototype IA de SaaS métier. C’est un bon complément pour rassurer un lecteur qui hésite encore entre correctif ciblé et reprise plus structurée.
Trois exemples concrets de budgets (pour vous situer)
“On a une V0, mais impossible de déployer”
Souvent un mélange de dépendances, variables d’environnement, build, et routes server/client.
Budget typique : 2 000 à 6 000 euros, selon la propreté du repo et le besoin d’industrialisation.
“Les utilisateurs se connectent, mais les droits ne sont pas fiables”
C’est un classique. Une fois que vous avez des rôles, des espaces, ou des données par client, il faut sécuriser.
Budget typique : 4 000 à 12 000 euros.
“Les données partent dans tous les sens”
Modèle flou, champs qui changent, exports impossibles, bugs en cascade.
Budget typique : 6 000 à 18 000 euros, surtout s’il faut migrer sans perte.
La suite logique si vous voulez un chiffre fiable
Le plus simple pour obtenir un chiffrage sérieux, c’est de partir d’un diagnostic court, puis de chiffrer un fix ciblé. C’est exactement l’approche Dr Lovable : éviter le devis énorme “au cas où”, et éviter aussi le petit devis qui explose en route.
Si votre prototype en vibe code est bloqué, on peut regarder votre projet, identifier le vrai nœud, et vous dire rapidement si vous êtes plutôt scénario A, B, C ou D. Ensuite, on intervient uniquement sur ce qui vous rapproche de la production, sans transformer votre reprise en refonte interminable.
Si vous voulez, vous pouvez nous solliciter via l’offre Dr Lovable de Scroll : diagnostic, identification du blocage, puis fix ciblé sur le déploiement, l’auth, les données ou la performance.
Faq
Le coût d’une reprise de projet Lovable ou Bolt varie généralement entre 1 500 € et 30 000 € ou plus selon l’état du prototype, le niveau de dette technique et les blocs à corriger. Une reprise ciblée peut rester abordable, tandis qu’un rebuild partiel ou complet coûte nettement plus cher.
Le prix d’une reprise de projet Lovable/Bolt dépend surtout de 4 facteurs : le déploiement, l’authentification, les données et la performance. Plus le prototype contient d’utilisateurs, d’intégrations, de logique métier ou de contraintes de sécurité, plus le budget augmente.
Oui, dans de nombreux cas, il est possible de reprendre un projet Lovable/Bolt sans repartir de zéro. Si le socle est exploitable, une agence ou un développeur peut corriger les points bloquants, fiabiliser la base technique et préparer le passage en production sans refaire toute l’application.
Une reprise suffit quand le prototype est globalement sain et que les problèmes sont concentrés sur quelques sujets comme le déploiement, l’auth ou les données. Un rebuild complet devient plus pertinent quand le code est trop instable, trop couplé ou trop risqué pour supporter une mise en production sérieuse.
Pour obtenir un chiffrage fiable, il faut commencer par un diagnostic rapide du projet. Cet audit permet d’identifier les vrais blocages, d’évaluer l’effort sur les sujets critiques et de savoir si votre projet relève d’un déblocage ciblé, d’un passage en production, d’un rebuild partiel ou d’une refonte complète.








