Consentement administrateur : ce que l’IT approuve réellement

Accueil › Blog › Consentement administrateur : ce que l’IT approuve réellement

Par Nicolas Saliba · Publié en octobre 2026 · 13 min de lecture

En bref

Dans Microsoft Entra ID, le consentement administrateur accorde un accès aux données à l’échelle de tout le tenant : ce n’est pas une simple formalité. Nous détaillons les données réellement exposées par les autorisations demandées, le rôle Entra habilité à les approuver, ainsi que la manière de documenter et de tester la procédure de révocation avant de cliquer sur « Accorder ».

À retenir

• Les autorisations d’application permettent à une application d’appeler Microsoft Graph avec sa propre identité, sans utilisateur connecté, et d’accéder à toutes les données couvertes par l’autorisation, par exemple à l’ensemble des fichiers de l’organisation.
• Seuls les rôles Administrateur de rôles privilégiés et Administrateur général peuvent accorder le consentement aux autorisations d’application Microsoft Graph ; l’Administrateur d’applications cloud couvre les autres cas.
• Exiger l’affectation des utilisateurs empêche les utilisateurs non affectés de se connecter, mais ne limite pas les données qu’une identité d’application seule peut lire.
• Les autorisations accordées à l’échelle du tenant peuvent être examinées dans l’onglet de consentement administrateur des applications d’entreprise et révoquées individuellement. Toutefois, leur révocation n’empêche pas les utilisateurs d’accorder à nouveau leur consentement.
• Exigez du fournisseur une matrice reliant chaque point de terminaison à son objectif : chaque autorisation doit correspondre à une fonctionnalité, et les conséquences d’un refus doivent être précisées.

À quoi l’administrateur donne-t-il réellement accès ?

Lorsque la fenêtre de consentement s’affiche, vous n’autorisez pas une simple connexion. Vous accordez à une application un ensemble d’autorisations d’API sur votre tenant Microsoft 365, au nom de toute l’organisation. Microsoft souligne clairement les enjeux : accorder le consentement administrateur au nom d’une organisation est une opération sensible qui peut donner à l’éditeur de l’application accès à une part importante des données de l’organisation, ou la capacité d’effectuer des opérations hautement privilégiées, comme la gestion des rôles, l’accès complet à toutes les boîtes aux lettres ou à tous les sites, et l’usurpation complète de l’identité d’un utilisateur.[1] Considérez cette fenêtre comme un contrat d’accès aux données et lisez-la ligne par ligne avant de cliquer sur « Accorder ».

Une application demande les autorisations d’API dont elle a besoin. Selon les autorisations sollicitées, la demande peut être adressée à un administrateur plutôt qu’à un utilisateur final.[2] Avant même d’examiner chaque autorisation, l’écran de consentement vous indique trois éléments à vérifier : l’identité de l’application, son éditeur et la liste exacte des autorisations demandées.

• L’identité de l’application : son nom d’affichage et son ID client, également appelé ID d’application, qui vous permet de retrouver cette même application dans votre propre centre d’administration Microsoft Entra.
• L’éditeur : l’organisation responsable de l’application et la confirmation éventuelle par Microsoft de l’authenticité de cette organisation.
• Les autorisations demandées : chaque portée, désignée selon le modèle {ressource}.{opération}.{contrainte} utilisé par Microsoft Graph.

Cette convention de nommage vous aide à interpréter les autorisations. La ressource indique quelles données Graph sont concernées, l’opération précise si l’application peut uniquement lire les données ou également les modifier, et la contrainte indique l’étendue de l’accès.[3]

Interprétez chaque autorisation avant de l’approuver et évaluez une demande d’analyse de la communication en fonction des données exposées par chaque autorisation, et non des assurances du fournisseur. Une autorisation en lecture seule n’est pas nécessairement limitée : une application disposant de l’autorisation d’application Files.Read.All peut lire n’importe quel fichier de l’organisation.[3] Le mot « Read » dans le nom ne réduit pas la portée indiquée par « All ».

Quelle est la différence entre les autorisations déléguées et les autorisations d’application ?

