Localhost, adresse IP ou nom de domaine ? Comment donner une vraie adresse à votre site web

Vous avez créé un site web avec l'IA, et il fonctionne parfaitement, sur votre propre ordinateur. La barre d'adresse affiche localhost:3000, ou peut-être une suite de chiffres comme 203.0.113.10. Vous envoyez le lien à un ami, et il ne s'ouvre pas.

Ce n'est pas un bogue. C'est l'écart entre faire tourner un site web et le publier, et la pièce manquante est presque toujours un nom de domaine. Ce guide explique la différence entre les adresses que vous utilisez peut-être aujourd'hui, pourquoi la plupart ne peuvent pas être la vraie adresse de votre site, et comment passer à un vrai nom de domaine, quel que soit votre type d'hébergement.

Les quatre types d'adresse

On peut accéder à un site web de quatre façons différentes. Elles se ressemblent, mais fonctionnent très différemment.

Les nombres de ce guide sont des exemples. 203.0.113.x est une plage réservée aux exemples, elle ne pointe donc jamais vers un vrai serveur.

Pourquoi localhost ne fonctionne que pour vous

localhost (aussi écrit 127.0.0.1) signifie « cette machine-ci ». Quand vous le saisissez, votre ordinateur se parle à lui-même. Quand votre ami saisit la même adresse, c'est son ordinateur qui se parle à lui-même, ne trouve rien et affiche une erreur. Ce mot a un sens différent sur chaque appareil.

Les adresses qui commencent par 192.168., 10. ou 172.16. à 172.31. sont la même chose à plus grande échelle. Ce sont des adresses privées, utilisées dans les foyers et les bureaux. Les personnes connectées à votre Wi-Fi peuvent les ouvrir, mais personne sur internet ne le peut.

Faire tourner un site en local est la bonne façon de le construire. Le problème commence quand c'est le seul endroit où il existe. Votre site n'est d'ailleurs en ligne que tant que votre ordinateur est allumé et que l'application tourne.

Pourquoi l'IP d'un serveur n'est pas une vraie adresse

Une fois votre site hébergé sur un vrai serveur, que ce soit un hébergement mutualisé, un VPS ou une machine dans le cloud, vous pouvez l'ouvrir avec l'adresse IP du serveur. Certains s'arrêtent là. Cela pose plusieurs problèmes :

• Le serveur peut ne pas savoir quel site afficher. Une même IP dessert souvent de nombreux sites web, et le serveur choisit lequel afficher d'après le nom de domaine contenu dans la requête. Si vous ouvrez l'IP seule, vous pouvez obtenir une page par défaut, une erreur, ou le site de quelqu'un d'autre.
• Pas de vrai HTTPS. HTTPS est normalement configuré pour un nom de domaine, et une IP seule ne peut généralement pas obtenir le certificat gratuit standard. Sans HTTPS, les navigateurs affichent « Non sécurisé », et tout ce que saisissent les visiteurs, comme les mots de passe et les données de formulaire, circule en clair.
• Cela casse quand vous déménagez. L'IP appartient au serveur. Si vous changez d'hébergeur ou d'offre, le numéro change et tous les liens que vous avez partagés cessent de fonctionner. Avec un nom de domaine, il suffit de le faire pointer vers le nouveau serveur.
• Les gens et les filtres s'en méfient. De nombreux filtres anti-spam et outils de sécurité jugent suspects les liens faits uniquement de chiffres, et les visiteurs ne peuvent ni les retenir ni les reconnaître.
• Pas d'e-mail professionnel. Une adresse comme hello@mysite.com nécessite un nom de domaine.
• Des copies en double pour les moteurs de recherche. Si votre site répond à la fois sur l'IP et sur le domaine, les moteurs de recherche peuvent voir deux copies de chaque page.

Ce qu'est vraiment un nom de domaine

Les ordinateurs se trouvent grâce à des numéros IP. Un nom de domaine est une étiquette lisible pour ce numéro, et un système appelé DNS joue le rôle d'annuaire d'internet : vous lui donnez un nom, il vous rend le numéro.

Trois acteurs interviennent :

