Migrer son site WordPress vers un nouvel hébergeur

Une migration se fait toujours dans le même ordre : on copie le site chez le nouvel hébergeur, on le teste entièrement sur une adresse temporaire, et seulement ensuite on redirige le nom de domaine. Inverser ces étapes est la cause de la quasi-totalité des migrations ratées. Et on ne résilie jamais l’ancien hébergement avant un mois.

Les bonnes raisons de changer

Avant de se lancer, autant vérifier que le problème vient bien de l’hébergement, parce qu’une migration ne règle que les problèmes d’hébergement.

Les motifs valables : un temps de réponse serveur constamment supérieur à une seconde, un support qui ne répond pas ou en anglais uniquement, une version de PHP bloquée sur une ancienne édition, l’absence de sauvegardes automatiques, ou un tarif de renouvellement qui a triplé après la première année.

En revanche, si votre site est lent à cause d’images non compressées ou de vingt extensions, changer d’hébergeur ne changera rien. Vous emporterez le problème avec vous. Mesurez d’abord le temps de réponse du serveur : en dessous de 500 millisecondes, l’hébergement n’est pas en cause.

Ce qu’il faut préparer avant de commencer

Une migration se prépare en une heure et s’exécute en deux. Sauter la préparation, c’est transformer deux heures en une journée.

Faites l’inventaire de ce qui vit chez l’ancien hébergeur : le site, bien sûr, mais aussi les adresses e-mail, les sous-domaines, les tâches planifiées et les certificats. Les e-mails sont le poste le plus souvent oublié, et le plus douloureux à récupérer après coup.

Notez ensuite vos identifiants de base de données actuels, la version de PHP utilisée, et la liste de vos extensions. Et vérifiez où est géré votre nom de domaine : chez l’hébergeur ou chez un registrar séparé. Cela change la manœuvre finale.

Étape 1 : sauvegarder pour de vrai

Une sauvegarde complète, fichiers et base de données, téléchargée sur votre propre ordinateur. Pas seulement chez l’hébergeur que vous êtes en train de quitter.

Vérifiez que l’archive est exploitable avant de continuer : ouvrez-la, comptez les dossiers, regardez que le dossier des médias contient bien vos images. Une archive vide ou tronquée se découvre toujours au pire moment.

C’est votre point de retour. Tant que vous l’avez, aucune erreur de migration n’est définitive.

Étape 2 : copier chez le nouvel hébergeur

Créez l’hébergement, une base de données vide, puis transférez les fichiers et importez la base.

Reportez les nouveaux identifiants de base dans le fichier de configuration : nom de la base, utilisateur, mot de passe, et surtout l’adresse du serveur de base de données. Cette dernière valeur est celle qu’on oublie : beaucoup d’hébergeurs n’utilisent pas la valeur locale par défaut mais une adresse propre.

Vérifiez aussi la version de PHP proposée par le nouvel hébergeur. Si elle est plus récente que l’ancienne, une extension ancienne peut cesser de fonctionner. C’est mieux de le découvrir maintenant que dans une heure.

Étape 3 : tester sans toucher au domaine

C’est l’étape qui distingue une migration propre d’une migration à l’aveugle, et elle est souvent sautée.

La plupart des hébergeurs fournissent une adresse temporaire. Sinon, modifiez le fichier hosts de votre ordinateur pour ne faire pointer le domaine vers le nouveau serveur que pour vous, sans rien changer pour les visiteurs.

Testez alors sérieusement : la page d’accueil, une page de prestation, un article, la connexion à l’administration, l’envoi du formulaire de contact, l’affichage des images, la version mobile. Sur une boutique, passez une commande de test complète avec paiement.

Ne passez à l’étape suivante que quand tout fonctionne. Tant que le domaine n’a pas bougé, vos visiteurs ne voient rien et vous avez tout le temps.

Étape 4 : basculer le domaine

