Le problème - tous les emails affichent la même date
Après une migration IMAP, les utilisateurs ouvrent leur boîte mail et découvrent un spectacle inquiétant : chaque email affiche exactement la même date. Au lieu de la date d'envoi ou de réception d'origine, tous les messages portent la date à laquelle la migration a été effectuée. Des années de correspondance qui semblent être arrivées le même jour.
C'est un cauchemar pour les administrateurs IT. Les tickets affluent, les utilisateurs ne retrouvent plus rien par date, et l'historique chronologique de la boîte mail est, en pratique, détruit.
Ce que ça donne dans Outlook
Dans Microsoft Outlook, la colonne "Reçu" affiche la date de migration pour chaque email. Qu'un message ait été envoyé en 2018 ou en 2023, Outlook montre la même date, celle du jour où l'outil de migration a traité la boîte mail. La boîte de réception, les éléments envoyés, chaque dossier est touché. Les utilisateurs qui se fient au tri par date voient leur flux de travail complètement cassé.
Ce que ça donne dans Apple Mail
Apple Mail sur macOS et iOS se comporte de façon similaire. La date affichée à côté de chaque message reflète l'horodatage de migration plutôt que la date d'origine. Comme Apple Mail utilise les métadonnées du serveur IMAP pour déterminer les dates d'affichage, le même problème sous-jacent produit le même résultat visible. En parcourant la boîte de réception, on ne voit qu'un mur de dates identiques.
Ce que ça donne dans Gmail (interface web)
L'interface web de Gmail présente une situation légèrement différente. Le client web de Gmail utilise généralement l'en-tête "Date" de l'email lui-même, donc les messages peuvent apparaître avec la bonne date dans Gmail. Mais l'INTERNALDATE IMAP reste fausse, ce qui signifie que tout client IMAP se connectant à ce compte Gmail (Outlook, Thunderbird, Apple Mail) affichera la date de migration. Du coup, la même boîte mail semble correcte dans un client mais fausse dans un autre. Plutôt déroutant.
Pourquoi ça arrive - la cause technique
La cause profonde réside dans la façon dont les outils de migration IMAP gèrent les en-têtes d'email et dans la manière dont les clients de messagerie déterminent quelle date afficher. Comprendre cela nécessite un bref coup d'oeil au protocole IMAP et à la structure des en-têtes.
Comment les outils de migration IMAP traitent les en-têtes
Quand un email est migré d'un serveur à un autre, l'outil de migration télécharge le message brut depuis le serveur source et le téléverse vers le serveur de destination via la commande IMAP APPEND. Pendant ce processus, le protocole IMAP impose au serveur de destination d'ajouter un en-tête "Received" au message. Cet en-tête contient l'horodatage du moment où le message a été inséré dans le nouveau serveur, c'est-à-dire la date de migration.
L'en-tête "Received" qui casse tout
Les messages email contiennent généralement plusieurs en-têtes "Received", chacun ajouté par un serveur de messagerie ayant géré le message lors de sa livraison d'origine. Les clients comme Outlook déterminent la "date de réception" en lisant l'en-tête "Received" le plus récent, celui en haut de la chaîne. Quand un outil de migration ajoute un nouvel en-tête "Received" avec l'horodatage de migration, il devient le plus récent, et les clients de messagerie affichent cette date au lieu de l'originale.
Ce n'est pas un bug de l'outil de migration ni du client de messagerie. Les deux suivent correctement les standards IMAP et email. Le problème vient du fait que ces standards n'ont jamais été conçus pour la migration en masse, et l'interaction entre IMAP APPEND et la logique d'affichage des dates produit ce résultat non désiré.
INTERNALDATE vs en-tête Date
Les serveurs IMAP stockent deux valeurs de date différentes pour chaque message. L'en-tête "Date" fait partie du message email lui-même, il enregistre quand le message a été composé et envoyé à l'origine. L'INTERNALDATE est une métadonnée stockée par le serveur IMAP, représentant quand le message a été livré ou inséré dans ce serveur particulier.
Certains outils de migration tentent de préserver l'INTERNALDATE d'origine en la définissant pendant la commande APPEND. Mais même quand l'INTERNALDATE est correctement définie, l'en-tête "Received" ajouté cause toujours des problèmes dans les clients qui priorisent la date "Received" par rapport à l'INTERNALDATE.
Quels outils de migration causent ce problème ?
Presque tous les outils de migration IMAP peuvent provoquer ce problème. Le souci est inhérent au protocole IMAP, pas spécifique à un outil. Certains sont cependant plus souvent associés au problème en raison de leur utilisation répandue.
BitTitan MigrationWiz
BitTitan MigrationWiz est l'un des outils de migration commerciaux les plus populaires utilisés par les MSP et les consultants IT. MigrationWiz ajoute un en-tête "Received" contenant "mx.migrationwiz.com" pendant le processus de migration. Cet en-tête devient le plus récent dans la chaîne, causant l'affichage de la date de migration dans Outlook et autres clients IMAP. Voir les guides détaillés pour corriger les dates BitTitan dans Outlook, Microsoft 365, Google Workspace et Exchange Online.
CloudM Migrate
CloudM Migrate (anciennement Cloud Migrator) est largement utilisé pour les migrations Google Workspace. Comme les autres outils, CloudM ajoute son propre en-tête "Received" lors de l'insertion IMAP. Les emails migrés avec CloudM affichent la date de migration dans les clients qui se basent sur l'en-tête "Received". Voir les guides pour corriger les dates CloudM dans Gmail, Outlook, Google Workspace et Microsoft 365.
imapsync
imapsync est un outil open source populaire auprès des administrateurs Linux et des hébergeurs. Bien qu'imapsync tente de préserver l'INTERNALDATE, le serveur de destination ajoute quand même un en-tête "Received" lors de l'opération APPEND. La FAQ d'imapsync reconnaît cette limitation mais ne propose pas de solution intégrée pour supprimer l'en-tête ajouté après migration. Voir les guides pour corriger les dates imapsync dans Outlook, Gmail, Microsoft 365 et Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) est l'outil propre de Google pour migrer depuis Exchange ou des fichiers PST Outlook vers Google Workspace. GSMMO peut produire le même problème de date, particulièrement quand la migration implique une étape IMAP intermédiaire. Voir les guides pour corriger les dates GSMMO dans Outlook, Gmail et Apple Mail.
Exchange Admin Center (import IMAP natif)
Le centre d'administration Exchange de Microsoft inclut une fonctionnalité d'import IMAP native pour migrer vers Exchange Online (Microsoft 365). Cet outil de migration intégré ajoute des en-têtes "Received" pendant l'import, causant le même problème d'affichage de date. Voir les guides pour corriger les dates de migration Exchange IMAP dans Outlook et OWA.
Copie IMAP manuelle
Même la copie manuelle d'emails entre serveurs IMAP via un client comme Thunderbird peut produire ce problème de date. Quand un client de messagerie copie un message via IMAP, le serveur de destination le traite comme une nouvelle insertion et ajoute son propre en-tête "Received" avec l'horodatage actuel. Voir les guides pour corriger les dates de copie IMAP manuelle dans Outlook, Gmail, Thunderbird et Apple Mail.
Pourquoi les solutions de contournement habituelles ne fonctionnent pas
Face à ce problème, utilisateurs et administrateurs tentent généralement plusieurs approches avant de réaliser qu'aucune ne résout véritablement le souci.
"Triez par date d'envoi" - pourquoi ça ne suffit pas
La suggestion la plus courante est de passer du tri par date de "réception" à la date d'"envoi" dans le client de messagerie. Ça change effectivement l'ordre d'affichage, mais ça ne corrige pas les données sous-jacentes. Les résultats de recherche montrent toujours la mauvaise date. Les intégrations calendrier, les outils de conformité et les workflows automatisés qui dépendent de la date de réception continuent de dysfonctionner. Et les utilisateurs doivent penser à changer ce paramètre sur chaque appareil et dans chaque dossier.
Re-migration - coûteuse et risquée
Certains administrateurs envisagent de relancer la migration, en espérant éviter le problème de date au deuxième passage. Cette approche est coûteuse (500 à 5000 EUR selon le nombre de boîtes mail), chronophage et risquée. Une seconde migration introduit le même problème d'en-tête "Received", double le risque de perte de données et nécessite un temps d'arrêt significatif. La re-migration ne résout pas le problème de date à moins que l'outil de migration ne soit fondamentalement modifié.
Édition manuelle des en-têtes - nécessite un accès serveur
Techniquement, la correction implique de supprimer l'en-tête "Received" de migration de chaque email. Mais le faire manuellement nécessite un accès direct au serveur, une connaissance de la structure des en-têtes email et du scripting sur mesure. Pour une boîte mail de 10000 emails, l'édition manuelle est impraticable et dangereusement sujette aux erreurs. Emails signés S/MIME, messages chiffrés PGP, structures multipart avec frontières MIME imbriquées, problèmes de Content-Transfer-Encoding, en-têtes non-ASCII (RFC 2047), pièces jointes surdimensionnées : chacun de ces cas peut amener un script basique à corrompre des données de façon irréversible. Comment confirmer que 10000 emails corrigés sont tous intacts ? On ne le peut pas, sauf avec un système de vérification conçu spécifiquement pour ça.
La vraie solution - restaurer les dates originales
La bonne approche consiste à identifier les artefacts de migration dans la chaîne d'en-têtes de chaque email et à appliquer des corrections ciblées qui restaurent l'ordre chronologique d'origine dans tous les clients de messagerie. Ce n'est pas une simple édition d'en-tête. Le processus implique une validation de conformité RFC, la préservation de la structure du message et une correspondance de signatures de migration provenant d'une base de données de profils d'outils connus.
Comment Redate.io corrige ce problème
Redate.io se connecte à la boîte mail (Google Workspace, Microsoft 365 ou tout serveur IMAP) et analyse chaque email pour identifier les messages affectés par les en-têtes de migration. L'analyse est gratuite et montre exactement combien d'emails sont concernés avant tout paiement.
Pour chaque email affecté, le moteur de correction propriétaire de Redate.io fait passer le message à travers un pipeline d'analyse multi-étapes. Le moteur applique une correspondance de signatures sur des centaines de profils d'outils de migration connus, construits à partir du traitement de grands volumes de données email réelles. Il gère les problèmes d'encodage, les structures multipart, les pièces jointes en ligne et des dizaines de cas particuliers qui feraient qu'un script DIY corromprait les données (pas le genre de découverte qu'on veut faire un lundi matin). Chaque email corrigé passe par une vérification d'intégrité avant d'être finalisé. Le message original est déplacé vers un dossier visible "Redate.io - Originals" (pas supprimé) et conservé pendant 30 jours.
Le résultat ? Les emails affichent leurs dates d'origine correctes dans tous les clients. Le tri fonctionne à nouveau. L'historique chronologique de la boîte mail est restauré.
Questions fréquentes
Les dates peuvent-elles être corrigées des mois après la migration ?
Oui. L'en-tête "Date" d'origine est préservé à l'intérieur du message email indépendamment du moment où la migration a eu lieu. Redate.io peut corriger les dates des emails des semaines, des mois ou même des années après la migration. La correction fonctionne tant que les en-têtes originaux de l'email sont intacts.
La correction va-t-elle supprimer des emails ?
Non. Redate.io ne supprime jamais d'emails. Les messages originaux sont déplacés dans un dossier visible appelé "Redate.io - Originals" dans la boîte mail, où ils restent accessibles pendant 30 jours. Chaque email corrigé est vérifié par rapport à l'original avant la finalisation du processus. Si la vérification échoue pour un message, l'original reste intact.
Est-ce que ça fonctionne avec les boîtes mail partagées ?
Oui. Redate.io fonctionne avec les boîtes mail partagées dans Google Workspace et Microsoft 365. Pour les boîtes partagées, un accès de niveau administrateur est requis pour autoriser la connexion. Le processus est identique aux boîtes individuelles : analyse, correction, vérification.
Prêt à restaurer les bonnes dates ? Lancez une analyse gratuite pour découvrir combien d'emails sont affectés dans chaque boîte mail.