Rôles et autorisations SAP : le guide PFCG, SU01, SU53

Un utilisateur SAP appuie sur Entrée et tombe sur le message « Vous n’avez pas l’autorisation pour la transaction MM03 ». Trois personnes interviennent dans la minute qui suit : l’utilisateur qui rage, l’admin SAP qui doit comprendre pourquoi, et le chef de projet qui rappelle qu’on est en go-live dans deux jours. La même scène se rejoue dans chaque entreprise SAP, chaque semaine. Et à chaque fois, la solution tient en trois transactions : PFCG, SU01, SU53.

Cet article remet à plat les concepts du système d’autorisations SAP pour un key user ou un consultant junior qui doit savoir lire un rôle, comprendre pourquoi un utilisateur est bloqué, et soit le déboquer lui-même soit transmettre une demande propre à l’équipe Basis. Pas d’angle Basis pur ni de Sécurité avancée, on reste sur le terrain métier.

C’est quoi un rôle SAP ? (et pourquoi ton key user en a besoin)

Un rôle SAP est l’objet qui détermine ce qu’un utilisateur a le droit de faire dans le système. Il combine deux choses : un menu (les transactions accessibles) et un ensemble d’objets d’autorisation avec leurs valeurs (les actions précises autorisées sur chaque transaction).

L’image qui marche bien : pense à un rôle comme à un badge d’accès dans une usine. Le menu = la liste des portes que tu peux ouvrir. Les objets d’autorisation = les conditions précises (par exemple : porte du magasin oui, mais seulement aux heures ouvrées, et seulement sur le site de Luxembourg). Sans badge, tu ne passes pas la première porte. Avec un badge mal configuré, tu peux entrer mais tu ne peux rien faire dedans. Le but du jeu c’est de calibrer chaque badge au métier exact de la personne.

Côté technique, le rôle est stocké dans la table AGR_DEFINE et lié à une série d’objets d’autorisation via AGR_1251. Le concept date de SAP R/3 et reste central en S/4HANA, sans coupure de paradigme. La documentation SAP Learning sur le concept d’autorisation S/4HANA couvre la théorie complète.

L’anatomie d’un rôle SAP en cascade

Le système d’autorisations SAP empile cinq niveaux. Ce schéma montre comment l’utilisateur final, en bas, hérite de tout ce qui est paramétré au-dessus :

Rôle simple, composite et dérivé : quand utiliser quoi

Trois types de rôles coexistent dans SAP, et la confusion entre eux fait perdre du temps sur tous les projets autorisations. Le rôle simple est l’unité de travail : il porte un menu + des objets d’autorisation cohérents pour une fonction métier précise. Le rôle composite est un agrégateur : il regroupe plusieurs rôles simples mais ne porte aucune autorisation en propre. Le rôle dérivé hérite des autorisations d’un rôle parent tout en permettant des restrictions organisationnelles (BUKRS, WERKS, VKORG) propres à chaque entité juridique : indispensable dans les déploiements multi-sociétés.

En production, on combine souvent les trois : un rôle parent métier (par exemple Acheteur), plusieurs rôles dérivés organisationnels (Acheteur FR, Acheteur DE, Acheteur LU) qui restreignent le périmètre par entité, regroupés ensuite dans un composite par fonction utilisateur. Sur un projet où la maintenance préventive multi-sites doit segmenter qui fait quoi par usine, le dérivé évite de dupliquer 15 fois le même rôle PM. Voir l’illustration concrète dans les rôles métier en maintenance préventive.

PFCG, SU01, SU53 : les 3 transactions à connaître

Trois transactions couvrent la grande majorité des opérations courantes sur les rôles et autorisations SAP. Chacune a un rôle précis dans le workflow et un public cible distinct :

Pour aller plus loin sur les options de paramétrage et les tables sous-jacentes, la documentation help.sap.com filtrée sur “User and Role Maintenance” couvre la mécanique complète de PFCG.

Si tu travailles sur des transactions custom, la création de variants via SHD0 est complémentaire à la gestion des autorisations : limiter l’accès via PFCG d’un côté, simplifier l’écran de l’utilisateur via SHD0 de l’autre.

Workflow type : créer un rôle métier de A à Z

Le pas-à-pas pour créer un rôle simple SAP, depuis l’interview du key user jusqu’au compte de recette. Sept étapes que tu retrouveras sur tous les projets autorisations :

1. 1
   Lister les transactions du métier

   Interview du key user ou observation terrain. Note chaque transaction effectivement utilisée (par exemple MM03, MIGO, MB52). Évite les listes théoriques type “il faut tout MM” : tu finiras avec un rôle qui donne accès à 50 transactions dont 5 servent vraiment.

