Migrer WordPress vers un VPS sans perdre ses e-mails
Comment déplacer un site WordPress d’un hébergement mutualisé vers un VPS sans perdre ses e-mails ni son DNS
Passer WordPress d’un hébergement mutualisé à un serveur privé virtuel (VPS) peut vous donner davantage de contrôle sur PHP, les ressources du serveur et sa configuration. Mais cette opération peut aussi perturber les e-mails ou rediriger les visiteurs vers le mauvais endroit si vous la considérez comme une simple copie de fichiers. L’essentiel est de dissocier le site web des services qui dépendent déjà de votre nom de domaine.
Si vous cherchez comment migrer un site WordPress d’un hébergement mutualisé vers un VPS, commencez par dresser la liste des services réellement fournis par votre hébergeur actuel. Le domaine peut être enregistré auprès d’une société, son DNS géré par une autre, les e-mails fournis par une troisième et le site WordPress hébergé par une quatrième. Ces services n’ont pas besoin d’être transférés ensemble.
1. Définir le périmètre de la migration : distinguer le site web des services qui restent en place
Notez où se trouvent les fichiers WordPress et la base de données, puis identifiez le fournisseur responsable de chaque service associé. Vérifiez le bureau d’enregistrement du domaine, l’hébergeur DNS, le fournisseur de messagerie et les éventuels services distincts, comme un CDN ou un stockage d’images. Votre panneau de contrôle d’hébergement affiche peut-être certaines de ces informations, mais les serveurs de noms et les enregistrements DNS du domaine indiquent où le trafic est réellement dirigé.
Par exemple, un site peut être hébergé sur un serveur mutualisé, tandis que son DNS est géré par Cloudflare et que les e-mails de son équipe passent par Google Workspace. Dans ce cas, migrer WordPress vers un VPS n’oblige pas à transférer le domaine ni les comptes e-mail. Il s’agit généralement de modifier les enregistrements qui dirigent le trafic web, tout en laissant les enregistrements de messagerie intacts.
Avant toute modification, faites un inventaire simple. Notez la destination web actuelle, les serveurs de noms et les éventuels enregistrements liés à la messagerie. Si vous ne savez pas si un enregistrement concerne les e-mails, demandez à votre fournisseur de messagerie ou consultez ses instructions de configuration au lieu de le supprimer. L’absence d’un enregistrement de messagerie peut empêcher la réception de messages, même si le site web semble fonctionner normalement.
2. Repérer les dépendances qu’une simple copie du site peut laisser de côté
Une sauvegarde WordPress peut inclure les fichiers du site et la base de données sans pour autant contenir tous les services dont le site dépend. Vérifiez les tâches planifiées, la configuration des e-mails sortants, le stockage externe, les redirections, la configuration SSL et les paramètres propres au serveur. Par exemple, un site avec espace membre peut dépendre d’une tâche planifiée pour désactiver les comptes arrivés à expiration, tandis qu’une boutique peut envoyer ses notifications de commande via un service SMTP externe.
Consultez le panneau de contrôle de l’hébergement et les extensions WordPress pour repérer les tâches planifiées. Le système de tâches intégré à WordPress peut s’exécuter lorsqu’un visiteur charge une page ; une tâche cron du serveur peut, quant à elle, appeler un script précis selon un calendrier défini. Notez la commande, la fréquence et le fuseau horaire de chaque tâche. Si le VPS ne comporte pas de tâche cron équivalente, une opération exécutée toutes les heures sur l’ancien hébergement risque de s’arrêter après la migration.
Vérifiez comment le site envoie ses e-mails. Notez s’il utilise le serveur de messagerie de l’hébergeur, une extension SMTP ou un service d’e-mails transactionnels, et confirmez l’adresse d’expéditeur utilisée par le site. Si l’ancien hébergeur fournissait le serveur de messagerie, les mêmes paramètres ne fonctionneront peut-être pas depuis le VPS. Demandez au fournisseur de messagerie s’il restreint les connexions ou impose une méthode d’authentification particulière.
Faites aussi la liste du stockage externe et des paramètres du serveur. Une extension de gestion des médias peut stocker les fichiers dans un espace de stockage objet plutôt que dans le dossier uploads de WordPress. Le site peut dépendre d’une version particulière de PHP, de certaines extensions PHP, de règles de réécriture ou d’un paramètre dans .htaccess. Conservez ces informations : devoir les deviner après la mise en ligne peut transformer un petit problème de compatibilité en une longue interruption de service.
3. Configurer le VPS en fonction des besoins réels du site
Choisissez une configuration VPS adaptée aux besoins observés du site, puis décidez de la manière dont il traitera les requêtes web. Parmi les choix courants, on trouve Apache et Nginx, mais la configuration appropriée dépend du site et de la capacité de l’administrateur à la maintenir. Avant d’installer l’environnement de production, vérifiez que la version de PHP et les extensions nécessaires sont compatibles avec le code, les extensions et le thème du site.
Configurez la base de données, le serveur web et le gestionnaire PHP, puis définissez les propriétaires et les permissions des fichiers pour que WordPress puisse les lire et n’écrire que là où c’est nécessaire. Évitez de rendre tous les fichiers modifiables simplement pour faire disparaître une erreur. Restreignez l’accès administrateur, activez un pare-feu et prévoyez des sauvegardes incluant la base de données et les fichiers du site.
Testez le VPS avant d’y transférer le site en production. Vérifiez que le serveur web peut afficher une page simple, que PHP fonctionne correctement et que la base de données accepte une connexion de test. Notez les versions installées et les fichiers de configuration. Ces informations vous serviront de référence si une extension se comporte différemment sur le nouveau serveur.
4. Transférer les fichiers et la base de données sans modifier le site en ligne
Créez une copie complète des fichiers WordPress et de la base de données, et laissez le site d’origine accessible aux visiteurs pendant vos opérations. Une extension de migration peut regrouper le site dans une archive, tandis que des outils en ligne de commande ou une sauvegarde fournie par l’hébergeur peuvent offrir davantage de contrôle. Quelle que soit la méthode choisie, vérifiez que la sauvegarde contient la base de données, les fichiers téléversés, les thèmes, les extensions et tous les fichiers de configuration personnalisés.
Si le site est régulièrement mis à jour, prévoyez comment gérer les nouvelles commandes, les commentaires ou les articles publiés après la première copie. Vous pouvez, par exemple, effectuer une première copie, la tester en privé, puis transférer à nouveau la base de données pendant une courte période de maintenance. Pour une boutique, cette méthode permet de déplacer un site WordPress sans perdre ses e-mails ni de nouvelles commandes : évitez d’accepter des commandes sur les deux copies, car des données de commande en double ou manquantes sont plus difficiles à corriger qu’une brève interruption annoncée.
Transférez les fichiers et la base de données vers le VPS, puis mettez à jour la configuration WordPress avec le nouveau nom de base de données, l’utilisateur, le mot de passe et l’hôte, si nécessaire. Conservez les anciennes et les nouvelles valeurs dans un endroit sécurisé. Si le domaine ou les chemins d’accès aux fichiers changent, mettez à jour les paramètres du site avec précaution ; une recherche-remplacement globale peut endommager les données sérialisées de la base de données si elle ne les traite pas correctement.
Ne dirigez pas encore le DNS public vers le VPS. L’ancien hébergement doit rester la destination publique pendant que vous vérifiez la copie privée, et le nouveau serveur ne doit pas recevoir d’activité réelle de clients avant que vous soyez prêt à basculer.
5. Tester le site en privé avant de modifier le DNS public
Utilisez une modification du fichier hosts sur votre ordinateur ou un nom d’hôte de préproduction temporaire pour diriger votre navigateur vers le VPS sans modifier le DNS public. Une modification du fichier hosts ne concerne que l’appareil sur lequel vous l’ajoutez ; elle est donc pratique pour vérifier le nouveau site avant qu’il soit visible par les autres visiteurs. Une fois les tests terminés, supprimez l’entrée afin de ne pas confondre l’accès privé avec l’accès public.
Testez à la fois le site public et le tableau de bord WordPress. Vérifiez la page de connexion, un échantillon représentatif des pages importantes, la recherche, les formulaires, les téléversements, les redirections ainsi que le processus de paiement ou les fonctionnalités réservées aux membres, le cas échéant. Envoyez un formulaire de test et vérifiez où le message arrive. Si le site envoie des e-mails, contrôlez leur distribution et leur éventuel classement dans les courriers indésirables : le fait qu’un formulaire affiche un message de confirmation ne prouve pas que l’e-mail a été envoyé.
Vérifiez les tâches planifiées et les intégrations qui contactent le site depuis l’extérieur. Un service de paiement, par exemple, peut envoyer une notification à une URL précise, tandis qu’un service de surveillance peut attendre une réponse particulière. Vérifiez également que HTTPS fonctionne sur le VPS. Un nom d’hôte de préproduction peut ne pas correspondre au certificat de production : testez donc la configuration prévue pour le certificat définitif avant de rediriger les visiteurs vers le nouveau serveur.
Vérifiez les redirections et les URL canoniques du domaine de production. Si le taux de rebond de votre site est élevé, une page d’arrivée ou une redirection défectueuse peut aggraver le problème ; ce guide explique quel est le bon taux de rebond pour un site web et comment interpréter cette mesure. Lors des tests de migration, concentrez-vous sur des problèmes précis, comme un formulaire qui renvoie une erreur ou un fichier téléversé qui n’apparaît pas.
6. Basculer le DNS en prévoyant la messagerie et un retour arrière
Avant de modifier le DNS, enregistrez les paramètres actuels et notez précisément les enregistrements web que vous comptez mettre à jour. Pour configurer le DNS après une migration WordPress, identifiez si le site utilise un enregistrement A ou un CNAME, puis modifiez uniquement l’enregistrement web nécessaire pour pointer vers le VPS. Conservez les enregistrements de messagerie, notamment les enregistrements MX et les enregistrements TXT utilisés pour l’authentification des e-mails, sauf si vous changez volontairement de fournisseur de messagerie.
Réduire à l’avance la durée de vie (TTL) des enregistrements DNS peut aider certains résolveurs à prendre en compte plus rapidement la nouvelle destination, mais cela ne garantit pas une propagation immédiate partout dans le monde. Vérifiez la configuration DNS actuelle et les recommandations de votre fournisseur avant de modifier les enregistrements. Si vous utilisez un proxy ou un CDN, vérifiez si l’adresse d’origine doit pointer directement vers le VPS et si le mode SSL du proxy est compatible avec le certificat installé sur le serveur.
Choisissez une plage horaire où vous pourrez surveiller le site et intervenir en cas de problème. Modifiez les enregistrements web prévus, puis vérifiez le domaine depuis plusieurs réseaux ou à l’aide de services de recherche DNS. Préparez une procédure écrite de retour arrière : rétablissez l’ancienne destination web, indiquez qui peut effectuer la modification et gardez accès à l’ancien compte d’hébergement. Ne supprimez pas l’ancien site tant que les caches DNS peuvent encore y diriger des visiteurs.
Lors de la bascule, vérifiez séparément la messagerie. Envoyez un message depuis un compte externe à une adresse du domaine, puis répondez depuis cette adresse si possible. Si les e-mails ne passent plus, comparez les enregistrements DNS actuels avec la copie sauvegardée avant de faire d’autres changements. La migration du serveur web ne devrait pas nécessiter la suppression des enregistrements de messagerie.
7. Vérifier la nouvelle configuration après la mise en ligne
Une fois le trafic public dirigé vers le VPS, vérifiez HTTPS, les pages importantes, les formulaires, la connexion et tous les processus liés aux revenus. Consultez les journaux WordPress et ceux du serveur pour repérer les erreurs PHP, les accès aux fichiers refusés, les échecs de connexion à la base de données ou les requêtes répétées vers des URL inexistantes. La page d’accueil peut sembler fonctionner normalement alors qu’une erreur d’extension empêche discrètement le formulaire de contact de fonctionner.
Vérifiez que les sauvegardes s’exécutent sur le VPS et que vous savez comment en restaurer une. Contrôlez leur emplacement et vérifiez qu’une sauvegarde récente contient à la fois la base de données et les fichiers. Configurez une surveillance de la disponibilité et de l’expiration du certificat, puis confirmez que les e-mails circulent dans les deux sens. Effectuez ces vérifications avant de résilier l’ancien hébergement.
Gardez l’ancien hébergement actif jusqu’à ce que le nouveau site ait passé les vérifications prévues et que les changements DNS concernés aient été pris en compte. Conservez une dernière copie des anciens fichiers et de la base de données, conformément à votre politique de conservation. Une fois que le VPS héberge le site, que la messagerie fonctionne et que les étapes de restauration sont documentées, vous pourrez décider quand fermer l’ancien compte sans avoir à deviner quels services en dépendent encore.
