Accueil › Lovable › Déploiement

Lovable Déploiement : Comment Publier et Héberger Votre Application

Lovable permet de publier votre app en un clic sur un sous-domaine .lovable.app (gratuit) ou sur un domaine personnalisé (plans payants). Pour plus de contrôle, vous pouvez exporter le code via GitHub et déployer sur Netlify, Vercel ou votre propre serveur.

Option 1 : Publication native depuis Lovable

La méthode la plus simple. Depuis l’éditeur Lovable, cliquez sur « Publish » en haut de l’interface. Lovable déploie un snapshot de votre projet sur une URL que vous pouvez partager immédiatement.

Ce qui se passe concrètement

Lovable déploie la version actuelle de votre projet sur un sous-domaine [votre-choix].lovable.app. Seule la version en cours est déployée : les modifications futures ne sont pas publiées automatiquement. Pour pousser des mises à jour, cliquez sur Publish > Update. C’est un point important : si vous ne voyez pas vos dernières modifications sur le site live, c’est que vous n’avez pas republié.

Vous pouvez choisir votre sous-domaine ou laisser Lovable en générer un automatiquement. Pour modifier le sous-domaine plus tard, allez dans Project Settings > Edit URL subdomain. Attention : renommer le projet ne change pas l’URL, seul le nom d’affichage est modifié.

Visibilité du projet vs accès au site

Lovable utilise deux paramètres de visibilité indépendants qu’il est crucial de comprendre :

Project visibility (accès éditeur) contrôle qui peut voir et modifier votre projet dans l’éditeur, y compris le code source et les modifications non publiées. Website access (accès URL publiée) contrôle qui peut visiter l’app publiée à son URL live. Publier ne change pas la visibilité de votre projet dans l’éditeur, et modifier la visibilité du projet n’affecte pas l’accès au site publié.

Sur les plans Business et Enterprise, vous pouvez restreindre l’accès au site publié aux seuls membres authentifiés du workspace (accès privé). Sur les plans Free et Pro, le site publié est accessible publiquement.

Configurer les métadonnées du site

Lovable fournit des options de métadonnées pour contrôler l’apparence de votre site dans les onglets du navigateur, les résultats de recherche et les aperçus de liens :

Icône et titre : le favicon et le titre du site affichés dans les onglets du navigateur et les résultats de recherche. Cliquez sur l’icône pour en uploader une nouvelle, sur le texte du titre pour le modifier.

Description : la meta description utilisée dans les résultats de recherche et les aperçus de liens. Cliquez sur le texte pour le modifier.

Image de partage social : l’image OG (Open Graph) affichée quand votre lien est partagé sur les réseaux sociaux ou les messageries. Format recommandé : 1200×630 pixels.

Dépublier un site

Pour retirer votre app du web, allez dans Project Settings > Unpublish project > Unpublish. Une fois dépublié, l’URL ne sera plus accessible et le sous-domaine sera libéré pour réutilisation.

Option 2 : Domaine personnalisé

Les domaines personnalisés sont disponibles sur les plans payants (Pro, Business, Enterprise). Ils vous permettent de déployer votre app sur votre propre URL (votre-app.com) au lieu d’un sous-domaine .lovable.app.

Connexion via Entri (automatique)

Lovable utilise un outil appelé Entri pour simplifier la connexion de domaines. Avec certains registrars (Namecheap, GoDaddy, Cloudflare, etc.), Entri configure automatiquement les enregistrements DNS à votre place :

Dans Lovable, allez dans Settings > Domains. Entrez votre nom de domaine. Sélectionnez votre registrar dans la liste. Si votre registrar est supporté, connectez-vous via Entri et laissez-le ajouter les enregistrements DNS automatiquement. Attendez la propagation DNS (quelques minutes à quelques heures). Le certificat SSL est provisionné automatiquement.

Configuration DNS manuelle

Si votre registrar n’est pas supporté par Entri, choisissez « Manual setup » et copiez les enregistrements DNS fournis par Lovable. Typiquement, vous devrez ajouter un enregistrement CNAME pour www et un enregistrement A ou ALIAS pour le domaine racine. La propagation DNS prend généralement entre quelques minutes et 24 heures.

Option 3 : Déploiement via GitHub + hébergeur externe

Pour un contrôle maximal sur votre hébergement, exportez votre code vers GitHub et déployez sur un hébergeur de votre choix. C’est l’approche recommandée pour les projets en production qui nécessitent un workflow professionnel dev/staging/prod.

Étape 1 : Connecter le projet à GitHub

Dans l’éditeur Lovable, cliquez sur le bouton « GitHub » puis « Connect to GitHub ». Authentifiez-vous avec votre compte GitHub. Lovable crée un repository et synchronise automatiquement votre code. Chaque modification faite dans Lovable génère un nouveau commit sur la branche main.

