Un rôle métier à la place de PFCG, des catalogues à la place des rôles techniques, et deux grandes releases par an capables de bouleverser tout le modèle d’autorisations. Voilà comment fonctionne l’autorisation dans SAP Public Cloud — et c’est le sujet du nouvel épisode de GRC Ninja.

Dans l’épisode précédent, nous demandions ce qu’est SAP Public Cloud, à qui il convient et quelles sont ses limites. Cette fois, nous descendons d’un niveau. Rafał, consultant ayant accompagné plusieurs de ces implémentations, fait la démonstration sur un système réel. Il montre de quoi se compose un rôle métier, ce que voit l’utilisateur dans le Launchpad et pourquoi le modèle d’autorisations doit être revu tous les six mois. Voici l’essentiel de cette conversation.

PFCG, c’est fini. Le rôle métier prend le devant de la scène

Public Cloud aborde l’autorisation d’une manière totalement différente des systèmes on-premise et private cloud. Les rôles métier ont remplacé les rôles techniques classiques construits dans PFCG. Chaque rôle se compose de catalogues métier, eux-mêmes constitués d’applications Fiori. Les Spaces and Pages définissent leur présentation — ce sont les espaces et pages de navigation du Launchpad. Restent les restrictions, qui limitent l’accès aux données à l’intérieur même des applications.

Logique ? Sur le papier, oui. En pratique, ce modèle surprend même les consultants expérimentés, car un rôle ne se limite pas à l’accès : c’est toute la disposition des applications dans l’interface. Vous pouvez attribuer toutes les autorisations, mais sans Spaces and Pages assignés, l’utilisateur se connecte et trouve un écran vide. En on-premise, cela ne passerait jamais. Ici, c’est la norme.

De quoi se compose un rôle dans Maintain Business Roles ?

La gestion des rôles se fait dans l’application Maintain Business Roles — un référentiel où l’on crée et modifie les rôles. Chaque rôle comprend quelques éléments :

• Données de base — la description du rôle et les catégories d’accès, c’est-à-dire si le rôle permet de modifier les données ou seulement de les afficher. On y voit aussi la catégorie tarifaire du rôle.
• Business Catalogs — les catalogues métier qui donnent aux utilisateurs l’accès aux différentes applications. Chaque catalogue peut être ouvert et examiné en détail.
• IAM Apps — toutes les applications affectées via les catalogues. De là, on peut aussi restreindre l’accès à certaines d’entre elles.
• Launchpad Spaces — les espaces de navigation qui aident chacun à retrouver les applications dont il a besoin.
• Restrictions — des filtres de données au sein des applications, par exemple au niveau de la société (company code), de la division ou du groupe d’autorisations.

L’ensemble est très visuel. Et c’est justement pour cela qu’il exige de la discipline à la conception : chaque pièce du puzzle doit trouver sa place, sinon quelqu’un perd un morceau de son écran.

Deux releases par an. Qui décide des changements ?

Un environnement on-premise fonctionnait des années, jusqu’à ce que vous décidiez vous-même de le mettre à niveau. Dans Public Cloud, c’est SAP qui décide : de façon centralisée, deux fois par an. Une major release apporte des changements fonctionnels, de nouvelles applications Fiori, parfois aussi des ajustements dans les catalogues ou les restrictions. Et tout cela touche directement les autorisations.

Prenons le rôle d’un comptable. Après une nouvelle release, SAP peut ajouter des applications au catalogue Accounts Payable, renommer ou reclasser une application existante, retirer des fonctions jusque-là disponibles ou introduire un nouveau champ dans les restrictions. Le comptable voit soudain une nouvelle tuile et peut exécuter une opération à laquelle il n’avait pas droit. Ou l’inverse : il perd l’accès à un rapport qu’il utilisait depuis des mois.

Ce ne sont pas des scénarios théoriques. Dans un projet, SAP a changé son approche des valeurs requises dans les restrictions, et personne ne l’a corrigé à temps. Les rapports financiers semblaient corrects, mais n’affichaient qu’une partie des données. Dans une autre release, un catalogue métier a disparu et l’administrateur n’a jamais rattaché son successeur.

