Politiques de rétention, archivage et eDiscovery dans Microsoft 365 : configurer proprement et optimiser la recherche et les performances

Qui met en place des politiques de conservation dans Microsoft 365 évolue toujours dans le domaine tendu de la conformité, des coûts d’exploitation, des attentes des utilisateurs et de la recherche. En pratique, les projets échouent rarement en surface dans le portail, mais à cause d’objectifs de conservation flous, de périmètres (scopes) mal choisis, de règles contradictoires et d’une configuration de recherche qui devient inutilisable lorsque les volumes de données augmentent. Cet article vous guide, en tant qu’administrateur, ingénieur système ou prestataire technique, vers une mise en œuvre opérationnelle : des prérequis et décisions d’architecture aux pièges typiques, en passant par les étapes de vérification, l’optimisation des performances de recherche et une stratégie de secours robuste.

Important : la rétention (conservation/suppression selon des règles) n’est pas automatiquement de l’archivage (déménagement/séparation ciblé, p. ex. Exchange Online Archive). Et eDiscovery (préservation de preuves électroniques/recherche dans un contexte juridique et d’audit) n’est pas une recherche utilisateur classique ; elle fonctionne avec des workflows, des rôles et des contraintes propres. Qui sépare clairement ces trois disciplines aura moins de surprises en exploitation, en qualité de recherche et en performances.

Objectif : ce que la rétention, l’archivage et l’eDiscovery accomplissent respectivement (et ce qu’ils ne font pas)

Les politiques de conservation dans Microsoft 365 (aujourd’hui typiquement via Microsoft Purview, le portail de conformité et de gouvernance) contrôlent la durée de conservation des contenus et le moment de leur suppression automatique. Selon la charge de travail (Exchange, SharePoint, OneDrive, Teams), ces règles s’appliquent à différents endroits et provoquent des effets secondaires distincts. Important : la rétention n’a pas pour but de « nettoyer » le stockage sans conséquences. La conservation peut même entraîner la rétention interne de contenus supprimés.

L’archivage dans Microsoft 365 désigne dans la pratique administrative la plupart du temps Exchange Online Archive (archive de boîte aux lettres distincte) ou des concepts d’archivage organisationnels pour SharePoint/OneDrive (p. ex. sites d’archivage, bibliothèques en lecture seule, processus de cycle de vie). L’archivage vise la structure, les coûts et l’utilisabilité : les données « actives » restent légères, les données plus anciennes migrent de façon contrôlée vers un autre contenant. La rétention peut compléter l’archivage, mais ne le remplace pas automatiquement.

L’eDiscovery (Standard ou Premium, selon la licence) est la boîte à outils pour la recherche juridiquement conforme, l’exportation, la revue et les workflows de mise sous conservation (hold). Le Legal Hold (conservation juridique) empêche la suppression/la manipulation en cas de litige. Il s’agit d’un cas d’usage différent de « nous voulons conserver pendant 7 ans ». Pour les administrateurs, point essentiel : l’eDiscovery génère de la charge (recherches/exports), nécessite des contrôles de rôles et d’accès et doit être documentée proprement afin que, en cas d’audit, il soit possible de retracer qui a recherché ou exporté quoi et quand.

Prérequis : licences, rôles, sources de données et gestion des attentes

Avant de créer des règles, clarifiez quatre points fondamentaux, sinon vous vous retrouverez dans des ajustements sans fin :