Le code exporté est du React/TypeScript standard, propre et maintenable. Vous pouvez le cloner localement, le modifier dans n’importe quel IDE, et le code reste pleinement portable.

Étape 2 : Déployer sur Netlify

Netlify est l’hébergeur le plus couramment utilisé avec Lovable. Le processus est simple :

Connectez-vous à Netlify avec votre compte GitHub. Cliquez sur « Add new site » > « Import an existing project ». Sélectionnez votre repository Lovable. Cliquez sur « Deploy ». Netlify build et déploie automatiquement votre app. Chaque commit sur la branche main déclenche un redéploiement automatique.

Pour ajouter un domaine personnalisé sur Netlify : allez dans Domain management > Add domain, entrez votre nom de domaine, et configurez les enregistrements DNS chez votre registrar selon les instructions fournies par Netlify. Le SSL est automatique.

Étape 2 (alternative) : Déployer sur Vercel

Vercel est une alternative populaire, particulièrement adaptée aux projets React/Next.js :

Connectez-vous à Vercel. Importez votre projet depuis GitHub. Vercel détecte automatiquement la configuration et déploie. Pour un domaine personnalisé, ajoutez-le dans Domains et configurez les DNS.

Workflow professionnel dev/prod

Pour un workflow de développement sérieux avec Lovable + GitHub + hébergeur externe, voici la configuration recommandée :

1. Créez une branche dev. Dans les paramètres GitHub de Lovable, configurez les commits pour aller sur une branche « dev » au lieu de « main ».

2. Configurez l’hébergeur pour builder uniquement main. Sur Netlify ou Vercel, définissez la branche de production sur « main ». Les commits sur « dev » ne déclenchent pas de déploiement en production.

3. Travaillez sur Lovable normalement. Toutes vos modifications vont sur la branche dev. Votre site live n’est pas affecté.

4. Créez une Pull Request quand vous êtes prêt. Sur GitHub, ouvrez une PR de dev vers main. Vérifiez les changements, testez si nécessaire, puis mergez. L’hébergeur déploie automatiquement la nouvelle version.

Ce workflow vous donne un filet de sécurité : vous pouvez tester de nouvelles fonctionnalités sans risquer de casser votre site en production. Netlify et Vercel offrent aussi des preview deployments automatiques pour chaque PR, ce qui vous permet de tester les changements sur une URL temporaire avant de les pousser en prod.

Autres hébergeurs

Vous n’êtes pas limité à Netlify et Vercel. Voici d’autres options viables :

Le choix de l’hébergeur dépend de vos besoins. Pour la majorité des projets Lovable, Netlify ou Vercel suffisent amplement. Si vous avez besoin d’un contrôle total sur l’infrastructure (configuration serveur, variables d’environnement avancées, intégrations custom), un VPS est plus adapté. L’avantage d’un hébergement externe par rapport à Lovable natif : vos coûts sont généralement plus bas à l’échelle, vous n’avez aucune dépendance aux changements de pricing ou de politique de Lovable, et vous avez une liberté totale de configuration.

Lovable Cloud : l’hébergement intégré

Lovable Cloud est l’option d’hébergement intégrée qui utilise l’infrastructure Supabase sous le capot. Quand vous publiez via le bouton Publish natif de Lovable, votre app est hébergée sur Lovable Cloud.

Chaque workspace bénéficie de 25 $ d’usage Cloud gratuit par mois et de 1 $ d’usage IA par mois (offre temporaire jusqu’à fin Q1 2026). Pour les petites applications avec peu de trafic, cette allocation suffit. Au-delà, les coûts sont facturés selon l’usage : serveur de base de données, transfert de données, stockage, invocations Edge Functions.

Les utilisateurs des plans payants peuvent ajouter des fonds à leur balance workspace pour couvrir l’usage excédentaire, soit par top-up manuel, soit par top-up automatique configurable. Les fonds non utilisés sont reportés de mois en mois mais expirent après un an.

SEO et déploiement : le défi du Client-Side Rendering

C’est le point faible du déploiement Lovable que vous devez absolument comprendre avant de publier. Lovable génère des applications React en Client-Side Rendering (CSR). Concrètement, la page HTML initiale envoyée au navigateur est quasiment vide : c’est JavaScript qui construit le contenu visible côté client.

Pourquoi c’est un problème pour le SEO

Google peut exécuter JavaScript et indexer le contenu CSR, mais le processus est plus lent et moins fiable que pour du HTML statique ou du Server-Side Rendering (SSR). Google utilise une file d’attente de rendu séparée pour les pages JavaScript, et le contenu peut être indexé partiellement ou de manière incohérente.

