Migration iCloud vers Office 365 : dates d'emails incorrectes

Un scénario de migration qui casse systématiquement les dates

Vous venez de terminer le transfert de votre messagerie iCloud vers Office 365. Les emails sont là, les dossiers sont en place, tout semble parfait. Lundi matin, la première plainte arrive : "Tous mes anciens emails affichent la date d'aujourd'hui." Puis une deuxième. Puis dix.

Ce n'est pas un bug isolé. La migration depuis iCloud Mail vers Office 365 est l'un des scénarios les plus documentés de corruption de dates d'emails, pour des raisons techniques très précises qui tiennent à la fois au comportement d'Apple Mail, au protocole IMAP, et à la façon dont Microsoft 365 traite les messages entrants.

Pourquoi iCloud vers Office 365 casse les dates

Pour comprendre le problème, il faut distinguer trois choses que beaucoup de gens (y compris des admins IT expérimentés) confondent : l'en-tête Date:, l'INTERNALDATE IMAP, et la date de création du fichier.

L'en-tête Date: (RFC 2822)

Chaque email contient un en-tête Date: qui indique quand le message a été envoyé. Cet en-tête est intégré dans le corps brut du message et ne change jamais, en théorie. C'est la date "originale" au sens strict du terme.

L'INTERNALDATE IMAP

Le protocole IMAP (défini dans la RFC 3501) associe à chaque message une métadonnée distincte appelée INTERNALDATE. C'est cette valeur que la plupart des clients mail utilisent pour trier et afficher les messages dans la boîte de réception, pas l'en-tête Date:. Outlook, en particulier, s'appuie très fortement sur l'INTERNALDATE pour l'affichage et le tri.

Le problème ? Quand un outil de migration copie un email d'un serveur IMAP vers un autre, il devrait idéalement préserver cet INTERNALDATE. En pratique, ce n'est pas toujours ce qui se passe.

Le comportement particulier d'Apple Mail

