Passage POP vers IMAP : vos anciens mails datent d'aujourd'hui

Le scénario classique du lundi matin

Vous venez de basculer votre compte email de POP3 vers IMAP. La configuration était simple, votre hébergeur vous a guidé, tout s'est bien passé. Jusqu'à ce que vous rouvriez votre boîte de réception. Vos emails de 2019, 2021, vos archives de l'année dernière... tous affichent la même date : aujourd'hui. Parfois même la même heure, à quelques secondes près.

Ce n'est pas un bug de votre client mail. Ce n'est pas un problème de fuseau horaire. C'est le comportement attendu du protocole IMAP, et il touche n'importe qui qui remonte des emails stockés localement sur un serveur via cette méthode.

POP3 vs IMAP : une différence fondamentale de stockage

Pour comprendre pourquoi le problème se produit, il faut d'abord comprendre comment POP3 fonctionne, et en quoi c'est radicalement différent d'IMAP.

Avec POP3, le serveur sert uniquement de boîte aux lettres temporaire. Votre client (Outlook, Thunderbird, Apple Mail) se connecte, télécharge les messages, puis les supprime du serveur (ou les laisse selon votre configuration). Les emails vivent ensuite exclusivement en local : dans un fichier .pst pour Outlook, dans le profil local de Thunderbird, dans une base de données sur votre disque dur.

Avec IMAP, c'est l'inverse : les emails vivent sur le serveur. Votre client ne fait qu'afficher ce qui est stocké à distance. D'où la synchronisation transparente entre tous vos appareils.

Le problème survient dans la transition entre les deux. Quand vous remontez vos anciens emails POP locaux sur le serveur IMAP.

IMAP APPEND : la commande qui change tout

Quand votre client email remonte un message local vers un serveur IMAP, il utilise la commande IMAP APPEND. Cette commande dit au serveur : "stocke ce message dans tel dossier".

Le serveur reçoit le message, l'enregistre, et lui attribue un timestamp. Ce timestamp, c'est l'INTERNALDATE. C'est la métadonnée centrale d'IMAP : elle indique quand le message a été déposé sur le serveur. Et par défaut, si le client ne spécifie pas explicitement une date dans la commande APPEND, le serveur utilise... le moment présent.

Autrement dit : peu importe que le message contienne dans ses en-têtes une date de 2018, si personne ne dit au serveur "cet email date de 2018", le serveur conclut qu'il a été déposé maintenant et lui assigne l'INTERNALDATE d'aujourd'hui.

(D'ailleurs, si vous avez déjà regardé les en-têtes bruts d'un email, vous avez vu la ligne Date: au milieu d'une dizaine d'autres lignes Received:. C'est ce champ Date:, défini par la RFC 2822, qui contient la vraie date d'envoi. Mais l'INTERNALDATE IMAP est une métadonnée séparée, stockée côté serveur, qui n'a rien à voir avec le contenu du message lui-même.)

Pourquoi c'est différent d'une migration IMAP-to-IMAP

Dans une migration classique d'un serveur IMAP vers un autre (avec BitTitan, CloudM, imapsync, etc.), le problème est légèrement différent. L'outil de migration copie les messages d'un serveur à l'autre, et dans ce cas, il peut (en théorie) transmettre l'INTERNALDATE original au serveur de destination via la commande APPEND. Le problème là-bas, c'est que certains outils ajoutent un en-tête Received: avec la date de migration, ce qui perturbe l'affichage dans des clients comme Outlook.

Dans votre cas, vous partez de données purement locales. Il n'y a pas d'INTERNALDATE source à copier. Le fichier .pst ou le profil Thunderbird stocke les messages dans son propre format propriétaire, avec ses propres métadonnées internes. Quand le client mail relit ces messages pour les remonter sur le serveur IMAP, il reconstruit la commande APPEND à partir du contenu du message. Et la plupart du temps, il ne transmet pas de date explicite.

Résultat : le serveur IMAP reçoit des centaines ou des milliers de messages dans les minutes qui suivent, et attribue à tous la même plage horaire : maintenant.

C'est précisément pourquoi le problème se propage sur tous vos appareils instantanément. Votre téléphone, votre tablette, votre second ordinateur : ils se connectent tous au même serveur IMAP et voient exactement la même chose. Pas de correction possible côté client.

Quel client affiche quoi, et pourquoi

Tous les clients email ne réagissent pas de la même façon. C'est un point que beaucoup d'admins IT découvrent après coup.

Outlook (dans ses versions récentes, et surtout depuis les mises à jour de 2023-2024) utilise l'INTERNALDATE du serveur pour la colonne "Reçu". Il affiche donc la date de remontée, pas la date d'envoi originale. Pour en savoir plus sur ce comportement spécifique à Outlook, cet article est utile : Outlook : date reçue migration IMAP vs date envoyée.

Gmail / Google Workspace et Thunderbird ont des comportements un peu plus nuancés. Gmail, par exemple, peut parfois utiliser le champ Date: de l'en-tête du message pour l'affichage, ce qui donne l'impression que tout va bien... jusqu'à ce que vous essayiez de trier par date et que vous réalisiez que l'ordre est complètement aléatoire.