Modifiez les serveurs de noms, ou l’enregistrement A selon votre configuration. C’est une opération de deux minutes.

Choisissez un moment creux pour votre activité, jamais un vendredi soir ni la veille d’un jour férié. Vous voulez être disponible dans les heures qui suivent.

Générez ensuite le certificat de sécurité sur le nouvel hébergement, sans quoi les visiteurs verront un avertissement. La plupart des hébergeurs le font automatiquement, mais vérifiez plutôt que de supposer.

Les 48 heures de propagation

Pendant un à deux jours, certains visiteurs arrivent encore sur l’ancien serveur et d’autres sur le nouveau. C’est normal, ce n’est pas une panne, et il ne faut surtout rien modifier.

La conséquence pratique est importante sur une boutique ou un site avec formulaire : une commande passée pendant cette période peut atterrir dans l’ancienne base. Sur une boutique, mieux vaut prévoir une courte fenêtre de maintenance que de perdre des commandes.

Gardez les deux hébergements actifs pendant toute la propagation, et ne modifiez pas de contenu tant qu’elle n’est pas terminée : vous ne sauriez pas où votre modification a été enregistrée.

Le cas des adresses e-mail

C’est le poste qui provoque le plus de dégâts, parce qu’on y pense en dernier.

Si vos e-mails sont hébergés chez l’ancien hébergeur, ils basculent avec le domaine. Sans préparation, vous perdez les messages reçus pendant la transition, et parfois l’historique complet.

Avant de basculer, sauvegardez chaque boîte en local. Recréez les adresses chez le nouvel hébergeur avant le changement de serveurs de noms, pour qu’elles existent au moment où le courrier arrive. Et prévenez vos correspondants principaux qu’un message pourrait se perdre ce jour-là.

Une alternative plus sûre : dissocier la messagerie de l’hébergement web. Vos e-mails ne dépendent alors plus de vos changements de serveur.

Après la migration

Quelques vérifications valent la peine, et elles prennent dix minutes.

Contrôlez que le site s’affiche bien en HTTPS et que les anciennes adresses en HTTP redirigent. Regardez la Search Console pendant une semaine : les erreurs d’exploration révèlent ce qui n’a pas suivi. Refaites une sauvegarde depuis le nouvel hébergement, pour valider que le système fonctionne. Et mesurez le temps de réponse, pour vérifier que le changement a servi à quelque chose.

Enfin, la règle qu’il ne faut pas négliger : ne résiliez pas l’ancien hébergement avant un mois. Quinze euros pour garder une porte de sortie, c’est la meilleure assurance du projet.

Migrer un site en production sans coupure

Sur un site vitrine, une interruption de quelques minutes n’a aucune conséquence. Sur une boutique ou un site de réservation, c’est différent, et il existe une méthode plus prudente.

Réduisez d’abord la durée de vie des enregistrements DNS à 300 secondes, au moins 24 heures avant l’opération. La propagation passe alors de deux jours à quelques minutes.

Le jour venu, mettez le site en mode maintenance chez l’ancien hébergeur, faites une dernière synchronisation de la base pour récupérer les toutes dernières commandes, puis basculez. Vous perdez dix minutes de disponibilité au lieu de deux jours d’incertitude.

Remettez la durée de vie DNS à sa valeur normale une semaine plus tard.

Faut-il déléguer ?

Un site vitrine simple se migre soi-même en une matinée, en suivant cet ordre. Ce n’est pas de la magie, c’est de la méthode.

Déléguez en revanche dans trois cas : une boutique en ligne, parce qu’une commande perdue coûte plus cher que la prestation ; des adresses e-mail professionnelles avec un historique important ; ou un site dont vous n’avez pas tous les accès.

Une migration confiée s’accompagne aussi d’un audit au passage, ce qui est souvent l’occasion de régler les vraies causes de lenteur. C’est inclus dans le suivi que je propose sur la page maintenance.