Repérer les angles morts de conformité de Microsoft 365 avec Microsoft Graph

Par Mirko Peters · 2026-08-11

Bienvenue de retour dans le podcast et sur notre blog technique associé ! Si vous vous êtes déjà fié à un tableau de bord de conformité Microsoft 365 prêt à l’emploi en supposant que tout était en ordre…

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

Titelbild: Uncovering M365 Compliance Blindspots with Microsoft Graph

Bienvenue dans le podcast et sur notre blog technique associé ! Si vous vous êtes déjà fié à un tableau de bord de conformité Microsoft 365 par défaut en pensant que tout était pris en compte, vous risquez de vivre avec un faux sentiment de sécurité. Les tableaux de bord de conformité par défaut sont conçus comme des synthèses, pas comme la vérité absolue. Les signaux critiques, comme les détections de prévention des pertes de données (DLP), les actions eDiscovery et les alertes de sécurité sous-jacentes, se trouvent souvent derrière des points de terminaison Microsoft Graph qui exigent des autorisations distinctes, des paramètres de requête avancés et un assemblage rigoureux des données. Dans cette analyse approfondie, nous allons examiner pourquoi vos rapports natifs omettent des informations cruciales, identifier les points de terminaison Graph exacts à interroger et vous montrer comment acheminer ces preuves brutes directement vers Microsoft Purview pour un reporting clair et défendable. Pour écouter notre discussion complète sur ce sujet, n’hésitez pas à consulter l’épisode de podcast associé : Find Missing Microsoft 365 Compliance Data with Graph.

Vue d’ensemble

Les tableaux de bord de conformité par défaut sont des synthèses, pas la vérité. Les signaux critiques (détections DLP, actions eDiscovery, alertes de sécurité) se trouvent souvent derrière des points de terminaison Graph dotés d’autorisations distinctes. Nous identifions les API, les périmètres et les schémas de script exacts permettant d’extraire des preuves complètes et de les centraliser dans Purview pour un reporting clair et défendable.

À qui cela s’adresse

Responsables conformité, juridique et risques ayant besoin de preuves prêtes pour un audit
Administrateurs M365 et Entra qui conçoivent les reportings et l’automatisation
Équipes de sécurité qui corrèlent la télémétrie DLP, eDiscovery et des alertes

Les angles morts (pourquoi les tableaux de bord natifs passent à côté)

Agrégation et décalage : les synthèses de l’interface omettent les détails imbriqués des incidents et l’activité récente
Lacunes de périmètre : les actions eDiscovery et les correspondances DLP peuvent se situer en dehors des exports standard
Autorisations fractionnées : les points de terminaison /security et /compliance exigent des périmètres différents
Absence de jointures : les tableaux de bord corrèlent rarement les incidents avec les utilisateurs, les dépositaires ou les étapes de dossier

Les points de terminaison Graph à forte valeur ajoutée (liste à copier)

Alertes de sécurité (vue d’ensemble)
- Point de terminaison : /security/alerts ou /security/alerts_v2
- Autorisations d’application (exemples) : SecurityEvents.Read.All (ou Alerts.Read.All dans les modèles plus récents)
- Utilisation : chronologies des alertes, gravité, statut, affectations
Stratégies et activité DLP (perte de données)
- Points de terminaison (la disponibilité varie selon le locataire) :
  - /security/dataLossPreventionPolicies (inventaire des stratégies)
  - /security/dlpIncidents ou points de terminaison avancés d’incidents DLP dans l’espace de noms security (selon le locataire)
- Autorisations d’application : SecurityEvents.Read.All (et/ou les autorisations de lecture DLP spécifiques disponibles)
- Utilisation : correspondances, emplacements (Exchange, SharePoint, Teams), décision
eDiscovery (dossiers et actions)
- /compliance/ediscovery/cases
- Chemins enfants : /custodians, /searches, /reviewSets, /noncustodialDataSources, /operations
- Autorisations d’application : eDiscovery.Read.All (et en écriture si vous gérez les dossiers)
- Utilisation : statut des dossiers, conservations, dépositaires, exports, actions des réviseurs
Audit et contexte de connexion (preuves complémentaires)
- /auditLogs/directoryAudits, /auditLogs/signIns
- Autorisations d’application : AuditLog.Read.All, Directory.Read.All
- Utilisation : qui a modifié quoi et quand, contexte des sessions

Astuce : de nombreuses charges utiles de conformité sont profondément imbriquées. Prévoyez d’utiliser $expand, de paginer via @odata.nextLink et de joindre les données à /users/{id} pour obtenir les noms d’affichage et les services.

Authentification et autorisations (la voie sans complication)

