# Voir son site migré avant tout le monde

> Fichier hosts sous Windows, macOS et Linux, adresse temporaire de l'hébergeur, piège du certificat HTTPS : tester un site migré avant de basculer le DNS.


*Ou : la répétition générale se joue devant une salle vide, et c'est voulu.*

La réponse courte : pour voir votre site chez le nouvel hébergeur avant le reste du monde, vous avez deux moyens. Le premier est l'adresse temporaire que l'hébergeur fournit pour chaque site. Le second est une ligne dans le fichier hosts de votre ordinateur, qui associe votre nom de domaine à l'adresse IP du nouveau serveur. Ce fichier est consulté avant tout serveur DNS, comme le rappelle [l'article de Wikipédia sur le fichier hosts](https://fr.wikipedia.org/wiki/Hosts) : votre navigateur, et lui seul, voit le nouveau site sous sa vraie adresse, pendant que les visiteurs restent sur l'ancien. C'est l'étape que toute [migration vers un nouvel hébergeur](/guides/hebergement-web/changer-hebergeur-migration/) devrait prévoir avant de toucher à la zone DNS.

Le piège tient au HTTPS. Tant que le DNS public pointe vers l'ancien serveur, le nouvel hébergeur ne peut pas obtenir de certificat Let's Encrypt par la méthode la plus courante, et votre navigateur affichera une alerte. Ce n'est pas un défaut du nouveau serveur. C'est le signe que le certificat viendra après la bascule.

## Modifier le fichier hosts pour tester un site avant la bascule DNS

Il vous faut l'adresse IP du nouvel hébergement, affichée dans son panneau d'administration, puis une ligne de ce type, adresse d'abord, noms ensuite :

```text
# Test de migration : à retirer après la bascule
203.0.113.10   exemple.be www.exemple.be
```

L'adresse 203.0.113.10 sert ici d'exemple : remplacez-la par celle du nouveau serveur, et le domaine par le vôtre. Pensez aux deux formes du nom, avec et sans `www`, sinon la moitié des liens vous ramèneront chez l'ancien hébergeur sans prévenir.

| Système | Emplacement du fichier | Pour enregistrer |
|---|---|---|
| Windows (depuis NT) | `%SystemRoot%\system32\drivers\etc\hosts` | éditeur ouvert en tant qu'administrateur |
| macOS (OS X 10.2 et suivants) | `/private/etc/hosts`, aussi accessible par `/etc/hosts` | `sudo` dans le Terminal |
| Linux et autres Unix | `/etc/hosts` | `sudo` ou compte root |

Le fichier relève de l'administrateur de la machine, d'où les droits élevés. La modification est prise en compte sans redémarrage ; un navigateur qui garde ses propres résolutions en mémoire demande seulement d'être relancé. Sous Windows, la [documentation de la commande ipconfig](https://learn.microsoft.com/fr-fr/windows-server/administration/windows-commands/ipconfig) précise que `ipconfig /displaydns` affiche les entrées préchargées depuis le fichier hosts, et `ipconfig /flushdns` vide le cache du résolveur.

Comment savoir que vous êtes bien sur le nouveau serveur ? Le plus simple est de déposer chez le nouvel hébergeur un petit fichier qui n'existe que là, par exemple `migration-test.txt`, et de l'ouvrir. S'il s'affiche, le fichier hosts fait son travail. S'il renvoie une erreur 404, vous regardez encore l'ancien site.

![Illustration : un judas dans une lourde porte sombre, traversé par une lumière ambrée](/images/tester-site-avant-bascule-dns-judas.original.webp "Le fichier hosts est un judas : vous voyez le nouveau site, le reste du monde voit toujours l'ancien.")

**L'adresse temporaire, pratique mais capricieuse.** L'autre voie évite de toucher à votre machine. Infomaniak, par exemple, affiche pour chaque site une [URL de prévisualisation](https://www.infomaniak.com/fr/support/faq/2060/previsualiser-un-site-peu-importe-son-nom-de-domaine?utm_term=67f2b039d38a3) en `preview.infomaniak.website`. Elle est réservée aux offres payantes et peut changer à tout moment. La même FAQ signale le défaut classique : si l'adresse de prévisualisation saute aussitôt vers une autre URL, un fichier `.htaccess` contenant des règles de réécriture en est souvent la cause. Avec le fichier hosts, le site est appelé par son vrai nom, et ce genre de règle ne gêne plus.

**Ce qu'il faut vérifier pendant la répétition.** Google recommande de tester complètement la copie du site : pages, images, formulaires et documents. Ajoutons ce que les migrations cassent le plus souvent :

- les formulaires de contact, qui envoient désormais leurs mails depuis le nouveau serveur ;
- la connexion à l'administration du site et aux comptes clients ;
- les tâches planifiées (cron), à recréer à la main dans le nouveau panneau ;
- les versions de PHP et les extensions demandées par le site ;
- les liens codés en dur vers une ancienne adresse ou un ancien chemin de fichiers.

Côté HTTPS, Let's Encrypt explique, dans sa [description des types de challenges](https://letsencrypt.org/fr/docs/challenge-types/), que la méthode HTTP-01 consiste à lire un fichier déposé sur votre serveur, sur le port 80, depuis ses propres serveurs et parfois depuis plusieurs endroits. Ces serveurs suivent le DNS public, donc l'ancien hébergeur, tant que la bascule n'a pas eu lieu. La méthode DNS-01, qui passe par un enregistrement TXT, échappe à cette contrainte, mais elle suppose que le nouvel hébergeur, ou son outil, puisse écrire dans la zone DNS du domaine. En pratique, vous testez avec l'alerte de certificat, que vous acceptez temporairement, et vous vérifiez le cadenas une fois le DNS basculé.

### Quand la répétition est concluante

Un test réussi ne déclenche pas encore la bascule : il reste à préparer le DNS pour que les visiteurs suivent vite. La valeur à abaisser, et surtout le moment où l'abaisser, sont expliqués dans [la préparation du TTL avant la bascule](/guides/hebergement-web/changer-hebergeur-migration/baisser-ttl-avant-migration/).

### Un WordPress qui se croit encore chez l'ancien hébergeur

WordPress enregistre son adresse dans la base de données. Tant que le domaine reste le même, une copie fidèle s'affiche sans retouche par le fichier hosts. Les ennuis commencent si vous testez par une adresse temporaire et changez les URL pour l'occasion, ou si une extension de cache sert encore des pages générées sur l'ancien serveur. Les méthodes de copie et le remplacement propre des URL sont détaillés dans [le choix entre extension et copie manuelle](/guides/hebergement-web/changer-hebergeur-migration/migrer-cms-extension-ou-manuel/).

### Retirer la ligne, et seulement ensuite fermer l'ancien compte

Une fois le DNS basculé, retirez la ligne du fichier hosts. Infomaniak le rappelle : une entrée oubliée vous empêchera d'afficher le site le jour où l'adresse IP du serveur changera. Gardez aussi l'ancien hébergement actif tant que des visiteurs y arrivent encore. Le bon moment pour le résilier, et ce que deviennent les données ensuite, sont détaillés dans [la résiliation de l'ancien hébergeur](/guides/hebergement-web/changer-hebergeur-migration/resilier-ancien-hebergement/).


---

Cette page contient des liens d'affiliation. Si tu souscris via ces liens, je peux toucher une commission sans coût supplémentaire pour toi. Mon avis reste indépendant et s'appuie sur mon expérience de client de plusieurs hébergeurs, sur leur documentation officielle et sur les tarifs vérifiés à la date de rédaction.