CloudM Migrate : corriger les dates d'emails erronees

Le probleme de dates CloudM Migrate dont personne ne parle

CloudM Migrate a termine le boulot. Le tableau de bord affiche 100 % de completion, tous les utilisateurs migres, zero erreur. Le ticket est ferme, on passe au client suivant.

Une semaine plus tard, le DSI appelle. "Pourquoi est-ce que chaque email de ma boite affiche le 2 avril ?"

Pas quelques emails. Tous. Cinq ans de correspondance client, des documents juridiques, des fiches RH, des bons de commande de 2020, tout affichant la date a laquelle CloudM a lance la migration. Les messages sont la, le contenu est intact, les pieces jointes aussi. Mais les dates sont fausses sur chaque message.

Ce n'est pas un bug de CloudM. La documentation support de CloudM le reconnait ouvertement. Le probleme se situe a l'intersection entre la facon dont les outils de migration transferent les messages et la maniere dont les serveurs de messagerie destination gerent les metadonnees entrantes. Mais savoir ca n'aide pas votre client dont la boite de reception est devenue introuable chronologiquement.

Comment CloudM transfere les emails en pratique

CloudM Migrate se connecte aux plateformes source et destination via leurs API. Pour Google Workspace, cela passe par un compte de service avec delegation a l'echelle du domaine (configure dans la Console d'administration Google sous Securite > Controles des API). Pour Microsoft 365, CloudM utilise Exchange Web Services ou l'API Microsoft Graph, selon le chemin de migration.

Quand CloudM lit un message depuis la source, il recupere le contenu complet RFC 2822, y compris tous les en-tetes originaux et le corps du message. L'en-tete Date: original (celui que le serveur de messagerie de l'expediteur a estampille lors de l'envoi initial) est transmis intact. Les en-tetes Received: originaux qui retracent le parcours de livraison du message sont egalement preserves.

Le probleme survient a la destination. Quand CloudM ecrit ce message dans la boite cible, le serveur de destination le traite comme une nouvelle livraison. Il y appose un en-tete Received: frais avec la date et l'heure actuelles, et fixe l'INTERNALDATE (l'horodatage qu'IMAP utilise pour le tri) au moment de l'insertion.

Voici a quoi ressemble la chaine d'en-tetes apres une migration CloudM vers Microsoft 365 :

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

L'en-tete de 2019 est bien la. L'en-tete Date: original indique toujours le 23 septembre 2019. Mais Outlook lit l'en-tete Received: le plus recent pour determiner l'ordre d'affichage, et celui-la indique le 2 avril 2026.

Le parametre "Strip Received Headers" de CloudM

CloudM propose un parametre pour traiter ce probleme. Dans les parametres avances de la plateforme de destination, sous Message Options, il existe un toggle "Strip Received Headers". Quand il est active, CloudM supprime les en-tetes Received avant d'inserer le message et les remplace par un seul en-tete correspondant a l'en-tete Date: de l'email.

Ca parait resoudre le probleme, non ? Pas tout a fait.

D'abord, il faut connaitre cette option avant de lancer la migration. La plupart des administrateurs decouvrent le probleme de dates apres la fin de la migration. A ce stade, les messages sont deja a destination avec les mauvaises dates. Relancer CloudM avec le parametre active ne fait que creer des doublons, ca ne corrige pas ce qui est deja en place.

Ensuite, ce parametre a une limitation importante quand Google Workspace est la destination. La documentation de Google le confirme : Gmail reecrit systematiquement les en-tetes Received: sur les messages inseres via API, en les estampillant avec l'horodatage d'insertion. C'est une restriction au niveau de la plateforme que CloudM ne peut pas contourner. Meme avec "Strip Received Headers" active, Google Workspace ajoute son propre en-tete Received: avec la date de migration.

