Import PST dans Outlook : pourquoi toutes vos dates passent au jour J

Le symptôme : tous vos emails datent d'aujourd'hui

Vous venez de terminer un import PST dans Outlook. La barre de progression est arrivée à 100 %, tout s'est bien passé. Et puis vous ouvrez la boîte de réception... et chaque email importé affiche la date d'aujourd'hui. Un message de 2019, un autre de 2021, une archive de cinq ans : tous portent la même date. Celle du jour de l'import.

Ce n'est pas un bug d'affichage. Ce n'est pas un problème de fuseau horaire. C'est un comportement parfaitement documenté, cohérent avec la façon dont IMAP gère les métadonnées de date. Mais ça reste un désastre pour quiconque a besoin de retrouver ses anciens emails par date.

PST local et IMAP : deux mondes très différents

Avant d'expliquer pourquoi les dates cassent, il faut comprendre ce qu'est un fichier PST du point de vue de la gestion des dates.

Un fichier PST (Personal Storage Table) est un format propriétaire Microsoft. Il stocke les emails avec leurs métadonnées complètes : date d'envoi, date de réception, pièces jointes, catégories, indicateurs de lecture. Ces métadonnées sont gérées directement par Outlook, en dehors de tout protocole de messagerie. Quand vous consultez un PST dans Outlook sans connexion à un serveur, les dates affichées proviennent directement des champs internes du fichier PST. Jusque-là, tout va bien.

Le problème apparaît quand vous tentez de transférer ce contenu vers une boîte mail hébergée sur un serveur IMAP, qu'il s'agisse de Microsoft 365, Google Workspace ou n'importe quel hébergeur classique. Là, vous quittez le monde PST pour entrer dans le monde IMAP, et les règles changent radicalement.

IMAP APPEND et l'INTERNALDATE : le coeur du problème

En IMAP, chaque message stocké sur le serveur possède deux types de données de date :

• L'en-tête Date: (RFC 2822), qui fait partie du contenu du message lui-même. C'est la date inscrite dans le message par l'expéditeur.
• L'INTERNALDATE, qui est une métadonnée gérée par le serveur IMAP. Elle représente le moment où le message a été déposé sur le serveur. C'est cette valeur qu'Outlook utilise pour trier les messages dans la vue "Date de réception".

(D'ailleurs, si vous avez déjà essayé de lire les en-têtes bruts d'un email, vous savez que ce n'est pas exactement de la lecture de plage. Mais c'est là que tout se passe.)

Quand un email arrive normalement sur votre serveur, le serveur de messagerie définit automatiquement l'INTERNALDATE au moment exact de la réception. Résultat : la date affichée dans Outlook correspond bien à quand vous avez reçu le message.

Quand Outlook importe un fichier PST vers une boîte IMAP, il utilise la commande IMAP APPEND pour envoyer chaque message au serveur. Le standard IMAP permet de passer un INTERNALDATE explicite lors d'un APPEND. Mais Outlook ne le fait pas. Il envoie les messages sans spécifier d'INTERNALDATE. Le serveur IMAP, en l'absence d'instruction, applique alors sa règle par défaut : l'INTERNALDATE est défini à l'heure actuelle, c'est-à-dire le moment de l'import.

Résultat : 8000 emails importés, 8000 emails avec la date d'aujourd'hui.

Pourquoi Outlook se comporte ainsi

Ce n'est pas un oubli de Microsoft. C'est un choix d'implémentation qui a probablement semblé raisonnable à l'époque : dans le cas d'usage originel de l'import PST, l'utilisateur archive des messages localement et les "importe" dans sa boîte courante. La date pertinente pour le tri est alors la date de réception originale... mais Microsoft a choisi de ne pas propager l'INTERNALDATE lors de l'opération d'import.

Pour être précis, ce comportement concerne l'import PST via l'assistant natif d'Outlook (Fichier > Ouvrir et exporter > Importer/Exporter). D'autres méthodes d'import, comme certains outils tiers ou des migrations via le Centre d'administration Exchange, peuvent se comporter différemment selon leur implémentation de IMAP APPEND.

Ce comportement est connu et documenté sur les forums Microsoft depuis des années. Il n'a pas changé avec Outlook 2016, ni avec Outlook 2019, ni avec les versions Microsoft 365 actuelles. Un utilisateur qui importe un PST aujourd'hui rencontrera exactement le même problème qu'en 2015.

En quoi c'est différent d'une migration IMAP classique

C'est là que ça devient intéressant, parce que l'import PST produit un résultat similaire à une migration IMAP classique avec des dates cassées, mais par un mécanisme différent.

Dans une migration IMAP typique, par exemple avec BitTitan MigrationWiz ou imapsync, les emails passent d'un serveur IMAP source vers un serveur IMAP destination. L'outil de migration récupère les messages et les réinjecte via IMAP APPEND. Certains outils préservent correctement l'INTERNALDATE, d'autres non. Mais dans tous les cas, les messages ont déjà un en-tête Received: avec la date de migration ajouté au passage, ce qui peut perturber l'affichage dans Outlook indépendamment de l'INTERNALDATE.

Avec un import PST, le mécanisme est plus simple : il n'y a pas d'en-tête Received: de migration ajouté (les fichiers PST ne transitent pas par un serveur de messagerie intermédiaire), mais l'INTERNALDATE n'est simplement jamais défini à la valeur correcte. Le résultat visible est identique, la cause sous-jacente est légèrement différente.

