CloudM Migrate : corriger les dates d'emails erronées

Le problème de dates CloudM Migrate dont personne ne parle

CloudM Migrate a terminé le boulot. Le tableau de bord affiche 100 % de complétion, tous les utilisateurs migrés, zéro erreur. Le ticket est fermé, on passe au client suivant.

Une semaine plus tard, le DSI appelle. "Pourquoi est-ce que chaque email de ma boîte 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 à laquelle CloudM a lancé la migration. Les messages sont là, le contenu est intact, les pièces jointes aussi. Mais les dates sont fausses sur chaque message.

Ce n'est pas un bug de CloudM. La documentation support de CloudM le reconnaît ouvertement. Le problème se situe à l'intersection entre la façon dont les outils de migration transfèrent les messages et la manière dont les serveurs de messagerie destination gèrent les métadonnées entrantes. Mais savoir ça n'aide pas votre client dont la boîte de réception est devenue introuable chronologiquement.

Comment CloudM transfère 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 délégation à l'échelle du domaine (configuré dans la Console d'administration Google sous Sécurité > Contrôles 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 récupère le contenu complet RFC 2822, y compris tous les en-têtes originaux et le corps du message. L'en-tête Date: original (celui que le serveur de messagerie de l'expéditeur a estampillé lors de l'envoi initial) est transmis intact. Les en-têtes Received: originaux qui retracent le parcours de livraison du message sont également préservés.

Le problème survient au moment où la copie est écrite. La destination garde la date qu'on lui donne : Microsoft 365 et Gmail conservent la date d'origine quand la copie la porte. Sinon, la copie prend comme date le moment de l'insertion. Et sur Google Workspace, chaque message écrit via l'API Gmail reçoit en plus un nouvel en-tête Received: daté du moment de l'insertion.

Voici ce que portent encore les en-têtes d'un de ces emails après une migration CloudM vers Microsoft 365 :

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

L'en-tête Date: original de 2019 est toujours là, tout comme la chaîne Received: d'origine. Mais dans Microsoft 365, la date qu'Outlook affiche comme date de réception est celle que la boîte a enregistrée à l'arrivée de chaque email : si CloudM n'a pas transmis la date d'origine, elle indique le 2 avril 2026.

Le paramètre "Strip Received Headers" de CloudM

CloudM propose un paramètre pour traiter ce problème. Dans les paramètres avancés de la plateforme de destination, sous Message Options, il existe un toggle "Strip Received Headers". Quand il est activé, CloudM supprime les en-têtes Received avant d'insérer le message et les remplace par un seul en-tête correspondant à l'en-tête Date: de l'email.

Ça paraît résoudre le problème, non ? Pas tout à fait.

D'abord, il faut connaître cette option avant de lancer la migration. La plupart des administrateurs découvrent le problème de dates après la fin de la migration. À ce stade, les messages sont déjà à destination avec les mauvaises dates. Relancer CloudM avec le paramètre activé ne fait que créer des doublons, ça ne corrige pas ce qui est déjà en place.

Ensuite, ce paramètre a une limitation importante quand Google Workspace est la destination. La documentation de Google le confirme : Gmail réécrit systématiquement les en-têtes Received: sur les messages insérés 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. Même avec "Strip Received Headers" activé, Google Workspace ajoute son propre en-tête Received: avec la date de migration.

Pour les destinations Microsoft 365, ce paramètre compte moins : Microsoft 365 garde la date qu'on lui donne, donc ce qui décide de la date affichée, c'est que CloudM transmette ou non la date d'origine de chaque email.

Quelles migrations CloudM cassent les dates (et lesquelles non)

Toutes les migrations CloudM ne produisent pas des dates erronées. Le résultat dépend de la combinaison source-destination et du chemin API spécifique utilisé par CloudM :

• Google Workspace vers Microsoft 365 : Les dates sont erronées. CloudM lit via l'API Gmail et écrit vers Exchange, et chaque email reçoit la date de la copie.
• Microsoft 365 vers Google Workspace : Les dates sont erronées. Même avec Strip Received Headers, l'API de Google réécrit l'en-tête 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 erronées. Changement de domaine, consolidation de tenants, fusions : chaque message écrit via l'API Gmail reçoit un en-tête Received: daté de la migration.
• Exchange sur site vers Microsoft 365 : Tout dépend de la date que CloudM transmet, que la copie passe par IMAP ou par EWS.
• Source IMAP (générique) vers n'importe quelle destination : Même règle : quand CloudM se connecte à un serveur IMAP générique comme source, la copie affiche la date de migration chaque fois que la date d'origine n'est pas transmise à la destination.

Le point délicat ? 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 réussi. Et techniquement, c'est vrai. Les messages ont été transférés. Les dates, elles, n'ont pas survécu au voyage.

CloudM Manage vs. Self-Service : même problème de dates

CloudM propose deux modèles de déploiement. La version SaaS (CloudM Migrate hébergé) tourne entièrement dans l'infrastructure de CloudM. La version auto-hébergée permet de déployer des serveurs de migration primaires et secondaires sur votre propre réseau, Google Cloud, Azure ou AWS.

