Comment quitter Lovable Cloud pour votre propre Supabase

Pourquoi quitter Lovable Cloud

Lovable propose désormais trois actions en libre-service, dans More → Cloud → Overview → Advanced settings :

• Export project data crée une sauvegarde de la base qui contient sa structure, les données, les règles de sécurité et les comptes utilisateurs. Le fichier d’export peut atteindre 5 Go, à raison d’un export toutes les 24 heures.
• Pause Cloud empêche une instance inactive de consommer des crédits, sans la supprimer.
• Remove Lovable Cloud supprime définitivement l’instance Cloud.

Export project data, Pause Cloud et Remove Lovable Cloud, en bas de la page Advanced settings · cliquer pour agrandir

BWorlds a testé le parcours de migration de bout en bout, y compris la conservation des mots de passe et la reconnexion du même projet Lovable à un Supabase au nom du client. La suppression de Cloud vient toujours en dernier : exportez, restaurez, déplacez le reste du backend et vérifiez la destination avant d’effacer quoi que ce soit.

Comment ce guide est organisé

Ce guide compte trois phases. Celles dont vous avez besoin dépendent de là où vous voulez arriver :

• Phase 1 : reprendre vos données. Vous créez votre propre projet Supabase et vous y copiez votre base, vos utilisateurs, vos fichiers, vos fonctions et vos secrets depuis Lovable Cloud, avec l’export officiel de Lovable pour la base. Pendant ce temps, votre app continue de tourner sur Cloud, sans que rien n’y change. Tout le monde commence par là.
• Phase 2 : reprendre l’hébergement. Vous mettez votre frontend en ligne sur Vercel, pour que votre app ne dépende plus de l’hébergement de Lovable. Faites cette phase si vous voulez une infrastructure entièrement sous votre contrôle, ou si vous comptez continuer avec un autre outil d’IA. Si vous voulez continuer à publier depuis Lovable, passez-la.
• Phase 3 : couper le cordon. Vous supprimez l’ancienne instance Lovable Cloud et, si vous restez sur Lovable, vous connectez votre propre Supabase au même projet pour continuer à créer exactement comme avant. La suppression est définitive et ne déplace aucune donnée à votre place : c’est pour ça qu’elle vient en dernier.

À la fin, vous trouverez la marche à suivre en cas d’urgence, pour le jour où Lovable Cloud tombe en panne. Si vous avez déjà fait les phases 1 et 2, vous n’aurez rien à faire. Si vous n’avez fait que la phase 1, votre app peut tourner sur votre propre hébergement en 20 minutes environ.

Ce qui migre, et comment

Lors d’un test de migration de bout en bout, BWorlds a vérifié la restauration complète du schéma d’authentification et la reconnexion au même projet.

Pendant la migration, gardez vos identifiants pour vous

Ne collez jamais un mot de passe, une clé secrète ou des données clients dans un prompt, même quand un outil d’IA vous aide à migrer.

La sauvegarde exportée contient les données personnelles de vos utilisateurs : gardez-la pour vous, stockez-la uniquement sur votre propre machine et supprimez-la une fois la migration terminée et vérifiée.

Phase 1 : reprendre vos données

L’objectif : une copie vérifiée de votre base, de vos utilisateurs, de vos fichiers, de vos fonctions et de vos secrets sur un projet Supabase que vous contrôlez, pendant que votre app continue de tourner sur Lovable Cloud, sans que rien n’y change.

Il vous faut : un compte Supabase, un compte GitHub, et 2 à 4 heures selon l’app. La restauration de la base passe par des outils en ligne de commande : suivez la procédure vérifiée ci-dessous.

Avant de commencer : l’export est une photographie à un instant donné. Tout ce que vos utilisateurs écrivent après le lancement de l’export n’y sera pas. Pour la bascule finale, mettez d’abord votre app hors ligne, pour qu’aucune donnée ne soit créée après la sauvegarde. Lovable n’a pas de mode maintenance, mais vous pouvez dépublier votre projet (Project Settings, puis Unpublish project). Prévenez vos utilisateurs à l’avance et lancez-vous au moment où le trafic est le plus faible. Vous pourrez republier une fois la migration terminée. Pour un premier essai à blanc, vous pouvez sauter cette étape et migrer une copie des données réelles pendant que l’app reste en ligne.