• Niveau de licence : les fonctionnalités de rétention et d’eDiscovery diffèrent selon l’offre. Vérifiez si vous disposez des politiques de conservation, des étiquettes de conservation, de l'(auto-)étiquetage, de l’eDiscovery (Standard/Premium) et, le cas échéant, des fonctions d’audit. Ne vous fiez pas à « le portail l’affiche » – établissez ce qui est réellement utilisable en production.
• Modèle de rôles : Séparez les rôles d’administration (configuration) des rôles eDiscovery (traitement des affaires). Dans Purview, des rôles/Role Groups sont attribués. Minimisez les « Global Admin » dans le contexte eDiscovery.
• Sources de données / Workloads : Quelles données sont dans le périmètre ? Boîtes aux lettres Exchange, sites SharePoint, comptes OneDrive, discussions/ messages de canal Teams, éventuellement M365 Groups. Chaque source dispose de mécanismes de conservation et de recherche différents.
• Attentes : « Nous supprimons après X ans » est souvent trop imprécis. Définissez : durée de conservation, point de départ (création, dernière modification, événement), exceptions (p. ex. projets, RH, finance), blocages (Legal Hold) et si les utilisateurs sont encore autorisés à supprimer.

Conseil pratique : Rédigez un objectif concis sous forme de tableau : Type de données → Propriétaire → Objectif de conservation → Objectif de suppression → Exigence de recherche/eDiscovery → Mise en œuvre technique. Cela évite de travailler ensuite avec des stratégies contradictoires.

Planification des politiques de rétention dans Microsoft 365 : périmètre, priorités et conflits

Les problèmes opérationnels les plus fréquents ne proviennent pas de « mauvais clics », mais d‘erreurs de périmètre et de conflits entre règles. Périmètre signifie : pour quels utilisateurs, groupes, sites ou emplacements une stratégie ou une étiquette s’applique. Dans les grands tenants, il est tentant de définir « pour tous » — puis d’exclure laborieusement ensuite. Préférez un déploiement progressif : pilote → unités organisationnelles définies → global.

Policy vs. Label : quel outil et quand ?

Politique de rétention convient si vous avez besoin d’une conservation/suppression simple et largement applicable sans interaction utilisateur. Étiquette de rétention est appropriée lorsque des durées de conservation différentes coexistent dans une même bibliothèque/boîte aux lettres et que l’attribution doit être basée sur des règles ou manuelle (p. ex. « Contrat », « Offre », « Dossier du personnel »). Les étiquettes offrent plus de fonctionnalités, mais sont aussi plus sensibles aux erreurs de gouvernance (attributions incorrectes, formation insuffisante, règles d’auto-étiquetage incomplètes).

Comprendre la logique de conflit (pour que la suppression ne « se bloque » pas)

Lorsque plusieurs règles de conservation s’appliquent au même contenu, c’est généralement la règle « la plus contraignante » qui l’emporte — en pratique souvent : une durée de conservation plus longue prime sur une plus courte. C’est pertinent pour la conformité, mais trompeur si vous introduisez une « conservation des discussions de 30 jours » et qu’une règle générale « conserver 5 ans » existe quelque part. Résultat : rien n’est supprimé au bout de 30 jours et la recherche est alourdie par des données historiques. Documentez donc les priorités par workload et testez les conflits pendant le pilote.

Classer correctement l’archivage : Exchange Online Archive, archive SharePoint et données Teams

L’archivage est souvent une décision opérationnelle : comment garder les espaces de travail actifs allégés sans perdre d’informations ? Cela concerne particulièrement les boîtes aux lettres (le courrier électronique reste dans de nombreuses organisations le « canal de rangement ») et SharePoint/Teams quand des équipes projet accumulent des données pendant des années.

Exchange Online Archive : soulagement, mais pas d’excuse pour une mauvaise rétention

Exchange Online Archive sépare la boîte aux lettres principale et la boîte d’archives. Les administrateurs l’utilisent pour contrôler les quotas et stabiliser les performances d’Outlook sur des boîtes aux lettres très volumineuses. Important : l’archivage ne remplace pas la rétention. Si vous « poussez tout vers l’archive » sans définir de règles de suppression, l’archive continuera de croître indéfiniment — et les opérations d’eDiscovery ainsi que les tâches d’exportation deviendront de plus en plus lourdes.