• Le registraire : l'entreprise auprès de laquelle vous enregistrez le domaine. Vous n'achetez pas un domaine pour toujours. Vous le louez, en général un an à la fois, et vous le renouvelez.
• Le DNS : il conserve les enregistrements qui indiquent vers quel serveur pointe votre domaine.
• Votre hébergeur : l'endroit où se trouvent les fichiers de votre site.

Mettre votre site sur votre domaine

Les étapes suivent la même logique chez tous les hébergeurs. Seuls les boutons et les noms de menus changent.

1. Savoir où se trouve votre site

Ce vers quoi vous faites pointer votre domaine dépend de votre type d'hébergement :

Suivez toujours les instructions de votre hébergeur pour les valeurs exactes. Elles figurent dans son tableau de bord ou sa documentation, et souvent dans l'e-mail de bienvenue.

2. Faire pointer le domaine vers votre hébergeur

Vous pouvez le faire de deux manières. Choisissez-en une, pas les deux.

• Option A : changer les serveurs de noms (nameservers). Chez votre registraire, remplacez les serveurs de noms du domaine par ceux que vous donne votre hébergeur. À partir de là, vous gérez tous les enregistrements dans le tableau de bord de l'hébergeur.
• Option B : garder le DNS où il est (chez le registraire ou dans un service comme Cloudflare) et y ajouter des enregistrements : un enregistrement A qui envoie le domaine vers l'IP de votre serveur, et un enregistrement CNAME pour que www le suive.

3. Informer votre hébergeur du domaine

Faire pointer le domaine vers un serveur ne suffit pas. Le serveur doit aussi savoir quel site correspond à ce nom. Chaque hébergeur a un endroit pour cela : une page Domaines sur un hébergement mutualisé (celle de cPanel en est un exemple), une ligne server_name dans les réglages du serveur web sur votre propre serveur, ou un onglet Domaines dans les paramètres du projet d'une plateforme. Si vous sautez cette étape, votre domaine atteint le serveur mais affiche une page par défaut.

4. Attendre la propagation du DNS

C'est ce qu'on appelle la propagation. Elle peut prendre de quelques minutes à un jour ou deux, même si elle est souvent rapide. Tant qu'elle n'est pas terminée, le domaine peut échouer ou afficher une ancienne page pour certaines personnes.

5. Activer HTTPS

La plupart des plateformes et de nombreux hébergeurs installent automatiquement un certificat gratuit dès que votre domaine pointe vers eux. Sur votre propre serveur, vous pouvez utiliser un service de certificats gratuits comme Let's Encrypt avec l'outil Certbot. Dans les deux cas, le domaine doit déjà pointer vers le serveur. Une fois cela fait, configurez le site pour rediriger toutes les visites http vers https.

6. Choisir une seule version de votre adresse

mysite.com et www.mysite.com comptent comme deux adresses différentes. Choisissez-en une comme adresse principale et redirigez l'autre vers elle. Les plateformes ont généralement un réglage pour cela. Sur un serveur Apache, ces règles font le travail (placez-les dans le fichier .htaccess du site). La première envoie www vers le domaine sans www, et la seconde envoie vers votre domaine toute personne qui arrive par l'IP brute du serveur :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.mysite\.com$ [NC]
RewriteRule ^(.*)$ https://mysite.com/$1 [L,R=301]

RewriteCond %{HTTP_HOST} ^203\.0\.113\.10$
RewriteRule ^(.*)$ https://mysite.com/$1 [L,R=301]

Remplacez le domaine et l'IP d'exemple par les vôtres. Sur Nginx ou un autre serveur, l'idée est la même, mais la syntaxe est différente ; consultez donc sa documentation.

Corriger les adresses cachées dans votre code

Le code écrit par une IA contient souvent localhost en dur. Sur un site en ligne, cela casse des choses de façon déroutante. Le navigateur d'un visiteur interprète localhost comme son propre ordinateur : votre page essaie donc de charger des données depuis une machine qui n'a rien à voir avec votre site.

À éviter :

fetch("http://localhost:3000/api/products")

Correct (fonctionne partout) :

fetch("/api/products")

Cherchez dans tout votre projet localhost, 127.0.0.1, 192.168 et toute IP que vous avez utilisée. Vérifiez ensuite ces endroits :