Pour les destinations Microsoft 365, le parametre fonctionne mieux en theorie, mais le pipeline de transport de M365 a son propre comportement. Exchange Online peut quand meme fixer l'INTERNALDATE en se basant sur son propre traitement de livraison, selon la facon dont le message entre dans le systeme.

Quelles migrations CloudM cassent les dates (et lesquelles non)

Toutes les migrations CloudM ne produisent pas des dates erronees. Le resultat depend de la combinaison source-destination et du chemin API specifique utilise par CloudM :

• Google Workspace vers Microsoft 365 : Les dates sont cassees. CloudM lit via l'API Gmail et ecrit vers Exchange. La couche transport de M365 appose de nouveaux en-tetes Received.
• Microsoft 365 vers Google Workspace : Les dates sont cassees. Meme avec Strip Received Headers, l'API de Google reecrit l'en-tete Received avec la date d'insertion. La documentation support de CloudM parle de "limitation stricte de la plateforme".
• Google Workspace vers Google Workspace : Les dates sont cassees. Changement de domaine, consolidation de tenants, fusions, le tenant Google de destination estampille systematiquement la date de migration sur les messages entrants.
• Exchange sur site vers Microsoft 365 : Generalement casse via le chemin IMAP. Si CloudM utilise EWS des deux cotes, la preservation des dates est plus fiable mais pas garantie.
• Source IMAP (generique) vers n'importe quelle destination : Les dates sont cassees. Quand CloudM se connecte a un serveur IMAP generique comme source, la destination ajoute quand meme ses propres en-tetes de livraison.

Le point delicat ? Le tableau de bord de migration CloudM ne signale rien de tout cela. La barre de progression se remplit, la colonne statut affiche "Completed", les compteurs correspondent. Du point de vue de CloudM, la migration a reussi. Et techniquement, c'est vrai. Les messages ont ete transferes. Les dates, elles, n'ont pas survecu au voyage.

CloudM Manage vs. Self-Service : meme probleme de dates

CloudM propose deux modeles de deploiement. La version SaaS (CloudM Migrate heberge) tourne entierement dans l'infrastructure de CloudM. La version auto-hebergee permet de deployer des serveurs de migration primaires et secondaires sur votre propre reseau, Google Cloud, Azure ou AWS.

Certains MSP supposent que l'option auto-hebergee offre plus de controle sur la gestion des dates puisqu'on administre directement les serveurs de migration. Ce n'est pas le cas. Le probleme de dates se produit au niveau du serveur de destination, pas sur les noeuds de traitement de CloudM. Que votre ferme de migration tourne dans le cloud de CloudM ou sur votre propre VM Azure, le serveur de destination estampille quand meme la date de migration sur chaque message recu.

CloudM propose aussi un service "Serviced Migration" entierement gere ou leur equipe prend en charge le projet de bout en bout. Meme resultat pour les dates. L'ingenierie est identique, ce sont juste d'autres mains sur le clavier. Vous avez deja paye pour un service premium et obtenu la meme limitation que la version gratuite ? C'est exactement ce sentiment.

La complication des en-tetes Date invalides

Il y a un autre comportement specifique a CloudM qui aggrave les choses. Quand CloudM rencontre un email source dont l'en-tete Date: ne respecte pas RFC 822 (fuseau horaire malformed, jour de la semaine manquant, format non standard), il modifie l'en-tete pour que le message puisse etre migre.

Du coup, certains emails perdent meme leur reference de date originale. L'en-tete Date: modifie peut ne pas correspondre du tout a la vraie date d'envoi. La documentation support de CloudM mentionne ce comportement sous "Possible Changes to Migrated Items" mais ne precise pas ce que devient la date modifiee.

Pour une boite aux lettres de 12 000 messages accumules sur huit ans, vous pourriez avoir des centaines d'emails avec des en-tetes Date legerement non standards (particulierement des messages provenant d'anciens serveurs de messagerie, de systemes automatises ou d'expediteurs internationaux avec des particularites de formatage de fuseau horaire). Apres la modification de CloudM plus la reecriture de l'en-tete Received par le serveur de destination, ces messages se retrouvent avec des dates qui n'ont plus aucun rapport avec la realite.

