Où héberger un site créé avec l’IA

Vous avez créé un site avec ChatGPT, Claude, Cursor, Bolt ou Lovable et il fonctionne sur votre ordinateur. Pour le publier, commencez par déterminer ce qui doit s’exécuter lorsque quelqu’un le consulte. L’outil qui a écrit le code ne détermine pas l’hébergement.

Meilleur hébergement pour un projet créé avec l’IA : comparatif 2026

Il n’existe pas de gagnant universel : le code généré peut être un site statique, une application avec rendu serveur ou un frontend relié à une API et une base de données. Ce comparatif éditorial a été vérifié le 9 octobre 2026 à partir des pages publiques de produits et tarifs citées. Il compare les parcours et limites publiés ; ce n’est pas un test indépendant de vitesse, disponibilité ou support.

Pour un frontend statique dans Git, comparez Projects, Netlify et Vercel selon le framework, le parcours et la facturation. Pour Next.js avec SSR, validez le runtime exact ; une exportation statique modifie les besoins. Pour Docker ou des tâches en arrière-plan, comparez conteneurs gérés et VPS en incluant le temps d’administration. Une base externe, l’authentification ou le stockage ne sont pas transférés avec le frontend. Hostbrid exploite une infrastructure en Espagne ; consultez les tarifs et limites Sites, Projects et VPS. Les prix Vercel, Netlify et Hostinger varient selon le pays, la devise, les taxes et l’usage : vérifiez les conditions Hobby de Vercel, les tarifs Vercel et les tarifs et crédits Netlify. Pour comparer l’hébergement géré et son coût total, consultez aussi le comparatif qualité-prix.

Choisissez l’hébergement selon ce que votre projet doit exécuter

• HTML, CSS ou frontend statique construit depuis Git : Projects construit et publie le dépôt. Vérifiez le framework, la commande de build et le dossier de sortie ; le nom de l’outil d’IA ne garantit pas la compatibilité.
• WordPress, PHP ou site géré depuis un panneau : comparez Sites et ses applications compatibles. Pour Node.js, consultez d’abord le parcours Node Apps dans Sites : l’application doit être associée à un domaine et suit sa propre configuration.
• Si vous gérez les sites de plusieurs clients : consultez le guide d’hébergement pour les agences, qui compare Sites Agency aux fonctions spécifiques de l’hébergement revendeur.
• API ou processus Node/Docker avec le frontend : envisagez les services Projects seulement après avoir vérifié le runtime, l’offre, les quotas, le port et le stockage nécessaires. Pour Node.js, comparez avec les parcours Sites et VPS.
• Docker Compose, paquets système ou accès root : un VPS vous permet d’administrer l’environnement ; vous devez configurer et maintenir le système et les services.

Si votre projet expose des outils via MCP et doit rester accessible en HTTP, consultez le guide pour héberger votre propre serveur MCP sur un VPS. C’est différent de la connexion d’un assistant au MCP de Hostbrid pour gérer les ressources de votre compte.

Pour une application Nuxt, vérifiez si elle génère des fichiers statiques ou si Nitro doit tourner en production ; le guide SSR Nuxt sur Projects détaille la sortie Node et les vérifications à faire.

Avec SvelteKit, l’adaptateur détermine ce que l’hébergement doit exécuter. Consultez le guide adapter-node sur Projects si l’app a besoin d’un serveur ; si elle peut être pré-générée, vérifiez la sortie statique avant de choisir un runtime.

Si vous envisagez de quitter Netlify, vérifiez d’abord si votre site dépend de ses formulaires, fonctions ou aperçus. Le guide pour migrer un site statique de Netlify vers Projects passe en revue ces dépendances avant de modifier le DNS.

Si le projet utilise une base de données, l’authentification ou des fichiers, déterminez où chaque composant sera hébergé avant de commander : publier le frontend ne migre pas ces données et ne crée pas un backend à lui seul.

