À un moment ou à un autre, presque toute entreprise en croissance dépasse son premier hébergeur, ou souhaite simplement plus de rapidité, un meilleur support ou un meilleur prix. On craint souvent qu’une migration entraîne une interruption du site, des problèmes de messagerie et une perte de données. Avec une préparation soignée, on peut limiter l’interruption au minimum. Ce guide explique ce que comprend réellement une migration et comment la planifier pour que votre site soit hors service le moins longtemps possible.
Ce que déplace réellement une migration de site
Une migration complète ne se résume pas à copier des fichiers. Il y a quatre composants distincts, à traiter dans le bon ordre :
- Les fichiers du site : tous les fichiers du thème, les extensions, les images téléversées et tout code personnalisé. Pour un site WordPress, ces fichiers se trouvent principalement dans le dossier
wp-content. - La base de données : un site WordPress conserve ses pages, articles, réglages et comptes utilisateurs dans une base MySQL, pas dans les fichiers. Migrer sans la base de données vous donne une coquille vide. L’endroit où des extensions comme les formulaires ou les boutiques stockent leurs propres données dépend de l’extension et de sa configuration : vérifiez-le séparément.
- Les comptes e-mail : si votre messagerie fonctionne sur le même compte d’hébergement (par exemple [email protected]), il faut migrer les boîtes, les dossiers et les contacts, ou faire pointer le service de messagerie vers un nouveau serveur. C’est l’élément qui dysfonctionne le plus souvent lors d’une migration précipitée.
- Le certificat SSL : le cadenas HTTPS doit être actif sur le nouvel hébergeur avant de basculer le DNS. Les visiteurs qui arrivent sans connexion sécurisée voient des avertissements du navigateur et partent aussitôt.
La bascule DNS : là où l’interruption se produit généralement
Lorsque vous changez d’hébergeur, vous mettez à jour les enregistrements DNS de votre domaine pour qu’ils pointent vers l’adresse IP du nouveau serveur. Les changements DNS n’atteignent pas tout le monde en même temps : chaque enregistrement a un TTL (Time to Live) qui indique aux résolveurs combien de temps ils peuvent le conserver en cache, et certains le gardent plus longtemps que d’autres. Pendant cette période, certains visiteurs arrivent sur l’ancien serveur et d’autres sur le nouveau.
Une approche courante consiste à abaisser le TTL (par exemple à 300 secondes) au moins 24 heures avant la bascule prévue. Cela raccourcit la durée pendant laquelle les enregistrements en cache restent utilisés, mais ne garantit pas que tout le trafic bascule en quelques minutes. Une fois le TTL abaissé pris en compte, vous effectuez le changement DNS. L’ancien serveur reste en ligne, intact, jusqu’à ce que vous soyez certain que tout fonctionne : il sert de filet de sécurité. Ce n’est qu’ensuite que vous le désactivez. Pour comprendre le fonctionnement du TTL, voir la référence TTL de Cloudflare.
Commandes, formulaires et autres écritures pendant la bascule
Tant que les deux serveurs sont joignables, un site qui reçoit des commandes, des formulaires ou des commentaires peut les recevoir à la fois sur l’ancien et sur le nouveau serveur, et les deux copies divergent alors. Convenez d’une méthode adaptée à votre site avant la migration : un bref gel du contenu, une synchronisation finale de la base de données après la bascule, ou une autre approche selon le fonctionnement du site. Un retour arrière après l’arrivée de nouvelles commandes nécessite aussi un plan pour ces données. Voir les recommandations AWS sur la phase de bascule pour l’approche générale.
Liste de contrôle avant le lancement
Avant de modifier le moindre enregistrement DNS, vérifiez chaque point de cette liste :
- Sauvegarde complète des fichiers et de la base de données de l’ancien hébergeur, conservée hors serveur (pas uniquement chez le nouvel hébergeur).
- Fichiers et base de données importés et vérifiés sur le nouvel hébergeur à l’aide d’une URL temporaire de préproduction ou d’une modification locale du fichier hosts qui associe le domaine à l’adresse du nouveau serveur.
- Tous les liens internes et URL de médias fonctionnent sur le nouvel hébergeur, surtout si vous changez aussi de domaine.
- Certificat SSL émis et actif sur le nouvel hébergeur pour votre domaine.
- Formulaires de contact, passerelles de paiement et intégrations tierces testés et fonctionnels.
- Comptes e-mail créés sur le nouveau serveur de messagerie et paramètres IMAP/SMTP documentés.
- TTL déjà abaissé sur votre DNS actuel depuis au moins 24 heures.
- Un plan pour les commandes et formulaires qui arrivent pendant la bascule.
- Alerte de supervision configurée pour être prévenu immédiatement si le site renvoie une erreur après la bascule.
Ce qu’il faut demander à tout prestataire de migration
Toutes les offres de « migration gratuite » ne se valent pas. Avant de communiquer vos accès, posez ces questions :
- Migrez-vous la base de données ou seulement les fichiers ? Si seuls les fichiers sont migrés, votre site ne fonctionnera pas correctement.
- Prenez-vous en charge la migration des e-mails, ou est-ce une prestation à part ? Beaucoup de prestataires migrent le site mais laissent la messagerie de côté, souvent sans le dire d’emblée.
- Quelle est votre procédure de retour arrière en cas de problème ? Un prestataire sérieux dispose d’un plan documenté, pas d’un vague « nous réglerons ça ».
- Comment limitez-vous l’interruption ? Un prestataire doit pouvoir expliquer le plan de bascule de votre site, y compris la gestion des nouvelles commandes et des formulaires. Une vague promesse de « zéro interruption » est un signal d’alerte.
- Qui contacter pendant la fenêtre de bascule ? La bascule DNS est le moment le plus risqué. Il vous faut un interlocuteur désigné et joignable, plutôt qu’une simple file d’attente de demandes d’assistance.
Après la bascule
Une fois le DNS propagé et le nouveau serveur en service, passez environ 30 minutes à parcourir votre site comme un vrai utilisateur : testez le paiement si vous avez une boutique, envoyez un formulaire de contact, vérifiez que les e-mails arrivent et contrôlez le cadenas SSL sur chaque page importante. Conservez l’ancien hébergement pendant au moins 7 jours afin de disposer d’une solution de repli fiable si un problème imprévu survient durant la première semaine.
Si vous préférez déléguer, le service de migration de WebHostLB examine les dépendances de votre site, de votre domaine et de votre messagerie, et convient avec vous du périmètre et de la méthode de bascule avant la migration.