Pourquoi les corrections manuelles ne passent pas a l'echelle

Est-ce qu'on pourrait corriger ca soi-meme ? Techniquement, l'en-tete Date: original est toujours present dans la plupart des messages (sauf ceux que CloudM a modifies pour conformite RFC). Certains administrateurs ont tente d'ecrire des scripts pour corriger les dates apres une migration CloudM.

Voici la realite de cette approche. On parle de se connecter a potentiellement des milliers de boites aux lettres, chacune avec des milliers de messages. Pour chaque email, il faut parser la chaine d'en-tetes complete, identifier quels en-tetes Received: CloudM ou le serveur de destination ont ajoutes, gerer les cas limites (messages signes S/MIME ou la modification d'en-tete casse la signature, contenu chiffre PGP, structures MIME multipart avec des frontieres imbriquees, en-tetes non-ASCII RFC 2047 d'expediteurs japonais ou coreens), et faire tout ca sans perdre une seule piece jointe ni casser le threading des emails.

Un script qui fonctionne sur 50 emails de test dans une boite propre ne survivra pas au contact d'un environnement de production de 40 000 messages sur une decennie. Que se passe-t-il quand on tombe sur un email de 47 Mo avec six pieces jointes imbriquees ? Et les quotas API (250 unites par utilisateur par seconde pour Google, le throttling de Microsoft a environ 10 000 requetes par 10 minutes) ? Quel est le plan de rollback quand quelque chose tourne mal au message numero 8 347 ?

Et la vraie question que la plupart des administrateurs ne posent pas avant qu'il soit trop tard : comment verifier que chaque message corrige est effectivement intact ?

Corriger les dates de migration CloudM avec Redate.io

Redate.io se connecte directement aux boites aux lettres affectees (Google Workspace, Microsoft 365 ou IMAP) et scanne les emails portant la signature de date de migration CloudM. Le scan est gratuit et prend quelques minutes par boite, affichant le nombre exact de messages affectes avant tout engagement.

La correction utilise un moteur d'analyse propriataire de chaines d'en-tetes qui identifie les patterns de migration specifiques a CloudM a travers la chaine Received. Redate.io effectue une correction ciblee des metadonnees sans alterer le contenu du message, en preservant les pieces jointes, le threading, les labels, les dossiers et les signatures numeriques. Chaque message corrige passe par une verification individuelle, controlant l'integrite du message par rapport a l'original avant de poursuivre le processus.

Les emails originaux sont conserves dans un dossier de sauvegarde visible Redate.io - Originals pendant 30 jours. Si quoi que ce soit doit etre annule, les originaux sont la, directement dans la boite aux lettres, pas enfouis dans une archive externe.

Pour les MSP qui ont utilise CloudM sur des environnements clients, Redate.io gere les corrections multi-boites a l'echelle, avec la meme verification par message que ce soit pour 1 boite ou 500. Le probleme de dates que CloudM a laisse derriere n'a pas a devenir une caracteristique permanente de l'environnement mail de votre client.

Guides de correction par plateforme pour CloudM

Le processus de correction s'adapte a la plateforme de destination. Redate.io gere les specificites de chaque plateforme automatiquement, mais pour les details sur votre configuration :

• Corriger les dates de migration CloudM dans Gmail
• Corriger les dates de migration CloudM dans Outlook
• Corriger les dates de migration CloudM dans Google Workspace
• Corriger les dates de migration CloudM dans Microsoft 365

Pour une explication approfondie de pourquoi cela se produit avec tous les outils de migration (pas seulement CloudM), consultez pourquoi les emails affichent des dates erronees apres migration.

Migration avec CloudM et des dates fausses sur chaque email ? Lancez un scan gratuit pour voir exactement combien de messages sont affectes et combien ca coute de les corriger.