Piège courant : l’archivage peut modifier le comportement des utilisateurs (« c’est en archive, c’est sûr, donc je garde tout »). Les règles doivent prendre en compte ce comportement, sinon les volumes de données, les index et les temps de recherche exploseront.

Archive SharePoint/OneDrive : la structure prime sur le dossier fourre‑tout

Pour SharePoint Online et OneDrive, un « archive » est souvent un modèle d’organisation : sites d’archive séparés, bibliothèques avec droits restreints, zones éventuellement en lecture seule et processus clairs de cycle de vie (fin de projet → transfert → archive). La rétention garantit ensuite que les contenus archivés ne disparaissent pas de manière incontrôlée ou ne restent pas stockés trop longtemps. Pour la recherche : plus l’architecture de l’information est bonne (sites, bibliothèques, métadonnées), moins l’eDiscovery devra « fouiller à la truelle » par la suite.

Teams : les chats et messages de canal ne sont pas des fichiers classiques

Les données Teams sont réparties techniquement : les chats et les messages de canal résident dans des emplacements de stockage proches d’Exchange et de SharePoint (selon le type de contenu). Pour les administrateurs, cela signifie : la rétention doit prendre explicitement en compte les emplacements Teams, et la recherche eDiscovery doit savoir si l’on cherche un chat, un canal, un fichier ou des artefacts de réunion. Erreur fréquente : ne couvrir que SharePoint/OneDrive, laissant les chats Teams non régulés ou conservés par erreur trop longtemps.

Étape par étape : mettre en place proprement des politiques de rétention (pilote, contrôles, déploiement)

Une pratique éprouvée en exploitation est un déploiement en trois étapes. Il réduit les risques et aide à détecter tôt les effets sur la recherche et la performance.

1) Définir le pilote : petit, représentatif, contrôlable

• Choisissez 1–2 départements avec des schémas de données typiques (orientés e‑mail, orientés SharePoint).
• Utilisez des groupes de test dédiés (groupes M365 ou groupes de sécurité) pour les périmètres.
• Définissez des points de mesure : temps de recherche pour des requêtes standard, nombre de résultats, durée d’export (eDiscovery), retours utilisateur.

2) Conception des politiques : peu de règles, points de démarrage clairs

Points de départ (quand l’horloge « tourne ») sont décisifs. Selon le workload, « création », « dernière modification » ou « événement » sont possibles. Basé sur les événements est souvent correct du point de vue métier, mais difficile sur le plan organisationnel : vous avez besoin d’un événement fiable (p. ex. « employé parti », « projet clôturé ») et d’une attribution solide. Si l’événement se trouve dans les systèmes RH, prévoyez des interfaces ou un processus manuel avec journal d’audit.

3) Activation et validation : ne pas se contenter de vérifier « Statut : actif »

Dans Microsoft 365, les modifications n’apparaissent pas toujours instantanément. Préparez une phase de validation et vérifiez non seulement le portail, mais les effets dans les workloads et dans eDiscovery.

Approche de vérification technique : avec Exchange Online PowerShell, vous pouvez par ex. vérifier si les mécanismes de conservation (Hold) s’appliquent et si les boîtes aux lettres sont correctement dans le périmètre. Les commandes sont volontairement fournies comme exemples – adaptez-les à vos rôles et conventions de nommage.

# Verbindung zu Exchange Online (moderne Authentifizierung vorausgesetzt)
Connect-ExchangeOnline

# Beispiel: Prüfen, ob ein Postfach ein Archiv aktiviert hat
Get-Mailbox -Identity user@contoso.com | Format-List ArchiveStatus,ArchiveName

# Beispiel: Litigation Hold prüfen (falls eingesetzt)
Get-Mailbox -Identity user@contoso.com | Format-List LitigationHoldEnabled,LitigationHoldDuration

# Beispiel: In-Place Holds / Compliance Holds (Übersicht, je nach Tenant-Konfiguration)
Get-Mailbox -Identity user@contoso.com | Format-List InPlaceHolds

