Si tu débutes en administration Microsoft 365 ou Azure, tu as sûrement déjà vécu ce moment de confusion : tu cherches à donner un accès à quelqu’un, et tu tombes sur trois systèmes de rôles différents qui se ressemblent sans être pareils. RBAC Azure, rôles Entra ID, rôles Microsoft 365.
Même les administrateurs avec de l’expérience mélangent parfois les trois.
Ce n’est pas une question de vocabulaire. Ce sont trois systèmes de permissions distincts, qui répondent à trois questions différentes. Une fois que tu as compris ça, tout le reste devient logique.
🎓 Formation recommandée
Certification Microsoft Azure AZ-900
Le cours parfait pour débuter sur Azure et préparer ta certification AZ-900. Idéal si tu démarres dans le cloud Microsoft.
Voir le cours AZ-900 sur Udemy →Lien affilié · Prix souvent à 10-15$ lors des promos Udemy
Le problème de fond : trois systèmes, une seule confusion
La confusion vient du fait que les trois systèmes utilisent le même mot, « rôle », pour des choses qui n’ont pas le même périmètre. Voici la question que chaque système répond :
- RBAC Azure répond à : qui peut faire quoi sur mes ressources cloud (machines virtuelles, comptes de stockage, réseaux) ?
- Rôles Entra ID répondent à : qui peut administrer les identités du tenant (utilisateurs, groupes, appareils, politiques de sécurité) ?
- Rôles Microsoft 365 répondent à : qui peut administrer les applications M365 (Exchange, SharePoint, Teams, conformité) ?
Trois questions, trois systèmes, trois portées d’action. Regardons chacun en détail.
1. Azure RBAC (Role-Based Access Control)
Le RBAC Azure gère l’accès aux ressources Azure elles-mêmes. C’est le système que tu utilises quand tu veux qu’une personne puisse démarrer une machine virtuelle, mais pas la supprimer, ou qu’un développeur puisse lire un compte de stockage sans pouvoir le modifier.
Les trois rôles RBAC de base à connaître
| Rôle | Ce qu’il permet |
|---|---|
| Lecteur | Voir les ressources, aucune modification possible |
| Contributeur | Créer, modifier et supprimer des ressources, mais pas gérer les accès des autres |
| Propriétaire | Accès complet, incluant la capacité d’attribuer des rôles à d’autres personnes |
La portée hiérarchique du RBAC
Ce qui rend le RBAC puissant, c’est qu’il s’applique à quatre niveaux hiérarchiques, du plus large au plus précis :
- Groupe de gestion (regroupe plusieurs abonnements)
- Abonnement (ton contrat Azure)
- Groupe de ressources (un dossier logique de ressources liées)
- Ressource individuelle (une VM précise, un compte de stockage précis)
Un rôle attribué à un niveau élevé se propage automatiquement vers le bas. Si tu donnes le rôle Contributeur sur un groupe de ressources, la personne a ce rôle sur toutes les ressources contenues dans ce groupe.
C’est le principe d’héritage, à garder en tête quand tu modélises tes accès : plus tu attribues haut dans la hiérarchie, plus l’impact est large.
À retenir pour le SC-300 et en pratique
Le RBAC Azure ne donne aucun accès à Entra ID ou à Microsoft 365. Un Propriétaire RBAC sur un abonnement Azure ne peut pas créer un utilisateur dans Entra ID s’il n’a pas aussi un rôle Entra ID.
C’est l’erreur de débutant la plus fréquente : penser qu’un rôle RBAC élevé donne automatiquement des droits d’administration sur les identités. Ce n’est pas le cas, et c’est volontaire : ça permet de séparer la gestion de l’infrastructure cloud de la gestion des identités.
2. Les rôles Entra ID (anciennement Azure AD)
Les rôles Entra ID gèrent l’administration des identités et des objets liés au tenant : utilisateurs, groupes, appareils, applications enregistrées, politiques de sécurité comme l’accès conditionnel.
Les rôles les plus courants
| Rôle | Ce qu’il permet |
|---|---|
| Administrateur général (Global Administrator) | Accès complet à Entra ID et à tous les services M365 liés. Le rôle le plus puissant, à attribuer avec parcimonie |
| Administrateur des utilisateurs | Créer, modifier, supprimer des comptes utilisateurs, réinitialiser des mots de passe |
| Administrateur des groupes | Gérer les groupes et leur appartenance |
| Lecteur de sécurité | Lecture seule sur les configurations de sécurité, sans capacité de modification |
| Administrateur d’accès conditionnel | Créer et gérer les politiques d’accès conditionnel |
Pourquoi ce système existe séparément du RBAC Azure
Entra ID est le service d’identité qui sert de fondation à tout l’écosystème Microsoft, pas seulement Azure.
Un tenant Entra ID peut exister sans aucun abonnement Azure actif. C’est pour ça que ses rôles forment un système séparé : ils gèrent l’identité elle-même, indépendamment de ce que cette identité va ensuite utiliser comme service (Azure, M365, ou une application tierce intégrée).
Le piège classique
Un Administrateur des utilisateurs peut créer des comptes et réinitialiser des mots de passe, mais ça ne lui donne aucun droit sur les boîtes courriel Exchange ou les sites SharePoint de ces utilisateurs.
La gestion de l’identité et la gestion des applications sont deux couches séparées, ce qui nous mène au troisième système.
3. Les rôles Microsoft 365
Les rôles M365 gèrent l’administration des applications et services de la suite : Exchange Online, SharePoint, Teams, conformité, sécurité des données.
Les rôles les plus courants
| Rôle | Ce qu’il permet |
|---|---|
| Administrateur Exchange | Gérer les boîtes courriel, les règles de flux de messagerie, les politiques anti-spam |
| Administrateur Teams | Gérer les politiques Teams, les équipes, les paramètres d’appels |
| Administrateur SharePoint | Gérer les sites, les collections de sites, les permissions de partage |
| Administrateur de conformité | Gérer les politiques de rétention, la prévention de perte de données (DLP) |
Le lien avec Entra ID
Voici la nuance importante : techniquement, ces rôles M365 sont gérés depuis le centre d’administration Entra ID, parce que Microsoft a unifié l’attribution des rôles dans une interface commune.
Mais leur portée d’action reste limitée aux applications M365. Un Administrateur Exchange ne peut pas créer un utilisateur ou modifier une politique d’accès conditionnel, même s’il configure ses rôles depuis le même portail qu’un Administrateur des utilisateurs.
C’est cette unification d’interface qui crée la confusion chez les débutants. Le portail est commun, mais le périmètre de chaque rôle reste cloisonné.
Le tableau de synthèse
| Système | Répond à quelle question | S’applique à | Exemple de rôle |
|---|---|---|---|
| RBAC Azure | Qui gère les ressources cloud ? | VMs, stockage, réseaux, groupes de ressources | Contributeur, Propriétaire |
| Rôles Entra ID | Qui gère les identités et le tenant ? | Utilisateurs, groupes, appareils, sécurité du tenant | Administrateur des utilisateurs, Administrateur général |
| Rôles Microsoft 365 | Qui gère les applications M365 ? | Exchange, SharePoint, Teams, conformité | Administrateur Exchange, Administrateur Teams |
Le principe qui doit guider toutes tes attributions : le moindre privilège
Peu importe le système, la règle reste la même : donne uniquement les droits nécessaires pour accomplir la tâche, jamais plus. Un besoin ponctuel de réinitialiser des mots de passe ne justifie pas un Administrateur général. Un besoin de gérer les boîtes courriel ne justifie pas un accès Exchange combiné à un accès SharePoint si la tâche ne le demande pas.
Ce principe devient encore plus important quand tu modélises des rôles à grande échelle, comme dans un contexte de gouvernance des identités en entreprise : plus la granularité de tes rôles est fine, plus tu réduis la surface de risque en cas de compromission d’un compte.
Aller plus loin : Privileged Identity Management (PIM)
Une fois que tu as compris les trois systèmes de rôles, l’étape suivante logique est PIM, qui s’applique aux trois. PIM permet d’attribuer un rôle de façon temporaire et activable, plutôt que permanente.
Concrètement, au lieu de donner le rôle Administrateur général à quelqu’un de façon permanente, tu le rends « éligible » à ce rôle. La personne doit ensuite activer ce rôle quand elle en a réellement besoin, pour une durée limitée, parfois avec une justification ou une approbation requise. C’est ce qu’on appelle l’accès Just-in-Time (JIT).
Ça s’applique aussi bien aux rôles RBAC Azure, qu’aux rôles Entra ID, qu’aux rôles M365. PIM est disponible avec une licence Entra ID P2, et c’est un sujet central pour qui prépare le SC-300 ou qui travaille sérieusement en gouvernance des accès.
Si tu ne retiens qu’une chose de cet article : ne te demande jamais « quel rôle donner », mais d’abord « sur quel système la personne doit agir ». Si c’est une ressource Azure, c’est RBAC. Si c’est une identité ou une politique de sécurité du tenant, c’est Entra ID. Si c’est une application M365 comme Exchange ou Teams, c’est un rôle M365.
Une fois cette distinction ancrée, le reste de l’administration des accès devient beaucoup plus clair, et tu évites l’erreur classique de sur-attribuer des droits par simplicité plutôt que par nécessité réelle.
