Quitter Lovable : qu’est-ce que tu dois vraiment récupérer ?

Ton code est sur GitHub. Et le reste ?

Tu as construit ton app avec Lovable. Elle tourne, des gens l’utilisent, et tu veux maintenant la faire évoluer ailleurs. Peut-être avec un développeur. Peut-être pour mieux maîtriser ton hébergement.

Tu connectes GitHub, tu récupères les fichiers, tu ouvres le projet. Tout est là. Enfin, tout ce qui ressemble à du code.

Mais les documents envoyés par tes clients ? Les comptes utilisateurs ? Le service qui envoie les emails ? Le paiement qui débloque un abonnement ?

Une application, c’est du code, des données et des services qui travaillent ensemble. Pour la déménager, il faut savoir où vit chaque morceau.

Voici l’inventaire à faire avant de toucher à ce qui tourne.

D’abord, qu’est-ce que tu veux quitter ?

Il y a trois décisions différentes : changer d’outil pour coder, déplacer les pages de ton app, déplacer les services qui stockent les données et gèrent les utilisateurs.

Lovable permet de déplacer ces parties séparément. Tu peux notamment héberger l’interface ailleurs tout en conservant le backend Lovable Cloud. Documentation Lovable sur les options d’hébergement.

Identifie ensuite ton cas : Lovable Cloud ou un projet Supabase externe que tu contrôles déjà. Ce sont deux configurations distinctes, même si Cloud s’appuie sur les technologies de Supabase. Documentation Lovable Cloud.

Si tu gardes ton propre Supabase, ses données n’ont pas à déménager simplement parce que tu changes d’éditeur. Commence par écrire ce qui reste et ce qui bouge. Ça peut réduire considérablement le chantier.

1. Le code et de quoi le faire tourner

La synchronisation GitHub permet de récupérer le code et de travailler dessus en dehors de Lovable. Elle fonctionne dans les deux sens : garde en tête que les modifications de la branche synchronisée peuvent revenir dans Lovable. Documentation de l’intégration GitHub.

Vérifie que le dépôt est dans un compte ou une organisation que ton entreprise contrôle. Pouvoir consulter le code et pouvoir administrer son dépôt sont deux niveaux d’accès différents.

Demande ensuite une preuve simple : quelqu’un peut-il récupérer ce dépôt sur une autre machine et lancer le projet avec des instructions écrites ?

Ces instructions doivent expliquer comment installer le projet, le démarrer, préparer sa version de production et fournir sa configuration. Conserve aussi les règles métier, les décisions importantes et les bugs connus. Le prochain développeur ne doit pas reconstituer six mois de conversations à partir d’un écran.

Si tu veux changer de stack en même temps, pose d’abord ce choix noir sur blanc. Faire tourner l’existant ailleurs te donnera une base de comparaison pour la suite.

2. La base de données, avec ses règles

Imagine une app de devis. Récupérer les lignes de la table « clients » ne suffit pas. Il faut aussi les devis, leurs liens avec les clients, les règles d’accès et la structure qui tient le tout.

Pour Lovable Cloud, l’export complet de la base se trouve dans les paramètres avancés. Il comprend la structure et les données, mais exclut les fichiers stockés, le code des fonctions serveur et les secrets. La documentation fixe aussi des limites de taille et de fréquence : vérifie-les avant de planifier la bascule. Export des données Lovable Cloud.

Après import, demande ces vérifications :

• Les volumes correspondent : autant de clients, de devis et de commandes que prévu.
• Les relations tiennent : chaque devis appartient toujours au bon client.
• Les droits fonctionnent : Alice ne peut pas consulter les données de Bob.
• Une nouvelle donnée peut être créée, modifiée puis relue.

Une base importée sans erreur doit encore être vérifiée dans l’application. C’est là que tu vois si ton produit a réellement retrouvé ses données.

3. Les comptes utilisateurs et la connexion

Une adresse email dans une table ne garantit pas que son propriétaire pourra se connecter.

Dans le parcours documenté de migration de Lovable Cloud, les mots de passe ne sont pas récupérables pour être réutilisés : il faut prévoir leur réinitialisation. Les fournisseurs de connexion, comme Google, doivent également être reconfigurés. Guide de migration du backend Lovable.

Ça ne veut pas dire que tu dois demander à tout le monde de recréer son compte. Il faut préparer la reprise des identifiants et des liens avec les données existantes, puis le parcours de reconnexion adapté à chaque méthode.

Teste avec un compte créé avant la migration : il doit retrouver ses documents, son équipe et ses droits. Vérifie aussi l’inscription, le mot de passe oublié et les invitations. Si une action des utilisateurs est nécessaire, prépare l’email qui l’explique avant le déménagement.