Microsoft Graph prend en charge deux modes d’accès : l’accès délégué, dans lequel l’application appelle Graph au nom d’un utilisateur connecté, et l’accès exclusivement applicatif, dans lequel l’application appelle Graph avec sa propre identité, sans utilisateur connecté.[3] Cette différence détermine l’ampleur des conséquences potentielles de votre approbation. Commencez donc par identifier le type d’accès demandé.

Dans un scénario délégué, les privilèges de l’application dépendent à la fois des autorisations accordées et des propres autorisations de l’utilisateur : lorsqu’elle agit au nom de Tom, une application disposant de Files.Read.All ne peut lire que les fichiers auxquels Tom a déjà accès.[3] Dans un scénario exclusivement applicatif, aucun plafond lié aux droits d’un utilisateur ne s’applique. C’est pourquoi Microsoft recommande le modèle d’autorisations déléguées dans une logique de moindre privilège, dès lors qu’il répond aux besoins de l’application. Une demande d’accès exclusivement applicatif doit donc faire l’objet d’un examen particulièrement rigoureux.

Il est logique qu’un outil d’analyse exécuté en arrière-plan demande un accès exclusivement applicatif : il doit lire périodiquement les données d’activité SharePoint et Viva Engage dans l’ensemble du tenant, qu’un utilisateur soit connecté ou non. Les limites des rapports natifs qui conduisent votre équipe de communication à demander une couche analytique sont bien réelles : tableaux de bord fragmentés selon les outils, ou encore période de reporting de 30 jours sans licences Premium, comme expliqué dans Viva Connections analytics. La question n’est donc pas de savoir si la demande inclut des autorisations d’application, mais si chacune correspond à la portée la plus restreinte permettant de fournir une fonctionnalité que vous avez réellement commandée.

Quelle identité est autorisée à approuver la demande ?

Le droit d’accorder le consentement dépend des autorisations demandées et du rôle d’administrateur, et non de l’intitulé du poste ou de l’ancienneté.[2] Le modèle de rôles de Microsoft répartit les droits d’approbation en plusieurs niveaux. Les connaître permet d’orienter la demande vers la bonne personne, plutôt que de l’escalader systématiquement vers le détenteur du rôle le plus puissant.

• Administrateur de rôles privilégiés : peut accorder le consentement aux applications demandant n’importe quelle autorisation pour n’importe quelle API.
• Administrateur d’applications cloud, Administrateur IA ou Administrateur d’applications : peut accorder le consentement aux applications demandant des autorisations pour n’importe quelle API, à l’exception des rôles d’application Microsoft Graph, c’est-à-dire des autorisations d’application.
• Rôle d’annuaire personnalisé : un rôle incluant l’autorisation d’accorder des autorisations aux applications peut être limité précisément aux permissions nécessaires à ce type d’approbation.

Les autorisations d’application constituent ici l’exception importante : seuls les rôles Administrateur de rôles privilégiés et Administrateur général peuvent les approuver.[3] Comme le déploiement d’un outil d’analyse en arrière-plan inclura des rôles d’application, la décision finale reviendra à l’une de ces deux identités. Entre les deux, le rôle Administrateur de rôles privilégiés est le choix le plus limité. L’Administrateur général ne devrait pas être l’approbateur par défaut de toutes les demandes de consentement.

Le rôle personnalisé constitue une bonne base pour mettre en place une gouvernance reproductible. Limitez un rôle d’annuaire à l’octroi des autorisations pour cette catégorie de demandes, attribuez-le à l’identité responsable des approbations des fournisseurs et évitez de confier les décisions de consentement à l’échelle du tenant à vos comptes les plus privilégiés. En définissant délibérément le circuit d’approbation, vous faites de l’attribution du rôle elle-même un élément de la piste d’audit.

Quels éléments le fournisseur doit-il fournir en amont ?

Fixez les exigences documentaires avant la première démonstration, et non après la signature du contrat. Exigez une matrice reliant chaque point de terminaison à son objectif : chaque autorisation Graph demandée doit être associée à la fonctionnalité qu’elle active et aux données qu’elle lit. La documentation doit être compréhensible à la fois par l’équipe IT et par les parties prenantes de la communication. Un fournisseur incapable d’expliquer pourquoi une autorisation est nécessaire vous demande d’accepter un risque qu’il n’a lui-même pas analysé.

