Nouvel Outlook : dates fausses après migration, causes réelles

Deux Outlook, deux comportements face aux mêmes emails

Si vous avez migré des boîtes mail vers Microsoft 365 récemment et que certains utilisateurs se plaignent que tous leurs emails anciens affichent la même date (celle de la migration), vous avez peut-être remarqué quelque chose d'étrange : les utilisateurs sous l'Outlook classique voient parfois la bonne date dans le volet de lecture, alors que ceux sur le nouvel Outlook pour Windows voient systématiquement la date de migration. Même boîte. Mêmes emails. Résultats différents.

Ce n'est pas un bug au sens strict. C'est une décision d'architecture qui a des conséquences directes sur la façon dont les dates s'affichent après une migration IMAP. Pour comprendre ce qui se passe, il faut entrer dans les détails des en-têtes email et du protocole IMAP, ce qui n'est pas exactement de la lecture légère mais qui permet de comprendre pourquoi aucune manipulation côté client ne suffit à régler le problème.

L'INTERNALDATE IMAP : le vrai coupable

Quand un email est stocké sur un serveur IMAP, il possède deux types de dates qui coexistent et ne se confondent pas.

La première est l'en-tête Date:, défini par la RFC 2822. C'est la date écrite dans le message lui-même, celle que l'expéditeur a mise au moment d'envoyer l'email. Elle fait partie du corps du message et ne change jamais, quel que soit le chemin que l'email emprunte ensuite.

La deuxième est l'INTERNALDATE, une métadonnée gérée par le serveur IMAP, extérieure au message. C'est la date à laquelle le serveur a enregistré le message. Lors d'une migration normale, les outils sérieux préservent l'INTERNALDATE originale. Mais lors d'une migration mal configurée, ou avec certains outils qui ne gèrent pas cette métadonnée correctement, l'INTERNALDATE est réinitialisée à la date du jour de la migration. Le résultat : tous les emails migrés portent la même date de réception aux yeux du serveur.

(D'ailleurs, si vous avez déjà lu les logs d'imapsync ou de MigrationWiz, vous savez qu'il existe des options spécifiques pour tenter de préserver l'INTERNALDATE. Ces options ne fonctionnent pas toujours, et certains serveurs de destination refusent de les honorer.)

Outlook classique : comment il lit les dates

L'Outlook classique, c'est-à-dire les versions COM installées localement (Outlook 2016, 2019, 2021 et le client de bureau Microsoft 365 Apps), utilise un mécanisme un peu plus complexe pour déterminer quelle date afficher dans la liste des messages.

Pour les emails dans le dossier Envoyés, il s'appuie sur l'en-tête Date:. Pour les emails reçus, il utilise en priorité l'INTERNALDATE du serveur, mais dans certains contextes (notamment quand le cache OST est impliqué ou lors du premier affichage dans le volet de lecture), il peut également lire la chaîne des en-têtes Received: pour reconstruire une date d'origine approximative.

C'est pour cette raison qu'on observe ce comportement incohérent : l'Outlook classique peut parfois afficher la bonne date dans le volet de lecture, parce qu'il lit l'en-tête Date: original du message pour l'aperçu détaillé, même si la liste des emails elle-même utilise l'INTERNALDATE corrompue. Mais attention, ce n'est pas fiable, et ça ne corrige rien. Le tri reste cassé, les recherches par date restent faussées.

Le nouvel Outlook : une architecture radicalement différente

Le nouvel Outlook pour Windows, déployé progressivement depuis fin 2023, n'est plus une application COM. C'est essentiellement une Progressive Web App (PWA) basée sur la même base de code qu'Outlook sur le web (OWA). Cette refonte a des implications profondes.

Le nouvel Outlook délègue entièrement l'affichage des dates à l'API Microsoft 365. Il ne lit pas les en-têtes Received:, ne creuse pas dans la chaîne des en-têtes pour retrouver une date d'origine, et ne fait aucune tentative de reconstruction côté client. Il affiche simplement ce que le serveur lui retourne : l'INTERNALDATE.

Résultat : si l'INTERNALDATE a été corrompue lors de la migration, le nouvel Outlook n'a aucune hésitation. Il affiche la date de migration pour chaque email concerné, sans exception, sans nuance. C'est un comportement plus cohérent et plus prévisible que celui de l'Outlook classique, mais il rend le problème de migration immédiatement visible et impossible à ignorer.

Un admin qui migre 300 boîtes un vendredi soir va découvrir le lundi matin que tous les utilisateurs sur le nouvel Outlook voient leurs archives entières datées du week-end dernier. Les tickets arrivent vite.

Pourquoi aucun contournement côté client ne fonctionne

Beaucoup d'admins essaient des solutions côté client avant de comprendre que le problème est dans les données serveur. Voici les tentatives classiques, et pourquoi elles échouent.

Trier par "Date d'envoi" au lieu de "Date de réception"

Le tri par date d'envoi dans Outlook s'appuie sur l'en-tête Date: du message, qui lui est intact. Donc oui, ce tri peut fonctionner. Mais c'est un pansement, pas une solution. Les recherches par date restent cassées. Les règles basées sur la date restent inutilisables. Et surtout, l'utilisateur doit reconfigurer manuellement chaque dossier, chaque boîte. Sur 300 boîtes, c'est irréaliste. Le tri par date d'envoi n'est pas une solution, et les utilisateurs finaux ne comprennent pas pourquoi on leur demande de changer leurs habitudes.

