Du localhost à une vraie URL : mettre ton projet en ligne

« Ça marche chez moi » n'est pas « c'est en ligne ». Entre le projet qui tourne sur ton écran et une vraie URL que tu peux envoyer à quelqu'un, il y a une marche — et c'est celle qui bloque le plus de monde. Bonne nouvelle : ce n'est pas de la magie, c'est une suite d'étapes claires. Voici comment les franchir proprement.

« localhost », c'est juste chez toi

Quand tu lances npm run dev, ton ordinateur démarre un petit serveur qui ne sert qu'à toi. L'adresse localhost (ou 127.0.0.1) est une boucle interne : elle revient à ta propre machine. Personne d'autre sur Terre ne peut l'ouvrir. Ce n'est pas Internet, c'est ton atelier privé.

« En ligne » veut dire autre chose : ton code tourne sur une machine toujours allumée, joignable à une adresse publique, que n'importe qui peut atteindre avec l'URL. Cette machine, c'est l'hébergeur.

Déployer, c'est donc déménager ton projet de l'atelier vers la boutique : une machine publique, configurée pour la production. Tout le reste de l'article, ce sont les détails de ce déménagement — et aucun n'est sorcier.

Le build : ce que tu livres n'est pas ce que tu codes

Le code que tu écris (React, Vue, etc.) n'est pas exécuté tel quel par le navigateur. Une étape de build le transforme en fichiers optimisés — du HTML, CSS et JavaScript compacts que le navigateur charge vite. En dev, tu utilises npm run dev, pratique mais bavard, pensé pour toi. Pour livrer, tu lances npm run build, qui produit le vrai paquet, généralement dans un dossier dist/ ou build/.

Le réflexe qui t'évite l'essentiel des galères de premier déploiement : lance npm run build en local avant de déployer. Le mode dev pardonne des choses que la build de production, elle, refuse — une erreur de type, un import bancal, une variable manquante. Mieux vaut découvrir ça dans ton atelier que devant tes visiteurs. Si la build passe chez toi, tu pars du bon pied.

Les variables d'environnement ne voyagent pas

Souvenir classique du premier déploiement : « ça marchait chez moi, et en ligne c'est cassé ». Le plus souvent, le coupable est une variable d'environnement.

Ton fichier .env local reste sur ta machine — et c'est tant mieux, il n'a rien à faire en ligne. L'hébergeur a son propre endroit pour définir ces valeurs : un écran « Environment Variables » dans son tableau de bord. Si ton app lit une clé d'API ou une URL de base de données depuis l'environnement, il faut la recréer là, sinon elle est tout simplement absente en production.

Le réflexe : avant de déployer, liste ce que ton app attend de l'environnement, et reporte chaque entrée côté hébergeur. Et garde en tête la distinction client/serveur — une variable destinée au navigateur finit dans le bundle public, donc on n'y met jamais de secret.

Site statique ou app avec serveur ?

C'est LA question qui détermine ton hébergeur. Deux cas :

• Un site statique : une fois buildé, ton projet n'est qu'un paquet de fichiers (le front-end seul — une page, une SPA React, un site généré). Ça se sert depuis un hébergeur statique, souvent gratuit pour démarrer : Netlify, Vercel, Cloudflare Pages, GitHub Pages.
• Une app avec serveur : tu as du code qui tourne côté serveur — une API, des pages rendues côté serveur, une base à interroger avec une clé secrète. Là, il te faut un hébergeur qui exécute ton code en continu (ou via des fonctions) : Vercel, Netlify, Railway, Render, Fly.io…

La question qui tranche : est-ce que ton app doit faire tourner du code sur un serveur, ou est-ce juste des fichiers que le navigateur exécute ?

Cas très fréquent en vibecoding : un front-end branché sur un backend géré comme Supabase. Dans ce schéma, ton front est statique (hébergeur statique) et le « serveur », c'est Supabase. Simple et économique.

Et ne te crispe pas sur le « comment » : les hébergeurs modernes détectent ton framework, lancent le build à ta place et se connectent à ton dépôt Git — à chaque push, ça redéploie tout seul. Déployer, en pratique, c'est souvent : connecter le repo, renseigner les variables, et laisser la plateforme faire.

HTTPS et nom de domaine

Deux derniers points, plus simples qu'ils n'en ont l'air.

Le HTTPS — le petit cadenas qui chiffre le trafic — est aujourd'hui quasi obligatoire. La bonne nouvelle : sur un hébergeur correct, tu n'as rien à faire, il te le fournit automatiquement et gratuitement. Ce qui était un calvaire il y a quelques années est devenu un non-événement.

Le nom de domaine est optionnel, et ça vaut la peine de le dire : dès ton déploiement, l'hébergeur te donne déjà une URL publique (du type ton-app.vercel.app). Tu es déjà en ligne avant d'acheter quoi que ce soit. Pour utiliser ton propre monsite.com, tu l'achètes chez un registrar (OVH, Gandi, Cloudflare, Namecheap…), puis tu le fais pointer vers ton hébergeur en ajoutant un enregistrement DNS — l'hébergeur te donne la valeur exacte à coller. Le DNS, c'est l'annuaire d'Internet : tu ajoutes simplement une ligne qui dit « ce nom mène ici ». La propagation peut prendre un moment, puis l'hébergeur active le HTTPS sur ton domaine tout seul.

En résumé

Passer du localhost à une vraie URL, ce n'est pas un saut dans le vide : c'est déménager ton projet sur une machine publique, en pensant à la build, aux variables d'environnement et au bon type d'hébergeur. Vérifie ta build en local, reporte tes variables côté hébergeur, choisis statique ou serveur selon ce que fait ton app, et branche un domaine quand tu veux — tu es en ligne bien avant ça. Mettre en prod posément, étape par étape : c'est exactement ça, vibecoder comme un pro.