Connecter votre projet Lovable à GitHub

Si votre projet est déjà connecté à GitHub, passez à l’étape suivante. Sinon :

1. Créez un compte sur github.com si vous n’en avez pas
2. Créez un nouveau dépôt (il peut porter le nom de votre projet, par exemple my-lovable-app)
3. Dans l’éditeur Lovable, ouvrez Project Settings, puis Git, puis GitHub, et connectez ce dépôt

Lovable y enverra tout votre code source, y compris les migrations de la base, les Edge Functions et les policies RLS. Vous en aurez besoin pour le code des Edge Functions et pour la phase 2.

Créer un nouveau projet Supabase

Rendez-vous sur supabase.com et créez un nouveau projet, dans une région proche de vos utilisateurs. Supabase vous demande de définir un mot de passe pour la base : notez-le en lieu sûr, la restauration en aura besoin. Notez aussi l’URL du projet et la clé publishable (menu déroulant Copy du tableau de bord).

Exporter votre base depuis Lovable Cloud

Dans votre projet Lovable, ouvrez More → Cloud → Overview → Advanced settings. Dans la section Export project data, cliquez sur Export data et confirmez. Lovable vous envoie un lien de téléchargement par e-mail quand l’export est prêt ; le fichier apparaît aussi dans Cloud → Storage, sous la forme d’un bucket au nom du genre database_export_..., qui contient un fichier .backup.

Advanced settings se trouve en bas de Cloud → Overview ; votre export arrive dans le bucket database_export de Storage · cliquer pour agrandir

Téléchargez le fichier tout de suite et gardez-le en lieu sûr. L’export est stocké dans l’espace Cloud de votre projet : si vous supprimez Cloud un jour, il disparaît avec.

Lovable autorise un export toutes les 24 heures. L’export en libre-service est ouvert aux projets dont la base occupe jusqu’à 15 Go, mais le fichier d’export lui-même ne doit pas dépasser 5 Go. Au-delà, écrivez à support@lovable.dev en indiquant l’identifiant de votre projet. Si l’export est impossible, l’ancienne solution de secours fonctionne toujours : exporter chaque table en CSV depuis la vue Database de l’onglet Cloud. Méfiez-vous toutefois : Lovable produit des CSV séparés par des points-virgules, avec des tableaux écrits à la manière du JSON, que l’outil d’import de Supabase refuse. Demandez à votre outil d’IA de les convertir, et gardez en tête que la restauration de la sauvegarde est de loin la voie la plus sûre.

Restaurer la sauvegarde dans votre Supabase

Un fichier .backup se restaure avec des outils en ligne de commande : le tableau de bord Supabase ne sait pas l’ouvrir. Suivez la procédure de migration de Supabase. Si vous confiez la restauration à Claude Code, donnez-lui le chemin de la sauvegarde et le projet de destination, puis relisez chaque commande avant de l’approuver.

Restaure [chemin de la sauvegarde] dans le projet Supabase [nom du projet]
en suivant la procédure de migration prise en charge par Supabase. Conserve
le schéma auth complet. À la fin, compare le nombre de lignes de chaque table
et le nombre d’utilisateurs auth. Arrête-toi et montre-moi toute erreur de
restauration avant de modifier les tables auth.

Ne mettez aucun identifiant dans le prompt. Authentifiez-vous dans le navigateur ou dans le terminal quand on vous le demande. Si la restauration signale des erreurs sur auth.identities, réglez-les avant de continuer ; ne remplacez pas le schéma auth par des INSERT écrits à la main.

Vérifier la restauration

Ouvrez le Table Editor de votre nouveau projet Supabase. Vos tables doivent y être, avec leurs lignes. Allez dans Authentication pour confirmer que vos utilisateurs sont bien arrivés, et comparez par sondage le nombre de lignes de vos tables les plus importantes avec celui de Lovable Cloud.

Vérifier que vos utilisateurs peuvent se connecter

