Migration Google Workspace vers Google Workspace : dates cassées

Le scénario que personne ne soupçonne

Vous venez de finaliser la migration d'un tenant Google Workspace vers un autre. Rachat d'une société, changement de domaine, fusion de deux entités qui coexistaient sous des comptes G Suite séparés depuis des années. L'opération s'est bien passée, les boîtes sont en place, les utilisateurs se connectent. Lundi matin, premier ticket : "Tous mes emails ont la même date." Puis un deuxième. Puis dix.

Instinctivement, vous pensez : c'est forcément un problème IMAP, un outil mal configuré, quelque chose d'exotique. Pas une migration Google vers Google. Pourtant, c'est exactement là que ça se passe.

Ce scénario est probablement le plus mal documenté du secteur. La plupart des admins IT qui le rencontrent perdent plusieurs heures à chercher une explication côté client mail, côté Outlook, côté paramètres de compte, avant de réaliser que le problème est dans les en-têtes des emails eux-mêmes.

Pourquoi une migration Google vers Google casse les dates

Pour comprendre ce qui se passe, il faut revenir à la mécanique des en-têtes email. Chaque message RFC 2822 contient un champ Date: original, posé par le client ou le serveur expéditeur au moment de l'envoi. C'est la date "vraie" de l'email, celle qui correspond à quand le message a été rédigé et envoyé.

Mais il existe un autre mécanisme : l'INTERNALDATE IMAP. C'est une métadonnée stockée côté serveur qui indique quand le message a été déposé dans la boîte. Et c'est là que ça devient intéressant.

Quand un outil de migration transfère un email d'un tenant Google Workspace vers un autre, il passe par le protocole IMAP (même si les deux serveurs sont chez Google). Le message est lu depuis la source, puis réinséré dans la destination. Au moment de cette réinsertion, le serveur de destination ajoute automatiquement un en-tête Received: avec l'horodatage de l'opération, c'est-à-dire la date de migration.

Or, des clients mail comme Outlook utilisent le premier Received: de la chaîne pour afficher la date d'un message, pas forcément le champ Date: original. Résultat : tous les emails affichent la date du jour de migration.

Quels outils déclenchent le problème

Pratiquement tous les outils utilisés pour des migrations inter-tenants Google Workspace sont concernés. Pas d'exception notable :

• GSMMO (Google Workspace Migration for Microsoft Outlook) : conçu à la base pour migrer depuis Exchange, mais utilisé dans certains flux GWS vers GWS.
• CloudM Migrate : très répandu chez les MSPs pour les migrations inter-Google, ajoute systématiquement un Received: de migration. Voir l'analyse détaillée de CloudM.
• BitTitan MigrationWiz : idem, le comportement est documenté dans cet article sur BitTitan.
• imapsync : l'outil open source qui permet de scripter des migrations IMAP, y compris entre deux tenants Google.
• Les exports/imports manuels via Takeout + réimport IMAP : moins courants, mais produisent exactement le même effet.

La raison est simple : tous ces outils fonctionnent comme des clients IMAP standards. Ils n'ont pas accès à une voie "native" Google qui préserverait les métadonnées. Même si les deux tenants sont chez Google, le transfert passe par la couche IMAP, et cette couche ne sait pas qu'elle parle à elle-même.

La mécanique des en-têtes Received en détail

(D'ailleurs, si vous avez déjà essayé de lire les en-têtes bruts d'un email depuis Gmail ou Outlook, vous savez que c'est rarement une lecture de plaisir. Mais c'est là que toute la vérité se cache.)

Un email qui a voyagé normalement contient une chaîne d'en-têtes Received: dans l'ordre inverse du trajet : le dernier serveur à avoir touché le message est en haut. Après une migration, l'en-tête de migration se retrouve donc tout en haut de la pile.

Voici à quoi ça ressemble dans un message migré via CloudM d'un tenant GWS vers un autre :

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <utilisateur@nouveau-domaine.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Le champ Date: dit 2019. Le premier Received: dit octobre 2024. Outlook lit le premier Received:. L'utilisateur voit octobre 2024 pour un email de 2019.

Le champ Date: original est intact. Il n'a pas bougé. C'est la bonne nouvelle : la donnée est là, elle attend juste d'être utilisée correctement.

Outlook et Gmail ne se comportent pas pareil

C'est une précision importante. Les utilisateurs qui accèdent à leurs emails via l'interface web de Gmail voient souvent les bonnes dates, parce que Gmail utilise en priorité le champ Date: RFC 2822 pour afficher les messages. Le problème est moins visible côté web.

En revanche, les utilisateurs qui configurent leur boîte Google Workspace dans Outlook via IMAP (ou via la synchronisation Exchange ActiveSync) subissent de plein fouet la mauvaise date, parce qu'Outlook se fie à l'INTERNALDATE IMAP, qui lui reflète la date du premier Received: ajouté lors de la migration.

Correction : pour être précis, le comportement d'Outlook varie selon la version et le mode de connexion. Outlook 2019 et Microsoft 365 (les versions récentes) utilisent l'INTERNALDATE quand ils se connectent en IMAP. Les versions plus anciennes peuvent avoir des comportements légèrement différents. Mais dans tous les cas observés en production, la migration GWS vers GWS via IMAP produit des dates incorrectes dans Outlook.