Utilisez les autorisations d’application (principal de service) pour les tâches non supervisées
Enregistrez des applications distinctes pour la sécurité et pour Graph principal si votre organisation impose une séparation des privilèges
N’accordez que les périmètres de moindre privilège et stockez les secrets et certificats dans Key Vault
Mettez en œuvre une temporisation exponentielle (exponential backoff) pour les erreurs 429 et 503 et consignez x-ms-request-id dans les journaux

Modèles de scripts (PowerShell ou Python)

Select et expand : ne demandez que les champs nécessaires, avec $select=… et $expand=… pour les entités imbriquées
Filtrer et délimiter dans le temps : $filter=createdDateTime ge {ISO8601} pour les deltas
Paginer : bouclez sur @odata.nextLink ; ne supposez jamais que les résultats tiennent sur une seule page
Normaliser : associez dès le départ les identifiants d’utilisateurs et d’objets à leurs noms et services, pour obtenir des sorties lisibles
Joindre pour le contexte : enrichissez les incidents avec les métadonnées d’utilisateur, de site, d’équipe ou de dossier avant l’export

Intégration dans Purview (transformer les données en décisions)

Standardiser la sortie : CSV ou JSON avec des noms de champs cohérents (tenant, incidentId, workload, userId, userUPN, severity, status, created, lastAction, caseId)
Ingérer : déposez les fichiers dans un emplacement de stockage sécurisé que Purview peut lire (par exemple, ADLS Gen2)
Baliser et étiqueter : appliquez des étiquettes de confidentialité ou des balises personnalisées (par exemple « DLP-PII-High ») pour le routage
Tableaux de bord : Purview (ou Power BI sur les données Purview) pour les tendances, les responsables et l’ancienneté des SLA
Automatisations : règles pour notifier les responsables de dossiers en cas de récidive ou d’escalade ; synthèses PDF hebdomadaires

Pilote de 30 minutes (étape par étape)

0–10 min : enregistrement de l’application + SecurityEvents.Read.All / eDiscovery.Read.All ; créez un secret ou un certificat
10–20 min : scriptez un point de terminaison (alertes ou dossiers) avec pagination + $filter pour les 7 derniers jours
20–30 min : enrichissez avec /users, exportez en CSV, déposez le fichier dans le chemin ADLS et affichez un graphique simple

Les KPI qui prouvent la valeur

% d’incidents dont le responsable et la décision de traitement sont renseignés
Délai moyen entre l’incident et la création du dossier (ou la revue par un relecteur)
Comptes et emplacements récidivistes par période de 30 jours
Écart avec les compteurs du tableau de bord par défaut (réduction des écarts)
Durée du cycle d’audit (heures de préparation des preuves économisées)

Pièges courants (et solutions)

Résultats vides → périmètres incorrects, ou utilisation de l’autorisation déléguée là où l’autorisation d’application est requise
Détails manquants → $expand oublié ou collections imbriquées non analysées
Données partielles → pas de pagination ; seule la première page est récupérée
Incohérences de noms → pas de jointure d’enrichissement avec /users ni avec les données RH
Tableaux de bord obsolètes → pas d’exécutions planifiées ; ajoutez une tâche et une alerte en cas d’échec

Gains rapides de la semaine

Récupérez les 7 derniers jours depuis /security/alerts et comparez les volumes avec ceux du portail
Exportez les dossiers eDiscovery ouverts ainsi que leurs dépositaires, puis partagez-les avec le service juridique pour validation
Lancez un balayage des incidents DLP, identifiez les récidives par une balise et ouvrez les actions de suivi dans Purview
Planifiez un lot de preuves hebdomadaire (CSV + PDF) envoyé à une boîte aux lettres de conformité

Questions fréquentes

Faut-il être développeur ? Non : PowerShell ou de courts scripts Python suffisent.
Pourquoi des autorisations d’application ? La plupart des points de terminaison /security et /compliance exigent un accès sans interface utilisateur et à haute confiance.
Puis-je rester dans PowerShell ? Oui : utilisez le SDK PowerShell Microsoft Graph et gérez $top, $filter, $expand et la pagination.
Purview est-il indispensable ? Pas strictement, mais il transforme le JSON brut en flux de travail auditables et en tableaux de bord.

Conclusion

Les tableaux de bord synthétisent, Graph raconte toute l’histoire. Interrogez les bons points de terminaison, corrigez l’authentification, paginez et développez les données, puis centralisez le tout dans Purview. Vous passerez d’une conformité de pure forme à une visibilité démontrable et en temps réel, sans vous noyer dans les exports manuels. Pour une discussion approfondie et des conseils d’experts sur la façon de traiter directement ces angles morts, écoutez notre épisode de podcast dédié Find Missing Microsoft 365 Compliance Data with Graph. Continuez à itérer sur vos scripts, sécurisez vos autorisations d’application et commencez à faire remonter les données que vos tableaux de bord dissimulaient !