Microsoft Purview en septembre 2026 : DLP réseau, apps tierces et IA

Microsoft Purview ne se contente plus de protéger les documents Microsoft 365 : la plateforme étend son application (enforcement) au réseau, aux applications tierces et aux navigateurs, tout en absorbant la gouvernance des agents IA et de Copilot. Cet article de synthèse couvre les évolutions publiées entre mai et août 2026 sur Microsoft Learn et les blogs officiels Microsoft, avec un focus sur ce qui est réellement actionnable en production. Il s'adresse aux administrateurs Purview, Exchange Online et Microsoft Defender qui doivent distinguer les fonctionnalités en disponibilité générale (GA) des aperçus (preview) — ces derniers ne devant jamais être présentés comme des contrôles opérationnels.

Vue d'ensemble : Purview étend son emprise au réseau, aux apps tierces et à l'IA

Deux trajectoires structurent les publications récentes. D'un côté, l'enforcement (l'application effective des politiques) sort du périmètre Microsoft 365 pour couvrir les applications non-Microsoft, les endpoints, les navigateurs et désormais le réseau lui-même. De l'autre, la gouvernance s'étend des documents classiques vers les systèmes d'IA et les agents autonomes : Copilot, Agent 365, Claude, et les workloads IA hébergés hors de l'écosystème Microsoft.

Cette double extension a une conséquence directe sur le pilotage : la question n'est plus « avez-vous activé telle fonctionnalité Purview ? » mais « vos données sensibles et vos interactions IA sont-elles classifiées, surveillées, appliquées, retenues et documentées de façon cohérente sur chaque plateforme et chaque couche de contrôle ? ». Gardez cette distinction en tête : plusieurs capacités décrites ci-dessous sont encore en preview et doivent rester des pilotes bornés, pas des contrôles de production.

Panorama des nouveautés publiées entre mai et août 2026

Avant d'entrer dans le détail technique, voici une vue synthétique du statut et de la date de publication de chaque évolution majeure. Elle sert de check-list pour votre revue de conformité trimestrielle.

DLP réseau et applications tierces : la protection sort de Microsoft 365

La nouveauté la plus structurante concerne l'intégration de Purview avec Microsoft Entra Global Secure Access (documentée en juillet 2026, statut preview). Concrètement, les organisations peuvent désormais intercepter et inspecter du texte et des interactions IA au niveau réseau, appliquer des actions restrictives basées sur une politique DLP, et détecter une activité utilisateur à risque via Insider Risk Management.

L'intérêt business est direct : l'enforcement ne dépend plus du fait que la destination soit une application Microsoft managée. Pour les organisations dont le risque principal est un collaborateur copiant du contenu confidentiel dans un service IA non sanctionné, c'est le premier point de contrôle qui se situe réellement dans le chemin du trafic, et non plus seulement sur l'endpoint.

En parallèle, les politiques DLP et les politiques d'étiquetage automatique peuvent désormais protéger des données sensibles au repos dans des applications connectées non-Microsoft comme Box et Google Workspace (preview, août 2026). Cette fonctionnalité s'appuie sur les connecteurs Microsoft Defender for Cloud Apps et sur le moteur de classification Microsoft 365 — un seul modèle de classification et une seule autorité de politique couvrent désormais Microsoft et une partie du non-Microsoft.

Ce point mérite attention : les étiquettes de sensibilité ne se contentent pas de classer un document, elles portent le chiffrement, alimentent les conditions DLP et déterminent les décisions d'accès dont hérite Copilot. Étendre leur portée aux apps tierces revient donc à étendre, de facto, la surface de protection de vos agents IA.

Étiquetage automatique, simulation et fiabilité de la classification

La capacité d'auto-étiquetage (licences E5 ou E7) sur SharePoint et OneDrive passe de 100 000 à 500 000 fichiers par jour, selon le Microsoft Security Blog du 27 août 2026. Pour des tenants qui hébergent souvent plusieurs dizaines de millions de fichiers, cette augmentation change concrètement la vitesse à laquelle un chantier de classification peut être mené à terme.

Autre ajout utile : un onglet Insights dans le panneau de détails d'une politique DLP ou d'auto-étiquetage donne désormais une vue synthétique de sa performance, avec un contenu qui diffère selon que la politique est en mode simulation ou en mode application. Cet onglet n'apparaît que pour le contenu Microsoft 365.

Côté Exchange Online, les politiques DLP détectent désormais les échecs de classification provoqués par des timeouts, de la limitation de débit (throttling) ou d'autres erreurs de scan. Les administrateurs peuvent activer cette détection et utiliser la condition DocumentScanFailures pour appliquer une action de protection différente lorsqu'un message n'a pas pu être scanné correctement — évitant ainsi de traiter un échec technique comme une violation de politique.

Gouvernance interne : alertes, suppression définitive et expiration des rôles

Dans Insider Risk Management, le tableau de bord de l'agent de triage et le tableau de bord d'alertes standard fusionnent en une seule liste : les alertes classiques et celles triées par agent se gèrent désormais au même endroit, avec résumés d'agent et détails utilisateur directement accessibles depuis la liste.

Le profil utilisateur s'enrichit de signaux Microsoft Entra — emplacement du bureau, type d'employé, département, dernière date de travail — et les analystes peuvent ajouter des notes sur les alertes et les cas, avec des notes système générées automatiquement à chaque changement de statut, d'affectation, de clôture ou d'escalade.

Autre changement notable : les politiques de priority cleanup, qui accélèrent la suppression permanente d'informations redondantes couvertes par une politique de rétention, imposent désormais un workflow d'approbation à trois approbateurs distincts : un administrateur Priority Cleanup, un gestionnaire de rétention et un administrateur eDiscovery.

Enfin, les attributions de groupes de rôles Purview (à l'exception des rôles eDiscovery Administrator et eDiscovery Manager) peuvent désormais être configurées avec une date d'expiration, révoquant l'accès automatiquement à l'échéance. Cette option se configure directement au niveau de l'attribution du groupe de rôles concerné dans le portail Microsoft Purview, sans outillage ni licence supplémentaire — un gain appréciable pour les tenants qui n'ont pas étendu Microsoft Entra Privileged Identity Management aux rôles Purview.

Purview face à l'intelligence artificielle : Copilot, agents et multi-cloud

Le DLP reste, selon moi, l'un des piliers de la protection de l'information à l'ère agentique — et son périmètre continue de s'élargir côté IA. Une nouvelle condition « Email is received from > External users » dans l'emplacement de politique Microsoft 365 Copilot et Copilot Chat empêche Copilot d'utiliser des e-mails d'origine externe pour se fonder (grounding), documentée dans les notes de version DLP de juin 2026 : voir la documentation Microsoft Learn sur Microsoft Purview DLP for Microsoft 365 Copilot and Copilot Chat.

L'enjeu est concret : un des premiers vecteurs d'attaque observés consiste à injecter des instructions IA dans le corps HTML d'un e-mail. Lorsque la cible (un CFO, par exemple) ouvre le message, le prompt s'exécute avec ses propres identifiants. Cette condition DLP peut donc devenir un contrôle central de protection de votre tenant.

Autres jalons de mai à juin 2026 :

• Agent 365 est passé en disponibilité générale en mai 2026 et intègre la nouvelle suite de licences Microsoft 365 E7, offrant un moyen supporté d'inventorier quels agents sont utilisés, demandés et quelles données ils manipulent.
• Le connecteur Anthropic Claude (Enterprise) est disponible en preview depuis mai 2026 : Claude apparaît comme une application IA supplémentaire aux côtés de Microsoft 365 Copilot, Copilot Studio et ChatGPT Enterprise, avec un suivi des interactions individuelles via Activity Explorer. Voir la documentation Microsoft Learn : Use Microsoft Purview to manage data security & compliance for Anthropic Claude (Enterprise).
• Microsoft a publié un guide, le 5 juin 2026 sur le Microsoft Purview Blog (Tech Community), pour étendre la protection des données Purview aux agents AWS Bedrock, dans le scénario courant où une organisation gouverne avec Microsoft 365/Purview tout en exécutant des workloads IA sur plusieurs clouds.
• La surveillance sélective des applications IA génératives dans Insider Risk Management passe en disponibilité générale (juin 2026) : vous pouvez désormais choisir quelles applications IA sont surveillées par les indicateurs de politique, réduisant le bruit d'alerte et les coûts de facturation à l'usage.

Endpoint DLP : scoping par groupe, télémétrie et investigation des preuves

Une politique Endpoint DLP peut désormais être limitée à des groupes d'appareils spécifiques — par exemple appliquer une politique aux utilisateurs de la Finance sur des appareils Windows, mais pas lorsqu'ils travaillent depuis macOS — via des groupes d'appareils dynamiques définis dans Microsoft Entra ID. Cela lève un vrai frein opérationnel : l'application uniforme sur tous les appareils était souvent trop perturbatrice pour être adoptée largement.

Côté supervision, les attributs de configuration d'appareil et de synchronisation de politique Endpoint DLP peuvent être interrogés à grande échelle via la colonne DlpInfo de la table DeviceInfo dans Advanced Hunting du portail Microsoft Defender, plutôt que de dépendre d'exports ponctuels depuis le portail Microsoft Purview.

1// Recherche des appareils avec informations de configuration Endpoint DLP dans Advanced Hunting
2DeviceInfo
3| where isnotempty(DlpInfo)
4| project DeviceId, DeviceName, DlpInfo, Timestamp
5| order by Timestamp desc

Enfin, les investigateurs peuvent interroger les données capturées par les politiques Endpoint DLP sur les appareils onboardés et ajouter le contenu associé à un périmètre d'investigation pour une analyse assistée par IA, permettant une analyse agrégée des événements d'exfiltration plutôt qu'un triage alerte par alerte. La préparation des données s'exécute désormais automatiquement en arrière-plan, supprimant une étape manuelle de vectorisation. Voir la documentation Microsoft Learn sur Search, review, and refine results in Data Security Investigations.

Mise en œuvre : auditer l'état de vos politiques DLP et d'auto-étiquetage

Avant d'activer une nouvelle politique en mode application, il est indispensable de savoir combien de politiques existantes tournent encore en simulation dans votre tenant. Le script ci-dessous produit un inventaire lisible de toutes les politiques DLP et d'auto-étiquetage, avec leur mode réel.

Module requis : ExchangeOnlineManagement (couvre également Security & Compliance PowerShell). Installation : Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser Permission minimale : rôle « View-Only DLP Compliance Management » pour un accès en lecture seule, ou « Compliance Data Administrator » pour une vue complète incluant les métadonnées de configuration. Sortie produite : deux tableaux console listant respectivement les politiques DLP et les politiques d'auto-étiquetage, avec leur mode (application active ou simulation/test) et leur périmètre.

1# Connexion à Security & Compliance PowerShell (Microsoft Purview)
2Connect-IPPSSession -UserPrincipalName admin@contoso.com
3 
4# Audit des politiques DLP : distingue les politiques en simulation de celles en application
5$dlpPolicies = Get-DlpCompliancePolicy | Select-Object Name, Mode, Enabled, Workload
6 
7Write-Host "=== Politiques DLP ===" -ForegroundColor Cyan
8$dlpPolicies | ForEach-Object {
9    [PSCustomObject]@{
10        Politique = $_.Name
11        Mode      = $_.Mode
12        Statut    = if ($_.Mode -eq 'Enable') { 'Application active' } else { 'Simulation / test' }
13        Perimetre = $_.Workload
14    }
15} | Format-Table -AutoSize
16 
17# Même audit pour les politiques d'étiquetage automatique (auto-labeling)
18$autoLabelPolicies = Get-AutoSensitivityLabelPolicy | Select-Object Name, Mode, Enabled
19 
20Write-Host "=== Politiques d'auto-étiquetage ===" -ForegroundColor Cyan
21$autoLabelPolicies | ForEach-Object {
22    [PSCustomObject]@{
23        Politique = $_.Name
24        Mode      = $_.Mode
25        Statut    = if ($_.Mode -eq 'Enable') { 'Application active' } else { 'Simulation / test' }
26    }
27} | Format-Table -AutoSize
28 
29# Fermeture propre de la session pour éviter d'épuiser le quota de connexions
30Disconnect-ExchangeOnline -Confirm:$false

Exécutez ce script en lecture seule avant toute campagne de bascule en mode application. Le paramètre Mode de chaque politique doit correspondre à ce que vous pensez avoir déployé — un écart révèle souvent une politique jamais réellement basculée hors simulation.

Dépannage : pièges courants à anticiper

• Connect-IPPSSession échoue avec une erreur d'authentification : vérifiez que le compte dispose du rôle Purview requis et que l'authentification multifacteur (MFA) est correctement gérée par le module — utilisez un compte de service dédié pour les scripts planifiés plutôt qu'un compte administrateur interactif.
• Le mode d'une politique reste affiché en TestWithNotifications après modification : comptez un délai de propagation pouvant atteindre plusieurs heures avant que le changement ne soit visible partout, y compris dans l'onglet Insights.
• L'étiquetage automatique ne s'applique pas sur Box ou Google Workspace : vérifiez que le connecteur Microsoft Defender for Cloud Apps correspondant est bien configuré et synchronisé — sans connecteur actif, la politique Purview reste sans effet, même si elle apparaît « Enabled ».
• Une politique de protection Purview visant Azure SQL Database ne s'applique plus : ce scope a été retiré, sans explication détaillée à ce stade dans les notes de version. Ne comptez plus sur Purview pour ce type de charge de travail et compensez avec les contrôles natifs Azure SQL.
• Get-DlpCompliancePolicy renvoie un accès refusé : le rôle attribué ne couvre probablement que l'administration Exchange classique — vérifiez l'appartenance à un groupe de rôles Purview dédié à la conformité, pas seulement à Exchange Online.

Ce qu'il faut retenir

La direction est constante depuis plusieurs années : Microsoft Purview devient le plan de contrôle qui couvre les données Microsoft et non-Microsoft, plusieurs couches d'enforcement (endpoint, navigateur, réseau), ainsi que les assistants et agents IA. La portée et le débit de classification progressent en même temps que les capacités de preuve, d'investigation et de gouvernance administrative.

Concrètement, dès lundi matin :

• Exécutez le script d'audit ci-dessus pour identifier toutes les politiques DLP et d'auto-étiquetage encore en simulation dans votre tenant.
• Vérifiez si votre organisation dépend d'applications non-Microsoft (Box, Google Workspace) pour justifier une extension pilote de DLP/auto-étiquetage via les connecteurs Defender for Cloud Apps.
• Évaluez la nouvelle condition « External users » sur vos politiques Copilot Chat comme priorité anti prompt-injection.
• Configurez une date d'expiration sur vos attributions de groupes de rôles Purview les plus sensibles — c'est gratuit et immédiat.
• Ne présentez aucune capacité encore en preview (DLP réseau via Global Secure Access, connecteur Claude, apps non-Microsoft) comme un contrôle de production tant qu'elle n'a pas été validée en mode simulation sur un périmètre pilote.

Si votre organisation exploite déjà plusieurs applications IA hors Copilot (Claude, ChatGPT Enterprise, agents AWS Bedrock), l'urgence n'est plus d'ajouter des outils de gouvernance IA distincts, mais de vérifier que Purview couvre effectivement ces surfaces avant d'investir ailleurs.