Reprendre une app Bolt.new ou v0 : ce qui change par rapport à une app Lovable

Une application générée par IA arrive chez celui qui la reprend avec les choix de l’outil qui l’a produite : un framework, une base de données, un hébergeur, une façon de synchroniser le code. Pour une app Lovable, ces choix sont connus : React et Supabase, avec Lovable Cloud par défaut. Pour Bolt.new et v0, le point de départ est différent, et les premières heures d’une reprise ne se passent pas au même endroit.

Cet article ne parle pas de budget (nous l’avons fait dans ce que coûte la reprise d’une app Lovable, Bolt ou v0) ni de migration de framework (voir migrer une app Lovable vers Next.js). Il répond à une question plus en amont : selon l’outil, qu’est-ce qu’on a vraiment entre les mains, où sont le code et les données, et que faut-il vérifier en premier ? Nous avons repris et mis en production une douzaine d’applications générées par IA, dont une application RH et une messagerie chiffrée interne d’entreprise où il a fallu corriger de nombreuses failles de sécurité. Les faits sur Bolt, v0 et Lovable ci-dessous ont été vérifiés sur leurs documentations officielles en octobre 2026.

Le tableau comparatif

Sources : FAQ Lovable, mise à niveau TanStack Start, Lovable Cloud et Supabase, GitHub chez Lovable, FAQ Bolt, technologies prises en charge par Bolt, applications full-stack v0, sandbox v0 et éditeur de code v0 (pages consultées en octobre 2026).

La différence qui compte le plus se lit dans la ligne « base de données ». Avec Lovable, on sait presque toujours qu’on va auditer du Supabase. Avec Bolt, il faut d’abord savoir si la base est une Bolt Database ou un projet Supabase, parce que les outils d’accès ne sont pas les mêmes. Avec v0, la base peut être n’importe lequel des fournisseurs de la Marketplace, rattaché au compte Vercel de quelqu’un.

Reprendre une app Bolt.new

Ce que Bolt génère

Bolt fonctionne sur les WebContainers, la technologie de StackBlitz qui fait tourner un environnement de développement complet dans le navigateur. Côté code, la documentation est large : tout framework JavaScript qui s’exécute côté front, et Node.js pour le back-end. PHP et Python ne sont pas pris en charge, et un projet peut devenir une application mobile avec Expo.

Conséquence pour la reprise : on ne peut pas deviner la stack. Un projet Bolt peut être une application Vite, un Next.js, une app Expo. La première commande d’un audit est donc la même que pour une app Lovable ancienne, mais avec plus de réponses possibles : ouvrir le package.json.

Où vivent les données

Chez Bolt, les nouveaux projets utilisent par défaut une Bolt Database, créée automatiquement dès que le projet en a besoin. Elle inclut l’authentification, le stockage de fichiers, des server functions et un gestionnaire de secrets, le tout administré depuis l’interface de Bolt. Sur les plans Pro et Teams, on peut choisir Supabase à la création du projet, ou brancher un projet Supabase existant.

Pour celui qui reprend, cela change l’outillage. La documentation de la Bolt Database décrit la consultation, le filtrage et l’export des lignes depuis l’onglet Tables, des journaux (dont PostgreSQL) et un audit de sécurité, mais pas d’éditeur SQL. Bolt le dit lui-même : si vous avez besoin d’outils externes, d’édition SQL ou de supervision avancée, passez par Supabase. Pour une base déjà créée, l’option s’appelle « Claim » : elle transfère la Bolt Database dans votre propre compte Supabase, sur un plan Pro ou Teams. Attention, la page générale sur la base affirme dans le même temps qu’il n’existe pas de migration prise en charge d’une Bolt Database vers Supabase : les deux pages se contredisent, faites l’opération sur une copie avant de compter dessus.

Récupérer le code

Deux voies, documentées par Bolt :

• GitHub : la synchronisation fonctionne dans les deux sens. Bolt crée un commit à chaque modification qui ne casse pas le projet, et vérifie GitHub toutes les 30 secondes pour récupérer ce qui a été poussé ailleurs. On peut créer des branches depuis Bolt, mais pas les fusionner : la fusion se fait dans GitHub. On peut aussi importer un dépôt existant dans un nouveau projet Bolt, ce que Lovable ne permet pas ;
• le téléchargement : depuis le titre du projet, Download produit un .zip de tous les fichiers, à ouvrir dans votre propre éditeur.

Aucune des deux ne sort la base. Le .zip et le dépôt contiennent le code, les migrations éventuelles et les appels aux server functions ; les données, les utilisateurs et les secrets restent dans Bolt Cloud ou dans Supabase.

Les pièges propres à Bolt