Les recommandations de Microsoft aux développeurs précisent ce qu’est une demande bien préparée : les autorisations doivent être définies statiquement dans l’inscription de l’application et couvrir l’ensemble des autorisations qu’elle pourrait demander dynamiquement. L’administrateur du tenant peut ainsi examiner la liste complète et donner son consentement une seule fois dans le portail, plutôt que de découvrir de nouvelles autorisations après le déploiement.[4] Demandez au fournisseur de confirmer que sa liste d’autorisations est statique et exhaustive, et qu’elle est versionnée. Toute mise à jour ajoutant des autorisations devra ainsi déclencher un nouvel examen plutôt que créer une surprise.

Demandez ensuite l’ID client de l’application et vérifiez le statut de validation de l’éditeur. Lorsqu’un éditeur est vérifié, Microsoft a confirmé l’authenticité de l’organisation éditrice par l’intermédiaire d’un compte partenaire vérifié. Un badge bleu de vérification apparaît alors dans la fenêtre de consentement.[5] Il faut toutefois connaître les limites de ce badge : Microsoft précise qu’il ne garantit ni la qualité du produit, ni des certifications, ni le respect des bonnes pratiques de sécurité. Complétez cette vérification par des éléments portant réellement sur le traitement des données des collaborateurs : statut SOC 2 Type 2, conformité au RGPD et localisation des données, comme l’explique le guide security and compliance guidance for IC analytics tells you to gate a vendor on.

Enfin, vérifiez les informations directement dans votre tenant au lieu de vous fier à une présentation commerciale : ouvrez Applications d’entreprise, sélectionnez l’application et consultez la liste des autorisations dans la section « Autorisations ». La description fournie par un fournisseur sur what its analytics layer reads les données que sa couche analytique lit dans un tenant Microsoft 365 — et celles auxquelles elle n’accède volontairement pas — représente le niveau de précision que vous devriez exiger de tout fournisseur demandant un consentement à l’échelle du tenant.

Quel est l’effet des restrictions d’affectation sur l’accès des utilisateurs ?

Deux contrôles sont souvent confondus lors des réunions d’approbation : qui peut se connecter à l’application et quelles données une identité exclusivement applicative peut lire. Il s’agit de deux mécanismes distincts. Par défaut, le consentement administrateur accordé à l’échelle du tenant permet à tous les utilisateurs d’accéder à l’application, sauf si vous imposez des restrictions. Pour limiter les connexions, configurez l’application afin qu’elle exige une affectation, puis attribuez-la aux utilisateurs ou aux groupes concernés.[1]

Cette distinction est particulièrement importante pour le déploiement d’un outil d’analyse : l’obligation d’affectation empêche les utilisateurs non affectés de se connecter, mais l’identité de service de l’application continue de lire toutes les données couvertes par ses rôles d’application, quelle que soit la liste des utilisateurs affectés. L’affectation des utilisateurs ne limite pas la portée des autorisations exclusivement applicatives. L’affectation détermine qui peut consulter le tableau de bord ; seul l’examen des autorisations décrit plus haut détermine quelles données le service peut lire.

Configurez l’application en conséquence. Affectez l’application à l’équipe de communication et aux dirigeants qui doivent consulter les rapports, afin de maîtriser l’audience du tableau de bord. Considérez la liste des autorisations approuvées comme le levier déterminant l’exposition des données. Si les vues segmentées soulèvent des questions sur les personnes autorisées à consulter les données d’engagement par groupe, il s’agit d’une décision relative aux droits d’accès au tableau de bord. Les compromis entre données anonymisées et données identifiables méritent d’être étudiés avant la mise en production, et non après la première question du comité social et économique.

Comment examiner ou révoquer les autorisations ultérieurement ?

Gérez l’autorisation tout au long de son cycle de vie, avec un responsable, un déclencheur de révision et une procédure de retrait testée, plutôt que comme une simple case à cocher au déploiement. Les outils d’audit sont déjà disponibles dans votre centre d’administration : vous devez savoir où les trouver avant d’en avoir besoin.

