Monter en charge : gérer la pagination, la limitation de débit et les audits de grands locataires M365

Par Mirko Peters · 2026-08-11

Bienvenue de nouveau sur le blog ! Si vous gérez un environnement Microsoft 365 de grande envergure, vous savez déjà que les outils de reporting standard, prêts à l’emploi, ne font qu’effleurer la su…

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

Titelbild: Scaling Up: Managing Pagination, Throttling, and Large Tenant M365 Audits

Bienvenue sur le blog ! Si vous gérez un environnement Microsoft 365 de grande ampleur, vous savez déjà que les outils de reporting standard, prêts à l'emploi, ne font qu'effleurer la surface. Lorsque les équipes de sécurité et les responsables de la conformité examinent des locataires de très grande taille, les scripts de base et les vues du centre d'administration échouent tout simplement sous le poids de milliers d'utilisateurs, de groupes et de fichiers. Auditer des locataires M365 massifs exige plus que des scripts basiques : cela demande une approche tactique et programmatique reposant sur l'API Microsoft Graph. Dans ce guide complet, nous prolongeons directement notre échange récent dans l'épisode de podcast Map Microsoft 365 Users, Groups, Files, and Shares with Graph. Entrons dans le détail de la gestion de la pagination @odata.nextLink, du respect des limites de débit 429 grâce à un backoff exponentiel, et de l'évitement de pièges courants comme le biais de la page 1, afin d'obtenir une visibilité totale sur le locataire.

Introduction aux défis de l'audit M365

Les environnements d'entreprise se développent de manière organique. Les utilisateurs arrivent et partent, des projets créent des services du jour au lendemain, et des prestataires externes sont invités dans des espaces de collaboration. Avec le temps, la visibilité administrative se dégrade. Les centres d'administration par défaut ne montrent que des fragments isolés de votre infrastructure, laissant des angles morts que des acteurs malveillants ou des initiés involontaires peuvent exploiter. Pour obtenir une image fidèle de la posture de sécurité de votre locataire, vous devez passer d'un audit manuel, point et clic, à un parcours automatisé des graphes via l'API. Toutefois, passer ces requêtes à l'échelle de l'entreprise soulève des difficultés complexes : volumes de données massifs, limitation de débit agressive et structures relationnelles profondément imbriquées.

Pourquoi M365 n'est pas isolé : comprendre l'accès relationnel

L'une des réalités fondamentales de Microsoft 365 est que des services comme SharePoint, Teams et OneDrive ne sont pas des silos isolés. Ils se croisent en permanence via l'appartenance aux groupes et les listes de contrôle d'accès sous-jacentes. Une seule action d'administration, comme l'ajout d'un utilisateur à un groupe de sécurité, peut se propager à des dizaines de sites d'équipe, de bibliothèques de documents et de canaux privés, sans laisser de trace d'audit évidente dans les vues standard.

Cela crée des risques de conformité cachés. Des liens d'invité partagés dans des conversations isolées, des fichiers dupliqués dans différentes bibliothèques d'équipe et des partages orphelins issus de projets depuis longtemps terminés ouvrent des chemins invisibles vers vos données d'entreprise. Dans M365, l'accès est fondamentalement relationnel, et non lié à un emplacement. Pour auditer efficacement, vous devez cartographier ces relations en cascade plutôt que de traiter chaque service comme une île indépendante.

Cartographier l'empreinte avec Graph Explorer

Avant d'écrire une automatisation à l'échelle de l'entreprise, il faut savoir retracer manuellement l'empreinte d'un utilisateur à l'aide de Graph Explorer. Construire vos requêtes pas à pas garantit la solidité de votre logique avant d'écrire la moindre ligne de code. Voici la marche à suivre pour cartographier les points de contact d'un utilisateur :

