Oui, vous pouvez héberger une application Lovable ailleurs. La documentation officielle de Lovable le prévoit : le code se récupère via la synchronisation Git, et l'application peut tourner sur votre propre hébergement dès qu'elle n'appelle plus les services de Lovable. Le code n'est donc pas prisonnier de la plateforme.
La difficulté se trouve ailleurs. Le code n'est qu'une partie de votre application. Vos données, les fichiers envoyés par vos utilisateurs, les comptes, les clés d'API, les fonctions côté serveur et les fonctionnalités d'IA ne partent pas avec lui. Une migration qui ne déplace que le code donne une application qui démarre, mais vide ou partiellement cassée.
Cet article fait le tour de ce qu'il faut déplacer, dans quel ordre, et des questions à vous poser avant de décider. Il s'appuie sur la documentation publique de Lovable à la date de rédaction ; vérifiez-la avant de lancer votre propre migration, car la plateforme évolue vite.
Héberger une application Lovable ailleurs : ce qui est possible
Lovable propose deux façons de récupérer le code. La synchronisation avec un dépôt Git, que la documentation indique comme disponible sur toutes les offres, copie votre projet dans un dépôt que vous contrôlez (GitHub par exemple). Le téléchargement du code en archive .zip est réservé aux offres payantes.
Ensuite, tout dépend du type d'application. D'après la page de Lovable consacrée à l'auto-hébergement :
- Les applications plus anciennes en React + Vite se compilent en fichiers statiques. N'importe quel hébergeur de fichiers statiques peut les servir : Netlify, Vercel, Cloudflare Pages, un stockage cloud derrière un CDN, ou votre propre serveur avec Nginx ou Apache.
- Les applications en TanStack Start exécutent du code côté serveur. Il leur faut un hébergeur capable de faire tourner ce code, pas seulement de servir des fichiers.
- Le backend (base de données, comptes utilisateurs, fichiers) peut aller sur un Supabase géré, un Supabase auto-hébergé ou un autre backend PostgreSQL offrant des services équivalents.
Si vous ne savez pas dans quelle catégorie se trouve votre application, c'est la première chose à faire vérifier : le choix de l'hébergeur en dépend.
Ce que l'export du code ne contient pas
C'est là que la plupart des migrations improvisées se passent mal. La documentation de Lovable est claire sur plusieurs points :
- Vos données ne sont pas dans le code. L'export contient les fichiers source et les fichiers de migration qui décrivent la structure de la base, mais pas son contenu. La FAQ de Lovable indique que la base s'exporte à part, depuis les réglages avancés de Lovable Cloud (« Export project data »).
- L'export des données ne contient pas tout. Selon cette même FAQ, il n'inclut ni les fichiers stockés, ni le code des fonctions Edge (de petits programmes exécutés côté serveur), ni les secrets.
- Déplacer la base ne suffit pas. La documentation précise que déplacer seulement la base PostgreSQL ne déplace pas l'authentification, le stockage de fichiers, le temps réel (realtime) ni les fonctions Edge.
- Les secrets sont à recréer. Les variables d'environnement et les clés d'API doivent être reconfigurées sur le nouvel hébergement.
- Les fonctionnalités d'IA et les connecteurs de Lovable continuent de passer par Lovable tant que l'application en dépend. Il faut les remplacer par des services équivalents si vous voulez couper complètement.
Autrement dit, « récupérer le code » et « héberger une application Lovable ailleurs » sont deux chantiers différents. Le premier prend quelques minutes, le second se prépare.
Les étapes d'une migration sans casse
Voici l'ordre que je recommande. Il n'a rien d'original : c'est celui de toute migration d'application qui a déjà des utilisateurs.
1. Faire l'inventaire
Avant de toucher à quoi que ce soit, listez ce dont l'application dépend : base de données, comptes utilisateurs et méthodes de connexion (e-mail, Google...), fichiers stockés, fonctions côté serveur, services externes (paiement, envoi d'e-mails, IA), clés d'API, nom de domaine. Chaque élément de cette liste devra avoir une destination.
2. Mettre le code dans un dépôt que vous contrôlez
Activez la synchronisation Git vers un compte qui appartient à votre entreprise, pas au compte personnel d'un freelance. C'est aussi le bon moment pour vérifier qu'aucune clé secrète ne traîne dans le code ; si c'est le cas, notre article sur la clé API exposée détaille quoi faire.
3. Monter l'environnement cible et y faire une répétition
Installez l'application sur le nouvel hébergement avec une copie des données, sans toucher à la production. Testez les parcours essentiels : inscription, connexion, paiement, envoi d'e-mails, téléversement de fichiers. Mettez à jour les adresses de redirection après connexion pour les services que vous conservez, comme le demande la documentation de Lovable.
4. Vérifier la sécurité de la nouvelle base
Si votre application utilise Supabase, les règles d'accès aux données (RLS) doivent être actives et correctes sur la nouvelle base. Une migration est l'occasion idéale de les contrôler : voir comment vérifier la sécurité Supabase d'une application Lovable.
5. Basculer, puis garder l'ancien environnement
Le jour J, gelez les modifications, exportez les données définitives, importez-les, vérifiez-les, puis faites pointer le nom de domaine vers le nouvel hébergement. La documentation de Lovable recommande de vérifier les données et fichiers à destination avant de retirer l'original. Ne supprimez rien côté Lovable tant que vous n'avez pas fonctionné quelques jours sans incident.
Les pièges qui apparaissent après la bascule
Une fois l'application en ligne ailleurs, certains problèmes ne se voient pas le premier jour :
- Plus personne ne s'occupe de l'hébergement. Chez Lovable, la plateforme gérait une partie de l'infrastructure. Sur votre propre hébergement, les mises à jour de sécurité, les sauvegardes et la surveillance sont à votre charge. Si personne n'est désigné, ça ne sera pas fait.
- Les sauvegardes ne sont pas configurées par défaut partout. Vérifiez qu'elles existent et testez une restauration ; notre article sur le minimum en matière de sauvegarde donne le socle.
- Une fonctionnalité oubliée (un e-mail automatique, une fonction planifiée, un connecteur IA) cesse de fonctionner sans erreur visible. D'où l'intérêt de l'inventaire initial.
- Le flux de travail change. Si vous continuiez à faire évoluer l'application dans Lovable, il faut décider où se font désormais les modifications et comment elles sont déployées.
Faut-il vraiment quitter Lovable ?
Pas forcément. Rester sur Lovable a du sens tant que l'application reste simple, que la plateforme répond à vos besoins et que vous acceptez d'en dépendre. Partir devient pertinent quand :
- vous devez maîtriser l'hébergement pour des raisons contractuelles ou de conformité (localisation des données, exigences d'un client) ;
- un développeur doit reprendre l'application avec ses propres outils et son propre processus de déploiement ;
- l'application devient centrale pour votre activité et vous voulez réduire la dépendance à un seul fournisseur.
Entre les deux, une étape intermédiaire suffit souvent : synchroniser dès maintenant le code dans un dépôt Git de l'entreprise et savoir exporter vos données. Vous ne migrez pas encore, mais vous pourriez le faire.
Questions fréquentes
Lovable bloque-t-il la sortie de mon code ?
Non. La synchronisation Git est présentée par Lovable comme disponible sur toutes les offres, et la plateforme publie un guide pour héberger l'application ailleurs.
Puis-je migrer moi-même sans développeur ?
Pour une application statique sans base de données, c'est envisageable. Dès qu'il y a des utilisateurs, des données et des paiements, la migration touche à la sécurité et à la continuité de service : mieux vaut qu'une personne habituée aux mises en production la prépare et la répète avant la bascule.
Mon application continuera-t-elle d'évoluer avec l'IA ?
Oui. Le code exporté peut être modifié avec Claude Code, Cursor ou d'autres outils. Il faut simplement un processus clair pour tester et déployer ces modifications.
Si vous envisagez de sortir votre application de Lovable et que vous voulez que quelqu'un prépare, exécute et suive la migration à votre place, c'est le rôle de l'offre Pilote : Devnco s'en charge, puis l'hébergement peut passer sur le socle technique Autopilote. Et si vous voulez simplement savoir si votre cas justifie une migration, parlons-en : un premier échange suffit souvent à y voir clair.