RBAC dans Microsoft Teams : les 8 rôles d'administration
Le contrôle d’accès basé sur les rôles (RBAC) dans Microsoft Teams repose sur Microsoft Entra ID, réparti en 8 rôles d’administration spécifiques à Teams plutôt qu’un interrupteur tout ou rien. Bien faire les choses, c’est faire correspondre le travail de chaque administrateur au rôle le plus restreint qui le couvre, plutôt que de basculer par défaut sur Global Administrator.
Réponse rapide : Microsoft Entra ID compte 8 rôles d’administration spécifiques à Teams, du rôle complet Teams Administrator au rôle en lecture seule Teams Reader, en passant par des rôles restreints comme Teams Devices Administrator. Attribuez le rôle le plus restreint qui couvre la tâche, gardez votre nombre de Global Administrator en dessous de cinq, et utilisez Privileged Identity Management (PIM) pour tout ce qui ne nécessite qu’une élévation limitée dans le temps.
Ce que signifie vraiment le RBAC dans Microsoft Teams
Il est utile de distinguer deux choses souvent confondues : les rôles d’administration au niveau du tenant et les rôles de propriétaire/membre au niveau de chaque équipe.
Les 8 rôles présentés ici sont des rôles d’annuaire Microsoft Entra ID. Ils déterminent qui peut administrer le service Teams (stratégies, appareils, téléphonie, paramètres à l’échelle du tenant) depuis le Teams admin center ou PowerShell, sur l’ensemble du tenant.
Les rôles de propriétaire et de membre d’équipe forment une couche différente, plus restreinte : un propriétaire d’équipe peut ajouter ou supprimer des membres, modifier les paramètres d’une équipe ou gérer des canaux au sein de cette seule équipe, sans aucun accès au centre d’administration. Pour déterminer « qui peut faire quoi », vérifiez d’abord dans quelle couche vous vous situez, car les deux ne se recoupent pas.
Les 8 rôles d’administration Microsoft Teams
Selon la documentation de référence des rôles intégrés Microsoft Entra, Entra ID compte 8 rôles spécifiques à Teams : Teams Administrator, Teams Communications Administrator, Teams Communications Support Engineer, Teams Communications Support Specialist, Teams Devices Administrator, Teams External Collaboration Administrator, Teams Reader et Teams Telephony Administrator.
Une bizarrerie de nommage : la référence des rôles Entra appelle le rôle 5 « Teams Devices Administrator » (pluriel), tandis que la documentation des rôles d’administration Teams écrit « Teams Device Administrator » (singulier). Même rôle, documentation incohérente. Cette même page ne documente d’ailleurs que 7 des 8 rôles : elle ne couvre pas encore Teams External Collaboration Administrator, qui ne figure pour l’instant que dans la référence des rôles Entra.
| Rôle | Ce qu’il gère | Où il est géré | Limite notable |
|---|---|---|---|
| Teams Administrator | Ensemble du service Teams : réunions, voix, stratégies de messagerie, paramètres de fédération/à l’échelle de l’organisation, appareils, dépannage, tous les rapports, CQD, publication du catalogue d’applications | Teams admin center + PowerShell | La création de comptes de ressources nécessite également User Administrator |
| Teams Communications Administrator | Fonctionnalités d’appel et de réunion : stratégies, voix, attribution de numéros de téléphone, comptes de ressources, dépannage de la qualité des appels, CQD | Teams admin center + PowerShell | La création de comptes de ressources nécessite également User Administrator |
| Teams Communications Support Engineer | Dépannage avancé de la qualité des appels, CQD jusqu’aux utilisateurs affectés | Call Analytics / CQD | Dépannage uniquement, aucun contrôle de configuration |
| Teams Communications Support Specialist | Dépannage de base des appels dans Call Analytics | Call Analytics | Ne peut consulter que l’utilisateur spécifique recherché |
| Teams Devices Administrator | Configuration des appareils, mises à jour, état de santé, profils, redémarrages | Teams admin center (Devices) | Aucun accès à la qualité des appels ni aux analyses ; nécessite Communications Administrator |
| Teams External Collaboration Administrator | Stratégies de collaboration externe : domaines externes, quels groupes/utilisateurs peuvent interagir avec l’organisation | Entra ID | Nouveau rôle (voir plus bas), pas encore présent sur la page des rôles d’administration Teams |
| Teams Reader | Vue en lecture seule du Teams admin center | Teams admin center | Ne peut pas consulter Teams management, les détails de Meetings & Calls, Notifications & Rules, Frontline deployment, ni le tableau de bord d’insights |
| Teams Telephony Administrator | Voix/téléphonie : stratégies d’appel, numéros de téléphone, applications vocales, comptes de ressources, rapports PSTN, tickets de support | Teams admin center + PowerShell | Certaines tâches vocales exigent que l’administrateur dispose d’une licence Teams |
Quel rôle attribuer, concrètement ?
Partez de la tâche à accomplir, pas de l’ancienneté ou du niveau hiérarchique :
- L’ensemble du service Teams, y compris la fédération et les paramètres à l’échelle de l’organisation → Teams Administrator.
- Uniquement les stratégies d’appel et de réunion, sans appareils ni reporting → Teams Communications Administrator.
- Dépannage approfondi de la qualité des appels pour une équipe support → Teams Communications Support Engineer.
- Support de premier niveau consultant l’historique d’appels d’un utilisateur à la fois → Teams Communications Support Specialist.
- Appareils certifiés Teams et matériel de salle de réunion, rien d’autre → Teams Devices Administrator (aucune visibilité sur la qualité des appels).
- Domaines externes et organisations autorisées à collaborer avec votre tenant → Teams External Collaboration Administrator.
- Auditeurs ou toute personne ayant seulement besoin de visibilité → Teams Reader.
- Numéros de téléphone et reporting PSTN → Teams Telephony Administrator.
Si aucun des 8 rôles ne correspond exactement, ne basculez pas par défaut sur Global Administrator : vérifiez d’abord si un rôle personnalisé limité à une unité d’administration convient mieux.
Le nouveau rôle Teams External Collaboration Administrator
Teams External Collaboration Administrator est le plus récent ajout à cette liste. Microsoft l’a annoncé dans la notification de centre de messages MC1215071 le 8 janvier 2026, avec un déploiement annoncé pour fin janvier 2026, selon l’article de Tony Redmond sur Office365itpros.com. Sa description Entra : il gère « les stratégies et paramètres de collaboration externe pour Teams, y compris la configuration des domaines externes et le contrôle des groupes et utilisateurs pouvant interagir avec l’organisation ».
Redmond doute que la plupart des tenants aient besoin d’un rôle dédié pour cela :
« Le principe, c’est qu’un petit nombre de rôles suffit à cloisonner les tâches d’administration pour de nombreux tenants Microsoft 365. »
Son avis : modifier les paramètres de collaboration externe n’est pas assez contraignant pour justifier un administrateur délégué dédié dans la plupart des organisations. Ce rôle convient davantage aux « très grands tenants d’entreprise disposant d’équipes d’administration importantes et de responsabilités clairement délimitées » qu’aux organisations de taille intermédiaire classiques.
Comment attribuer un rôle d’administration Teams
Chemin de navigation : entra.microsoft.com → Entra ID → Rôles et administrateurs → Tous les rôles, sélectionnez le rôle, ouvrez Attributions, puis Ajouter des attributions. Vous ne savez pas quel rôle choisir ? Le filtre Service de cette liste permet de réduire les plus de 65 rôles intégrés d’Entra à ceux pertinents pour Teams.
Pour une attribution scriptée, la méthode actuellement prise en charge est le SDK Microsoft Graph PowerShell et sa cmdlet New-MgDirectoryRoleMemberByRef :
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
New-MgDirectoryRoleMemberByRef `
-DirectoryRoleId "<role-id>" `
-BodyParameter @{ "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/<user-id>" }Les cmdlets spécifiques à Teams se trouvent dans le module Teams ; exécutez Get-Command -Module MicrosoftTeams pour voir ce qui est disponible pour le travail sur les stratégies en complément de l’attribution de rôles.
Avertissement de migration si vous travaillez à partir d’anciens scripts : les modules PowerShell AzureAD et MSOnline sont retirés, dépréciés depuis le 30 mars 2024 et hors support depuis le 30 mars 2025. Les runbooks appelant Connect-AzureAD ou Get-MsolUser sont désormais des références historiques, pas des commandes à continuer d’exécuter. Migrez cette automatisation vers le SDK Microsoft Graph PowerShell, ou vers le module Microsoft Entra PowerShell.
Attribuer des rôles à des groupes plutôt qu’à des personnes
Vous pouvez attribuer un rôle d’administration Teams à un groupe plutôt que de gérer les attributions une par une, mais le groupe doit être correctement construit dès le départ.
Un groupe pouvant se voir attribuer un rôle requiert Microsoft Entra ID P1, et doit être créé comme un nouveau groupe de sécurité ou Microsoft 365 avec le paramètre « Les rôles Microsoft Entra peuvent être attribués au groupe » défini sur Oui dès la création. Ce paramètre, isAssignableToRole, est immuable : vous ne pouvez pas convertir un groupe existant après coup.
Le point le plus important : le type d’appartenance doit être Assigned ; les groupes à appartenance dynamique ne sont pas pris en charge pour l’attribution de rôles. La raison invoquée par Microsoft : un peuplement automatisé pourrait ajouter un compte non souhaité, qui hériterait alors automatiquement du rôle. Si un ancien processus distribue des rôles d’administration par intitulé de poste via des règles dynamiques, il s’agit d’une faille de sécurité à corriger.
Risque d’escalade associé : toute personne pouvant gérer par ailleurs l’appartenance dynamique d’un groupe pourrait s’ajouter indirectement à un rôle attribué à ce groupe. L’exemple donné par Microsoft : un groupe auquel le rôle User Administrator est attribué, où un administrateur Exchange capable de modifier des groupes à appartenance dynamique pourrait s’y ajouter et devenir User Administrator sans jamais s’être vu attribuer ce rôle directement.
Autres contraintes : 500 groupes pouvant se voir attribuer un rôle au maximum par tenant, la création d’un tel groupe nécessite Privileged Role Administrator, la gestion de l’appartenance via Graph nécessite RoleManagement.ReadWrite.Directory (Group.ReadWrite.All ne fonctionne pas), et l’imbrication n’est pas prise en charge. Le détail complet figure dans la documentation Microsoft sur les groupes pouvant se voir attribuer un rôle.
Accès juste-à-temps avec PIM
Un accès privilégié permanent constitue une surface d’attaque plus large que nécessaire pour des rôles utilisés seulement occasionnellement. PIM permet de rendre une attribution de rôle éligible plutôt que permanente : la personne l’active, pour une durée définie, lorsqu’elle en a besoin. Cela nécessite Entra ID P2 ou Microsoft Entra ID Governance.
Chemin de configuration : Entra admin center → Identity Governance → Privileged Identity Management → Microsoft Entra roles → Roles, sélectionnez le rôle, Add assignments, définissez-le comme Eligible ou Active, avec des dates de début et de fin.
Si un administrateur a besoin de plusieurs rôles éligibles, les activer un par un devient fastidieux. PIM for Groups résout ce problème : créez un groupe, accordez-lui un accès permanent aux rôles nécessaires, puis faites de l’administrateur un membre éligible. Une seule activation couvre tout ce à quoi le groupe est lié.
Limiter le nombre de Global Admin
Microsoft recommande de rester en dessous de cinq Global Administrator, car ce rôle dispose d’un accès pratiquement illimité. Une alerte apparaît sur la page Overview d’Entra ID au-delà de ce seuil. Gardez également le total des attributions de rôles privilégiés en dessous de 10, car Entra affiche un avertissement au-delà de ce nombre et marque les rôles privilégiés PRIVILEGED. Conservez aussi deux comptes de secours (« break glass ») cloud uniquement, attribués en permanence au rôle Global Administrator, non rattachés à une personne en particulier, afin de ne jamais vous retrouver bloqué hors de votre propre tenant.
En pratique, la façon d’atteindre ce seuil de « moins de cinq » est la délégation : confiez le travail bien délimité à l’un des 8 rôles Teams ci-dessus, ou à un rôle personnalisé, plutôt que de basculer sur Global Administrator par habitude. Le RBAC au niveau applicatif peut aussi y contribuer : nBold, par exemple, superpose ses propres rôles délégués (End-User, Catalog Manager, Integration Manager, Teams Service Admin, Global Admin) en complément des rôles Entra plutôt qu’en remplacement, de sorte que le travail courant, comme la création de modèles d’espace de collaboration, la configuration d’intégrations ou la maintenance en masse des espaces, ne nécessite pas de rôle Global Admin à l’échelle du tenant. Chaque action passe toujours par l’API Microsoft Graph, sous les permissions que le tenant contrôle.
La MFA fait partie de la même discussion. Amy Hogan-Burney, Corporate Vice President, Customer Security & Trust chez Microsoft, a déclaré lors de l’annonce du Microsoft Digital Defense Report 2025 que « la MFA peut bloquer plus de 99 % des attaques basées sur l’identité ». Ce même rapport indique que plus de 97 % des attaques d’identité sont des attaques par mot de passe, et que les attaques ont bondi de 32 % au premier semestre 2025, ce qui correspond exactement à la cible que représentent les comptes privilégiés. Par ailleurs, les recommandations de bonnes pratiques Microsoft sur les rôles Entra citent encore un chiffre plus ancien, issu d’une étude antérieure : la MFA rend un compte 99,9 % moins susceptible d’être compromis. Source différente, même tendance.
Utilisez également des comptes natifs du cloud pour les attributions de rôles Entra, plutôt que des comptes synchronisés depuis l’environnement local, car un compte synchronisé compromis peut lui aussi atteindre les ressources gérées par Entra.
Des contrôles complémentaires, au-delà des rôles
Les rôles ne suffisent pas à eux seuls à couvrir tout le contrôle d’accès. Les recommandations de bonnes pratiques Microsoft sur Entra décrivent un modèle en couches combinant plusieurs contrôles, chacun adapté à un problème différent :
| Contrôle | Ce qu’il fait | Quand l’utiliser |
|---|---|---|
| Administrative units | Limiter un rôle à un sous-ensemble d’utilisateurs, de groupes ou d’appareils | Déléguer à des administrateurs régionaux/départementaux sans accès à l’échelle du tenant |
| Custom roles | Définir exactement les permissions nécessaires à une tâche | Rôles intégrés trop larges ou trop restreints |
| PIM | Activation juste-à-temps, limitée dans le temps et soumise à approbation | Éliminer les accès privilégiés permanents |
| Conditional Access | Évaluer des signaux en temps réel : risque, appareil, localisation, application | Décisions d’accès basées sur le contexte |
| Entitlement management | Regrouper des ressources dans des packages d’accès avec approbation/expiration | Gouverner les accès à grande échelle |
| Continuous Access Evaluation (CAE) | Réévaluer l’accès en cours de session lors d’événements critiques ou de changements de stratégie | Appliquer les changements en quasi-temps réel, sans attendre l’expiration du jeton |
| Custom security attributes (Azure ABAC) | Étiqueter des principaux et conditionner l’accès à un attribut | Actuellement, actions de données Azure Blob/Queue Storage |
L’exemple concret donné par Microsoft : un rôle personnalisé limité à une unité d’administration pour qu’un administrateur de support régional ne puisse réinitialiser des mots de passe que dans sa région, une activation PIM pour la limiter dans le temps et la soumettre à approbation, un accès conditionnel exigeant un appareil conforme et la MFA à l’activation, et des révisions d’accès pour confirmer que l’administrateur en a toujours besoin. Les rôles personnalisés et l’accès conditionnel nécessitent Entra ID P1, tout comme les unités d’administration pour les administrateurs qui y sont limités. PIM nécessite Entra ID P2 ou Microsoft Entra ID Governance, tandis que la gestion des droits d’utilisation et les révisions d’accès nécessitent Entra ID Governance ou Microsoft Entra Suite.
Examinez les étiquettes de confidentialité et les groupes Microsoft 365 auxquels elles s’appliquent en parallèle de votre structure de rôles : le contrôle d’accès et la classification des données doivent être conçus ensemble.
Surveillance et révisions d’accès
L’audit se trouve désormais dans le portail Microsoft Purview, sur purview.microsoft.com, sous la vignette Audit : l’ancienne appellation Security & Compliance Center est retirée. Il est activé par défaut pour les licences Microsoft 365 standard, mais pas pour les licences PME (Business Basic, Standard, Premium), les essais gratuits ou les tenants d’entreprise non gérés. Vérifiez-le explicitement avec Exchange Online PowerShell :
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabledL’activer tardivement signifie perdre toute visibilité sur tout ce qui précède l’activation : confirmez-le donc dès la configuration initiale du tenant, pas après un incident.
Au-delà de la journalisation, effectuez des révisions d’accès périodiques sur les attributions de rôles. Microsoft avance deux raisons à cela : un compte peut être compromis, et les collaborateurs changent d’équipe au sein d’une entreprise, accumulant au fil du temps un accès superflu si personne ne l’audite. Les révisions d’accès nécessitent Microsoft Entra ID Governance ou Microsoft Entra Suite.
FAQ
Quels sont les rôles d’administration Microsoft Teams ? Microsoft Entra ID compte 8 rôles d’administration spécifiques à Teams : Teams Administrator, Teams Communications Administrator, Teams Communications Support Engineer, Teams Communications Support Specialist, Teams Devices Administrator, Teams External Collaboration Administrator, Teams Reader et Teams Telephony Administrator. Chacun couvre une partie différente du service Teams, de l’administration complète à l’accès en lecture seule, en passant par des tâches précises comme la gestion des appareils ou les paramètres de collaboration externe.
Quelle est la différence entre Teams Communications Support Engineer et Support Specialist ? Les deux résolvent des problèmes d’appels et de réunions, mais avec des outils différents. Le Support Engineer dispose des outils de diagnostic avancés et d’un accès au Call Quality Dashboard jusqu’aux utilisateurs précis affectés par une mauvaise qualité d’appel. Le Support Specialist ne dispose que des outils de base et, dans Call Analytics, ne peut consulter les informations que pour l’utilisateur spécifique recherché.
Puis-je attribuer des rôles d’administration Teams à un groupe plutôt qu’à des utilisateurs individuels ? Oui, à condition d’utiliser un groupe pouvant se voir attribuer un rôle, ce qui nécessite Microsoft Entra ID P1. Le groupe doit être créé comme pouvant se voir attribuer un rôle dès le départ, car ce paramètre est immuable et ne peut pas être ajouté ultérieurement. Le type d’appartenance doit être Assigned. Les groupes à appartenance dynamique ne sont pas pris en charge pour l’attribution de rôles, car des changements d’appartenance automatisés pourraient ajouter un compte non souhaité à un rôle privilégié.
Combien de Global Administrator devrions-nous avoir ? Microsoft recommande de rester en dessous de cinq Global Administrator, car ce rôle dispose d’un accès pratiquement illimité sur l’ensemble du tenant. Au-delà de cinq attributions actives, Entra ID affiche un avertissement sur la page Overview. Microsoft recommande également de conserver deux comptes d’urgence cloud uniquement, attribués en permanence au rôle Global Administrator, non rattachés à une personne en particulier, au cas où l’accès administrateur habituel serait indisponible.
Ai-je besoin d’une licence pour Privileged Identity Management ? Oui. Privileged Identity Management nécessite Microsoft Entra ID P2 ou Microsoft Entra ID Governance. PIM permet de rendre les attributions de rôles éligibles plutôt que permanentes, afin que les administrateurs activent un rôle uniquement lorsqu’ils en ont besoin, pour une durée limitée, plutôt que de disposer d’un accès privilégié permanent en continu.
En résumé
Huit rôles couvrent la surface d’administration spécifique à Teams dans Entra ID, et choisir le bon pour chaque tâche, plutôt que de recourir par défaut à Global Administrator, constitue l’essentiel de ce que signifie « bien faire le RBAC » ici. Ajoutez des groupes pouvant se voir attribuer un rôle correctement construits (appartenance Assigned, jamais dynamique), PIM pour tout ce qui ne nécessite pas d’accès permanent, des unités d’administration et l’accès conditionnel là où un rôle intégré est trop grossier, et des révisions d’accès régulières pour que les permissions inutilisées ne s’accumulent pas discrètement. Rien de tout cela n’est compliqué ; il suffit de l’appliquer avec constance à mesure que votre tenant grandit.