Vider le cache Outlook ou recréer le profil

Ça ne touche pas l'INTERNALDATE côté serveur. Après recréation du profil, Outlook re-synchronise les emails depuis le serveur et récupère exactement les mêmes métadonnées corrompues. Le cache n'est pas le problème.

Utiliser OWA à la place

OWA et le nouvel Outlook partagent la même base de données. Si l'INTERNALDATE est corrompue sur le serveur Exchange Online, OWA affiche exactement la même mauvaise date. Changer de client ne change pas les données.

Le problème est sur le serveur, dans les métadonnées de chaque message. Aucune action côté client ne peut corriger des données stockées côté serveur.

Le piège des en-têtes Received : pourquoi ils compliquent tout

Quand un outil de migration copie un email d'un serveur à un autre via IMAP, le serveur de destination ajoute automatiquement un en-tête Received: en haut de la chaîne, avec la date et l'heure de l'insertion. C'est le comportement normal des serveurs SMTP et IMAP conformes aux RFC.

Ces en-têtes s'accumulent dans l'ordre inverse du chemin parcouru par l'email. Le plus récent est en haut. Certains clients mail lisent le premier Received: pour estimer la date de réception, ce qui donne la date de migration au lieu de la date originale.

Correction : ce comportement n'est pas propre à un seul outil. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, et même une copie manuelle IMAP entre deux clients Thunderbird produisent tous ce résultat. L'en-tête Date: original reste intact dans le message. C'est précisément ce qui rend la correction possible techniquement. Mais l'INTERNALDATE, elle, est une métadonnée distincte gérée par le serveur et ne peut pas être corrigée en manipulant simplement les en-têtes du message côté client.

Pour aller plus loin sur ce mécanisme, l'article sur l'INTERNALDATE IMAP et les dates erronées détaille comment cette métadonnée est gérée selon les serveurs.

Quels outils de migration causent ce problème sur Microsoft 365

La question revient souvent : est-ce que tous les outils de migration provoquent ce problème ?

La réponse courte, c'est que ça dépend de la configuration et de la plateforme de destination. Sur Exchange Online / Microsoft 365, le serveur est particulièrement strict sur la gestion de l'INTERNALDATE. Même des outils qui tentent de la préserver échouent parfois, car l'API Graph et EWS (Exchange Web Services) ont des comportements différents selon le chemin d'insertion utilisé.

BitTitan MigrationWiz est l'un des outils les plus répandus pour les migrations vers Microsoft 365, et c'est aussi l'un de ceux dont les problèmes de dates sont les mieux documentés. La page dédiée corriger les dates BitTitan dans Microsoft 365 couvre les configurations spécifiques à surveiller. CloudM et imapsync ont leurs propres particularités, respectivement documentées sur corriger les dates CloudM dans Microsoft 365 et corriger les dates imapsync dans Microsoft 365.

Ce qui est commun à tous ces outils : l'en-tête Date: original survit à la migration. C'est la base sur laquelle une correction est possible.

Pourquoi un script maison est une mauvaise idée ici

Comprendre le problème donne parfois l'illusion que la solution est simple. Elle ne l'est pas, pas à l'échelle d'une production.

Modifier les métadonnées d'emails stockés sur Exchange Online n'est pas trivial. L'API Graph de Microsoft impose des limites de taux strictes (l'erreur 429 Too Many Requests sur un batch de nuit, ça arrive vite). La gestion des emails signés S/MIME ou chiffrés PGP nécessite une attention particulière pour ne pas invalider les signatures. Les structures multipart avec des pièces jointes volumineuses ajoutent des contraintes sur les timeouts réseau. Et surtout : comment vérifier, email par email, que la correction a bien fonctionné sans altérer le contenu ou les pièces jointes ?

Un script qui tourne bien sur 50 emails de test ne se comportera pas de la même façon sur une boîte de 40000 messages avec 8 ans d'historique. La probabilité qu'un cas limite casse quelque chose augmente avec chaque millier de messages supplémentaires. Et sans mécanisme de rollback, une erreur à mi-parcours laisse la boîte dans un état incohérent.

Voir aussi : corriger les dates d'emails après migration Microsoft 365 pour un aperçu complet des options disponibles.

Ce que Redate.io fait concrètement

Redate.io ouvre la boîte mail Microsoft 365 grâce à une simple connexion avec le compte Microsoft de l'utilisateur, sans mot de passe stocké, puis analyse les emails avec des dates incorrectes gratuitement, puis applique un moteur de correction propriétaire sur les messages identifiés. Le pipeline d'analyse multi-étapes réalise une correspondance sur des centaines de signatures d'outils de migration connus, une validation de conformité RFC, et une analyse de la chaîne d'en-têtes pour reconstruire les métadonnées de date correctes.

Chaque email corrigé est vérifié individuellement. Les messages originaux sont conservés dans un dossier de sauvegarde visible, dans la boîte mail elle-même, jusqu'à ce que l'utilisateur les supprime lui-même. Le modèle tarifaire est un paiement unique par boîte mail, sans abonnement.

Le nouvel Outlook affiche alors les bonnes dates, parce que les données serveur sont corrigées, pas masquées.

Vous avez des boîtes affectées sur le nouvel Outlook ? Lancez un scan gratuit sur Redate.io pour identifier exactement combien d'emails sont concernés avant de décider de la marche à suivre.