Partir de l'utilisateur : commencez par récupérer l'objet utilisateur principal avec GET /v1.0/users/{userPrincipalName}?$select=id,displayName,userPrincipalName.
Énumérer les appartenances : récupérez les groupes et les rôles liés à cette identité avec GET /v1.0/users/{id}/memberOf?$select=id,displayName.
Remonter vers les ressources de ces groupes : pour les groupes Microsoft 365 et les équipes, ciblez le site SharePoint sous-jacent avec GET /v1.0/groups/{groupId}/drive/root/children?$select=id,name,lastModifiedDateTime,webUrl, ou énumérez directement les bibliothèques du site via GET /v1.0/sites/{siteId}/drives.
Récupérer les autorisations et les liens des éléments : inspectez l'accès à un fichier précis avec GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$select=id,grantedToV2,link,roles,shareId.
Retracer qui a accédé à quoi : corrélez les actions des utilisateurs à l'aide des journaux de connexion ou des alertes de sécurité, associés au contexte des fichiers et des sites.
Boucler avec les messages Teams : recherchez dans les messages des canaux les références à un fichier précis avec GET /v1.0/teams/{teamId}/channels/{channelId}/messages?$search="filename" (en gardant à l'esprit les autorisations et les prérequis de la version bêta).

Filtres anti-bruit que vous utiliserez vraiment

Interroger Microsoft Graph sans filtres revient à se noyer rapidement sous un flux massif de données. Pour faire ressortir les risques réels, il faut des stratégies de filtrage précises. Voici les schémas de requête à déployer :

Partages externes au cours des 7 derniers jours : ciblez les liens anonymes ou accessibles à toute l'organisation à l'aide de GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$filter=link/scope eq 'anonymous' ou link/scope eq 'organization'.
Uniquement les types de fichiers à risque : ajoutez des filtres tels que $filter=endsWith(resourceReference/name,'.xlsm') ou endsWith(resourceReference/name,'.pst') pour repérer les macros et les archives.
Mentions de termes sensibles en dehors des heures de bureau dans Teams : recherchez dans les messages de canal des termes tels que confidentiel, puis filtrez les résultats selon les horodatages de création situés en dehors des horaires de bureau habituels.
Limitez la taille des charges utiles : incluez toujours les paramètres $select afin de ne renvoyer que les identifiants, noms, URL et horodatages nécessaires.
Plafond pour le tri : utilisez $top=50 pour les contrôles ponctuels rapides, mais supprimez ce paramètre lors des exports complets vers votre magasin de données.

Incontournables à grande échelle : pagination et limitation de débit

Lorsque vous auditez un locataire comptant des centaines de milliers d'objets, vos scripts se heurteront à des obstacles s'ils ne tiennent pas compte des limites de l'API et de la pagination. Vous n'avez jamais fini de récupérer les données tant que vous n'avez pas suivi la propriété @odata.nextLink pour chaque page renvoyée par l'API. L'ignorer signifie que vos scripts ne captureront que le premier lot de résultats, en passant complètement à côté du reste de votre locataire.

Vous devez par ailleurs respecter les réponses HTTP 429 (limitation de débit). Mettez en œuvre une logique robuste de backoff exponentiel afin que votre script marque une pause, attende la fin de la période de refroidissement, puis reprenne sans accroc là où il s'était arrêté. Regroupez judicieusement vos requêtes en privilégiant un nombre réduit de requêtes logiques plus volumineuses, et mettez en cache les correspondances groupe-site. Pour les locataires très volumineux, partitionnez vos parcours par site ou par plage de dates, et planifiez-les en dehors des heures de pointe afin de ne pas affecter les performances de production.

Pièges courants et correctifs rapides

Même les administrateurs chevronnés se heurtent à des obstacles lorsqu'ils étendent leurs audits M365. Voici les pièges les plus fréquents et la manière de les corriger :

Piège : les exports CSV dérivent à mesure que les schémas évoluent. Correctif : utilisez directement l'API Graph avec des transformations versionnées et gérez les champs inconnus avec souplesse.
Piège : les identifiants mixtes, comme les GUID et les noms d'utilisateur principaux (UPN), rompent les jointures de bases de données. Correctif : normalisez toutes les données dans un modèle sémantique cohérent couvrant les utilisateurs, les groupes, les sites, les lecteurs, les éléments et les autorisations.
Piège : le biais de la première page masque la majorité des incidents de sécurité enfouis plus profondément dans les résultats. Correctif : journalisez systématiquement le nombre total de pages traitées et configurez des alertes si le volume de données attendu chute brusquement.
Piège : les flots de fichiers non pertinents ralentissent les moteurs de traitement. Correctif : appliquez des filtres stricts sur les étendues de partage, les fenêtres temporelles et les listes de termes sensibles.
Piège : les partages Teams sont déconnectés des fichiers sous-jacents. Correctif : corrélez directement les URL web des messages de canal aux éléments de lecteur, et stockez ces deux identifiants ensemble.

Indicateurs clés de performance (KPI) pour la direction rendus possibles

Les données techniques n'ont de valeur que si vous pouvez les traduire en informations commerciales exploitables pour la direction. La mise en place d'un pipeline d'audit Graph automatisé ouvre la voie à de puissants KPI pour les dirigeants :

Vitesse d'exposition externe : mesurez le nombre de nouveaux liens d'invité créés par semaine, ventilés par site et par équipe.
Taux de consultation de contenus sensibles : suivez le nombre d'utilisateurs uniques consultant des contenus étiquetés, en distinguant les utilisateurs internes des invités externes.
Effet d'entraînement des groupes : mesurez les fichiers devenus accessibles dans les 24 heures suivant des modifications majeures de l'appartenance aux groupes.
Circulation parallèle : surveillez les fichiers sensibles apparaissant dans plusieurs équipes ou sites au cours d'un même sprint.
Efficacité du nettoyage : suivez dans le temps le nombre de liens révoqués et les délais de remédiation.

Recette de requêtes pour démarrer rapidement

Si vous êtes prêt à construire votre propre pipeline de collecte, utilisez ce flux à copier-coller pour vous lancer :

Récupérez les informations de base des utilisateurs et leurs appartenances : /users/{upn}?$select=id,displayName et /users/{id}/memberOf?$select=id,displayName.
Pour chaque groupe Microsoft 365, énumérez les éléments du lecteur : /groups/{groupId}/drive/root/children?$select=id,name,webUrl,lastModifiedDateTime&$top=200, en veillant à suivre @odata.nextLink.
Pour chaque élément, récupérez les autorisations : /drives/{driveId}/items/{itemId}/permissions?$select=id,roles,grantedToV2,link, en filtrant sur les étendues anonymes ou organisationnelles.
Exportez les lignes vers votre magasin de données désigné, en capturant l'heure du locataire, les identifiants de site, les identifiants de lecteur, les identifiants d'élément, les URL web, les propriétaires, les étendues et les détails d'expiration.
Visualisez vos données normalisées dans Power BI pour les tableaux de bord destinés à la direction et aux opérations.

Transformer cela en tableau de bord vivant

Un audit exécuté une seule fois n'est qu'un instantané ; un audit exécuté en continu devient un véritable programme de sécurité. Pour transformer les appels Graph bruts en tableau de bord dynamique, alimentez vos données dans Power Dataflows afin d'obtenir des tables normalisées pour Users, Groups, Sites, Drives, Items, Permissions et Messages. Modélisez vos données selon un schéma en étoile dont Items constitue le centre, avec des relations claires vers Users et Groups.

Configurez des actualisations incrémentielles basées sur les champs lastModifiedDateTime, et exécutez des mises à jour intrajournalières pour les sites à haut risque. Enfin, mettez en place des alertes automatisées qui se déclenchent dès qu'un nouveau lien externe apparaît sur un contenu portant une étiquette de confidentialité, ou lorsque des pics de propagation via les groupes laissent présager une extension non autorisée des autorisations.

Plan de déploiement sur 30 jours

Rome ne s'est pas faite en un jour, et un cadre d'audit d'entreprise exige une mise en place méthodique. Suivez ce plan de déploiement sur 30 jours pour garantir une mise en œuvre sans accroc :

Semaine 1 : configurez l'inscription d'application dans Azure, attribuez des autorisations Graph API au strict minimum nécessaire, puis établissez vos premières requêtes de référence en utilisant les paramètres $select et $filter.

Semaine 2 : développez vos scripts de pagination, normalisez les identifiants en UPN et noms d'appareils cohérents, et réalisez votre première exportation de données de bout en bout réussie.

Semaine 3 : construisez votre modèle de données Power BI et configurez des indicateurs clés de performance tels que l'exposition externe, le risque de propagation et les délais entre exposition et révocation.

Semaine 4 : automatisez les actualisations des données, mettez en place des alertes d'anomalies et documentez les procédures opérationnelles standard à l'intention de votre équipe d'investigation en sécurité.

Public concerné

Ce cadre est conçu spécifiquement pour les administrateurs M365 et les responsables SecOps qui soupçonnent que leurs tableaux de bord au vert masquent des zones grises, pour les équipes de conformité qui ont besoin d'une visibilité de bout en bout sur les partages sans multiplier les outils tiers, ainsi que pour les responsables de la collaboration chargés de maintenir des pratiques de partage externe sûres.

Conseils de terrain

Lorsque vous déployez ces scripts en conditions réelles, gardez ces conseils rapides à l'esprit : commencez toujours vos investigations soit par l'utilisateur, soit par le fichier, puis pivotez dans les deux directions pour éliminer les angles morts. Traitez tout événement d'ajout à un groupe comme un changement à haut risque et examinez les accès en aval dans les 24 heures. Tenez à jour une liste évolutive de termes sensibles à rechercher dans les noms de fichiers et les messages Teams. Enfin, consignez soigneusement le nombre de pages et le volume de résultats : le silence d'un script est souvent le signe d'une tâche défaillante plutôt que d'un locataire propre.

Conclusion

Maîtriser la pagination, respecter les limites de débit et éviter le biais de la première page sont des compétences essentielles pour quiconque est chargé de sécuriser un locataire Microsoft 365 de grande envergure. En dépassant les consoles d'administration de base et en exploitant toute la puissance programmatique de l'API Microsoft Graph, vous pouvez transformer des risques de partage invisibles en indicateurs de sécurité clairs et mesurables.

Pour des analyses approfondies, des exemples de code et des cas pratiques Graph, n'hésitez pas à écouter notre discussion complète dans le podcast. Consultez l'épisode associé et retrouvez tous les détails sur Map Microsoft 365 Users, Groups, Files, and Shares with Graph. Restez en sécurité, continuez à automatiser, et rendez-vous dans le prochain épisode !