Séparation des tâches en 2026 :
SAP S/4HANA, agents IA et l'avenir de la gestion des accès

1.1 Le principe fondamental

La séparation des tâches consiste à répartir les étapes critiques des processus métier entre au moins deux personnes différentes, de sorte qu'aucune personne ne puisse à la fois initier et finaliser une transaction qui entraîne une perte d'argent, de données ou d'actifs. L'objectif est simple : si aucun être humain seul ne contrôle l'intégralité du cycle, la fraude ou l'erreur devient considérablement plus difficile à commettre sans détection.

Une bonne illustration est le processus d'achat. La personne qui crée une demande d'achat ne devrait pas être la même personne qui l'approuve, reçoit la marchandise, comptabilise la facture fournisseur et exécute le paiement. Chacune de ces étapes représente un point de décision. En répartissant ces décisions entre différentes personnes, l'organisation crée des contrôles et équilibres naturels. Le détournement nécessiterait au moins deux personnes en collusion, ce qui augmente significativement le coût et le risque de la fraude.

Lorsqu'un seul employé contrôle l'intégralité du cycle d'achat et entretient une relation étroite avec un fournisseur, les conditions de fraude sont réunies. Le fournisseur a toutes les incitations à entretenir cette relation - par des bonus, des cadeaux de Noël, des voyages, des invitations à des événements sportifs ou de l'argent liquide. Du point de vue du fournisseur, conserver cet employé comme allié interne facilite tout : gagner des contrats sans véritable concurrence, facturer à des prix gonflés, facturer pour des biens ou services non livrés - et tout maintenir non détecté tant que l'employé contrôle le processus.

Les données de l'ACFE Occupational Fraud 2024: A Report to the Nations, basées sur 1 921 cas réels de fraude dans 138 pays, confirment à quel point la fonction d'achat est exposée. Selon le rapport, les systèmes de facturation restent l'un des types les plus courants de fraude dans les dépenses avec une perte médiane de 100 000 USD par cas ; la corruption, y compris les pots-de-vin et commissions occultes des fournisseurs, est mentionnée dans 48% de tous les cas, et la perte médiane due à la fraude aux achats est de 200 000 USD - parmi les plus élevées de toutes les catégories.

Dans les systèmes ERP modernes de pointe comme SAP S/4HANA, la SoD est appliquée via le modèle d'autorisation et contrôle quelles transactions, applications et objets de données maîtres un utilisateur peut accéder. Un modèle bien conçu attribue des rôles en fonction de la fonction de travail et intègre des contraintes empêchant une personne de détenir une combinaison d'autorisations créant un conflit SoD. Cette architecture de contrôle technique est évidemment le fondement.

Le défi pratique est que les organisations partent rarement de zéro. La plupart des environnements SAP ont été configurés il y a des années, les rôles ont été conçus davantage pour la fonctionnalité que pour le contrôle, et le paysage d'accès a grandi organiquement avec de nouveaux utilisateurs, intégrations et cas d'usage métier. Au fil du temps, les rôles accumulent des autorisations pour lesquelles ils n'étaient jamais prévus, et les responsabilités migrent entre les départements de manière qui n'était pas prise en compte dans la conception originale des rôles.

Le résultat est un système où la SoD théorique existe dans les documents de politique, mais l'accès réel raconte une histoire très différente. Et ce défi s'accélère en 2026. Chaque activation d'app Fiori, chaque nouvelle variable de configuration spécifique au pays, chaque itération de S/4HANA crée de nouvelles combinaisons de conflits potentielles. Les organisations qui s'appuient exclusivement sur des matrices SoD statiques basées sur les conceptions ECC originales gèrent en réalité les risques d'il y a six ans. La meilleure pratique est ailleurs.

1.2 Pourquoi les programmes SoD échouent en pratique

1. Accès façonné par l'urgence, pas par la conception. Sous la pression du go-live, la priorité passe de faire les choses correctement au lancement. Les utilisateurs obtiennent l'accès en fonction de ce dont ils ont besoin pour se débloquer, et les autorisations sont approuvées rapidement pour maintenir l'élan. Ce qui devait être temporaire devient permanent. Un modèle d'autorisation compromis devient une dérive institutionnalisée, et personne n'a le temps de nettoyer.

Mais sous l'urgence se cache un problème plus profond. Même quand le temps et la bonne intention sont présents, personne ne peut clairement répondre à quel accès est requis pour un rôle donné. Les descriptions de poste RH fonctionnent à un niveau trop élevé. Les spécialistes fonctionnels décrivent ce dont les gens ont besoin en termes de processus, pas en termes d'objets d'autorisation. Les équipes IT doivent traduire entre ces deux mondes, souvent sans réponses claires de l'un ou l'autre côté. Le résultat est que l'accès est attribué sur la base de conjectures.

En quelques semaines, ces conjectures deviennent la nouvelle référence. Quand une nouvelle personne rejoint la même équipe, elle est provisionnée pour correspondre à son prédécesseur, héritant d'un accès qui n'était jamais correct dès le départ, plus toutes les autorisations supplémentaires accumulées entre-temps. Ce qui a commencé comme un contournement temporaire devient le modèle de rôle permanent.

2. Onboarding par copier-coller ou make-like. Quand un nouvel utilisateur rejoint, le chemin de moindre résistance est de trouver quelqu'un dans la même équipe et de copier ses rôles. Cela prend quelques minutes, le nouvel utilisateur est immédiatement productif, et le manager est content. Mais le compte source a également hérité de son accès par la même méthode, probablement il y a de nombreuses itérations.

Le compte source est rarement examiné avant d'être cloné. Mais même si quelqu'un voulait l'examiner, il se heurterait rapidement au même problème décrit au point 1. Personne ne sait avec certitude quelles autorisations un poste donné devrait avoir. Ainsi, la copie se poursuit, et chaque génération ajoute sa propre couche.

Au fil du temps, le problème s'aggrave silencieusement. Le profil d'accès du département dérive plus loin de toute conception prévue à chaque embauche, mais parce que chaque étape individuelle semble raisonnable, personne ne lève le drapeau. Le compromis des rôles ne se manifeste pas comme un problème distinct - il se manifeste comme un bruit accumulé dans la matrice SoD et des observations d'audit répétitives qui deviennent plus difficiles à expliquer chaque année.

Au moment où un audit ou un examen de sécurité met le problème en lumière, il est presque impossible de retracer ce qui a mal tourné. Les comptes de référence d'origine peuvent ne plus exister. Les personnes qui ont pris les décisions de provisioning peuvent ne plus être dans l'entreprise. La logique métier qui justifiait jadis ces attributions est perdue depuis longtemps.

3. Le framework de risques SoD que personne ne possède. La plupart des organisations traitent la matrice de risques SoD comme un livrable technique - quelque chose que l'équipe sécurité ou les consultants externes créent pendant le processus d'implémentation, obtiennent des signatures formelles, puis archivent sur un lecteur partagé jusqu'au moment de l'audit. Cette approche méconnaît fondamentalement ce que la matrice devrait être.

La matrice n'est pas seulement une liste de codes de transaction conflictuels. C'est la réponse à une série de questions métier sur lesquelles quelqu'un doit s'asseoir et réfléchir en profondeur. Que se passerait-il si la même personne pouvait créer un fournisseur et le valider ? Que se passerait-il si elle contrôlait à la fois la saisie de commande et la réception de marchandises ? Ces scénarios n'ont pas de réponses univoques - ils dépendent du profil de risque de l'entreprise, du secteur, des réglementations et de la tolérance au risque de l'organisation.

Quand cette conversation se passe bien, elle fait plus que produire un document. Elle change la manière dont les business owners pensent à l'accès. Ils cessent de voir les autorisations système comme une affaire technique pour l'IT et commencent à les voir comme un reflet de la manière dont l'entreprise opère. Ce changement de mentalité transforme la SoD d'une tâche de compliance en partie vivante de la gestion des processus métier.

En pratique, cette conversation a rarement lieu à la profondeur où elle devrait. Ce que la plupart des projets font à la place est de prendre un jeu de règles de référence d'une implémentation précédente, d'un modèle SAP standard ou parfois d'une bibliothèque de règles d'outil GRC, d'ajuster quelques éléments et de l'appeler terminé. Le travail technique est fait, mais le travail métier sous-jacent - mapper comment cette entreprise particulière opère et quelles combinaisons représentent réellement un risque - est à peine touché.

Cette absence de propriété est ce qui rend le problème de maintenance inévitable. Le système évolue continuellement après le go-live. De nouvelles applications Fiori sont déployées, des transactions Z sont créées pour les exigences locales, le processus d'achat est restructuré, et une fusion intègre une nouvelle filiale dans le modèle de rôles ROK. Chacun de ces changements modifie potentiellement quelles combinaisons d'accès sont risquées. Mais si personne ne possède la matrice du point de vue métier, ces changements ne retrouvent jamais leur chemin vers les règles.

4. Surcharge par les mitigations. Quand un conflit SoD ne peut pas être résolu rapidement - parce que sa résolution nécessite une refonte du rôle, un changement de processus ou une conversation que personne ne veut avoir - la réaction par défaut est d'ajouter un contrôle compensatoire et de le déclarer terminé. La matrice est mise à jour, le risque est documenté comme mitigé, et l'équipe passe au problème suivant.

Le registre des contrôles compensatoires croît à des centaines d'entrées. Chaque contrôle nécessite un propriétaire responsable et un examen périodique d'efficacité, mais quand la liste grandit, les examens deviennent un exercice de cases à cocher. Certains contrôles sont documentés mais jamais exécutés en pratique. D'autres font référence à des rapports ou workflows qui n'existent plus depuis longtemps. Le registre semble solide sur papier, mais son efficacité réelle diminue chaque trimestre.

5. Examens d'autorisations uniquement pilotés par l'audit. Le cycle de revue d'accès est défini par le calendrier d'audit externe, pas par le profil de risque du système. Une fois par an, généralement dans les semaines précédant l'audit financier, l'équipe sécurité lance une revue périodique. Les managers métier reçoivent des listes Excel avec des centaines d'utilisateurs et de rôles, sont priés d'approuver ou de refuser chacun, et tout le monde se précipite pour clôturer le cycle avant la visite de l'auditeur.

Le processus d'audit lui-même ajoute une couche supplémentaire de complexité. Les auditeurs arrivent souvent avec leur propre jeu de règles SoD, construit pas pour cette entreprise, cette configuration système ou cette version SAP. Ils ouvrent une liste de findings basée sur leur matrice que l'organisation doit défendre ou corriger - souvent sans contexte sur pourquoi cette combinaison spécifique pose ou non un problème dans cet environnement.

Et pourtant, malgré toutes ses limites, l'audit fait quelque chose d'important. Il met l'accès et les risques SoD à l'ordre du jour. Il crée un moment où le senior management prête attention, où le sujet passe d'une affaire technique à une affaire de gestion. Sans cette pression externe, de nombreuses organisations ne porteraient pas d'attention continue à la SoD du tout.

