Passer d'un prototype Lovable à la production : ce qu'on garde, ce qu'on refait
Lovable, Bolt et v0 écrivent du vrai code, et il s'exporte. Ce qu'on garde (écrans, parcours, règles métier), ce qu'on refait (authentification, base, sécurité, paiement), le coût, et comment avancer sans tout jeter, dès 1 990 € HT/mois.
Sommaire
Votre prototype Lovable plaît. Vos premiers utilisateurs s'en servent. Il ne tient pas encore la production.
Passer un prototype Lovable, Bolt ou v0 en production, c'est sortir son code de l'outil, garder ce qui a fait ses preuves (les écrans, le parcours, les règles métier) et refaire ce qui protège : l'authentification, la base de données, les droits, le paiement. Le prototype devient le cahier des charges, et souvent une bonne partie du code.
Chez Figue, ce passage se fait dans l'abonnement, à 1 990 € HT/mois, sans engagement. Quand le périmètre est fermé, au forfait projet, dès 9 990 € HT, prix fixé avant de démarrer.
Que vous laissent vraiment Lovable, Bolt et v0 ?
Bonne nouvelle d'abord : ces trois outils écrivent du code standard, en React et TypeScript, et il vous appartient. Vous pouvez le sortir sur un dépôt GitHub à votre nom. Ce n'est pas le cas de Bubble, qui ne fournit pas de code. Ce qui change d'un outil à l'autre, c'est surtout où vivent vos données.
| Critère | Lovable | Bolt | v0 |
|---|---|---|---|
| Le code | Synchronisé dans les deux sens avec un dépôt GitHub privé, ou téléchargé en ZIP sur un forfait payant | Téléchargé en ZIP, ou synchronisé avec un dépôt GitHub | Synchronisé avec un dépôt GitHub, ou téléchargé en ZIP |
| La technique | React, TypeScript et Tailwind | Le plus souvent React et TypeScript, selon le projet | Next.js, TypeScript, Tailwind et shadcn/ui |
| Les données | Lovable Cloud, la base intégrée. Un export PostgreSQL complet, comptes et mots de passe chiffrés compris, se restaure chez un autre fournisseur, Supabase par exemple | Bolt Database, la base intégrée. Sur Pro ou Teams, elle se rattache à votre propre compte Supabase ; ses lignes s'exportent aussi depuis ses tables | Pas de base intégrée : une base externe, branchée par intégration sur votre compte |
| Ce qui ne sort pas | Avec la base : ni les fichiers, ni les secrets, ni les réglages de connexion (Google par exemple), à reprendre à part | Les secrets, et la base, qui ne sort pas avec le code | Les secrets et les variables d'environnement |
| Prix d'entrée | Pro dès 25 $ par mois pour 100 crédits, Business dès 50 $ | Pro dès 25 $ par mois pour 10 millions de jetons | Gratuit avec 7 messages par jour, puis Plus à 30 $ par mois et par utilisateur |
Sources publiques, relevées le 5 novembre 2026 (tarifs et règles bougent, vérifiez les conditions actuelles) : tarifs Lovable, synchronisation GitHub de Lovable, export de la base Lovable Cloud, tarifs Bolt, projets et téléchargement Bolt, intégrations Bolt, dont GitHub, rattacher Bolt Database à Supabase, tarifs v0, FAQ v0 (GitHub et export).
Le piège n'est donc pas l'export. C'est ce que contient le code exporté. Il fait ce que vous avez demandé, écran par écran. Il fait rarement ce que vous n'avez pas pensé à demander.
Ce qu'on garde, ce qu'on refait
Un prototype généré se lit par couches. Celles qui se voient ont été testées par vos utilisateurs : elles ont de la valeur. Celles qui ne se voient pas n'ont été testées par personne.
| Couche | On garde | On refait |
|---|---|---|
| Écrans et parcours | Presque tout : l'ordre des étapes, les libellés, ce que vos utilisateurs ont adopté | Les doublons et les variantes d'un même écran, fusionnés en un seul |
| Règles métier | Les règles elles-mêmes (calculs, statuts, cas particuliers), affinées en testant | Leur place : elles passent du navigateur au serveur, là où personne ne peut les contourner |
| Authentification | Les comptes existants, mots de passe compris quand l'outil les exporte (c'est le cas de Lovable) | Le contrôle d'accès : chaque requête vérifie qui demande, côté serveur, pas seulement l'écran |
| Base de données | Le schéma comme point de départ, et les données | Les règles d'accès, les migrations versionnées, les sauvegardes testées, une base de test séparée |
| Sécurité | Rien par défaut : tout se relit | Les clés sorties du code, les entrées contrôlées côté serveur, les accès partagés à plusieurs personnes |
| Paiement | La page de paiement Stripe, souvent correcte | La suite : les notifications de Stripe (paiement échoué, résiliation) qui tiennent votre base à jour |
La liste complète des vérifications de sécurité est dans vibe coding : que vérifier avant la mise en production. Et si votre projet doit devenir un SaaS vendu à d'autres entreprises, les sept briques à ajouter sont détaillées dans transformer son projet Claude en vrai SaaS.
Reprendre le code exporté ou reconstruire ?
Trois chemins. Le bon dépend de deux questions : la structure du code tient-elle, et avez-vous déjà votre propre architecture ?
Rester dans l'outil, avec une relecture
Le code est synchronisé sur GitHub. Un développeur relit, ferme les failles et pose les sauvegardes. Vous continuez à faire évoluer l'interface dans l'outil.
Quand le choisir : un outil interne simple, peu d'utilisateurs, pas d'argent qui transite. La limite arrive vite : deux sources de modifications sur le même code finissent par se marcher dessus.
Reprendre le code exporté
On coupe le lien avec l'outil. On garde l'interface et les règles, on refait les couches du dessous : comptes, base, droits, paiement. Le produit reste en ligne pendant tout le chantier.
Quand le choisir : c'est le cas le plus fréquent. Le code est lisible, les écrans tiennent, il manque ce qui protège.
Reconstruire, avec le prototype comme modèle
On reconstruit dans une architecture propre, ou dans la vôtre si elle existe déjà. Le prototype ne part pas à la poubelle : il sert de spécification. Chaque écran devient une demande, chaque règle une ligne de recette.
Quand le choisir : la logique est éparpillée dans les écrans, les données ne se cloisonnent pas proprement, ou votre vrai produit tourne déjà ailleurs. Ça se constate en lisant le code, pas en le supposant.
Trois situations qu'on rencontre
- Des évolutions faites sur une copie. Un éditeur de SaaS, dans un domaine réglementé, avait laissé son équipe faire évoluer une copie de son application sur Lovable. Les nouveautés plaisaient. Mais le vrai produit tournait sur sa propre architecture. La question n'était pas d'exporter : c'était de reporter ces évolutions, une par une, dans le code qui sert déjà les clients.
- Un prototype fonctionnel, et l'envie de confier la suite. Un porteur de projet arrive avec un prototype qui marche, fait seul avec l'IA. Il veut externaliser le développement. Le prototype ne remplace pas le cadrage, il l'accélère : on le parcourt ensemble, écran par écran, et on décide de ce qui reste.
- Plus d'une centaine de maquettes générées. Un client nous a confié plus de cent maquettes produites par IA. Beaucoup étaient des variantes du même écran. Le premier travail a été de les ramener à une liste d'écrans réels, avant tout chiffrage. Une maquette générée coûte quelques secondes ; un écran développé, non.
Comment avancer sans tout jeter ?
L'ordre compte plus que la vitesse. On commence par ce qui protège, on finit par ce qui se voit.
Figer une version et sortir le code
Connectez le projet à un dépôt GitHub à votre nom, ou téléchargez le code. Notez la version de référence. À partir de là, le code vit dans le dépôt, plus seulement dans l'outil.
Faire l'inventaire
La liste des écrans réels, des règles, des e-mails, des intégrations et des données. On fusionne les doublons. C'est cette liste qui fixe le périmètre, donc le prix.
Fermer les portes
Clés sorties du code et changées, règles d'accès relues table par table, sauvegardes automatiques, accès partagés à au moins deux personnes. Rien ne change à l'écran, et c'est normal.
Poser le socle
Une base à vous, avec ses migrations versionnées. Des comptes vérifiés côté serveur. Un environnement de test séparé, pour ne plus jamais essayer une modification sur les vraies données.
Brancher le paiement pour de bon
Abonnement, factures, carte expirée, résiliation. Le bouton « payer » ne suffit pas : votre base doit apprendre de Stripe qu'un paiement a échoué ou qu'un client est parti.
Mettre en ligne, puis avancer demande par demande
Un domaine, des e-mails qui arrivent, une alerte quand ça casse. Ensuite, chaque évolution est une demande, livrée et vérifiée une à la fois.
Combien coûte le passage en production ?
Trois options, prix affichés. La première est de continuer seul.
| Critère | Continuer seul dans l'outil | Figue Unlimited | Forfait projet Figue |
|---|---|---|---|
| Prix | Votre temps, plus l'outil (dès 25 $ par mois chez Lovable ou Bolt, relevé le 5 novembre 2026) | 1 990 € HT/mois par slot, sans engagement | Dès 9 990 € HT, prix fixé avant démarrage |
| Pour qui | Un outil pour vous seul, sans données sensibles | Un produit qui continue de bouger pendant et après la reprise | Une reprise ou une reconstruction au périmètre fermé, avec une date visée |
| Ce qui est inclus | La génération de code, sans relecture | Demandes illimitées, une active à la fois ; développement, UI/UX, IA, intégrations, review et livraison | 20 écrans sur mesure, puis 500 € HT par écran en plus ; maquettes, itérations illimitées |
| Délai | Vos soirées | Pas de délai garanti : il dépend de la complexité | En général 1 à 3 mois pour un SaaS ou un outil interne, confirmé au cadrage |
Produit qui bouge chaque semaine : l'abonnement. Périmètre fermé et date visée : le forfait. Outil pour vous seul : continuez, et sauvegardez le code.
Au forfait, le prix suit le nombre d'écrans. D'où l'inventaire : fusionner les variantes générées par l'IA, c'est souvent la première économie.
Dans les deux formules Figue, les frais tiers (hébergement, base de données, domaines, licences, APIs) restent à votre charge, facturés par vos fournisseurs. Figue peut porter ces comptes et les refacturer en prestation séparée. Tout reste transférable.
Pour situer ces montants face à un recrutement ou un freelance, voyez combien coûte un développeur.
Pour qui c'est le bon moment ?
Le bon moment, si…
- Des personnes hors de l'entreprise se connectent, ou quelqu'un a demandé à payer.
- L'outil stocke des données de clients : noms, e-mails, documents, chiffres.
- Vous passez plus de temps à corriger les générations qu'à parler à vos utilisateurs.
Pas encore, si…
- Vous cherchez encore à qui le produit sert. Continuez à tester dans l'outil : c'est le plus rapide pour ça.
- L'outil ne sert qu'à vous et ne stocke rien de sensible. Sortez le code sur GitHub, et gardez votre budget.
Transparence : Figue vend l'abonnement et le forfait, c'est donc notre préférence. Le code, les maquettes, la documentation et les structures de données vous appartiennent, et les droits vous sont cédés à mesure des livraisons, dès paiement.
Votre application tourne sur Bubble plutôt que sur une IA ? Le chemin est différent : sortir de Bubble. Vous n'avez pas encore choisi votre outil ? Lisez no-code ou sur-mesure : comment choisir.
FAQ
Questions fréquentes
Ce qu'on nous demande quand un prototype Lovable, Bolt ou v0 doit passer en production.
Peut-on exporter le code d'une application Lovable ?
Oui. Lovable synchronise le code avec un dépôt GitHub privé, et permet de le télécharger sur un forfait payant. C'est du React et du TypeScript standard, qui tourne hors de Lovable. Les données vivent à part, dans Lovable Cloud : un export de la base, comptes compris, se restaure chez un autre fournisseur. Les clés d'API sont à reposer chez le nouvel hébergeur.
Faut-il tout réécrire pour passer un prototype Lovable en production ?
Rarement. On garde les écrans, le parcours et les règles métier, que vos utilisateurs ont déjà validés. On refait les couches qui protègent : authentification vérifiée côté serveur, règles d'accès à la base, sauvegardes, paiement. Une reconstruction se justifie quand la structure du code empêche de cloisonner les données, ce qu'on constate en le lisant.
Combien coûte le passage d'un prototype IA en production ?
Chez Figue, dans l'abonnement à 1 990 € HT par mois, sans engagement, quand le produit continue d'évoluer. Au forfait projet, dès 9 990 € HT avec 20 écrans inclus, quand le périmètre est fermé. Les frais tiers (hébergement, base, domaine) restent à votre charge.
Peut-on continuer à utiliser Lovable ou Bolt une fois en production ?
Pour maquetter, oui, dans une copie. Mais dès que des développeurs travaillent dans le dépôt, le code ne doit plus être modifié dans l'outil : une génération peut écraser une correction. Une seule source de vérité, le dépôt.
Mes utilisateurs et mes données sont-ils perdus si je quitte Lovable ?
Non. Lovable exporte la base complète, comptes et mots de passe chiffrés compris : après une restauration correcte, vos utilisateurs gardent leur mot de passe. Les fichiers se téléchargent à part, les secrets et les réglages de connexion se reposent. Attention : supprimer Lovable Cloud efface aussi l'export. Téléchargez-le avant, et gardez l'ancienne base tant que la nouvelle n'est pas vérifiée.