Peut-on garder le contrôle ? Oui — les outils existent. La fonction Manage Changes After Upgrade de Maintain Business Roles liste les changements qui touchent un rôle donné, par exemple les catalogues retirés et remplacés par de nouveaux. Le What’s New Viewer décrit les changements en langage métier, souvent avec leur impact sur les autorisations et des consignes de correction des rôles. Chaque release s’accompagne aussi d’une note qui rassemble toutes les modifications d’autorisations : rôles, catalogues, restrictions et objets liés. Le problème ? Presque personne ne la lit.

Quatre erreurs qui reviennent dans les projets

1. Des rôles trop larges

Un classique. Pendant les tests, les utilisateurs reçoivent un accès large « pour que ça marche », puis tout reste en l’état. Résultat : des accès à des fonctions dont personne n’a besoin et plus d’occasions d’erreurs. Les coûts de licences grimpent aussi, car certaines applications font passer l’utilisateur dans une catégorie tarifaire supérieure. Dans le pire des cas, un audit révèle des conflits de séparation des tâches passés inaperçus, et la question de la fraude arrive sur la table.

2. Pas de Spaces and Pages

Les utilisateurs se connectent, voient un écran vide et signalent que le système ne fonctionne pas. Les rôles sont formellement attribués, alors l’équipe IT fouille les logs à la recherche d’un bug technique. Or il manque simplement le menu. Rafał a vu des projets où les tests ont démarré avec une semaine de retard à cause de cela.

3. Pas de revue des restrictions après les releases

Une bombe à retardement silencieuse. Après une mise à jour, SAP peut modifier des restrictions ou ajouter de nouveaux champs, et une partie des données disparaît des rapports. Un utilisateur ne voit plus les documents d’une autre société, parce que le champ company code a reçu une nouvelle valeur. Parfois, cela ne se remarque qu’au bout d’une semaine, quand quelqu’un constate qu’il manque des factures. Impossible d’ignorer les releases dans le cloud : la revue des rôles après chaque mise à jour doit être un processus permanent, pas une opération de sauvetage.

4. Pas de contrôle SoD

En on-premise, des systèmes de classe GRC surveillaient les conflits d’autorisations. Dans Public Cloud, on l’oublie souvent : le système est standard, donc les risques semblent moindres. Faux. Vous pouvez toujours avoir un utilisateur qui crée des fournisseurs et approuve des paiements — sauf que sans base de règles à jour pour les applications Fiori, aucun outil ne le montrera. Les auditeurs s’en donnent alors à cœur joie : tout fonctionne, mais personne ne peut prouver que tout fonctionne selon les règles.

Maintenir les autorisations : un processus, pas un projet

Chacune de ces erreurs a des conséquences réelles : frustration des utilisateurs, erreurs dans les données, risques d’audit et risques financiers. Dans le cloud, la règle « construire une fois et oublier » ne fonctionne plus. L’équipe autorisations travaille un peu comme une équipe sécurité — elle suit les releases et réagit à ce qu’elles apportent. Tous les six mois, SAP redistribue les cartes. Les gagnants sont les organisations qui ont fixé un standard dès le début du projet et qui s’y tiennent.

Voyez-le en direct dans le système

Cet article s’appuie sur un épisode de la chaîne GRC Ninja consacré au modèle d’autorisations de SAP Public Cloud. La vidéo propose une démo complète : à quoi ressemble un rôle métier dans l’application Maintain Business Roles et comment fonctionne Manage Changes After Upgrade. Vous verrez aussi quoi vérifier avant chaque release — avant qu’un auditeur ne le fasse à votre place. Le tout dure un peu moins de 11 minutes, le temps d’un café. Regardez l’épisode sur la chaîne GRC Ninja et partagez votre propre liste d’erreurs en commentaire. Vous en avez peut-être une que nous n’avons pas citée ?