6. Réparez-le pendant le projet ou portez-le pour toujours. Il existe une différence fondamentale entre réparer le profil d'accès d'un utilisateur et réparer le concept de rôle sur lequel toute l'organisation fonctionne. Amener les profils d'accès des utilisateurs individuels en conformité est possible à tout moment - on peut identifier des utilisateurs concrets avec des conflits, impliquer leurs managers et supprimer les autorisations problématiques. La réparation de l'architecture de rôles elle-même est d'un ordre de grandeur plus difficile.

Comme décrit aux points 1 et 2, le fondement est souvent déjà compromis avant le go-live. Mais même en mettant de côté la qualité des décisions d'accès individuelles, l'architecture de rôles elle-même porte son propre héritage. Des rôles conçus autour de fonctions techniques plutôt que de fonctions métier. Des rôles à large périmètre conçus pour la commodité du projet plutôt que pour la précision opérationnelle. Des rôles qui ont accumulé des autorisations au fil des ans sans revue de conception.

Quand l'entreprise fonctionne sur un concept de rôle, toute tentative de nettoyage crée un risque opérationnel immédiat. Supprimer un objet d'autorisation casse une transaction dont quelqu'un dépend. Diviser un rôle signifie que quelqu'un qui avait tout a maintenant besoin de deux nouveaux rôles au lieu d'un, et un manager doit approuver le nouveau provisioning. Ces perturbations sont payées sur le budget du projet, donc les organisations tombent dans le piège : techniquement, la résolution du conflit nécessite un chemin concret, mais le chemin cause de la douleur pour l'entreprise.

7. La SoD comme documentation pour les auditeurs, pas comme principe de conception. Dans les organisations sans fonction GRC dédiée, la SoD n'a pas de propriétaire entre les cycles d'audit. Il n'y a pas d'équipe responsable de l'entretien de la matrice de risques entre les itérations, pas de surveillance continue des conflits, pas de suivi des tendances dans le temps. La matrice existe dans un dossier auquel les gens reviennent en mars ou octobre, quand l'auditeur apparaît.

Quand les auditeurs arrivent, l'organisation joue son rôle. Les données sont extraites, les preuves sont emballées, les mitigations sont documentées, et les findings sont traités avec urgence. Cela ressemble à un environnement de contrôle fonctionnel. Mais quand l'audit est terminé, les données sont remises en boîte, et l'attention de l'organisation se tourne vers d'autres priorités jusqu'à la prochaine fois.

Le problème plus profond est ce que ce schéma fait à la compréhension de l'organisation de son propre risque. Quand la SoD est pilotée par les échéances d'audit plutôt que par la propriété métier, les questions posées sont toujours étroites - avons-nous des preuves pour le contrôle X ? - et non larges : notre modèle d'accès reflète-t-il comment cette entreprise opère réellement ?

Quelque chose se perd aussi dans la manière dont la SoD est communiquée. Les findings d'audit vont au senior management comme problèmes de compliance, présentés en langage d'audit, mesurés par rapport aux critères d'audit et résolus depuis la mentalité de gestion d'audit. La conversation se concentre sur la clôture du finding, pas sur le changement de la manière dont l'entreprise opère. Ce qui ne se perd pas est quelque chose qui a causé le finding en premier lieu.

8. Pas du tout de programme SoD. La plupart des organisations ont les ingrédients. Il y a une matrice de risques, même si obsolète. Il y a des registres de mitigation, même si personne ne les examine. Il y a des revues d'accès, même si seulement annuelles. Les personnes responsables des différentes parties connaissent leurs noms.

Ce qui manque est l'architecture qui relie ces parties en quelque chose qui fonctionne réellement. Un appétit pour le risque défini qui dit à l'organisation quel niveau de risque d'accès est acceptable et ce qui nécessite escalade. Un forum de gouvernance où l'accès et le risque sont régulièrement discutés au niveau exécutif. Un cycle qui relie l'identification des risques avec la remédiation, la surveillance et l'amélioration des politiques.

Sans cela, chaque composant vit dans son propre silo. La matrice de risques n'est pas connectée au cycle de revue. Le cycle de revue n'est pas connecté au processus de remédiation. Les registres de mitigation ne sont pas surveillés par rapport aux changements système. Chaque équipe exécute sa partie, mais l'ensemble ne fonctionne pas ensemble. C'est le moment où la SoD cesse d'être un programme et devient une série d'activités isolées.

9. Excel au lieu d'un outil GRC dédié. L'analyse SoD gérée dans des tableurs crée un écart structurel entre l'apparence de contrôle et sa réalité. Les exports de rôles sont tirés manuellement du système, croisés avec la matrice de risques dans Excel et présentés comme statut de contrôle. Les résultats positifs sont documentés. Les négatifs sont discutés et soit mitigés soit amortis comme acceptés.

10. Personne ne veut être la personne qui dit non. Les programmes SoD échouent pour des raisons techniques, processuelles et de gouvernance. Mais sous beaucoup de ces échecs se cache un problème plus simple et plus humain. Dire non à l'accès coûte. Cela cause un conflit avec le manager qui a demandé. Cela ralentit le projet que le manager vient de promettre. Cela crée la réputation d'être une personne qui bloque les choses.

Cette dynamique est rarement visible dans les findings d'audit ou les registres de risques. Elle n'apparaît pas comme une défaillance de contrôle dans un sens formel. Mais elle façonne chaque décision dans le processus de gestion des accès. Les décisions de conception de rôles favorisent l'étendue plutôt que la précision. Les approbateurs approuvent parce que refuser est inconfortable. Les mitigations sont ajoutées à la matrice plutôt que de réparer les conflits à la source, parce que la réparation nécessiterait une conversation difficile.

Construire un programme SoD fonctionnel signifie reconnaître directement cette dynamique. Cela signifie donner aux personnes responsables du contrôle d'accès le soutien organisationnel pour dire non, des chemins d'escalade pour soulever des préoccupations quand la gestion est en désaccord, et un cadre de gouvernance qui protège le processus de la pression à court terme. Sans cela, même les matrices SoD les plus avancées et les meilleurs outils GRC ne feront aucune différence.

1.3 Le coût métier des défaillances SoD

Les régulateurs et auditeurs ont longtemps traité les violations SoD comme une déficience de contrôle significative. Sous Sarbanes-Oxley Section 404, les conflits SoD non résolus dans les systèmes financiers peuvent escalader vers une Material Weakness - un statut qui nécessite une divulgation publique et peut affecter la valorisation des actions de l'entreprise. Le PCAOB identifie systématiquement les faiblesses des IT General Controls, y compris la SoD, comme parmi les findings d'audit les plus courants dans SAP.

Les données de fraude rendent l'enjeu concret. L'ACFE estime que les organisations perdent 5% de leurs revenus annuels à cause de la fraude professionnelle, avec une perte moyenne par cas de 1,7 million USD. Ce chiffre est largement cité comme benchmark, mais cache une image bien plus large : la plupart des fraudes ne sont jamais détectées ou signalées en externe. L'ACFE Report to the Nations montre systématiquement que les contrôles anti-fraude sont absents ou contournés dans presque tous les cas. La SoD est centrale dans cette image.

Au-delà du risque de fraude, le coût opérationnel d'une mauvaise gestion SoD est significatif en lui-même. Les organisations qui dépendent d'examens manuels annuels passent généralement trois à six semaines par cycle de revue - personne-semaines tirées dans l'extraction d'exports, la normalisation des données, l'identification des conflits, l'escalade vers les managers métier, le suivi des sign-offs et l'emballage des preuves pour l'auditeur. C'est un coût récurrent et inefficace qui évolue moins bien que linéairement à mesure que l'organisation grandit.

Le schéma que décrivent les données ACFE - contrôles absents ou contournés, fraude se poursuivant non détectée pendant des mois, pertes découvertes seulement après les faits - n'est pas un risque abstrait. C'est le résultat prévisible des programmes SoD conçus plus pour la compliance que pour l'action.

1.4 Les coûts invisibles

Quand on parle de coûts, la plupart des managers pensent aux impacts directs - findings d'audit, amendes, pertes de fraude. Mais les coûts réels d'un programme SoD mal fonctionnel sont beaucoup plus répandus et souvent invisibles dans les rapports financiers standards.

Vitesse opérationnelle perdue. Les organisations à structure d'accès chaotique réagissent plus lentement aux changements métier. Une nouvelle acquisition, une réorganisation, un nouveau lancement de produit - chacun de ces changements nécessite des ajustements au modèle d'accès. Quand le modèle est peu clair, chacun de ces ajustements prend des semaines au lieu de jours. Multipliez cela par des dizaines de demandes de changement par trimestre, et l'effet composé sur l'agilité devient significatif.

Productivité réduite des employés. Quand le processus de provisioning d'accès est lent et opaque, les nouveaux employés attendent des jours ou des semaines pour l'accès complet. Pendant ce temps, ils travaillent avec des autorisations limitées et doivent demander de l'aide à des collègues ayant un accès plus large. Cela crée deux problèmes : le nouvel employé est sous-productif, et l'employé expérimenté qui aide est détourné de son propre travail.

Coûts de licence et de maintenance plus élevés. Une mauvaise gestion d'accès conduit souvent à des coûts de licence inutiles. Quand l'organisation ne peut pas voir clairement qui utilise quoi, elle a tendance à attribuer plus de licences que nécessaire. Dans les systèmes SAP, cela peut affecter la classification des utilisateurs comme Professional Users quand ils devraient être classifiés comme Self-Service ou Limited Users. L'impact annuel peut être significatif.

Coûts relationnels. Quand chaque audit produit des findings que l'entreprise perçoit comme injustes, la relation entre IT Security, équipe GRC et unités métier se détériore. L'IT est perçu comme obstacle, l'audit comme ennui, et la SoD comme bureaucratie. Cette perception rend chaque initiative d'amélioration future plus difficile à lancer, parce qu'elle commence sur une base de confiance déjà endommagée.

Coûts stratégiques. Au niveau le plus élevé, une mauvaise gestion SoD limite les options de l'organisation. Une migration cloud planifiée devient plus complexe quand le modèle d'accès actuel est peu clair. Un nouveau fournisseur GRC devient plus difficile à intégrer quand la configuration actuelle n'est pas documentée. Une acquisition est chargée de risque supplémentaire quand la conformité SoD de la cible ne peut pas être vérifiée. Chacune de ces frictions réduit l'agilité stratégique.

1.5 Ce qui fonctionne

Les programmes SoD efficaces partagent plusieurs caractéristiques clés qui les distinguent des tentatives pilotées par la compliance. Ils commencent avec un contexte métier clair - comprendre quels processus portent réellement du risque, comment ils fonctionnent dans cette organisation spécifique, et quels contrôles ont du sens. Ils ne s'appuient pas exclusivement sur des modèles génériques de l'industrie.

Ils ont une propriété métier. Chaque processus critique a un propriétaire clair responsable des décisions liées à la SoD dans ce domaine. Ces propriétaires comprennent que le contrôle d'accès fait partie de la gestion des risques de leur entreprise, pas un détail technique géré par l'IT.