Guides pour poursuivre selon votre projet

Avec Cursor, distinguez l’éditeur du service de déploiement : les Cloud Agents de Cursor peuvent publier via Vercel si vous connectez un compte Vercel. Pour héberger le code chez un autre fournisseur, envoyez-le sur Git et vérifiez d’abord son framework, son serveur et ses services externes ; le guide Git de Cursor explique comment cloner, pousser et synchroniser des dépôts. Suivez ensuite notre guide de publication d’un site créé avec Cursor sur Projects.

Une fois le projet publié, suivez le guide pour connecter un nom de domaine à Projects sans remplacer toute votre zone DNS ni interrompre le courrier. Si vous hésitez entre publier sans forfait mensuel et passer à une offre payante, consultez hébergement web gratuit ou payant pour comparer le sous-domaine et les limites de Dev aux besoins de votre projet.

Si vous avez créé le projet avec Figma Make et souhaitez le déployer depuis son dépôt GitHub, consultez le guide Figma Make vers Projects. Ce parcours diffère de Figma Sites, qui propose sa propre option de publication. Si vous avez créé l’app avec Claude Code, vérifiez d’abord si le dépôt produit des fichiers statiques ou nécessite un serveur ; notre guide Git et déploiement Claude Code distingue l’agent de l’hébergement.

Si vous avez créé l’application avec Base44 et souhaitez déplacer le code hors de la plateforme, consultez le guide d’export GitHub et d’hébergement ; changer l’hébergement du frontend ne migre ni le backend ni les données. Si vous avez utilisé Google AI Studio, vérifiez quelles parties sont statiques et lesquelles nécessitent un serveur avant de transférer l’application vers GitHub et Projects ; ses clés et services externes ne sont pas migrés automatiquement.

Pour un projet précis, consultez le guide pour passer de localhost à une URL publique, publier React et Vite depuis Git, déployer Astro et Markdown depuis Git ou vérifier si Next.js peut être exporté en fichiers statiques. Chaque tutoriel vérifie un cas distinct ; cela ne garantit pas que toutes les fonctions conviennent au même produit.

Un site statique : des fichiers que le navigateur peut charger

Une page HTML avec du CSS et des images peut être servie sous forme de fichiers. Un projet React utilisant Vite peut aussi produire des fichiers statiques après compilation. Toutes les applications React ne sont pas pour autant statiques : vérifiez la présence de code serveur et de services externes.

Examinez package.json et sa commande de build. Dans un projet Vite configuré pour un déploiement statique, npm run build produit généralement dist; ce dossier peut être modifié dans la configuration. Ne publiez pas node_modules et ne confondez pas le serveur de développement avec le résultat de production. Vite décrit cette procédure.

Hostbrid Projects importe des dépôts GitHub, GitLab ou Bitbucket, construit le projet et le publie avec HTTPS. Vérifiez la commande de build et le dossier de sortie correspondant à votre dépôt. Ce parcours utilise Git : télécharger un ZIP depuis un outil ne signifie pas que le panneau accepte son envoi direct.

Si votre site contient du HTML et du CSS sans backend, suivez le tutoriel de publication d’un site HTML créé avec une IA, avec un dépôt réutilisable, les réglages et une démonstration publiée.

Si le site contient un formulaire, distinguez validation navigateur, backend et livraison avec notre guide de diagnostic des formulaires. Un message de succès ne prouve pas la réception du courrier ; l’exemple original valide uniquement des données synthétiques en local, sans envoi.

Une application avec serveur : un processus qui doit rester actif

Une API Node, des pages générées à chaque requête ou un service Docker nécessite un environnement capable d’exécuter ce processus. Copier uniquement les fichiers du frontend laisserait cette partie de côté.

Projects propose aussi des backends et des conteneurs avec une offre payante. Identifiez d’abord la commande de démarrage, le port, les variables d’environnement et les besoins de stockage persistant. Un dossier nommé dist ne prouve pas, à lui seul, que l’application est statique.