• Applications d’entreprise, puis Autorisations, puis onglet Consentement administrateur : affiche les autorisations accordées à l’application à l’échelle du tenant.
• Onglet Consentement utilisateur : affiche les autorisations accordées par un utilisateur ou un groupe spécifique.
• Révocation : un Administrateur d’applications cloud peut révoquer une autorisation accordée à l’échelle du tenant depuis le même panneau, à l’aide de la commande de révocation.

Deux points sont à connaître avant d’utiliser cette commande. Premièrement, les autorisations de l’onglet Consentement utilisateur ne peuvent pas être révoquées depuis le portail. Leur suppression nécessite des appels à l’API Microsoft Graph ou des commandes PowerShell.[6] Deuxièmement, la révocation d’une autorisation accordée n’empêche pas les utilisateurs de donner à nouveau leur consentement aux autorisations demandées par l’application. Pour éviter cela, vous devez également renforcer les paramètres de consentement des utilisateurs du tenant.[6]

Documentez trois éléments au moment de l’approbation, tant que les détails sont encore clairs. Identifiez le responsable de l’autorisation : qui a approuvé quelle liste d’autorisations, pour quel ID client et à quelle date. Définissez les déclencheurs de révision : modification des autorisations de l’application, incident de sécurité chez le fournisseur ou fin du contrat. Enfin, répétez une fois la procédure de retrait dans un tenant de test : révoquez les rôles d’application, vérifiez que le service perd son accès et notez les étapes nécessaires pour le réactiver en cas de nouvel octroi. Une procédure de sortie que vous avez réellement exécutée constitue un contrôle ; une procédure que vous supposez fonctionner n’est qu’un espoir.

Quels éléments doivent accompagner l’approbation de Communication Insights ?

Appliquez la même liste de contrôle à la demande que vous êtes le plus susceptible de recevoir : celle de votre équipe de communication souhaitant analyser plusieurs canaux. Demandez à Tryane la liste actuelle des autorisations requises par Communication Insights, la plateforme d’analyse multicanale qui rassemble les newsletters par e-mail, l’intranet SharePoint, Viva Connections et Viva Engage dans un tableau de bord centralisé. Examinez-la à l’aide de la même matrice reliant les points de terminaison à leurs objectifs que vous exigeriez de tout fournisseur : chaque autorisation doit être associée à la fonctionnalité qu’elle active et aux données qu’elle lit, sans qu’aucune ne soit justifiée par la seule confiance.

• Examen des autorisations : chaque autorisation demandée est justifiée et la liste statique est confirmée comme exhaustive.
• Circuit d’approbation : le consentement est accordé par le rôle disposant des privilèges les plus limités parmi ceux autorisés à approuver les types de permissions demandés.
• Affectation : les utilisateurs du tableau de bord sont affectés délibérément, tandis que l’exposition des données est régie uniquement par les autorisations approuvées.
• Révocation : un responsable identifié, un déclencheur de révision défini et une procédure de retrait testée dans un tenant de test.

N’approuvez la demande qu’une fois l’examen des autorisations terminé, confiez le consentement au rôle le moins privilégié habilité à l’accorder et archivez la procédure de révocation avec le dossier d’approbation. Une fois le consentement accordé, le déploiement peut commencer : connexion de chaque canal, structuration du modèle d’audience et consultation des KPI multicanaux au même endroit, plutôt que dans quatre consoles distinctes. C’est précisément l’objectif de Communication Insights , qui s’appuie sur la liste d’autorisations que vous venez d’examiner.

Si vous souhaitez examiner la demande de consentement avec l’équipe qui l’a conçue, passez en revue les autorisations requises par Communication Insights avec Tryane : réservez un échange et vérifiez la liste des autorisations au regard de votre propre tenant avant de cliquer sur « Accorder ».

Foire aux questions

À quoi le consentement administrateur donne-t-il réellement accès à une application ?

