Héberger une application créée avec l'IA : de Lovable ou Bolt à votre serveur

Où votre application tourne aujourd'hui

Lovable, Bolt et Replit publient l'application sur leur propre infrastructure, en un clic. Voici ce que dit leur documentation, consultée en octobre 2026 :

v0 publie sur un projet Vercel et génère une application Next.js (React, TypeScript, Tailwind CSS) ; le code s'exporte, ou se synchronise avec GitHub dans les deux sens. Cursor est un éditeur et un agent de programmation installé sur votre ordinateur : le code s'y trouve déjà, et l'hébergement reste entièrement à votre choix.

Ces hébergements intégrés sont pensés pour publier vite. Chez Lovable comme chez Replit, la version en ligne est un instantané, renouvelé à chaque publication, et le coût suit l'usage de la plateforme (chez Lovable, des crédits couvrent l'activité du back-end et l'IA ; chez Replit, le forfait Starter comprend une application publiée, qui expire au bout de 30 jours et se republie). On passe à son propre serveur pour un domaine et des données sous son contrôle, des ressources réservées, des tâches de fond permanentes ou des exigences de conformité.

Récupérer le code et les données

Le plus sûr est de relier le projet à un dépôt GitHub : chaque modification y arrive en commit, avec tout l'historique. Chez Lovable, la synchronisation fonctionne dans les deux sens : vous continuez à construire dans Lovable pendant que votre serveur sert l'application.

1. Lovable : reliez le projet à GitHub, GitLab ou Bitbucket, ou téléchargez l'archive .zip du code (forfait payant).
2. Bolt : connectez GitHub, ou cliquez sur le titre du projet, en haut à gauche, puis sur « Download ».
3. Replit : menu à trois points en haut de l'arborescence, puis « Download as zip » ; ou l'outil Git, relié à votre compte GitHub, avec la synchronisation automatique.
4. v0 : connectez GitHub depuis le menu du projet (« Settings », puis « GitHub »), ou exportez le code.

Le code ne contient ni le contenu de la base, ni les fichiers téléversés par vos utilisateurs. Chez Lovable, la base s'exporte depuis le projet en un fichier .backup, à restaurer avec pg_restore, et les fichiers du stockage se téléchargent à part. Chez Bolt, la base peut se rattacher à votre propre compte Supabase (forfaits Pro et Teams).

De quoi votre application est faite

Ouvrez le fichier package.json : il indique sur quoi l'application repose, et donc ce que votre serveur doit faire tourner.

Avec Vite, toute variable dont le nom commence par VITE_ est intégrée au code envoyé au navigateur, au moment du build : chaque visiteur peut la lire, et changer sa valeur demande un nouveau build. C'est voulu pour la clé publique de Supabase (sb_publishable_…, ou l'ancienne anon), faite pour le navigateur et encadrée par les règles de sécurité au niveau des lignes (RLS). La clé secrète (sb_secret_…, ou l'ancienne service_role) passe outre ces règles : elle reste sur le serveur, sans préfixe VITE_.

VITE_SUPABASE_URL=https://xxxx.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_xxxx
VITE_SUPABASE_PROJECT_ID=xxxx

Activez RLS sur chaque table avant la mise en ligne : ce sont ses règles qui protègent vos données pendant que la clé publique circule dans le navigateur.

La mettre sur votre propre serveur, étape par étape

Sur un VPS sous Linux, la mise en ligne suit toujours le même ordre. Lovable recommande Node.js 22 pour construire et faire tourner ses applications.

1. Le build : clonez le dépôt sur le serveur, puis lancez npm install et npm run build. Une application Vite produit des fichiers statiques dans dist/ ; une application TanStack Start se construit avec NITRO_PRESET=node-server npm run build et démarre avec node .output/server/index.mjs, sur le port 3000 ; une application Next.js démarre avec npm run start.
2. Le processus : pour une application avec serveur, un service systemd la démarre avec la machine et la relance si elle s'arrête.
3. Le serveur web : Nginx ou Caddy reçoit les visiteurs. Pour une application Vite, il renvoie index.html sur toute adresse inconnue, faute de quoi une page rafraîchie répond 404 ; pour une application avec serveur, il transmet les requêtes au processus Node.js.
4. Le nom de domaine : un enregistrement DNS A (et AAAA pour l'IPv6) pointe vers le serveur.
5. Le HTTPS : un certificat Let's Encrypt, gratuit. Caddy l'obtient et le renouvelle de lui-même ; avec Nginx, Certbot s'en charge.
6. Les secrets : dans un fichier d'environnement lisible par le seul utilisateur de l'application, hors du dépôt Git.
7. La base de données : gardez le back-end chez son fournisseur, ou installez-le sur votre serveur. Une application Supabase a besoin, avec sa base PostgreSQL, de l'authentification, du stockage, du temps réel et des fonctions : Supabase auto-hébergé les réunit.
8. Les adresses de redirection : ajoutez votre domaine aux URL autorisées de l'authentification, et chez Google ou GitHub si le back-end change d'adresse.
9. Les sauvegardes : la base et les fichiers chaque nuit, copiés hors du serveur, et une restauration d'essai de temps en temps.

app.votre-domaine.com {
	reverse_proxy 127.0.0.1:3000
}

server {
    server_name app.votre-domaine.com;
    root /var/www/app/dist;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Ce qu'il faut pour qu'elle tienne

Une application en ligne vit : ses dépendances reçoivent des correctifs, sa base grossit, son trafic change. Ce qui la garde rapide et sûre tient en une routine :

Cette routine est le métier d'un administrateur système, et elle se confie. Avec un VPS géré, l'hébergeur tient le serveur à jour, le supervise jour et nuit et intervient sans attendre votre appel. Il suit aussi votre application de manière proactive (erreurs, lenteurs, requêtes coûteuses, espace disque) et vous recommande la correction : vous l'appliquez avec votre propre assistant IA, comme vous avez construit l'application, et vous gardez la main sur votre code.