Ce qui est arrivé à Lovable

Ce que c'est et pourquoi ça compte

En avril 2026, The Register a rapporté le signalement d'un chercheur sur Lovable, puis Lovable a expliqué l'incident sur son blog : entre février et avril, à cause d'un problème dans son backend, les chats et le code des projets publics pouvaient être vus par d'autres utilisateurs. Lovable dit que les projets privés n'ont pas été touchés et que le problème est corrigé. Si vous avez un projet là-bas, lisez leur article.

Je n'ai rien contre Lovable. Cette histoire m'a juste rappelé à quel point il compte de savoir où vit votre projet et qui en tient les clés. S'il vit dans une plateforme, la sécurité de la plateforme est la vôtre. S'il vit dans un dossier à vous, avec vos clés, les erreurs sont les vôtres, et au moins vous pouvez les corriger.

Le fait est qu'un projet, ce n'est pas que le code : il y a les données, les comptes des utilisateurs, les fichiers envoyés, les clés, le domaine. Chaque morceau sort par une porte différente, et si vous en oubliez un, vous vous en rendez compte quand un utilisateur n'arrive plus à se connecter.

Ci-dessous, voici comment tout sortir. J'utilise les menus de Lovable, mais la logique vaut pour n'importe quelle plateforme. Et c'est utile même si vous restez : avoir votre propre copie, c'est du bon sens.

Une règle avant tout : ne supprimez rien tant que le nouveau ne fonctionne pas.

1. Le code

Sur Lovable : Project settings → Git → GitHub. Vous connectez votre compte et vous faites créer le dépôt : Lovable le crée en privé et le garde synchronisé dans les deux sens, ce que vous changez dans Lovable part sur GitHub et inversement.

La synchronisation suit une seule branche, en général main. Tant qu'elle est active, faites vos essais sur une branche à part et vous ne toucherez pas au projet dans Lovable.

Si votre forfait le propose, le même menu contient aussi « Download codebase » : le zip de tout le code. Bien comme copie de sécurité, mais il ne se met pas à jour.

Ensuite, vous clonez le dépôt sur votre ordinateur, depuis le bouton « Code » de la page du dépôt sur GitHub. À partir de là, c'est un dossier à vous.

2. La base de données

Le code emporte la structure de la base de données, pas les données. La structure se trouve dans les migrations : des fichiers SQL, en général dans le dossier supabase/migrations, qui recréent tables, colonnes et règles d'accès. Les données, c'est-à-dire les vraies lignes, vous les exportez à part.

Pour le schéma et les données, avec le backend intégré de Lovable (Lovable Cloud), vous utilisez l'export de la base de données depuis les réglages avancés : More → Cloud → Overview → Advanced settings → Export data. Le lien arrive par e-mail. C'est une archive de sauvegarde Postgres, pas un fichier SQL à coller : elle se restaure avec pg_restore. Si vous avez en revanche la chaîne de connexion de la base, vous utilisez pg_dump. Sur Supabase, la chaîne se trouve sous le bouton « Connect » du tableau de bord du projet, et son guide utilise la commande supabase db dump.

Vous l'importez dans un Postgres ou un Supabase à vous, neuf et vide.

3. Les utilisateurs

Les comptes de connexion ne voyagent pas avec les tables : si vous ne déplacez que les données, les utilisateurs restent derrière.

L'export complet de Lovable Cloud, lui, les inclut, avec les mots de passe enregistrés sous forme chiffrée. Si vous le restaurez dans un projet Supabase, les utilisateurs gardent leur mot de passe. Deux choses ne passent pas, en revanche : les sessions, donc tout le monde devra se reconnecter, et les réglages des méthodes de connexion, comme « Se connecter avec Google », que vous reconfigurez sur le nouveau.

Si vous venez d'ailleurs et que les mots de passe ne peuvent pas être repris, préparez un e-mail « réinitialisez votre mot de passe » à envoyer le jour du changement.

4. Les fichiers envoyés

Photos, documents, avatars : ils ne sont ni dans la base de données ni dans le code. Sur Lovable Cloud, vous les trouvez dans More → Cloud → Storage. Téléchargez-les et renvoyez-les sur le nouveau stockage, dans des buckets (les « dossiers » du stockage) qui portent les mêmes noms.

Ensuite, comptez les fichiers avant et après.

5. Les clés