Il accorde à l’application les autorisations d’API qu’elle a demandées au nom de toute l’organisation. Microsoft décrit cette opération comme sensible, car elle peut donner à l’éditeur de l’application accès à une part importante de vos données ou à des opérations hautement privilégiées, comme l’accès complet à toutes les boîtes aux lettres ou à tous les sites. La liste des autorisations doit donc être examinée avant toute approbation.

Quelle est la différence entre les autorisations déléguées et les autorisations d’application ?

Les autorisations déléguées permettent à l’application d’agir au nom d’un utilisateur connecté, dans les limites des données auxquelles cet utilisateur peut déjà accéder. Les autorisations d’application (rôles d’application) fonctionnent sans utilisateur connecté et permettent à l’application d’accéder à toutes les données couvertes par l’autorisation, par exemple à tous les fichiers de l’organisation. Microsoft recommande le modèle délégué dans une logique de moindre privilège dès lors qu’il répond aux besoins de l’application.

Quel rôle Microsoft Entra peut accorder le consentement administrateur à l’échelle du tenant ?

Cela dépend des autorisations demandées. L’Administrateur de rôles privilégiés peut accorder le consentement aux applications demandant n’importe quelle autorisation pour n’importe quelle API. L’Administrateur d’applications cloud, l’Administrateur IA et l’Administrateur d’applications peuvent approuver toutes les autorisations, à l’exception des autorisations d’application Microsoft Graph, qui ne peuvent être accordées que par l’Administrateur de rôles privilégiés ou l’Administrateur général. Un rôle d’annuaire personnalisé doté de l’autorisation de consentement peut également être limité à cette tâche.

Si je limite l’application aux utilisateurs affectés, est-ce que je réduis son accès aux données ?

Non. Exiger une affectation et attribuer l’application à des utilisateurs ou groupes spécifiques détermine qui peut se connecter et obtenir des jetons. Cela ne limite pas la portée d’une identité exclusivement applicative : une autorisation d’application continue de couvrir les données qu’elle désigne, indépendamment de l’affectation des utilisateurs. Seule la liste des autorisations détermine les données que le service peut lire.

Comment examiner ou révoquer les autorisations après avoir accordé le consentement administrateur ?

Dans le centre d’administration Microsoft Entra, ouvrez Applications d’entreprise, sélectionnez l’application, puis Autorisations et l’onglet Consentement administrateur pour consulter les autorisations accordées à l’échelle du tenant et révoquer des autorisations individuellement. Les autorisations accordées par les utilisateurs doivent être supprimées via Microsoft Graph ou PowerShell. Notez que la révocation d’une autorisation n’empêche pas les utilisateurs de donner à nouveau leur consentement, sauf si vous renforcez également les paramètres de consentement des utilisateurs.

Peut-on approuver automatiquement une autorisation en lecture seule sans risque ?

Non. Une autorisation en lecture seule n’est pas nécessairement limitée : une autorisation d’application telle que Files.Read.All permet à l’application de lire n’importe quel fichier de l’organisation sans utilisateur connecté. Évaluez chaque autorisation en fonction des données qu’elle expose, et non du mot « Read », et exigez du fournisseur qu’il justifie chaque permission par une fonctionnalité concrète.

Quels documents dois-je exiger d’un fournisseur avant d’approuver le consentement ?

Demandez une matrice reliant les points de terminaison à leurs objectifs : chaque autorisation demandée doit être associée à la fonctionnalité qu’elle active, aux données qu’elle lit et aux conséquences d’un éventuel refus. Les recommandations de Microsoft préconisent précisément cette approche, ainsi qu’une liste d’autorisations versionnée et la vérification de l’éditeur, afin que vous puissiez comparer la demande aux informations visibles dans votre propre tenant.

Sources

• learn.microsoft.com

• learn.microsoft.com

• learn.microsoft.com

• docs.azure.cn

• learn.microsoft.com

• learn.microsoft.com

Pour aller plus loin

• Viva Insights vs communication analytics: two different questions

• IC analytics data retention: what to set and why

Pour découvrir à quoi ressemble un reporting multicanal appliqué à vos données réelles, Tryane propose une démonstration guidée de 15 minutes, sans présentation de diapositives. Réservez un créneau avec Jérémy.