Combien coûte la reprise d’une app Lovable, Bolt ou v0 pour la mettre en production ?

Deux applications Lovable peuvent avoir les mêmes écrans, le même parcours d’inscription, le même tableau de bord, et coûter des sommes sans rapport à mettre en production. Ce qui fait la différence ne se voit pas dans la démo : les règles d’accès de la base, la façon dont les prompts successifs ont empilé le code, et la liste de ce qui manque encore pour accueillir des clients qui paient. C’est pour cela qu’aucun prestataire sérieux ne peut chiffrer une reprise à partir d’une capture d’écran ou d’un lien vers l’application.

Chez Raicode, nous avons repris et mis en production une douzaine d’applications générées par IA, venues de Lovable, Bolt, v0, Cursor ou Claude Code, dont une application RH et une messagerie chiffrée interne d’entreprise où il a fallu corriger de nombreuses failles de sécurité. Cet article ne donne pas de prix : il explique ce qui fait monter ou baisser la facture, comment lire le devis qu’on vous remettra, et quels pièges coûtent le plus cher.

Ce qu’on paie vraiment dans une reprise

Une reprise n’achète pas des écrans : vous les avez déjà. Elle achète du travail sur quatre postes, dont le poids varie d’un projet à l’autre :

• fermer ce qui est ouvert : règles d’accès, clés exposées, fonctions appelables sans connexion ;
• rendre le code maintenable : le sortir des prompts, le ranger, poser des tests sur les parcours qui comptent ;
• ajouter ce qui manque pour la production : paiement, e-mails, sauvegardes, supervision ;
• décider ce qu’on garde : renforcer l’existant ou refaire une partie, voire tout.

Le coût d’une reprise, c’est la somme de ces postes, mesurée en jours de travail. Et chacun dépend de l’état réel du projet, que seule une lecture du code révèle.

Premier facteur : l’état de la sécurité Supabase

La plupart des applications Lovable, et une bonne partie de celles faites avec Bolt ou v0, sont des applications React qui parlent directement à Supabase depuis le navigateur. Ce modèle ne tient que si la base refuse elle-même ce qui n’est pas autorisé, grâce au Row Level Security (RLS). Quand ces règles manquent ou laissent tout passer, la clé publique présente dans le code du site suffit pour lire les données de tous vos clients.

Le cas n’a rien de rare. En mai 2025, Matt Palmer a publié l’analyse de 1 645 applications de la vitrine Lovable : 170 d’entre elles avaient des réglages RLS insuffisants, soit environ 10,3 %.

Pour le coût, trois situations reviennent :

• le RLS est actif et les règles sont à peu près justes : il s’agit de les relire table par table, d’en resserrer quelques-unes, de vérifier les fonctions. C’est le cas le moins coûteux ;
• le RLS est absent ou ouvert à tous : il faut écrire les règles une à une, et surtout comprendre qui doit voir quoi. Dans une application B2B où plusieurs utilisateurs partagent les données d’une même entreprise, cela suppose souvent d’ajouter une notion d’organisation que le modèle de données n’avait pas prévue ;
• des secrets sont dans le code envoyé au navigateur : clé service_role, clé OpenAI ou Stripe. Il faut les révoquer, déplacer les traitements concernés côté serveur, dans des Edge Functions, et vérifier que chacune contrôle qui l’appelle.

Le troisième cas pèse plus lourd qu’il n’y paraît, parce qu’il touche à l’architecture : un traitement qui passait du navigateur à un service tiers doit maintenant transiter par une fonction serveur, avec authentification et gestion d’erreur.

Un audit ne garantit pas une sécurité absolue. Il dit ce qui est ouvert aujourd’hui et ce qu’il faut fermer avant d’accueillir des clients, ce qui suffit à chiffrer ce poste.

Deuxième facteur : la dette du code généré

Un outil de génération produit du code qui marche, mais il le produit par couches. Chaque prompt ajoute, rarement il retire. Après quelques centaines d’itérations, on retrouve les mêmes symptômes :

• du code dupliqué : trois composants qui font presque la même chose, parce qu’aucun prompt n’a demandé de factoriser ;
• de la logique métier dans l’interface : un calcul de prix ou une règle de droits écrits dans un composant React, donc contournables depuis le navigateur ;
• des requêtes lancées en boucle : une liste qui appelle la base une fois par ligne, invisible avec dix enregistrements de test, pénible avec mille ;
• des dépendances jamais mises à jour, et parfois deux bibliothèques qui font la même chose ;
• aucun test, d’où un symptôme familier : chaque correction en casse une autre.

Cette dette ne se paie pas forcément d’un coup. Une partie se rembourse au fil de l’eau, une partie se tolère, une partie bloque l’ouverture et passe en premier. Nous avons détaillé cet arbitrage dans ce qu’on accepte et ce qu’on refuse en dette technique sur un MVP, et les défauts typiques du code produit par IA dans ce qu’il faut reprendre sur un MVP codé par IA.