Si votre projet nécessite un processus serveur, vérifiez port, santé, routes et mémoire avec notre exemple original Node et Docker. Le test du conteneur ne démontre pas un service public en HTTPS.

Si votre application utilise Prisma et PostgreSQL, vérifiez comment appliquer les migrations en production et contrôler les données avant de déplacer le backend. Déployer le code ne copie pas les enregistrements de votre base locale.

Un frontend avec backend externe : conservez ses dépendances

Un site statique peut utiliser un service externe pour la connexion, les fichiers ou les données. Déplacer le frontend ne supprime pas ces dépendances. Vérifiez les URL de redirection d’authentification autorisées, les domaines permis et les variables du nouveau déploiement. Si vous gardez Supabase en déplaçant un frontend Vite, consultez le guide sur l’URL, RLS et les redirections pour effectuer ces contrôles.

Si la connexion échoue après un changement de domaine

Mettez à jour l’URL du site et la liste des destinations autorisées dans votre fournisseur d’authentification. Avec OAuth, vérifiez aussi que l’URL de callback exacte du fournisseur est autorisée dans la console du fournisseur social : l’URL de retour de votre application et la callback du fournisseur ont des rôles différents. Par exemple, Supabase recommande le chemin exact de production et Auth0 compare les callbacks à sa liste autorisée. Avec Firebase, vérifiez le domaine autorisé et le domaine authDomain utilisé par la redirection (documentation Firebase).

Séparez le domaine de production des URL de prévisualisation et limitez les règles génériques aux environnements que vous contrôlez. Ensuite, dans une fenêtre privée, testez l’inscription, la callback OAuth, la déconnexion, la récupération du mot de passe et les liens de confirmation utilisés par votre application. Ouvrez aussi directement une route protégée, puis rechargez-la. Si le parcours renvoie vers localhost, affiche une erreur de callback ou perd la session, vérifiez l’URL envoyée par le navigateur et la configuration du fournisseur ; n’exposez pas de secrets pour diagnostiquer le problème.

Avec Lovable, examinez l’architecture de votre projet avant de l’exporter : tous ne suivent pas le même parcours. Sa documentation sur l’hébergement et la propriété explique les options. PostgreSQL seul ne remplace pas l’authentification, le stockage et les fonctions de Supabase. Si vous avez créé l’app avec Bolt ou Replit, consultez aussi nos guides pour héberger Bolt Cloud ailleurs et héberger un projet Replit hors de sa plateforme.

Les vérifications avant de choisir une offre

1. Listez les composants : frontend, serveur, données, connexion, fichiers et services tiers.
2. Confirmez une destination compatible pour chacun et calculez le coût total.
3. Consultez les offres et limites. L’activation de Dev nécessite une carte ; un domaine personnalisé et les services permanents ont des conditions différentes du déploiement statique gratuit. L’enregistrement et le renouvellement du domaine sont facturés séparément.
4. Gardez les identifiants privés hors du code envoyé au navigateur et du dépôt.
5. Après publication, testez depuis un autre appareil : ouvrez directement une route interne, puis vérifiez la connexion, les formulaires et les fichiers lorsqu’ils existent.

Pour le parcours Git, consultez Projects. Pour WordPress et les applications d’hébergement web, consultez Sites. En cas de doute sur l’architecture, contactez Hostbrid en indiquant le framework, le backend et les dépendances, sans transmettre de mots de passe ni de clés privées.

Si vous hésitez entre un panneau géré et l’accès au système, comparez hébergement mutualisé et VPS selon l’environnement d’exécution, le contrôle et la maintenance que vous pouvez assurer.

Si votre projet utilise WordPress, des fichiers statiques ne remplacent ni sa base de données ni ses médias. Consultez le diagnostic de migration WordPress pour vérifier SQL, médias et URL avant de choisir la destination.