Les alternatives à Lovable se divisent en deux catégories. Elles répondent à des questions différentes. Quand vous lancez un produit, vous sélectionnez un flux de travail et décidez qui exploitera le backend une fois que la première version fonctionne. Quand vous exploitez déjà une application Lovable fonctionnelle, votre première tâche est un inventaire : la documentation propre de Lovable indique que le code source de l'application vous appartient et que le déplacer est un changement de déploiement plutôt qu'une réécriture. Le travail difficile se trouve ailleurs. Les données et les services demandent le vrai travail. Ci-dessous se trouvent cinq parties, dans l'ordre : un tableau pour les nouvelles créations, les faits actuels de portabilité, une vérification du framework, un tableau pour les applications existantes et une liste de contrôle d'acceptation en production.
Deux lecteurs, deux décisions différentes
Quand vous partez de zéro, comparez comment chaque outil s'adapte à votre flux de travail et ce que vous devrez maintenir une fois que la démo fonctionne. La démo est la partie facile. Le générateur compte moins que celui qui exploite la base de données, le pipeline de déploiement et le système de connexion six mois plus tard.
Pour une application déjà fonctionnelle, abstenez-vous de la reconstruire dans un autre outil. Commencez par l'inventaire. Identifiez ce sur quoi elle s'appuie : où le code réside, où le frontend s'exécute, quel backend stocke les données, et quelles fonctionnalités IA et connecteurs passent par Lovable au moment de l'exécution.
Et voici le point que les gens sautent. Rester sur Lovable est une option parfaitement valide. Le guide de propriété de Lovable qualifie sa configuration gérée de recommandation pour la plupart des applications et dit de déplacer des composants uniquement quand vous rencontrez une vraie contrainte, comme un mandat de résidence des données, une mise en réseau non prise en charge ou une politique exigeant un hébergement autogéré. Si aucune de ces conditions ne s'applique et que personne dans votre équipe ne veut assumer des opérations supplémentaires, migrer est un coût sans bénéfice.
Nouvelle création : le tableau de décision
Ce tableau représente mon jugement. Je l'ai établi à partir de la documentation propre de chaque fournisseur où elle est disponible. Ce n'est pas un classement, et il ne prétend pas dire quel outil produit de meilleures applications.
| Option | Flux de travail qu'il convient | Modèle de code source et de dépôt | Responsabilité du backend et du déploiement | Tâche de preuve d'adéquation |
|---|---|---|---|---|
| Lovable | Créations pilotées par chat où une seule plateforme gère l'édition, l'hébergement et le backend | Code géré dans Lovable ; synchronisation Git vers GitHub, GitLab ou Bitbucket sur tous les plans | Lovable peut assurer l'hébergement et le backend intégré ; vous n'assumez les opérations que pour les parties que vous déplacez | Construisez le flux, synchronisez vers Git, puis clonez et exécutez-le localement |
| v0 | Travail de conversion en application qui se termine par un examen et un déploiement | Code réel ; v0 documente le déploiement ou l'ouverture d'une demande de tirage pour examen | Déploiement en un clic sur l'infrastructure Vercel ; le backend se connecte par intégrations | Déployez le flux, puis modifiez-le via une pull request |
| Bolt | Construction basée navigateur où vous gardez votre propre historique Git | Bolt documente une intégration Git ; confirmez l'aller-retour dans un dépôt de test | Bolt Cloud inclut l'hébergement, une base de données intégrée, l'authentification, le stockage et les fonctions serveur | Créez le flux avec des données persistantes et connexion utilisateur, publiez-le et vérifiez le flux de travail Git |
| Replit | Construction et hébergement dans un seul espace de travail cloud | Le projet réside dans l'espace de travail Replit ; vérifiez ses options Git actuelles | Replit documente la publication via Deployments ; confirmez quel type exécute le code serveur | Publiez le flux, redéployez et vérifiez que les données persistent |
| Dépôt en propre avec outils menés par les développeurs | Équipes avec ingénieurs, révision de code et pipeline existant | Votre propre dépôt, n'importe quel éditeur ou agent de codage | Vous gérez CI/CD, l'hébergement, la base de données et l'authentification | Générez un démarrage, créez le flux, déployez-le via votre pipeline |
La dernière ligne décrit un flux de travail, non un produit clés en main. Vous assemblez vous-même les pièces. Vous choisissez une stack, un hébergement et un agent ou éditeur, puis vous assumez tout le travail opérationnel décrit plus bas. Si vous comparez des frameworks pour cette voie, Astro vs Next.js et la page Next.js et Supabase couvrent les points de départ standards.
La tâche de preuve prend la même forme pour chaque candidat. Gardez-la petite, mais rendez-la réelle. Construisez un flux utilisateur réaliste avec données persistantes, authentification et déploiement en direct. Une capture d'écran générée ne prouve rien. S'inscrire, persister un enregistrement, se déconnecter, se reconnecter et revoir cet enregistrement prouve beaucoup.
Ce que Lovable vous permet vraiment de récupérer
Les faits actuels de portabilité proviennent du guide de déploiement et du guide de propriété de Lovable :
- La synchronisation Git est disponible sur tous les plans (GitHub, GitLab, Bitbucket). Le téléchargement de la codebase, un instantané .zip ponctuel, est disponible sur les plans payants.
- Les deux chemins vous donnent la source de l'application, y compris la configuration et les fichiers de migration de base de données. Ni l'un ni l'autre n'inclut les enregistrements de votre base de données ou les fichiers en stockage.
- Les lignes de base de données et les fichiers de stockage nécessitent des exports séparés, et vous les vérifiez à la destination avant de retirer l'original.
- Vous pouvez garder Lovable comme outil de développement tandis qu'un autre hébergement sert la production. Connectez le dépôt via la synchronisation Git et laissez l'autre hébergement déployer à partir de celui-ci.
L'intégration GitHub comporte des contraintes à noter. Certaines sont operationnellement maladroites. Lovable modifie et synchronise une seule branche à la fois. La synchronisation Git provisionne toujours un nouveau dépôt et ne peut pas rattacher un projet à un dépôt existant, et se reconnecter après une déconnexion crée un autre nouveau dépôt. Le dépôt est privé par défaut. Le supprimer arrête la synchronisation.
Le code n'est donc pas verrouillé. C'est utile, mais ce n'est pas toute la migration. Stocker la source dans votre dépôt n'élimine pas les dépendances d'exécution vis-à-vis de Lovable. Gardez cette distinction à l'esprit pour le tableau des applications existantes.
Vérifiez le framework avant de choisir un hébergement
La documentation de Lovable indique que les nouvelles applications créées à partir du 13 mai 2026 utilisent TanStack Start, qui exécute du code serveur. Les applications plus anciennes sont différentes. Elles reposent sur React plus Vite et se compilent en fichiers statiques. La documentation d'intégration Supabase mentionne le 22 juin 2026 pour les plans Enterprise sur une capacité connexe, les paiements intégrés avec votre propre projet Supabase, donc évitez d'appliquer une règle basée sur la date de création à tous les comptes.
Inspectez plutôt votre projet réel. Ouvrez package.json dans l'onglet Code. Un projet TanStack Start liste @tanstack/react-start dans ses dépendances. Un projet plus ancien avec React et Vite ne le fait pas.
Les conséquences pour l'hébergement diffèrent :
- TanStack Start : l'hébergement doit exécuter la partie serveur : rendu côté serveur, fonctions serveur et routes API. Un hébergement qui ne reçoit que des fichiers statiques n'exécute pas ces fonctionnalités. Le stockage d'objets ou un CDN seul ne suffit pas. Lovable pointe vers une plateforme que Nitro détecte, un conteneur ou votre propre serveur. Vérifiez aussi que
package.jsonlistenitro, car sans cela la compilation ne prépare pas l'application pour un hébergement en dehors de Lovable. - React et Vite plus ancien : déployez la sortie statique dans
dist/vers un hébergement statique, un CDN ou un serveur web comme Nginx, avec une redirection versindex.htmlpour que les routes côté client fonctionnent.
Un autre piège : les variables préfixées VITE_ sont intégrées au moment de la compilation, pas lues à l'exécution. Cela piège les équipes. Lors de l'utilisation du backend intégré, Lovable vous demande de définir VITE_SUPABASE_URL et VITE_SUPABASE_PUBLISHABLE_KEY avant d'exécuter npm run build.
J'ai omis ici les recettes de déploiement propres à chaque fournisseur. C'est un contrôle délibéré de la portée. Le guide de Lovable détaille les étapes actuelles, et pour un projet avec rendu côté serveur, il prescrit des vérifications comme charger une page rendue côté serveur et exécuter une fonction serveur avant basculer le trafic.
Application existante : quatre chemins, comparés
| Chemin | Ce qui reste | Ce qui change | Toujours facturé ou exploité par Lovable | Travail à vérifier | Responsable opérationnel |
|---|---|---|---|---|---|
| Conserver la configuration entièrement gérée | Tout | Rien | Hébergement, backend intégré, fonctionnalités IA et connecteurs ; l'utilisation du Cloud est débitée sur les crédits de l'espace de travail | Qu'il répond à vos besoins de conformité et de lancement | Lovable gère l'infrastructure ; vous êtes propriétaire du produit |
| Déplacer seulement l'hébergement du frontend | Backend intégré, fonctionnalités IA, connecteurs ; Lovable peut rester l'outil d'édition | Construction et déploiement du frontend | Le backend, l'IA et les connecteurs continuent de fonctionner via Lovable | Hébergez les variables d'environnement, les secrets serveur, les URL de redirection de connexion, les valeurs VITE_ au moment de la construction, et les fonctionnalités serveur sur TanStack Start | Vous pour le pipeline frontend et les logs ; Lovable pour le backend |
| Migrez le backend intégré vers un projet Supabase que vous possédez | Code synchronisé dans Git ; le frontend peut rester ou être migré | Base de données, authentification, stockage et fonctions sur Supabase géré ou auto-hébergé | Les fonctionnalités IA et les connecteurs peuvent encore fonctionner via Lovable | Restauration des données, authentification, stockage, politiques d'accès, Edge Functions, secrets | Vous, dans le tableau de bord Supabase et sous votre facturation Supabase |
| Quitter Lovable complètement | Code source | Frontend, backend, données, plus remplaçants pour les appels IA et connecteurs | Rien, une fois les remplaçants en place et acceptés | La liste de vérification complète ci-dessous | Vous, pour tout |
Deux éléments de ce tableau sont faciles à mal comprendre.
D'abord, migrer un backend n'est pas un simple interrupteur. Lovable déclare qu'il ne peut pas transférer un projet du backend intégré vers Supabase en une seule étape, ni inverser le processus. La route documentée est plus manuelle. Elle nécessite de recréer le schéma et de déplacer les données manuellement : exporter du backend actif, connecter le nouveau, et demander à Lovable de reconstruire le schéma.
Ensuite, les cibles supportées sont Supabase géré et Supabase auto-hébergé. Migrer la base de données PostgreSQL seule laisse trop de choses derrière : authentification, stockage, fonctionnalités temps réel et Edge Functions. Passer à PostgreSQL pur ou un autre fournisseur nécessite de construire vous-même leurs équivalents, un chemin que Lovable ne supporte pas. C'est un vrai travail d'ingénierie, pas une migration directe. Si vous prenez cette route, l'aperçu des bases de données serverless est un bon endroit pour comparer les cibles.
Quitter le backend intégré supprime aussi les outils natifs. Vous perdez les vues intégrées de Database, Users, Storage, Secrets, Jobs et Logs, les sauvegardes quotidiennes avec restauration en un clic, et l'authentification configurée par Lovable comme la connexion Google gérée. Exécuter votre propre projet Supabase nécessite votre propre abonnement Supabase et la gestion directe de l'infrastructure.
Et aucune source ne dit qu'un autre constructeur importe un backend Lovable complet. Supposez que ce ne sera pas le cas.
Liste de vérification d'acceptation pour la production
Commencez par un inventaire. Pour le projet réel, listez :
- Données et schéma (les fichiers de migration se trouvent sous
supabase/migrations/) - Utilisateurs et fournisseurs d'authentification
- Fichiers de stockage et politiques d'accès
- Abonnements en temps réel
- Edge Functions ou fonctions serveur
- Secrets
- Tâches programmées et webhooks
- Accès IA et connecteurs d'application
Puis travaillez dans cet ordre :
- Clonez le dépôt et exécutez le code réel localement. Cela montre ce qu'il installe, dont il dépend et ce qu'il lit dans l'environnement.
- Identifiez le framework et le runtime (voir la vérification
package.jsonci-dessus). - Restaurez l'export de données dans un projet de staging, pas en production.
- Téléchargez les fichiers de stockage depuis Plus → Stockage et chargez-les dans le stockage de staging.
- Testez l'inscription, la connexion et les redirections OAuth, et vérifiez la continuité du compte. La documentation d'export de base de données de Lovable indique que la restauration dans un projet Supabase conserve les mots de passe des utilisateurs, et que quiconque était connecté au moment du changement doit se reconnecter. Ne supposez rien ; validez-le et suivez les recommandations actuelles de Supabase en matière de migration d'utilisateurs. Voir aussi la page authentification.
- Testez l'accès aux fichiers et les permissions avec des comptes réels de différents rôles.
- Vérifiez la sécurité au niveau des lignes. Chaque table a besoin de politiques qui limitent qui peut lire et écrire chaque ligne, et Lovable dit de les vérifier vous-même dans le tableau de bord Supabase.
- Exécutez un flux critique payant ou modifiant l'état en mode test, sans jamais débiter de vrais clients.
- Comparez les nombres d'enregistrements et ouvrez des fichiers représentatifs du stockage.
- Vérifiez les journaux, les sauvegardes, la récupération et un plan de restauration.
- Remplacez tout ce qui a fonctionné via Lovable : accès IA, connecteurs, tâches programmées.
- Seulement ensuite supprimez les services d'origine.
L'étape 12 mérite un avertissement. Prenez-la au sérieux. Supprimer la base de données Lovable efface votre export ainsi que vos fichiers, donc téléchargez-les et inspectez-les au préalable. Ne collez jamais d'identifiants dans les tickets, chats ou le dépôt lors de cette manipulation.
Un autre piège : si deux projets Lovable partagent un seul projet Supabase, ils écrasent les secrets l'un de l'autre, y compris LOVABLE_API_KEY, ce qui casse toute fonctionnalité qui en dépend.
Restez, passez à l'hybride, ou partez
La plupart des vraies décisions se situent entre les deux.
- Une exigence pour un pipeline de déploiement différent ne peut nécessiter qu'un déplacement du frontend.
- Un besoin de base de données dans votre propre compte peut nécessiter la migration du backend, et rien de plus.
- Le mécontentement face à l'expérience de création ne signifie que travailler dans le dépôt exporté avec votre propre éditeur, tandis que Lovable reste connecté via la synchronisation Git.
Désignez un responsable de maintenance et cartographiez chaque dépendance runtime restante avant d'annuler tout service. Gardez le document concis. Il doit indiquer qui déploie, qui restaure une sauvegarde, qui alterne les secrets, et quelles fonctionnalités appellent encore Lovable. Si vous ne pouvez pas nommer un responsable, restez où vous êtes pour l'instant.
Si vous voulez un second avis sur cette transition, envoyez le dépôt, une carte de déploiement et le flux utilisateur nécessitant une supervision technique à l'équipe d'ingénierie agentique pour une évaluation des limites de responsabilité et des travaux restants. Soyez précis sur votre demande. Il s'agit d'une évaluation, pas une garantie de résolution automatique.
FAQ
Puis-je auto-héberger l'éditeur Lovable et l'agent ?
Non. Lovable stipule que l'éditeur et l'agent IA fonctionnent comme un service géré et ne peuvent pas être auto-hébergés ni déployés dans un VPC client. Les applications que vous créez avec eux, cependant, peuvent être hébergées n'importe où.
Passer à un autre constructeur transporte-t-il mon backend ?
Rien dans les sources n'indique que c'est le cas. Prévoyez un travail séparé. Exportez vos données et fichiers, transférez la base de code via Git ou un téléchargement, et configurez à nouveau l'authentification, les secrets et les services d'accompagnement à la destination.
Le téléchargement .zip suffit-il si je suis sur un plan gratuit ?
Le téléchargement .zip du code source direct de Lovable est disponible sur les plans payants. La synchronisation Git est différente. Puisque la synchronisation Git est disponible sur tous les niveaux, testez d'abord cet itinéraire.
La mise en garde principale est claire : le code exporté vous appartient, mais les enregistrements de base de données, les fichiers de stockage, la configuration d'authentification, et l'IA et les connecteurs gérés par Lovable nécessitent des migrations séparées, aucune desquelles ne se produit automatiquement. Faites l'inventaire avant le basculement. Vérifiez votre package.json, inventoriez chaque dépendance, et testez la migration en environnement de test avant d'annuler quoi que ce soit.