Quand le rôle ne suffit plus : modéliser le périmètre d'accès à partir de l'organigramme

Dans une application métier, gérer les accès semble d’abord simple : un utilisateur possède un rôle, et ce rôle lui donne certaines permissions. Ce modèle fonctionne tant que les droits restent globaux.

Mais que se passe-t-il lorsque deux utilisateurs ayant le même rôle ne doivent pas accéder aux mêmes données ? Ou lorsqu’un responsable peut agir sur toute une direction, tandis qu’un autre utilisateur est limité à une équipe précise ?

C’est à ce moment que le rôle ne suffit plus. Le système doit comprendre ce que l’utilisateur peut faire, mais aussi où il peut le faire.

C’est précisément la problématique rencontrée lors de l’évolution d’une application métier récente. Nous avons donc repensé le modèle d’habilitation autour d’un principe simple : utiliser l’organisation réelle de l’entreprise comme base du périmètre d’accès.

1. Du rôle au périmètre : la limite d’un RBAC classique

Le RBAC (Role-Based Access Control) associe des permissions aux rôles et répond à « que peut-il faire ? ». Pourtant, UPDATE_DOSSIER ne précise pas quels dossiers sont modifiables. Deux responsables partagent cette permission : l’un relève de la Direction Import, l’autre de la Direction Finance. Leur accorder un accès global ignorerait leur responsabilité opérationnelle.

Créer des rôles « Responsable Import », « Responsable Finance », puis leurs déclinaisons par département semble tentant. Cette stratégie couple droits et organigramme : chaque réorganisation entraîne de nouvelles attributions et des risques d’incohérence. Les règles deviennent difficiles à expliquer et à tester.

Le modèle retenu dissocie trois éléments : le rôle, qui regroupe des responsabilités ; la permission, qui nomme l’action ; et le périmètre, qui délimite les ressources concernées. La décision devient contextuelle : une opération n’est autorisée que si l’utilisateur possède la permission ET si la ressource appartient au périmètre applicable. Le principe de moindre privilège se traduit ainsi dans le modèle métier, sans confondre authentification et autorisation.

2. L’organigramme comme source du périmètre d’accès

L’organisation est représentée par des nœuds : entreprise, direction, département ou équipe. Chaque nœud possède un identifiant et, sauf la racine, un parent. Cet arbre accepte des profondeurs variables sans modifier le schéma ni multiplier les rôles.

Le rattachement d’un utilisateur à un nœud définit son point de départ. Le périmètre considéré inclut ce nœud et ses descendants. Ainsi, un responsable Import peut disposer de droits sur les dossiers de ses départements ; un responsable Finance n’obtient pas ce périmètre en partageant la même permission.

Figure 1 — Un même droit peut s’exercer sur des sous-arbres organisationnels distincts.

La formule reste volontairement simple : les permissions répondent à « que peut-il faire ? » ; l’organigramme répond à « où peut-il le faire ? ». Cette séparation facilite aussi l’administration : déplacer une équipe modifie son appartenance hiérarchique plutôt que la définition des permissions. Elle suppose, en contrepartie, que chaque ressource protégée soit reliée de manière fiable à son nœud organisationnel.

3. Traduire la hiérarchie en décisions d’accès

3.1. Parent-enfant, CTE récursives et Closure Table

OrgNode(id, nom, parent_id) suffit pour conserver la hiérarchie. Pour vérifier qu’un dossier de l’Équipe A1 appartient à la Direction Import, une CTE récursive remonte les parents ou explore les descendants. Cette option reste adaptée aux parcours peu fréquents ou aux structures très évolutives.

Dans une application de gestion de la supply chain, nous avons privilégié une Closure Table afin de rendre explicites les relations ancêtre-descendant. Une ligne associe un ancêtre, un descendant et une profondeur ; on peut également enregistrer la relation d’un nœud avec lui-même, de profondeur zéro. La recherche d’appartenance devient une vérification de relation plutôt qu’une reconstruction de chemin à chaque contrôle. À l’échelle actuelle (35 nœuds et 5 niveaux), une CTE récursive aurait aussi convenu : le choix vise surtout la simplicité des contrôles répétés et des listes de dossiers filtrées, sans prétendre à un gain de latence mesuré.

Ancêtre	Descendant	Profondeur
Direction Import	Département A	1
Direction Import	Équipe A1	2
Département A	Équipe A1	1
Équipe A1	Équipe A1	0

Tableau 1 — Exemple simplifié de relations conservées dans la Closure Table.

Les deux tables sont complémentaires : parent_id exprime la structure métier ; la Closure Table matérialise ses chemins pour les consultations hiérarchiques répétées. Les index sur les couples (ancêtre, descendant) sont essentiels, tout comme les tests de non-régression sur les créations, rattachements et suppressions de nœuds.

3.2. Une optimisation qui a aussi un coût

