Trier par date d'envoi n'est pas une solution

6 min

Le conseil le plus répandu sur chaque forum

Cherchez "emails affichent mauvaise date après migration" sur n'importe quel forum IT, et la première réponse est presque toujours la même : "Triez par date d'envoi au lieu de date de réception." Ce conseil apparaît sur les forums Microsoft, les fils d'aide Google Workspace, les posts Reddit et les discussions Spiceworks. C'est devenu la réponse par défaut à ce qui est en réalité un problème de données au niveau du serveur.

Le conseil part d'une bonne intention. Dans Outlook, changer la colonne de tri de "Reçu" a "Envoyé" modifie effectivement l'ordre visible des emails. Les messages qui semblaient tous avoir la même date de migration se retrouvent soudainement dans leur séquence chronologique d'origine. À première vue, le problème semble résolu.

Mais il ne l'est pas.

Pourquoi ça semble fonctionner

L'amélioration visuelle

Quand un utilisateur change la vue Outlook pour trier par "Date d'envoi", la boîte de réception a immédiatement l'air correcte. Les emails de 2020 apparaissent avant ceux de 2023. Pour un utilisateur qui fixait 10000 emails affichant tous la même date, c'est une amélioration spectaculaire.

Ça fonctionne dans une vue, sur un appareil

Le contournement par tri par date d'envoi fonctionne à exactement un endroit : la vue du dossier spécifique, sur l'appareil spécifique, où l'utilisateur a fait la modification. Si l'utilisateur passe à un autre dossier, la vue peut revenir. Si l'utilisateur consulte ses emails sur un autre appareil, le réglage ne se transfère pas.

Toutes les façons dont ça échoue

Les résultats de recherche affichent toujours les mauvaises dates

La recherche d'emails dans Outlook, Gmail, Apple Mail et Thunderbird indexe les messages en utilisant la date de réception (INTERNALDATE), pas la date d'envoi. Quand un utilisateur cherche "emails reçus en mars 2022", le moteur de recherche vérifie l'INTERNALDATE, qui affiche toujours la date de migration. La recherche renvoie zéro résultat pour mars 2022 et renvoie tous les emails pour la date de migration.

Pour les utilisateurs qui recherchent fréquemment par plage de dates (comptables cherchant les factures d'un trimestre précis, avocats rassemblant la correspondance d'une période de dossier), la boîte mail est fonctionnellement inutilisable. Changer la colonne de tri ne touche pas ce qu'utilise le moteur de recherche.

Conformité et eDiscovery sont compromis

Des outils comme Microsoft Purview, Google Vault et les plateformes de conformité tierces interrogent les métadonnées côté serveur, y compris l'INTERNALDATE. Trier par date d'envoi dans Outlook n'a strictement aucun effet sur ce que ces outils récupèrent. Une demande de conservation juridique pour "tous les emails reçus entre janvier et mars 2023" renverra des résultats incorrects.

Pour les organisations dans la finance, la santé, le juridique et le secteur public, des résultats d'eDiscovery inexacts peuvent mener à des sanctions, des amendes ou des décisions judiciaires défavorables.

À configurer sur chaque appareil et chaque dossier

Outlook n'applique pas les réglages de vue globalement. Changer la colonne de tri dans la Boîte de réception ne la change pas dans Éléments envoyés, Brouillons, Archive ou les dossiers personnalisés. Chaque dossier doit être ajusté individuellement. Les réglages sont stockés localement, ce qui signifie qu'ils doivent être répétés sur chaque appareil. Pour une organisation de 100 utilisateurs, chacun avec 4 appareils et 10 dossiers, ça fait 4000 modifications de vues individuelles. Qui va faire ça ?

L'INTERNALDATE est toujours fausse

L'INTERNALDATE IMAP reste incorrecte sur le serveur. Cela affecte les outils de sauvegarde, les futurs outils de migration (qui propagent la mauvaise INTERNALDATE), les intégrations API et les systèmes d'archivage email. Le problème d'INTERNALDATE persiste indéfiniment tant qu'il n'est pas corrigé au niveau du serveur.

Les règles et filtres email utilisent la date de réception

Les règles Outlook, les filtres Gmail et les règles de transport Exchange basées sur la date de réception vont dysfonctionner. Une règle qui dit "déplacer les emails reçus il y a plus de 90 jours vers Archive" peut archiver tout le contenu de la boîte mail ou rien du tout. Les flux Power Automate et les Google Apps Scripts qui traitent les emails en fonction de la date de réception produisent des résultats incorrects.

Certains clients de messagerie ne le supportent même pas

Tous les clients de messagerie ne supportent pas le tri par date d'envoi. Apple Mail sur iOS ne propose pas d'option "trier par date d'envoi". Thunderbird gère les colonnes de date différemment d'Outlook. Les interfaces webmail (Roundcube, Horde) ont des possibilités de personnalisation limitées des colonnes.

Le threading des conversations est cassé

Les clients de messagerie qui supportent la vue par conversation regroupent les messages liés en se basant sur les en-têtes et les dates. Quand les dates de réception sont fausses, le threading des conversations peut mal ordonner les messages au sein d'un fil ou afficher la date du fil comme étant la date de migration.

La vraie solution : corriger les données côté serveur

La raison pour laquelle "trier par date d'envoi" échoue est que ça traite le symptôme (mauvais ordre d'affichage) sans corriger la cause (mauvaises métadonnées de date côté serveur). La vraie solution passe par la correction des métadonnées de date sur le serveur pour chaque email affecté.

Une fois les données côté serveur corrigées, chaque client de messagerie affiche la bonne date. Les résultats de recherche renvoient des plages de dates exactes. Les outils de conformité interrogent les bons horodatages. Les règles et filtres opèrent sur la vraie date de réception. Aucun réglage par appareil ou par dossier nécessaire. La correction est permanente et universelle.

Comment Redate.io effectue la correction au niveau serveur

Le moteur de correction propriétaire de Redate.io se connecte à la boîte mail (Google Workspace, Microsoft 365 ou tout serveur IMAP) et scanne chaque email pour identifier ceux avec des en-têtes "Received" de migration. Le scan est gratuit.

Pour chaque email affecté, le pipeline d'analyse multi-étapes identifie les signatures de migration par correspondance de motifs sur des centaines de signatures d'outils de migration connues, applique des corrections ciblées tout en préservant l'intégrité du message (signatures S/MIME, structures multipart, pièces jointes en ligne, en-têtes non-ASCII et des dizaines d'autres cas limites), et exécute une vérification d'intégrité sur chaque email corrigé. Les originaux sont déplacés vers un dossier de sauvegarde visible pendant 30 jours. Le processus complet est détaillé dans l'article comment corriger les dates email après migration.

Après la correction, il n'y a rien à configurer dans Outlook, aucun réglage à changer sur chaque appareil, aucun contournement à retenir. Les dates sont tout simplement correctes, partout, en permanence.

Arrêtez de compter sur un contournement qui ne fonctionne qu'à moitié. Lancez un scan gratuit pour voir combien d'emails ont des dates erronées, et corrigez-en 10 gratuitement pour vérifier les résultats.