Les comparatifs RBAC contre ABAC remplissent des pages entières de résultats de recherche. Presque tous s'arrêtent au moment intéressant : la mise en production.
TL;DR : j'ai construit un système ABAC pour les droits applicatifs d'une plateforme à plus de 25 millions d'utilisateurs. En production, ce ne sont pas les policies qui cassent. Ce sont les attributs périmés, l'explosion des règles, les points d'application manquants et les décisions silencieuses. Quatre modes de défaillance, et les règles pour les contenir.
Cet article est pour les équipes qui dépassent les rôles simples et préparent le saut vers l'autorisation fine.
Le contexte
Deux définitions d'abord. Le RBAC donne des droits par rôles : admin, éditeur, lecteur. L'ABAC décide par attributs : qui demande, sur quelle ressource, dans quel contexte.
Sur la plateforme santé où je travaille, les droits applicatifs dépendent de l'utilisateur, de l'application et du site. Plus de 25 millions d'utilisateurs, plus de 1 000 sites.
Avec des rôles seuls, ce genre de matrice finit en explosion. Un rôle par combinaison, des centaines de rôles, personne ne sait plus qui peut quoi. C'est le chemin classique vers l'ABAC.
Mais l'ABAC ne supprime pas la complexité. Il la déplace : des rôles vers les attributs et les policies. Et c'est là que la production t'attend.
Le débat RBAC contre ABAC est terminé
Le match des modèles est plié depuis longtemps. En pratique, tout le monde finit hybride : du RBAC pour la base, de l'ABAC pour l'affinement.
L'outillage a mûri aussi. OpenFGA est devenu projet CNCF en incubation fin 2025. SpiceDB porte les permissions des connecteurs de ChatGPT Enterprise, via AuthZed. Le modèle Zanzibar de Google a fait des petits.
Choisir un modèle n'est donc plus le vrai problème. Le vrai problème, c'est ce qui casse ensuite. Et ça, presque personne ne l'écrit.
Défaillance n°1 : les attributs périmés
Une décision ABAC est aussi fraîche que son attribut le plus vieux.
Les attributs viennent d'ailleurs. Un annuaire, un référentiel de sites, un contrat. Ils se synchronisent, donc ils se périment.
Le piège est silencieux. Une policy parfaite, évaluée sur des attributs faux, rend des décisions fausses avec une confiance parfaite.
Mes règles. Chaque attribut a une source de vérité désignée. Chaque attribut a une fraîcheur maximale acceptée. Et un attribut absent ferme l'accès, jamais l'inverse.
Fail closed, toujours. Fail closed veut dire : en cas de doute ou de panne, refuser.
Défaillance n°2 : l'explosion des règles
Deuxième mode de défaillance : les policies s'accumulent.
Chaque cas particulier devient une règle. Personne n'ose supprimer une règle qu'il ne comprend plus. Deux règles finissent par se contredire, et l'ordre d'évaluation devient une superstition.
Mes règles. Chaque policy a un propriétaire nommé. Les policies se relisent à date fixe, et une policy sans propriétaire vivant se supprime.
Et surtout : des tests de décisions. Des cas d'or rejoués à chaque changement : cet utilisateur, cette ressource, ce contexte, ce verdict attendu. Une policy sans test de non-régression est une roulette.
Défaillance n°3 : les points d'application manquants
Le mode de défaillance le plus dangereux n'est pas une mauvaise policy. C'est un chemin de code qui ne pose jamais la question.
Un nouvel endpoint. Un job batch. Un export. Un outil d'admin. Chacun peut lire les données sans demander les droits.
Une policy sans point d'application est une opinion.
Mes règles. Une seule porte de décision, bibliothèque ou service, et tous les chemins passent par elle. Une deuxième barrière dans la base pour les données les plus sensibles.
Et des tests qui attaquent les chemins, pas les policies. Appelle l'endpoint sans le droit. Attends un refus. Chaque route doit savoir dire non.
Défaillance n°4 : les décisions silencieuses
Dernier mode : le silence. Un refus d'accès sans trace fabrique deux problèmes.
Le support ne peut pas répondre à « pourquoi je n'ai pas accès ? ». Et l'audit ne peut pas répondre à « qui a accédé à quoi ». Sur une plateforme santé, la deuxième question n'est pas optionnelle.
Mes règles. Journaliser chaque décision, accordée ou refusée, avec les attributs évalués. Attention au contenu du journal : des identifiants et des catégories, pas de données personnelles en clair.
Et un outil de rejeu pour le support. La même question, les mêmes attributs, la décision expliquée. Le « pourquoi » doit prendre une minute, pas une journée d'archéologie.
La checklist avant de passer à l'ABAC
Les quatre modes de défaillance ne dépendent pas de l'outil choisi. La checklist non plus.
- Reste hybride : RBAC pour la base, ABAC là où la finesse paie
- Donne à chaque attribut une source de vérité, une fraîcheur max, un fail closed
- Nomme un propriétaire par policy, supprime les policies orphelines
- Écris des cas d'or de décisions, rejoués à chaque changement
- Une seule porte de décision, et tous les chemins passent par elle
- Teste les chemins sans droit : chaque endpoint doit savoir refuser
- Journalise chaque décision avec ses attributs, sans PII en clair
- Outille le « pourquoi » : le support doit pouvoir rejouer une décision
Ce qu'il faut retenir
L'ABAC tient sa promesse : des droits fins qui suivent le métier. Mais sa fiabilité ne vit pas dans les policies. Elle vit dans les attributs, les points d'application et les journaux.
Si tu pars de zéro aujourd'hui, regarde OpenFGA ou SpiceDB avant d'écrire le tien. Les quatre modes de défaillance, eux, te suivront quel que soit l'outil.
Un système d'autorisation à concevoir ou à fiabiliser ? Parlons-en.