Une migration sans interruption signifie que chaque message envoyé à votre domaine arrive dans une boîte, et que chaque salarié peut écrire à ses correspondants le jour de la bascule. Elle ne signifie pas que l’historique, les mobiles et les habitudes changent sans aucun geste.
Deux plateformes vivent en parallèle.
Le trou classique vient d’un MX basculé pendant qu’une copie est incomplète, ou d’un copieur, d’un site ou d’un CRM qui envoie encore avec l’ancien identifiant.
Le MX est un enregistrement DNS : il indique aux serveurs expéditeurs où livrer le courrier de votre domaine. Changer de messagerie, c’est d’abord changer cette adresse de livraison. Le reste (comptes, historique, appareils) se prépare autour.
Le protocole SMTP tolère bien les incidents courts. Un serveur expéditeur qui reçoit une erreur temporaire garde le message en file d’attente et réessaie plus tard. Un serveur momentanément injoignable ne fait donc pas perdre de courrier. En revanche, une erreur définitive (boîte inconnue, message refusé) renvoie le message à son expéditeur, et ce message n’arrivera jamais seul. Le risque principal d’une bascule n’est pas la panne, c’est la nouvelle plateforme qui refuse un destinataire parce qu’un alias ou une liste n’a pas été recréé.
Le TTL (durée de vie) fixe combien de temps un résolveur DNS peut garder une réponse en mémoire. Pendant ce délai, une partie des expéditeurs livre encore à l’ancienne plateforme. C’est normal, et c’est pour cela que l’ancienne doit rester capable de recevoir pendant la transition.
Deux semaines avant. Inventaire des boîtes, alias, listes, boîtes partagées, et de toutes les applications qui envoient du mail. Baisse du TTL DNS du MX à une valeur courte (souvent 300 secondes), pour que le jour J se propage vite. Création des comptes cibles. Première copie de l’historique.
Le TTL se baisse tôt parce qu’un résolveur qui a lu l’ancienne valeur la garde jusqu’à son expiration : le TTL court ne prend effet qu’une fois l’ancien cache écoulé. La première copie, elle, est la plus longue ; la lancer tôt laisse le temps de découvrir les boîtes qui posent problème.
Quelques jours avant. Contrôle d’un échantillon : nombre de messages, dossiers ou libellés, rendez-vous, contacts. Correction de la méthode si l’échantillon échoue. Préparation des notices mobiles et Outlook. Test d’envoi depuis la cible vers Gmail et Outlook.com, avec SPF, DKIM et DMARC déjà valides sur la nouvelle plateforme. Ces enregistrements peuvent être publiés avant le MX.
Concrètement : un seul enregistrement SPF qui autorise les deux plateformes pendant la transition (deux enregistrements SPF distincts font échouer la vérification), une clé DKIM de la nouvelle plateforme publiée sous son propre sélecteur, à côté de l’ancienne, et une politique DMARC relue. DMARC exige que le message soit authentifié par SPF ou par DKIM au nom du domaine de l’expéditeur ; si votre politique est stricte et que la cible n’est pas encore autorisée, vos correspondants rejettent vos messages.
La veille. Seconde passe : ne copier que ce qui est arrivé depuis la première copie. Geler les changements d’alias et de listes.
Le jour J. Bascule du MX. Vérification externe immédiate : un mail envoyé depuis une boîte personnelle extérieure doit arriver sur la nouvelle plateforme dans le délai du TTL. Surveillance de la file d’attente. Reconfiguration des applications d’envoi. Hotline interne identifiée, avec le droit de remettre le MX en arrière si un flux critique échoue.
Changez en même temps l’enregistrement autodiscover s’il existe : c’est lui qu’Outlook interroge pour trouver son serveur. Retirez aussi les MX secondaires qui désigneraient encore l’ancienne plateforme : un expéditeur qui n’arrive pas à joindre le MX principal essaie les suivants.
Les jours suivants. L’ancienne plateforme en lecture. Remontée des écarts (un dossier manquant, une boîte partagée). Troisième passe ciblée si besoin. Puis fermeture de l’envoi sur l’ancienne, pour qu’un salarié ne réponde plus depuis deux endroits.
Ce dernier point a une raison technique. L’ancienne plateforme se considère toujours responsable de votre domaine : un message envoyé depuis elle à un collègue y est livré localement, sans consulter le MX. Le collègue ne le verra jamais dans sa nouvelle boîte.
| Risque | Ce qui se passe | Parade |
|---|---|---|
| MX basculé trop tôt | Le courrier neuf arrive, l’historique manque | Basculer après contrôle de l’échantillon et seconde passe |
| Alias ou liste oubliés | La cible refuse définitivement ces messages | Inventaire, gel des alias la veille, test des adresses collectives |
| SPF, DKIM ou DMARC incomplets | Vos messages sont rejetés ou classés en indésirables chez les correspondants | Publier avant le jour J, vérifier sur un message réel |
| Application qui envoie avec l’ancien compte | Factures, alertes ou numérisations ne partent plus | Liste des applications, nouveau serveur SMTP configuré le jour J |
| Envoi resté ouvert sur l’ancienne plateforme | Des messages internes restent dans l’ancien système | Fermer l’envoi dès que l’échantillon est validé |
| Retour arrière non préparé | Le MX revient en arrière, mais les messages reçus entre-temps restent sur la cible | Plan écrit, avec la reprise de ces messages |
Prenons, à titre d’illustration, un cabinet de 40 personnes. Il choisit de basculer un jeudi en fin de journée plutôt qu’un vendredi : le lendemain, l’équipe est présente pour traiter les écarts, et la hotline interne a une journée ouvrée devant elle. Le copieur de l’accueil, qui numérise vers le mail, est reconfiguré le soir même. Si deux boîtes partagées remontent un dossier manquant, une passe ciblée les complète. Dans ce scénario, aucun message n’est perdu, mais plusieurs salariés doivent refaire leur compte sur le téléphone : c’est la part visible qu’il faut annoncer.
Ils changent de serveur dans Outlook ou sur le mobile. Le premier chargement d’une grosse boîte prend du temps. Les messages déjà en cache sur le téléphone peuvent faire doublon si le profil n’est pas refait proprement. Prévoyez la procédure « supprimer le compte et le recréer » plutôt qu’un bricolage de serveur.
La raison est la même pour Outlook : le profil garde un cache local lié à l’ancien serveur. Un nouveau profil part d’un état propre ; un ancien profil modifié mélange les deux mondes. Sur mobile, le protocole utilisé (Exchange ActiveSync ou IMAP selon la cible) change parfois avec la plateforme, ce qui est une raison de plus pour recréer le compte.
Les règles côté serveur, les signatures centralisées et les droits de délégation se reposent. Annoncez-le. Ce n’est pas une interruption du courrier. C’est du travail d’administration.
Ce renvoi demande un réglage explicite : l’ancienne plateforme, qui croit encore héberger les boîtes, doit être configurée pour relayer vers la nouvelle au lieu de livrer chez elle. À défaut, une passe de rattrapage ciblée fait le même travail.
Les particularités de chaque point de départ sont décrites dans migrer depuis Microsoft 365 et migrer depuis Google Workspace.
Le temps de vérifier qu’aucun flux n’utilise encore l’ancienne, et que les écarts remontés sont traités. Cela dépend du nombre de boîtes, des applications qui envoient et du rythme de reconfiguration des postes. Fermer trop tôt empêche de corriger ; fermer trop tard laisse des salariés travailler dans deux systèmes.
Non, s’il est préparé. Pendant la durée du TTL, une partie des expéditeurs livre encore à l’ancienne plateforme, l’autre à la nouvelle. Les deux reçoivent, et la passe suivante réunit les deux. Le courrier n’est perdu que s’il est refusé, d’où l’importance des alias et des listes.
En général, non : les adresses ne changent pas. Prévenez en revanche les partenaires qui filtrent strictement vos messages ou qui vous ont attribué une règle particulière, et ceux qui échangent avec vous du courrier chiffré, si les clés changent.
Oui, en remettant l’ancien MX, à condition que l’ancienne plateforme soit encore active. Les messages reçus par la nouvelle entre-temps doivent alors être recopiés ou rester consultables. Le plan de retour arrière dit qui décide, en combien de temps, et comment ces messages sont repris.
Demandez à l’opérateur ce qu’il garantit : l’arrivée des messages, la reprise de l’historique, ou les deux. Ce sont des engagements différents. Demandez aussi le plan de retour arrière, écrit, avec la personne qui a le droit de l’activer.
Une garantie sur l’arrivée des messages porte sur le jour J et les jours suivants. Une garantie sur l’historique porte sur la copie et son contrôle. Un prestataire peut tenir l’une sans l’autre ; le devis doit dire laquelle il prend en charge et comment elle se vérifie.
Chez Klytic, les conseils et suggestions pour préparer la migration de messagerie sont gratuits, et aucun mail n’est perdu. La migration réalisée par Klytic est établie sur devis. Les abonnements sont sur la page Tarifs et se facturent à part. Le détail des postes de coût est dans combien coûte une migration Microsoft 365, et la liste de contrôle dans la checklist. Pour comparer les cibles, voir choisir une messagerie européenne.
Cette page décrit une méthode. Le déroulé réel dépend de vos flux, de vos volumes et de la plateforme que vous quittez.
Consultées en octobre 2026.
Conseils gratuits, aucun mail perdu. La migration réalisée par Klytic est établie sur devis, après inventaire.
Offre de bienvenue
Offre d'essai sans engagement. Un conseiller vous rappelle pour comprendre vos besoins et préparer votre espace Klytic.
