Exporter un projet Lovable ou Bolt et l’héberger ailleurs

Votre projet est né sur Lovable, Bolt ou v0, et il a grandi. Vient un moment où la question se pose : est-ce que je peux récupérer mon code, l’héberger où je veux, et ne plus dépendre d’une seule plateforme ? La réponse est oui. Ces outils génèrent du code standard, que vous pouvez emporter. Mais l’export ne se résume pas à un bouton « Télécharger », et quelques pièges attendent ceux qui déménagent sans plan.

Ce guide fait le tour de la question : quand ça vaut le coup, comment s’y prendre, et ce qui casse le plus souvent au passage.

Faut-il vraiment quitter la plateforme ?

Pas forcément. Rester sur l’hébergement de Lovable ou Bolt est un choix raisonnable pour un outil interne, un prototype qu’on fait encore tester, ou un site simple sans données sensibles. L’export devient pertinent quand l’une de ces situations se présente :

• vous voulez faire intervenir un développeur, qui travaillera avec ses propres outils ;
• vous avez besoin de maîtriser l’hébergement : localisation des données, performances, nom de domaine, coûts ;
• le référencement compte pour vous et vous voulez choisir une architecture adaptée (on y revient plus bas) ;
• vous ne voulez plus dépendre d’un abonnement pour continuer à faire vivre votre projet.

Et il existe un entre-deux très confortable : synchroniser le code avec GitHub tout en continuant à utiliser l’éditeur de la plateforme. Vous gagnez une copie de sauvegarde et un historique, sans rien changer à vos habitudes.

Ce que vous récupérez exactement

Lovable et Bolt produisent le plus souvent une application React (avec Vite ou Next.js selon les cas), écrite en TypeScript et stylée avec Tailwind. v0 génère des composants React et Next.js. C’est du code tout à fait classique, qu’un développeur web sait reprendre.

Ce qu’il faut bien comprendre, c’est que votre projet est en réalité fait de deux morceaux :

• le code de l’interface, que vous exportez via GitHub ou en téléchargeant une archive ;
• le « backend » : la base de données, la gestion des comptes, les fichiers envoyés par les utilisateurs et les fonctions serveur. Il vit le plus souvent chez Supabase ou dans le service intégré de la plateforme, et il ne part pas avec le code.

Si votre backend est un projet Supabase ouvert à votre nom, il reste où il est : votre nouvel hébergement s’y connecte simplement. S’il est géré par la plateforme elle-même, sa migration demande une étape de plus (exporter le schéma, les données, les comptes utilisateurs et les fichiers). C’est la partie la plus délicate d’un déménagement, à anticiper.

Les étapes d’un export propre

1. Connecter le projet à GitHub

C’est la base de tout. Lovable, Bolt et v0 proposent une connexion à GitHub depuis leurs réglages. Utilisez un compte ou une organisation qui appartient à votre entreprise, pas celui d’un prestataire ou d’un ami qui vous a aidé : le jour où vous en aurez besoin, il faudra pouvoir y accéder sans demander la permission.

2. Faire l’inventaire des secrets et des réglages

Votre application a besoin d’informations qui ne sont pas dans le code : adresse du projet Supabase, clés d’API (Stripe, emails, IA), URL du site. Ce sont les « variables d’environnement ». Listez-les toutes avant de déménager : une variable oubliée donne une page blanche ou une fonctionnalité muette, sans message d’erreur clair.

Profitez-en pour vérifier qu’aucune clé secrète ne se trouve dans le code lui-même. Une clé écrite en dur puis poussée sur GitHub doit être considérée comme compromise et régénérée. La checklist sécurité détaille comment vérifier.

3. Choisir l’hébergement

Pour une application React ou Next.js, les options les plus simples sont Vercel, Netlify ou Cloudflare Pages : vous connectez le dépôt GitHub, et chaque modification est mise en ligne automatiquement. Si l’hébergement des données en France ou en Europe est un critère (clients publics, données de santé, exigences de vos clients), des hébergeurs comme Scaleway, OVHcloud ou Clever Cloud sont à considérer, avec un peu plus de configuration.