• Les règles d’accès des sites sans connexion. La documentation de sécurité de Bolt prévient que si vous n’avez pas demandé de connexion, Bolt peut écrire des règles RLS qui laissent n’importe quel visiteur lire, ajouter, modifier et supprimer les données. C’est le premier point à vérifier sur une app qui a ajouté l’authentification tard. L’onglet Security Audit reprend les contrôles du Security Advisor de Supabase, mais il ne regarde que la base, pas le code.
• Brancher Supabase écrase la base existante. Sur un projet qui a déjà une Bolt Database, connecter un projet Supabase remplace la connexion et peut entraîner une perte de données. C’est l’erreur typique d’une reprise faite trop vite.
• L’historique de versions ne restaure pas la base. Revenir à une version antérieure du projet ne modifie ni la Bolt Database ni Supabase. Le code revient en arrière, le schéma et les données non : un retour arrière peut laisser un code qui ne correspond plus à sa base.
• Le conflit de synchronisation tranche en faveur de Bolt. Si Bolt et GitHub sont modifiés presque en même temps, Bolt garde ses changements et écrase la version GitHub. Et déconnecter un projet de GitHub est définitif : pour le relier de nouveau au même dépôt, il faut passer par le support.
• La base en pause et l’hébergement plafonné. Sur un projet non publié, une base peu utilisée pendant six jours peut être mise en pause. Une fois publié, un site qui atteint la limite d’hébergement de son plan n’est plus affiché publiquement jusqu’au cycle de facturation suivant.
• Le domaine acheté chez Bolt. Les domaines personnalisés ne suivent pas un transfert de projet, et un domaine acheté via Bolt ne peut pas être reconnecté avant son expiration après un transfert. Si le projet doit changer de compte, réglez la question du domaine d’abord.

Checklist de reprise Bolt

• Le projet est relié à un dépôt GitHub au nom du founder, ou au moins téléchargé en .zip.
• Le package.json est lu : framework, version, présence d’Expo.
• On sait si la base est une Bolt Database ou un projet Supabase, et à quel compte elle appartient.
• L’onglet Security Audit est vide, et chaque table a des règles RLS qui correspondent au modèle de droits voulu.
• Les secrets sont dans l’onglet Secrets et lus par des server functions, pas écrits dans le code envoyé au navigateur.
• Les données ont été exportées, et la décision « rester en Bolt Database ou faire un Claim vers Supabase » est prise, testée sur une copie.
• L’hébergeur (Bolt hosting ou Netlify), le plan et le propriétaire du domaine sont identifiés.
• Une règle est posée : plus de modification simultanée dans Bolt et dans le dépôt.

Reprendre un projet v0

Ce que v0 génère

v0 est l’outil de Vercel, et ses choix techniques en découlent. Il génère du Next.js par défaut, avec React Server Components, routes App Router, TypeScript, Tailwind CSS et shadcn/ui. Depuis le passage à la Vercel Sandbox, l’aperçu tourne dans une vraie machine virtuelle Node.js, capable d’exécuter les routes d’API et de se connecter à une base, alors que l’ancien aperçu dans le navigateur ne le pouvait pas.

Pour la reprise, c’est plutôt une bonne nouvelle : le code est déjà dans le framework vers lequel beaucoup de projets Lovable cherchent à migrer, avec des conventions qu’un développeur Next.js reconnaît.

Où vivent les données

C’est là que v0 diffère le plus. v0 n’a pas de base intégrée : il propose des intégrations en un clic avec Supabase, Neon, Upstash et Vercel Blob, installées depuis la Vercel Marketplace. Chaque intégration crée un compte chez le fournisseur et ajoute les variables d’environnement au projet Vercel. Une app v0 peut donc avoir sa base chez Neon, ses fichiers dans Vercel Blob et son cache chez Upstash, chacun relié au compte Vercel de la personne qui a cliqué.

Installé via la Marketplace, Supabase est facturé par Vercel, l’organisation Supabase correspond une pour une à l’équipe Vercel, les rôles se gèrent dans Vercel, et les nouveaux projets ne se créent que depuis le tableau de bord Vercel. La question « à qui appartient la base » se pose donc au niveau de l’équipe Vercel.

Côté code, v0 n’utilise pas d’ORM par défaut : les requêtes sont écrites directement avec le client du fournisseur, souvent dans des Server Actions ou des Route Handlers.

Récupérer le code

La voie normale est GitHub. Depuis les réglages du projet, v0 crée un dépôt privé sous le compte ou l’organisation choisie et y pousse le code. Ensuite, chaque modification part sur une branche de travail, jamais directement sur la branche de base ; le bouton Publish ouvre ou réutilise une pull request, la fusionne et attend le déploiement de production. Les règles de protection de branche s’appliquent : on peut imposer une revue humaine avant toute mise en production.

Deux points de la documentation sont à retenir. Le dépôt connecté devient la source de vérité : s’il est supprimé, le code peut être irrécupérable. Et sans GitHub, l’éditeur de v0 permet de télécharger les fichiers un par un, pas un export complet : connectez le dépôt avant toute autre chose.

