RBAC vs ReBAC : deux modèles d'autorisation, deux philosophies

Emmanuel Gautier · 17 juillet 2026

Toute application finit par se heurter au même mur. Le système de permissions qui fonctionnait au lancement — quelques rôles, une vérification avant chaque action — commence à craquer sous la complexité du réel. De nouveaux types de ressources apparaissent. Les utilisateurs veulent contrôler finement ce qu’ils partagent et avec qui. Les équipes souhaitent déléguer des accès sans passer par un administrateur. Et soudain, le modèle admin / membre / lecteur génère des centaines de rôles ad hoc que personne ne peut auditer.

Deux modèles d’autorisation dominent cette discussion : le Role-Based Access Control (RBAC) et le Relationship-Based Access Control (ReBAC), popularisé par l’article de Google sur Zanzibar. Cet article explique comment chacun fonctionne, où chacun échoue, et comment choisir — ou les combiner.

La question à laquelle les deux modèles répondent

Avant de comparer les approches, il est utile de formuler le problème précisément. Au cœur de tout système d’autorisation se trouve une question unique :

Étant donné cet utilisateur, cette ressource et cette action — l’accès est-il autorisé ?

Les modèles diffèrent dans la façon dont ils représentent la réponse et dans la localisation de la complexité.

Pour rendre la comparaison concrète, nous utiliserons un exemple filé tout au long de cet article : un outil de gestion de projets B2B SaaS. Les utilisateurs appartiennent à des organisations. Les organisations possèdent des workspaces. Les workspaces contiennent des projets. Les projets contiennent des documents. Les utilisateurs peuvent partager des documents individuels avec des collaborateurs — internes ou externes à leur organisation. C’est un produit délibérément ordinaire, et c’est précisément l’intérêt : c’est le type de système où la complexité d’autorisation s’accumule sans crier gare.

RBAC : le modèle basé sur les rôles

Comment ça fonctionne

Le RBAC est le modèle d’autorisation le plus répandu dans les logiciels d’entreprise, et pour une bonne raison — le modèle mental est immédiatement intuitif. Pensez-y comme un intitulé de poste. Un utilisateur se voit attribuer un rôle (admin, éditeur, lecteur), et ce rôle porte un ensemble de permissions (créer_projet, modifier_document, lire_document).

L’implémentation se résume essentiellement à deux tables :

Pour répondre à la question « Bob peut-il modifier ce document ? », le système cherche le rôle de Bob (éditeur), vérifie si modifier_document est dans l’ensemble de permissions de ce rôle, et renvoie oui ou non. La vérification est en O(1). Le modèle est facile à expliquer à un auditeur de conformité. Il correspond naturellement à la façon dont les organisations pensent déjà aux accès — postes et départements.

Quand le RBAC fonctionne bien

Le RBAC est le bon modèle quand votre domaine de permissions est plat, stable et applicable à l’ensemble du produit :

• Un tableau de bord d’administration interne avec deux ou trois types d’utilisateurs
• Un produit SaaS en phase MVP où « l’admin peut tout faire, le membre peut faire la plupart des choses, le lecteur peut seulement lire » est réellement vrai
• Les contextes nécessitant une conformité stricte (SOC 2, HIPAA) où les auditeurs veulent voir un mapping clair entre les rôles et les droits d’accès
• Les produits où les permissions n’ont pas besoin de varier par instance de ressource — chaque éditeur a les mêmes droits sur chaque document

Là où le RBAC se dégrade

Les difficultés commencent dès que les permissions doivent varier au niveau de la ressource.

Dans notre exemple de gestion de projets : Alice est éditrice du Projet X mais seulement lectrice du Projet Y. Bob est propriétaire du Document 42 et souhaite le partager en lecture seule avec une prestataire externe, Carol, sans lui donner d’autre accès au workspace.

La réponse naïve en RBAC est de créer plus de rôles : éditeur-du-projet-x, éditeur-du-projet-y, lecteur-du-doc-42. C’est ce qu’on appelle l’explosion de rôles — une prolifération combinatoire qui croît avec chaque nouveau projet, document ou arrangement de partage, jusqu’à ce que la liste de rôles devienne ingérable et que le système ne fournisse plus de frontières d’accès significatives.

Le deuxième problème est le privilege creep (l’accumulation de droits). Le RBAC enregistre ce que peut faire un utilisateur, mais pas pourquoi. Quand Alice passe de l’équipe engineering au marketing, son rôle éditeur-du-projet-x n’est pas automatiquement révoqué. La relation organisationnelle d’origine qui justifiait la permission a disparu ; la permission persiste. Avec le temps, les utilisateurs accumulent des rôles qui ne reflètent plus leur position réelle dans l’organisation.