Piège typique : un Legal Hold (p. ex. Litigation Hold) peut empêcher les suppressions. Si des contenus « ne disparaissent pas », ce n’est souvent pas un bug mais un hold. Donc : documentez les holds de manière centralisée, désignez des propriétaires, fixez des échéances et des dates de revue.

Mettre en place eDiscovery : rôles, dossiers, recherche et export sans dérives

eDiscovery est sensible sur le plan organisationnel. Une exploitation propre nécessite un modèle de rôles minimaliste, des processus clairs et des garde-fous techniques. Éléments clés :

• Role Groups: Qui peut créer des dossiers, qui peut rechercher, qui peut exporter ? L’export est particulièrement critique (risque de fuite de données).
• Case-Management: Nommage uniforme (ID du ticket, période, objectif), conservation de la documentation du dossier.
• Stratégie de recherche: D’abord ciblée, puis élargie. Préférez plusieurs petites recherches plutôt qu’une requête gigantesque « tout depuis 2016 ».
• Stratégie des holds: Les holds doivent être aussi restreints que nécessaire. Chaque hold a un coût opérationnel (les données restent plus longtemps, les index grossissent, les processus de suppression sont bloqués).

Content Search vs. eDiscovery : ce qui distingue les administrateurs au quotidien

Dans de nombreux tenants coexistent les deux chemins : Content Search (recherche simple dans le contexte de la compliance) et des eDiscovery-Cases (traitement structuré des dossiers). Content Search est rapide pour des contrôles ad hoc, mais évolue mal sur le plan organisationnel si beaucoup de personnes effectuent des recherches « vite fait ». eDiscovery est plus maîtrisable, mais nécessite de la discipline sur les rôles et le cycle de vie des dossiers.

Performance d’export : pourquoi les « listes de résultats trop grandes » posent problème

Les exports prennent du temps et sont sujets aux erreurs lorsque les résultats sont gigantesques ou quand de nombreuses locations (sites, boîtes aux lettres) sont impliquées. Causes fréquentes de mauvaise performance d’export :

• Des requêtes trop larges (périodes longues, mots-clés génériques sans restriction).
• Trop de sources de données simultanées (boîtes aux lettres + de nombreux sites + OneDrive global).
• Beaucoup de petits éléments (chats) plutôt que peu de gros documents.
• Des holds/retentions supplémentaires augmentent le volume de données à parcourir.

Les contre-mesures sont généralement méthodiques : limiter la fenêtre temporelle, prioriser les emplacements, affiner la requête de façon itérative, segmenter les exports (p. ex. par mois ou par source de données). Il s’agit moins d’un « tuning » que d’un runbook propre.

Optimiser la recherche et les performances : causes, leviers et attentes réalistes

Lorsque les administrateurs entendent « la recherche est lente », il n’est pas clair si les utilisateurs parlent de la recherche M365 (SharePoint/Office), d’eDiscovery ou de la recherche Outlook (client). Séparez ces niveaux, sinon vous optimisez au mauvais endroit.

1) Volume de données et scope : le principal levier de performance

L’optimisation la plus efficace est presque toujours : réduire le scope. Pas « optimiser à outrance » techniquement, mais restreindre proprement d’un point de vue métier et organisationnel :

• Ne pas appliquer la rétention de manière uniforme « pour tous les types de données », mais différencier selon la valeur des données et le risque.
• Séparer logiquement les zones d’archive (p. ex. archives par projet) pour permettre à eDiscovery de rechercher de façon plus ciblée.
• Appliquer les holds uniquement à des personnes/sites concrètes et à des fenêtres temporelles définies, avec revue.

2) Architecture de l’information dans SharePoint : les métadonnées l’emportent sur les noms de fichiers