4. Tester sur une adresse provisoire

Mettez d’abord le site en ligne sur l’adresse technique fournie par l’hébergeur, sans toucher à votre nom de domaine. Parcourez tout : inscription, connexion, mot de passe oublié, paiement de test, envoi de fichier. Tant que ce n’est pas parfait, vos utilisateurs continuent sur l’ancienne version sans rien voir.

5. Basculer le nom de domaine

Une fois tout validé, vous pointez votre domaine vers le nouvel hébergement. Le changement peut mettre de quelques minutes à quelques heures à se propager. Choisissez un moment creux, et gardez l’ancienne version en ligne quelques jours, au cas où.

Les pièges qui cassent le plus souvent

La connexion qui renvoie vers l’ancienne adresse

Les emails de confirmation, les liens « mot de passe oublié » et la connexion via Google redirigent vers une adresse enregistrée dans les réglages d’authentification (dans Supabase : « Site URL » et « Redirect URLs »). Si vous oubliez de les mettre à jour, vos utilisateurs atterrissent sur l’ancien site, ou sur une erreur. Même chose côté Google Cloud si vous proposez la connexion avec Google.

Les pages en erreur 404 quand on rafraîchit

Beaucoup de projets Lovable ou Bolt sont des applications « monopage » : toute la navigation est gérée dans le navigateur. Sur un nouvel hébergeur, la page d’accueil marche, mais rafraîchir une page intérieure donne une erreur 404. La correction tient en une règle de redirection (un fichier de configuration pour Netlify ou Vercel), encore faut-il savoir qu’elle manque.

Les webhooks qui partent dans le vide

Stripe et d’autres services préviennent votre application quand un événement se produit (un paiement réussi, un abonnement résilié) en appelant une adresse précise. Si cette adresse change, il faut la mettre à jour dans leur tableau de bord, sinon les paiements sont encaissés sans que votre application le sache.

Les emails qui finissent en spam

Si vos emails partent désormais depuis votre propre domaine, il faut le configurer (enregistrements SPF, DKIM et DMARC). Sans cela, les emails de confirmation arrivent en spam, et vos nouveaux inscrits pensent que votre service ne fonctionne pas.

Et le référencement dans tout ça ?

C’est un point souvent découvert trop tard. Une application « monopage » affiche son contenu grâce à JavaScript, dans le navigateur. Google sait lire ce type de page, mais moins bien et moins vite qu’une page dont le contenu est déjà présent dans le HTML, et d’autres moteurs, ainsi que les aperçus de liens sur les réseaux sociaux, s’en sortent nettement moins bien.

Pour un outil derrière une connexion, ça n’a aucune importance. Pour un site qui doit attirer des visiteurs depuis Google (pages de présentation, blog, fiches produits), l’export est le bon moment pour faire générer ces pages côté serveur, par exemple en passant les pages publiques sur Next.js. C’est un chantier en soi, mais c’est souvent ce qui débloque la visibilité d’un projet.

Peut-on continuer à utiliser Lovable ou Bolt après l’export ?

Oui, grâce à la synchronisation GitHub : les modifications faites dans l’éditeur sont poussées sur le dépôt, et votre hébergement les met en ligne. La prudence s’impose en revanche dès que plusieurs personnes (vous dans l’éditeur, un développeur dans le code) modifient le projet en même temps : mieux vaut convenir d’une règle simple, par exemple travailler chacun sur une branche séparée, pour éviter que les modifications de l’un écrasent celles de l’autre.

Le bon moment pour se faire accompagner

Un export simple (application sans comptes utilisateurs, backend Supabase déjà à votre nom) est tout à fait faisable seul en suivant ce guide. Les choses se compliquent quand il faut migrer une base gérée par la plateforme, déplacer des comptes utilisateurs sans leur demander de recréer un mot de passe, ou revoir l’architecture pour le référencement. Ce sont aussi les étapes où une erreur coûte cher, parce qu’elle touche les données de vos clients.

Pour la suite, une fois le projet chez vous, le guide pour passer un prototype en production détaille les chantiers qui rendent une application vraiment fiable.