Voir son site migré avant tout le monde
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 : 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 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 :
| |
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 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.
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 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, 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.
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.
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.