Lors d’un test de migration de bout en bout, BWorlds a restauré le schéma auth complet. Après la migration, les utilisateurs existants se sont connectés avec leur mot de passe d’origine. Les sessions en cours n’ont pas suivi : les utilisateurs ont dû se reconnecter.

Refaites ce test avec un vrai compte avant la bascule.

Remettre en ligne les Edge Functions et ressaisir les secrets

Le code de vos Edge Functions est sur GitHub, pas dans la sauvegarde. Après la restauration, connectez le dépôt dans Project Settings → Integrations, activez Deploy to production pour la branche main et vérifiez que les fonctions sont déclarées dans supabase/config.toml. Lancez volontairement une mise en ligne, puis vérifiez les fonctions dans le tableau de bord.

L’intégration peut aussi appliquer les migrations. Si elle signale des erreurs sur l’état des migrations, réglez-les au lieu de rejouer le schéma à l’aveugle.

La valeur des secrets ne sort jamais de Lovable. Ressaisissez-les dans Edge Functions → Secrets, avec exactement les noms qu’utilisent vos fonctions.

Exporter les fichiers des buckets de stockage

Dans votre projet Lovable, cliquez sur le bouton Cloud, puis sur Storage dans le menu latéral. Pour chaque bucket :

1. Sélectionnez le bucket
2. Cochez la case qui sélectionne tous les éléments
3. Cliquez sur le bouton de téléchargement

Ensuite, dans votre nouveau projet Supabase, créez les mêmes buckets et importez-y les fichiers depuis la section Storage du tableau de bord.

Recréer les tâches planifiées

Si votre app utilise des tâches planifiées (cron), leurs définitions font partie de l’export, mais la restauration ne peut pas les écrire à leur emplacement protégé dans le nouveau projet : il faut donc les recréer. D’abord, dans votre nouveau projet Supabase, allez dans Database → Extensions et activez pg_cron (ainsi que pg_net, dont les tâches se servent pour appeler vos fonctions en HTTP). Ensuite, listez ce que vous aviez : dans le SQL Editor de Lovable Cloud (bouton Cloud, puis Database, puis SQL Editor), lancez :

SELECT jobname, schedule, command FROM cron.job;

Recréez chaque tâche dans le SQL Editor du nouveau projet avec cron.schedule, ou collez la liste dans votre outil d’IA et demandez-lui d’écrire les instructions. Surveillez les URL : une tâche qui appelle une Edge Function pointe encore vers l’adresse de l’ancien projet, remplacez-la au fur et à mesure par celle du nouveau. Si vous sautez cette étape, vos tâches planifiées continueront, sans bruit, d’appeler un backend qui disparaîtra à la phase 3.

Migrer la connexion Google (facultatif)

Si votre app n’utilise pas la connexion avec Google, sautez cette étape. Si elle l’utilise sans que ce soit essentiel, envisagez de la désactiver pour l’instant : vous pourrez toujours la remettre une fois le reste de la migration terminé. La connexion Google est la partie la plus délicate de la migration.

Si vous en avez besoin, deux choses sont à régler :

1. Configurer Google OAuth dans votre nouveau projet Supabase. Regardez vos réglages d’authentification dans Lovable (bouton Cloud, puis Auth). Si vous êtes sur « Managed by Lovable », il vous faudra créer vos propres identifiants OAuth Google Cloud (demandez à votre outil d’IA de vous guider si la documentation de Google vous paraît touffue), puis les renseigner dans votre nouveau projet Supabase, dans Authentication, puis Providers, puis Google. Si vous êtes déjà sur « Your own credentials », vous pouvez réutiliser le même Client ID et le même Client Secret.

2. Adapter votre code. Lovable Cloud gère la connexion Google avec ses propres bibliothèques, pas directement avec Supabase, et elles ne fonctionnent pas en dehors de Lovable Cloud. Demandez à votre outil d’IA de chercher dans le code tous les appels à lovable.auth et tous les imports depuis @lovable.dev/, et de les remplacer par les méthodes d’authentification natives équivalentes de Supabase.

Les utilisateurs existants devront peut-être se reconnecter après la migration. Avant la bascule, vérifiez avec des comptes de test que chaque utilisateur retrouve bien son compte et que les sessions se comportent comme prévu ; ne partez pas du principe que les identités OAuth ou les sessions existantes suivront automatiquement.