Les variables secrètes ne sortent ni avec le code ni avec l'export de la base de données. Et sur Lovable, les secrets ne peuvent pas être relus, seulement remplacés : la valeur, vous la récupérez auprès du service qui vous l'a donnée.

Faites la liste de toutes : base de données, API, paiements, e-mail. Mettez-les dans votre .env sur l'ordinateur et dans les réglages du nouvel hébergement. Les clés privées ne vont jamais dans le code ni dans git, et jamais dans une variable qui commence par VITE_ : celles-là finissent dans le navigateur, donc là, seulement des valeurs publiques.

Ensuite, régénérez-les : nouvelles clés, anciennes révoquées. Une clé qui reste valide sur une plateforme que vous n'utilisez plus, c'est une porte laissée ouverte.

6. Domaine et connexion

Faites pointer le domaine vers le nouvel hébergement, en suivant les instructions de votre hébergeur. L'adresse lovable.app reste chez Lovable et continue d'afficher la dernière version que vous y avez publiée.

Ensuite, mettez à jour les URL de redirection de la connexion : la nouvelle adresse doit être ajoutée à celles qu'autorise votre système de connexion. Si vous utilisez « Se connecter avec Google » ou équivalent, mettez-la à jour là aussi. Si vous l'oubliez, la connexion casse justement sur le nouveau domaine.

Avec Claude Code, dans le dossier

Ouvrez le terminal dans le dossier du projet et lancez Claude Code (cd dans le dossier, puis claude). Il lit les fichiers tout seul. Je lui donne ces demandes, dans cet ordre.

Lis ce projet et fais-moi la liste de tout ce qui dépend de la plateforme d'où il vient : variables, services, URL, fonctions côté serveur.

C'est votre carte. Les fonctions côté serveur sont celles qui tournent en dehors du navigateur : dans les projets Lovable avec Supabase, elles se trouvent en général dans supabase/functions et doivent être déployées à part sur le nouveau backend.

La suivante, je l'ajoute moi-même : elle vous donne la liste des clés du point 5 sans devoir les chercher à la main.

Fais-moi la liste de toutes les variables d'environnement que le projet utilise : où elles sont lues, lesquelles finissent dans le navigateur et lesquelles doivent rester secrètes. N'écris pas les valeurs.

Fais-le tourner en local avec ma nouvelle base de données et dis-moi ce qui manque.

C'est là que ressortent les clés oubliées et les tables vides. Claude Code vous demande la permission avant de modifier des fichiers ou de lancer des commandes, selon le mode de permissions choisi : lisez ce qu'il s'apprête à faire avant de dire oui.

Vérifie qu'aucune clé n'est écrite dans le code ou dans l'historique git.

S'il en trouve une dans l'historique, supprimer le fichier ne suffit pas : elle reste dans les anciens commits. Cette clé, vous la régénérez, point.

7. Publiez, testez, puis éteignez l'ancien

Quand tout marche en local, publiez sur un hébergement que vous contrôlez. Ensuite, testez les choses qui cassent en premier :

1. La connexion : connectez-vous avec un compte qui existait déjà et créez-en un nouveau.
2. Un envoi de fichier, et qu'il se rouvre.
3. Les paiements, si vous en avez, en mode test.

Seulement alors, éteignez l'ancien.

Les erreurs les plus courantes

• Supprimer l'ancien projet dès que vous avez le dépôt. Gardez-le allumé tant que connexion, fichiers et paiements ne marchent pas sur le nouveau.
• Croire que le dépôt, c'est tout le projet. Le code emporte la structure ; données, utilisateurs, fichiers et secrets sortent chacun de leur côté.
• Importer les données dans une base déjà utilisée. Partez d'un Postgres neuf et vide.
• Copier les anciennes clés sur le nouveau et s'arrêter là. Régénérez-les et révoquez les anciennes.
• Oublier les URL de redirection. Ajoutez le nouveau domaine à ceux qu'autorise la connexion avant de le déplacer.

Check-list

• Dépôt sur GitHub, privé, cloné sur l'ordinateur
• Structure et données dans la nouvelle base, vide avant l'import
• Connexion testée avec un ancien compte et un nouveau
• Fichiers téléchargés, renvoyés et comptés
• Clés listées, régénérées, anciennes révoquées
• Domaine et URL de redirection mis à jour
• L'ancien éteint en dernier

Questions fréquentes