Vos équipes régionales ou vos filiales voudraient gérer leurs propres stratégies DLP pour Copilot, sans toucher à celles du tenant ? C’est précisément ce que Microsoft annonce dans le message center MC1486284 : la prise en charge des unités administratives de Microsoft Entra ID pour les stratégies Microsoft Purview Data Loss Prevention (DLP) qui ciblent Microsoft Copilot et Copilot Chat. Cet article détaille le calendrier, le périmètre de la délégation, les contraintes qui restent valables et les audits à lancer dès aujourd’hui pour être prêt.
Ce qui change entre fin octobre et début novembre 2026
À la date de rédaction (4 octobre 2026), la fonction n’est pas encore disponible. Les pages Microsoft Learn consultées indiquent toujours que l’emplacement de stratégie « Microsoft 365 Copilot and Copilot Chat » ne prend pas en charge les unités administratives. Le déploiement décrit par MC1486284 concerne les environnements Worldwide, GCC, GCC High et DoD.
Mai 2026
DSPM et unités administratives
Selon la page des nouveautés Purview, la gestion de la posture de sécurité des données (DSPM) prend en charge les unités administratives, par parité avec DSPM classique et DSPM for AI.
Juin 2026
Condition sur les e-mails externes (préversion)
La condition « Email is received from > External users » entre en préversion pour la protection DLP de Copilot.
Fin octobre 2026
Début du déploiement MC1486284
Les unités administratives deviennent utilisables pour les stratégies DLP Copilot, sur Worldwide, GCC, GCC High et DoD.
Début novembre 2026
Fin prévue du déploiement
Microsoft prévoit d’avoir terminé à cette date. Aucune action n’est requise de votre part.
Le changement ne crée pas de nouveau modèle d’administration. Il prolonge le contrôle d’accès basé sur les rôles (RBAC) de Purview et les unités administratives existantes à un emplacement qui en était exclu jusqu’ici.
Ce qu’un administrateur délégué pourra faire (et ne pas faire)
Un administrateur limité à une unité administrative pourra créer, consulter, modifier et supprimer les stratégies DLP Copilot prises en charge dans son unité. Les stratégies à l’échelle du tenant et celles des autres unités lui restent inaccessibles.
| Sujet | Administrateur limité à une unité | Administrateur sans restriction |
|---|---|---|
| Stratégies de sa propre unité | Création, lecture, modification, suppression | Oui, selon ses rôles Purview |
| Stratégies à l’échelle du tenant | Modification impossible | Oui, selon ses rôles Purview |
| Stratégies d’une autre unité | Gestion impossible | Oui, selon ses rôles Purview |
| Applicabilité de l’application des règles | Inchangée | Inchangée |
Le moteur d’application ne change pas : seule la délégation de gestion évolue. Les utilisateurs finaux ne voient aucun nouveau parcours, et les stratégies tenant-wide continuent de fonctionner comme aujourd’hui.
Le rôle Purview reste obligatoire
La référence des stratégies DLP précise qu’un administrateur restreint à une unité ne cible que ses propres unités, et qu’il doit en plus appartenir à un rôle ou groupe de rôles qui administre le DLP, par exemple Compliance administrator ou Information Protection Admin. L’unité limite le périmètre, elle ne donne aucun droit par elle-même. Le rôle Purview Data Security AI Admin permet de modifier les stratégies DLP liées à Copilot, sans accès au contenu des prompts et réponses.
Comment le périmètre est évalué : par l’utilisateur, pas par le contenu
La frontière d’unité administrative est déterminée par l’utilisateur qui lance l’interaction Copilot, et non par le propriétaire ou l’emplacement de stockage du contenu référencé. Copilot évalue chaque interaction face à l’ensemble des stratégies applicables : celles du tenant et celles de l’unité de l’utilisateur.
Concrètement, imaginons une organisation multi-filiales. Un utilisateur de la filiale A interroge Copilot sur un document stocké dans l’espace de la filiale B. Ce sont les stratégies de la filiale A (plus celles du tenant) qui s’appliquent à cette interaction, car l’initiateur est rattaché à A. Ce scénario est une illustration du principe décrit par Microsoft, pas un cas mesuré.
Cette règle a une conséquence de conception : l’appartenance des utilisateurs aux unités devient un élément de votre posture de sécurité. Un utilisateur placé dans la mauvaise unité hérite des mauvaises règles.
Les contraintes de l’emplacement Copilot restent valables
Une stratégie Copilot limitée à une unité administrative suivra les mêmes contraintes que n’importe quelle stratégie de cet emplacement. La documentation Microsoft Learn sur la DLP pour Microsoft 365 Copilot et Copilot Chat en liste plusieurs :
- l’emplacement Copilot n’existe que dans le modèle de stratégie Custom ; en le sélectionnant, tous les autres emplacements de la stratégie sont désactivés ;
- les alertes, les notifications et le mode simulation sont pris en charge ;
- les types d’informations sensibles (SIT) saisis dans le prompt peuvent bloquer le traitement ou la recherche web ;
- les fichiers et e-mails portant une étiquette de sensibilité sont couverts (e-mails envoyés à partir du 1er janvier 2025) ;
- les fichiers téléversés dans un prompt ne sont pas analysés : seul le texte saisi l’est.
Tony Redmond (Office 365 for IT Pros) ajoute dans son retour sur la stratégie DLP de Copilot et le blocage des recherches web que la stratégie par défaut « Protect sensitive M365 Copilot interactions » est livrée en mode simulation, et que les SIT créés par empreinte de document ne peuvent pas y être utilisés.
SIT et étiquettes : des règles distinctes
Les SIT et les étiquettes de sensibilité ne se combinent pas dans une même règle. Prévoyez deux règles par stratégie si vous couvrez les deux cas. Les mises à jour de stratégie peuvent aussi prendre jusqu’à quatre heures pour être prises en compte par Copilot : ne testez pas la modification dix minutes après l’avoir enregistrée.
Mise en œuvre : auditer vos unités administratives avant l’activation
Microsoft recommande de revoir la structure des unités et les affectations de rôles avant de déléguer. Les scripts ci-dessous sont en lecture seule : ils ne modifient rien. Ils ne créent pas de stratégie, car la fonction n’est pas encore déployée.
- Module :
Microsoft.Graph.Identity.DirectoryManagement(Microsoft Graph PowerShell), installé parInstall-Module Microsoft.Graph.Identity.DirectoryManagement -Scope CurrentUser. - Permissions déléguées minimales :
AdministrativeUnit.Read.AlletRoleManagement.Read.Directory. - Sortie : un tableau en console et un fichier CSV
audit-unites-administratives.csvavec, par unité, le nombre d’utilisateurs, de groupes et d’administrateurs délégués Entra.
1# Connexion avec les scopes en lecture seule2Connect-MgGraph -Scopes 'AdministrativeUnit.Read.All','RoleManagement.Read.Directory' -NoWelcome3 4# Parcours de toutes les unités administratives du tenant5$rapport = foreach ($au in Get-MgDirectoryAdministrativeUnit -All) {6 # Membres de l'unité (utilisateurs, groupes, appareils)7 $membres = @(Get-MgDirectoryAdministrativeUnitMember -AdministrativeUnitId $au.Id -All)8 $utilisateurs = @($membres | Where-Object { $_.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.user' })9 $groupes = @($membres | Where-Object { $_.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.group' })10 11 # Administrateurs auxquels un rôle Entra est délégué sur cette unité12 $admins = @(Get-MgDirectoryAdministrativeUnitScopedRoleMember -AdministrativeUnitId $au.Id -All)13 14 [pscustomobject]@{15 UniteAdministrative = $au.DisplayName16 Id = $au.Id17 Utilisateurs = $utilisateurs.Count18 Groupes = $groupes.Count19 AdminsDelegues = $admins.Count20 }21}22 23# Affichage et export24$rapport | Sort-Object UniteAdministrative | Format-Table -AutoSize25$rapport | Export-Csv -Path .\audit-unites-administratives.csv -NoTypeInformation -Encoding UTF8Les affectations Entra visibles ici ne remplacent pas la revue des groupes de rôles Purview, qui se fait dans le portail Microsoft Purview. Vérifiez que chaque administrateur n’est rattaché qu’aux unités qu’il gère.
Pour inventorier les stratégies DLP existantes avant d’en créer de nouvelles, utilisez le module ExchangeOnlineManagement avec un compte membre d’un rôle DLP (par exemple Compliance administrator).
1# Connexion au service Security & Compliance2Connect-IPPSSession3 4# Inventaire des stratégies DLP du tenant avec leur mode5Get-DlpCompliancePolicy | Select-Object Name, Mode, Comment | Sort-Object Name | Format-Table -AutoSizePour examiner une seule unité, deux approches équivalentes :
1# Remplacez la valeur par l'identifiant d'une unité relevé dans le CSV2$auId = '00000000-0000-0000-0000-000000000000'3Get-MgDirectoryAdministrativeUnitMember -AdministrativeUnitId $auId -All |4 Select-Object Id, @{n='Type';e={$_.AdditionalProperties['@odata.type']}}Vérifier le résultat et diagnostiquer les écarts
Une fois la fonction disponible dans votre tenant, validez le comportement en mode simulation avant d’appliquer un blocage. Microsoft recommande de démarrer en simulation et d’appliquer le moindre privilège.
Contrôles après déploiement
- Un administrateur de test limité à une unité voit et modifie uniquement les stratégies de cette unité
- Le même compte ne peut pas modifier une stratégie du tenant ni celle d’une autre unité
- Une interaction Copilot d’un utilisateur de l’unité déclenche bien la stratégie en simulation
- Les alertes et rapports d’incident sont activés avant de passer le mode à « On »
- Au moins quatre heures se sont écoulées entre la dernière modification et le test
| Symptôme | Cause probable | Résolution |
|---|---|---|
| L’administrateur d’unité ne voit aucune stratégie | Il n’appartient à aucun rôle ou groupe de rôles DLP, ou la stratégie n’est pas dans son unité | Ajouter un rôle DLP adapté (Compliance administrator, Information Protection Admin) et vérifier l’unité cible |
| La modification n’a aucun effet | Délai de propagation, jusqu’à quatre heures | Attendre, puis retester avec un utilisateur de l’unité |
| Un fichier téléversé dans le prompt n’est pas bloqué | Seul le texte saisi est analysé | Compléter par des contrôles sur le stockage, ou par des règles sur les étiquettes de sensibilité |
| Impossible de combiner SIT et étiquette | Limite de l’emplacement Copilot | Créer des règles distinctes dans la même stratégie |
| Un SIT par empreinte de document est refusé | Non pris en charge par la stratégie Copilot | Utiliser un autre type de SIT |
Questions fréquentes
Faut-il agir si nous n’utilisons pas les unités administratives ?
Non. Microsoft indique qu’aucune action n’est requise et que les organisations sans unités administratives n’ont pas à modifier leurs stratégies Copilot existantes. Les stratégies à l’échelle du tenant continuent de fonctionner comme aujourd’hui.
Quelle licence faut-il pour cette fonction ?
Le message center précise que les exigences de licence de Microsoft Purview DLP et de Microsoft Copilot continuent de s’appliquer, sans ajouter de licence propre à cette évolution. Pour comparer les éditions, consultez notre matrice de licences Purview DLP.
Les utilisateurs finaux verront-ils une différence ?
Non. Aucun nouveau parcours n’est introduit pour eux. Copilot continue d’évaluer chaque interaction face aux stratégies du tenant et à celles de l’unité de l’utilisateur.
Le contenu stocké dans une autre unité change-t-il la stratégie appliquée ?
Non. La frontière est déterminée par l’utilisateur qui initie l’interaction, pas par le propriétaire ou l’emplacement du contenu référencé.
Par où commencer
Le déploiement n’exige aucune action, mais la délégation ne vaut que si vos unités et vos rôles sont propres. Préparez le terrain avant la fin octobre 2026.
Prochaines actions
- Exécuter le script d’audit et corriger les unités vides ou mal peuplées
- Revoir les groupes de rôles Purview : chaque administrateur n’est affecté qu’aux unités qu’il gère
- Passer en revue vos stratégies DLP Copilot tenant-wide avant d’en créer par unité
- Si la stratégie par défaut « Protect sensitive M365 Copilot interactions » est en simulation, retirer les SIT inutiles, ajouter ceux qui manquent et activer les rapports d’incident
- Planifier des tests en mode simulation dès que la fonction apparaît dans votre tenant
Si votre organisation est centralisée, gardez une administration unique : Microsoft Education le recommandait tant que la prise en charge n’existait pas, et la délégation n’apporte rien sans équipes locales à responsabiliser. Si vous gérez plusieurs entités avec des contraintes réglementaires distinctes, la délégation par unité devient pertinente, à condition d’avoir fiabilisé l’appartenance des utilisateurs. Pour situer ce chantier dans l’ensemble, notre carte de la gouvernance des données Purview et notre point sur Purview en septembre 2026 donnent le contexte, et le dossier sur la DLP réseau et les IA non gérées couvre l’autre face de la protection contre les fuites vers l’IA.
Pour aller plus loin
- Microsoft Purview DLP for Microsoft 365 Copilot and Copilot Chat : conditions, actions, limites et rôles requis pour les stratégies Copilot.
- Data Loss Prevention policy reference : différence entre administrateur sans restriction et administrateur restreint à une unité.
- Administrative units in Microsoft Purview : fonctionnement des unités administratives dans Purview.
- DLP Policy for Copilot Can Block Web Searches : retour d’expérience de Tony Redmond sur la stratégie par défaut.
- What’s new in Microsoft Purview : suivi des nouveautés Purview, dont DSPM et les unités administratives.