Les pièges propres à v0

• Les Server Actions sont des points d’entrée publics. La documentation de Next.js est explicite : une Server Action exportée est joignable par une requête POST directe, et le contrôle d’accès d’une page ne s’étend pas aux actions qu’elle définit. Chaque action doit vérifier qui l’appelle et si cette personne a le droit d’agir sur cette ressource. C’est l’équivalent, pour v0, du RLS absent chez Lovable : la faille la plus fréquente et la moins visible en démo.
• Les variables NEXT_PUBLIC_. Seules les variables préfixées NEXT_PUBLIC_ arrivent dans le navigateur. v0 analyse leur usage et prévient des risques, mais une clé secrète renommée avec ce préfixe pour « faire marcher » un composant client reste exposée. Une recherche de NEXT_PUBLIC_ dans le dépôt prend une minute.
• L’aperçu et la production n’ont pas les mêmes variables. Les aperçus v0 n’accèdent qu’aux variables de l’environnement Development du projet Vercel. Une app peut fonctionner dans l’aperçu et échouer en production, ou l’inverse, selon ce qui a été saisi où.
• Plusieurs chats, une seule production. Un projet v0 peut être alimenté par plusieurs conversations, et publier depuis n’importe laquelle met à jour la même URL de production. Avant de reprendre, listez les chats rattachés au projet et désignez celui qui fait foi.
• Les bacs à sable de paiement non réclamés. Au premier Publish, v0 fait passer en revue les bacs à sable de test Stripe non réclamés et propose de les réclamer avant la mise en ligne. Un compte Stripe qui n’est pas au nom du founder est un problème à régler avant le premier paiement réel.

Checklist de reprise v0

• Le projet est connecté à un dépôt GitHub dans l’organisation du founder, et l’application GitHub de Vercel y a accès.
• La branche de production est protégée : pull request et revue obligatoires.
• Le projet Vercel et chaque intégration Marketplace (base, stockage, cache) appartiennent à l’équipe Vercel du founder.
• Chaque Server Action et chaque Route Handler vérifie l’authentification et l’autorisation.
• Aucune clé secrète ne porte le préfixe NEXT_PUBLIC_.
• Les variables Development, Preview et Production sont distinctes et complètes.
• Si la base est Supabase et que le navigateur l’interroge directement, le RLS est vérifié comme sur une app Lovable.
• Les chats rattachés au projet sont listés, et un seul sert désormais à générer.

Ce qui ne change pas d’un outil à l’autre

Que l’app vienne de Lovable, de Bolt ou de v0, la moitié du travail est identique. Dès qu’une base Supabase est interrogée depuis le navigateur, sa sécurité repose sur le RLS : notre check-list de sécurité Lovable et Supabase s’applique telle quelle à une app Bolt branchée sur Supabase, et en grande partie à une Bolt Database, qui utilise les mêmes contrôles. Les briques d’exploitation (e-mails transactionnels, sauvegardes testées, supervision, Stripe en mode live) manquent aussi souvent dans les trois cas ; la check-list de mise en production se lit en remplaçant Lovable par l’outil concerné. Les défauts du code généré, enfin, ne dépendent pas de l’outil : duplication, logique métier dans l’interface, absence de tests.

Ce qui change, c’est l’ordre des opérations :

1. Lovable : récupérer le dépôt, puis savoir si la base est sur Lovable Cloud ou sur votre Supabase, puis le RLS.
2. Bolt : savoir quelle base on a, l’exporter, puis le RLS et les server functions, sans jamais brancher Supabase sur une Bolt Database à la légère.
3. v0 : connecter GitHub, rapatrier les intégrations Marketplace dans la bonne équipe Vercel, puis auditer les Server Actions.

La propriété avant tout le reste

Les trois outils disent que le code vous appartient : Bolt indique que le code créé avec Bolt et StackBlitz est le vôtre, y compris pour un usage commercial, et Vercel qu’il ne possède pas le code généré par v0. Mais posséder le code ne suffit pas si le dépôt, la base, l’hébergeur, le domaine et le compte Stripe sont dispersés entre votre compte, celui d’un associé et celui d’un freelance passé par là. Une reprise commence par un inventaire des comptes, et par le transfert de tout ce qui n’est pas à votre nom. Nous avons détaillé pourquoi dans notre article sur la réversibilité et la propriété du code.

Si vous ne savez pas encore laquelle de ces situations est la vôtre, c’est exactement ce que tranche notre audit de reprise d’app Lovable, Bolt ou v0 : un état des lieux de la sécurité, du code et de ce qui manque pour la production, adapté à l’outil d’origine, et un verdict écrit sous 48 h, garder et renforcer ou refaire.