Calipia : le blog

Il existe dans toute organisation une tension fondamentale, souvent inconfortable, entre deux impératifs contradictoires : conserver les données pour satisfaire les obligations légales et réglementaires, et pouvoir les supprimer définitivement quand les circonstances l’exigent. Exchange Online et Microsoft Purview ont longtemps excellé dans le premier exercice. Pour le second, les administrateurs devaient jusqu’ici naviguer à vue dans un labyrinthe procédural peu documenté et franchement risqué. Microsoft s’apprête à changer la donne avec Priority Cleanup V2, une version substantiellement remaniée d’une fonctionnalité déjà existante, dont l’annonce mérite qu’on s’y attarde sérieusement.

Un problème que tout le monde connaît mais que peu savent résoudre proprement

Dans les environnements Exchange Online, il n’est pas rare que l’intégralité du contenu d’une boîte aux lettres soit préservée pendant de longues périodes, que ce soit via les contrôles de Litigation hold historiques, les étiquettes et politiques de rétention modernes, ou les holds eDiscovery premium. Cette approche « mieux vaut trop que pas assez » est compréhensible d’un point de vue juridique, mais elle génère une accumulation de données qui peut rapidement devenir problématique.

Les scénarios qui nécessitent une suppression forcée sont en réalité assez courants : soit il s’agit de demandes de droit à l’effacement émanant d’anciens employés réclamant la suppression de leurs données après une période déterminée, soit d’incidents de type data spillage, où des informations sensibles se retrouvent dans une boîte aux lettres qui doit être purgée. 

Le problème, jusqu’ici, était que la procédure pour supprimer des éléments sous « hold » impliquait de désactiver manuellement les « holds » concernés, de couper le « single item recovery », d’intervenir sur les éléments en question, puis de tout réactiver. Ce processus exposait les administrateurs au risque de supprimer des éléments non ciblés, potentiellement perdus pour toujours.On comprend aisément pourquoi beaucoup préféraient ne pas y toucher 🙂

Priority Cleanup V1 : une bonne idée, une exécution douloureuse

Vous le savez, Microsoft a introduit Priority Cleanup comme une fonctionnalité de Microsoft Purview permettant de supprimer définitivement du contenu de boîtes Exchange Online même lorsque celui-ci est soumis à des politiques de rétention, des étiquettes ou des « holds eDiscovery », en imposant dynamiquement plusieurs niveaux d’approbation selon les holds applicables à chaque élément. 

Techniquement, le mécanisme est élégant : une politique Priority Cleanup est en réalité une politique de rétention étendue avec un nouveau type d’objet PriorityCleanup. Une règle KQL définit les éléments à cibler, qui reçoivent une étiquette de conformité. Des reviewers désignés valident ensuite la suppression via un workflow de disposition — fonctionnalité déjà existante dans Purview, ici réutilisée à bon escient.

Mais la V1 souffrait de défauts rédhibitoires dans les faits. En termes de vitesse de traitement, la première version prenait plus de six jours pour traiter même de petites boîtes aux lettres. Six jours pour purger un incident de sécurité, c’est exactement six jours de trop. Le workflow d’approbation comportait trois étapes distinctes, ce qui, combiné à l’obligation de désigner des approbateurs aux rôles très précis (Priority Cleanup Admin, Retention Management, Search And Purge), aboutissait à mobiliser au minimum quatre personnes différentes — sans qu’aucune d’entre elles ne puisse être la même personne ayant créé la politique. Enfin, l’absence d’estimation préalable du nombre d’éléments ciblés par la requête KQL forçait les administrateurs à travailler à l’aveugle jusqu’à la fin du traitement initial.

V2 : une refonte centrée sur la réalité opérationnelle

Priority Cleanup V2 promet une vitesse de suppression significativement améliorée, et même une exécution instantanée lorsque la boîte aux lettres ne fait l’objet d’aucun preservation hold. Le workflow d’approbation passe de trois à deux étapes, réduisant ainsi la friction administrative sans sacrifier le principe de double validation. 