Dans SharePoint Online, une structure propre a un impact indirect sur la recherche : si les contenus sont placés dans des sites/bibliothèques pertinents et enrichis de métadonnées (p. ex. type de document, projet, statut), les recherches peuvent être plus ciblées. Sans métadonnées, les équipes aboutissent à « mot-clé + 5 ans », ce qui fait exploser les listes de résultats et le volume des exports.

Piège typique : les métadonnées sont introduites mais pas maintenues. Les filtres deviennent alors inefficaces. En tant qu’admin, vous pouvez agir via des modèles, des champs obligatoires (avec parcimonie) et des processus de classement clairs – pas via des exceptions de rétention à répétition.

3) Indexation et délais : ne pas interpréter chaque effet comme une erreur

Dans Microsoft 365, il existe des temps d’indexation et de traitement. Les modifications des scopes de rétention ou du labelling n’apparaissent pas toujours immédiatement dans tous les parcours de recherche. Prévoyez donc, lors de changements :

• Une période d’attente et d’observation définie avant d’appeler au « rollback ».
• Points de mesure : même requête, mêmes emplacements, heure documentée.
• Communication aux opérateurs eDiscovery : « Scope modifié aujourd’hui, les résultats peuvent évoluer avec retard. »

4) Recherche Outlook vs recherche serveur : délimiter clairement les problèmes côté client

Outlook peut « ralentir » alors même qu’eDiscovery et la recherche serveur M365 fonctionnent correctement. Les causes sont les index locaux, la taille des OST, les compléments ou les conditions réseau. Vérifiez donc : cela concerne-t-il seulement certains clients ou toutes les recherches côté serveur ? Pour les projets de rétention/eDiscovery, cette distinction est importante pour éviter de modifier par erreur des règles de rétention afin de « résoudre » un problème client.

Dépannage : scénarios d’erreurs typiques et séquence de vérification systématique

Les modèles suivants apparaissent fréquemment en pratique. L’ordre de vérification aide à distinguer rapidement entre erreur de configuration, conflit de périmètre et écart par rapport aux attentes.

Schéma d’erreur A : « Il n’est pas supprimé alors que la rétention est expirée »

• Vérifier : Existe-t-il un Hold (Legal Hold, Litigation Hold, eDiscovery Hold) ?
• Vérifier : Une autre règle de rétention avec durée plus longue s’applique-t-elle ?
• Vérifier : Le point de départ (création/modification/événement) correspond-il à l’attente ?
• Vérifier : L’emplacement est-il réellement dans le périmètre (Site, OneDrive, Mailbox) ?

Schéma d’erreur B : « eDiscovery ne retrouve pas des contenus que les utilisateurs voient »

• Vérifier : Recherchez-vous dans les emplacements corrects (Mailbox vs. Site vs. OneDrive vs. Teams) ?
• Vérifier : Fenêtre temporelle/requête trop restrictive ? Caractères spéciaux, langues, variantes ?
• Vérifier : Autorisations/rôles : le rôle exécutant la recherche a-t-il accès dans le contexte eDiscovery ?
• Vérifier : Retard d’indexation : le contenu a-t-il été créé/modifié récemment ?

Schéma d’erreur C : « Recherches/exports prennent un temps excessif ou échouent »

• Vérifier : Nombre de résultats et sources de données : segmentez la recherche/l’export.
• Vérifier : Parallélisme : plusieurs gros jobs s’exécutent-ils en même temps (y compris par d’autres équipes/prestataires) ?
• Vérifier : Les holds/la rétention augmentent-ils les volumes de données – est-ce souhaité d’un point de vue métier ?
• Vérifier : Stratégie d’export : préférer plusieurs petits exports plutôt qu’un « One Shot ».

Opérationnalisation : Runbooks, supervision, gestion des changements et documentation

La rétention et l’eDiscovery ne se configurent pas « une fois pour toutes ». Pour une exploitation stable, vous avez besoin au minimum de :

