Un site WordPress et des boîtes e-mail peuvent partager le même domaine sans partager le même serveur, les mêmes données ni le même moment de bascule. Une migration site et emails fiable utilise deux plans coordonnés : l’un pour le web, l’autre pour le courrier.
Changer l’enregistrement du site ne déplace pas les messages. Changer le MX ne copie pas les boîtes. Et changer les serveurs de noms peut toucher les deux à la fois ainsi que des services oubliés. La première protection est donc une cartographie complète.
Sommaire
La réponse courte
Inventoriez séparément WordPress, domaine, zone DNS, boîtes, alias, groupes, quotas, clients et authentification. Préparez les deux destinations et testez-les avant tout changement public. Copiez le site, effectuez une copie initiale des e-mails, puis une resynchronisation finale.
Basculez uniquement les enregistrements nécessaires, vérifiez réception interne/externe, envoi et authentification, et gardez les anciens services accessibles le temps prévu. N’exposez jamais dans un article les domaines réels, adresses, IP, noms de serveurs, volumes de boîtes, comptes ou configurations internes.
Principes qui restent valables
Le trafic web est dirigé par des enregistrements comme A, AAAA ou CNAME. Le courrier entrant est dirigé principalement par MX, tandis que SPF, DKIM et DMARC participent à l’authentification et à la politique des messages.
L’IMAP permet de lire et synchroniser des dossiers sur un serveur, mais une migration doit aussi considérer drapeaux, dates, arborescences, contacts, calendriers, règles, alias et délégations selon les plateformes. Une simple copie visible de la boîte de réception n’est pas toujours complète.
Définir quatre périmètres
Séparez le domaine enregistré, l’autorité DNS, l’hébergement web et le service e-mail. Notez le propriétaire, l’accès, la date de renouvellement et la méthode de récupération de chacun.
Ajoutez les services du domaine : sous-domaines, CDN, formulaires, SMTP transactionnel, signatures DKIM, validation de moteurs, outils de visioconférence et applications. Le changement doit préserver ceux qui ne migrent pas.
Cette carte reste privée. La procédure publique doit utiliser des exemples fictifs.
Inventorier le site WordPress
Relevez versions, thème, extensions, médias, base, tâches, formulaires, cache, HTTPS, redirections et intégrations. Identifiez les contenus qui peuvent changer pendant la copie et la durée acceptable d’un gel.
Préparez une sauvegarde restaurable et une cible qui répond avec le vrai nom de domaine lors d’un test contrôlé. La checklist migration WordPress détaille la copie cohérente et le retour arrière.
Ne migrez pas le site sur la foi d’une seule page d’accueil. Testez administration, recherche, formulaires et fonctions métier.
Inventorier le courrier
Listez boîtes, alias, groupes, redirections, boîtes partagées, quotas, politiques de rétention, carnets d’adresses, calendriers, délégations et applications qui envoient. Pour chaque identité, notez source, destination et propriétaire.
Mesurez le nombre de dossiers et la taille de manière privée. Repérez les noms utilisant des caractères particuliers, les messages volumineux et les dossiers exclus par l’outil de copie.
Décidez ce qui doit être migré, archivé ou recréé. Une adresse publiée mais jamais inventoriée peut devenir un trou de réception.
Comprendre le rôle du MX
Un enregistrement MX indique les échangeurs qui reçoivent le courrier destiné au domaine. Sa préférence aide les expéditeurs à choisir entre plusieurs cibles ; elle ne copie aucune boîte.
Les migrations par étapes peuvent maintenir une coexistence ou un routage entre anciens et nouveaux systèmes. La documentation Microsoft décrit par exemple la nécessité de choisir où le courrier entrant arrive en premier dans un scénario de coexistence. Le détail dépend entièrement des plateformes.
Le protocole de transport lui-même est décrit par la spécification SMTP de l’IETF. Elle permet de distinguer le routage des messages de la copie des boîtes, des règles et des autres données utilisateur.
Ne publiez pas les valeurs MX réelles ni les chemins de routage internes.
Préparer SPF, DKIM et DMARC
SPF autorise des sources d’envoi au niveau du domaine ; DKIM signe les messages ; DMARC définit une politique et des rapports en s’appuyant sur l’alignement. Une migration peut modifier les sources et clés.
Construisez l’état cible avec le fournisseur et vérifiez les limites syntaxiques. Évitez de publier deux enregistrements SPF concurrents. Préparez les nouveaux sélecteurs DKIM, mais ne retirez pas les anciens tant que des messages peuvent encore être envoyés par l’ancienne plateforme.
Modifiez DMARC selon une décision de risque, pas pour masquer une migration mal testée.
Tester la destination e-mail
Créez les identités et appliquez quotas, sécurité, alias et groupes. Testez la connexion avec les protocoles et clients prévus, en utilisant TLS et une authentification forte lorsque disponible.
Envoyez entre deux comptes de test internes, depuis l’extérieur vers la destination, puis de la destination vers plusieurs services externes autorisés. Vérifiez arrivée, dossier, expéditeur, signature, réponses et pièces jointes.
Utilisez uniquement des données de test. Ne copiez pas des messages réels dans des captures publiques.
Effectuer une copie initiale
Une première passe transfère l’essentiel avant la fenêtre de bascule. Elle permet de mesurer la vitesse, repérer les dossiers refusés et corriger les quotas sans pression.
Pour une migration IMAP, la norme actuelle définit des identifiants de messages et UIDVALIDITY pour détecter les changements d’identité entre sessions. Cela aide la resynchronisation, mais chaque outil interprète et mappe différemment les données.
Conservez un rapport de compteurs par boîte dans le dossier privé. Un statut « terminé » ne remplace pas une comparaison.
Prévoir les données hors IMAP
Contacts, calendriers, tâches, signatures, règles, réponses automatiques et autorisations ne passent pas nécessairement avec les messages IMAP. Inventoriez-les séparément et choisissez export, API, recréation ou accompagnement utilisateur.
Les applications mobiles et de bureau peuvent conserver d’anciens paramètres. Préparez des instructions claires sans inclure de mot de passe. Testez la découverte automatique si elle est prévue.
Une migration réussie du serveur mais inutilisable par les clients reste un échec opérationnel.
Préparer la bascule web
Terminez une synchronisation de fichiers et de base, appliquez le gel convenu et testez la cible. Préparez certificat, cache, tâches et redirections. Modifiez A/AAAA ou l’alias nécessaire sans toucher aux MX si le courrier ne bascule pas encore.
Le guide DNS et migration de site web explique la gestion du TTL, des deux origines et du retour.
Après changement, surveillez l’ancienne et la nouvelle origine jusqu’à ce que les caches observés aient basculé.
Préparer la bascule e-mail
Effectuez une synchronisation delta aussi près que possible du changement MX. Activez le routage cible et vérifiez les enregistrements d’authentification. Gardez l’ancien service capable de recevoir ou de relayer selon le plan.
Les expéditeurs peuvent conserver l’ancien MX en cache. Une seule valeur observée sur votre ordinateur ne prouve pas que le monde entier utilise la nouvelle route.
Prévoyez une dernière synchronisation après bascule pour récupérer les messages arrivés à l’ancienne destination.
Coordonner sans fusionner les fenêtres
Le web et le courrier peuvent basculer le même jour si l’équipe et les plans le justifient, mais chaque volet doit conserver ses critères, responsables et retour arrière. Souvent, des fenêtres séparées simplifient le diagnostic.
Évitez d’ajouter un transfert de registrar ou un changement complet de serveurs de noms à la même fenêtre. Plus le changement est large, plus le rayon d’incertitude augmente.
Communiquez aux utilisateurs ce qui change réellement et quand effectuer leurs tests.
Vérifier les formulaires du site
Un formulaire WordPress peut remettre un message via le serveur local, un relais SMTP ou une API. Migrer l’hébergement ou le courrier peut changer l’adresse d’envoi, l’authentification ou l’autorisation SPF/DKIM.
Testez formulaire, notification, réponse et réception avec des données fictives. Vérifiez que les messages ne sont ni perdus ni envoyés deux fois. Contrôlez la destination configurée dans les extensions.
Ne concluez pas à partir du message « envoyé » affiché dans le navigateur : il indique souvent seulement que la requête a été acceptée.
Tester après bascule
Pour le web : DNS, HTTP, HTTPS, pages, administration, formulaires, tâches, transactions et recherche. Pour l’e-mail : réception externe, envoi externe, échanges internes, alias, groupes, réponses, pièces jointes et authentification.
Comparez les compteurs de dossiers et effectuez une resynchronisation finale. Interrogez plusieurs résolveurs pour le MX et les enregistrements associés.
Surveillez les files et rejets sans partager leurs contenus. Une alerte d’authentification doit être traitée avant la fermeture de l’ancien service.
Concevoir deux retours arrière
Le web peut revenir vers l’ancienne origine si elle est restée cohérente. Le courrier peut revenir vers l’ancien MX, mais les messages déjà reçus sur la nouvelle plateforme doivent être réconciliés.
Définissez les seuils : indisponibilité, erreur de données, livraison impossible ou authentification critique. Documentez les valeurs précédentes et la personne qui décide.
Un retour DNS subit lui aussi les caches. Le mécanisme de coexistence ou de resynchronisation protège la période intermédiaire.
Ordre recommandé
- Cartographier domaine, DNS, web, e-mail et services associés.
- Inventorier WordPress et toutes les identités de courrier.
- Sauvegarder et tester les restaurations.
- Préparer les deux destinations.
- Tester web, boîtes, alias, envoi et authentification.
- Réaliser les copies initiales.
- Préparer TTL, gel, delta et retours arrière.
- Basculer chaque périmètre selon sa fenêtre.
- Resynchroniser et vérifier les fonctions réelles.
- Fermer les anciennes plateformes seulement après validation.
Les erreurs à éviter
- Croire que le changement du site déplace les boîtes.
- Remplacer toute la zone DNS par défaut.
- Oublier alias, groupes, calendriers ou règles.
- Retirer l’ancien DKIM alors qu’il envoie encore.
- Vérifier seulement les échanges internes.
- Fermer l’ancien courrier avant la dernière synchronisation.
- Utiliser des messages réels dans la documentation publique.
- Prévoir un seul retour arrière pour deux systèmes.
Checklist migration site et emails
- [ ] Les quatre périmètres et leurs responsables sont identifiés.
- [ ] La zone DNS complète est sauvegardée.
- [ ] WordPress et les identités e-mail sont inventoriés.
- [ ] Les destinations sont testées avant bascule.
- [ ] SPF, DKIM et DMARC ont un état de transition.
- [ ] La copie initiale et la synchronisation delta sont planifiées.
- [ ] Les formulaires WordPress sont testés de bout en bout.
- [ ] Les deux anciens services restent disponibles temporairement.
- [ ] Les compteurs et fonctions sont vérifiés après bascule.
- [ ] Deux retours arrière incluent la réconciliation des données.
Conclusion
Une migration site et emails devient maîtrisable lorsque le domaine, le DNS, WordPress et le courrier restent quatre objets distincts. Les plans peuvent être coordonnés sans être confondus.
La qualité se mesure au fonctionnement réel : pages accessibles, formulaires reçus, messages acheminés, authentification valide et données réconciliées. Pour choisir la cible web dans cette même logique de responsabilité, consultez choisir un hébergement WordPress.