Le problème de dates après migration Google Workspace
Les organisations qui migrent vers Google Workspace font souvent une découverte désagréable : tous les emails de toutes les boîtes aux lettres affichent la mauvaise date. Au lieu de la date d'envoi ou de réception d'origine, chaque message affiche la date à laquelle la migration a été effectuée. Peu importe que l'organisation ait migré depuis Microsoft Exchange, Office 365, Zimbra, Lotus Notes ou un autre serveur IMAP. Des milliers d'emails, tous estampillés avec une seule et même date.
Et ce n'est pas spécifique à un outil de migration en particulier. Le problème se produit avec BitTitan MigrationWiz, CloudM Migrate, GSMMO, imapsync, et tous les autres outils qui insèrent des emails dans Google Workspace via IMAP ou l'API Gmail. La cause est liée à un mécanisme fondamental du traitement des messages par les serveurs de messagerie.
Pour un guide spécifique à l'outil GSMMO (Google Workspace Migration for Microsoft Outlook), consultez l'article dédié à GSMMO.
Parcours de migration courants vers Google Workspace
Depuis Microsoft Exchange (sur site)
Les organisations qui opèrent des serveurs Exchange sur site (2010, 2013, 2016 ou 2019) migrent vers Google Workspace pour réduire les coûts d'infrastructure et adopter un modèle cloud. Ces migrations utilisent généralement CloudM, BitTitan MigrationWiz ou GSMMO. L'outil de migration se connecte à Exchange, télécharge chaque email et le charge dans la boîte Google Workspace de l'utilisateur. Chaque email chargé reçoit un nouvel en-tête "Received" avec l'horodatage de la migration.
Depuis Microsoft 365 (Office 365)
Les migrations de Microsoft 365 vers Google Workspace sont fréquentes lorsque les organisations changent d'écosystème. BitTitan MigrationWiz et CloudM sont les outils les plus populaires pour ce type de migration. Le processus extrait les emails d'Exchange Online et les inséré dans Google Workspace. Le même problème d'en-tête "Received" s'applique : chaque email migré affiche la date de migration.
Depuis d'autres serveurs IMAP
Les migrations depuis Zimbra, Zoho, un hébergement cPanel, Dovecot, Courier et d'autres serveurs IMAP vers Google Workspace utilisent des outils comme imapsync, CloudM ou des scripts personnalisés. La destination (Google Workspace) ajoute un en-tête "Received" lors de l'opération d'insertion, quelle que soit la plateforme source. Même les migrations depuis un autre tenant Google Workspace produisent le même problème.
Pourquoi les dates sont fausses dans Google Workspace
L'interface web Gmail vs. les clients IMAP
Google Workspace présente une situation particulière. L'interface web de Gmail utilise généralement l'en-tête "Date" de l'email pour afficher la date du message, ce qui signifie que les emails apparaissent souvent avec la bonne date quand on les consulte via l'interface web. En revanche, quand la même boîte est accédée via un client IMAP (Outlook, Apple Mail, Thunderbird), le client lit l'en-tête "Received" le plus récent et affiche la date de migration.
Cette différence créé une confusion considérable. Un administrateur qui teste la migration dans l'interface web de Gmail voit des dates correctes et en conclut que la migration est réussie. Mais quand les utilisateurs connectent Outlook à leur compte Google Workspace, ils signalent que chaque email à la mauvaise date. Le problème existe bien sur le serveur (les en-têtes contiennent l'horodatage de migration) mais il ne devient visible que dans certains clients. Combien d'administrateurs ont clôturé un projet de migration en pensant que tout allait bien, pour se retrouver submergés de tickets le lundi suivant ?
Le facteur IMAP INTERNALDATE
Google Workspace stocké un INTERNALDATE pour chaque email, défini lors du processus d'insertion. Certains outils de migration définissent correctement cette valeur à la date d'origine, d'autres la laissent à la date de migration. Mais même quand l'INTERNALDATE est correct, les clients IMAP qui privilégient les en-têtes "Received" (comme Outlook) affichent quand même la mauvaise date. La correction complète nécessite à la fois la suppression de l'en-tête "Received" de migration et la vérification que l'INTERNALDATE est correctement défini. Pour une explication technique détaillée, voir pourquoi les emails affichent de mauvaises dates après migration IMAP.
Les options d'administration Google Workspace (qui ne fonctionnent pas)
La console d'administration Google
La console d'administration Google offre des contrôles étendus pour la gestion de Google Workspace, mais elle n'inclut aucune fonctionnalité pour corriger les dates des emails après migration. Pas d'outil d'édition d'en-têtes en masse. Pas d'utilitaire de correction de dates. Pas de moyen de modifier l'INTERNALDATE des emails existants via l'interface d'administration.
Google Apps Script
Google Apps Script peut automatiser de nombreuses opérations Gmail, mais il ne peut pas modifier les en-têtes bruts des emails. Les services GmailApp et Gmail API exposés via Apps Script permettent de lire les messages, changer les libellés et modifier les metadonnées, mais ils ne prennent pas en charge le remplacement du contenu RFC 2822 brut d'un message. Du coup, la correction nécessite de travailler à un niveau bien plus profond que ce que Apps Script expose.
Service de migration de données Google
Le service de migration de données de Google (disponible dans la console d'administration) est conçu pour migrer des emails vers Google Workspace, pas pour corriger les en-têtes après migration. Lancer une seconde migration avec cet outil ajouterait un en-tête "Received" supplémentaire, aggravant le problème.
Corriger les dates Google Workspace avec Redate.io
Fonctionnement de la délégation d'administration
Redate.io utilise la fonctionnalité de délégation à l'échelle du domaine de Google Workspace pour accéder aux boîtes aux lettres. L'administrateur créé un compte de service dans la Google Cloud Console, lui accordé les portées API Gmail nécessaires et active la délégation à l'échelle du domaine. Cela permet à Redate.io de traiter n'importe quelle boîte aux lettres de l'organisation sans nécessiter les identifiants individuels des utilisateurs.
La configuration de la délégation prend environ 10 minutes et suit le même processus que les autres outils de migration et de gestion Google Workspace. Une fois configurée, l'administrateur peut analyser et corriger n'importe quel nombre de boîtes depuis le tableau de bord Redate.io.
Mise en route
Créer un compte de service. Dans la Google Cloud Console, crééz un nouveau projet (ou utilisez un projet existant), activez l'API Gmail et crééz un compte de service avec la délégation à l'échelle du domaine activée.
Accorder les portées API. Dans la console d'administration Google Workspace, naviguez vers Sécurité, puis Contrôles API, puis Delegation à l'échelle du domaine. Ajoutez l'ID client du compte de service et accordéz les portées API Gmail requises par Redate.io.
Connecter dans Redate.io. Connectez-vous à Redate.io, sélectionnez "Google Workspace" comme plateforme et téléchargez le fichier de clé JSON du compte de service. Redate.io valide la connexion et liste les boîtes disponibles.
Analyser les boîtes. Sélectionnez les boîtes à analyser (ou analysez toutes les boîtes). L'analyse gratuite identifié le nombre d'emails avec des dates incorrectes dans chaque boîte. Aucun paiement n'est requis pour l'analyse.
Corriger. Examinez les résultats de l'analyse, choisissez une formule et lancez la correction. Le moteur de correction propriétaire de Redate.io traité chaque boîte en passant chaque email dans un pipeline d'analyse multi-étapes qui gère les problèmes d'encodage, les structures de messages multipart, les signatures numériques et des dizaines de cas particuliers qu'un script artisanal corromprait. La progression est visible en temps réel. Les messages originaux sont conservés dans un libellé "Redate.io - Originals" pendant 30 jours.
Après la correction
Une fois la correction terminée par Redate.io, les emails affichent la bonne date dans tous les clients : Gmail web, Outlook, Apple Mail, Thunderbird et toute autre application connectée en IMAP. La correction est permanente. Aucune maintenance continue ou abonnement n'est nécessaire. Les utilisateurs peuvent trier par date, rechercher par plage de dates et utiliser les outils de conformité en ayant confiance dans l'exactitude des horodatages. La boîte fonctionne comme elle aurait du fonctionner des le premier jour.
Guides spécifiques par outil pour Google Workspace
Pour des instructions détaillées basées sur l'outil de migration spécifique utilise, consultez ces guides :
- Corriger les dates BitTitan MigrationWiz dans Google Workspace
- Corriger les dates de migration CloudM dans Google Workspace
Migration vers Google Workspace et tous les emails affichent la mauvaise date ? Zazenite brezplacno analizo avec Redate.io pour voir combien d'emails sont concernés dans toutes les boîtes et restauréz les dates correctes.