« Combien de temps le site sera-t-il coupé ? » — c’est la première question qu’on
nous pose avant une migration. Et la réponse surprend toujours : zéro seconde, si c’est
fait dans le bon ordre. Une migration n’est pas un déménagement où le site quitte un serveur
puis arrive sur l’autre : c’est une copie suivie d’un changement d’adresse.
Pendant la phase critique, votre site tourne sur les deux serveurs en même temps — et vos visiteurs
passent de l’un à l’autre sans jamais le savoir. Voici la mécanique complète, avec les deux réglages
qui font toute la différence : le TTL DNS et le fichier hosts.
Le principe : copier, tester, puis seulement changer l’adresse
L’erreur des migrations improvisées est de raisonner en « bascule » : on résilie,
on transfère, on croise les doigts. Notre logique est inverse :
- →L’ancien hébergement reste intact et en service du début à la fin — on ne résilie rien avant la fin de la période de recouvrement.
- →Le nouveau serveur reçoit une copie complète (fichiers + base de données) qu’on configure et qu’on teste tranquillement, sans aucune pression.
- →Le DNS ne bascule qu’une fois le nouveau serveur validé — et grâce au TTL court, la bascule se propage en minutes, pas en jours.
La procédure technique détaillée (exports, base, wp-config, e-mails) est dans notre
guide de migration en 12 étapes ; ici on
se concentre sur ce qui garantit le zéro coupure.
Réglage n°1 : le TTL DNS — à baisser une semaine AVANT
Le TTL (time to live) indique aux résolveurs DNS du monde entier combien de temps garder votre
adresse IP en cache. Par défaut, il est souvent réglé sur 24 à 48 heures :
concrètement, après un changement, une partie de vos visiteurs continuerait d’arriver sur l’ANCIEN
serveur pendant un à deux jours. C’est ça, la vraie cause des migrations « où le site a sauté
un jour ou deux » — pas une coupure, un partage incontrôlé du trafic entre deux serveurs.
Notre réglage : une semaine avant la bascule, on descend le TTL de l’enregistrement A à 300 secondes (5 minutes). Il faut le faire EN AVANCE : tant que l’ancien TTL de 24-48 h n’a pas expiré chez les résolveurs, votre nouveau TTL n’est pas pris en compte. Le jour J, la propagation réelle se joue alors en minutes. Après stabilisation, on remonte le TTL à une valeur normale (3600-14400 s).
Réglage n°2 : le fichier hosts — tester le nouveau serveur en aveugle
Comment vérifier que le site fonctionne sur le nouveau serveur avant de basculer le
DNS ? En mentant à votre propre ordinateur. Le fichier hosts
(Windows/System32/drivers/etc/hosts sous Windows, /etc/hosts sous
macOS/Linux) permet d’associer votre domaine à l’IP du nouveau serveur uniquement sur votre
machine :
- Vous ajoutez une ligne
IP.DU.NOUVEAU.SERVEUR votredomaine.fr— et votre navigateur affiche le site depuis le nouveau serveur, avec la vraie URL, pendant que le reste du monde voit toujours l’ancien. - On teste tout en conditions réelles : pages clés, formulaires (envoi d’e-mails compris), tunnel de commande, espace admin, certificat SSL — le certificat doit être émis et valide sur le nouveau serveur AVANT la bascule, sinon les premières minutes afficheront une alerte de sécurité.
- Une fois validé, on retire la ligne du fichier hosts. Ce test élimine 90 % des mauvaises surprises du jour J.
Le cas du site actif : geler ou resynchroniser
Entre la copie initiale et la bascule DNS, il peut s’écouler quelques jours. Si votre site est un
site vitrine, aucune importance. Mais si des données s’écrivent en continu — commandes WooCommerce,
commentaires, formulaires stockés en base — tout ce qui arrive sur l’ancien serveur après la copie
serait perdu. Deux stratégies :
| Type de site | Stratégie | En pratique |
|---|---|---|
| Vitrine / institutionnel | Copie simple | Aucune précaution particulière : le contenu ne bouge pas entre la copie et la bascule |
| Blog actif / formulaires en base | Resynchronisation finale | Nouvelle copie de la base juste avant la bascule DNS, pendant une fenêtre calme (tôt le matin) |
| E-commerce | Gel court + resync | Mode « commandes suspendues » de 15-30 minutes le temps de la resynchronisation finale + bascule — le seul « arrêt » de toute l’opération, et il est commercial, pas technique |
Le jour J, minute par minute
- →H-1 : resynchronisation finale de la base si nécessaire ; dernier contrôle du site via fichier hosts ; certificat SSL vérifié.
- →H0 : changement de l’enregistrement A (et AAAA le cas échéant) vers la nouvelle IP. Avec le TTL à 300 s, la propagation utile se fait en 5 à 15 minutes.
- →H+15 min : contrôle des logs du NOUVEAU serveur — le trafic doit y arriver ; test depuis un réseau différent (4G) ; envoi d’un formulaire de test.
- →H+24 h : vérification Search Console (pas d’explosion d’erreurs de couverture), temps de réponse, e-mails. L’ancien serveur ne reçoit plus que des miettes de trafic (résolveurs paresseux).
- →Semaines 2 à 4 : l’ancien hébergement reste ouvert en filet de sécurité, puis résiliation — jamais avant.
Un mot sur les e-mails, l’oubli classique : si vos boîtes sont chez l’ancien hébergeur, la
bascule des enregistrements MX suit sa propre logique (comptes recréés à l’identique, SPF/DKIM/DMARC
mis à jour, période de double relève). Ne résiliez jamais l’ancien compte tant que les boîtes n’ont
pas été intégralement rapatriées.
Enfin, si vous changez d’hébergeur ET de structure d’URLs en même temps (refonte), les enjeux SEO
se superposent : notre
checklist anti-perte de trafic
couvre ce scénario — et pour choisir la destination, voyez
mutualisé, VPS ou infogéré.
🚀 Vous voulez un basculement invisible, e-mails et SEO compris ? EVICO migre votre site WordPress sans coupure ni perte SEO, e-mails compris : découvrez notre service migration & hébergement — étude gratuite de votre hébergement actuel. Ou contactez-nous directement.
Sources : documentation DNS (fonctionnement du TTL et des résolveurs) ;
procédures hébergeurs (o2switch, OVH, Infomaniak, Hostinger) ; méthode et minutage :
protocole de migration EVICO appliqué en production.