Apple Mail, quand il synchronise des messages depuis iCloud, utilise parfois la date de création du fichier côté serveur comme référence pour l'INTERNALDATE. Ce n'est pas un bug au sens strict, c'est une interprétation de la spécification IMAP qui diverge de ce que font d'autres clients. (D'ailleurs, si vous avez déjà essayé de déboguer un problème d'INTERNALDATE en lisant les RFC IMAP brutes, vous savez que la spécification laisse une marge d'interprétation assez large sur ce point.)

Résultat : quand vous exportez ou migrez depuis iCloud via Apple Mail, les INTERNALDATES des messages peuvent déjà être incorrects avant même d'arriver dans Office 365.

Les trois méthodes de migration iCloud et leurs pièges

Migration IMAP directe

La méthode la plus courante consiste à configurer iCloud comme source IMAP et Office 365 comme destination, puis à utiliser un outil de migration (imapsync, MigrationWiz, ou un outil maison). L'outil se connecte aux deux serveurs et copie les messages.

Le problème ici est double. D'abord, les serveurs IMAP d'Apple ont des limites de débit qui forcent les outils à faire des pauses, créant des fenêtres de temps où les connexions se ferment et rouvrent, ce qui peut générer des INTERNALDATES parasites. Ensuite, chaque message copié via IMAP APPEND vers Exchange Online reçoit par défaut une date de dépôt correspondant au moment de la migration, sauf si l'outil passe explicitement l'INTERNALDATE original dans la commande d'insertion.

Certains outils le font bien. D'autres, pas systématiquement. Et sur une boîte de 40000 messages, même un taux d'erreur de 2 % représente 800 emails avec la mauvaise date.

Pour les migrations via imapsync, voir aussi : corriger les dates imapsync dans Microsoft 365.

Export .mbox ou .eml puis import

Certains utilisateurs exportent leurs emails iCloud via Apple Mail au format .mbox, puis essaient de les importer dans Outlook. C'est une méthode artisanale qui produit des résultats variables.

Le format .mbox encode les emails comme une séquence de messages texte. Les dates sont présentes dans les en-têtes Date: individuels, mais la ligne de séparation entre messages ("From ") inclut une date qui peut être interprétée comme date de création par certains importeurs. Outlook, quand il importe un .mbox converti en .pst, utilise parfois cette date de séparation plutôt que l'en-tête Date: du message lui-même.

Le glisser-déposer via Outlook

Voici la méthode qui cause le plus de dégâts. Un utilisateur configure les deux comptes dans Outlook (iCloud et Office 365), puis fait un glisser-déposer de ses messages d'un dossier à l'autre. Ça semble simple. C'est une catastrophe pour les dates.

Quand Outlook déplace un message par glisser-déposer entre deux comptes IMAP, il génère en réalité un nouveau fichier .EML, l'insère dans le compte de destination, et supprime l'original. Ce nouveau fichier hérite de la date de création du fichier Windows, c'est-à-dire le moment exact du glisser-déposer. L'en-tête Date: original est toujours présent dans le corps du message, mais l'INTERNALDATE enregistré sur le serveur Exchange Online correspond à la date de la manipulation. Outlook affiche ensuite cette date de migration pour tous les messages déplacés.

Pour être précis, ce comportement varie selon la version d'Outlook. Depuis la mise à jour Outlook de l'automne 2023, le comportement s'est légèrement amélioré pour certains scénarios, mais le glisser-déposer entre comptes reste une source de corruption de dates documentée.

Ce qu'Office 365 et Outlook affichent finalement

Exchange Online stocke les emails avec leur INTERNALDATE. Outlook Desktop lit cet INTERNALDATE pour afficher la date dans la colonne "Reçu" et pour trier la boîte de réception. Si l'INTERNALDATE a été écrasé pendant la migration, Outlook affiche la date de migration, point final.

Outlook Web App (OWA) fait de même. Il n'y a pas de "vue alternative" qui montrerait la date originale de l'en-tête Date:. Ce que vous voyez dans la colonne de date, c'est l'INTERNALDATE.

L'en-tête Date: original est toujours là, intact, lisible si vous affichez les en-têtes bruts d'un message. Mais aucun affichage normal ne le montre. C'est là la frustration centrale de ce problème : la bonne information existe, elle est juste inaccessible sans correction technique.

Ce que le support Microsoft ne résout pas

Si vous ouvrez un ticket chez Microsoft Support pour ce problème, voici ce que vous obtiendrez probablement : une confirmation que les dates affichées correspondent aux INTERNALDATES stockés, une suggestion de vérifier les paramètres de tri dans Outlook, et éventuellement un renvoi vers l'outil de migration que vous avez utilisé.

Ce n'est pas de la mauvaise volonté. Microsoft n'a tout simplement pas d'outil natif pour corriger rétroactivement les INTERNALDATES de milliers de messages déjà ingérés dans Exchange Online. La correction nécessite d'accéder aux messages individuellement, d'analyser leurs en-têtes, et de reconstruire les métadonnées de date, ce qui est hors du périmètre du support standard.

Le support iCloud, de son côté, considère que les messages ont été exportés correctement et que le problème est côté destination. Les deux supports se renvoient la balle, et l'utilisateur se retrouve avec 12000 emails datés du jour de la migration.

Le problème d'échelle

Comprendre pourquoi les dates sont cassées est une chose. Les corriger manuellement sur une boîte de production en est une autre.

Certains admins IT tentent de scripter la correction. L'idée de base n'est pas compliquée à conceptualiser, mais l'exécution sur des volumes réels pose des problèmes que les scripts maison ne gèrent pas bien :

• Les emails S/MIME signés ou chiffrés avec PGP ne peuvent pas être modifiés sans invalider la signature cryptographique
• Les messages avec des structures multipart/alternative complexes (HTML + texte brut + pièces jointes imbriquées) sont fragiles à manipuler
• Les en-têtes encodés en non-ASCII (RFC 2047, notamment pour les caractères japonais, arabes ou cyrilliques) peuvent être corrompus par des outils qui ne gèrent pas correctement ces encodages
• Les quotas API de Microsoft Graph et les limites de débit Exchange Online (erreur 429 Too Many Requests) stoppent les scripts non conçus pour la gestion de backoff exponentiel
• Un script qui tourne correctement sur 500 emails de test s'arrête à 3h du matin sur le 8000ème message d'une vraie boîte, sans mécanisme de reprise

Et la question qui tue : comment vérifier que chaque email corrigé est intact après la correction ? Que la pièce jointe est toujours là ? Que le fil de discussion n'est pas cassé ? Un script maison ne fait généralement pas cette vérification.

Comment Redate.io traite les migrations iCloud vers Office 365

Redate.io se connecte directement à Office 365 via les permissions Microsoft 365 (Azure AD), sans nécessiter d'accès aux serveurs iCloud. Les emails sont déjà dans Exchange Online au moment où Redate intervient.

Le moteur de correction de Redate analyse la chaîne d'en-têtes de chaque message pour identifier la date originale, en distinguant les en-têtes Received: ajoutés lors de la migration des métadonnées de date légitimes. Cette analyse inclut une correspondance de motifs sur des signatures d'outils de migration connus, ce qui permet d'identifier les en-têtes parasites même quand ils ne sont pas immédiatement évidents.

Chaque email corrigé est vérifié individuellement après traitement. Les originaux sont conservés dans un dossier de sauvegarde visible pendant 30 jours, ce qu'aucun script maison ne fait par défaut. Le scan initial est gratuit et permet de quantifier exactement le nombre d'emails affectés avant de décider de corriger.

Redate supporte également les migrations depuis Google Workspace vers Office 365 et les corrections après migration cPanel. Voir par exemple : corriger les dates d'emails après migration Microsoft 365 ou mauvaises dates après migration vers Exchange Online.

Scanner d'abord, corriger ensuite

Le point de départ recommandé pour toute migration iCloud vers Office 365 qui a produit des dates incorrectes : lancer le scan gratuit de Redate.io sur les boîtes affectées. Le scan identifie précisément combien d'emails ont un INTERNALDATE suspect et dans quels dossiers ils se trouvent.

Ça prend entre 12 et 45 minutes selon le volume, et ça donne une image claire de l'étendue du problème avant toute intervention. Pour les MSPs qui gèrent plusieurs boîtes à la fois après une migration, ce scan par lots évite de corriger des boîtes qui n'en ont pas besoin.

Si les dates de vos emails sont incorrectes après une migration depuis iCloud, commencez par le scan gratuit sur Redate.io pour mesurer l'ampleur du problème sur vos boîtes Office 365.