La Closure Table a un coût. Le nombre de lignes croît avec les nœuds et la profondeur ; une arborescence profonde peut devenir volumineuse. Chaque insertion ajoute des liens, tandis que déplacer un sous-arbre exige de recalculer les relations concernées. Pour éviter une divergence entre parent_id et la table des chemins, les mises à jour doivent être atomiques et contrôlées. Un cache de périmètres exige également une invalidation lors des réorganisations ou des changements de droits. Cette structure est justifiée lorsque les consultations hiérarchiques répétées compensent ces écritures plus coûteuses.

3.3. Contrôler au moment d’accéder à la ressource

Côté application, le contrôle ne doit pas s’arrêter à l’affichage d’un bouton ou à la présence d’un rôle dans un jeton. Le backend doit identifier l’action demandée, vérifier la permission effective, retrouver le nœud de la ressource et tester son appartenance au périmètre autorisé. Si l’une des deux conditions échoue, ou si une information nécessaire manque, l’accès doit être refusé par défaut. Cette même règle doit protéger aussi bien la lecture des listes filtrées que l’accès direct à un dossier par son identifiant.

Figure 2 — Décision d’autorisation : permission effective et appartenance organisationnelle.

4. Pourquoi un moteur intégré plutôt qu’un service dédié ?

Avant de choisir un moteur maison, il faut comparer les alternatives. OpenFGA et SpiceDB modélisent des relations entre sujets et ressources (ReBAC) ; Cedar et OPA expriment des politiques ; Keycloak et Okta proposent des capacités d’autorisation. Tous exigent des données métier fiables pour déterminer le périmètre d’une ressource.

Approche	Atout principal	Arbitrage pour une application de supply chain
Moteur intégré	Nœuds et dossiers proches du métier	Simplicité du modèle ; tests, sécurité et évolution à maintenir.
OpenFGA (ReBAC)	Relations d’accès fines et API dédiée	Gérer et synchroniser un référentiel de relations.
SpiceDB (ReBAC)	Graphe de permissions et vérifications dédiées	Modèle et exploitation supplémentaires pour un besoin arborescent.
Cedar / OPA	Politiques expressives, séparables du code	Fournir les attributs et relations métier à chaque décision.
Keycloak	Permissions, ressources et politiques centralisées	Adapter ses services d’autorisation au périmètre métier.
Okta	Identités, scopes et politiques d’accès aux API	Conserver le contrôle des dossiers métier dans l’application.

Tableau 2 — Six options examinées à travers le besoin précis d’une hiérarchie métier.

Pour cette application de supply chain, un moteur intégré rapprochait nœuds, dossiers et règles de portée du modèle existant, sans second référentiel pour une logique essentiellement arborescente. Ce compromis ne signifie ni que les outils spécialisés seraient moins performants, ni qu’une solution interne serait toujours moins coûteuse.

La décision doit être réévaluée si plusieurs applications partagent les mêmes politiques, si les relations deviennent un graphe complexe, ou si l’audit et la gouvernance exigent un moteur centralisé. Le « build » impose lui aussi une responsabilité durable : tests d’autorisation, traçabilité, revue de sécurité et maintenance des règles.

5. Le cas en chiffres

Deux indicateurs décrivent la structure organisationnelle actuellement modélisée : 35 nœuds et une profondeur de 5 niveaux. Il s’agit de caractéristiques du référentiel d’organisation, et non d’un benchmark du contrôle d’habilitation ou d’un endpoint complet.

Indicateur	Valeur
Nœuds organisationnels	35 nœuds
Profondeur actuelle	5 niveaux

Tableau 3 — Volumétrie de l’organigramme modélisé.

Les 35 nœuds représentent la volumétrie actuelle, et non une limite de capacité. Les 5 niveaux décrivent la profondeur de l’organigramme en place ; ils servent à contextualiser le stockage et les mises à jour de la Closure Table. Aucun résultat de performance n’est avancé sans protocole de mesure vérifiable.

L’enseignement principal est architectural : séparer le droit d’agir de l’étendue sur laquelle il s’applique rend les règles plus lisibles. La Closure Table constitue une réponse possible au coût des contrôles hiérarchiques répétés, mais elle exige une discipline sur les mises à jour. Et le choix d’un moteur interne doit rester proportionné à la complexité effective du besoin.

Conclusion — Faire refléter le métier dans la sécurité

Un système d’habilitation robuste ne se résume pas à une liste de rôles. Dès lors que les décisions dépendent d’une structure métier, l’organigramme devient une composante explicite de l’autorisation. Dans cette application de supply chain, ce principe a guidé un modèle associant permissions fines et périmètres hiérarchiques, avec une Closure Table pour interroger ces relations.

Pour le versant expérience utilisateur de ce même module, lire l’article de Mohamed Staili : « Comment offrir une expérience utilisateur fluide pour un système supposé complexe ».

Chez We Are Beebay, nous privilégions ce type de démarche : partir d’une contrainte opérationnelle, exposer les arbitrages et construire une solution maintenable. Vous cherchez à maîtriser des droits d’accès devenus difficiles à faire évoluer ? Échangeons sur la manière d’aligner vos habilitations avec votre organisation métier.