Prévisualiser un site sur un nouveau serveur avant de modifier les DNS : toutes les méthodes comparées

Un serveur héberge souvent de nombreux sites et choisit le bon d’après le nom de domaine envoyé par le navigateur : http://203.0.113.10/ affiche donc une page par défaut ou un avertissement de certificat. Chaque méthode ci-dessous envoie la requête à la nouvelle IP tout en disant « je veux example.com ». Elles diffèrent par qui voit le résultat, sur quels appareils, et avec quelle exactitude.

Votre système d’exploitation lit le fichier hosts avant d’interroger le DNS. Une ligne par nom d’hôte fait pointer votre domaine vers le nouveau serveur, sur cet ordinateur uniquement :

# Windows: C:\Windows\System32\drivers\etc\hosts  (edit as Administrator)
# macOS / Linux: /etc/hosts  (edit with sudo)
203.0.113.10   example.com
203.0.113.10   www.example.com

# Then flush the DNS cache
ipconfig /flushdns                                              # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS
resolvectl flush-caches                                         # Linux with systemd-resolved

• Avantages : exact, gratuit et valable pour tout : IP privées, tous les ports, le certificat et les en-têtes propres au nouveau serveur. Le générateur de fichier hosts écrit les lignes pour vous.
• Inconvénients : une machine à la fois, droits d’administrateur requis, peu pratique sur iOS et Android, et facile à oublier. Une ligne oubliée après la migration vous laisse sur le mauvais serveur.
• Idéal pour : un développeur qui vérifie son propre travail, et la vérification finale du HTTPS, des en-têtes de sécurité et des connexions tierces avant la bascule.

--resolve indique à curl quelle IP utiliser pour un nom d’hôte : la requête porte votre vrai domaine, y compris dans la négociation TLS, et le certificat est vérifié :

# Status line and headers from the new server, over HTTPS
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/

# The page title, to make sure it is your site and not a default page
curl -s --resolve example.com:443:203.0.113.10 https://example.com/ | grep -i "<title>"

# No certificate yet? -k skips verification; plain HTTP works with a Host header
curl -skI --resolve example.com:443:203.0.113.10 https://example.com/
curl -sI -H "Host: example.com" http://203.0.113.10/

N’utilisez -H "Host: …" qu’en HTTP simple : en HTTPS, curl enverrait toujours l’IP lors de la négociation TLS et vérifierait le certificat par rapport à elle. Sous Windows, tapez curl.exe, car dans Windows PowerShell 5.1 curl est un alias de Invoke-WebRequest.

• Avantages : quelques secondes, rien à défaire, scriptable, et il montre les codes de statut, les redirections et le certificat exactement tels que le serveur les envoie.
• Inconvénients : aucun rendu : HTML et en-têtes seulement, et pour vous seul.
• Idéal pour : confirmer que le site est bien configuré sur le nouveau serveur avant d’y passer du temps, et les contrôles dans des scripts ou en CI.

Beaucoup d’hébergeurs donnent à chaque compte une adresse temporaire sur leur propre domaine, et les serveurs cPanel peuvent servir un compte à http://203.0.113.10/~username/ lorsque l’hébergeur a activé mod_userdir. Vous pouvez aussi ajouter un enregistrement pour un nouveau nom comme staging.example.com pointant vers le nouveau serveur : cela ajoute un nom d’hôte sans toucher aux enregistrements en production.

• Avantages : une URL ordinaire qui fonctionne sur tout appareil et s’envoie à n’importe qui, sans service supplémentaire.
• Inconvénients : le site répond pour un autre nom d’hôte. WordPress et la plupart des CMS redirigent vers le domaine enregistré dans leurs réglages, qui pointe encore vers l’ancien serveur, et les liens absolus et les cookies suivent aussi le vrai domaine. Y remédier impose un rechercher-remplacer à annuler avant la mise en ligne. Beaucoup d’hébergeurs désactivent les URL ~user, et le HTTPS porte sur le nom temporaire, pas sur votre domaine.
• Idéal pour : les sites statiques et les applications aux URL relatives, ou la remise d’un hébergeur quand rien d’autre n’est disponible.

Chrome et les autres navigateurs basés sur Chromium acceptent une option de démarrage qui associe des noms d’hôte à une IP pour cette session du navigateur uniquement. Un dossier de profil séparé garantit qu’une nouvelle instance démarre avec la règle :

# Windows (Command Prompt)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir=%TEMP%\chrome-preview --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

# macOS
open -na "Google Chrome" --args --user-data-dir=/tmp/chrome-preview --host-resolver-rules="MAP example.com 203.0.113.10, MAP www.example.com 203.0.113.10"

# A resolver for your whole network (dnsmasq; also covers subdomains)
address=/example.com/203.0.113.10

