Purview étend son bras armé au-delà de Microsoft 365
Jusqu'ici, Microsoft Purview cantonnait ses politiques de Data Loss Prevention (DLP) et d'étiquetage automatique aux données hébergées dans l'écosystème Microsoft 365 : Exchange Online, SharePoint Online, OneDrive et Teams. La notification de centre de messages MC1449180 (publiée le 6 août 2026, référencée sous l'identifiant de feuille de route Microsoft 365 roadmap 568075) change la donne : DLP et les politiques d'auto-étiquetage d'Information Protection peuvent désormais traiter des données stockées dans des applications non-Microsoft comme Google Workspace et Box.
La disponibilité en préversion est annoncée pour la mi-août 2026, la disponibilité générale pour début septembre 2026, avec un déploiement mondial complet attendu fin octobre 2026. Ce n'est pas une simple option à cocher dans un blade du portail : la mise en œuvre demande une vraie préparation technique et budgétaire.
Bon à savoir
Cette extension ne fonctionne pas de manière autonome. Elle repose entièrement sur les connecteurs de Microsoft Defender for Cloud Apps, qui servent d'interface entre Purview et les plateformes tierces.
Comprendre le rôle des connecteurs Defender for Cloud Apps
Pour que Purview puisse lire et agir sur des données hébergées ailleurs que dans Microsoft 365, il faut d'abord configurer un connecteur Microsoft Defender for Cloud Apps pour la plateforme cible. Dans le cas de Google Workspace, cela implique de configurer le connecteur Google Workspace — une opération qu'un administrateur Microsoft 365 ne peut pas réaliser seul.
Le connecteur récupère les listes d'utilisateurs, les activités et les fichiers de la plateforme cible. Une fois cette liaison établie, les politiques DLP peuvent cibler l'emplacement Managed cloud apps au même titre que SharePoint ou Exchange.
Obtenir les droits côté plateforme tierce
Demandez au titulaire du rôle Super Admin de Google Workspace (ou du rôle administrateur équivalent pour Box, Dropbox, Salesforce, ServiceNow, AWS ou Cisco Webex) de créer un projet et d'autoriser Defender for Cloud Apps à utiliser ses identifiants d'API.
Connecter l'application dans Defender for Cloud Apps
Dans le portail Microsoft Defender, section Cloud apps > Connected apps, ajoutez le connecteur correspondant à la plateforme cible et validez l'autorisation OAuth avec le compte administrateur tiers.
Créer ou adapter la politique Purview
Dans le portail Microsoft Purview, créez une politique DLP ou une politique d'auto-étiquetage et sélectionnez l'emplacement Managed cloud apps (Non-Microsoft cloud apps) parmi les emplacements ciblés.
Valider les actions disponibles
Vérifiez pour chaque application connectée quelles actions de politique sont réellement supportées avant de vous fier au comportement observé sur SharePoint ou OneDrive.
Rôle minimal requis
Côté Microsoft 365, la création et la modification de politiques DLP nécessitent au minimum le rôle Compliance Administrator ou Security Administrator dans Microsoft Entra ID. La configuration du connecteur Defender for Cloud Apps exige en plus des droits d'administration globale sur le tenant Microsoft, et un rôle de type Super Admin sur la plateforme tierce.
Calendrier de disponibilité
Le déploiement suit un calendrier échelonné, ce qui laisse le temps de planifier la préversion avant la bascule en production :
| Phase | Date annoncée | Portée |
|---|---|---|
| Préversion | Mi-août 2026 | Disponible pour tests ciblés |
| Disponibilité générale (GA) | Début septembre 2026 | Activation standard |
| Déploiement mondial complet | Fin octobre 2026 | Tous les tenants concernés |
Quelles actions DLP et Information Protection sont réellement disponibles
Microsoft est clair sur un point : « les conditions et actions de politique disponibles varient selon l'application ». Il ne faut donc pas s'attendre à retrouver, sur Google Workspace ou Box, le même arsenal d'actions que sur SharePoint Online. Par exemple, l'action DLP de mise en quarantaine suppose un stockage SharePoint et n'a probablement pas d'équivalent sur des plateformes tierces.
| Plateforme connectée | Politiques DLP | Auto-étiquetage Information Protection |
|---|---|---|
| Google Workspace | Oui | Oui |
| Box | Oui | Oui |
| Dropbox | Oui | Non |
| Salesforce | Oui | Non |
| ServiceNow | Oui | Non |
| AWS | Oui | Non |
| Cisco Webex | Oui | Non |
La documentation détaille les actions supportées par connecteur. Testez systématiquement le comportement réel en préversion avant de communiquer une promesse de conformité à vos équipes sécurité.
Le piège des anciennes stratégies de fichiers Cloud App Security
Conflit de politiques
Si vous exploitez déjà des file policies Defender for Cloud Apps sur les mêmes plateformes tierces, désactivez-les ou supprimez-les avant de déployer les politiques Purview équivalentes. Faire fonctionner les deux mécanismes en parallèle expose à un « unexpected policy enforcement » — des actions appliquées de manière incohérente ou en double.
Ce point n'est pas cosmétique : Microsoft a fixé la retraite des file policies au 6 janvier 2027 et recommande explicitement de migrer vers les politiques Purview. Toute organisation qui utilise encore ces anciennes stratégies dispose donc d'une fenêtre limitée pour planifier sa bascule, indépendamment de l'intérêt qu'elle porte à l'extension vers les applications non-Microsoft.
Vérifier la configuration avec PowerShell
Avant de valider un déploiement en production, contrôlez que vos politiques DLP couvrent bien l'emplacement Managed cloud apps via le module ExchangeOnlineManagement (Security & Compliance PowerShell) :
1Connect-IPPSSession -UserPrincipalName admin@contoso.com2 3Get-DlpCompliancePolicy | Where-Object { $_.ThirdPartyAppsLocation -ne $null } |4 Select-Object Name, Mode, ThirdPartyAppsLocationPour inspecter les règles rattachées à une politique ciblant les applications tierces et vérifier les actions activées :
1Get-DlpComplianceRule -Policy "Protection donnees Google Workspace" |2 Select-Object Name, BlockAccess, GenerateIncidentReport, NotifyUserCôté auto-étiquetage, listez les politiques existantes et leur périmètre (workload) :
1Get-AutoSensitivityLabelPolicy | Select-Object Name, Mode, Workload, EnabledEnfin, vérifiez que les utilisateurs concernés disposent bien de la licence requise via le module Microsoft.Graph (PowerShell SDK v2.x) :
1Connect-MgGraph -Scopes "User.Read.All"2 3Get-MgUserLicenseDetail -UserId user@contoso.com | Select-Object SkuPartNumberUn SkuPartNumber correspondant à une offre E5 Compliance ou E5 Information Protection and Governance confirme que l'utilisateur est correctement licencié pour bénéficier du service.
Le calcul du coût : licences et facturation Purview At Rest Protection
Le coût de cette extension se décompose en deux postes distincts, et aucun des deux n'est négligeable à l'échelle d'un tenant :
| Poste de coût | Détail | Remarque |
|---|---|---|
| Licence Purview Enterprise tier | Probablement Microsoft 365 E5 Compliance ou E5 Information Protection and Governance | Microsoft n'a pas encore publié de guide de licence détaillé |
| Purview At Rest Protection | Service Azure facturé au pay-as-you-go | 1 000 fichiers non-Microsoft = 1 « data asset », soit environ 0,50 $ par mois |
Le coût total additionne donc les licences E5 nécessaires pour les utilisateurs concernés et les frais At Rest Protection proportionnels au volume de fichiers ingérés depuis les connecteurs. Sur un tenant qui synchronise des dizaines de milliers de fichiers Google Drive ou Box, la facture mensuelle At Rest Protection peut vite dépasser le coût des licences elles-mêmes.
Astuce budget
Demandez un chiffrage précis auprès d'un spécialiste licensing Microsoft avant tout engagement : la documentation actuelle reste imprécise sur le mapping exact entre offres E5 et fonctionnalités « non-Microsoft applications ».
Dépannage : erreurs fréquentes
- La politique DLP ne montre pas l'emplacement « Managed cloud apps » : vérifiez qu'au moins un connecteur Defender for Cloud Apps est actif et en état « connecté » pour la plateforme visée ; sans connecteur opérationnel, l'emplacement reste grisé.
- Erreur d'autorisation lors de la connexion du connecteur : le jeton OAuth accordé par le Super Admin Google Workspace (ou l'équivalent) a pu expirer ou être révoqué ; il faut relancer le processus de consentement depuis le portail Defender.
- Actions incohérentes ou en double sur les fichiers : signe classique d'un conflit entre une ancienne file policy Cloud App Security encore active et une nouvelle politique Purview ciblant le même emplacement ; désactivez la première.
- Aucune donnée remontée après configuration : la synchronisation initiale des connecteurs peut prendre plusieurs heures ; patientez avant de conclure à un échec de configuration.
Faut-il déployer cette extension Purview ?
Importer des données Google Workspace ou Box dans Azure pour que Purview puisse les traiter n'est clairement pas une manœuvre destinée au tenant Microsoft 365 moyen. C'est une fonctionnalité pensée pour les grandes organisations qui gèrent des informations sensibles réparties sur plusieurs plateformes cloud et qui ont besoin d'une stratégie DLP unifiée.
Pour ces environnements multi-cloud, la complexité de configuration et le coût récurrent peuvent se justifier au regard des risques de fuite de données évités. Pour la majorité des tenants Microsoft 365, en revanche, la combinaison connecteurs + licences E5 + facturation At Rest Protection en fait plutôt une solution de niche, à réserver aux cas d'usage réellement multi-plateformes.
Points clés à retenir
- Purview DLP et l'auto-étiquetage s'étendent désormais à Google Workspace, Box et d'autres applications tierces via les connecteurs Microsoft Defender for Cloud Apps.
- La configuration nécessite l'intervention d'un administrateur avec des droits élevés sur la plateforme tierce, en plus des rôles Purview côté Microsoft 365.
- Les actions de politique disponibles varient selon l'application connectée : testez-les avant de vous engager.
- Désactivez impérativement les anciennes file policies Defender for Cloud Apps avant d'activer les politiques Purview équivalentes ; elles seront retirées le 6 janvier 2027.
- Le coût combine licences E5 et facturation Purview At Rest Protection au « data asset » (1 000 fichiers = 0,50 $/mois) — à chiffrer précisément avant tout déploiement en production.