--- term: "Contrôle d'Accès Basé sur les Rôles (RBAC)" seoTitle: 'Le RBAC expliqué : rôles, modèle NIST, explosion des rôles, conception' headline: "Qu'est-ce que le contrôle d'accès basé sur les rôles (RBAC) ?" slug: controle-d-acces-rbac category: auth-security shortDefinition: "Le contrôle d'accès basé sur les rôles est un modèle d'autorisation où les permissions s'attachent aux rôles, jamais directement aux utilisateurs." relatedTerms: - access-control-lists-acl - class-level-permissions-clp - identity-access-management-iam - row-level-security contrastsWith: - access-control-lists-acl aboutTerms: - 'Role Hierarchy' - 'Separation of Duties' - 'Role Explosion' faq: - question: "Qu'est-ce que le RBAC, en termes simples ?" answer: "L'accès s'accorde par fonction, pas par personne : les permissions s'attachent à des rôles — Editor, Admin, Support — et les utilisateurs héritent de tout ce que portent les rôles qui leur sont affectés. Embauche, promotion et départ deviennent des changements de rôle en un seul endroit, au lieu de modifications de permissions éparpillées partout." - question: 'Quelle est la différence entre RBAC et ABAC ?' answer: "Le RBAC décide à partir de rôles prédéfinis ; le contrôle d'accès basé sur les attributs (ABAC) évalue des attributs de l'utilisateur, de la ressource et du contexte — service, sensibilité, heure — au moment de la requête. Le RBAC est plus simple à raisonner et à auditer ; l'ABAC est plus fin et plus difficile à déboguer. Les systèmes matures prennent le RBAC comme socle et ajoutent des conditions d'attributs là où le contexte compte vraiment." - question: 'Quelle est la différence entre le RBAC et une ACL ?' answer: "Le sens du rattachement : une ACL accroche des entrées sujet-permission à chaque objet ; le RBAC accroche les permissions à des rôles valables dans tout le système. Les deux se composent plutôt qu'ils ne s'opposent — une entrée d'ACL peut nommer un rôle, et c'est ainsi que le contrôle par objet et la gestion des membres en un seul endroit cohabitent." - question: 'Quels sont les modèles de RBAC ?' answer: "Le standard définit le RBAC de base (utilisateurs, rôles, permissions, sessions), le RBAC hiérarchique (les rôles seniors héritent des permissions des rôles juniors) et le RBAC contraint (règles de séparation des tâches — contraintes statiques sur l'affectation, contraintes dynamiques sur ce qu'une même session peut activer simultanément)." - question: 'Quelles sont les trois règles du RBAC ?' answer: "Issues de la formulation originale de 1992 : un sujet ne peut agir qu'à travers un rôle sélectionné (affectation de rôle) ; le sujet doit être autorisé pour ce rôle (autorisation de rôle) ; et une action n'est permise que si le rôle actif détient la permission correspondante (autorisation de permission). En somme : aucun accès autrement que par les rôles." - question: "Qu'est-ce que l'explosion des rôles (role explosion) ?" answer: "La croissance incontrôlée des rôles lorsque chaque exception, projet, région ou tenant engendre un nouveau rôle — Project-A-Manager-Region-West — jusqu'à ce que les rôles soient plus nombreux que les utilisateurs et que plus personne ne puisse auditer le système. La cause profonde : encoder des attributs contextuels sous forme de rôles au lieu de les traiter par des conditions ou des entrées par objet." - question: 'Le RBAC, est-ce la même chose que le moindre privilège ?' answer: "Non — le moindre privilège est le principe, le RBAC un mécanisme pour le poursuivre, et seule la discipline des rôles relie les deux. Un rôle trop large viole le moindre privilège de l'intérieur même du RBAC ; restreindre les rôles au minimum et les revoir périodiquement, voilà ce qui fait réellement vivre le principe." - question: "Qu'est-ce que la séparation des tâches dans le RBAC ?" answer: "Des contraintes qui tiennent à distance les pouvoirs incompatibles : la séparation statique interdit à un même utilisateur de détenir à la fois le rôle de créateur de paiements et celui d'approbateur ; la séparation dynamique autorise les deux, mais jamais activés dans la même session. C'est de la prévention de la fraude exprimée comme une règle de rôle." codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'NIST Role-Based Access Control project' url: 'https://csrc.nist.gov/projects/role-based-access-control' - name: 'Ferraiolo & Kuhn — Role-Based Access Control (1992)' url: 'https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/ferraiolo-kuhn-92.pdf' - name: 'NISTIR 7316 — Assessment of Access Control Systems' url: 'https://nvlpubs.nist.gov/nistpubs/legacy/ir/nistir7316.pdf' - name: 'OWASP Authorization Cheat Sheet' url: 'https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html' cta: title: 'Des rôles que vous pouvez interroger' text: "Sur Back4app, les rôles sont des objets de la base de données : ajoutez des membres via une relation, imbriquez des rôles pour obtenir une hiérarchie et accordez les droits via les permissions de classe et les ACL d'objet — un RBAC appliqué par la plateforme à chaque requête." linkText: 'Commencez gratuitement' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-11' translationKey: role-based-access-control-rbac --- **Le contrôle d'accès basé sur les rôles est un modèle d'autorisation où les permissions s'attachent aux rôles, jamais directement aux utilisateurs.** Toute l'idée tient dans cette indirection : rien n'est jamais accordé directement à une personne, si bien qu'un changement d'organisation devient un changement de données — une promotion est une réaffectation de rôle, pas une fouille archéologique parmi des droits éparpillés. Proposé par [Ferraiolo et Kuhn en 1992](https://csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/documents/ferraiolo-kuhn-92.pdf) comme alternative aux modèles discrétionnaire et obligatoire plus anciens, il est devenu le standard ANSI/INCITS 359 et le vocabulaire d'autorisation par défaut des logiciels d'entreprise. ## Points clés | Question | Réponse | | --- | --- | | L'indirection | Utilisateur → rôle → permission — jamais utilisateur → permission directement | | Rôle ≠ groupe | Un groupe rassemble des *utilisateurs* ; un rôle rassemble des *permissions* | | Les niveaux du modèle | De base · hiérarchique (héritage) · contraint (séparation des tâches) | | Le mode de défaillance | L'explosion des rôles — des attributs encodés en rôles jusqu'à ce que les rôles dépassent les utilisateurs | | La composition | Des rôles dans les entrées d'ACL : le RBAC pour la masse, les ACL pour les exceptions | ## Utilisateurs, rôles, permissions — l'indirection à l'œuvre ```text Permissions Rôles Utilisateurs ───────────── ───────────── ───────────── posts:read ─┐ posts:write ├──▶ Editor ◀────── Ada, Grace posts:publish ─┘ users:manage ─┐ billing:view ├──▶ Admin ◀────── Linus posts:* ─┘ posts:read ────▶ Viewer ◀────── tous les autres Ada publie parce qu'Editor porte posts:publish — réaffectez son rôle, et chaque permission qu'il portait la suit. Une modification, pas N. ``` Des rôles sous forme de données vivantes, branchés sur les permissions des objets : **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Roles as data: create a role, add members, grant through it const roleACL = new Parse.ACL(); roleACL.setPublicReadAccess(true); const editors = new Parse.Role('Editors', roleACL); editors.getUsers().add(adaUser); await editors.save(); // Grant by role, not by user — membership changes in one place const post = new Parse.Object('Post'); const acl = new Parse.ACL(currentUser); // owner entry acl.setRoleWriteAccess('Editors', true); // RBAC meets the object's ACL post.setACL(acl); await post.save(); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Roles as data: create a role, add members, grant through it final roleACL = ParseACL()..setPublicReadAccess(allowed: true); final editors = ParseObject('_Role') ..set('name', 'Editors') ..setACL(roleACL) ..addRelation('users', [adaUser]); await editors.save(); // Grant by role, not by user — membership changes in one place final post = ParseObject('Post'); final acl = ParseACL(owner: currentUser) // owner entry ..setRoleWriteAccess('Editors', true); // RBAC meets the object's ACL post.setACL(acl); await post.save(); ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Roles as data: create a role, add members, grant through it var editors = try ParseRole(name: "Editors") let savedRole = try await editors.save() try await savedRole.users.add([adaUser]).save() // membership = a relation // Grant by role, not by user — membership changes in one place var post = Post() var acl = ParseACL() acl.setReadAccess(user: currentUser, value: true) acl.setWriteAccess(user: currentUser, value: true) // owner entry acl.setWriteAccess(roleName: "Editors", value: true) // RBAC meets the ACL post.ACL = acl try await post.save() ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Roles as data: create a role, add members, grant through it val roleACL = ParseACL() roleACL.publicReadAccess = true val editors = ParseRole("Editors", roleACL) editors.users.add(adaUser) editors.save() // Grant by role, not by user — membership changes in one place val post = ParseObject("Post") val acl = ParseACL(ParseUser.getCurrentUser()) // owner entry acl.setRoleWriteAccess("Editors", true) // RBAC meets the object's ACL post.acl = acl post.save() ``` ## Le modèle NIST, correctement La plupart des explications compressent le standard en une liste à puces ; la structure réelle mérite trente secondes. Le **RBAC de base** définit les utilisateurs, les rôles, les permissions — et les *sessions*, l'élément oublié : un utilisateur active un sous-ensemble de ses rôles par session, ce qui permet à un administrateur de naviguer par défaut avec des pouvoirs de simple membre et de s'élever délibérément. Les trois règles de l'article original font tenir l'ensemble : n'agir qu'à travers un rôle, ne détenir que des rôles autorisés, ne faire que ce que le rôle actif permet. Le **RBAC hiérarchique** ajoute l'héritage — les rôles seniors englobent les rôles juniors (Manager ⊇ Employee), ce qui supprime les doublons. Le **RBAC contraint** ajoute la séparation des tâches : les règles *statiques* interdisent purement et simplement les affectations de rôles incompatibles (jamais créateur et approbateur de paiements à la fois) ; les règles *dynamiques* autorisent l'affectation mais interdisent d'activer les deux dans une même session. Et la clarification la plus tranchante du NIST, régulièrement déformée : un **groupe est une collection d'utilisateurs ; un rôle est une collection de permissions** — le rôle se définit par ce qu'il peut faire, pas par qui en fait partie. ```mermaid flowchart LR accTitle: Structure du RBAC avec sessions et séparation des tâches accDescr: Les utilisateurs se voient affecter des rôles et en activent un sous-ensemble par session. Les rôles portent des permissions et peuvent hériter de rôles juniors. Les contraintes de séparation des tâches limitent les rôles qui peuvent être affectés ou activés ensemble, et les permissions s'appliquent aux ressources. U["Utilisateur
Ada"] -->|"affectés"| R["Rôles
Editor · Auditor"] U -->|"active un sous-ensemble
par session"| S["Session
Editor uniquement"] R -->|"hérite"| RJ["Rôle junior
Viewer"] R ---|"contrainte SoD :
pas avec Approver"| X["Rôle incompatible"] S -->|"permissions des
rôles actifs"| P["posts:write
posts:publish"] --> D[("Ressources")] ``` ## RBAC vs. ACL vs. ABAC | | RBAC | [ACL](/glossary/fr/listes-de-controle-d-acces-acl/) | ABAC | | --- | --- | --- | --- | | Les permissions s'attachent à | Des rôles | Chaque objet | Des règles d'attributs | | Question native | Que peut faire cette *fonction* ? | Qui peut toucher *cet objet* ? | Est-ce autorisé *dans ce contexte* ? | | Administration | Un seul endroit par rôle | Par objet | Par politique | | Partage par objet | Impossible à exprimer | Son terrain de prédilection | Exprimable, mais verbeux | | Auditer "que peut faire Ada ?" | Lire ses rôles | Parcourir chaque objet | Évaluer chaque règle | | Mode de défaillance | Explosion des rôles | Prolifération des listes | Politiques opaques | Ce que les pages de résultats des éditeurs enterrent : ces modèles **se composent, ils ne s'opposent pas**. Les rôles gèrent l'accès qui suit la fonction ; les entrées d'ACL gèrent les exceptions par objet — et la charnière est l'*ACE de rôle*, une ligne d'ACL qui nomme un rôle plutôt qu'un utilisateur, offrant un contrôle au niveau de l'objet avec une gestion des membres en un seul endroit. Les conditions d'attributs se superposent là où le contexte (heure, tenant, état de l'enregistrement) décide vraiment. "Lequel choisir ?" est généralement la mauvaise question ; "quelle couche prend quelle décision ?", c'est la conception. ## L'explosion des rôles — le mode de défaillance La maladie caractéristique du RBAC : chaque exception engendre un rôle, puis chaque projet, région et tenant les multiplie — `Project-A-Manager-Region-West-ReadOnly` — jusqu'à ce que les rôles soient plus nombreux que les utilisateurs et que la réponse de l'audit à "qui peut faire quoi ?" soit "personne ne sait". La cause profonde est toujours la même : **des attributs contextuels encodés sous forme de rôles**. Les parades, dans l'ordre : sortez les attributs des noms de rôle (la région et le tenant sont des conditions ou des périmètres, pas des rôles) ; gérez le partage par objet avec des [entrées d'ACL](/glossary/fr/listes-de-controle-d-acces-acl/), jamais avec des rôles par objet ; cloisonnez les rôles par [tenant](/glossary/fr/isolation-des-tenants/) de façon structurelle plutôt qu'en bricolant des noms ; et auditez — les rôles que personne ne détient, les permissions qu'aucun rôle n'utilise et les droits dont plus personne ne se souvient constituent une dérive, et c'est par la dérive que le moindre privilège meurt en silence. Une heuristique qui fonctionne : si la liste des rôles ne tient plus sur un écran, le modèle absorbe un travail qui revient à une autre couche. ## Concevoir les rôles : top-down, bottom-up, ou les deux Le volet qu'aucune explication bien classée ne couvre : d'où viennent les rôles. L'approche **top-down** les dérive de l'organisation et de ses processus — interroger les métiers, nommer les fonctions, attribuer des permissions minimales ; précis mais lent. L'approche **bottom-up** les extrait des droits existants — regrouper qui détient déjà quoi, et des rôles candidats en émergent ; rapide, mais cela blanchit les erreurs passées en politique officielle. La pratique est hybride : extraire des candidats, les valider face aux fonctions, puis appliquer le test 80/20 — une poignée de rôles larges pour le gros de l'organisation, les exceptions étant gérées par des ACL ou des conditions plutôt que par des rôles sur mesure. Et une règle d'implémentation qui survit à toutes les réorganisations : **le code doit vérifier des permissions, pas des noms de rôle** — `can('posts:publish')`, pas `hasRole('Editor')` —, pour que redéfinir un rôle soit un changement de données et non un refactoring, avec une application des règles [côté serveur](/glossary/fr/securite-couche-donnees-vs-application/) et un refus par défaut. ## Cas d'usage courants - **Panneaux d'administration et back-offices** — support, modérateur, finance, super-admin : les fonctions se traduisent proprement en rôles. - **Workflows de contenu et de publication** — auteur, éditeur, publieur, avec une séparation entre écrire et publier. - **Permissions d'équipe en SaaS B2B** — owner/admin/membre/facturation par espace de travail, cloisonnés par tenant. - **Opérations soumises à la conformité** — la séparation des tâches sous forme de contraintes de rôle applicables, l'appartenance aux rôles servant de pièce d'audit. - **La porte des rôles sur les couches de données** — les rôles comme le "qui" des [permissions au niveau de la classe](/glossary/fr/permissions-de-classe-clp/) et des [politiques au niveau des lignes](/glossary/fr/securite-au-niveau-des-lignes/). ## Devriez-vous utiliser le RBAC ? Matrice de décision | Situation | Penchez pour | | --- | --- | | L'accès suit la fonction de chacun | Le RBAC — son terrain de prédilection | | Les utilisateurs partagent des enregistrements au cas par cas | Des ACL — les rôles ne savent pas l'exprimer | | Le contexte décide (heure, état, tenant) | Des conditions d'attributs par-dessus les rôles | | Une poignée de types d'utilisateurs, stables | Le RBAC avec 3 à 7 rôles larges | | Organigrammes profonds, équipes imbriquées | Une hiérarchie de rôles — ou du ReBAC à vraiment grande échelle | | "Juste des admins et tous les autres" | Une seule porte de rôle — ne surmodélisez pas | ## Limites et trade-offs - **Le partage par objet est hors périmètre.** "Partager ce document avec Ana" n'a pas de réponse RBAC, sauf à créer un rôle par document — cette décision revient aux ACL. - **Même rôle, mêmes pouvoirs.** Deux Editors sont indiscernables ; la nuance individuelle exige une autre couche, pas un rôle quasi dupliqué. - **L'ingénierie des rôles est un vrai travail en amont.** La sauter produit des rôles qui ne reflètent ni l'organisation ni le modèle de risque — et qui sont copiés à l'infini. - **Des rôles statiques ne voient pas le risque dynamique.** L'appartenance à un rôle ne perçoit ni les horaires inhabituels, ni les nouveaux appareils, ni les états sensibles d'un enregistrement ; c'est le territoire des attributs. - **La dérive est l'état stationnaire.** Sans recertification périodique, le périmètre des rôles ne fait que grandir ; l'auditabilité du RBAC est une capacité, pas une garantie. ## Les rôles sur Back4app Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Les rôles y sont **des données, pas du code** : chacun est un objet de la classe `_Role`, avec une relation `users` pour les membres et une relation `roles` pour l'imbrication — et l'imbrication, c'est une hiérarchie obtenue sans effort, puisque les membres d'un rôle enfant héritent de tout ce qui est accordé à ses rôles parents. Les droits eux-mêmes s'accordent exactement là où l'indique la section sur la composition : les noms de rôle apparaissent dans les [permissions au niveau de la classe](/glossary/fr/permissions-de-classe-clp/) pour les grandes lignes et dans les [entrées d'ACL](/glossary/fr/listes-de-controle-d-acces-acl/) par objet pour les exceptions — les onglets de code montrent les deux moitiés —, et Back4app applique le résultat à chaque requête REST, GraphQL et Live Query. Comme les rôles sont des objets interrogeables, la gestion des membres, les audits et les interfaces d'administration relèvent du travail ordinaire sur la base de données : prévenir l'explosion des rôles devient une habitude de modélisation, pas un projet de gouvernance.