La dernière ligne applique la même idée un niveau plus haut : un résolveur local comme dnsmasq, ou un enregistrement DNS local dans Pi-hole, répond avec la nouvelle IP à tous les appareils qui l’utilisent, y compris les téléphones sur ce Wi-Fi, tant qu’ils utilisent le DNS du réseau et non leur propre DNS privé. Les extensions de navigateur ne peuvent pas modifier le fichier hosts ; certains services d’aperçu en proposent une comme raccourci vers leurs liens (hosts.click indique une extension Chrome ; DNSPeek n’en a pas encore).

• Avantages : aucun fichier système modifié, rien ne reste à la fermeture du navigateur, et une réponse exacte avec le vrai domaine et le vrai certificat.
• Inconvénients : l’option de Chrome ne fonctionne que sur ordinateur et se rate facilement si Chrome tourne déjà avec le même profil. Un résolveur demande quelqu’un pour le gérer, et il n’aide que les personnes sur votre réseau.
• Idéal pour : les développeurs qui veulent un comportement exact sans toucher au fichier hosts, et les équipes qui testent sur de vrais appareils dans un même bureau.

Un service d’aperçu vous donne un lien HTTPS sur son propre domaine. Il se connecte à l’IP saisie, demande votre vrai domaine et réécrit liens, redirections et cookies pour que les visiteurs restent dans l’aperçu. C’est la seule méthode ici qu’un client peut utiliser sans aide.

Ce que les services indiquent eux-mêmes, en octobre 2026 (détails dans DNSPeek vs SkipDNS, DNSPeek vs Peek-DNS et DNSPeek vs hosts.click) :

• Avantages : téléphones, tablettes et clients l’ouvrent comme n’importe quel lien, rien à installer ni à défaire, et un mot de passe ou une date d’expiration le gardent sous contrôle.
• Inconvénients : un proxy se trouve au milieu. DNSPeek, par exemple, supprime Strict-Transport-Security, Content-Security-Policy et X-Frame-Options et ajuste les attributs des cookies pour que l’aperçu fonctionne à sa propre adresse ; la connexion avec Google et les pages de paiement hébergées renvoient vers votre vrai domaine ; les pare-feu du nouveau serveur peuvent soumettre le trafic du proxy à une vérification ; et seules les IP publiques sont accessibles. Voir ce que les aperçus ne peuvent pas faire.
• Idéal pour : la relecture par les clients et les parties prenantes, les contrôles sur mobile, et toute personne à qui l’on ne devrait pas demander de modifier des fichiers système.

• Développeur seul, sur son propre ordinateur : curl --resolve, puis le fichier hosts ou l’option de Chrome. Ici, c’est tout simplement le meilleur choix : exact, gratuit, sans tiers sur le trajet. Gardez le lien d’aperçu pour votre téléphone.
• Agence avec validation client : un lien d’aperçu protégé par mot de passe. Le client ne touche jamais aux fichiers système ; vous gardez le fichier hosts pour vérifier le HTTPS, les en-têtes et la connexion, qu’un proxy modifie. Voir obtenir la validation du client avant la mise en ligne et DNSPeek pour les agences.
• Hébergeur qui migre ses clients : les URL temporaires cassent la plupart des CMS, alors envoyez des liens d’aperçu, créés via l’API ou avec un lien prérempli /new?domain=…&ip=…. S’il vous faut un bouton dans cPanel dès aujourd’hui, SkipDNS et hosts.click indiquent des plugins de panneau ; DNSPeek n’en a pas encore. Voir DNSPeek pour les hébergeurs.

La plupart des migrations combinent une vérification exacte pour vous et un lien pour tous les autres. Pour approfondir ce duo : fichier hosts ou lien d’aperçu ; pour le reste de la migration : la checklist de migration de site.

1. 1

   Étape 1 : Récupérer l’IP du nouveau serveur

   Prenez-la dans l’e-mail de bienvenue ou le panneau de contrôle du nouvel hébergeur, pas dans une résolution de votre domaine. Voir Trouver l’IP de votre serveur.

2. 2

   Étape 2 : Vérifier que le serveur répond pour votre domaine

   Lancez curl -sI --resolve example.com:443:203.0.113.10 https://example.com/. Un 200 ou une redirection vers votre propre domaine signifie que le site est configuré ; une page par défaut signifie qu’il ne l’est pas encore.

3. 3

   Étape 3 : L’examiner vous-même dans un navigateur

   Ajoutez des entrées hosts avec le générateur de fichier hosts ou lancez Chrome avec --host-resolver-rules, puis parcourez les pages clés, les formulaires et l’espace d’administration.

4. 4

   Étape 4 : Partager un lien d’aperçu avec la personne qui valide

   Saisissez le domaine et l’IP dans le formulaire de nouvel aperçu, ajoutez un mot de passe si le site est sensible, et envoyez le lien à votre client ou à votre équipe.

5. 5

   Étape 5 : Annuler vos substitutions après la bascule

   Supprimez les lignes du fichier hosts ou fermez le profil Chrome, puis confirmez que le DNS public a basculé avec le vérificateur de propagation DNS.