Recréer un profil Outlook : pourquoi les dates changent

Le geste de dépannage qui provoque des dates erronées

Un utilisateur se plaint qu'Outlook ne se synchronise plus. Les emails n'arrivent pas, le dossier Envoyé ne se met pas à jour, la roue tourne indéfiniment. Le technicien diagnostique un profil corrompu, supprime le fichier OST, recrée le profil Outlook depuis zéro. Résultat : Outlook se reconnecte, les emails réapparaissent, tout semble fonctionner.

Jusqu'au lendemain matin, quand l'utilisateur ouvre sa boîte et réalise que 8 ans de correspondance affiche la même date : aujourd'hui.

C'est exactement le même symptôme qu'une migration IMAP ratée. Et pour les mêmes raisons.

Ce qui se passe techniquement

Pour comprendre pourquoi recréer un profil produit ce résultat, il faut revenir sur une distinction que la plupart des techniciens connaissent mal : la différence entre l'en-tête Date: d'un email et son INTERNALDATE IMAP.

Chaque email contient dans ses en-têtes RFC 2822 un champ Date: qui indique quand le message a été envoyé. Ce champ est écrit par le client de messagerie de l'expéditeur au moment de l'envoi, puis transporté tel quel à travers tous les serveurs jusqu'à votre boîte. Il ne change jamais. Un email envoyé le 14 mars 2019 à 09h32 aura toujours ce champ Date: intact, peu importe ce qui se passe ensuite.

L'INTERNALDATE IMAP, c'est autre chose. C'est une métadonnée gérée par le serveur de messagerie, indépendante du contenu du message. Elle indique quand le message a été "déposé" dans la boîte. En conditions normales, quand un email arrive via SMTP, le serveur enregistre l'heure de réception comme INTERNALDATE. Un email reçu le 14 mars 2019 aura donc un INTERNALDATE cohérent avec sa date d'envoi.

Outlook, par défaut, trie et affiche les emails selon l'INTERNALDATE transmis par le serveur IMAP, pas selon le champ Date: du message lui-même. (D'ailleurs, si vous avez déjà ouvert les propriétés complètes d'un email dans Outlook pour voir ses en-têtes bruts, vous savez que c'est rarement une lecture de plage.)

Ce que déclenche la suppression du fichier OST

Quand Outlook utilise un compte IMAP, il maintient une base de données locale : le fichier OST (Offline Storage Table). Ce fichier est un miroir local des emails stockés sur le serveur, avec leurs métadonnées, leurs états de lecture, leurs catégories, etc.

Supprimer le fichier OST revient à effacer ce miroir local. Outlook doit donc tout retélécharger depuis le serveur IMAP.

Le problème ? Quand Outlook retélécharge un message via IMAP, il utilise la commande FETCH pour récupérer le contenu. Mais il n'utilise pas systématiquement la commande FETCH INTERNALDATE pour récupérer et conserver la date IMAP originale. Dans certaines configurations et versions d'Outlook, le client reconstruit son index local en utilisant la date à laquelle il a retéléchargé le message plutôt que l'INTERNALDATE stocké sur le serveur.

Et là, tous les emails de la boîte se retrouvent datés du jour du rechargement.

Toutes les versions d'Outlook ne se comportent pas pareil

Correction : ce comportement ne touche pas toutes les versions d'Outlook de manière identique, et c'est là que les choses deviennent complexes à diagnostiquer.

Outlook 2016 et 2019 en mode IMAP ont des comportements documentés de reconstruction d'index incorrecte après suppression du cache. Le nouvel Outlook (basé sur le web, déployé progressivement depuis fin 2023) gère le cache différemment et peut produire des résultats variables. Outlook via Exchange/Microsoft 365 avec un compte configuré en mode Exchange est moins exposé à ce problème spécifique, car le protocole MAPI/Exchange gère la synchronisation différemment d'IMAP.

Mais si votre utilisateur est sur un compte IMAP configuré dans Outlook classique, et qu'un technicien a supprimé le fichier OST ou recréé le profil : le risque est réel.

Comment distinguer ce cas d'une vraie migration

Un admin IT qui reçoit des tickets "mes dates sont fausses" après une recréation de profil peut penser à tort qu'il s'agit d'un problème de migration. Voici comment distinguer les deux cas.

Le cas d'une migration IMAP

Lors d'une migration IMAP (BitTitan, CloudM, imapsync, etc.), l'outil de migration copie les emails d'un serveur à l'autre. Pour chaque message copié, il crée une nouvelle entrée sur le serveur de destination via la commande IMAP APPEND. Si l'outil ne spécifie pas explicitement l'INTERNALDATE d'origine dans cette commande, le serveur de destination enregistre l'heure actuelle comme INTERNALDATE. En parallèle, certains outils ajoutent aussi un en-tête Received: avec la date de migration, ce qui aggrave le problème dans certains clients. Vous pouvez lire le détail de ce mécanisme dans notre article sur IMAP INTERNALDATE et les dates erronées.

Le cas de la recréation de profil

Ici, les emails sont toujours sur le même serveur, avec les mêmes INTERNALDATE d'origine. Rien n'a bougé côté serveur. C'est uniquement le cache local d'Outlook qui a été reconstruit avec des dates incorrectes. Le symptôme visible est identique (tous les emails affichent la même date récente), mais l'origine est différente.

