Comment voir quelles applications ont accès à votre Microsoft 365

Vous pouvez voir toutes les applications ayant accès à votre tenant Microsoft 365 depuis le centre d'administration Microsoft Entra, sous Identity → Applications → Enterprise applications → All applications. En sélectionnant une application et en ouvrant son onglet Permissions, vous voyez exactement quelles données Microsoft Graph elle peut atteindre, réparties entre les permissions approuvées par les administrateurs de votre organisation et celles que des utilisateurs individuels ont approuvées pour eux-mêmes.

Ce guide couvre ce chemin en détail, la distinction entre consentement admin et consentement utilisateur qui prête souvent à confusion, ainsi que ce qu'une revue application par application ne peut pas révéler.

Où trouver la liste des applications ayant accès dans Entra ?

1. Connectez-vous à entra.microsoft.com avec un compte disposant au minimum du rôle Cloud Application Administrator ou Application Administrator.
2. Accédez à Identity → Applications → Enterprise applications → All applications.
3. Sélectionnez l'application à examiner, puis ouvrez Permissions.

Cette liste recense toutes les applications ajoutées à votre tenant, que ce soit par consentement utilisateur ou par consentement admin — y compris les assistants IA, les bots de réunion et les extensions de productivité qui se connectent via la plateforme d'identité de Microsoft, aux côtés des applications métier internes. La liste couvre aussi bien les applications Microsoft de première partie que les enregistrements tiers ; il vaut donc la peine de regarder au-delà des noms familiers pour voir ce qui a discrètement accumulé des permissions au fil du temps.

Quelle est la différence entre consentement admin et consentement utilisateur ?

L'onglet Permissions se divise en deux catégories :

• Consentement admin (admin consent) — permissions accordées pour l'ensemble de l'organisation par un administrateur. Elles s'appliquent à tous les utilisateurs couverts par cette autorisation, pas seulement à la personne qui a cliqué.
• Consentement utilisateur (user consent) — permissions qu'un individu a approuvées pour lui-même, une personne à la fois, sans intervention d'un administrateur (lorsque les paramètres de consentement de votre tenant le permettent).

En sélectionnant n'importe quelle permission listée, un volet Permission Details s'ouvre et décrit précisément ce qu'elle autorise.

Comment révoquer l'accès d'une application ?

Pour une autorisation de consentement admin : ouvrez la permission dans la liste, sélectionnez le contrôle … à côté, puis choisissez Revoke permission — cela fonctionne directement dans le portail.

Pour une autorisation de consentement utilisateur, le portail ne propose aucun bouton de révocation. Pour la retirer, il faut passer par un appel à l'API Microsoft Graph (DELETE /oAuth2PermissionGrants/{id} pour les permissions déléguées, ou l'appel équivalent appRoleAssignments pour les permissions d'application) ou par la cmdlet PowerShell correspondante, exécutée par une personne disposant du rôle Cloud Application Administrator. Révoquer une autorisation n'empêche pas non plus le même utilisateur de redonner son consentement la prochaine fois que l'application le demandera : pour bloquer cela, il faut modifier séparément la politique de consentement du tenant, sous Enterprise apps → Consent and permissions → User consent settings.

Que se passe-t-il quand un utilisateur se heurte à une permission qu'il ne peut pas accorder lui-même ?

Si un tenant restreint le consentement utilisateur, une personne qui tente de se connecter à une application demandant une permission au-delà de cette limite se heurte à un blocage plutôt qu'à une autorisation. Un Global Administrator peut activer le workflow de consentement admin (admin consent workflow) sous Enterprise apps → Consent and permissions → Admin consent settings, ce qui permet à cette personne d'envoyer une demande à la place : elle est transmise par e-mail aux utilisateurs, groupes ou rôles désignés comme relecteurs, qui peuvent l'approuver, la bloquer ou la refuser depuis leur onglet My Pending. Seul un Global Administrator peut approuver une demande portant sur des permissions d'application Microsoft Graph — être désigné comme relecteur ne confère pas ce privilège à lui seul. Chaque demande expire également après un nombre de jours configurable, de sorte qu'une demande non traitée ne reste pas ouverte indéfiniment.

Que faire si mon organisation s'étend sur plusieurs tenants Microsoft 365 ou sur un annuaire partenaire ?

Une revue menée dans un seul tenant ne montre que ce tenant. Si votre organisation opère sur plusieurs annuaires Microsoft 365 — une société mère et une filiale acquise, par exemple, ou l'annuaire propre d'un partenaire — chacun d'eux nécessite le même parcours, effectué séparément, en se connectant avec le rôle approprié dans chacun. Un outil conçu pour un tenant unique cesse de fonctionner dès qu'un second annuaire entre en jeu ; tout outil censé couvrir plusieurs tenants doit donc pouvoir obtenir un consentement depuis l'annuaire propre de n'importe quelle organisation, et non uniquement celui pour lequel il a été configuré à l'origine.

Que ne révèle pas une revue application par application, et comment 8200.dev y répond-il ?

Parcourir les Enterprise applications une par une vous indique ce que chaque application est *autorisée* à atteindre. Cela ne classe pas les applications selon le risque réel qu'elles représentent, ne signale pas quelles autorisations sont devenues obsolètes, et ne reste pas figé pendant que vous avancez dans la liste — un nouveau consentement peut survenir pendant que vous examinez encore le précédent. Le connecteur Microsoft 365 de 8200.dev lit les Sites, Files, Directory, Application registrations, Users, les politiques de sécurité du tenant, les rapports d'inscription MFA, les journaux d'audit, les attributions de rôles et les autorisations de permissions déléguées — le tout via des scopes Graph en lecture seule — et transforme ces données en un inventaire unique, évalué en continu selon le risque, plutôt qu'une liste que l'on rouvre manuellement. Ce même accès en lecture seule effectue aussi un audit de configuration à l'échelle du tenant en parallèle de l'inventaire des applications : l'état des politiques Security Defaults et Conditional Access, la politique de consentement des applications, et les paramètres de collaboration externe, de sorte qu'une application trop permissive et un assouplissement de la politique du tenant qui l'a laissée entrer apparaissent ensemble, au lieu de figurer dans deux revues distinctes sans lien. Il se connecte de la même manière à l'annuaire professionnel ou scolaire Microsoft propre à n'importe quelle organisation, si bien qu'un groupe s'étendant sur plusieurs tenants n'a pas besoin d'une configuration distincte pour chacun. Tous les scopes utilisés ici sont en lecture seule : rien ne modifie une permission ou une politique, sauf si l'organisation choisit séparément d'automatiser une action spécifique.

Consultez la liste complète des connecteurs pour voir comment cela s'articule avec Google Workspace, Slack et GitHub.