Ils sont intégrés dans les processus métier. Les processus Joiner-Mover-Leaver sont conçus avec une conscience SoD dès la conception, pas comme une réflexion après coup. Quand une personne change de rôle, ses anciennes autorisations sont évaluées et supprimées si appropriée - pas simplement ajoutées aux nouvelles.

Ils utilisent la technologie comme levier, pas comme substitut à la discipline. Un bon outil GRC rend le programme plus efficace, mais il ne remplace pas le besoin d'une propriété claire, de bons processus et d'engagement du senior management. Le logiciel le plus avancé ne fera aucune différence dans une organisation sans ces fondations.

Ils ont un rythme d'amélioration continue. La matrice SoD est revue au moins annuellement, ou plus fréquemment si l'entreprise change significativement. Les modèles de conflit sont suivis dans le temps - pas seulement leurs nombres absolus mais aussi leurs tendances. Quand les conflits augmentent, le programme demande pourquoi, pas seulement comment les fermer.

Ils communiquent dans le langage de l'entreprise. Le reporting au senior management n'est pas présenté en langage technique d'audit mais en termes métier : quels risques sont exposés, quels sont les dommages les plus probables, comment répondons-nous ? Cette traduction est cruciale pour maintenir l'engagement et l'investissement continu.

1.6 Mise en place pour les chapitres suivants

Les chapitres suivants s'appuient sur ces concepts fondamentaux. Le chapitre 2 examine comment fonctionnent réellement les autorisations SAP - ce que sont les objets d'autorisation, comment les rôles sont construits, et quelles implications le modèle a pour la SoD. Le chapitre 3 approfondit les défis spécifiques de S/4HANA et Fiori. Le chapitre 4 examine comment les outils GRC (à la fois SAP GRC AC et alternatives) peuvent automatiser le travail d'analyse de risques.

Le chapitre 5 examine la logique métier des risques SoD - comment la matrice de risques est construite, ce qu'elle devrait inclure, et comment elle est entretenue dans le temps. Le chapitre 6 examine l'approche cycle de vie - comment les demandes d'accès sont gérées, les revues périodiques exécutées et les modèles de conflit suivis. Le chapitre 7 examine des sujets spécialisés tels que les contrôles compensatoires, l'accès d'urgence et les autorisations critiques.

Le chapitre 8 examine le modèle de maturité et comment une organisation évalue son état actuel et définit un chemin d'amélioration. Le chapitre 9 examine les meilleures pratiques et pièges courants des implémentations réelles. Le chapitre 10 conclut avec une discussion sur l'avenir de la SoD dans le contexte des technologies émergentes comme l'IA, les agents autonomes et l'évolution des cadres réglementaires.

2.1 Objets d'autorisation et champs

Le modèle d'autorisation SAP est basé sur des objets d'autorisation, qui sont l'unité atomique du contrôle d'accès. Un objet d'autorisation est un conteneur composé de plusieurs champs d'autorisation, chacun rempli avec des valeurs spécifiques. Cette combinaison définit quelles actions spécifiques un utilisateur peut effectuer avec quelles données spécifiques.

Prenons l'objet d'autorisation F_BKPF_BUK comme exemple. Il contrôle l'accès à l'en-tête de document pour les documents comptables au niveau de la société. Il contient deux champs : BUKRS (société) et ACTVT (activité). Le champ BUKRS peut contenir des valeurs de société spécifiques, comme 1000, 2000 ou un wildcard *. Le champ ACTVT peut contenir des codes d'activité comme 01 (créer), 02 (modifier) ou 03 (afficher).

Une autorisation est une instanciation spécifique d'un objet d'autorisation avec des valeurs de champ concrètes. Par exemple : F_BKPF_BUK avec BUKRS=1000 et ACTVT=03 permet à l'utilisateur d'afficher les documents dans la société 1000. Une autre autorisation pour le même objet avec BUKRS=* et ACTVT=01,02,03 permettrait à l'utilisateur de créer, modifier et afficher des documents dans toutes les sociétés.

Il y a environ 3 000 objets d'autorisation dans un système SAP standard, avec les solutions industrielles et d'extension en ajoutant encore plus. Chaque objet d'autorisation a une signification spécifique dans le contexte du processus métier qu'il contrôle. La complexité du modèle découle du nombre d'objets, de leurs effets interconnectés et de la configuration spécifique de chaque implémentation.

2.2 Rôles et profils

Les autorisations ne sont pas attribuées directement aux utilisateurs mais via les rôles. Un rôle est une collection d'autorisations qui prennent généralement en charge une fonction métier ou un sous-processus spécifique. Quand un utilisateur reçoit un rôle, il hérite de toutes les autorisations contenues dans ce rôle.

Il y a deux principaux types de rôles : rôles simples et rôles composites. Un rôle simple contient une liste d'autorisations avec leurs valeurs de champ spécifiques. Un rôle composite est une collection d'autres rôles (soit des rôles simples soit d'autres rôles composites). Quand un rôle composite est attribué à un utilisateur, il hérite des autorisations de tous les rôles qu'il contient.

Les profils sont l'implémentation technique des autorisations. Quand un rôle est généré, un profil est également généré simultanément, contenant les autorisations sous une forme que le système peut utiliser lors de la vérification d'autorisation. Les profils ont des noms commençant par un préfixe qui les identifie comme appartenant à un rôle spécifique.

Il y a aussi des profils SAP standards qui peuvent être attribués directement via le customizing. Le plus connu est SAP_ALL, qui accorde pratiquement l'accès complet à tout dans le système, et SAP_NEW, qui reçoit toutes les nouvelles autorisations ajoutées dans les releases ultérieurs. Ces profils ne devraient jamais être attribués à des utilisateurs normaux dans les systèmes productifs - leur existence est limitée aux scénarios d'urgence et à la configuration technique post-installation.

2.3 Vérification d'autorisation en pratique

Quand un utilisateur tente d'effectuer une action dans SAP, le système effectue une vérification d'autorisation. Cette vérification se produit généralement via la commande ABAP AUTHORITY-CHECK. Lors de l'appel de la commande, le système examine les autorisations attribuées à l'utilisateur et vérifie si au moins une d'elles permet l'accès à l'objet d'autorisation spécifique demandé avec les valeurs de champ appropriées.

La clé pour comprendre est que les autorisations sont additives - si un utilisateur a plusieurs rôles et que l'un d'eux permet l'accès, il a l'accès. Il n'y a pas de mécanisme pour le 'refus explicite' de la même manière que dans certains autres systèmes de sécurité. Si un utilisateur a donc un rôle qui permet l'accès à F_BKPF_BUK dans la société 1000, et un autre qui le permet dans la société 2000, l'utilisateur a effectivement accès aux deux.

Ce fait a des implications profondes pour la SoD. Quand la matrice de risques SoD définit que la combinaison de 'créer fournisseur' et 'exécuter run de paiement' représente un conflit, il ne s'agit pas seulement de chercher un rôle unique ayant les deux autorisations. Il s'agit de vérifier toutes les combinaisons possibles de rôles attribués qui, ensemble, accorderaient ces autorisations. Pour un utilisateur ayant dix rôles, le nombre de combinaisons possibles est très élevé.

C'est pourquoi l'analyse SoD au niveau utilisateur est toujours additive et liée à toutes les autorisations actives sur tous les rôles. Elle ne peut pas être effectuée par l'analyse des rôles individuels - bien que l'analyse des conceptions de rôles soit également importante pour comprendre les sources de conflit et améliorer le modèle.

2.4 PFCG : L'outil qui définit tout

L'outil principal pour gérer les rôles dans SAP est la transaction PFCG (générateur de profils). PFCG est l'endroit central où les administrateurs de sécurité créent, modifient les rôles et gèrent leurs autorisations. Comprendre ses fonctionnalités est essentiel pour quiconque travaille avec le modèle d'autorisation SAP.

PFCG a plusieurs onglets contrôlant différents aspects du rôle. L'onglet Menu définit quelles transactions et applications font partie de ce rôle. Quand des transactions sont ajoutées au menu, PFCG suggère automatiquement les objets d'autorisation qu'ils utilisent, basé sur les données dans la table SU24 (qui définit la relation entre transactions et objets d'autorisation).

L'onglet Autorisations affiche tous les objets d'autorisation que le rôle possède et permet leur configuration détaillée. Les administrateurs de sécurité peuvent définir des valeurs pour chaque champ d'autorisation - soit des valeurs spécifiques, plages de valeurs ou wildcards (*). C'est ici que la granularité du contrôle est définie.

L'onglet Utilisateurs affiche quels utilisateurs sont attribués à ce rôle. Ici, les administrateurs peuvent attribuer ou supprimer des rôles directement à des utilisateurs individuels ou à un groupe d'utilisateurs. Cependant, dans les implémentations plus matures, cette attribution se fait via les outils GRC avec approbation workflow, pas directement dans PFCG.

Une fonctionnalité PFCG importante est la liaison des rôles aux niveaux organisationnels comme société ou usine. Avec cette liaison, le même rôle peut accorder l'accès à différentes unités organisationnelles, selon quels niveaux organisationnels sont définis pour un utilisateur particulier. C'est un mécanisme puissant qui simplifie la conception de rôles mais peut aussi être une source de complexité s'il est implémenté incorrectement.

2.5 Transactions et leur relation aux autorisations

Dans ECC et les versions antérieures, le code de transaction (T-code) était l'unité primaire par laquelle les utilisateurs interagissaient avec le système. Chaque T-code représentait une action métier spécifique - comme ME21N pour créer une commande d'achat ou FB01 pour la comptabilisation comptable manuelle. Le T-code est aussi une unité importante pour les besoins SoD, parce que beaucoup de règles SoD ont été historiquement exprimées sous forme de combinaisons de T-codes.

