Introduction
Le rythme des mises à jour Microsoft 365 ne ralentit pas, et certaines évolutions récentes méritent une attention particulière côté administration. Cinq changements retiennent l'attention ce mois-ci : trois dans Microsoft Purview, un dans Microsoft Entra ID, et un dans SharePoint. Tous ont un impact direct sur la sécurité des données, la gestion des licences ou la gouvernance de marque.
Purview : les étiquettes de confidentialité activées par défaut sur groupes et sites
Dans Microsoft Purview (purview.microsoft.com), la fonctionnalité de contrôle d'accès pour les groupes et les sites lors de la création d'une étiquette de confidentialité était historiquement grisée. Il fallait activer des commandes PowerShell spécifiques pour la débloquer — une étape souvent oubliée, donc une faille de sécurité potentielle.
Ce paramètre est désormais actif par défaut. Concrètement, lors de la création d'une étiquette (menu Information Protection > Create > Label), l'option « Groups & sites » est directement accessible. Elle s'applique à :
- Les groupes de sécurité
- Les sites SharePoint
- Les groupes Microsoft 365 (donc les équipes Teams associées)
Pour chaque étiquette, l'administrateur peut désormais configurer :
- Le contrôle d'accès et de confidentialité (privé/public)
- Le marquage de contenu (filigrane, pied de page, en-tête)
- Le filigrane dynamique, personnalisable selon des critères (par exemple une couleur différente selon l'année)
- Le chiffrement double clé (DKE), réservé aux organisations disposant déjà d'une infrastructure de gestion des droits sur site (type Active Directory Rights Management Services)
- Les restrictions de partage externe, y compris pour les réunions Teams Premium
Prérequis DKE
Le chiffrement double clé ne fonctionne que si votre organisation dispose déjà d'une clé de chiffrement on-premises. Il combine cette clé locale avec la clé Azure, ce qui empêche Microsoft d'accéder seul au contenu déchiffré.
La vraie valeur ajoutée : ces étiquettes se combinent désormais avec les stratégies de prévention de la perte de données (DLP) via l'auto-étiquetage. Une règle peut, par exemple, détecter des informations sensibles US (données bancaires, cartes de crédit) et appliquer automatiquement l'étiquette ainsi que la politique DLP associée, sans intervention utilisateur. Sans auto-étiquetage, il faut compter sur un étiquetage manuel — ce qui implique formation des utilisateurs et changement de procédures, donc davantage de charge opérationnelle pour les équipes conformité.
Une fois l'étiquette appliquée à un groupe Microsoft 365 (visible dans Teams > Paramètres > Sensibilité), le contrôle s'exerce à la fois au niveau du groupe et au niveau du contenu individuel dans SharePoint.
Avant tout déploiement d'agents IA
Ces contrôles d'information protection et de DLP sont un prérequis avant tout déploiement d'agents IA ou de Copilot à grande échelle. Sans eux, le risque de fuite de données via des usages IA non maîtrisés augmente sensiblement.
Entra ID : le rapport « Licensing Coverage » pour l'accès conditionnel
Dans le blade Conditional Access de Microsoft Entra ID, une nouvelle section nommée Licensing Coverage fait son apparition. Objectif : répondre à une question récurrente des administrateurs — ai-je suffisamment de licences pour appliquer telle stratégie d'accès conditionnel basée sur un appareil, une localisation ou une application ?
Ce rapport affiche :
- Le nombre de licences détenues, réparties par niveau (Entra ID P1, P2, Entra Suite, etc.)
- Des liens directs vers les articles associés sur learn.microsoft.com pour chaque fonctionnalité
- Un accès direct à l'achat ou à l'essai des licences manquantes
Où gérer vos licences ?
Ce positionnement dans Entra ID plutôt que dans le centre d'administration Microsoft 365 peut surprendre : l'attribution des licences reste gérée depuis admin.microsoft.com. Considérez ce rapport comme un outil de diagnostic, pas comme une console de gestion.
Cette fonctionnalité limite le risque de découvrir, après coup, qu'une stratégie d'accès conditionnel repose sur une fonctionnalité non couverte par les licences en place — un scénario fréquent lors d'audits de conformité.
DLP : un contrôle granulaire par service dans Purview
Dans Microsoft Purview > Data Loss Prevention > Policies, la création d'une nouvelle stratégie propose désormais un niveau de personnalisation nettement plus fin par emplacement. Auparavant, la tentation était grande de cocher tous les emplacements (SharePoint, OneDrive, appareils, etc.) et de conserver les réglages par défaut. Chaque emplacement dispose désormais de son propre jeu de règles.
| Emplacement | Nouveauté principale | Cas d’usage |
|---|---|---|
| SharePoint / OneDrive | Blocage/autorisation par domaine ou adresse SMTP, distinction accès anonyme vs externe authentifié | Bloquer le partage vers des domaines non approuvés tout en autorisant des partenaires identifiés |
| Appareils (Intune) | Règles par condition de document et action (audit, restriction, blocage) sur Edge et hors navigateur | Restreindre le copier-coller ou l’impression sur les appareils gérés |
| Transferts FTP/SFTP | Nouveau canal surveillable, avec blocage conditionné au réseau (corporate/VPN) | Empêcher l’exfiltration de fichiers confidentiels via des transferts de fichiers non chiffrés |
Pour SharePoint et OneDrive, l'action « restreindre ou chiffrer le contenu » permet désormais de créer de véritables listes d'autorisation et de blocage par domaine ou par adresse e-mail, avec un opérateur « is » ou « is not ». Une granularité bienvenue pour les organisations qui collaborent avec des partenaires externes sur certains sites tout en verrouillant d'autres domaines.
Côté appareils, les règles s'appliquent aussi bien aux activités dans le navigateur Edge qu'aux activités générales sur l'appareil (copier-coller, impression, etc.), avec un mode audit ou un mode blocage strict.
La vraie nouveauté du mois reste le support natif du FTP et SFTP comme canal surveillé par DLP. Il devient possible d'auditer ou de bloquer des transferts de fichiers confidentiels selon l'origine réseau (réseau corporate, VPN), un point aveugle fréquent des politiques DLP jusqu'ici centrées sur le cloud et la messagerie.
Piège fréquent
Cliquer trop vite sur « Next » lors de la création d'une politique DLP applique les réglages par défaut à tous les emplacements sélectionnés, y compris ceux non pertinents pour votre cas d'usage. Prenez le temps de personnaliser chaque emplacement individuellement.
SharePoint : un Brand Center pour centraliser les ressources de marque
Dernier point : le nouveau Brand Center, accessible depuis le centre d'administration Microsoft 365 (Settings > Organizational settings). Il répond à un besoin simple — centraliser logos, chartes graphiques et modèles pour éviter que chaque équipe recrée ses propres visuels lors de la création de sites, pages ou documents.
La création d'un Brand Center génère automatiquement :
- Un sous-site SharePoint dédié servant de catalogue de ressources
- Une application mobile associée pour un accès rapide aux ressources depuis un smartphone
Ce site fonctionne comme un réseau de diffusion de contenu (CDN) interne pour tous les éléments de marque de l'organisation. Une documentation dédiée est disponible sur learn.microsoft.com pour le déploiement complet.
Points clés à retenir
- Information Protection : le contrôle d'accès sur groupes et sites est actif par défaut, sans configuration PowerShell préalable — vérifiez vos étiquettes existantes pour tirer parti de cette activation.
- DKE exige une infrastructure de gestion des droits on-premises préexistante.
- Licensing Coverage dans Entra ID permet de valider la couverture licence d'une stratégie d'accès conditionnel avant son déploiement, sans remplacer le centre d'administration Microsoft 365 pour la gestion réelle des licences.
- DLP offre désormais un contrôle par domaine/adresse SMTP sur SharePoint et OneDrive, et surveille nativement les transferts FTP/SFTP.
- Le Brand Center de SharePoint centralise logos et chartes graphiques dans un site dédié, avec application mobile associée.
Prochaine étape concrète : auditez vos étiquettes de confidentialité existantes pour vérifier si le contrôle d'accès sur groupes et sites était jusqu'ici désactivé faute d'activation PowerShell, et testez le rapport Licensing Coverage avant votre prochain déploiement de stratégies d'accès conditionnel.
