GSMMO a modifié vos dates d'emails ? Voici la solution

GSMMO et le problème de dates dont personne ne parle

Google Workspace Migration for Microsoft Outlook (GSMMO) est l'outil bureautique que Google fournit pour migrer des fichiers PST, des profils Outlook et des archives email locales vers Gmail. C'est gratuit, officiellement supporté, et c'est le chemin de migration que Google recommande quand on déplace une petite équipe ou quelques boîtes aux lettres individuelles d'Outlook vers Google Workspace.

L'outil fonctionne. Les emails arrivent dans Gmail, la structure de dossiers se mappe en labels, les contacts passent. Mais ouvrez Gmail après et triez par date. Chaque email affiche la date du jour. Cette proposition envoyée en janvier 2021 ? Avril 2026. La facture de votre comptable de mars 2023 ? Aussi avril 2026.

GSMMO ne prévient pas que ça va arriver. Le journal de migration affiche un succès pour chaque message. La documentation Google elle-même ne le mentionne pas comme limitation connue. On ne le découvre que quand quelqu'un cherche un ancien email par plage de dates et obtient zéro résultats.

Comment GSMMO envoie réellement vos emails

GSMMO lit les messages depuis le fichier PST (ou directement depuis le profil Outlook) et les envoie vers Gmail via l'API Gmail (les notes de version de l'outil publiées par Google le disent). C'est là que le problème de dates prend racine, et ça vaut la peine de comprendre la mécanique parce que ça explique pourquoi la solution n'est pas aussi simple que "réimporter".

Quand GSMMO envoie un message via l'API Gmail, Gmail lui ajoute un nouvel en-tête Received: daté du moment du transfert. Et quand la date d'origine n'est pas transmise avec le message, l'INTERNALDATE, l'horodatage que Gmail utilise en interne pour le tri et l'affichage, prend le moment du transfert au lieu de la date d'envoi d'origine.

Voici à quoi ressemble la chaîne d'en-têtes après une migration GSMMO :

Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
    bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
    by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200

Vous voyez cet en-tête Date: original de septembre 2019 ? Il est toujours là, intact. GSMMO ne modifie pas le corps du message ni les en-têtes originaux. Mais Gmail l'ignore pour l'affichage et utilise l'INTERNALDATE à la place, qui indique maintenant avril 2026.

GSMMO vs. les outils de migration administrateur

C'est là que la confusion commence souvent. Google dispose de plusieurs outils de migration, et ils ne se comportent pas tous de la même manière.