La relation entre une transaction et ses autorisations requises n'est pas triviale. Une seule transaction peut vérifier des dizaines d'objets d'autorisation, selon quelles actions spécifiques l'utilisateur effectue dans cette transaction. Par exemple, quand un utilisateur démarre ME21N, le système vérifie des autorisations comme M_BEST_BSA (commande), M_BEST_WRK (commande par usine), M_BEST_EKO (commande par organisation d'achats) et plus.

La table SU24 est l'endroit où ces relations sont définies. Elle contient des mappings SAP standards montrant quels objets d'autorisation sont associés à quelles transactions, et si l'autorisation est 'Default' (suggérée quand le T-code est ajouté au rôle) ou optionnelle. Cette table peut être personnalisée selon les besoins locaux d'une organisation, ce qui est une possibilité puissante mais en même temps complexe.

Dans S/4HANA, beaucoup de transactions existent toujours comme implémentation backend, mais les utilisateurs interagissent souvent avec elles via des applications Fiori, qui fournissent une UI moderne. Une seule app Fiori peut combiner plusieurs transactions sous-jacentes ou fournir une fonctionnalité entièrement nouvelle qui n'existe pas dans la connexion transactionnelle classique. Cela complique significativement le mapping SoD.

2.6 Données maîtres et customizing

Les données maîtres sont un aspect particulièrement sensible du point de vue SoD. Les données maîtres comme fournisseurs, clients, matières ou employés sont la base sur laquelle les transactions sont construites. Qui peut créer ou modifier des données maîtres a une influence indirecte sur les transactions qui utilisent ces données.

Exemple classique de SoD : créer des données maîtres fournisseurs et traiter le paiement en même temps. Une personne qui peut créer un nouveau fournisseur (avec ses propres coordonnées bancaires) et aussi autoriser le paiement à ce fournisseur a le contrôle complet pour diriger des fonds vers un fournisseur apparemment légitime mais en fait contrôlé. C'est l'un des scénarios de fraude les plus courants dans les systèmes SAP.

Les autorisations de customizing sont une autre catégorie majeure. Le customizing fait référence à la configuration du système SAP lui-même - définition des sociétés, usines, types de matières, types de documents et milliers d'autres paramètres contrôlant le comportement du système. Les autorisations de customizing devraient être extrêmement restrictives et accordées uniquement à de petites équipes (généralement dans les domaines fonctionnels et IT) responsables de maintenir la configuration du système.

Dans les systèmes productifs, le customizing devrait généralement être introduit uniquement via des transports depuis le développement et le test, pas configuré directement par les utilisateurs dans le système productif. Le customizing direct en production est un finding d'audit classique et peut représenter un problème de contrôle significatif, particulièrement pour les questions comptables sous SOX.

2.7 Implications pour les programmes SoD

La compréhension technique du modèle d'autorisation SAP a plusieurs implications directes pour la conception des programmes SoD. Premièrement, l'analyse SoD ne peut pas être effectuée uniquement au niveau des codes de transaction - elle doit descendre au niveau des objets d'autorisation et des valeurs de champ. Un rôle qui a le T-code ME21N dans PFCG, mais dont l'objet d'autorisation M_BEST_BSA est configuré avec une valeur vide, n'accorde pas effectivement à l'utilisateur l'accès à la commande de demandes d'achat.

Deuxièmement, l'analyse doit prendre en compte les niveaux organisationnels. Un rôle qui montre un conflit SoD au niveau de l'objet d'autorisation peut en pratique ne pas représenter de risque si les niveaux organisationnels sont restreints de sorte que l'utilisateur ne peut pas en pratique effectuer les deux actions pour la même unité organisationnelle. Cette subtilité est souvent négligée dans l'analyse SoD précoce.

Troisièmement, l'analyse doit considérer toutes les sources d'autorisation, y compris les autorisations explicites qui contournent les rôles. Dans les systèmes SAP legacy, il n'est pas rare de trouver des utilisateurs avec des autorisations attribuées directement (au lieu de via les rôles), ou des profils attribués directement. Ces sources peuvent être négligées dans une analyse SoD basée sur les rôles si les outils ne réalisent pas l'analyse au niveau de toutes les autorisations actives.

Quatrièmement, nous devons prendre en compte le fait que les rôles, une fois conçus, sont fréquemment modifiés au fil du temps. Un rôle qui était conforme SoD à un moment donné peut ne plus être conforme après plusieurs modifications. Par conséquent, la surveillance SoD doit être continue, pas ponctuelle.

Enfin, la complexité du modèle d'autorisation SAP implique que les outils GRC sont presque indispensables pour son analyse efficace. Les analyses manuelles peuvent détecter des cas simples mais luttent avec l'échelle, le mapping des niveaux organisationnels et la surveillance continue. Nous examinerons les outils GRC plus en détail dans le prochain chapitre.

3.1 Qu'est-ce que Fiori et pourquoi est-ce important

SAP Fiori est la couche UX moderne pour les applications SAP, basée sur les technologies web (HTML5, CSS, JavaScript) et conçue pour fournir une interface utilisateur moderne et intuitive qui fonctionne de manière cohérente sur différents appareils (desktop, tablette, smartphone). Du point de vue d'un utilisateur final, Fiori est le moyen principal d'interagir avec S/4HANA.

Architecturalement, les applications Fiori sont des apps indépendantes qui exécutent des fonctions métier spécifiques. Chaque app a un domaine clairement défini - par exemple, 'Créer commande', 'Afficher facture fournisseur' ou 'Enregistrer réception de marchandises'. Les apps sont organisées par rôle et domaine fonctionnel et accessibles via le Fiori Launchpad, qui sert de page d'accueil personnalisée pour chaque utilisateur.

Comparé au monde classique ECC, où les utilisateurs naviguaient via la recherche T-code ou via les menus, Fiori présente à l'utilisateur uniquement ce qui est pertinent pour son rôle. C'est à la fois bon et difficile. D'un côté, cela améliore la productivité de l'utilisateur et réduit le besoin de formation. De l'autre, cela crée une couche supplémentaire de gestion des autorisations - il ne suffit pas qu'un utilisateur ait accès à la fonction sous-jacente ; il doit aussi avoir accès à l'app Fiori spécifique qui l'exécute.

Du point de vue SoD, l'application Fiori est une nouvelle unité de risque. Une matrice de conflit définie sous forme de combinaisons classiques de T-codes peut manquer beaucoup de conflits potentiels qui émergent maintenant sous forme de combinaisons d'apps Fiori. La méthodologie SoD doit en tenir compte en inventoriant toutes les apps Fiori pertinentes et en les classifiant correctement dans la matrice de risques.

3.2 Services OData et autorisations

L'architecture de fond de Fiori est basée sur les services OData - services web REST-like qui fournissent des données et des fonctions métier via HTTP. Chaque app Fiori communique avec le backend via un ou plusieurs services OData. Ces services sont des endpoints techniques qui supportent l'accès aux données et les opérations comme lire, créer, mettre à jour et supprimer.

Du point de vue de la sécurité, les services OData représentent une nouvelle couche qui nécessite ses propres autorisations. Ces autorisations sont contrôlées via l'objet d'autorisation S_SERVICE et la configuration SICF (transaction pour les services internet). Un utilisateur doit avoir accès au service OData et aux objets d'autorisation sous-jacents qui contrôlent ses opérations spécifiques.

Cette stratification crée une complexité dans l'analyse SoD. Théoriquement, un utilisateur pourrait avoir accès à l'app Fiori mais sans accès aux autorisations sous-jacentes, il ne serait pas capable d'effectuer une action. Inversement, un utilisateur pourrait avoir accès aux autorisations sous-jacentes mais sans accès à l'app Fiori, sa capacité à l'exécuter serait limitée (à moins qu'il n'y ait un chemin alternatif comme un T-code classique ou un appel OData externe).

En pratique, cela signifie qu'une analyse SoD complète doit considérer tous les chemins : transactions classiques, apps Fiori, services OData et aussi appels externes (par exemple via intégrations API). Les outils qui analysent la SoD uniquement à l'un de ces niveaux risquent de manquer des sources de risque significatives.

3.3 Rôles standards et Business Catalogs

SAP fournit une bibliothèque étendue de rôles standards et de Business Catalogs pour S/4HANA. Ceux-ci sont conçus comme point de départ pour les organisations qui veulent implémenter des conceptions de rôles SoD-conscientes. Théoriquement, les rôles standards devraient couvrir des domaines d'application où la séparation des tâches est intégrée dans la conception.

En pratique, l'utilisation de rôles standards sans personnalisation substantielle est rarement pratique. Les rôles standards sont souvent trop larges (plus d'autorisations que nécessaire) ou trop étroits (ils ne reflètent pas des processus locaux spécifiques). Les organisations créent typiquement leurs propres rôles personnalisés, basés sur des rôles standards ou conçus de zéro.

Business Catalogs est une fonctionnalité plus récente introduite dans S/4HANA. Ce sont des collections d'apps Fiori groupées par domaine métier et qui peuvent être utilisées comme blocs de construction pour construire des rôles. Business Catalogs simplifient la conception de rôles en fournissant un groupement pré-construit d'apps liées. Cependant, leur personnalisation est aussi presque toujours nécessaire.

Une best practice importante dans le monde de S/4HANA est la séparation des rôles en deux niveaux : rôles d'autorisation (qui contiennent les autorisations SAP sous-jacentes) et Business Role Catalogs (qui contiennent les applications Fiori). Cette séparation facilite la maintenance et permet une gestion plus flexible. Cependant, elle augmente aussi la complexité de l'analyse SoD, puisque les conflits doivent être analysés sur les deux niveaux.

3.4 Risques spécifiques à S/4HANA

Plusieurs classes de risques SoD deviennent plus proéminentes ou nouvelles dans le monde S/4HANA. Premièrement, les apps Fiori qui consolident les processus end-to-end. Une app comme 'Gérer commandes d'achat' peut combiner plusieurs transactions classiques - créer, approuver, modifier, afficher. Une analyse SoD qui ne classifie pas correctement cette app peut manquer qu'un utilisateur avec accès à cette app a effectivement le contrôle complet du cycle de vie des commandes.

Deuxièmement, autorisations in-app et configurations de variantes. Certaines apps Fiori ont des possibilités de configuration interne qui peuvent affecter le modèle d'autorisation. Par exemple, une app d'approbation peut être configurée pour permettre à un utilisateur d'approuver ses propres demandes (ce qui serait un échec SoD évident). Ces options de configuration sont souvent négligées dans l'analyse d'autorisation de base.

Troisièmement, embedded analytics et dashboards KPI. S/4HANA intègre nativement des fonctions analytiques qui fournissent un accès aux données en temps réel. Ces fonctions peuvent exposer des informations métier sensibles qui étaient historiquement gérées via des systèmes BI séparés avec leurs propres contrôles d'accès. Les programmes SoD doivent considérer explicitement les risques liés à la divulgation involontaire de données sensibles.

Quatrièmement, extensions side-by-side avec SAP BTP. S/4HANA est fréquemment étendu avec des extensions personnalisées qui s'exécutent sur SAP Business Technology Platform. Ces extensions ont leurs propres modèles d'autorisation et peuvent accéder aux données S/4HANA via des API. Un programme SoD complet doit couvrir ces composants externes dans le périmètre des risques.

3.5 Stratégies de migration et SoD

Les organisations migrant d'ECC vers S/4HANA ont plusieurs stratégies disponibles : Brownfield (conversion de système avec configuration et données préservées), Greenfield (nouvelle implémentation de zéro) ou Selective Data Transition (sélection sélective de ce qui est transféré). Chacune de ces stratégies a des impacts différents sur le programme SoD.

Dans la migration Brownfield, les rôles et autorisations existants sont typiquement préservés, avec des autorisations supplémentaires pour les nouvelles apps Fiori. C'est la stratégie la plus rapide mais a l'inconvénient que tous les problèmes SoD existants sont transférés vers le nouveau système. C'est aussi une opportunité manquée de redessiner le modèle de rôles en considérant les nouvelles possibilités de S/4HANA.

Dans l'implémentation Greenfield, l'organisation peut redessiner le modèle de rôles de zéro. C'est une opportunité significative pour construire un modèle SoD-conforme dès le début. Cependant, cela nécessite un effort considérable et une bonne discipline pour éviter que les équipes d'implémentation ne reviennent aux mêmes schémas compromis décrits au chapitre 1 pour des raisons opérationnelles.