Parmi les autres améliorations annoncées : la possibilité de configurer des suppressions par lot pour les purges portant sur un grand nombre d’éléments, une meilleure gestion des politiques, de nouvelles métadonnées dans l’interface de review, et surtout l’introduction d’un Cleanup ID qui constitue une piste d’audit complète pour toute activité de purge. Ce dernier point est loin d’être anecdotique : dans un contexte réglementaire où la preuve de disposition est souvent aussi importante que la suppression elle-même, disposer d’un identifiant traçable pour chaque opération de nettoyage représente un progrès significatif.

Microsoft espère que Priority Cleanup V2 simplifiera le quotidien des administrateurs grâce à une suppression accélérée, une réduction de la charge administrative, une meilleure transparence et un support amélioré pour les exigences de sécurité et de conformité complexes. 

Ce que les architectes doivent retenir

Plusieurs points méritent l’attention des équipes en charge de l’architecture Microsoft 365.

• Premier point : le périmètre de la fonctionnalité. Priority Cleanup, dans ses deux versions, cible exclusivement Exchange Online, y compris les boîtes aux lettres associées aux groupes Microsoft 365. Les boîtes partagées et les boîtes de salles ne sont pas sélectionnables depuis l’interface Purview, bien qu’elles puissent être ajoutées via PowerShell. La roadmap ne mentionne pas d’extension imminente à SharePoint Online ou OneDrive, même si certaines sources indiquent que des travaux sont en cours dans cette direction.
• Deuxième point : le modèle de licences. Microsoft a intégré Priority Cleanup dans les SKUs Office 365 E5 ou équivalents incluant les fonctionnalités de conformité, évitant ainsi de créer un énième module complémentaire payant. C’est à noter positivement. Pour les organisations sous E3 qui envisagent la montée en gamme, cette fonctionnalité peut constituer un argument supplémentaire, à condition de la mettre en regard des autres capacités E5 déjà justifiées dans leur contexte.
• Troisième point : les implications en matière de gouvernance. La capacité de supprimer définitivement des données même sous preservation hold est une fonctionnalité à double tranchant. La conception par Microsoft d’un processus multi-approbateurs et d’une piste d’audit via le Cleanup ID traduit une conscience de ce risque. Mais cela signifie également que les organisations doivent définir en amont une politique claire sur qui peut déclencher une Priority Cleanup, dans quels cas, et avec quel niveau de documentation. Les DSI et DPO auraient tout intérêt à s’impliquer dans la rédaction de cette politique avant que la fonctionnalité ne soit disponible.
• Quatrième point : les requêtes KQL restent la clé de voûte. La puissance et la précision de la suppression dépendent entièrement de la qualité de la requête KQL définie lors de la création de la politique. L’interface actuelle ne fournit aucune estimation préalable du volume d’éléments ciblés — une lacune que V2 semble en partie adresser, mais sur laquelle il conviendra de rester vigilant à la mise en production. La recommandation est d’exécuter la même requête en parallèle via Content Search avant de valider une politique, pour s’assurer du périmètre réel.

Disponibilité et feuille de route

Priority Cleanup V2 devrait être disponible dans le courant de l’année, Microsoft encourageant d’ores et déjà les retours via les canaux de support ou les Customer Success Agents dédiés. ‘absence de date précise dans l’annonce est, disons-le, un classique de la communication produit Microsoft (entre « plus tard cette année » et « bientôt »), les équipes IT ont appris à ne rien planifier avant la disponibilité générale effective.

Il reste à voir si V2 tient ses promesses de rapidité dans les scénarios les plus complexes, notamment ceux impliquant simultanément des preservation holds actifs, des étiquettes de rétention immutables et des volumes importants. C’est précisément dans ces configurations que la V1 montrait ses limites les plus criantes, et c’est là que se jouera la réputation de la V2.

Source essentielle pour revenir sur la V1

Vasil Michev (MVP Microsoft) propose une analyse technique approfondie en deux parties sur le fonctionnement interne de Priority Cleanup V1, les mécanismes backend, l’expérience des reviewers et les limites observées en production : https://michev.info/blog/post/6454/priority-cleanup-enables-removal-of-items-on-hold-from-microsoft-365-mailboxes-part-1