28 mai 2026

RBAC, ABAC, PBAC : quel modèle de contrôle d'accès choisir

À retenir

Le RBAC attribue les droits via des rôles ; l’ABAC les calcule dynamiquement à partir d’attributs ; le PBAC structure ces décisions sous forme de politiques explicites.
RBAC et ABAC sont des modèles formalisés (respectivement ANSI/INCITS 359 et NIST SP 800-162). Le PBAC, lui, n’a pas de standard équivalent : c’est davantage une approche d’expression et de gouvernance des politiques.
En pratique, ces approches ne se remplacent pas : elles se combinent — RBAC en socle stable, ABAC pour les décisions contextuelles, PBAC pour gouverner les règles.
Le choix ne se résume pas à un classement « meilleur / moins bon » : il dépend de la taille, de la dynamique des accès, de la maturité de la gouvernance et du secteur.

Introduction

Dès qu’une organisation compte plus de quelques dizaines d’utilisateurs et d’applications, attribuer les permissions au cas par cas devient impraticable. Un modèle de contrôle d’accès s’impose : un cadre qui décide, de façon systématique, qui peut faire quoi sur quelle ressource. Trois approches dominent les discussions et les solutions du marché : RBAC, ABAC et PBAC. La SERP française les présente souvent comme trois étapes d’une évolution linéaire — c’est une simplification trompeuse.

Cet article les définit avec précision, en s’appuyant sur les sources normatives existantes, montre où elles diffèrent réellement et explique comment les combiner. Il s’adresse aux architectes et chefs de projet IAM qui doivent choisir ou faire évoluer un modèle d’autorisation. C’est l’un des satellites du silo Gouvernance des identités (IGA).

Les trois en une phrase

RBAC (Role-Based Access Control, contrôle d’accès basé sur les rôles) : les permissions sont attachées à des rôles, et les utilisateurs héritent des permissions via les rôles qui leur sont affectés.
ABAC (Attribute-Based Access Control, contrôle d’accès basé sur les attributs) : la décision d’autorisation est calculée à partir d’attributs du sujet, de la ressource, de l’action demandée et de l’environnement, évalués contre des règles.
PBAC (Policy-Based Access Control, contrôle d’accès basé sur les politiques) : approche dans laquelle les décisions d’accès sont exprimées par des politiques explicites et centralisées, indépendantes du code des applications.

RBAC : le contrôle d’accès basé sur les rôles

Principe

Le RBAC est un modèle indirect : on n’attribue pas une permission à une personne, on l’attribue à un rôle, puis on affecte ce rôle à des personnes. Le modèle a été formalisé en 1992 par David Ferraiolo et Rick Kuhn au NIST, puis normalisé sous la référence ANSI/INCITS 359 (édition 2004, révisée en 2012, reconduite R2022). C’est aujourd’hui le modèle le plus répandu dans les entreprises.

Forces

Le RBAC est simple à comprendre et à auditer : « ce rôle existe parce que telle fonction métier existe, et il porte ces permissions parce que cette fonction le requiert ». Il s’aligne naturellement sur l’organisation et facilite les recertifications. Un responsable métier peut valider « tel rôle est-il toujours justifié pour ces personnes ? » bien plus facilement qu’une liste de permissions atomiques.

Limites

Le RBAC montre ses limites face aux accès dynamiques : quand l’autorisation dépend du contexte (heure, localisation, sensibilité de la donnée, appartenance temporaire à un projet), il faut multiplier les rôles pour couvrir chaque combinaison — c’est l’explosion des rôles. La construction et l’entretien d’une structure de rôles propre est en soi un enjeu, traité par la démarche de role mining.

ABAC : le contrôle d’accès basé sur les attributs

Principe

L’ABAC évalue dynamiquement, à chaque demande d’accès, des attributs caractérisant la situation. Le NIST le définit formellement dans sa Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations : une méthodologie de contrôle d’accès logique où l’autorisation est déterminée par l’évaluation d’attributs associés au sujet, à l’objet, à l’opération demandée et, le cas échéant, aux conditions d’environnement, comparés à des règles décrivant les opérations autorisées.

Concrètement, quatre familles d’attributs entrent en jeu :

Sujet : caractéristiques de l’utilisateur (département, ancienneté, habilitation, certifications).
Ressource : caractéristiques de l’objet accédé (classification, propriétaire, statut).
Action : nature de l’opération (lire, écrire, supprimer, approuver).
Environnement : contexte de la demande (heure, localisation, réseau, niveau de risque).

Une règle ABAC prend une forme du type : « un utilisateur dont le département est X peut lire un document dont la classification est Y, pendant les heures ouvrées, depuis le réseau de l’entreprise ».

Forces

L’ABAC permet une granularité fine et un comportement dynamique : une modification d’attribut (un changement de département, par exemple) modifie automatiquement les accès sans toucher aux règles. Il convient particulièrement aux environnements où les décisions dépendent du contexte.

Limites

La contrepartie est la complexité de gouvernance. Les règles ABAC peuvent interagir de façon difficile à anticiper, et auditer « pourquoi cette personne a-t-elle pu accéder à cette ressource à ce moment ? » demande de reconstituer l’évaluation des règles à l’instant T. La qualité des attributs (à jour, fiables) devient critique : un attribut faux peut accorder ou refuser à tort. L’ABAC réclame donc une discipline de gestion des données et de test des politiques.

PBAC : le contrôle d’accès basé sur les politiques

Principe, et un point d’honnêteté

Le PBAC est moins un modèle au sens strict qu’une approche d’expression et de gouvernance des décisions d’accès. Là où le RBAC et l’ABAC font l’objet de normes établies (ANSI/INCITS 359 et NIST SP 800-162), le PBAC n’a pas d’équivalent normatif unique : le terme désigne avant tout l’idée d’exprimer les règles d’autorisation sous forme de politiques explicites, centralisées, lisibles et gouvernables, indépendantes du code des applications qui les appliquent.

