Migrer son hébergement sans interruption de service
Comment changer d'hébergeur sans perdre le site, les e-mails ou le référencement : DNS, TTL et vérifications, étape par étape.
Équipe rabbitclipPublié: 6 min de lecture
En bref
Une migration sans interruption se produit quand le nouveau serveur est entièrement configuré et testé avant que les enregistrements DNS ne soient basculés ; le site n'est jamais laissé à moitié prêt entre deux serveurs. Cela suppose d'abaisser la durée de vie, TTL, des enregistrements DNS quelques jours avant le changement ; sinon, le basculement vers le nouveau serveur peut prendre des heures, parfois une journée entière, pour atteindre tout le monde.
Le site d'une société de gestion d'immeubles cesse de recevoir des e-mails le jour de la migration et perd des demandes clients pendant des semaines ; la cause est rarement le nouveau serveur lui-même, elle vient le plus souvent du fait que les enregistrements MX n'ont pas été changés en même temps que le reste du DNS. Une migration menée dans le bon ordre écarte ce risque dès le départ.
Qu'est-ce qui est réellement en jeu lors d'une migration d'hébergement ?
Une migration d'hébergement consiste à déplacer les fichiers, la base de données et le service e-mail d'un site d'un serveur à un autre. Le risque se concentre sur trois points : le site inaccessible pendant le transfert, les e-mails retardés ou perdus, et un changement DNS qui envoie un mauvais signal aux moteurs de recherche.
Le point commun entre ces trois risques est le calendrier ; une migration menée dans le bon ordre avec le bon réglage de TTL les écarte largement tous les trois. Lors d'une migration précipitée, ces trois risques se manifestent en général en même temps, car la cause reste toujours la même : une étape sautée dans l'ordre.
Liste de vérification avant la migration
Les étapes suivantes doivent être terminées au moins une semaine avant le jour de la migration.
- Le site est entièrement configuré et testé sur le nouveau serveur, vérifié via une adresse temporaire, l'IP propre du serveur ou un sous-domaine de test
- Une sauvegarde à jour de la base de données et des fichiers est réalisée et conservée sur l'ancien comme sur le nouveau serveur
- Une liste complète des enregistrements DNS, A, MX, CNAME, TXT, est établie et reproduite à l'identique sur le nouveau serveur
- Le TTL des enregistrements DNS actuels est abaissé au moins 48 heures avant la migration
Pourquoi abaisser le TTL plusieurs jours avant la migration ?
Le TTL détermine combien de temps un enregistrement DNS reste en cache chez les navigateurs et les serveurs. D'après la documentation DNS de Cloudflare, un changement effectué avec un TTL élevé peut mettre des heures à atteindre tous les visiteurs ; c'est pourquoi il est judicieux d'abaisser le TTL à l'avance dès qu'un changement est prévu.
Si le TTL passe d'une heure à quelques minutes plusieurs jours avant la migration, le changement DNS réel du jour de la migration se propage bien plus vite ; certains visiteurs peuvent encore atterrir sur l'ancien serveur pendant quelques minutes, mais cette fenêtre reste de l'ordre des minutes plutôt que des heures.
Dans quel ordre se déroule le jour de la migration ?
Une fois le nouveau serveur testé et prêt, le jour de la migration se déroule dans cet ordre : les enregistrements DNS sont d'abord mis à jour, puis l'ancien serveur reste actif encore un moment, généralement une semaine, continuant à répondre à toute requête jusqu'à expiration complète de l'ancien TTL.
Les deux serveurs sont surveillés pendant cette période d'attente ; on observe le trafic basculer vers le nouveau, on compare les taux d'erreur et les temps de réponse. En cas de problème, l'enregistrement DNS peut être repointé vers l'ancien serveur, ce qui est précisément pourquoi il ne doit pas être éteint immédiatement.
Comment éviter une coupure d'e-mail ?
L'e-mail dépend du serveur vers lequel pointent les enregistrements MX ; si ces enregistrements sont oubliés pendant la mise à jour du DNS du site, ou changés à un autre moment, le courrier entrant peut se répartir un moment entre l'ancien et le nouveau serveur, voire se perdre complètement.
L'approche la plus sûre consiste à faire fonctionner l'e-mail comme un service séparé du site ; quand c'est possible, l'e-mail repose sur un service indépendant et n'est pas affecté par la migration du site. S'il reste sur le même serveur, les enregistrements MX doivent être mis à jour et testés en même temps que ceux du site, pas après.
Comment confirmer que la migration est vraiment terminée ?
Un outil de recherche DNS qui vérifie depuis plusieurs régions montre vers quelle adresse IP le domaine résout actuellement dans chacune, et jusqu'où la propagation est réellement allée. L'ancien serveur doit rester actif jusqu'à ce que toutes les régions renvoient la nouvelle adresse ; cette vérification prend quelques minutes.
La même vérification fonctionne pour l'e-mail ; une fois confirmé que l'enregistrement MX pointe vers le nouveau serveur, un e-mail de test doit être envoyé et son arrivée effective confirmée. Ces deux vérifications simples transforment une migration en quelque chose de confirmé par des preuves plutôt que présumé terminé.
Vérifications post-migration et erreurs fréquentes
Quelques vérifications après la migration permettent de repérer un problème tôt : le certificat SSL est valide sur le nouveau serveur, les formulaires et le paiement fonctionnent réellement, et il n'y a pas de pic soudain d'erreurs dans la search console.
- Ne pas abaisser le TTL avant la migration, laissant la propagation prendre des heures
- Éteindre l'ancien serveur immédiatement le jour de la migration, supprimant toute possibilité de retour en arrière
- Mettre à jour les enregistrements MX à un moment différent des enregistrements DNS du site, provoquant une perte d'e-mails
- Ne pas installer le certificat SSL sur le nouveau serveur avant la migration, déclenchant un avertissement de connexion non sécurisée au moment du basculement
Une migration d'hébergement, menée dans le bon ordre, est un processus invisible pour le visiteur. Abaisser le TTL tôt, déplacer les enregistrements MX en même temps que le DNS du site, et ne pas éteindre l'ancien serveur immédiatement sont les trois règles d'une migration propre. Un premier échange avec rabbitclip permet de passer en revue votre propre plan de migration d'hébergement.
Questions fréquentes
Une migration d'hébergement affecte-t-elle le référencement ?
Pas directement si les adresses restent identiques. Une migration qui change aussi les URL nécessite des redirections correctement mises en place ; c'est un sujet à part.
Combien de temps dure une migration ?
La préparation peut prendre plusieurs jours, mais l'interruption réelle, avec un TTL correctement réglé, reste de l'ordre de quelques minutes.
Quand faut-il éteindre l'ancien serveur ?
Après plusieurs fois la durée du TTL, généralement environ une semaine, pendant que le nouveau serveur est surveillé.
Un service e-mail séparé est-il obligatoire ?
Pas obligatoire, mais il réduit fortement le risque que l'e-mail dépende de la migration du site.
Comment confirmer que la propagation est terminée ?
Un outil de recherche DNS vérifie si le domaine résout vers l'adresse du nouveau serveur depuis plusieurs régions ; l'ancien serveur reste actif jusqu'à ce que toutes les régions donnent le même résultat.
