Corriger les dates CloudM dans Gmail

CloudM Migrate (anciennement Cloud Migrator) téléverse les e-mails vers Google Workspace via l'API Gmail. Pendant le transfert, Gmail enregistre l'horodatage d'insertion comme INTERNALDATE du message. L'en-tête Date original à l'intérieur du corps de l'e-mail survit à la migration. Mais l'INTERNALDATE - le champ que les clients IMAP lisent pour déterminer la date de réception - est définitivement écrasée par la date de migration.

Ce qui rend les migrations CloudM particulièrement déroutantes, c'est le comportement en double. L'interface web de Gmail lit l'en-tête Date pour l'affichage, donc les e-mails apparaissent parfaitement corrects dans le navigateur. Ouvrez la même boîte aux lettres dans Outlook via IMAP, et chaque e-mail affiche la date de migration. Apple Mail, Thunderbird, clients IMAP mobiles - même constat. Le problème est invisible pour quiconque utilise uniquement Gmail sur le web, ce qui le rend plus difficile à diagnostiquer et plus facile à ignorer.

"La migration s'est bien passée, les dates sont correctes." C'est ce que la console CloudM vous dit. C'est ce que Gmail vous dit. Mais 60 % de vos utilisateurs se connectent via Outlook, et pour eux, 14 mois d'historique e-mail viennent de s'effondrer sur un seul jour.

D'ailleurs, la console d'administration CloudM dans le panneau Google Admin (Admin > Applications > Google Workspace Marketplace > CloudM Migrate) ne signale pas ce problème. Pas d'erreur, pas d'avertissement, pas de rapport post-migration mentionnant la corruption de l'INTERNALDATE. C'est un problème silencieux de qualité des données qui ne fait surface que quand les utilisateurs se plaignent.

L'impact dépend entièrement de la façon dont les utilisateurs accèdent à leur boîte aux lettres. Gmail web ? Tout paraît normal. Outlook, Apple Mail, Thunderbird via IMAP ? Chaque e-mail affiche la date de migration dans la colonne de réception. Cette incohérence génère des tickets de support confus et rend le problème difficile à expliquer aux utilisateurs non techniques.

Au-delà des problèmes d'affichage, la corruption de l'INTERNALDATE atteint l'infrastructure de conformité et de sauvegarde. Google Vault référence l'INTERNALDATE pour certaines opérations de rétention et d'obligation légale, ce qui peut compromettre la précision des recherches eDiscovery par date. Les outils de sauvegarde tiers connectés via IMAP (Veeam, Spanning, Backupify) archivent la date de migration comme date du message, créant des inexactitudes permanentes dans les sauvegardes qui pourraient n'être découvertes qu'au moment d'une restauration.

Redate.io corrige ce problème grâce à une analyse de la chaîne d'en-têtes et une reconstruction des métadonnées de date, ciblant uniquement les artefacts de migration injectés par CloudM. L'expérience Gmail web (qui s'affichait déjà correctement) reste inchangée. Les clients IMAP, Google Vault et les outils de sauvegarde commencent à lire la date originale. Chaque message est vérifié individuellement avant et après la correction pour garantir zéro perte de données.