Ce qui fait varier le coût, c’est moins le volume de code que sa lisibilité : un développeur peut-il comprendre un écran sans relire tout le projet ? Si oui, la reprise avance par morceaux. Si non, chaque modification commence par une enquête.

Troisième facteur : ce qui manque pour la production

C’est le poste le plus sous-estimé, parce qu’il ne se voit pas en démo. Une application qui fonctionne pour cinq testeurs peut ignorer tout ce qui suit :

• le paiement : un bouton Stripe qui fonctionne en mode test ne suffit pas. Il faut des webhooks dont la signature est vérifiée, la gestion des échecs de paiement, des abonnements résiliés, des remboursements, et un accès au service qui suit l’état de l’abonnement ;
• les e-mails transactionnels : le fournisseur intégré de Supabase est limité à 2 e-mails par heure, et ce plafond ne se relève qu’avec votre propre SMTP. Au lancement, les confirmations d’inscription cessent d’arriver. Il faut un service d’envoi, un domaine configuré et des modèles d’e-mails ;
• les sauvegardes : Supabase sauvegarde chaque jour les projets Pro, Team et Enterprise, pas ceux du plan gratuit, et ces sauvegardes n’incluent pas les fichiers du Storage. Il faut choisir une politique, la mettre en place et faire au moins un essai de restauration ;
• la supervision : savoir qu’une erreur se produit avant qu’un client vous l’écrive. Remontée des erreurs, surveillance de disponibilité, alertes sur les fonctions qui coûtent à chaque appel ;
• les tests : pas une couverture exhaustive, mais des tests sur les parcours dont dépend le chiffre d’affaires, inscription, paiement, action principale ;
• l’environnement : un nom de domaine, des variables séparées entre préproduction et production, un déploiement reproductible.

Chaque brique absente est un morceau de travail en plus. Une application qui a déjà Stripe branché proprement et un SMTP configuré se reprend plus vite qu’une application identique à l’écran qui n’a rien de tout cela.

Garder et renforcer, ou refaire

C’est la décision qui pèse le plus sur le coût, et celle qu’on prend trop souvent sans critère.

Garder et renforcer se justifie quand :

• le modèle de données tient la route ;
• les failles se corrigent sans tout réécrire ;
• le parcours principal fonctionne de bout en bout.

Refaire se justifie quand :

• les données sont à restructurer de fond en comble ;
• chaque correction en déclenche d’autres ;
• le besoin a changé depuis le prototype, au point que le code ne correspond plus au produit.

Même dans le second cas, on ne repart pas de zéro : les écrans, le parcours validé par vos testeurs, vos contenus et ce que vous avez appris de vos premiers utilisateurs se gardent. Refaire, c’est reconstruire les fondations sous une interface qui a déjà fait ses preuves. Le chiffrage d’une reconstruction se rapproche alors de celui d’un MVP, et notre article sur la lecture d’un devis de MVP SaaS s’applique.

Rester sur la même stack fait aussi partie de la décision. Une application Lovable, c’est du React et Supabase, avec Vite pour les projets créés avant le 13 mai 2026 et TanStack Start pour les suivants, et elle peut très bien le rester. Migrer vers Next.js a un coût réel ; cela se justifie quand le référencement ou le rendu côté serveur l’exigent, pas par habitude du prestataire.

Comment lire un devis de reprise

Un devis de reprise sérieux ressemble davantage à un rapport qu’à une ligne « reprise de l’application ». Ce qu’il doit contenir :

• un état des lieux écrit : ce qui a été regardé, avec quels accès, et ce qui a été trouvé ;
• des postes séparés : sécurité, stabilisation du code, briques de production, évolutions fonctionnelles. Vous devez pouvoir retirer une ligne et savoir ce que vous perdez ;
• un ordre de priorité : ce qui bloque l’ouverture à vos clients d’abord, le confort ensuite ;
• le verdict et ses raisons : garder ou refaire, avec des critères que vous pouvez discuter ;
• ce qui n’est pas inclus : une migration de framework, une refonte graphique, de nouvelles fonctionnalités ;
• la propriété : le dépôt, la base, l’hébergement, Stripe et le nom de domaine restent à votre nom.

Le dernier point compte autant que le montant. Un prestataire qui héberge votre code sur ses propres comptes vous rend dépendant dès le premier jour ; nous l’avons développé dans notre article sur la réversibilité et la propriété du code.

Méfiez-vous aussi d’un devis trop précis trop tôt. Un chiffrage au jour près remis sans accès au code ni à la base est une estimation au jugé, présentée comme un engagement.

Les pièges qui font déraper la facture