Où vous en êtes après la phase 1

Tout existe désormais en double : votre app tourne toujours sur Lovable Cloud, sans changement, et une copie vérifiée de votre base, de vos utilisateurs, de vos fichiers, de vos fonctions et de vos secrets se trouve sur votre propre Supabase. Rien n’a encore basculé, et c’est voulu : l’instance Cloud d’origine reste votre solution de repli tant que le nouveau circuit n’a pas été vérifié de bout en bout.

Deux chemins à partir d’ici :

• Vous voulez continuer à créer dans Lovable : passez à la phase 3. Vous supprimerez Cloud et connecterez votre propre Supabase au même projet Lovable.
• Vous voulez votre propre hébergement, ou changer d’outil : faites d’abord la phase 2, vérifiez tout sur Vercel avec votre nouveau Supabase, puis terminez par la phase 3.

Phase 2 : reprendre l’hébergement

Après la phase 1, les données migrées sont sur votre propre Supabase, et l’instance Lovable Cloud d’origine reste disponible comme solution de repli. Cette phase déplace le frontend sur Vercel, pour que la nouvelle production ne dépende plus de l’hébergement de Lovable. C’est aussi la phase à faire si vous voulez continuer à développer votre projet avec un autre outil d’IA comme Claude Code, Codex ou Cursor. Une fois votre app en ligne sur Vercel à partir de votre dépôt GitHub, vous travaillez sur le code avec l’outil de votre choix, et Vercel publie automatiquement chaque push.

Il vous faut : un compte Vercel et environ 20 minutes.

Créer un compte Vercel

Rendez-vous sur vercel.com et créez un compte. Le plus simple est de vous inscrire avec votre compte GitHub, ce qui relie les deux automatiquement.

Importer votre projet

Dans le tableau de bord Vercel, cliquez sur New Project, puis importez votre dépôt GitHub. Vercel détecte tout seul qu’il s’agit d’un projet Lovable et configure le build. Cliquez sur Deploy.

Mettre à jour les variables d’environnement

Votre projet Lovable se connecte à Supabase grâce à des variables d’environnement. Il faut renseigner les mêmes dans Vercel. Vos identifiants se trouvent dans le tableau de bord Supabase : cliquez sur le bouton Copy à côté de l’URL du projet, puis choisissez Project URL ou Publishable key dans le menu déroulant.

Dans les réglages de votre projet Vercel, ajoutez :