Selective Data Transition se situe au milieu. L'organisation peut choisir quels aspects préserver et lesquels redessiner. Cela peut être une bonne approche pour redessiner l'architecture SoD dans les domaines les plus problématiques sans assumer la portée complète d'une implémentation Greenfield.

Quelle que soit la stratégie, le programme SoD devrait être activement impliqué dans la planification de migration, pas réactif. Cela signifie que la matrice de risques SoD est mappée contre le nouveau périmètre système, la conception des rôles est revue, et les propriétaires de processus métier sont impliqués dans les discussions sur les contrôles d'accès pendant la phase de migration.

4.1 SAP GRC Access Control : Vue d'ensemble

SAP GRC Access Control (AC) est l'outil GRC phare de SAP et pour beaucoup d'organisations avec un grand footprint SAP, le choix standard. Il consiste en plusieurs modules intégrés : Access Risk Analysis (ARA) pour l'analyse SoD, Emergency Access Management (EAM) pour la gestion des accès privilégiés temporaires, Business Role Management (BRM) pour la gestion de la conception de rôles, et Access Request Management (ARM) pour les demandes d'accès basées sur workflow.

La force de SAP GRC AC est l'intégration profonde avec l'écosystème SAP. Il connaît intimement le modèle d'autorisation, peut effectuer des analyses complexes sur les niveaux organisationnels, et supporte un large éventail de systèmes SAP (ECC, S/4HANA, BW, SCM et autres). Pour les organisations avec de grandes implémentations SAP complexes, cette profondeur est difficile à égaler.

La faiblesse de SAP GRC AC réside dans sa complexité et sa charge de maintenance. L'implémentation nécessite des consultants dédiés, la maintenance nécessite des compétences spécialisées, et la configuration typique peut prendre des mois d'effort avant que des résultats significatifs ne soient obtenus. Du point de vue d'un utilisateur final, l'expérience utilisateur est souvent décrite comme datée et non intuitive, particulièrement comparée aux plateformes GRC SaaS modernes.

Une autre question est la mise à l'échelle des coûts de licence. SAP GRC AC est typiquement licencié par nombre d'utilisateurs, ce qui peut augmenter significativement le coût total dans les grandes organisations. Le Total Cost of Ownership inclut aussi les coûts de maintenance, formation, personnalisations et upgrades périodiques, tous non triviaux.

4.2 Ce que SAP GRC AC fait bien

Malgré ses limites, SAP GRC AC livre une valeur réelle dans plusieurs domaines spécifiques. Premièrement, la profondeur d'analyse. Le module ARA peut effectuer des analyses SoD complexes sur toutes les autorisations actives, les niveaux organisationnels et les données maîtres. Il fournit des visualisations et des fonctionnalités de drill-down qui facilitent la compréhension des causes profondes.

Deuxièmement, le module EAM est un mécanisme puissant pour gérer les accès privilégiés temporaires (souvent appelés Firefighter Access). Il supporte des workflows structurés demande-approbation, un logging complet des activités effectuées et des revues périodiques. Pour les organisations avec de grandes opérations IT et de nombreuses situations d'urgence, c'est une fonctionnalité significative.

Troisièmement, l'intégration avec d'autres outils et processus SAP. SAP GRC AC fonctionne nativement avec SAP HR (pour les données employés), SAP Identity Management et d'autres composants SAP. Il peut utiliser directement les hiérarchies d'identité et les structures organisationnelles, ce qui simplifie la configuration des workflows.

Quatrièmement, la base de connaissances établie et la communauté de consultants. Il y a un nombre significatif de consultants avec des années d'expérience en SAP GRC AC, ce qui rend l'implémentation et la maintenance plus faciles que pour des outils plus rares. Cette communauté est aussi une source précieuse de best practices et de résolution de problèmes.

4.3 Les limites des outils GRC classiques

Malgré les forces décrites ci-dessus, les outils GRC classiques rencontrent des limites fondamentales qui deviennent de plus en plus pertinentes dans la réalité business moderne. Premièrement, leur modèle est principalement conçu pour les mondes SAP. Les organisations utilisant SAP avec d'autres plateformes (Oracle, Workday, Salesforce, ServiceNow, applications personnalisées) trouvent que les outils SAP GRC classiques ne livrent pas une vue complète du risque sur l'ensemble du portefeuille applicatif.

Deuxièmement, la vitesse du changement. Les outils GRC classiques ont été conçus à une époque où la configuration SAP était relativement stable et les changements moins fréquents et plus prévisibles. Dans le monde actuel du déploiement continu de nouvelles apps Fiori, des releases agiles de S/4HANA et des ajustements rapides aux exigences métier, les outils GRC doivent pouvoir réagir aussi rapidement. Les outils classiques luttent fréquemment à suivre le rythme du changement.

Troisièmement, l'expérience utilisateur. Les utilisateurs métier, y compris propriétaires de processus métier et managers approuvant les demandes d'accès et effectuant les revues périodiques, attendent une interface moderne et intuitive. Les outils GRC classiques livrent souvent des interfaces difficiles à apprendre et qui limitent l'engagement des utilisateurs métier.

Quatrièmement, l'analyse des données et le reporting. Les outils classiques livrent des rapports standardisés, mais les organisations modernes veulent souvent des analyses plus profondes - analyses de tendances dans le temps, corrélations avec d'autres événements métier, modélisation prédictive. Ces fonctionnalités nécessitent typiquement des outils BI supplémentaires et des intégrations de données qui augmentent la complexité.

4.4 La vague des plateformes GRC agiles

En réponse aux limites décrites ci-dessus, une nouvelle vague de plateformes GRC est apparue ces dernières années, appelées 'agile GRC' ou 'modern GRC'. Ces plateformes sont typiquement offertes en SaaS, ont des UIs modernes et sont conçues pour être déployées rapidement dans plusieurs environnements.

Les fonctionnalités qui distinguent souvent ces plateformes incluent : architecture cloud-native permettant des mises à jour rapides et la mise à l'échelle ; interfaces intuitives pour les utilisateurs métier ; moteurs de workflow intégrés conçus pour les processus métier agiles modernes ; analyses et visualisations intégrées ; et APIs ouvertes pour l'intégration avec d'autres outils.

Dans le contexte SoD, les plateformes GRC agiles apportent plusieurs innovations. Premièrement, analyse de risques continue - au lieu d'analyses batch périodiques, les risques sont recalculés en continu à mesure que les autorisations changent. Deuxièmement, workflows d'approbation contextuels qui fournissent un contexte métier additionnel au lieu de simplement lister les autorisations à approuver. Troisièmement, formation embarquée et sensibilisation aux risques dans le processus d'approbation.

Mais les plateformes modernes ont aussi des limites. La profondeur d'intégration SAP est souvent moins mature que pour SAP GRC AC. La méthodologie d'analyse de risques peut être moins complète, particulièrement pour les scénarios complexes avec niveaux organisationnels et multiples sources d'autorisation. Et pour les organisations avec un grand footprint SAP, le passage de SAP GRC AC à une plateforme agile peut être un effort de migration significatif.

4.5 Comment choisir : SAP GRC AC vs plateformes agiles

Le choix entre SAP GRC AC classique et une plateforme agile dépend de plusieurs facteurs. SAP GRC AC tend à être le bon choix quand l'organisation : a un footprint SAP grand et complexe ; est déjà investie dans SAP GRC AC ou d'autres outils SAP ; nécessite une analyse profonde sur les niveaux organisationnels et les structures d'autorisation complexes ; et dispose du budget et des compétences pour maintenir un outil complexe.

Une plateforme agile tend à être le bon choix quand l'organisation : a un portefeuille applicatif hétérogène au-delà de SAP ; priorise une forte expérience utilisateur et une création de valeur rapide ; cherche un déploiement plus rapide et un coût total de propriété plus bas ; et veut implémenter un programme GRC plus moderne et agile.

En pratique, beaucoup d'organisations choisissent une approche hybride. SAP GRC AC peut être utilisé pour l'analyse SoD profonde dans le monde SAP, tandis qu'une plateforme agile est utilisée pour les fonctions GRC transversales comme la gestion des risques, le suivi de conformité et les contrôles de processus métier. Cette approche peut livrer le meilleur des deux mondes mais augmente la complexité de l'architecture et nécessite une bonne intégration entre les outils.

Une question importante à considérer dans le choix est la stratégie à long terme. Où sera l'organisation dans 3-5 ans ? Quelles applications seront dans le portefeuille principal ? Comment évoluera la roadmap SAP (particulièrement SAP S/4HANA Cloud) ? Le choix qui est juste aujourd'hui peut être moins optimal dans quelques années, donc il est important de choisir une plateforme qui s'aligne sur les besoins à long terme de l'organisation.

5.1 Qu'est-ce réellement qu'une matrice de risques

Une matrice de risques SoD est une collection structurée de règles de risque, chacune définissant une combinaison d'actions métier qui ensemble représentent un risque de fraude ou d'erreur. Une règle de risque a typiquement : un ID unique, un nom descriptif, une description du risque métier, un niveau de risque attribué (typiquement élevé, moyen, faible) et une liste des fonctions conflictuelles (souvent appelées 'Risk Functions').

Les Risk Functions sont les blocs de construction de la matrice. Une Risk Function représente une action métier spécifique - par exemple, 'créer fournisseur', 'exécuter run de paiement' ou 'enregistrer réception de marchandises'. Chaque Risk Function est liée à un ensemble d'autorisations SAP (codes de transaction, apps Fiori, objets d'autorisation) qui représentent son implémentation technique.

Une règle de risque connecte typiquement deux ou plusieurs Risk Functions. Par exemple : 'créer fournisseur + exécuter run de paiement' est une règle qui identifie qu'une personne avec les deux fonctions pourrait exécuter un mécanisme de fraude classique. Quand un utilisateur a un accès effectif aux deux Risk Functions (via un ou plusieurs rôles), il est identifié comme étant en conflit.

La matrice de risques dans une organisation typique peut contenir de dizaines à plusieurs centaines de règles de risque. La taille elle-même n'est pas un indicateur de qualité - une matrice avec 500 règles n'est pas nécessairement meilleure qu'une avec 100. Ce qui importe, c'est que les règles incluses reflètent les risques métier réels, soient correctement mappées sur les autorisations SAP et soient maintenues dans le temps.

5.2 Logique métier vs implémentation technique

Une tension fondamentale dans la conception de la matrice SoD est l'équilibre entre logique métier et implémentation technique. D'un côté, la matrice doit refléter les risques métier réels - les risques qu'un propriétaire métier reconnaît comme significatifs et nécessitant un traitement. De l'autre côté, elle doit être mappée sur la configuration SAP spécifique qui doit être techniquement faisable pour l'analyse de risques.

Quand cette tension est bien gérée, la matrice est significative à la fois pour les utilisateurs métier et les implémenteurs techniques. Quand elle est mal gérée, la matrice est soit trop high-level (bonne pour les utilisateurs métier mais techniquement non faisable) soit trop technique (techniquement précise mais sans signification pour les utilisateurs métier).

