Lovable est excellent pour prototyper vite : en quelques minutes, vous avez une app fonctionnelle avec un backend Supabase géré pour vous. Le problème arrive quand le projet grandit et que vous avez besoin d'un contrôle total sur la base de données, les politiques de sécurité, ou que vous voulez simplement ne plus dépendre de leur couche gérée. Migrer vers votre propre projet Supabase est plus simple qu'il n'y paraît si vous suivez un ordre clair. Voici le processus que j'utilise avec mes clients.
Pourquoi migrer
- Contrôle total du schéma, des fonctions et des triggers, sans les limites de l'éditeur Lovable.
- Facturation directe avec Supabase, sans la marge que Lovable ajoute sur le backend géré.
- Liberté de faire évoluer le frontend en dehors de l'environnement Lovable (Next.js, un autre framework, apps natives).
Avant de commencer : checklist
- Exportez le code du projet vers GitHub depuis Lovable (Settings → GitHub).
- Documentez le schéma actuel : tables, relations, policies RLS et Edge Functions éventuelles.
- Faites une sauvegarde complète de la base de données (dump SQL) avant de toucher à quoi que ce soit.
Étape 1 — Créer votre propre projet Supabase
Créez un nouveau projet sur supabase.com, notez l'URL et l'anon key, et choisissez la même région que celle utilisée par le projet Lovable pour minimiser la latence si vous migrez des données en direct.
Étape 2 — Migrer le schéma et les données
Le projet Lovable tourne déjà sur une instance Supabase, vous pouvez donc exécuter pg_dump sur la base gérée (Lovable fournit les identifiants de connexion dans les paramètres du projet) et restaurer ce dump dans votre nouveau projet via psql ou l'éditeur SQL de Supabase. Vérifiez que les types personnalisés, les extensions (pgvector, uuid-ossp, etc.) et les triggers sont bien migrés.
Étape 3 — Reconfigurer l'authentification
Reconfigurez les providers Auth (email, Google, magic link) sur votre nouveau projet et mettez à jour les redirect URLs. Les utilisateurs existants ne migrent pas automatiquement avec un simple dump : exportez la table auth.users avec les identities pour conserver les comptes.
Étape 4 — Migrer le Storage
Recréez les buckets avec les mêmes noms et policies, puis copiez les objets avec le CLI Supabase ou un script qui parcourt le bucket source et envoie chaque fichier vers la destination. Mettez à jour les URLs signées ou publiques codées en dur dans le code.
Étape 5 — Mettre à jour les variables d'environnement
Dans le repo exporté, remplacez NEXT_PUBLIC_SUPABASE_URL et NEXT_PUBLIC_SUPABASE_ANON_KEY (ou les noms équivalents) par ceux de votre nouveau projet, et vérifiez qu'aucune référence au projet géré par Lovable ne reste dans la configuration de build ou de CI.
Étape 6 — Vérifier le Row Level Security avant la mise en production
C'est l'étape la plus souvent négligée, et celle qui cause le plus de problèmes. Lovable génère généralement des policies assez permissives pour que tout fonctionne rapidement en développement. Avant le lancement, auditez chaque table : ce qu'un utilisateur anonyme peut lire et écrire, ce qu'un utilisateur authentifié peut faire, et si une table devrait avoir le RLS activé sans l'avoir.
Étape 7 — Tester en staging et déployer
Déployez le frontend pointant vers le nouveau projet dans un environnement de staging, testez les flux critiques (login, CRUD principal, upload de fichiers, Edge Functions éventuelles), et basculez le DNS ou le domaine en production seulement après.
Erreurs courantes
- Ne pas migrer les Edge Functions (il faut les redéployer via le CLI, elles ne sont pas incluses dans le dump).
- Laisser le RLS désactivé par défaut sur les nouvelles tables.
- Oublier de migrer les webhooks et triggers de base de données dépendant de l'ancien projet.
Si vous préférez confier cette migration à quelqu'un sans risquer vos données de production, c'est exactement ce type de migration que nous faisons chez VeroLab. Contactez-moi et parlons de votre cas.