2. 2
   Créer le rôle dans PFCG (avec copie SAP standard si possible)

   Lance PFCG, saisis un nom en namespace Z (par exemple Z_MAGASINIER_SAP), choisis “Single Role”. Si un rôle SAP standard couvre déjà la majeure partie du besoin, copie-le et adapte plutôt que de partir de zéro.

3. 3
   Compléter le menu (onglet Menu)

   Ajoute les transactions de l’étape 1 dans l’onglet Menu. Tu peux organiser en arborescence (Menu > Production > Validation OF) pour que l’utilisateur s’y retrouve. Le menu détermine ce que l’utilisateur voit dans son SAP Easy Access.

4. 4
   Adapter les valeurs d’autorisation (onglet Authorizations)

   Clique sur “Change Authorization Data”. SAP propose des objets d’autorisation par défaut basés sur SU24. Adapte chaque valeur étoile (*) à la valeur métier réelle (par exemple BUKRS = 1000 pour la société Luxembourg uniquement). Le code couleur SAP : feu rouge = à compléter obligatoire, feu jaune = optionnel mais conseillé, feu vert = OK.

5. 5
   Générer le profil (cadenas)

   Clique sur l’icône cadenas en haut. SAP génère un profil d’autorisation à partir des valeurs saisies. Le profil porte un nom auto type T-XXXXX et c’est lui qui sera réellement chargé en mémoire à la connexion utilisateur.

6. 6
   Affecter le rôle à un utilisateur (ou à plusieurs via SU10)

   Soit via l’onglet User de PFCG (rapide, pour un seul utilisateur), soit via SU01 (workflow standard helpdesk). Pour un mass-assignment lors d’une réorganisation ou d’une migration, utilise SU10 : il permet d’assigner ou retirer un rôle à plusieurs utilisateurs en une seule opération, ce que SU01 ne sait pas faire. Pense à fixer une date de validité, surtout pour les comptes intérimaires ou stagiaires.

7. 7
   Tester avec un compte de recette

   Connecte-toi avec le compte test affecté au rôle, fais le parcours métier complet. Si une transaction du menu déclenche un message d’autorisation manquante, lance SU53 immédiatement après et corrige dans PFCG. Itère jusqu’à ce que le parcours métier passe sans blocage.

Les 4 pièges qui font échouer la plupart des projets autorisations

Quatre situations reviennent sur tous les projets et plombent la qualité du système d’autorisations à long terme :

1. SAP_ALL en dev oublié en prod

Le profil SAP_ALL donne tous les droits sur toutes les transactions. C’est utile en développement pour ne pas être bloqué pendant le paramétrage. Le piège : il finit affecté à un utilisateur en production parce que “on testait, on nettoie après”, et personne ne nettoie. Conséquence : un utilisateur métier a tous les droits SAP, y compris la possibilité de modifier les paramètres financiers ou de supprimer des données. Audit failure garanti. La règle terrain : SAP_ALL en prod, c’est jamais, même temporairement.

2. Profil non régénéré après modif

Tu modifies un rôle dans PFCG, tu sauves, tu affectes à un utilisateur, et l’utilisateur n’a toujours pas l’accès. Cause : le profil n’a pas été régénéré (cadenas). Le rôle stocke les valeurs en base, mais c’est le profil qui est chargé à la connexion. Sans régénération, les modifs ne sont pas effectives. Symptôme : SU53 de l’utilisateur affiche un message d’autorisation manquante alors que le rôle a l’air bon dans PFCG.

3. Valeurs étoile (*) partout

Quand un consultant ne sait pas quelle valeur mettre sur un champ d’autorisation, la tentation est de mettre * (toutes valeurs). Multiplier les étoiles transforme le rôle en pseudo-SAP_ALL sur le périmètre concerné. Sur 50 utilisateurs avec ce rôle, ça veut dire que tous peuvent tout faire sur ce périmètre. Audit failure.

4. Conflits de séparation des tâches (SoD)

La séparation des tâches (Segregation of Duties) interdit qu’un même utilisateur cumule deux fonctions incompatibles : créer un fournisseur et valider une facture, créer un article et passer une commande d’achat, valider un OF et le réceptionner. Le risque c’est la fraude ou l’erreur non détectée. Sur les projets matures, un audit SoD est lancé chaque année avec des outils dédiés (SAP GRC ou équivalents tiers). Sur les projets jeunes, c’est souvent oublié et découvert tard.

Comment diagnostiquer une erreur d’autorisation en 3 étapes

Quand un utilisateur appelle en disant « SAP me dit que je n’ai pas l’autorisation », voici la procédure terrain qui résout la plupart des cas en moins de 10 minutes :

1. 1
   SU53 immédiatement après l’erreur

   Demande à l’utilisateur de lancer /n SU53 dans la commande de transaction juste après avoir vu le message d’erreur. Surtout pas plus tard, le buffer mémoire est volatile. SU53 affiche l’objet d’autorisation manquant et la valeur attendue, en clair.