Ce ne sont pas des cas marginaux. Ce sont la trajectoire naturelle de tout produit permettant le partage au niveau de la ressource ou la réorganisation de l’organisation.

ReBAC : le modèle basé sur les relations

L’insight fondamental

Le Relationship-Based Access Control déplace la question de « quels rôles cet utilisateur possède-t-il ? » vers « quelle est la relation de cet utilisateur avec cette ressource ? »

Au lieu d’une table de rôles globale, l’état d’autorisation est un graphe de relations entre entités : utilisateurs, documents, dossiers, projets, organisations, équipes. Les permissions sont dérivées en parcourant ce graphe.

Le modèle mental est plus proche d’un réseau social que d’un organigramme. Alice n’a pas un rôle éditrice globalement — elle est éditrice de Projet X spécifiquement. Cette relation est un arc orienté dans le graphe. Quand Projet X contient Document 42, le graphe contient un second arc : Document 42 est un enfant de Projet X. Pour vérifier si Alice peut modifier Document 42, le moteur traverse le chemin : Alice → éditrice de → Projet X → parent de → Document 42. Accès accordé.

Google Zanzibar et le modèle de tuples

Le ReBAC en tant que discipline est antérieur à Google, mais le modèle tel qu’il est implémenté dans les systèmes modernes a été formalisé par l’article sur Zanzibar, publié à l’USENIX ATC en 2019. Zanzibar est le système d’autorisation derrière Google Drive, YouTube, Google Agenda et pratiquement tous les autres produits Google. Il gère des trillions d’objets pour des centaines de millions d’utilisateurs.

La primitive de données centrale dans Zanzibar est le tuple de relation, écrit ainsi :

<objet>#<relation>@<utilisateur>

Quelques exemples issus de notre outil de gestion de projets :

project:X#editor@alice
project:X#viewer@bob
document:42#parent@project:X
team:alpha#member@carol
project:X#viewer@team:alpha#member

Cette dernière ligne illustre la puissance du modèle. Elle signifie : « tout membre de team:alpha est lecteur de project:X. » Quand Carol est ajoutée à team:alpha, elle obtient immédiatement un accès en lecture à project:X et à tous ses documents — sans aucune réassignation de rôle.

Le moteur de vérification d’autorisation parcourt ces tuples comme un graphe, en suivant les arcs jusqu’à pouvoir confirmer ou refuser l’accès. Surtout, ce parcours respecte l’héritage : si une règle stipule que « les éditeurs d’un dossier sont aussi éditeurs des documents à l’intérieur », le moteur suit cette chaîne automatiquement.

L’écosystème open source

Zanzibar lui-même n’est pas disponible publiquement, mais l’article a suscité une génération d’implémentations open source :

• OpenFGA — originaire d’Auth0/Okta, désormais projet CNCF en incubation (v1.13 début 2026). L’implémentation Zanzibar la plus répandue.
• Ory Keto — intégré à la stack Ory, cloud-native, headless, API-first. Particulièrement adapté aux équipes utilisant déjà Ory Kratos ou Hydra.
• SpiceDB (Authzed) — implémentation Zanzibar commerciale avec un modèle de cohérence solide.
• Permify — OSS Zanzibar avec une adoption croissante et un profil opérationnel léger.

Ces systèmes exposent tous une API similaire : écrire des tuples de relations, définir un schéma (quelles relations existent, et lesquelles héritent d’autres), et poser des questions de vérification de permission.

Là où le ReBAC brille — et ses limites

Le ReBAC gère naturellement les cas qui font exploser le RBAC en rôles :

• Les permissions par ressource qui diffèrent entre utilisateurs
• Les hiérarchies de ressources profondes (organisation → workspace → projet → document → commentaire)
• Le partage piloté par l’utilisateur (« partager ce document avec carol@example.com en lecture seule »)
• Les architectures multi-tenant où chaque organisation gère sa propre topologie de permissions

Les compromis sont réels, cependant. Les vérifications de permission impliquent un parcours de graphe, plus coûteux en calcul qu’une recherche dans une table — bien que les systèmes de production atténuent cela avec du cache et de l’optimisation de requêtes. Plus significativement, l’auditabilité est plus complexe : en RBAC, un auditeur peut demander « listez toutes les permissions de ce rôle » et obtenir une table. En ReBAC, les permissions sont découvertes à l’exécution via le parcours de graphe, ce qui rend les requêtes d’audit statique plus complexes. Des outils comme les requêtes list-objects et list-users d’OpenFGA aident, mais le modèle demande plus d’investissement pour être pleinement auditable.