Du coup, dans les organisations qui ont migré vers un nouveau tenant et qui maintiennent des utilisateurs hybrides (certains sur Gmail web, d'autres sur Outlook), les remontées de tickets sont incohérentes. Les équipes IT passent du temps à comprendre pourquoi "certains sont affectés et d'autres pas", alors que la réponse est simplement : c'est le client mail qui fait la différence.

Rachats, fusions, changements de domaine : les cas les plus fréquents

Ce type de migration n'est pas anecdotique. Voici les scénarios qui génèrent le plus de tickets :

Rachat d'entreprise

Une société rachetée avait son propre tenant Google Workspace (domaine @ancienneentreprise.com). Après le rachat, tout doit migrer vers le tenant de la maison mère (@groupe.com). Les 250 boîtes, les archives, les 8 ans d'historique email. BitTitan ou CloudM est mandaté pour l'opération. Résultat : 2,4 millions d'emails avec la date du week-end de migration.

Changement de domaine

Une entreprise rebrandie passe de @anciennom.fr à @nouveaunom.fr. Même tenant Google, mais création d'un nouveau tenant pour repartir proprement (choix courant pour éviter les artifacts de configuration). Migration des boîtes via imapsync ou GSMMO. Les dates cassent exactement de la même façon.

Consolidation de filiales

Un groupe avec 4 filiales, chacune sur son propre tenant G Suite historique, qui décide de tout regrouper sur un tenant unique. Quatre migrations en parallèle, quatre lots d'emails avec des dates corrompues à traiter.

Dans ces trois scénarios, le problème est identique et la solution est la même. La checklist de migration email permet d'anticiper ce type de problème avant de lancer la migration.

Pourquoi un script maison n'est pas la réponse

Comprendre le problème, c'est une chose. Se dire "je vais écrire un script Python qui nettoie les en-têtes" et l'appliquer sur 30 000 emails de production, c'en est une autre.

Les cas limites sont légion. Un script qui fonctionne sur 50 emails de test dans un environnement propre rencontrera inévitablement, sur une boîte de production de taille réelle :

• Des messages avec des signatures S/MIME ou du contenu PGP chiffré, où toute modification de la structure du message invalide la signature cryptographique.
• Des emails avec des structures MIME imbriquées complexes (multipart/alternative dans un multipart/mixed avec des pièces jointes de plusieurs dizaines de mégaoctets).
• Des en-têtes encodés en RFC 2047 (caractères non-ASCII), que les parseurs mal configurés mangent silencieusement.
• Des erreurs 429 Too Many Requests de l'API Google à 2h du matin, en plein milieu d'un batch de correction, qui laissent le processus dans un état indéterminé.
• Des emails pour lesquels la chaîne de Received: est ambiguë : plusieurs outils de migration successifs ont chacun ajouté leur en-tête, et il n'est pas trivial de déterminer lequel retirer.

Et la question la plus importante : comment vérifier, email par email, que chaque message corrigé est intact et que rien n'a été perdu ou corrompu ? Un script maison ne fait généralement pas cette vérification. Redate.io la fait automatiquement, avec conservation des originaux dans un dossier de sauvegarde visible pendant 30 jours.

Ce que fait Redate.io sur ce type de migration

Redate.io se connecte au tenant Google Workspace de destination (via délégation de domaine, sans intervention manuelle boîte par boîte) et scanne les emails pour identifier ceux dont les métadonnées de date sont incohérentes avec le contenu du message. Cette phase de scan est gratuite et donne une vision exacte de l'ampleur du problème avant toute correction.

Le moteur de correction propriétaire analyse ensuite la chaîne d'en-têtes de chaque message, applique une correspondance de motifs sur les signatures connues des outils de migration (BitTitan, CloudM, imapsync, GSMMO, et d'autres moins courants), et effectue une correction ciblée des métadonnées sans altération du contenu du message. Chaque email corrigé est vérifié individuellement. Les originaux sont conservés.

Pour les migrations inter-tenants Google Workspace spécifiquement, le pipeline gère les cas où plusieurs passes de migration ont eu lieu (par exemple, une boîte migrée une première fois en 2021 puis à nouveau en 2024), avec plusieurs couches d'en-têtes parasites à démêler.

Le guide de correction spécifique CloudM vers Google Workspace et BitTitan vers Google Workspace détaillent les étapes de connexion pour ce type de configuration.

Détecter le problème avant que les utilisateurs ne s'en plaignent

Le meilleur moment pour détecter des dates corrompues, c'est juste après la migration, avant le go-live. Une vérification rapide sur quelques boîtes pilotes via un client IMAP comme Thunderbird permet de comparer l'affichage des dates avec ce qu'on attendrait. Si tous les emails importés semblent avoir la même date récente, c'est le signe caractéristique du problème.

Mais en pratique, la découverte du problème se fait souvent plusieurs semaines après la migration, quand un utilisateur cherche un vieux contrat et réalise que sa boîte Gmail est parfaitement triée... par date de migration. Des milliers d'emails entassés au même horodatage. La recherche par date ne fonctionne plus. Les fils de discussion sont dans le désordre. L'historique semble avoir disparu.

Pour les MSPs qui gèrent régulièrement des migrations inter-tenants Google Workspace, intégrer un scan Redate.io dans la checklist post-migration (avant la validation client) évite ce genre de surprise.

Vous venez de migrer entre deux tenants Google Workspace et les dates de vos emails sont incorrectes ? Lancez un scan gratuit sur Redate.io pour mesurer l'impact avant toute correction.