Apple Mail affiche généralement la date extraite de l'en-tête Date:, mais le tri et la recherche passent par l'INTERNALDATE en arrière-plan. Du coup, vos emails peuvent "sembler" bien datés visuellement, mais la fonctionnalité de tri ne fonctionne plus correctement. Pour le détail du comportement d'Apple Mail, voir Apple Mail : mauvaise date après migration.

La bonne nouvelle : la date originale est intacte

L'en-tête Date: de chaque email, celui qui contient la vraie date d'envoi (ou de réception), n'a pas été touché. Il est toujours là, dans le corps du message. C'est lui que vous voyez quand vous ouvrez un email et regardez les détails.

Ce que le serveur IMAP a "cassé", c'est uniquement l'INTERNALDATE, cette métadonnée externe au message. Le message lui-même est intact.

C'est ce qui rend la correction possible. Et c'est aussi ce qui explique pourquoi le problème peut passer inaperçu pendant un moment : les emails semblent corrects quand vous les ouvrez un par un. C'est seulement en regardant la liste de votre boîte de réception, triée par date, que le problème devient visible. Des emails de 2019 apparaissent en haut comme s'ils venaient d'arriver. Tous avec la même date.

Le problème d'échelle : 3000 emails, c'est différent de 3

Vous vous dites peut-être : "Je n'ai qu'à supprimer et réimporter, cette fois correctement." Sur 5 ou 10 emails de test, oui, ça marche. Sur une boîte de 8000 messages avec des dossiers imbriqués, des pièces jointes volumineuses, des emails S/MIME signés et des fils de discussion qui remontent à 2015... c'est une autre histoire.

Un script maison qui fonctionne sur un lot de test de 50 emails peut très bien produire des doublons, perdre des pièces jointes ou casser des fils de conversation sur une boîte de production. La gestion des quotas API, des timeouts réseau, des messages aux structures MIME atypiques... autant de cas limites qu'un outil non spécialisé ne gère pas.

Et si quelque chose tourne mal à mi-chemin ? Sans mécanisme de sauvegarde et de rollback, vous perdez des données sans possibilité de les récupérer.

Le problème est bien connu des admins qui gèrent des migrations à volume. Comprendre pourquoi les dates sont cassées est une chose. Corriger proprement 15000 emails en préservant chaque structure de message, c'en est une autre. Pour aller plus loin sur ce sujet, l'article Peut-on corriger les dates des emails après migration ? détaille les différentes approches et leurs limites.

Comment Redate.io gère ce cas spécifique

Redate.io a été conçu précisément pour ce type de situation. Son moteur d'analyse identifie les emails dont l'INTERNALDATE ne correspond pas à la date contenue dans les en-têtes du message, qu'il s'agisse d'une migration POP vers IMAP, d'une migration entre serveurs IMAP, ou d'une remontée manuelle d'archives locales.

Le pipeline d'analyse multi-étapes inspecte la chaîne d'en-têtes de chaque message, valide la conformité RFC, et reconstruit les métadonnées de date sans altérer le contenu du message : ni le texte, ni les pièces jointes, ni la structure MIME, ni les éventuelles signatures numériques. Chaque email corrigé est vérifié individuellement avant validation.

Les originaux sont conservés dans un dossier de sauvegarde visible pendant 30 jours. Si quelque chose ne vous convient pas, vous pouvez restaurer.

Le scan initial est gratuit : Redate analyse votre boîte, identifie les emails affectés, et vous indique le nombre exact avant que vous ne décidiez quoi que ce soit. Pas d'engagement à l'aveugle.

Redate.io se connecte directement à vos boîtes via Google Workspace (délégation de domaine), Microsoft 365 (Azure AD), ou IMAP direct. Aucune installation locale. Aucun export de fichiers .pst à manipuler à la main.

Pour les admins qui gèrent plusieurs boîtes et qui veulent un retour d'expérience sur ce type de cas, l'article MSP : corriger les dates email de vos clients est une bonne lecture complémentaire. Et pour les spécificités de la correction dans Thunderbird, qui a son propre comportement lors du passage POP/IMAP, voir Thunderbird : mauvaise date après migration.

Et si c'est encore à faire : anticiper le problème

Si vous n'avez pas encore remonté vos archives locales sur le serveur IMAP, ou si vous planifiez d'autres migrations de comptes POP dans votre organisation, voici ce qu'il faut garder en tête.

• Vérifiez si votre client email supporte le passage explicite de la date dans la commande APPEND. Thunderbird, par exemple, a eu des comportements variables selon les versions sur ce point.
• Faites d'abord un test sur un compte de validation avec 50-100 messages représentatifs : emails anciens, avec pièces jointes, emails signés. Vérifiez les dates affichées dans différents clients.
• Planifiez la correction avant que les utilisateurs finaux ne commencent à travailler sur la boîte migrée. Corriger les dates sur une boîte active est plus complexe que sur une boîte vierge post-migration.
• Documentez le nombre d'emails avant et après migration. C'est la seule façon de détecter des pertes silencieuses.

Pour une checklist complète des points à vérifier avant et après une migration, l'article Checklist migration email : prévenir les problèmes de dates couvre l'ensemble des cas.

Vos anciens emails affichent la date d'aujourd'hui après un passage POP vers IMAP ? Lancez un scan gratuit sur Redate.io pour mesurer l'étendue du problème et corriger les métadonnées de date sans toucher au contenu de vos messages.