Certains MSP supposent que l'option auto-hébergée offre plus de contrôle sur la gestion des dates puisqu'on administre directement les serveurs de migration. Ce n'est pas le cas. Ce qui décide de la date, c'est ce que le moteur de migration transmet avec chaque message, et ce moteur est le même où qu'il tourne. Que votre ferme de migration tourne dans le cloud de CloudM ou sur votre propre VM Azure, le résultat pour les dates est le même.

CloudM propose aussi un service "Serviced Migration" entièrement géré où leur équipe prend en charge le projet de bout en bout. Même résultat pour les dates. L'ingénierie est identique, ce sont juste d'autres mains sur le clavier. Vous avez déjà payé pour un service premium et obtenu la même limitation que la version gratuite ? C'est exactement ce sentiment.

La complication des en-têtes Date invalides

Il y a un autre comportement spécifique à CloudM qui aggrave les choses. Quand CloudM rencontre un email source dont l'en-tête Date: ne respecte pas RFC 822 (fuseau horaire malformed, jour de la semaine manquant, format non standard), il modifie l'en-tête pour que le message puisse être migré.

Du coup, certains emails perdent même leur référence de date originale. L'en-tête Date: modifié peut ne pas correspondre du tout à la vraie date d'envoi. La documentation support de CloudM mentionne ce comportement sous "Possible Changes to Migrated Items" mais ne précise pas ce que devient la date modifiée.

Pour une boîte aux lettres de 12 000 messages accumulés sur huit ans, vous pourriez avoir des centaines d'emails avec des en-têtes Date légèrement non standards (particulièrement des messages provenant d'anciens serveurs de messagerie, de systèmes automatisés ou d'expéditeurs internationaux avec des particularités de formatage de fuseau horaire). Après la modification de CloudM, et une copie qui ne porte pas la date d'origine, ces messages se retrouvent avec des dates qui n'ont plus aucun rapport avec la réalité.

Pourquoi les corrections manuelles ne passent pas à l'échelle

Est-ce qu'on pourrait corriger ça soi-même ? Techniquement, l'en-tête Date: original est toujours présent dans la plupart des messages (sauf ceux que CloudM a modifiés pour conformité RFC). Certains administrateurs ont tenté d'écrire des scripts pour corriger les dates après une migration CloudM.

Voici la réalité de cette approche. On parle de se connecter à potentiellement des milliers de boîtes aux lettres, chacune avec des milliers de messages. Pour chaque email, il faut parser la chaîne d'en-têtes complète, identifier quels en-têtes Received: CloudM ou le serveur de destination ont ajoutés, gérer les cas limites (messages signés S/MIME où la modification d'en-tête casse la signature, contenu chiffré PGP, structures MIME multipart avec des frontières imbriquées, en-têtes non-ASCII RFC 2047 d'expéditeurs japonais ou coréens), et faire tout ça sans perdre une seule pièce jointe ni casser le threading des emails.

Un script qui fonctionne sur 50 emails de test dans une boîte propre ne survivra pas au contact d'un environnement de production de 40 000 messages sur une décennie. Que se passe-t-il quand on tombe sur un email de 47 Mo avec six pièces jointes imbriquées ? Et les quotas API (250 unités par utilisateur par seconde pour Google, le throttling de Microsoft à environ 10 000 requêtes par 10 minutes) ? Quel est le plan de rollback quand quelque chose tourne mal au message numéro 8 347 ?

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

Corriger les dates de migration CloudM avec Redate.io

Redate.io se connecte directement aux boîtes aux lettres affectées (Google Workspace, Microsoft 365 ou IMAP) et repère les emails dont la date affichée ne correspond pas à leur date d'origine. Le scan est gratuit et prend quelques minutes par boîte, affichant le nombre exact de messages affectés avant tout engagement.

La correction utilise un moteur propriétaire d'analyse des chaînes d'en-têtes, qui n'a pas besoin de savoir quel outil a fait la migration. Redate.io effectue une correction ciblée des métadonnées sans altérer le contenu du message, en préservant les pièces jointes, le threading, les labels, les dossiers et les signatures numériques. Chaque message corrigé passe par une vérification individuelle, contrôlant l'intégrité du message par rapport à l'original avant de poursuivre le processus.

Les emails originaux sont conservés dans un dossier de sauvegarde visible Redate.io - Originals jusqu'à ce que vous les supprimiez vous-même. Si quoi que ce soit doit être annulé, les originaux sont là, directement dans la boîte aux lettres, pas enfouis dans une archive externe.

Pour les MSP qui ont utilisé CloudM sur des environnements clients, Redate.io gère les corrections multi-boîtes à l'échelle, avec la même vérification par message que ce soit pour 1 boîte ou 500. Le problème de dates que CloudM a laissé derrière n'a pas à devenir une caractéristique permanente de l'environnement mail de votre client.

Guides de correction par plateforme pour CloudM

Le processus de correction s'adapte à la plateforme de destination. Redate.io gère les spécificités de chaque plateforme automatiquement, mais pour les détails 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 erronées après migration.

Migration avec CloudM et des dates fausses sur chaque email ? Lancez un scan gratuit pour voir exactement combien de messages sont affectés et combien ça coûte de les corriger.