Pourquoi j'ai quitté Lovable

Ce que c'est et pourquoi ça compte

Lovable est pratique. La raison pour laquelle je l'ai quitté est ailleurs : dans une plateforme comme celle-là, le code vit chez eux, le déploiement passe par eux et les prix, c'est eux qui les fixent. Je préfère un projet qui tient dans un dossier à moi.

Selon moi, il y a un an, ce confort avait du sens, parce que les autres outils étaient difficiles. Aujourd'hui, avec Claude Code, je demande les mêmes choses que je demanderais à Lovable, en écrivant comme dans un chat, et au bout du compte le projet est à moi : je l'emmène où je veux.

C'est mon choix, pas une règle. Si vous êtes bien là où vous êtes, restez : ce guide vous servira quand même, parce qu'avoir votre propre copie de tout ne fait jamais de mal.

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.

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

1. Le code sur un GitHub à vous

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.

Sur Replit : Tools → Git. Si le projet n'a pas encore de dépôt, cliquez sur « Initialize Git Repository ». Ensuite, vous connectez GitHub (la première fois, Replit vous demande de l'autoriser), vous faites un commit et le push de tous les fichiers.

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 : structure et données

Le code emporte la structure de la base de données, pas les données. Sur Lovable, la structure se trouve dans les migrations, des fichiers SQL en général dans le dossier supabase/migrations. Les données, c'est-à-dire les vraies lignes, vous les exportez à part.

Sans les données, vous avez une app vide.

Sur Lovable Cloud, l'export de la base de données se trouve dans les réglages avancés du Cloud : More → Cloud → Overview → Advanced settings → Export data. Le lien arrive par e-mail : c'est une archive de sauvegarde Postgres, avec structure et données, qui se restaure avec pg_restore. Les fichiers envoyés et les clés restent dehors : vous les déplacez à la main, comme je l'explique plus bas.

Sur Replit, il y a deux bases de données. Celle de développement, vous l'utilisez pendant que vous construisez. Celle de production, c'est l'app publiée qui l'utilise, et c'est là que se trouvent les données de vos utilisateurs : c'est elle qu'il faut exporter.

Ouvrez l'outil Database et choisissez celle de production. Dans l'onglet My Data, vous pouvez exporter les données dans un fichier. L'onglet Settings contient la chaîne de connexion : selon la documentation de Replit, n'importe quel client compatible PostgreSQL peut se connecter à la base de production, donc pg_dump aussi. Traitez-la comme un mot de passe.

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

3. Variables d'environnement et 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.

Sur Replit, vous les trouvez dans Tools → Secrets, avec les valeurs visibles. Si l'app est publiée, vérifiez aussi les secrets de production dans les réglages de Publishing : ils peuvent être différents.

Faites la liste de toutes : base de données, API, paiements, e-mail. Mettez-les dans le .env sur l'ordinateur et dans les réglages du nouvel hébergement, jamais dans le code.

Quand la nouvelle app fonctionne, régénérez-les toutes et révoquez les anciennes : elles sont passées par une autre plateforme, et vous ne savez plus où elles ont fini.

4. Utilisateurs, fichiers, domaine

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 chiffrés. Si vous le restaurez dans un projet Supabase, les utilisateurs gardent leur mot de passe ; les sessions, non, donc tout le monde se reconnectera.

Sur Replit, dans Tools → Users & Auth, onglet Users, vous voyez qui s'est inscrit. Avec Replit Auth, les utilisateurs se connectent avec un compte Replit. Leurs lignes dans la base de données voyagent avec les données, la façon d'entrer, non : décidez d'abord de la nouvelle connexion et de la façon de faire revenir ceux qui sont déjà là.

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.

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.

Sur Replit, ils sont dans App Storage : Tools → App Storage, choisissez le bucket dans le menu en haut à gauche, et dans la vue Objects vous téléchargez chaque fichier avec l'icône à côté.

Ensuite, comptez les fichiers avant et après.

Le domaine

Notez où le domaine est enregistré et copiez ses enregistrements DNS actuels avant de les modifier. Sur Replit, le domaine relié se trouve dans Publishing, onglet Domains. Si vous l'avez acheté dans la plateforme, vérifiez comment le transférer avant de fermer quoi que ce soit.

5. Ouvrez le dossier avec Claude Code

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 tout le projet et explique-moi comment il est fait : framework, base de données, connexion, services externes. Fais-moi la liste des variables d'environnement nécessaires.

C'est la carte. Dans les projets Replit, l'app trouve en général la base de données via la variable DATABASE_URL : sur le nouveau, elle devra pointer vers la vôtre.

Crée un fichier .env.example avec toutes les variables, sans vraies valeurs, et ajoute .env au .gitignore.

Le .env.example ne contient que les noms. Les vraies valeurs sont dans le .env, sur votre ordinateur, et le .gitignore dit à git de ne jamais l'envoyer.

Fais-le démarrer en local. Si quelque chose dépend de l'ancienne plateforme, dis-moi quoi et propose-moi comment le remplacer.

C'est là que sortent les choses cachées : une connexion qui passe par la plateforme, une adresse écrite dans le code. Ce que Claude Code demande avant d'agir dépend du mode de permissions, que vous changez avec Shift+Tab. Quand il demande, lisez ce qu'il s'apprête à faire avant de dire oui.

Importe le dump de la base de données dans une base locale et vérifie que les pages affichent les vraies données.

Il vous faut Postgres sur l'ordinateur : s'il manque, demandez à Claude Code de vous aider à l'installer. Ensuite, ouvrez l'app : si vous voyez vos utilisateurs et vos contenus, les données sont là.

6. Publiez là où vous avez la main

Prépare le déploiement sur [Vercel / ton serveur] : dis-moi les étapes, les variables à définir et ce qu'il faut changer dans le DNS. Ne touche à rien tant que je ne t'ai pas dit ok.

La dernière phrase compte : je veux d'abord lire le plan. Vous pouvez aussi utiliser le plan mode (Shift+Tab, ou /plan devant le prompt) : Claude écrit un plan et ne modifie pas les fichiers tant que vous ne l'avez pas approuvé.

Avant de déplacer le domaine, testez tout sur l'adresse que vous donne le nouvel hébergement : connexion avec un ancien compte, un fichier envoyé, les paiements en mode test. Ensuite, seulement quand la nouvelle version fonctionne, dans cet ordre :

1. Vous déplacez le domaine, et vous ajoutez la nouvelle adresse aux URL de redirection qu'autorise votre connexion.
2. Vous régénérez les clés et révoquez les anciennes.
3. Vous éteignez l'ancienne version.

Les erreurs les plus courantes

• Exporter depuis Replit la base de développement. Les données de l'app publiée sont dans celle de production : exportez celle-là.
• Écrire les vraies valeurs dans le .env.example. Là, seulement les noms ; les valeurs sont dans le .env, que git ignore.
• Oublier comment les utilisateurs se connectent. Décidez d'abord de la nouvelle connexion et de la façon de faire revenir ceux qui sont déjà inscrits.
• Copier les anciennes clés sur le nouveau et s'arrêter là. Régénérez-les et révoquez les anciennes.

Check-list

• Code sur un GitHub à vous, privé, cloné sur l'ordinateur
• Structure et données exportées depuis la base de production
• Liste des variables et .env.example sans vraies valeurs
• Utilisateurs, fichiers et enregistrements DNS sauvegardés
• App en local avec les vraies données
• Connexion, fichiers et paiements testés sur le nouvel hébergement
• Domaine déplacé, clés régénérées, ancienne version éteinte en dernier

Questions fréquentes