Fiche concept

Contrôle d'accès basé sur les rôles (RBAC)

À jour au 2026-07-23

Édité par Cédric-Olivier Mâry, éditeur et directeur de la publication — 27 ans d'écosystème SAP. Comment ces pages sont produites, et où intervient l'automatisation.

Qu'est-ce que Contrôle d'accès basé sur les rôles (RBAC) ?

RBAC et DAC répondent à deux questions différentes qu'on confond sans cesse — RBAC contrôle si un utilisateur peut ouvrir un objet, DAC filtre quelles lignes de cet objet il peut voir.

De quoi il s'agit

Le RBAC (Role-Based Access Control) est le modèle d'autorisation où les permissions sont attachées à des rôles, et les rôles à des utilisateurs — jamais les permissions directement aux utilisateurs. Dans le paysage SAP, cela se joue à deux couches distinctes qu'un consultant senior ne doit jamais confondre : la couche ABAP/S-4HANA (rôles PFCG, objets d'autorisation, rôles composites) et la couche Datasphere/analytics (privilèges d'espace, rôles scopés, et Data Access Controls / DAC — companion C008).

Deux couches, deux finalités. Les rôles PFCG contrôlent ce qu'un utilisateur peut FAIRE dans l'ERP source (accès transaction, autorisations niveau organisation via des champs comme la société ou le site). Les rôles niveau-espace de Datasphere contrôlent ce qu'un utilisateur peut VOIR et CONSTRUIRE dans un espace (Viewer, Modeler, Space Administrator, plus rôles scopés custom). Le DAC filtre ensuite les LIGNES au sein d'un objet auquel l'utilisateur a déjà accès. Le RBAC répond à « cet utilisateur peut-il ouvrir cet objet »; le DAC répond à « quelles lignes de cet objet cet utilisateur peut-il voir ». Confondre les deux est l'erreur de design de gouvernance la plus fréquente dans les déploiements Datasphere.

Pourquoi le nombre de rôles explose. Un paysage SAP Tier-1 finit typiquement avec 50 à 200 rôles distincts une fois que les autorisations niveau organisation (société, site, org commerciale) sont croisées avec les scopes fonctionnels (Finance, Achats, Ventes) et les rôles niveau-espace Datasphere. La discipline de design — conventions de nommage des rôles, matrice rôle-fonction métier, et revue d'accès trimestrielle — est ce qui empêche cela de devenir une dette technique ingérable.

Pourquoi c'est important

Les rôles PFCG (accès transaction côté ERP) et les rôles d'espace Datasphere (Viewer/Modeler/Admin) sont deux couches distinctes — les confondre est l'erreur de design de gouvernance la plus fréquente dans les déploiements Datasphere.
Le nombre de rôles gonfle naturellement à 50-200 dès que les scopes organisationnels (société, site, org commerciale) se croisent avec les scopes fonctionnels et les rôles d'espace — sans discipline, on dépasse 500 et ça devient inauditable.
Accorder une exception de rôle au cas par cas plutôt que de la mapper à la matrice existante est exactement ce qui fait qu'un paysage Tier-1 finit avec des rôles qu'on ne peut plus auditer.

Points clés

RBAC = les permissions s'attachent aux rôles, les rôles s'attachent aux utilisateurs — jamais les permissions directement aux utilisateurs.
Deux couches distinctes : rôles PFCG/ABAP (accès aux objets) vs rôles space Datasphere (accès au space) — ne confondre ni l'un ni l'autre avec les DAC (accès aux lignes).
50-200 rôles est normal à l'échelle Tier-1 une fois le périmètre org-level × périmètre fonctionnel × rôle space multipliés entre eux.
La matrice des rôles (fonction métier × couche système × périmètre org) doit être validée avant le go-live, pas construite ad hoc.
Role-Based Access Control (RBAC) n'est maîtrisé que lorsqu'il change une décision d'achat identifiée.
Commencer par le contrat sémantique et le modèle de contrôle avant de démontrer l'outil.
S'appuyer sur les signaux SAP, analystes, études, Knowledge Graph et actualité actuels comme preuve, pas comme décoration.
Séparer les faits vérifiés des tendances directionnelles et des hypothèses modélisées.
Définir propriétaire, métrique, seuil, filière de support et plan de retrait avant de passer à l'échelle.
Pour les cas d'usage non-IA, définir malgré tout qualité, adoption et propriété opérationnelle.

Termes employés sur cette page

PFCG role: Transaction ABAP SAP de maintenance des rôles ; regroupe des objets d'autorisation dans un rôle, puis assigne le rôle aux utilisateurs.
Authorization object: Unité de permission de la couche ABAP combinant des champs (ex. société, division) avec des codes d'activité — l'unité atomique que les rôles PFCG regroupent.
Space role: Rôle au niveau space de Datasphere (Viewer, Modeler, Space Administrator) régulant ce qu'un utilisateur peut voir et construire dans un space.
Data Access Control (DAC): Filtre au niveau ligne appliqué une fois que le RBAC a déjà accordé l'accès à l'objet ; répond à « quelles lignes », pas « quel objet ».
Composite role: Rôle PFCG regroupant plusieurs rôles simples en un profil de poste unique, facilitant l'assignation à grande échelle.
Role matrix: Grille fonction métier × couche système × périmètre organisationnel utilisée pour concevoir les rôles avant le déploiement, non après.
Org-level authorization: Autorisation cadrée par un champ organisationnel tel que société, division ou organisation commerciale.
Access review: Audit périodique (généralement trimestriel) rapprochant les rôles accordés de la role matrix et de la fonction actuelle de chaque utilisateur.

Sources

Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code.

Ouvrir dans l'application →

Contrôle d'accès basé sur les rôles (RBAC)

Qu'est-ce que Contrôle d'accès basé sur les rôles (RBAC) ?

De quoi il s'agit

Pourquoi c'est important

Points clés

Termes employés sur cette page

Sources

Concepts liés

Modules d'académie associés

Études approfondies

Guides SAP analytics & TJM