• VITE_SUPABASE_URL = l’URL de votre nouveau projet Supabase (par exemple https://yourproject.supabase.co)
• VITE_SUPABASE_PUBLISHABLE_KEY = votre nouvelle clé publishable (anon)
• VITE_SUPABASE_PROJECT_ID = l’identifiant de référence de votre nouveau projet

Si votre app utilise d’autres variables d’environnement (Stripe, OpenAI, Resend, etc.), ajoutez-les elles aussi dans les réglages d’environnement protégés de Vercel. Dressez la liste des noms de variables nécessaires à partir du code de l’app et des tableaux de bord de chaque service ; n’envoyez jamais de fichier .env ni de valeur secrète sur GitHub.

Faire pointer votre domaine

Si vous avez votre propre nom de domaine, ajoutez-le à votre projet Vercel et modifiez vos enregistrements DNS pour qu’ils pointent vers Vercel au lieu de l’hébergement de Lovable.

Votre app tourne maintenant sur votre propre infrastructure. Vos utilisateurs arrivent sur Vercel, qui dialogue avec votre propre Supabase. Lovable Cloud existe toujours de son côté, mais plus personne n’en dépend. Vous pouvez continuer à modifier l’app dans l’éditeur Lovable : comme Lovable pousse par défaut sur la branche main et que Vercel publie automatiquement depuis main, les modifications faites dans Lovable passeront en ligne sur Vercel toutes seules. Avec un autre outil d’IA comme Claude Code ou Codex, vous pouvez prévisualiser et tester vos changements en local avant de les pousser sur main.

Phase 3 : couper le cordon

Vos données sont sur votre propre Supabase et, si vous avez fait la phase 2, votre app est déjà servie par votre propre hébergement. L’ancienne instance Cloud reste rattachée à votre projet Lovable. Cette phase la supprime, puis reconnecte le projet à votre Supabase si vous restez sur Lovable.

Avant de supprimer quoi que ce soit

La suppression est définitive : la checklist passe donc en premier.

• Le fichier d’export .backup est téléchargé sur votre machine. L’export est stocké dans l’espace Cloud de votre projet : il disparaît avec Cloud.
• Les fichiers stockés sont téléchargés et importés dans le nouveau projet.
• La restauration est vérifiée : tables, lignes, utilisateurs, policies.
• Les Edge Functions sont en ligne et les secrets ressaisis dans le nouveau projet.
• Les tâches planifiées pointent vers les URL du nouveau projet.
• Un vrai test de connexion a réussi sur le nouveau Supabase. Si vous restez sur Lovable et qu’aucune app ne pointe encore vers le nouveau projet, mettez en ligne une version jetable (la phase 2 sans l’étape du domaine) sur une URL vercel.app, testez-y la connexion et les données, puis supprimez-la.

Supprimer Lovable Cloud

Ouvrez Cloud → Overview → Advanced settings et cliquez sur Remove dans la section Remove Lovable Cloud. Lovable vous fait cocher deux cases de confirmation (la seconde se débloque après la première) et taper le nom exact du projet avant le Remove final. L’instance Cloud est alors supprimée définitivement, sans retour possible, et rien n’est migré à votre place. C’est à ça que servait la checklist ci-dessus.

Connecter votre propre Supabase au même projet

Si vous restez sur Lovable : après la suppression, l’onglet Cloud propose "Already have a Supabase project? Connect it here". Cliquez dessus, autorisez votre organisation Supabase et sélectionnez votre nouveau projet. Lovable réécrit automatiquement la configuration d’environnement du projet pour qu’elle pointe vers votre Supabase ; vous ne modifiez rien à la main. Si l’aperçu affiche une page d’erreur juste après la connexion, faites une petite modification ou rafraîchissez pour relancer un build.

À partir de là, vous continuez à créer et à publier dans Lovable exactement comme avant, à ceci près que le backend est un projet Supabase qui vous appartient.

Si vous en avez fini avec Lovable

Si vous avez fait la phase 2 et passez à un autre outil, il n’y a rien à connecter : votre app tourne sur Vercel et sur votre propre Supabase, et l’ancienne instance Cloud était la dernière dépendance. Même dans ce cas, ne la supprimez pas juste pour cocher une case : gardez-la tant que vous n’êtes pas certain que plus rien n’en dépend. Au moindre doute sur une dépendance, conserver vaut mieux qu’effacer sans retour possible.

Si Lovable Cloud tombe en panne

Voici la marche à suivre en cas d’urgence : Lovable Cloud est injoignable, votre app est en panne et vos utilisateurs sont touchés.

Si vous avez déjà fait la phase 2, vous n’avez rien à faire. Votre app tourne sur Vercel et sur votre propre Supabase : une panne de Lovable Cloud ne vous touche pas.

Si vous avez fait la phase 1 mais pas la phase 2, faites la phase 2 maintenant. Vos données sont déjà sur votre propre Supabase : il reste à mettre le frontend en ligne et à configurer les variables d’environnement de la destination. Prenez les 20 minutes annoncées comme un minimum, valable pour un frontend simple ; le DNS, les intégrations et les vérifications en production peuvent prendre plus longtemps.

Si vous n’avez commencé aucune phase, vous pouvez quand même remettre votre frontend en ligne. Publiez-le sur Vercel depuis votre dépôt GitHub (en suivant la phase 2), en laissant les variables d’environnement pointer vers le Supabase de Lovable Cloud (les valeurs déjà présentes dans votre .env), et faites pointer votre domaine vers Vercel. Votre app sera servie par Vercel, mais continuera de parler à la base de Lovable Cloud.

Vérifier que tout fonctionne

Une fois les phases nécessaires terminées, passez cette checklist :

• Authentification : inscription, connexion, déconnexion, réinitialisation du mot de passe. Tout doit fonctionner avec votre nouveau projet Supabase.
• Données : parcourez l’app comme le ferait un utilisateur. Vérifiez que les données se chargent, que les listes se remplissent et que les pages de détail s’affichent.
• Fichiers stockés : vérifiez que les images, les documents et les autres fichiers importés se chargent bien depuis les nouveaux buckets, et qu’aucune URL signée enregistrée ne pointe encore vers l’ancien projet.
• Edge Functions : testez toute la logique côté serveur, comme les paiements, l’envoi d’e-mails ou les intégrations d’API.
• Policies RLS : connectez-vous avec différents types d’utilisateurs. Vérifiez que chacun ne voit et ne modifie que ses propres données.
• Webhooks : si vous utilisez Stripe, Resend ou d’autres services à webhooks, mettez à jour leurs URL pour qu’elles pointent vers votre nouveau domaine.
• Tâches planifiées : confirmez que les tâches cron tournent sur le nouveau projet et qu’aucune n’appelle encore une ancienne URL Cloud.
• Nom de domaine : vérifiez que votre domaine pointe bien vers Vercel et que le HTTPS fonctionne.
• Performances : chargez quelques pages. Vérifiez que les temps de réponse de votre nouvelle infrastructure sont acceptables.

Si une vérification échoue, le problème se trouve presque à coup sûr dans les variables d’environnement ou dans des données manquantes. Revenez à la phase concernée et vérifiez que chaque élément a bien été transféré.

Mettre en place le schéma à la main

Si votre projet n’a pas de données de production qui méritent d’être restaurées (un prototype que vous refaites de zéro), vous pouvez vous passer complètement de l’export et ne mettre en place que le schéma, à partir des fichiers de migration de votre dépôt. Ne le faites pas sur un projet où vous avez restauré la sauvegarde : elle contient déjà le schéma, et rejouer les migrations par-dessus peut créer des conflits. Ces étapes demandent Git (déjà installé sur la plupart des Mac ; sur Windows, téléchargez-le ici) et Node.js (qui inclut npx). Ouvrez un terminal (Terminal sur Mac, PowerShell sur Windows) et lancez :

git clone https://github.com/your-username/your-lovable-app.git
cd your-lovable-app
npx supabase login
npx supabase link --project-ref your-new-project-ref
npx supabase db push
npx supabase functions deploy

Remplacez your-new-project-ref par l’identifiant de référence du projet, visible dans le tableau de bord Supabase (la partie avant .supabase.co dans l’URL du projet, par exemple asqyjpagrwvcmrcucsgn). supabase login ouvre votre navigateur pour vous authentifier. supabase link vous demande le mot de passe de la base noté plus tôt. db push applique le schéma de la base (tables, policies RLS, index). functions deploy met vos Edge Functions en ligne.

Si db push échoue avec une erreur du type "relation does not exist", c’est qu’un fichier de migration fait référence à une table créée depuis l’interface de Lovable plutôt que par le code. Collez l’erreur dans votre outil d’IA et demandez-lui de corriger le fichier de migration.

Et après

Votre migration est faite. Votre app tourne sur une infrastructure que vous maîtrisez. Vous pouvez changer de fournisseur de base de données ou d’hébergeur, ou monter en charge de votre côté, sans attendre le support de qui que ce soit.

Mais posséder son infrastructure, ce n’est pas la même chose que faire tourner une app en production. Qui audite votre sécurité, la qualité du code, la conformité ? Qui surveille votre app à 3 h du matin quand la connexion à la base tombe ? Qui remarque que votre webhook Stripe renvoie des erreurs 500 avant que vos utilisateurs commencent à se plaindre ?

C’est là que BWorlds intervient. BWorlds audite l’app sur la sécurité, la qualité du code, l’exploitation et la préparation à la conformité, surveille les signaux de production, classe les constats par priorité, et fournit le contexte pour enquêter ainsi que des prompts de correction. Une fois votre changement appliqué, BWorlds vérifie le code ou le site en ligne quand une vérification technique est possible. La migration vous donne le contrôle ; BWorlds y ajoute de quoi faire tourner l’app au quotidien.