• Runbook « Modifier la rétention » : changement de périmètre, pilote, observation, communication, remise en l’état.
• Runbook « Cas eDiscovery » : demande/motif, attribution des rôles, recherche, hold, export, clôture, conservation de la documentation du cas.
• Fenêtre de changement : ne pas effectuer de grands changements de périmètre en parallèle d’autres modifications de conformité.
• Documentation : intention de la politique (Pourquoi), pas seulement la configuration (Quoi). Ce n’est qu’ainsi que les nouveaux administrateurs comprendront la logique.

Un standard minimal raisonnable est un document central (Wiki/ITSM) qui, pour chaque règle, indique : responsable, périmètre, point de départ, durée de conservation, action de suppression, exceptions, dépendances (holds), preuves de test et dates de revue.

Stratégie de repli : comment annuler des changements en toute sécurité sans compromettre la conformité

« Rollback » signifie rarement « nous revenons à zéro » dans le contexte de la conformité. Si des contenus ont déjà été conservés pendant longtemps ou protégés par des holds, on ne peut pas simplement les désactiver techniquement sans créer de risques. Une stratégie de repli opérationnelle comprend trois niveaux :

1) Rollback de configuration (retrait de la politique/périmètre)

Si une nouvelle politique de rétention a des effets secondaires inattendus (p. ex. explosion du volume de recherche), la première étape consiste souvent à réduire le périmètre (retirer le groupe pilote, arrêter l’affectation globale). Cela réduit les nouveaux effets, tandis que les données existantes continuent d’être traitées conformément aux règles.

2) Contournement opérationnel (réduire la charge eDiscovery)

Si les performances d’eDiscovery sont dégradées, vous pouvez stabiliser à court terme par des mesures méthodiques : segmenter les exports, réduire la fenêtre de recherche, échelonner les jobs dans le temps. C’est souvent plus rapide et moins risqué que des modifications hâtives des politiques.

3) Correction de la gouvernance (corriger la cause)

À long terme, vous devez résoudre le conflit métier : conservation trop large, responsabilités floues, métadonnées/structure d’archivage manquantes ou pratique de mise en attente trop généreuse. Sans cette correction, le problème réapparaîtra lors du prochain audit ou d’une nouvelle demande juridique.

Checklist pour les administrateurs : vérifier une fois « rigoureusement » avant la mise en production

• Le périmétrage via les groupes est documenté et testé (pilot/production séparés).
• Les conflits entre politiques de rétention/labels sont évalués (la durée la plus longue prime sur la plus courte).
• Les holds sont inventoriés : responsable, finalité, date de revue, dépendances.
• Les rôles eDiscovery sont attribués de façon minimale et traçable (export strictement réglementé).
• L’archivage (zones d’archive Exchange / SharePoint) est défini comme concept de structure, et non comme un « bassin de collecte ».
• La stratégie de recherche est formalisée dans un runbook (itérations de requêtes, segmentation, plan d’export).
• Communication aux équipes concernées : qu’est‑ce qui change pour les utilisateurs et les opérateurs ?

Conclusion : des périmètres clairs et une gouvernance saine sont la vraie optimisation des performances

Les politiques de rétention dans Microsoft 365, l’archivage et eDiscovery ne sont pas des fonctionnalités isolées, mais un modèle opérationnel cohérent. La meilleure performance de recherche et d’exportation s’obtient rarement par du « tuning », mais par des périmètres clairs, des règles sans conflit, une architecture de l’information durable et des workflows de mise en attente disciplinés. Ceux qui prennent au sérieux la phase pilote, les étapes de vérification et les runbooks évitent les surprises classiques : suppressions qui ne s’exécutent pas, listes de résultats surdimensionnées et travaux eDiscovery devenant peu fiables lors des pics de charge. Ainsi, la conformité reste démontrable et l’exploitation quotidienne reste maîtrisable.

Pour ce thème, Microsoft Purview Retention et les politiques de conservation de Microsoft 365 sont également importantes. Cet article place ces aspects dans leur contexte et explique ce qui compte au quotidien.