Les plateformes sociales (LinkedIn, Twitter/X, Slack, Discord) envoient des bots pour générer les aperçus de liens. Ces bots n’exécutent pas JavaScript. Sans prerendering, vos aperçus sociaux seront vides ou afficheront les métadonnées par défaut de votre page d’accueil, pas celles de la page partagée.

De nombreux crawlers IA (ChatGPT, Perplexity, etc.) n’exécutent pas non plus JavaScript. Si la visibilité dans les réponses IA est importante pour vous, le CSR est un handicap.

Les correctifs possibles

react-helmet-async pour les métadonnées par page. Par défaut, toutes les pages d’une app Lovable partagent les mêmes title et description (celles du index.html). Demandez à Lovable : « Create an SEOHead component using react-helmet-async that takes title, description and canonical as props and use that component on every page with page-specific values. » Puis supprimez les balises meta statiques dans index.html pour éviter les conflits.

Sitemap XML. Demandez à Lovable de générer un sitemap.xml. Soyez explicite sur les URLs à inclure et utilisez votre domaine custom comme base. Attention : Lovable a tendance à halluciner des URLs inexistantes au-delà de 15 pages. Pour les sites plus grands, utilisez un script qui génère le sitemap à partir de vos routes réelles. Soumettez le sitemap à Google Search Console.

robots.txt. Lovable génère un robots.txt par défaut. Vérifiez son contenu et assurez-vous qu’il pointe vers votre sitemap et autorise les crawlers pertinents.

Schema markup (JSON-LD). Demandez à Lovable de générer le balisage structuré approprié (Organization, Article, FAQ, Product) et validez avec le Google Rich Results Test.

Prerendering. Pour résoudre le problème fondamental du CSR, vous pouvez ajouter une couche de prerendering qui génère des snapshots HTML statiques pour les bots. Des services comme Prerender.io interceptent les requêtes des crawlers et leur servent une version HTML complète. Lovable ne propose pas de prerendering natif, mais c’est configurable en post-déploiement.

Migration SSR. Pour les projets où le SEO est un canal de croissance critique, la solution la plus robuste est d’exporter votre code Lovable vers GitHub et de migrer vers un framework SSR comme Next.js. C’est un investissement en développement, mais c’est la seule approche qui résout le problème à la racine.

Considérations Supabase lors du déploiement

Si votre app utilise Supabase comme backend, le déploiement ajoute quelques considérations spécifiques :

Une seule instance Supabase. Actuellement, Lovable ne supporte qu’une seule instance Supabase par projet. Si vous faites des modifications SQL importantes, elles peuvent potentiellement casser la production. Testez votre environnement de production fréquemment après toute modification liée à Supabase.

Variables d’environnement. Quand vous déployez sur un hébergeur externe, assurez-vous de configurer les variables d’environnement Supabase (URL du projet, clé anon) dans les paramètres de votre hébergeur. Ces informations ne doivent pas être commitées en dur dans le code (même si, techniquement, la clé anon est conçue pour être publique).

Lovable Cloud vs Supabase propre. Si vous utilisez Lovable Cloud, le backend Supabase est géré par Lovable. Quand vous déployez sur un hébergeur externe, votre frontend est sur l’hébergeur mais le backend reste sur Lovable Cloud ou votre projet Supabase. Assurez-vous que les CORS sont correctement configurés pour autoriser votre nouveau domaine.

Security Scan avant publication. Utilisez le Security Scan de Lovable 2.0 au moment de la publication pour détecter les failles de sécurité, en particulier les tables sans RLS ou avec des politiques trop permissives. Consultez notre guide Lovable + Supabase pour la checklist de sécurité complète.

Checklist de déploiement

Voici la liste des vérifications à effectuer avant de publier votre app Lovable en production :

Notre verdict

Le déploiement est l’un des points forts de Lovable comparé à d’autres outils de vibe coding. La publication en un clic sur .lovable.app est imbattable pour les démos et les prototypes. L’intégration GitHub native et la qualité du code exporté (React/TypeScript propre et maintenable) vous donnent une portabilité totale, ce qui n’est pas le cas de tous les no-code builders.

Le principal angle mort est le SEO. Le Client-Side Rendering est un handicap structurel pour le référencement naturel et les aperçus sociaux. Si votre projet dépend du trafic organique, prévoyez du travail supplémentaire (react-helmet-async, sitemap, prerendering) ou planifiez une migration SSR via Next.js.

Pour la production, notre recommandation est claire : exportez vers GitHub et déployez sur Netlify ou Vercel avec un workflow de branches dev/main. Vous gagnez en contrôle, en fiabilité et en indépendance vis-à-vis de la plateforme Lovable, tout en continuant à utiliser Lovable comme outil de développement.