Le piège habituel est que la matrice est créée comme un artefact technique sans engagement suffisant des utilisateurs métier. Le résultat est une matrice qui identifie correctement les conflits, mais quand un conflit est présenté à un utilisateur métier pour résolution, l'utilisateur demande 'Pourquoi est-ce un problème ?' et l'équipe technique ne peut pas répondre à cette question en langage métier. La confiance dans le programme diminue, et les résolutions deviennent superficielles (mitigations sans compréhension profonde).

La pratique efficace est que la matrice est conçue dans une discussion itérative entre les propriétaires métier et l'équipe GRC. Les propriétaires métier décrivent les risques métier dans leur langage. L'équipe GRC les traduit en autorisations SAP et confirme la faisabilité technique. Ensuite, les risques sont validés avec la matrice contre les données d'accès actuellement actives, pour voir si les règles produisent en pratique des résultats significatifs.

5.3 Niveaux de risque et priorisation

Tous les conflits SoD ne sont pas égaux. Une matrice de risques devrait avoir un système clair de priorisation - typiquement trois ou quatre niveaux de risque (critique/élevé/moyen/faible ou conventions similaires). Ces niveaux aident les propriétaires métier et les équipes GRC à concentrer leur attention sur ce qui compte vraiment.

Les critères d'évaluation du risque incluent typiquement plusieurs facteurs : le potentiel d'impact financier du risque, la probabilité qu'il soit exploité, la présence d'autres contrôles qui peuvent mitiger le risque, et les implications réglementaires. Un conflit qui peut permettre une perte d'argent directe (par exemple créer fournisseur + exécuter run de paiement) est typiquement classé comme critique. Un conflit qui représente principalement des risques de reporting peut être classé plus bas.

La priorisation est importante pour plusieurs raisons pratiques. Premièrement, basée sur les ressources. Les équipes GRC et propriétaires métier ont un temps limité pour résoudre les conflits. Si tous les conflits sont traités de manière égale, ceux vraiment importants se perdront souvent dans le bruit. Deuxièmement, réglementaire. Dans les audits SOX, les conflits critiques sont ceux que l'équipe d'audit examine de près, et leur résolution est particulièrement importante. Troisièmement, métier. Certains conflits peuvent être entièrement acceptables si d'autres contrôles sont en place, tandis que d'autres nécessitent une résolution indépendamment des contrôles supplémentaires.

Une best practice importante est que les niveaux de risque sont revus dans le temps. Ce qui était classé comme critique il y a cinq ans peut être moins critique aujourd'hui en raison de contextes métier changeants, nouveaux paysages de menaces ou changements réglementaires (ou inversement). La revue des niveaux de risque devrait faire partie du cycle de maintenance périodique de la matrice.

5.4 Mapping sur les autorisations SAP

Une fois que les Risk Functions sont définies en langage métier, elles doivent être mappées sur les autorisations SAP. C'est à la fois un travail technique et analytique. Il nécessite une compréhension approfondie de la configuration SAP, du modèle d'autorisation et des processus métier.

Le mapping se produit typiquement à trois niveaux. Premièrement, au niveau des codes de transaction. Quels T-codes permettent d'exécuter cette Risk Function ? C'est le niveau le plus simple et suffisant pour la plupart des risques classiques ECC.

Deuxièmement, au niveau des apps Fiori. Quelles apps Fiori permettent d'exécuter cette Risk Function dans S/4HANA ? Cela nécessite un inventaire des apps Fiori déployées et leur connexion aux fonctions métier sous-jacentes.

Troisièmement, au niveau des objets d'autorisation et valeurs de champ. Pour des analyses plus précises, particulièrement pour les risques liés à la gestion des données maîtres ou au customizing, le mapping doit descendre au niveau d'objets d'autorisation spécifiques et leurs valeurs de champ. Par exemple : 'créer fournisseur' n'est pas seulement la transaction XK01, mais aussi des valeurs spécifiques de l'objet d'autorisation F_LFA1_BEK et similaires.

Une question technique importante est la présence de transactions Z - transactions personnalisées typiquement nommées avec le préfixe Z- ou Y-. Ces transactions sont souvent négligées dans le mapping SoD parce qu'elles n'apparaissent pas dans les templates standards. Mais elles peuvent permettre l'accès à des fonctions risquées - parfois même construites plus habilement pour contourner les contrôles standards. Un mapping SoD complet doit inclure ces transactions personnalisées.

Le défi constant est l'exhaustivité. SAP est un environnement extrêmement riche avec des milliers de transactions, et pour chaque Risk Function, il y a typiquement plusieurs chemins par lesquels un utilisateur peut l'exécuter. Trouver des chemins complets est un travail analytique difficile, et certains chemins manqueront toujours dans les premières analyses. Par conséquent, le mapping devrait être vu comme continuellement amélioré, avec des revues périodiques et des mises à jour basées sur l'analyse de données réelles et les chemins nouvellement découverts.

5.5 Maintenance et évolution de la matrice

Une matrice SoD n'est jamais terminée. Elle doit évoluer continuellement à mesure que l'entreprise, la configuration SAP et le paysage réglementaire changent. Une matrice bien maintenue est revue au moins annuellement et mise à jour plus fréquemment quand des changements significatifs se produisent.

Les déclencheurs de mises à jour de matrice incluent : releases SAP (particulièrement les grandes mises à jour S/4HANA qui introduisent de nouvelles apps Fiori) ; acquisitions ou cessions changeant le portefeuille métier ; réorganisations de processus métier changeant la structure organisationnelle ; nouvelles exigences réglementaires ou findings d'audit soulignant des risques additionnels ; et développements personnalisés introduisant de nouvelles transactions Z ou apps Fiori personnalisées.

Le processus de maintenance devrait avoir des propriétaires clairement définis. Qui est responsable de l'ajout de nouvelles règles ? Qui revoit les règles existantes ? Qui décide des changements de niveaux de risque ? Dans les programmes bien fonctionnels, c'est typiquement une propriété conjointe entre l'équipe GRC et les propriétaires de processus métier, avec des chemins d'escalade clairs en cas de désaccord.

Une pratique spécifique est la validation périodique de la matrice contre les données actuelles de conflits SoD. Si une règle ne produit jamais de conflit, signifie-t-elle qu'elle est effectivement obsolète ou que le mapping est incomplet ? Si une règle produit trop de conflits, est-elle définie trop largement ou reflète-t-elle un vrai problème systémique dans la conception des rôles ? Ces questions peuvent transformer la maintenance de la matrice en amélioration continue.

6.1 Workflow de demande d'accès avec vérifications SoD

Le premier point de défense dans le cycle de vie SoD est le processus de demande d'accès. Quand un utilisateur demande un nouvel accès (pour lui-même ou une autre personne), le système devrait vérifier cette demande contre la matrice SoD avant qu'elle ne soit accordée. Si la demande créerait un conflit, elle devrait être bloquée ou envoyée dans un workflow d'escalade.

Cette vérification préalable empêche l'accumulation de conflits à la source. C'est beaucoup plus efficace que les nettoyages réactifs où les conflits ne sont identifiés qu'après leur création. La discipline organisationnelle de faire passer toutes les demandes d'accès par un workflow contrôlé est une condition fondamentale pour cela.

En pratique, cela nécessite l'engagement des managers métier qui ont typiquement un rôle d'approbation dans les workflows. Si la demande montre un conflit potentiel, le système devrait fournir au manager des informations métier claires sur le risque et les solutions possibles : modifier l'accès proposé, ajouter un contrôle compensatoire, escalader à un approbateur de niveau supérieur ou refuser la demande.

La pratique efficace est que les informations workflow pour les managers sont présentées de manière à être significatives. Au lieu d'une liste technique d'objets d'autorisation, le manager devrait voir : 'Cet accès représenterait un conflit avec l'accès actuel de l'utilisateur, parce qu'il pourrait à la fois créer des fournisseurs et approuver les paiements. C'est un risque critique parce que...' Cette traduction métier est ce qui amène les managers à prendre des décisions éclairées.

6.2 Revues périodiques

Malgré la meilleure discipline de workflow, des conflits SoD s'accumuleront au fil du temps. Les managers peuvent négliger des risques pendant le bruit des approbations de routine. Les employés peuvent changer de rôle sans que les anciennes autorisations soient retirées. Les processus métier peuvent changer, rendant les combinaisons précédemment acceptées maintenant problématiques. Pour ces raisons, les revues périodiques sont nécessaires.

Une revue périodique efficace a plusieurs caractéristiques. Premièrement, elle est bien définie. Il est clair quelle population est examinée, qui est l'examinateur, quelles informations leur sont présentées et quelles actions ils peuvent effectuer (approuver, refuser, accepter avec mitigation). Deuxièmement, elle est focalisée sur les risques. L'attention des examinateurs est concentrée sur les domaines à plus haut risque, pas distribuée uniformément sur toutes les autorisations.

Troisièmement, elle est continue, pas un mégaprojet annuel. Au lieu d'une revue annuelle de toutes les autorisations en un exercice de trois semaines, les revues peuvent être distribuées sur l'année - par exemple un trimestre par domaine métier, ou des rolling reviews continues avec des échantillons plus petits. Cela réduit la charge de travail de pointe et conduit à une plus grande attention par revue.

Quatrièmement, elle est connectée au processus de remédiation. Si un manager refuse un accès dans la revue, le système devrait automatiquement déclencher un workflow de remédiation pour supprimer cet accès. Si le manager accepte l'accès mais applique une mitigation, cette mitigation devrait être ajoutée au registre de mitigations. Ces connexions sont ce qui rend les revues vraiment actionnables.

6.3 Contrôles compensatoires

Tous les conflits SoD ne peuvent pas être complètement éliminés par des ajustements de rôles. Il y a des scénarios métier où la séparation des tâches n'est pas pratique - par exemple dans une petite équipe où une personne joue plusieurs rôles. Dans ces cas, les contrôles compensatoires sont la réponse.

Un contrôle compensatoire est un contrôle secondaire qui mitigue le risque lié à un conflit SoD. Les exemples incluent : revues détaillées d'audit trail pour les transactions affectées ; approbation obligatoire à quatre yeux pour certaines actions ; rapprochements métier périodiques qui identifient les anomalies ; ou reporting sept-pour-sept à des managers de niveau supérieur.

L'efficacité d'un contrôle compensatoire dépend de sa conception et son exécution correctes. Un contrôle mal conçu - par exemple une 'revue de rapports' que personne ne lit réellement - offre l'illusion de protection sans mitigation de risque réelle. Un contrôle bien conçu a un propriétaire clair, une exécution régulière, des preuves documentées et des vérifications périodiques d'efficacité.

Le plus grand piège dans la gestion des contrôles compensatoires est l'accumulation. Si chaque conflit non résolu ajoute un contrôle compensatoire, la liste peut croître à des centaines d'entrées, chacune nécessitant ses propres propriétaires, fréquence d'exécution et vérifications d'efficacité. Pour cette raison, l'ajout d'un contrôle compensatoire devrait être l'exception, pas la solution par défaut. Le premier choix devrait toujours être la résolution du rôle. Un contrôle compensatoire devrait être ajouté quand la résolution n'est pas pratique et que la mitigation du risque nécessite une action métier réelle.