Cette distinction a une conséquence directe sur la correction : l'approche à adopter n'est pas tout à fait la même selon qu'on traite une migration IMAP ou un import PST. Voir aussi pourquoi l'INTERNALDATE cause des dates cassées pour une explication détaillée des deux cas.

Pourquoi les options de vue Outlook ne corrigent rien

La réaction habituelle quand on découvre le problème, c'est de fouiller dans les paramètres d'Outlook. Et il y a effectivement un paramètre qui semble prometteur : la possibilité de trier les emails par "Date" plutôt que par "Date de réception".

Le tri par date d'envoi n'est pas une solution. C'est un pansement.

Voici pourquoi : même si vous changez le tri pour afficher la colonne "Date" (qui correspond à l'en-tête Date: du message, donc la date originale), plusieurs problèmes persistent :

• La recherche Outlook indexe sur l'INTERNALDATE. Une recherche "emails de janvier 2020" ne retournera pas vos emails importés de janvier 2020, parce que leur INTERNALDATE dit qu'ils datent du jour de l'import.
• Les dossiers "Aujourd'hui", "Cette semaine", "Ce mois-ci" dans l'interface Outlook sont basés sur l'INTERNALDATE, pas sur l'en-tête Date:.
• Dans les interfaces web (Outlook Web App, Gmail) et sur les clients mobiles, la date affichée et le comportement de tri dépendent presque toujours de l'INTERNALDATE serveur.
• Les règles et filtres automatiques appliqués à la date de réception ne fonctionneront pas correctement.

Bref, changer la vue résout l'affichage pour un utilisateur spécifique, sur un client spécifique, dans une configuration spécifique. Ça ne corrige pas le problème à la source.

La re-synchronisation OST ne sert à rien non plus

Autre tentative classique : vider le cache OST et forcer une re-synchronisation complète depuis le serveur. L'idée est que le problème vient peut-être du cache local d'Outlook, pas du serveur.

Mauvaise piste. Le fichier OST est un cache local qui reflète l'état du serveur IMAP. Si l'INTERNALDATE est erroné sur le serveur, il sera erroné dans l'OST après resynchronisation. Supprimer l'OST ne change rien aux données stockées sur le serveur Exchange Online ou Google Workspace. C'est le serveur qui fait autorité.

La seule façon de corriger les dates, c'est de corriger les métadonnées directement côté serveur, message par message. Et c'est précisément là que ça devient compliqué à faire manuellement.

Le problème d'échelle : 1 email, c'est trivial. 15000, c'est une autre histoire

Techniquement, si on comprend le problème, on pourrait imaginer écrire un script qui parcourt la boîte, lit l'en-tête Date: de chaque message, et corrige l'INTERNALDATE en conséquence. Comprendre le problème est une chose. Le corriger sur 15000 emails sans en perdre un seul, c'en est une autre.

Quelques réalités de terrain :

• Les API Microsoft Graph et Gmail imposent des limites de taux (rate limits). Un script naïf va déclencher des erreurs 429 Too Many Requests, interrompre son exécution au milieu d'une correction, et vous laisser avec une boîte partiellement corrigée, sans savoir quels emails ont été traités et lesquels ne l'ont pas été.
• Certains emails dans un PST peuvent avoir des en-têtes Date: malformés ou manquants. Un script sans gestion de ces cas limites peut corrompre ces messages ou les sauter silencieusement.
• Les emails signés (S/MIME) ou chiffrés (PGP) ont des contraintes d'intégrité supplémentaires. Modifier leurs métadonnées sans précaution peut invalider la signature cryptographique.
• Les structures multipart/alternative avec des frontières MIME complexes réagissent parfois de façon imprévisible aux opérations de modification.
• Aucun mécanisme de rollback. Si quelque chose tourne mal au milieu du traitement, comment revenir à l'état initial ?

Un script qui fonctionne sur 10 emails de test ne fonctionnera pas sur une boîte de production de 50000 messages. L'année dernière, un client avec une archive PST de 40 Go a essayé de corriger ça avec un script Python récupéré sur Stack Overflow. Résultat : 3000 emails en double, 200 messages avec des pièces jointes inaccessibles, et deux semaines de nettoyage manuel.

Ce que fait Redate.io dans ce cas précis

Redate.io analyse les métadonnées de chaque message dans la boîte cible, identifie les emails dont les dates sont incorrectes (y compris ceux issus d'un import PST), et applique une correction via son moteur propriétaire. Le pipeline d'analyse multi-étapes compare la chaîne d'en-têtes de chaque message, extrait la date originale avec validation de conformité RFC, et procède à 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 dans un dossier de sauvegarde visible pendant 30 jours avant toute modification définitive. La correction fonctionne sur les trois plateformes principales : Microsoft 365 (via Azure AD), Google Workspace (via délégation de domaine), et IMAP direct pour les hébergeurs classiques.

Le scan initial est gratuit. Il permet de voir exactement combien d'emails sont affectés et quelle est la distribution des dates incorrectes, avant de décider quoi que ce soit.

Voir aussi :

• Corriger les dates d'emails après migration Microsoft 365
• Outlook : date reçue migration IMAP vs date envoyée
• Peut-on corriger les dates des emails après migration ?

Votre import PST a écrasé toutes les dates de vos emails ? Scannez votre boîte gratuitement sur Redate.io pour mesurer l'étendue du problème avant d'agir.