Hébergeur mutualisé vers Microsoft 365 : le problème de dates caché

Le problème que personne ne vous a signalé

Vous venez de finaliser la migration de votre messagerie depuis OVH, Infomaniak, Ionos ou o2switch vers Microsoft 365. L'assistant de migration de l'EAC (Exchange Admin Center) a tourné toute la nuit, tout est au vert, les boîtes sont remplies. Lundi matin, premier ticket : "Tous mes anciens emails ont la date d'aujourd'hui." Puis un deuxième. Puis dix.

Ce n'est pas un bug de Microsoft 365. Ce n'est pas non plus un hasard. C'est le résultat mécanique d'une migration IMAP, et dans le cas d'un hébergeur mutualisé, le problème est souvent deux fois plus grave que dans une migration classique. Voici pourquoi.

Comment IMAP gère les dates (et où ça déraille)

Chaque email stocké sur un serveur IMAP possède deux types de datation distincts. D'un côté, l'en-tête Date: (défini par la RFC 2822), présent dans le corps du message lui-même, qui indique quand le message a été envoyé ou reçu. De l'autre, l'INTERNALDATE, une métadonnée au niveau du serveur qui indique à quelle date ce message a été déposé dans la boîte. C'est cette valeur que les clients mail comme Outlook utilisent par défaut pour trier et afficher les emails.

(D'ailleurs, si vous avez déjà essayé de lire les en-têtes bruts d'un email dans l'EAC, vous savez que ce n'est pas exactement de la lecture de plage. Il y a facilement vingt à trente lignes d'en-têtes avant d'arriver au contenu.)

Quand un outil de migration IMAP transfère un message d'une boîte à une autre, il doit recréer cet INTERNALDATE sur la destination. Certains outils le font correctement. Beaucoup ne le font pas, ou le font avec des limitations. Le serveur de réception, lui, garde ce qu'on lui donne : quand une copie porte sa date d'origine, Exchange Online conserve cette date. Quand les dates ressortent fausses, c'est donc l'outil qu'il faut regarder, pas Microsoft 365.

Résultat : chaque email migré semble avoir été "reçu" le jour de la migration. Peu importe qu'il date de 2019.

Le scénario en deux étapes : pourquoi les hébergeurs mutualisés aggravent tout

Voilà où la situation devient vraiment problématique pour les migrations depuis des hébergeurs mutualisés comme OVH, Infomaniak, Gandi, Ionos ou o2switch.

Ces hébergeurs utilisent généralement des serveurs mutualisés Postfix, Dovecot ou cPanel avec des configurations IMAP standard. Beaucoup de PME y ont accumulé des années d'emails, parfois depuis 2010 ou 2012. Quand elles décident de passer à Microsoft 365, la migration se déroule souvent en deux temps.

Étape 1 : la première corruption (avant même Microsoft 365)

Dans de nombreux cas, les emails ont déjà subi une première migration. L'entreprise a changé d'hébergeur mutualisé une ou deux fois au fil des années : de Gandi vers OVH en 2018, puis d'OVH vers Infomaniak en 2022, par exemple. Chaque transfert IMAP a pu ramener l'INTERNALDATE original au jour du transfert (chaque fois que l'outil ne transmettait pas la date d'origine), et certains outils laissent en plus leurs propres en-têtes de migration, datés de ce jour-là.

Quand les emails arrivent sur Microsoft 365, ils portent donc déjà des cicatrices. L'en-tête Date: d'origine est intact (il fait partie du corps du message, personne ne le touche), mais les métadonnées de date ont déjà été perturbées une première fois.

Étape 2 : la deuxième corruption lors du passage vers Exchange Online

L'outil de migration IMAP de l'EAC, ou un outil tiers comme BitTitan MigrationWiz configuré en mode IMAP, ingère alors ces emails déjà abîmés. Si cet outil ne transmet pas non plus la date d'origine de chaque email, Exchange Online range l'email au jour du transfert, et c'est cette "date de réception" qu'Outlook finit par afficher.

Un email envoyé en mars 2017 peut donc porter deux couches de dates fausses : les en-têtes de migration laissés par le changement d'hébergeur de 2022, et une date de réception issue de la migration vers Microsoft 365 en 2024. Outlook affiche 2024. L'utilisateur voit 2024. C'est faux à deux niveaux.

Correction, pour être tout à fait précis : Outlook détermine la date d'affichage à partir d'une combinaison entre l'INTERNALDATE enregistré par Exchange Online et les en-têtes présents. Mais chaque fois que l'outil de migration ne transmet pas les dates d'origine, le passage vers Exchange Online ajoute une nouvelle couche d'erreurs par-dessus l'ancienne.

Outils de migration et hébergeurs : les combinaisons à risque

Quelques combinaisons reviennent très souvent dans les migrations depuis hébergements mutualisés :