Pour confirmer : connectez-vous à la boîte via webmail (Gmail, Outlook.com, ou l'interface webmail de votre hébergeur). Si les dates affichées en webmail sont correctes, le problème est purement local à Outlook. Si les dates sont aussi incorrectes en webmail, le problème est côté serveur (migration ou modification des INTERNALDATE sur le serveur lui-même).

Pourquoi les dates d'origine restent récupérables

Bonne nouvelle : dans les deux cas (migration ou recréation de profil), les dates originales ne sont pas perdues.

L'en-tête Date: RFC 2822 est une partie intégrante du message. Il est aussi immuable que le corps du texte ou les pièces jointes. Un email envoyé en 2017 contient dans son texte brut quelque chose comme :

Date: Mon, 12 Jun 2017 14:23:41 +0200

Cette ligne est présente dans le message stocké sur le serveur. Elle n'a pas été modifiée. Ce qu'Outlook affiche (incorrectement) est une métadonnée externe au contenu du message.

C'est ce qui rend la correction possible. Le moteur de Redate.io analyse la chaîne d'en-têtes de chaque message pour extraire la date d'origine réelle, puis effectue une correction ciblée des métadonnées sans altérer le contenu du message. L'INTERNALDATE visible par Outlook est reconstruit à partir de cette information authentique, toujours présente dans le message.

Le piège de la recréation "propre"

Vous venez de résoudre un problème de synchronisation pour un utilisateur. Son Outlook refonctionne, les nouveaux emails arrivent. Vous fermez le ticket.

Trois jours plus tard, l'utilisateur rappelle : il cherche un email d'un fournisseur datant de l'année dernière, mais dans Outlook tous ses emails de 2023 apparaissent comme reçus "hier". Il ne trouve rien. L'archivage automatique a peut-être classé des emails récents en les traitant comme anciens. Et son chef lui demande une conversation email de septembre 2022 pour un litige.

Ce scénario arrive régulièrement. Pas parce que le technicien a mal fait son travail, mais parce que ce comportement d'Outlook n'est pas documenté de manière visible dans les guides de dépannage standard.

Les fausses solutions qui ne résolvent rien

Trier les emails par "Date d'envoi" au lieu de "Date de réception" dans Outlook est la première chose que les utilisateurs essaient. Et ça semble fonctionner... jusqu'à ce qu'ils réalisent que le tri par date d'envoi n'est disponible que pour certains dossiers, qu'il disparaît quand on change de vue, et que d'autres applications (mobile, webmail, règles de tri automatique) continuent d'utiliser l'INTERNALDATE incorrect.

Le tri par date d'envoi n'est pas une solution. C'est un pansement qui cache le symptôme sans toucher au problème réel. Nous l'expliquons en détail dans l'article Trier par date d'envoi n'est pas une solution.

Recréer une deuxième fois le profil ? Ça ne change rien si le comportement d'Outlook reconstruit son cache avec la date courante.

Exporter puis réimporter en PST ? Attention. Un export PST depuis un Outlook avec des dates incorrectes exporte des métadonnées incorrectes. Le fichier PST contiendra les mauvaises dates. Réimporter ce fichier ne corrige rien, et peut même aggraver la situation en créant des doublons avec des dates incohérentes. Ce sujet est traité séparément dans l'article sur l'import PST et les dates qui passent au jour J.

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

Que le problème vienne d'une migration IMAP ou d'une recréation de profil Outlook, le résultat côté serveur est similaire : des emails dont les métadonnées de date sont incohérentes avec leur contenu réel.

Redate.io se connecte directement à la boîte mail (Google Workspace, Microsoft 365, ou IMAP direct), scanne l'ensemble des messages pour identifier ceux dont les métadonnées sont incorrectes, puis applique son pipeline d'analyse multi-étapes pour corriger chaque email individuellement. Chaque correction est vérifiée. Les messages originaux sont conservés dans un dossier de sauvegarde visible jusqu'à ce que vous les supprimiez vous-même.

Le processus gère les cas limites que les scripts maison ratent systématiquement : messages S/MIME signés, emails avec encodages non-ASCII dans les en-têtes (RFC 2047), structures multipart complexes, en-têtes Date: avec fuseaux horaires non standards ou malformés. Un script qui tourne correctement sur 50 emails de test dans une boîte de développement peut corrompre irrémédiablement 2000 messages en production. Il n'y a pas de rollback natif en IMAP une fois un message remplacé sans sauvegarde préalable.

Pour les cas liés à Outlook spécifiquement, la page de correction corriger les dates de copie IMAP dans Outlook détaille les étapes pour connecter votre boîte et lancer l'analyse.

Prévenir le problème lors des prochaines interventions

Si vous êtes technicien ou admin IT et que vous intervenez régulièrement sur des profils Outlook, quelques réflexes permettent d'éviter cette situation.

Avant de supprimer un fichier OST ou de recréer un profil, vérifiez les dates affichées en webmail. Si elles sont correctes, notez-le dans votre ticket. Après la recréation, connectez-vous à nouveau en webmail et comparez les dates affichées avec celles dans Outlook. Si un écart apparaît, le problème est identifié immédiatement, avant que l'utilisateur ne s'en plaigne trois jours plus tard.

Pour les migrations planifiées, la checklist migration email liste les vérifications à faire avant et après pour détecter ce type de problème dès la fin de l'opération.

Vous avez recréé un profil Outlook et les dates de votre boîte sont maintenant toutes fausses ? Lancez un scan gratuit sur Redate.io pour identifier les emails affectés et corriger les métadonnées sans toucher au contenu de vos messages.