2. 2
   SUIM pour identifier qui a déjà l’objet

   Si tu veux savoir qui dans l’organisation a déjà cet objet d’autorisation avec la bonne valeur, lance SUIM > Users by complex sélection criteria. Tu trouves rapidement un utilisateur de référence dont tu peux copier le rôle.

3. 3
   ST01 pour les cas avancés

   Quand SU53 ne dit rien (ou dit des choses incohérentes) et que tu suspectes un check d’autorisation custom dans un Z program, lance ST01 en mode trace authorization. Active la trace, fais répéter le parcours utilisateur, désactive la trace, lis le résultat. Niveau intermédiaire-avancé : pas pour le helpdesk N1.

Ce qu’il faut faire face à une erreur d’autorisation

Quand un utilisateur rencontre une erreur d’autorisation, deux réflexes sont contre-productifs : ouvrir le code en debug pour voir « pourquoi ça bloque », ou demander temporairement SAP_ALL. Les deux exposent l’organisation à des risques SOX, GDPR et ISO 27001, et laissent une trace systématiquement remontée par tout audit interne ou externe.

La méthode standard côté équipe Basis tient en quatre étapes :

1. 1
   Reproduire l’erreur côté utilisateur

   Note la transaction lancée et le code retour exact affiché dans la status bar SAP GUI. Sans reproduction propre, le diagnostic SU53 sera vide ou pollué par un check antérieur.

2. 2
   Tracer l’objet d’autorisation manquant via SU53

   Lance SU53 immédiatement après l’erreur. Tu obtiens le dernier check qui a échoué, avec l’objet (par exemple M_BEST_BSA), le champ et la valeur attendue. C’est la base factuelle de toute la suite.

3. 3
   Identifier le rôle responsable via SUIM

   Ouvre SUIM > Rôles > avec valeurs d’autorisation et filtre sur l’objet remonté par SU53. Cela donne le ou les rôles candidats à amender. Si l’objet d’autorisation touche un système de classification SAP, la liste peut être large : filtre aussi sur l’utilisateur pour cibler.

4. 4
   Décider de l’amendement avec l’équipe métier

   Faut-il vraiment ajouter cette autorisation à ce rôle, et donc à toutes les personnes qui l’ont ? Ou créer un dérivé pour ne l’ouvrir qu’à un sous-périmètre ? La réponse détermine si on patch le rôle existant via PFCG, ou si on en crée un nouveau.

Le debug du code applicatif pour faire « passer » un check d’autorisation n’est jamais une réponse appropriée en production : ça contourne la séparation des tâches, masque le besoin réel, et laisse une trace dans les transports et les logs.

Le système d’autorisations SAP est l’un de ces sujets qu’on apprend tôt et qu’on continue à découvrir pendant 10 ans. Les concepts de base (rôle simple, rôle composite, profil, objet d’autorisation, valeurs) suffisent au quotidien. Les pièges (SAP_ALL, profil non régénéré, étoiles, SoD) suffisent à reconnaître un projet qui dérape avant qu’il soit trop tard. Et les trois transactions PFCG, SU01, SU53 couvrent l’essentiel des opérations courantes. Pour aller plus loin sur la création concrète des rôles, la documentation SAP officielle FR sur la création des rôles d’autorisation détaille les options par contexte.

Questions fréquentes

À lire ensuite

01

Tutos SAP

Synchronisation des données entre SAP ERP et EWM : embedded, décentralisé et le rôle du CIF, ALE et DRF

Synchronisation des données entre SAP ERP et EWM : partage en embedded, transfert CIF/ALE/DRF en décentralisé, et ce qui se crée à la main vs en background.

Michael A. 9 min de lecture

02

Tutos SAP

Numéro de série SAP : guide de décision OIS2, 6 procédures et arbitrage matériel vs équipement PM

Quand activer la sérialisation SAP, comment paramétrer le profil OIS2, choisir parmi les 6 serializing procedures et arbitrer entre numéro de série matériel et équipement PM.

Pierre B. 17 min de lecture

03

Tutos SAP

SAP PRT (Production Resources/Tools) : guide des outillages réutilisables

Comprendre les PRT dans SAP : les 4 catégories (Material, Miscellaneous, Document, Equipment), la création MM01, l’assignation gamme et le contrôle de disponibilité, expliqués pas à pas.

Pierre B. 14 min de lecture

04

Tutos SAP

SAP WM 2-step picking : configurer la cascade pick / allocation pour les entrepôts à fort volume

SAP WM 2 Step Picking : cascade picking-allocation, configuration SPRO 3 niveaux, cas concret end-to-end, pièges hypercare et migration EWM.

Michael A. 17 min de lecture