Le ReBAC est aussi limité aux relations qui peuvent être exprimées comme des arcs de graphe. Il ne peut pas gérer nativement le contexte dynamique : « autoriser l’accès uniquement pendant les heures ouvrées », ou « autoriser la suppression uniquement si le statut du document est brouillon ». Pour ces conditions, il faut une logique attributaire (ABAC) en supplément.

Comparaison côte à côte

Quand choisir lequel

Choisissez le RBAC quand :

• Votre modèle de permissions tient dans moins de ~10 catégories de rôles stables
• Les permissions ne varient pas par instance de ressource — chaque éditeur est éditeur de tout
• Vous avez besoin de pistes d’audit de conformité rapides (les auditeurs SOC 2 apprécient une matrice de rôles simple)
• Vous êtes en phase MVP et la simplicité opérationnelle est la priorité
• Votre équipe n’a pas encore l’infrastructure dédiée à un service d’autorisation séparé

Choisissez le ReBAC quand :

• Les utilisateurs doivent contrôler le partage au niveau des ressources individuelles
• Vous avez une hiérarchie de ressources profonde et les permissions doivent se propager vers le bas
• Vous construisez un produit collaboratif (éditeurs de documents, outils de projet, partage de fichiers)
• Vous êtes en SaaS B2B multi-tenant et chaque organisation doit gérer sa propre topologie de permissions sans impliquer vos développeurs
• Vous êtes déjà en situation d’explosion de rôles

La réalité hybride

La plupart des produits SaaS matures ne choisissent pas un modèle exclusivement — ils font tourner les deux en couches. Le RBAC gère la politique produit à gros grain : « les admins peuvent configurer le workspace, les membres peuvent créer des projets, les lecteurs peuvent seulement lire. » Le ReBAC gère la politique fine par ressource : « Alice est éditrice de ce projet spécifique, Carol est lectrice de ce document spécifique. »

Le signal pratique pour savoir quand ajouter le ReBAC : quand vos développeurs commencent à créer des rôles comme éditeur-du-projet-x pour gérer des permissions spécifiques à une ressource, c’est le début de l’explosion de rôles. C’est le moment d’introduire une couche relationnelle.

Lien avec les CIAM et l’infrastructure d’identité

Une distinction architecturale importante : le RBAC et le ReBAC vivent dans votre couche d’autorisation, pas dans votre couche d’authentification.

Votre plateforme CIAM (Auth0, Ory Kratos, Cognito, Stytch, etc.) gère l’identité — qui est l’utilisateur, comment il s’est authentifié, à quelle organisation il appartient. La plupart des plateformes CIAM embarquent un support natif du RBAC : elles stockent les rôles sur les profils utilisateurs et les émettent dans les tokens à la connexion.

Le ReBAC nécessite un service d’autorisation séparé en complément de votre CIAM. OpenFGA, Ory Keto et SpiceDB sont tous conçus pour fonctionner indépendamment du fournisseur d’identité. Votre CIAM authentifie l’utilisateur ; votre moteur ReBAC décide à quoi cet utilisateur peut accéder.

Les outils de gestion des utilisateurs — y compris les interfaces d’administration opérationnelles comme AUMS — opèrent au niveau de la couche identité : ils exposent les assignations de rôles, l’appartenance aux organisations et la structure des équipes qui alimentent le modèle d’autorisation utilisé en aval par l’application. Un bon outil d’administration des utilisateurs facilite l’inspection et la modification de ces assignations sans intervention des développeurs, quel que soit le modèle aval — RBAC, ReBAC ou les deux.

Conclusion

Le choix entre RBAC et ReBAC n’est pas une question de supériorité technique de l’un sur l’autre. C’est une question d’adéquation du modèle à la complexité de votre domaine de permissions.

Le RBAC est le bon point de départ pour la plupart des produits. Il est simple, auditable, et correspond naturellement à la façon dont les organisations pensent les accès. Le moment où vous vous retrouvez à créer des rôles spécifiques à des ressources pour contourner ses limites, c’est le signal d’introduire une couche relationnelle.

Le ReBAC, dans la tradition Zanzibar, gère les scénarios de permissions sur lesquels le RBAC explose en rôles. Il demande plus d’infrastructure et plus de conception de schéma, mais c’est le modèle qui passe à l’échelle avec un produit au fur et à mesure que le partage, la délégation et les hiérarchies de ressources deviennent plus complexes.

La plupart des équipes finissent par faire tourner les deux : le RBAC pour la politique au niveau produit, le ReBAC pour les décisions au niveau ressource. Comprendre la frontière entre eux — et reconnaître le moment de la franchir — est l’une des décisions architecturales les plus importantes dans un produit SaaS en croissance.