• OVH / Infomaniak / Ionos + outil IMAP de l'EAC : l'outil natif Microsoft est pratique mais notoire pour ne pas préserver correctement les dates lors de migrations IMAP volumineuses.
• cPanel (o2switch, LWS, etc.) + BitTitan MigrationWiz en mode IMAP : MigrationWiz en mode IMAP ajoute ses propres en-têtes de migration. Le résultat est documenté, entre autres, sur notre page corriger les dates BitTitan dans Microsoft 365.
• Gandi / Mailcow + imapsync : imapsync est un outil puissant mais sa gestion de l'INTERNALDATE dépend de la configuration. Sans l'option appropriée, les dates ne sont pas préservées. Voir aussi imapsync : dates non préservées.
• Toute migration manuelle par glisser-déposer dans Outlook : si quelqu'un a copié des dossiers entiers en faisant du drag-and-drop entre deux comptes configurés dans Outlook, l'INTERNALDATE de chaque email est réécrit à la date de la copie. Sans exception.

Le dénominateur commun : toutes ces méthodes aboutissent à Exchange Online avec des emails dont la date affichée dans Outlook ne correspond plus à rien de réel.

Pourquoi "corriger ça soi-même" est une mauvaise idée à grande échelle

Comprendre le problème est une chose. Corriger 8000 emails répartis dans 40 boîtes Exchange Online, sur des comptes avec des structures de dossiers complexes, des emails signés S/MIME, des pièces jointes volumineuses et des fils de discussion imbriqués, c'en est une autre.

Un script PowerShell qui semble fonctionner sur dix emails de test peut silencieusement échouer sur le message numéro 4237 à cause d'une frontière MIME corrompue ou d'un en-tête encodé en RFC 2047 (ce format =?UTF-8?B?...?= pour les caractères non-ASCII dans les noms d'expéditeurs). Sans mécanisme de vérification individuelle, vous ne le saurez pas. Vous aurez juste un email perdu.

Les risques concrets du DIY sur ce type de migration :

• Messages en double si la logique d'insertion échoue à mi-chemin
• Pièces jointes manquantes si la structure multipart est mal reconstruite
• Fils de discussion cassés dans Outlook (les conversations se basent sur des en-têtes References: et In-Reply-To: qui peuvent être altérés)
• Erreurs 429 (Too Many Requests) de l'API Microsoft Graph à 3h du matin, qui interrompent le traitement sans rollback
• Aucun moyen simple de vérifier que les 8000 corrections ont toutes été appliquées correctement

Et dans le cas spécifique des migrations depuis hébergeurs mutualisés, il y a une difficulté supplémentaire : les emails portent plusieurs couches d'en-têtes Received: parasites, pas juste une. Un script simple qui retire "le dernier Received:" ne suffit pas. Il faut analyser la chaîne complète pour identifier quel en-tête correspond à quelle migration, et lequel représente réellement la date de réception originale.

Ce que Redate.io fait différemment

Chaque utilisateur se connecte avec son propre compte Microsoft, et Redate.io ouvre cette boîte avec les accès que cette connexion autorise. Si l'organisation exige l'accord d'un administrateur, Redate.io prépare un lien à lui transmettre. Le scan initial est gratuit : Redate.io identifie tous les emails dont la date affichée ne correspond pas à la date réelle, et en donne une estimation précise par boîte.

La correction repose sur un moteur propriétaire qui analyse la chaîne complète d'en-têtes de chaque message et reconstruit les métadonnées de date correctement, quel que soit l'outil de migration utilisé, même quand plusieurs couches de corruption se superposent. Chaque email corrigé est vérifié individuellement. Redate.io ne supprime jamais les originaux : ils restent dans un dossier de sauvegarde visible de votre propre boîte, jusqu'à ce que vous décidiez vous-même de les effacer.

Pour les migrations depuis hébergeurs mutualisés, le pipeline d'analyse multi-étapes de Redate.io gère explicitement les scénarios de double corruption : il ne se contente pas de regarder le dernier en-tête Received:, il remonte l'historique complet pour retrouver la date de réception réelle. Voir aussi comment corriger les dates après migration Microsoft 365 de manière générale, et le guide spécifique sur les INTERNALDATE erronés en IMAP pour comprendre la mécanique sous-jacente.

Avant de migrer ou après : deux moments pour agir

Deux situations, deux postures.

Vous n'avez pas encore migré. La bonne nouvelle : il est possible de limiter la casse. Certains outils de migration (MigrationWiz en mode Exchange, CloudM avec les bonnes options) préservent mieux les dates que d'autres. Mais même dans le meilleur des cas, une migration depuis un hébergeur mutualisé sans historique propre laissera probablement des traces. Prévoyez un passage par Redate.io après la migration, avant de livrer les boîtes aux utilisateurs.

Vous avez déjà migré et les tickets arrivent. Redate.io corrige les boîtes existantes dans Microsoft 365, quelle que soit l'ancienneté de la migration. Le scan vous donnera une image précise de l'état réel de chaque boîte avant toute intervention. Consultez aussi la checklist migration email pour éviter les mêmes problèmes à l'avenir.

Vous avez migré depuis OVH, Infomaniak, Ionos ou o2switch vers Microsoft 365 et les dates sont fausses ? Créez un compte Redate.io pour scanner vos boîtes gratuitement et voir exactement l'étendue des dégâts avant de décider quoi que ce soit.