Le devis à l’heure sans plafond

La régie a sa place, pour l’exploitation et les petites évolutions. Pour une reprise dont personne ne connaît encore l’ampleur, elle fait porter tout le risque sur vous : chaque découverte dans le code devient des heures facturées, sans point d’arrêt. Si vous acceptez une facturation au temps passé, exigez un plafond par lot, et un point de décision écrit avant de le dépasser.

« On refait tout » par réflexe

Beaucoup de développeurs préfèrent leur propre code au code d’un autre, et à plus forte raison au code généré. Proposer de tout réécrire est confortable pour eux, et plus cher pour vous. La question à poser est simple : quels critères vous ont conduit à ce verdict ? Si la réponse est « le code est sale », ce n’est pas un critère. Si c’est « le modèle de données ne permet pas d’isoler les clients entre eux, et chaque table devrait changer », on peut en discuter.

L’inverse existe aussi : un prestataire qui promet de « juste corriger quelques failles » sur un projet dont les fondations ne tiendront pas trois mois. Le verdict doit être argumenté dans les deux sens.

Les crédits Lovable qui flambent

Tant que les corrections passent par des prompts, chacune se paie. La documentation de Lovable indique qu’en mode Build, le coût d’une demande dépend de sa complexité et du travail effectué (page consultée le 11 octobre 2026). Une correction de sécurité qui demande plusieurs allers-retours, qui en défait une autre, puis qu’on relance, consomme d’autant plus que le projet est gros et emmêlé.

Ce coût ne figure dans aucun devis, mais il compte dans la comparaison. Une fois le code repris dans un dépôt à votre nom, les corrections ne passent plus par des prompts facturés. Lovable propose une synchronisation dans les deux sens avec GitHub, sur une branche à la fois : vous pouvez continuer à prototyper de nouveaux écrans dans Lovable, à condition de convenir de la façon dont ces changements arrivent dans le code repris, pour qu’une nouvelle génération ne défasse pas une correction.

Le cas Bubble

Bubble n’exporte pas de code. Il n’y a donc rien à reprendre au sens propre : une application Bubble se reconstruit, et le budget est celui d’un développement de MVP SaaS, pas celui d’une reprise.

Pourquoi nous commençons par un audit à prix fixe

Puisque le coût dépend de ce qu’on trouve dans le code, la seule façon honnête de le chiffrer est de regarder d’abord. C’est le rôle de notre audit de reprise d’application Lovable, Bolt ou v0 :

• un prix fixe, communiqué sur WhatsApp avant de commencer : vous savez ce que coûte la réponse avant de la demander ;
• un verdict écrit sous 48 h après réception des accès : garder et renforcer, ou refaire, avec les critères ;
• un périmètre défini : sécurité (règles RLS, clés et secrets, authentification, fonctions exposées), qualité du code, ce qui manque pour la production, et l’estimation du coût de la reprise, poste par poste et par ordre de priorité ;
• aucun engagement au-delà : vous pouvez confier la reprise à quelqu’un d’autre avec le rapport, ou ne rien faire pour l’instant.

Le prix fixe inverse le risque du devis à l’heure : c’est à nous de tenir le périmètre, pas à vous de surveiller un compteur. Et le verdict sous 48 h évite de payer des semaines de découverte avant de savoir si l’application vaut d’être gardée. Pour un projet construit avec un autre outil ou par une autre équipe, la démarche est la même dans notre offre de reprise de projet IA, dont nous avons décrit la première semaine d’audit.

Ce que vous pouvez préparer avant de demander un chiffrage

Plus le prestataire voit, plus son estimation est fiable. Avant le premier échange, rassemblez :

• le lien de l’application et l’outil qui l’a générée ;
• un accès en lecture au code, idéalement via un dépôt GitHub à votre nom ;
• un accès en lecture au projet Supabase, ou à défaut une exportation du schéma ;
• la liste de ce qui vous inquiète : données exposées, lenteurs, corrections qui en cassent d’autres ;
• votre échéance : une date d’ouverture, une démonstration, une levée de fonds ;
• ce qui doit absolument rester : les écrans validés par vos utilisateurs, une intégration à laquelle vous tenez.

Ces éléments suffisent pour un audit. Ils permettent aussi de comparer deux prestataires sur la même base, ce qui est rare.

La prochaine étape

Si votre application tourne en démo et que vous préparez l’arrivée de vrais clients, ne commencez pas par demander un prix global : demandez d’abord ce qu’il y a dans le code. Envoyez le lien de votre app sur WhatsApp ou décrivez-la par écrit via le formulaire : vous recevez le prix de l’audit, puis, sous 48 h après réception des accès, le verdict et l’estimation de la reprise. Le détail de la démarche est sur notre page reprise d’app Lovable, Bolt et v0.