Changer d’hébergeur inquiète toujours pour la même raison : le site va-t-il tomber, et surtout, va-t-on perdre des e-mails ? Les deux risques existent, mais ils sont entièrement évitables. Ils viennent presque toujours d’un ordre d’opérations, pas d’une difficulté technique.
Ce qui peut réellement mal tourner
- Le site indisponible quelques heures, pendant que l’adresse bascule.
- Des e-mails perdus, envoyés vers un serveur qui ne les attend pas.
- Une alerte de sécurité dans le navigateur, faute de certificat sur le nouveau serveur.
- Des contenus disparus : tout ce qui a été publié entre la copie et la bascule.
- Le site sorti de Google, quand le blocage d’indexation posé sur la copie de test n’est pas retiré.
Les deux derniers sont les plus fréquents, et les plus silencieux : rien ne les signale.
Les e-mails : le vrai risque
Voici le point que presque personne ne connaît, et qui explique la majorité des messages perdus.
Votre nom de domaine ne pointe pas vers un service, mais vers plusieurs. Une entrée indique où se trouve le site, une autre — appelée MX — indique où se trouve la messagerie. Ce sont deux réglages indépendants.
Le problème survient quand on transfère toute la configuration du domaine vers le nouvel hébergeur : celui-ci crée une configuration neuve, avec ses propres entrées par défaut. L’entrée du site est correcte, mais l’entrée de messagerie pointe désormais vers un serveur qui n’a aucune boîte à votre nom.
Les messages ne rebondissent pas toujours. Ils sont parfois acceptés puis jetés. L’expéditeur ne reçoit aucune erreur, vous ne recevez rien, et personne ne s’en aperçoit avant plusieurs jours.
La règle : notez tous les enregistrements existants avant de toucher à quoi que ce soit, et recréez-les à l’identique. Les entrées MX en particulier ne doivent pas bouger si votre messagerie reste où elle est.
Pourquoi ça ne bascule pas instantanément
Quand vous changez l’adresse d’un domaine, l’information ne se propage pas partout au même instant. Les fournisseurs d’accès conservent l’ancienne valeur pendant une durée définie à l’avance, souvent plusieurs heures.
Concrètement, pendant cette fenêtre, une partie de vos visiteurs arrive sur l’ancien serveur et une autre sur le nouveau. C’est normal, et c’est précisément pour ça qu’il ne faut jamais couper l’ancien hébergement le jour de la bascule.
On peut réduire cette fenêtre : en abaissant la durée de conservation 24 heures avant l’opération, la bascule devient quasi immédiate.
L’ordre qui évite la coupure
Une migration propre se fait dans cet ordre, sans exception :
- Copier le site sur le nouveau serveur et le rendre accessible via une adresse temporaire.
- Tout tester : pages, formulaires, connexion à l’administration, tunnel de commande, paiement.
- Relever la configuration du domaine, ligne par ligne, en particulier les entrées de messagerie.
- Abaisser la durée de conservation 24 heures avant.
- Geler les publications le jour J, et pour une boutique, choisir un créneau creux.
- Resynchroniser la base de données juste avant la bascule, pour ne perdre aucune commande ni aucun message.
- Basculer l’entrée du site uniquement, sans toucher à la messagerie.
- Émettre le certificat sur le nouveau serveur.
- Laisser l’ancien hébergement en ligne 48 heures, puis vérifier avant de résilier.
La sixième étape est celle qu’on saute le plus souvent, et c’est celle qui fait perdre les commandes passées pendant la migration.
Ce qu’il faut avoir sous la main
- Les accès au registrar du domaine — pas seulement à l’hébergement. Ce sont deux comptes différents, et c’est le registrar qui commande.
- La liste des boîtes e-mail existantes et leur volume.
- Une sauvegarde complète conservée de votre côté.
Si vous ne savez pas où est votre domaine ni qui en est titulaire, réglez cette question avant la migration, pas pendant.
Les erreurs classiques
- Résilier l’ancien hébergement trop tôt. Attendez d’avoir vérifié pendant plusieurs jours.
- Migrer un vendredi, ou la veille d’une opération commerciale.
- Oublier de retirer le blocage d’indexation posé sur la copie de test. Le site fonctionne parfaitement et disparaît de Google en quelques semaines, sans le moindre signe. Les symptômes sont décrits dans Pourquoi votre site n’apparaît que sur son propre nom.
- Ne pas retester les formulaires après. L’envoi d’e-mails dépend du serveur : ce qui marchait avant ne marche pas forcément après.
Ce qu’il faut retenir
Une migration ne coupe pas un site quand elle est faite dans le bon ordre : copier, tester, relever la configuration, basculer, garder l’ancien serveur allumé. Le risque ne vient pas de la technique, il vient de la précipitation.
Et si vous en profitez pour reconstruire plutôt que déplacer, la question préalable reste la même : Quand faut-il refondre plutôt que réparer.
Une migration s’accompagne souvent d’un ménage dans les extensions accumulées — le raisonnement est détaillé dans Extension ou développement sur mesure : comment choisir.
Nous prenons en charge ces migrations, configuration de messagerie comprise, dans le cadre d’une refonte de site WordPress. Et si vous préférez n’avoir qu’un seul interlocuteur pour l’hébergement comme pour l’entretien, la migration est incluse dans le forfait Tout compris de nos offres de maintenance WordPress.