• Réglages d'URL du site : des valeurs comme APP_URL ou BASE_URL doivent utiliser votre vrai domaine, en https.
• Services de connexion et de paiement : la connexion Google, les passerelles de paiement et les services similaires exigent votre vrai domaine dans leurs tableaux de bord, comme adresse de redirection (callback) autorisée. Les webhooks de paiement ne peuvent pas du tout atteindre localhost, car les serveurs de la passerelle ont besoin d'une adresse HTTPS publique.
• Origines autorisées (CORS) : si votre code liste des adresses autorisées, remplacez localhost par votre domaine.
• Sitemap et balises canoniques : ils doivent afficher le domaine, pas une IP ni une adresse locale.

Problèmes courants

• « Impossible d'accéder à ce site » juste après la configuration : le DNS ne s'est peut-être pas encore propagé, ou un enregistrement est incorrect. Patientez, puis vérifiez les enregistrements.
• Le domaine affiche la page par défaut de votre hébergeur : le domaine atteint votre serveur, mais le serveur ne sait pas que le site lui appartient. Ajoutez le domaine dans les réglages de votre hébergeur.
• Il affiche un ancien site ou celui de quelqu'un d'autre : un ancien enregistrement ou le cache de votre navigateur. Essayez une fenêtre de navigation privée, ou un autre réseau.
• « Non sécurisé » ou une erreur de certificat : le certificat n'a pas encore été émis, ou le domaine ne pointe pas encore vers votre hébergeur.
• Ça marche avec www mais pas sans (ou l'inverse) : il manque un enregistrement. Ajoutez le CNAME pour www.
• Utiliser un outil de tunnel pour une démo : des outils comme ngrok ou Cloudflare Tunnel conviennent pour un test rapide, mais ce n'est pas de l'hébergement.
• Ouvrir la box de votre domicile à internet (redirection de ports) : évitez-le. Cela expose votre réseau domestique, et les IP de particuliers changent souvent.

Protéger votre domaine

Votre domaine est l'adresse la plus précieuse que vous possédez, alors protégez-le :

• Activez le renouvellement automatique. Un domaine expiré peut être enregistré par quelqu'un d'autre.
• Utilisez un mot de passe fort et unique ainsi que l'authentification à deux facteurs sur votre compte chez le registraire.
• Activez le verrouillage du registraire, qui empêche le transfert du domaine sans votre accord.
• Gardez votre e-mail de contact à jour, car c'est là que arrivent les avis de renouvellement et de sécurité.

L'auto-vérification de 2 minutes

• Ouvrez http://VOTRE-IP-DE-SERVEUR. Elle ne devrait pas afficher votre site (ou devrait vous rediriger vers votre domaine).
• Ouvrez http://mysite.com. Vous devriez arriver sur https://mysite.com avec un cadenas.
• Ouvrez la version avec www. Vous devriez arriver à la même adresse finale.
• Cherchez dans votre projet localhost et tout numéro d'IP.
• Dans un terminal, lancez nslookup mysite.com. La réponse doit afficher l'IP de votre hébergeur (ou, sur une plateforme, vous renvoyer vers ses serveurs).

La liste de contrôle rapide

1. N'utilisez localhost que pour construire, jamais comme adresse
2. Enregistrez un domaine et activez le renouvellement automatique et l'authentification à deux facteurs
3. Faites-le pointer vers votre hébergeur avec les serveurs de noms (Option A) ou des enregistrements A et CNAME (Option B), pas les deux
4. Ajoutez le domaine dans les réglages de votre hébergeur pour que le serveur sache à quel site il correspond
5. Attendez la propagation du DNS, puis activez HTTPS
6. Choisissez une version (avec ou sans www) et redirigez l'autre
7. Remplacez chaque localhost et chaque IP dans votre code, et mettez à jour les tableaux de bord de connexion et de paiement
8. Empêchez le site de répondre sur l'IP brute du serveur

Un nom de domaine, c'est ce qui transforme « ça marche sur mon ordinateur » en « tout le monde peut le visiter ». Configurez-le une fois, correctement, et tous les liens que vous partagerez continueront de fonctionner, même si vous changez d'hébergeur plus tard.