Et si tu conserves ton service d’authentification actuel, ne déclenche pas une réinitialisation générale par réflexe : ce chantier dépend de ce que tu déplaces réellement.

4. Les fichiers envoyés par tes clients

Avatars, photos, contrats PDF, pièces jointes : fais-en un inventaire séparé.

Une base peut contenir l’adresse d’un fichier sans contenir le fichier lui-même.

Pour chaque espace de stockage, vérifie les fichiers, leurs chemins et leurs permissions. Après la copie, ouvre un ancien document depuis l’app, puis envoie un nouveau fichier et télécharge-le.

Teste aussi avec un autre utilisateur. Un contrat privé doit rester privé. Et si les adresses des fichiers changent, vérifie les liens déjà enregistrés dans les données ou envoyés à tes clients.

5. Les services qui font vivre ton produit

Ton interface peut s’afficher parfaitement alors qu’aucun email ne part et qu’aucun abonnement ne s’active.

Liste chaque service utilisé : paiement, emails, connexion Google, analyse d’erreurs, fonctionnalités IA, automatisations. Pour chacun, note le compte propriétaire, la facturation, les accès nécessaires et l’endroit où il est configuré.

Les secrets restent dans un gestionnaire de secrets. Ta fiche d’inventaire contient leur nom et leur emplacement, pas leur valeur. Prévois de les reconfigurer ou de les renouveler auprès du fournisseur.

Pour les traitements serveur, vérifie aussi où tourne leur code et comment ils sont déclenchés. Une relance quotidienne doit repartir sur la nouvelle installation sans être envoyée une deuxième fois par l’ancienne.

Pour le paiement, distingue le compte du prestataire et ton app. Si tu conserves le même compte Stripe, commence par vérifier la correspondance entre les clients, leurs abonnements et tes utilisateurs. Contrôle ensuite les webhooks : ce sont les messages qui préviennent ton app qu’un paiement ou un changement d’abonnement a eu lieu.

Le test utile couvre toute la chaîne : événement reçu, abonnement mis à jour, bon accès accordé, absence de doublon. C’est le même principe que dans mon analyse d’un checkout Stripe généré par IA.

6. Le domaine et les clés de la maison

Ouvre le compte qui gère ton nom de domaine. Vérifie que tu peux modifier ses réglages et récupérer l’accès au compte sans dépendre d’un prestataire.

Conserve les réglages existants, notamment ceux des emails. Changer l’adresse de ton site ne doit pas supprimer la configuration de ta messagerie.

Sur le nouvel hébergement, teste une page interne en ouvrant directement son adresse, puis en la rechargeant. Vérifie aussi les liens de connexion et les liens envoyés par email. La page d’accueil seule ne prouve pas que le déménagement est terminé.

Enfin, décide qui reçoit les alertes, qui vérifie les sauvegardes et qui intervient quand un déploiement échoue. Tu peux confier ces tâches à des services gérés ou à quelqu’un. Il faut simplement un responsable. Le guide de mise en production détaille ces bases.

La bascule : répéter avant de déplacer les clients

Monte une copie de validation séparée de la production. Neutralise les vrais envois d’emails, les paiements et les tâches automatiques pendant les essais.

Puis rejoue les parcours qui comptent : un ancien utilisateur se connecte, retrouve son abonnement, ouvre un document et crée une nouvelle donnée. Refais le parcours avec un second compte pour vérifier les droits.

Le jour de la bascule, traite explicitement ce qui a changé depuis la copie initiale. Si un client a créé une commande entre-temps, elle doit arriver dans la nouvelle base. Selon ton app, cela demande une courte pause des écritures ou un mécanisme de synchronisation préparé à l’avance.

Prévois également le retour arrière. Si la nouvelle app a déjà reçu des commandes, remettre l’ancienne en ligne sans réconcilier les données peut en faire disparaître aux yeux des utilisateurs.

Garde l’ancien environnement disponible le temps de valider la transition, avec ses automatisations maîtrisées. La suppression de Lovable Cloud est définitive ; télécharge les exports nécessaires avant toute suppression. Documentation sur la suppression de Cloud.

Ta checklist avant de partir

Tu peux commencer cet inventaire tout en restant sur Lovable. Il te servira aussi pour accueillir un développeur ou faire auditer ton application.

Les possibilités d’export citées ici ont été vérifiées dans la documentation officielle le 18 septembre 2026. Consulte les pages liées au moment de ta migration : les fonctions et limites peuvent évoluer.

Tu veux préparer la reprise de ton app Lovable ?

Je peux regarder comment ton produit est construit, identifier ce qui dépend encore de Lovable et te proposer un ordre de migration adapté à tes utilisateurs. Parlons de ton projet.

Et pour recevoir d’autres guides pratiques sur la vie d’un produit construit avec l’IA, inscris-toi à la newsletter.