Comment publier un site depuis localhost

Un site qui s’ouvre sur localhost n’est disponible que sur l’ordinateur qui l’exécute. Pour que d’autres personnes puissent le consulter, publiez chaque partie du projet sur un service accessible par Internet. Choisissez l’hébergement selon ce qui doit s’exécuter, pas selon l’éditeur ou l’IA qui a généré le code.

Si votre projet contient du HTML créé avec une IA, consultez le guide de publication HTML et CSS. Pour React et Vite, suivez le tutoriel de déploiement depuis Git. Si Codex a créé le projet, comparez ChatGPT Sites au déploiement depuis un dépôt avant de choisir l’hébergement.

1. Identifiez ce qui se trouve derrière la page

Examinez le dossier du projet, package.json, la documentation et les scripts. Notez s’il contient :

Des fichiers statiques : HTML, CSS, images et parfois du JavaScript téléchargé par le navigateur. Certains projets React/Vite ou Astro produisent aussi des fichiers statiques après une compilation.
Un processus serveur : une API, des pages générées à chaque requête, une authentification propre, des tâches en arrière-plan ou un service Node/Python.
Des services externes : base de données, stockage de fichiers, e-mail, connexion ou API. Une page qui s’affiche ne prouve pas que ces intégrations sont connectées.

Un serveur de développement comme npm run dev sert à travailler sur votre ordinateur. Ce n’est pas la version publique. Vérifiez la commande de compilation et le dossier de sortie du framework ; Vite crée généralement dist, mais la configuration peut changer ce dossier (documentation Vite).

2. Enregistrez et préparez le projet

Placez le code dans un dépôt Git et gardez une copie avant de modifier sa configuration. Ne publiez pas les fichiers .env, mots de passe, clés privées ou données réelles de clients. Recherchez localhost, les chemins de votre disque et les URL de test ; sur un site public, localhost désigne l’appareil de chaque visiteur.

Si le dossier n’est pas encore suivi par Git, ajoutez d’abord à .gitignore des règles pour les dépendances et les secrets, par exemple :

node_modules/
.env
.env.*
!.env.example

Depuis le dossier du projet, initialisez et vérifiez le dépôt avant le premier commit :

git init -b main
git add .
git status --short
git commit -m "Première version"

Si git status affiche une clé, un fichier .env ou des données privées, ne faites pas le commit : retirez-les des éléments préparés et corrigez .gitignore. Cette règle ne cesse pas de suivre les fichiers déjà enregistrés par Git. Créez ensuite un dépôt vide — privé si le code appartient à un client — puis associez son URL :

git remote add origin https://github.com/UTILISATEUR/DEPOT.git
git push -u origin main

Si le dossier contient déjà .git, ne créez pas de dépôt imbriqué : vérifiez la branche et le dépôt distant avec git branch --show-current et git remote -v. Le guide GitHub pour ajouter du code local présente d’autres variantes. Connectez ensuite ce dépôt à Hostbrid Projects ; le manuel Projects explique les autorisations et le choix du dépôt.

Si le projet est un monorepo, notez le dossier de l’application et les fichiers nécessaires à l’installation et à la compilation. Ne supprimez pas une API, un dossier serveur ou une intégration simplement pour faire fonctionner la page d’accueil.

3. Choisissez où exécuter chaque composant

Pour HTML, CSS et les autres fichiers statiques, il vous faut un hébergement qui les sert et permet d’ouvrir les routes publiques. Hostbrid Sites couvre les sites gérés tels que WordPress ; vérifiez son catalogue et ses limites pour votre projet précis.

Pour un dépôt qui nécessite compilation et déploiement depuis Git, découvrez Hostbrid Projects. Projects peut aussi exécuter des services Docker dans la limite de l’offre : Dev publie des projets statiques, tandis que les services permanents nécessitent une offre payante. Consultez les offres et prix Projects pour connaître le nombre de services et les ressources disponibles avant de commander. Une compilation statique ne lance pas à elle seule une API Node dont votre application dépend.

Envisagez un VPS si vous avez besoin d’un accès root, du contrôle du système d’exploitation, d’une configuration réseau ou de processus qui dépassent les limites de Projects. Avec un VPS, vous gérez le système, ses mises à jour, la sécurité, les sauvegardes et les déploiements. Comparez les offres et prix actuels aux besoins réels, pas seulement à la taille du dossier.

4. Configurez la compilation, les variables et les données

Définissez les commandes d’installation et de compilation, ainsi que le dossier de sortie propre au framework. Les variables du frontend peuvent se retrouver dans les fichiers reçus par le navigateur : n’y placez aucun secret. Gardez les clés privées sur le serveur et configurez-les comme variables d’environnement protégées.

Si vous utilisez une base locale, la migration consiste à transférer son schéma et ses données par une procédure adaptée, puis à modifier la connexion de production. Publier le code ne copie pas automatiquement SQLite ni une autre base de votre ordinateur. Lisez comment préparer une migration PostgreSQL avant de connecter de vraies données.

Un formulaire a également besoin d’une destination qui accepte et traite les soumissions. Consultez comment vérifier le backend et la réception du formulaire ; le message « envoyé » à l’écran ne prouve pas que l’e-mail est arrivé.

5. Testez la version publique avant de l’annoncer

Ouvrez l’URL HTTPS depuis un autre appareil et testez la page d’accueil ainsi qu’une route interne saisie directement dans la barre d’adresse. Vérifiez les images, styles, erreurs de console, liens, connexion, formulaires et appels API réellement utilisés par le projet. Si vous modifiez une variable de compilation, recompilez : la modifier ensuite ne change pas les fichiers déjà publiés.

Connectez le domaine lorsque la version temporaire fonctionne. Configurez les enregistrements DNS indiqués par le fournisseur, attendez leur propagation et vérifiez le certificat HTTPS. Gardez l’ancien site accessible tant que le nouveau n’est pas validé et conservez un moyen de revenir à la version précédente.

Quelle offre choisir pour votre projet ?

HTML ou frontend compilé sans serveur propre : vérifiez les offres compatibles avec ces fichiers et routes. Build Git ou service Docker dans la limite de l’offre : consultez Projects et ses limites. Accès root, contrôle système ou besoins au-delà de ces limites : envisagez un VPS. Pour WordPress et les autres services PHP gérés, consultez Sites. Si vous ne savez pas où le frontend s’arrête et où le backend commence, indiquez-nous le framework et ses services, sans transmettre de secrets.

Publier rend le site accessible ; cela ne garantit ni son indexation par Google, ni une position donnée, ni une recommandation par une IA. Vérifiez d’abord son fonctionnement et que le contenu public répond aux questions de vos visiteurs.