C’est pourquoi il est plus rigoureux de présenter le PBAC comme une façon d’organiser RBAC ou ABAC — en découplant l’écriture des règles de leur mise en œuvre — plutôt que comme un troisième modèle situé sur le même plan.

Forces

Centraliser les politiques apporte cohérence, auditabilité et capacité d’évolution : une règle modifiée à un endroit s’applique partout, et la politique est exprimable dans des termes compréhensibles par les responsables métier et conformité. Le standard XACML (eXtensible Access Control Markup Language), publié par l’OASIS, est l’exemple historique d’un langage d’expression de politiques associé à cette approche.

Limites

Les difficultés sont proches de celles de l’ABAC quand les politiques deviennent nombreuses : interactions complexes, besoin de tests rigoureux, et nécessité d’outils dédiés (moteur de politiques, points de décision et d’application séparés des applications elles-mêmes).

Comparatif synthétique

Critère	RBAC	ABAC	PBAC
Base de décision	Rôles	Attributs (sujet, ressource, action, environnement)	Politiques explicites (souvent en s’appuyant sur des attributs)
Standard de référence	ANSI/INCITS 359	NIST SP 800-162	Pas de standard formel unique (XACML/OASIS comme exemple)
Dynamique	Statique (le rôle change peu)	Dynamique (recalcul à chaque demande)	Variable selon l’implémentation
Granularité	Moyenne	Fine	Fine, selon les politiques
Lisibilité métier	Élevée	Plus faible	Élevée si politiques bien écrites
Auditabilité	Élevée	Plus complexe	Élevée si gouvernance des politiques en place
Risque principal	Explosion des rôles	Complexité, qualité des attributs	Prolifération et conflits de politiques
Usage type	Socle stable d’autorisation	Décisions contextuelles, sécurité fine	Gouvernance centralisée des règles

En pratique : combiner plutôt que remplacer

Présenter RBAC, ABAC et PBAC comme une suite linéaire à suivre conduit à de mauvaises décisions. Les implémentations réelles les combinent :

Le RBAC sert de socle pour les autorisations stables liées aux fonctions de l’organisation (accès « par défaut »).
L’ABAC vient compléter le RBAC pour les décisions qui dépendent du contexte (sensibilité de la ressource, environnement de connexion, appartenance à un projet temporaire).
Le PBAC fournit le cadre de gouvernance : exprimer ces décisions sous forme de politiques explicites, centralisées et auditables, qu’elles s’appuient sur des rôles, des attributs, ou les deux.

Cette combinaison limite l’explosion des rôles tout en évitant la complexité ingérable d’un ABAC pur.

Comment choisir

Le bon point de départ n’est pas le modèle, mais le profil de l’organisation et des accès :

Taille et stabilité. Petite ou moyenne organisation, accès relativement stables alignés sur des fonctions : un RBAC bien construit suffit souvent.
Dynamique des accès. Beaucoup de décisions dépendantes du contexte (heure, localisation, sensibilité, projet) : un complément ABAC devient utile.
Maturité de la gouvernance. Si les attributs ne sont pas fiables ou si la gouvernance des politiques n’existe pas, introduire de l’ABAC ou du PBAC risque de produire plus de complexité que de contrôle.
Exigences sectorielles. Certains secteurs (santé, finance, défense) ont des besoins de granularité ou de traçabilité qui poussent vers ABAC/PBAC, mais ne dispensent pas du socle RBAC.

Une bonne séquence consiste à fiabiliser un modèle de rôles avant d’introduire des règles contextuelles, puis à passer en gouvernance par politiques quand la maturité le permet.

FAQ

Quelle est la principale différence entre RBAC et ABAC ? Le RBAC accorde l’accès via des rôles attribués aux utilisateurs ; l’ABAC le calcule à la demande à partir d’attributs (utilisateur, ressource, action, environnement). Le RBAC est plus simple à auditer ; l’ABAC est plus granulaire et dynamique.

Le PBAC est-il « mieux » que le RBAC et l’ABAC ? La question est mal posée : le PBAC n’est pas au même niveau. C’est une approche d’expression des politiques, qui peut envelopper du RBAC, de l’ABAC, ou les deux. Il ne les remplace pas.

Peut-on combiner RBAC et ABAC ? Oui, c’est même le cas le plus courant en pratique : le RBAC fournit le socle stable, l’ABAC gère les décisions contextuelles. Cette combinaison limite l’explosion des rôles.

Faut-il un outil dédié pour faire de l’ABAC ou du PBAC ? À petite échelle, des règles dispersées dans les applications peuvent suffire. À mesure que les règles se multiplient, un moteur de politiques externalisé (avec des points de décision et d’application séparés) devient nécessaire pour rester gouvernable.

Conclusion

Le choix d’un modèle de contrôle d’accès n’est pas un classement entre RBAC, ABAC et PBAC mais une question d’adéquation au contexte : ce que l’organisation veut décider, à quelle granularité, et avec quelle gouvernance. En pratique, ces approches se combinent. Pour démarrer concrètement, le plus efficace est de bâtir d’abord un RBAC propre, d’identifier les décisions qui résistent vraiment au modèle par rôles, puis d’introduire l’ABAC sur ces zones et le PBAC quand la quantité de règles le justifie.

Sources

ANSI/INCITS 359, Information Technology – Role Based Access Control (édition 2004 ; révision INCITS 359-2012, reconduite R2022). Modèle RBAC du NIST.
NIST Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations (2014, révisée).
OASIS — XACML (eXtensible Access Control Markup Language), exemple historique de langage d’expression de politiques.