Microsoft Purview est aujourd’hui présenté comme la solution pour gouverner et protéger les données dans Microsoft 365.
Classification, DLP, audit, eDiscovery, Insider Risk, tout y est. Sur le papier, c’est impressionnant.
Et pourtant, sur le terrain, Purview laisse souvent un sentiment étrange : celui d’un outil à la fois très puissant et délicat à manier, voire risqué, si on ne sait pas exactement où l’on va.
Cet article est une une tentative de mettre des mots sur un décalage réel : celui entre ce que Purview promet, et l’effort de gouvernance nécessaire pour en tirer une vraie valeur — sans casser le quotidien des utilisateurs.
Purview n’est pas un outil de décision
C’est probablement le point le plus important, et aussi le moins clairement exprimé.
Purview ne décide de rien, il applique des règles que quelqu’un a définies :
- sur ce qui est sensible,
- sur ce qui peut être partagé,
- sur ce qui doit être bloqué,
- sur ce qui est acceptable ou non.
Mais Purview ne connaît pas :
- vos processus métiers,
- vos contraintes opérationnelles,
- vos exceptions “historiques” mais indispensables,
- ni les compromis tacites qui permettent à l’entreprise de fonctionner.
Autrement dit, Purview exécute des choix organisationnels — même quand ces choix n’ont jamais été explicitement formulés.
Et quand ils ne le sont pas, on configure, au feeling, on se repose sur des hypothèses — souvent implicites — et parfois fausses.
Le travail que personne ne vend
Dans les présentations et la documentation Microsoft Purview, l’accent est mis sur les fonctionnalités :
- créer une règle DLP,
- configurer un label,
- activer une alerte,
- améliorer le Secure Score.
Ce qui est beaucoup moins visible, c’est le travail préalable :
- comprendre les processus métiers réels (pas ceux sur un organigramme),
- savoir qui a légitimement le droit de faire quoi,
- identifier les flux de données critiques,
- distinguer ce qui est risqué de ce qui est simplement inconfortable.
Ce travail-là est :
- long,
- humain,
- parfois politique,
- difficile à standardiser,
- et non monétisable pour un éditeur logiciel.
Purview n’élimine pas ce travail. Il le rend simplement impossible à éviter.
Quand on s’y aventure sans boussole
Quand Purview est déployé sans cette base de gouvernance, deux scénarios reviennent très souvent.
Des flux de travail bloqués sans bruit
Certaines règles — notamment en DLP ou avec des labels restrictifs — ne s’appliquent pas instantanément.
La propagation peut prendre des heures. Et quand l’effet se produit, il est parfois peu explicite côté utilisateur.
Résultat typique :
- “Je n’arrive plus à envoyer ce fichier.”
- “Le partage ne fonctionne plus.”
- “Ça marchait hier.”
Ceci sans message clair, sans lien évident avec une règle activée récemment.
Et parfois sans que l’IT ne fasse immédiatement le rapprochement.
Et ce sont les incidents les plus pénibles : diffus, silencieux, chronophages. Sans même parler de la perte de confiance dans les outils IT, des tickets circulaires qui s’accumulent, et le mécontentement légitime du management.
On n’ose plus rien activer
C’est le corolaire du paragraphe précédent, beaucoup d’organisations adoptent une posture très prudente :
- quelques labels génériques,
- des règles DLP en audit uniquement,
- très peu de blocage réel,
- et une forte hésitation à aller plus loin.
Purview est là, mais sous-utilisé.
Non pas parce qu’il est inutile, mais parce que le coût d’une erreur est perçu comme trop élevé.
Le paradoxe Purview
Il y a là un paradoxe intéressant, car Purview est le plus efficace :
- dans des organisations déjà très matures,
- avec des processus clairs,
- des rôles bien définis,
- et une gouvernance existante.
Autrement dit, là où l’on aurait presque pu s’en passer.
À l’inverse, dans les organisations moins structurées — celles qui auraient besoin de cadres — Purview devient difficile à utiliser sans risques.
Purview n’est donc pas un point de départ: C’est un outil d’aboutissement.
Changer de regard sur Purview
Plutôt que de le voir comme un produit à “déployer”, il est plus juste de le considérer comme :
un amplificateur de décisions organisationnelles
S’il y a du flou en amont, Purview amplifie le flou.
S’il y a des contradictions, il les rend visibles.
S’il y a des tensions entre sécurité et métier, il les met au premier plan.
Ce n’est pas un défaut du produit, c’est sa nature.
Avant de toucher à une règle
Avant toute règle bloquante, les vraies questions ne sont pas techniques :
- Quels flux métiers doivent absolument continuer à fonctionner ?
- Quelles données sont réellement critiques, et dans quels contextes ?
- Qui est responsable des décisions de blocage ?
- Comment saura-t-on rapidement qu’on a cassé quelque chose ?
- Quelle friction est acceptable et laquelle ne l’est pas ?
Tant que ces questions restent sans réponse claire, le minimalisme assumé est souvent plus sain que la complexité par défaut.
En conclusion
Microsoft Purview est un excellent outil, mais ce n’est ni une baguette magique, ni un raccourci vers la conformité.
Il exige :
- de la clarté,
- de la gouvernance,
- et une compréhension fine des flux humains qu’il va contraindre.
Le vrai danger n’est pas de “ne pas tout activer”, le vrai danger est d’automatiser des règles que l’on n’a jamais vraiment prises le temps de définir.