Reprise d'un projet Lovable ou Bolt : ce qui fait le coût, et comment l'estimer

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 : expliquer ce qui fait le coût d’une reprise, puis comment l’estimer avant de vous engager, 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.

Ces modèles ne se pilotent d'ailleurs pas de la même façon, et c'est utile à savoir avant de choisir où prototyper. Au 28 août 2026, Bolt facture des jetons, 300 000 par jour et 1 million par mois sur le plan gratuit, à partir de 10 millions par mois sur le plan Pro à 25 $, et précise lui-même que la consommation dépend de la taille du projet exposé au modèle : « plus le projet est grand, plus chaque message consomme de jetons ». Lovable facture des crédits, avec 5 crédits de build par jour en gratuit et un coût qui varie selon la complexité de la tâche. Conséquence directe sur une reprise : chez Bolt, un prototype devenu gros coûte cher à faire évoluer, ce qui pousse mécaniquement vers la reprise en code. Grilles : Bolt et Lovable.

Le problème, c’est que la “vitesse prototype” s’obtient souvent au prix de compromis qui ressortent plus tard. Ce sont eux qui font le coût d’une reprise.

Les 6 facteurs qui font le coût d’une reprise

Sans audit, personne ne peut donner « le prix » de votre reprise. En revanche, on sait ce qui le fait varier : six facteurs, qui décident de l’effort à fournir. Si vous recevez deux devis très éloignés, c’est souvent qu’ils ne font pas la même hypothèse sur l’un d’eux.

1. L’état du code

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.

C’est le premier facteur de coût. Un code lisible se corrige par petites touches ; un code très couplé oblige à reprendre des fondations avant de toucher au reste.

2. La sécurité et l’authentification

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.

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)
  

Un point précis mérite d'être testé avant tout devis de reprise, car il change le diagnostic : si le backend est Supabase, la sécurité au niveau des lignes est désactivée par défaut sur les nouvelles tables. Tant qu'elle ne l'est pas, la clé publique embarquée dans le front donne accès à la table entière depuis le navigateur, quel que soit ce que l'interface affiche. Le test prend une minute depuis un onglet privé, et son résultat peut changer à lui seul l’ampleur de la reprise. Ce n'est pas un cas exotique : le contrôle d'accès défaillant est la première catégorie de l'OWASP Top 10. Références : la Row Level Security de Supabase et OWASP A01.

3. Le modèle de données

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.

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
  

L’effort grimpe vite si les données existent déjà et qu’il faut reprendre sans perdre d’historique.

4. Le déploiement

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

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
  

5. La performance

Avec de vrais utilisateurs et de vraies données, les requêtes lentes, l’absence de cache et les écrans trop lourds se voient tout de suite. L’effort dépend du nombre d’écrans et de cas limites.

Sur la performance, il vaut mieux viser un seuil public qu'une impression. Les Core Web Vitals fixent trois cibles mesurables : LCP inférieur à 2,5 secondes, INP inférieur ou égal à 200 millisecondes, CLS inférieur ou égal à 0,1, au 75e centile des chargements, séparément sur mobile et sur ordinateur. Formuler la reprise ainsi change la conversation avec un prestataire : on ne demande plus « que ce soit plus rapide », on demande d'atteindre trois nombres vérifiables. Référence : les Core Web Vitals.

6. Les tests et l’observabilité

Sans tests sur les parcours clés ni journaux exploitables, chaque correction risque d’en casser une autre, et vous découvrez les erreurs en même temps que vos utilisateurs. Inutile de viser 100 % de couverture : il s’agit de protéger ce qui compte.

• gestion d’erreurs propre
  
• logs exploitables
  
• monitoring, alertes
  
• tests ciblés (pas forcément 100% de couverture, mais les parcours clés)
  

Ce qui alourdit 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.
‍

Trois situations fréquentes, et ce qui fait leur coût

“On a une V0, mais impossible de déployer”

Souvent un mélange de dépendances, variables d’environnement, build, et routes server/client.

Ce qui fait le coût : la propreté du dépôt et le besoin d’industrialiser le déploiement.

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

Ce qui fait le coût : le nombre de rôles, d’espaces et de données par client à sécuriser.

“Les données partent dans tous les sens”

Modèle flou, champs qui changent, exports impossibles, bugs en cascade.

Ce qui fait le coût : la reprise du modèle et la migration des données, surtout s’il faut migrer sans perte.
‍

Pour reprendre le contrôle complet de votre application Lovable, voir notre guide Jailbreak Lovable.

Comment estimer le coût de votre reprise

Étape 1 : une auto-évaluation 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 de l’ampleur de la reprise.

1. Est-ce que quelqu’un peut expliquer l’architecture en 5 minutes ?
   
2. L’auth est-elle réelle, avec rôles et parcours complets ?
   
3. Le modèle de données est-il clair, avec des contraintes et une logique métier lisible ?
   
4. Le déploiement est-il reproductible, ou c’est “ça marche sur ma machine” ?
   
5. En cas d’erreur, est-ce qu’on a des logs utiles, ou rien ?
   
6. Si on ajoute 10 fonctionnalités, est-ce que ça tient, ou ça casse partout ?
   

Si vous répondez “non” à 3 questions ou plus, attendez-vous à une reprise qui touche plusieurs fondations, pas à un simple correctif.
‍

Étape 2 : un diagnostic de 48 h, offert

En 48 heures, on examine le code, l’authentification, le modèle de données et le déploiement de votre projet. Vous recevez un diagnostic écrit : ce qui marche, ce qui casse, ce qui menace, et un plan d’action. Le diagnostic est offert et sans engagement : vous repartez avec le rapport, même si vous ne donnez pas suite.

Étape 3 : un chiffrage sur mesure

À partir du diagnostic, chaque reprise est chiffrée sur mesure. Le chiffrage porte uniquement sur ce qui vous rapproche de la production : vous évitez le devis énorme « au cas où », et le petit devis qui explose en route.

Durées indicatives

Chez Scroll, un premier diagnostic est offert sous 48 h. Un audit approfondi prend 1 à 3 jours, et son rapport arrive en moins d'une semaine. Une stabilisation avant mise en production demande en général 1 à 3 semaines. Une reprise complète prend 6 à 12 semaines, et jusqu'à 16 pour les plus gros périmètres. Exemple : un ERP construit avec Lovable (62 écrans) est passé en production 7 semaines après le début du chantier. Ce qui fait varier ces délais, c'est l'état du code et la rapidité des accès : vous recevez un calendrier ferme avec l'audit.

• Audit : …
• Stabilisation : …
• Reprise complète : …

Reprise de projets IA : une offre pensée pour débloquer vite, sans surpayer

Chez Scroll, on a créé l'offre de reprise de projets IA pour répondre exactement à ce moment où tout se joue : entre prototype vibe code et production.

Le principe est volontairement simple :

1. Diagnostic : on regarde votre projet, on identifie le vrai blocage, et on vous donne un plan clair.
   
2. Fix ciblé : on intervient uniquement là où ça bloque vraiment, sur l’un des 4 grands sujets : déploiement, auth, données, performance.
   
3. 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.
‍

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 de reprise IA : é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 quelle ampleur de reprise est nécessaire. 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 de reprise de projets IA de Scroll : diagnostic, identification du blocage, puis fix ciblé sur le déploiement, l’auth, les données ou la performance.