6.4 Accès d'urgence et gestion des privilèges

Une classe spécifique d'accès qui nécessite un traitement spécial est l'accès d'urgence - la possibilité d'obtenir temporairement des accès privilégiés pour résoudre des urgences opérationnelles. Les exemples classiques incluent la résolution d'un job échoué en production, la résolution d'un problème métier critique en dehors des heures de bureau, ou le support d'urgence pendant une panne système.

L'accès d'urgence est une tension inhérente dans le programme SoD. D'un côté, c'est une nécessité métier - il y aura des urgences, et l'entreprise a besoin d'une solution rapide. De l'autre côté, l'accès privilégié est par définition à haut risque et devrait être strictement contrôlé. Comment résoudre cette tension ?

La pratique standard est l'implémentation d'un mécanisme 'Firefighter' avec trois composants principaux. Premièrement, un pool prédéfini d'IDs Firefighter avec accès privilégié qui sont pré-configurés et non attribués aux utilisateurs standards. Deuxièmement, un workflow structuré demande-approbation par lequel un utilisateur peut demander temporairement une connexion ID Firefighter, avec justification métier documentée. Troisièmement, un logging complet et revue des actions effectuées pendant la session Firefighter.

L'efficacité de ce mécanisme dépend de la discipline du processus de revue. Si personne ne revoit les logs Firefighter, l'accès privilégié est effectivement exploité sans contrôle. Les programmes efficaces ont des examinateurs désignés (typiquement propriétaires de processus métier ou équipe GRC) qui, dans une période clairement définie (typiquement quelques jours) après la session Firefighter, revoient les actions effectuées, confirment qu'elles correspondaient à la justification métier prévue, et signalent toutes anomalies.

7.1 Autorisations critiques et fonctions sensibles

Au-delà de la SoD classique qui compare deux fonctions ou plus, il y a une classe d'autorisations qui, indépendamment des combinaisons, sont si critiques que leur possession nécessite un contrôle strict. Celles-ci sont typiquement appelées 'autorisations critiques' ou 'Critical Authorizations'.

Les exemples incluent : autorisations SAP qui peuvent modifier le modèle d'autorisation lui-même (PFCG, SU01) ; autorisations qui permettent le customizing en production (SE16N avec accès en écriture, SM30) ; autorisations qui peuvent modifier directement les données maîtres (maintenance des tables avec accès en écriture) ; autorisations qui fournissent un accès direct à la base de données (S_TABU_DIS avec accès en écriture dans les tables sensibles) ; et autorisations qui peuvent contourner les contrôles transactionnels (autorisations Debug, autorisations RFC).

Le contrôle de ces autorisations est souvent plus strict que la SoD classique. Elles peuvent n'être disponibles que pour des groupes d'utilisateurs très limités, elles nécessitent souvent une approbation personnelle du senior management et leur utilisation est souvent surveillée au niveau de la session. Dans SAP GRC AC et outils similaires, elles sont typiquement gérées comme une catégorie séparée de conflits SoD (avec le terme 'Critical Action Conflicts').

Une question importante dans S/4HANA est l'identification d'apps Fiori critiques. Les templates SAP standards incluent des listes de T-codes critiques, mais celles-ci ne sont souvent pas traduites en apps Fiori équivalentes. Les organisations doivent construire leur propre liste d'apps Fiori critiques en analysant les fonctions sous-jacentes que ces apps exécutent.

7.2 Transactions Z et développement personnalisé

Les transactions Z sont des développements personnalisés typiquement nommés avec le préfixe Z- ou Y- pour les distinguer des fonctionnalités SAP standards. Elles sont créées pour une variété de buts : ajustements à des exigences métier spécifiques, intégration avec d'autres systèmes, exigences réglementaires locales et parfois comme workaround pour les limites standards.

Du point de vue SoD, les transactions Z sont souvent un angle mort. La plupart des templates SoD standards se concentrent sur les transactions SAP standards, sans couvrir les transactions Z personnalisées. Mais les transactions Z peuvent avoir la même ou une plus grande capacité métier - une transaction Z mal conçue peut par exemple contourner les objets d'autorisation SAP standards ou combiner plusieurs fonctions métier qui devraient être séparées.

La best practice est l'inventaire régulier de toutes les transactions Z et leur classification dans le mapping SoD. Pour chaque transaction Z, les questions suivantes devraient être répondues : Quelle fonction métier exécute-t-elle ? Quels objets d'autorisation SAP standards vérifie-t-elle ? Quelles Risk Functions dans la matrice SoD devrait-elle représenter ? Cette analyse nécessite la collaboration entre l'équipe GRC et les équipes de développement ABAP et fonctionnelles.

Une question similaire est le développement d'apps Fiori personnalisées. S/4HANA permet la création d'apps Fiori personnalisées basées sur des services OData personnalisés. Ces apps peuvent être très puissantes, mais elles nécessitent la même analyse que les apps standards - quelle fonction métier elles exécutent et comment elles devraient être classifiées dans la matrice SoD.

7.3 Connexions RFC et comptes de service

RFC (Remote Function Call) est un mécanisme que SAP utilise pour la communication entre systèmes - entre systèmes SAP, entre SAP et applications externes, ou entre composants SAP. Les connexions RFC utilisent typiquement des comptes de service (utilisateurs techniques) qui ont des autorisations spéciales pour permettre la communication.

Les comptes de service sont un défi de sécurité SoD pour plusieurs raisons. Premièrement, ils ont souvent des autorisations très larges - parfois SAP_ALL ou des profils similaires - pour s'assurer que l'intégration n'échoue pas en raison de problèmes d'autorisation. Deuxièmement, leurs mots de passe sont rarement changés et peuvent être connus de plusieurs employés. Troisièmement, ils ne sont pas couverts dans les analyses SoD standard orientées utilisateur, parce qu'ils ne sont pas des utilisateurs 'normaux'.

Les best practices pour les comptes de service incluent : configuration des comptes comme type d'utilisateur 'System' ou 'Service' pour empêcher les connexions humaines ; restriction des autorisations RFC uniquement aux fonctions requises pour l'intégration, au lieu d'utiliser SAP_ALL ; rotation régulière des mots de passe ou encore mieux, passage à l'authentification basée sur certificat ; et extension de l'analyse SoD pour inclure les comptes de service comme population séparée.

Les autorisations RFC elles-mêmes sont aussi une composante SoD. La possibilité d'autoriser des appels RFC (objets d'autorisation S_RFC, S_RFCACL) peut être utilisée pour exécuter des fonctions depuis un système externe en contournant les autorisations originales de l'utilisateur. Un contrôle strict des autorisations RFC fait partie d'un bon programme SoD.

8.1 Le modèle de maturité à cinq niveaux

Nous définissons un modèle de maturité à cinq niveaux pour les programmes SoD : Initial (Niveau 1), Compliance-Driven (Niveau 2), Structuré (Niveau 3), Intégré (Niveau 4) et Optimisé (Niveau 5). Chaque niveau a des caractéristiques distinctives dans quatre dimensions : Gouvernance, Processus, Technologie et Culture.

Niveau 1 - Initial : Il n'y a pas de programme SoD formel. Il n'y a pas de matrice SoD documentée ou elle est obsolète et inutilisée. Les demandes d'accès sont gérées ad-hoc sans approbation structurée. Les revues périodiques ne sont pas effectuées ou ne sont effectuées qu'en réaction aux findings d'audit. Les risques SoD sont gérés par l'équipe IT, sans engagement métier.

Niveau 2 - Compliance-Driven : Il y a une matrice SoD maintenue principalement à des fins de compliance. Les revues périodiques se produisent annuellement, typiquement avant les audits externes. Il y a un processus formel d'approbation de demande d'accès, mais il est principalement orienté vers le traitement des demandes, pas la gestion des risques. L'équipe GRC est petite, et la responsabilité est principalement avec l'IT.

Niveau 3 - Structuré : Il y a un programme SoD formel avec des rôles et responsabilités définis. La matrice SoD est bien définie et régulièrement maintenue. Les outils GRC sont utilisés pour l'analyse des risques et la gestion des workflows. Les revues périodiques sont effectuées trimestriellement ou plus fréquemment. Les managers métier sont impliqués dans le processus d'approbation et comprennent leur responsabilité pour les risques d'accès.

Niveau 4 - Intégré : La SoD est intégrée dans les processus métier. La matrice SoD évolue continuellement basée sur des modèles de risque réels. Il y a une forte propriété métier des risques. Les demandes d'accès incluent des évaluations de risque intégrées présentées en langage métier. Les revues périodiques sont continues et focalisées sur les risques. Les tendances et modèles sont suivis dans le temps et intégrés dans les conversations stratégiques.

Niveau 5 - Optimisé : Le programme SoD est un outil stratégique pour l'entreprise. Les insights de risque du programme SoD influencent les conceptions des processus métier. Il y a une forte connexion entre la SoD et d'autres disciplines GRC (risque opérationnel, compliance, audit interne). Des analyses avancées comme la détection d'anomalies basée sur l'IA sont utilisées pour identifier de nouveaux risques. La maturité SoD est considérée comme un avantage concurrentiel.

8.2 Comment évaluer la maturité

L'évaluation de la maturité devrait se faire sur toutes les quatre dimensions : Gouvernance, Processus, Technologie et Culture. Une erreur commune est de se concentrer uniquement sur la dimension technique - si l'organisation a implémenté SAP GRC AC, vous croyez qu'elle est au Niveau 4 ou 5. Mais la technologie elle-même n'est qu'une des dimensions.

L'évaluation de la Gouvernance inclut des questions comme : Y a-t-il un propriétaire formel pour le programme SoD ? Y a-t-il un forum de gouvernance qui supervise le programme ? Les rôles et responsabilités sont-ils clairement définis ? Comment le programme est-il connecté dans la hiérarchie organisationnelle ?

L'évaluation des Processus inclut des questions comme : Quels processus sont définis (demandes d'accès, revues périodiques, traitement des conflits) ? À quelle fréquence sont-ils exécutés ? Comment les exceptions sont-elles traitées ? Comment les résultats sont-ils mesurés et rapportés ?

L'évaluation de la Technologie inclut des questions comme : Quels outils GRC sont utilisés ? Quelle est la largeur de leur couverture sur le portefeuille applicatif ? Quelle est leur intégration avec d'autres systèmes métier ? Quel est le niveau d'automatisation des processus clés ?

L'évaluation de la Culture inclut des questions comme : Comment les managers métier comprennent-ils les risques SoD ? Quelle importance le senior management accorde-t-il au programme ? Quelle est la sensibilisation parmi les employés normaux ? Comment l'organisation réagit-elle quand des conflits ou risques sont identifiés ?

Répondre à ces questions peut se faire via des ateliers d'auto-évaluation, interviews d'employés, revue de documents et analyse de performance métier. Le résultat est une évaluation honnête de l'état actuel qui sert de base pour la planification d'amélioration.

8.3 Le chemin vers la maturité