GSMMO (l'application bureautique) tourne sur la machine de l'utilisateur. Il lit depuis Outlook ou un fichier PST et envoie les emails via l'API Gmail. L'utilisateur a besoin d'un compte Google Workspace et du plugin GSMMO installé dans Outlook. C'est un outil côté client.

Google Workspace Migration Service (l'outil de la console d'administration) fonctionne côté serveur. Un administrateur le configure dans la Console d'administration Google, le pointe vers un serveur Exchange ou un autre tenant Google Workspace, et la migration s'exécute dans l'infrastructure Google. Cet outil gère les dates un peu mieux dans certaines configurations parce qu'il peut définir l'INTERNALDATE à partir des métadonnées source. Mais "un peu mieux" ne veut pas dire "fiable", et beaucoup d'administrateurs signalent le même problème de dates avec cet outil aussi.

La différence clé ? Avec GSMMO, il n'y a aucune intelligence côté serveur pour la préservation des dates. Chaque message qu'il envoie reçoit le même traitement, qu'il s'agisse d'un email tout frais ou d'un message archivé vieux de 10 ans : un en-tête Received: daté du jour du transfert. Point.

Pourquoi la préservation des dates GSMMO ne fonctionne pas

Si vous avez regardé les paramètres GSMMO, vous avez peut-être remarqué qu'il n'y a pas d'option "préserver les dates". Ce n'est pas un oubli. GSMMO dépend de la façon dont Gmail traite les messages envoyés via son API, et ne peut pas la contourner.

Voici la chaîne technique :

1. GSMMO lit le message depuis le fichier PST, y compris ses horodatages originaux
2. GSMMO envoie les données du message via l'API Gmail
3. Gmail reçoit le message et le range dans la boîte
4. Gmail ajoute un nouvel en-tête Received: daté du moment du transfert (la ligne gmailapi.google.com de l'exemple ci-dessus)
5. Quand la date d'origine n'est pas transmise, Gmail définit l'INTERNALDATE à l'heure du transfert
6. Le message atterrit dans Gmail avec la date du jour

Les étapes 4 et 5 sont celles qui comptent. Gmail ajoute cet en-tête à chaque message envoyé via son API, quoi que l'outil transmette, et GSMMO n'a aucun réglage pour transmettre ou garder la date d'origine. Le résultat : tous vos emails historiques semblent être arrivés aujourd'hui.

Certains administrateurs ont essayé de lancer GSMMO avec des paramètres Google Workspace spécifiques ou en ajustant les paramètres de profil GSMMO. Rien de tout cela n'affecte le comportement des dates. L'en-tête Received: est ajouté côté Google, et aucune configuration côté client ne change ça.

Scénarios GSMMO qui cassent les dates

Toutes les migrations GSMMO ne finissent pas en chaos de dates, mais la plupart si. Voici les cas concernés :

• Fichier PST vers Gmail : Les dates sont erronées. C'est le cas d'utilisation GSMMO le plus courant et le plus affecté.
• Profil Outlook vers Gmail : Les dates sont erronées. Même transfert via l'API Gmail que l'import PST.
• Exchange Online (Microsoft 365) vers Gmail via GSMMO : Les dates sont erronées. GSMMO lit depuis le serveur Exchange et envoie via l'API Gmail.
• Exchange sur site vers Gmail via GSMMO : Les dates sont erronées. Même mécanisme.
• Gmail vers Gmail (réimport d'un export PST) : Les dates sont erronées. Même si les emails originaux avaient les bonnes dates dans le PST, le réimport les retamponne.

Le schéma est clair. Chaque message envoyé via l'API Gmail reçoit un en-tête Received: daté du jour du transfert. GSMMO utilise toujours ce chemin.

Ce qui rend ça particulièrement frustrant, c'est que le rapport de migration GSMMO affiche tout comme réussi. Pas d'avertissement sur les dates, pas d'erreurs, pas de drapeaux. Il faudrait comparer manuellement les horodatages avant et après la migration pour le détecter, et la plupart des administrateurs ne font pas ça tant qu'un utilisateur ne se plaint pas.

L'impact va bien au-delà du tri

Les mauvaises dates après une migration GSMMO créent des problèmes réels qui dépassent une boîte de réception désordonnée.

Imaginez que vous êtes comptable et venez de migrer vers Google Workspace. Vous devez retrouver toute la correspondance client du T3 2024 pour une déclaration fiscale. Vous cherchez dans Gmail par plage de dates : juillet à septembre 2024. Zéro résultats. Chaque email de cette période affiche maintenant la date de migration, donc le filtre de dates de Gmail ne peut pas les trouver. Vous êtes coincé à faire défiler des milliers de messages ou à chercher par mot-clé en espérant vous souvenir des bons termes.

Pour les secteurs réglementés, c'est pire que gênent. Les horodatages d'emails servent de preuve légale. Un conseiller financier qui doit prouver avoir envoyé une divulgation avant une date de transaction ne peut pas le faire quand l'email affiche avril 2026 au lieu de février 2023. Les audits de conformité au titre du RGPD ou de la réglementation CNIL s'appuient sur des horodatages de communication précis, et de mauvaises dates signifient des audits échoués.

Et puis il y a le problème du threading. Gmail regroupe les conversations par date et sujet. Quand chaque message d'un fil affiche la même date, la vue de conversation devient confuse. Les réponses apparaissent avant le message original. Toute la structure du fil s'effondre en un tas d'emails datés identiquement.

Corriger les dates GSMMO avec Redate.io

La bonne nouvelle : cet en-tête Date: original est toujours intact dans chaque email migré. GSMMO ne modifie pas le contenu du message. La date correcte est là, elle est juste ignorée par la logique d'affichage de Gmail parce que l'INTERNALDATE et l'en-tête Received supérieur pointent vers la date de migration.

Redate.io se connecte à la boîte aux lettres Google Workspace, scanne les emails affectés par la migration GSMMO, et corrige les métadonnées de date via un moteur propriétaire d'analyse de chaîne d'en-têtes et de reconstruction de dates. Redate n'a pas besoin de savoir quel outil a fait la migration : il repère les emails dont la date affichée ne correspond pas à leur date d'origine, et les corrige sans altérer le contenu du message, les pièces jointes ou le threading.

Chaque email corrigé passe par une vérification individuelle : intégrité du message, préservation des pièces jointes, mapping des labels et cohérence du threading. Les originaux restent dans un dossier visible Redate.io - Originals jusqu'à ce que vous les supprimiez vous-même.

Pourriez-vous corriger ça vous-même avec un script ? Comprendre le problème, c'est une chose. Corriger 12 000 emails sans casser les signatures S/MIME, corrompre les parties MIME imbriquées ou mutiler les en-têtes encodés RFC 2047 sur une boîte de production, c'est tout autre chose. Comment gérez-vous l'email avec une pièce jointe de 38 Mo et une frontière MIME corrompue que GSMMO a importée mais a peine tenu ensemble ? Comment vérifier que chaque message est passé intact ? Un script qui fonctionne sur 20 messages de test en labo ne survivra pas à une vraie boîte avec 8 ans de correspondance.

Guides de correction par plateforme pour GSMMO

Puisque GSMMO migre spécifiquement vers Google Workspace, la correction se fait au niveau Gmail. Mais les emails affectés sont visibles dans chaque client connecté à ce compte Gmail :

• Corriger les dates de migration GSMMO dans Gmail
• Corriger les dates de migration GSMMO dans Outlook (connecté à Google Workspace)
• Corriger les dates de migration GSMMO dans Apple Mail

Migration effectuée il y a des mois ? L'en-tête Date original ne se dégrade pas dans le temps. Redate.io peut corriger les emails affectés par GSMMO que la migration ait eu lieu la semaine dernière ou il y a trois ans.

GSMMO a laissé vos emails avec des mauvaises dates ? Lancez un scan gratuit pour voir le nombre exact d'emails affectés et le coût de la correction, avant de vous engager.