La transition entre les niveaux de maturité ne se produit pas du jour au lendemain. Typiquement, la transition d'un niveau au suivant nécessite 12-24 mois d'effort focalisé avec un soutien soutenu du senior management. Les tentatives de sauter plusieurs niveaux simultanément échouent généralement.

La transition du Niveau 1 au Niveau 2 nécessite principalement l'introduction de structures formelles : création d'une matrice SoD documentée, définition de processus formels de demande d'accès, introduction de revues annuelles. Cela est souvent motivé par des findings d'audit ou exigences réglementaires.

La transition du Niveau 2 au Niveau 3 nécessite une structuration plus profonde : implémentation d'un outil GRC, extension de la fréquence des revues périodiques, engagement des managers métier dans le processus d'approbation. Cela nécessite souvent un investissement dans des ressources d'équipe GRC dédiée.

La transition du Niveau 3 au Niveau 4 nécessite un changement fondamental dans la manière dont le programme est perçu - d'une activité technique à une discipline métier. Cela nécessite un changement culturel, un engagement intensif de la direction métier et un recadrage du programme en langage métier.

La transition du Niveau 4 au Niveau 5 est la plus exigeante et implique l'intégration du programme dans la stratégie métier plus large. C'est un niveau que peu d'organisations atteignent, et typiquement nécessite plusieurs années de maturité soutenue au Niveau 4 avant cette transition.

9.1 Ce qui fonctionne

Commencez par les risques les plus élevés. Si le programme est nouveau, n'essayez pas de traiter tous les risques en même temps. Concentrez-vous sur les conflits critiques - typiquement les risques d'argent direct et de fraude. Une fois ceux-ci sous contrôle, étendez progressivement aux risques moyens puis aux moins élevés.

Engagez la direction métier dès le début. La SoD n'est pas une discipline technique - c'est une discipline métier. Si le programme est perçu comme technique, il sera difficile d'obtenir l'engagement et les ressources nécessaires. Cadrez le programme en langage métier : gestion des risques, prévention des pertes, conformité réglementaire.

Investissez dans la traduction des règles de risque en langage métier. Une règle SoD présentée en langage technique est sans signification pour les managers métier. Quand vous présentez un conflit pour résolution, dites : 'Nous avons constaté que [utilisateur] peut à la fois créer des comptes fournisseurs et approuver les paiements. C'est un risque parce que [conséquence métier concrète]. Nous recommandons [action concrète].'

Construisez le programme itérativement. N'essayez pas de concevoir le programme parfait dès le début. Commencez avec une version simple mais fonctionnelle, collectez l'expérience, identifiez les problèmes et améliorez-les. L'amélioration itérative est plus efficace que d'essayer de concevoir la solution parfaite à la première étape.

Concentrez-vous sur les causes profondes, pas sur les symptômes. Si les mêmes conflits réapparaissent à plusieurs reprises, il y a un problème systémique dans la conception des rôles ou le processus métier. Traitez la cause profonde, pas seulement les symptômes. Cela nécessite souvent des conversations métier plus profondes mais est beaucoup plus efficace à long terme.

9.2 Ce qui va mal

Dépendance excessive aux templates. Les templates SoD standards peuvent être un bon point de départ, mais ils ne reflètent pas les risques spécifiques de votre organisation. Si la matrice est adoptée du template sans intégrer les spécificités organisationnelles, elle identifiera des conflits non pertinents et manquera des risques réels.

Mitigations comme solution par défaut. Si la réponse standard au conflit est 'ajouter un contrôle compensatoire', le registre de mitigations croît hors de contrôle et les résolutions réelles ne sont jamais traitées. Les mitigations devraient être l'exception, pas la norme.

Reporting en langage technique au management. Si vous rapportez au senior management des métriques techniques (nombre de conflits par système, nombre de conflits résolus), le programme est perçu comme une activité technique. Rapportez en langage métier : quels risques métier existent, lesquels ont été réduits, quels événements métier ont conduit à des changements.

Négligence des développements personnalisés. Les transactions Z et apps Fiori personnalisées sont des sources de risque fréquentes négligées dans les analyses SoD standard. Intégrez des vérifications régulières des développements personnalisés dans le processus de maintenance SoD.

Traitement de la migration comme projet IT pur. Les migrations S/4HANA sont une opportunité significative pour revoir le modèle de rôles et le rendre SoD-conforme. Si la migration est effectuée comme un projet IT pur, sans implication SoD, vous aurez probablement à la fin un modèle reflétant les anciens problèmes SoD.

10.1 L'impact de l'IA

L'intelligence artificielle - à la fois sous forme de modèles classiques de machine learning et sous forme d'IA générative - change l'image GRC de plusieurs manières. Premièrement, l'IA peut être utilisée pour améliorer l'analyse SoD. Les modèles de détection d'anomalies peuvent identifier des modèles d'autorisation inhabituels que les examinateurs humains pourraient manquer. Les modèles prédictifs peuvent identifier quels utilisateurs sont les plus susceptibles de créer des conflits à l'avenir.

Deuxièmement, l'IA améliore l'évaluation des risques. Une matrice de risques traditionnelle évalue les risques basés sur la combinaison d'autorisations, mais ne considère pas le contexte métier - combien de transactions l'utilisateur exécute, avec quelles valeurs, à quels jours et heures. Les modèles IA peuvent intégrer ce contexte et générer un score de risque beaucoup plus précis.

Troisièmement, l'IA change la réalité métier que nous devons protéger. Les agents autonomes - systèmes IA qui prennent des décisions métier sans intervention humaine - deviendront plus significatifs dans les années à venir. Ces agents nécessitent leurs propres autorisations, et leurs actions doivent être évaluées du point de vue SoD. Que signifie 'séparation des tâches' quand 'l'exécuteur de fonction' est un modèle IA ? Comment surveillons-nous le comportement IA ? Ce sont des questions auxquelles les programmes SoD devront répondre dans les années à venir.

10.2 Cloud et SaaS

La transition vers le cloud change l'image SoD de plusieurs manières. Premièrement, le portefeuille applicatif s'élargit. Une organisation moderne peut utiliser SAP S/4HANA Cloud, Workday, Salesforce, ServiceNow, Microsoft 365, Zoom, Slack et des dizaines d'autres applications cloud. Chacune de ces applications a son propre modèle d'autorisation et peut représenter des risques SoD.

Deuxièmement, la vitesse du changement s'accélère. Les applications cloud reçoivent fréquemment des mises à jour - parfois mensuellement ou plus souvent. Ces mises à jour peuvent introduire de nouvelles fonctionnalités, nouvelles autorisations et potentiellement de nouveaux risques SoD. Les programmes SoD doivent être assez rapides pour suivre.

Troisièmement, le cloud change le modèle traditionnel de contrôle interne. Dans le modèle on-premise, l'organisation a le contrôle complet sur la configuration de l'application. Dans le modèle SaaS, la configuration est en partie contrôlée par le fournisseur, et l'organisation ne peut pas toujours la modifier selon ses préférences. Cela nécessite une refonte de certaines hypothèses de contrôle.

Enfin, le cloud ouvre de nouveaux modèles de gestion d'identité - Identity Federation, Single Sign-On, plateformes SaaS connectées avec accès privilégié. Ceux-ci peuvent faciliter les efforts SoD (en centralisant les identités et fournissant une source unique de données) ou les compliquer (en étendant la complexité du modèle d'autorisation). Comment ces outils sont déployés sera la clé de l'efficacité du programme SoD dans le monde cloud.

10.3 Évolution réglementaire

Le paysage réglementaire continue d'évoluer vers des exigences plus strictes pour les contrôles d'accès et la SoD. Sarbanes-Oxley, qui domine aux États-Unis depuis 2002, a évolué de manière cohérente contre la surveillance continue de la SEC et du PCAOB. L'Europe a son propre framework - les directives comptables, DORA (Digital Operational Resilience Act) pour le secteur financier, et la Corporate Sustainability Reporting Directive à venir.

Une nouvelle tendance est l'attention réglementaire portée aux systèmes IA - l'EU AI Act, initiatives similaires aux États-Unis et autres juridictions. Celles-ci auront des implications sur la SoD, particulièrement pour les agents autonomes et processus métier pilotés par IA. Quels contrôles doivent être en place pour un modèle IA qui prend des décisions financières ? Comment surveillez-vous son comportement ? Ce sont des questions qui se formaliseront dans les années à venir.

La protection des données et la confidentialité - GDPR, CCPA et similaires - ont aussi des implications pour la SoD. Qui a accès aux données personnelles est une question SoD. La séparation entre ceux qui gèrent les données et ceux qui les analysent est une forme de SoD. Les programmes doivent intégrer ces dimensions de confidentialité au lieu de les traiter séparément.

Enfin, nous observons une convergence globale des exigences. Bien que les frameworks réglementaires spécifiques varient, les attentes sous-jacentes se ressemblent de plus en plus : contrôles documentés, preuves de leur efficacité, reporting périodique et réponse rapide aux problèmes identifiés. Les organisations qui construisent leurs programmes SoD pour répondre à ces exigences communes sont en bonne position pour la prochaine vague de changements réglementaires.

10.4 Ce qui vient ensuite

En regardant vers les années à venir, nous voyons plusieurs tendances clés qui façonneront les programmes SoD. Premièrement, analyse de risques continue au lieu de revues périodiques. Au lieu d'une revue annuelle ou trimestrielle, les risques seront continuellement réévalués basés sur les données comportementales réelles et changements de configuration.

Deuxièmement, plateformes GRC intégrées. Au lieu d'outils séparés pour SoD, risque opérationnel, compliance et audit interne, nous verrons une consolidation dans des plateformes unifiées qui fournissent une vue holistique du risque. Cela créera de nouvelles possibilités de cross-correlation et insights plus profonds.

Troisièmement, managers métier comme gestionnaires de risque primaires. Le déplacement de la responsabilité des équipes GRC centrales aux managers métier s'accélérera. Les outils seront conçus pour rendre les risques accessibles aux managers sans formation GRC formelle, en langage métier.

Quatrièmement, IA comme co-pilote pour le GRC. Les modèles IA augmenteront le travail des analystes GRC en automatisant les analyses routinières, soulignant les anomalies et même suggérant des résolutions. Cela libérera les équipes GRC pour se concentrer sur les problèmes stratégiques et complexes.

Cinquièmement, un test de maturité de l'industrie elle-même. Nous croyons que les prochaines années apporteront une large réflexion sur ce qui fonctionne réellement dans les programmes SoD et ce qui ne fonctionne pas. Les organisations en tête de cette réflexion seront capables de construire des programmes qui livrent une valeur métier réelle au lieu de simplement remplir les obligations d'audit.

Au final, la SoD ne concerne pas la technologie ou la compliance. Elle concerne la construction de la confiance métier - la confiance que les actions entreprises au nom de l'entreprise sont effectuées par des personnes autorisées pour les bonnes raisons avec une supervision appropriée. Bien que les moyens changent, l'objectif reste le même. Ceux qui le comprennent et construisent leurs programmes autour de cet objectif rempliront à la fois les exigences réglementaires et créeront une valeur réelle pour leurs organisations.