L’essentiel :
- Un conflit SoD survient lorsqu’un utilisateur cumule des droits permettant deux actions incompatibles dans un même processus (ex : créer un fournisseur ET valider un paiement).
- L’analyse doit aller au-delà des t-codes et descendre au niveau des objets d’autorisation SAP pour éliminer les faux positifs (40 à 60 % des conflits remontés avec une analyse t-code classique).
- Croiser droits théoriques et transactions réellement exécutées (logs SM20, STAD) permet de distinguer les risques actifs des risques dormants.
- Une revue annuelle ou semestrielle est insuffisante : les mouvements de personnel rendent les données obsolètes en quelques semaines.
- La démarche complète couvre 4 étapes : diagnostic préalable → construction de la matrice → analyse des accès → industrialisation.
- Chaque action corrective doit être tracée avec date, responsable et justification pour être défendable lors d’un audit
Qu’est-ce qu’un conflit SoD dans SAP ?
La Séparation des Tâches (SoD) est un principe de contrôle interne fondamental : aucun utilisateur ne devrait pouvoir initier et finaliser seul une opération sensible. Dans SAP, ce principe se traduit par des règles d’incompatibilité entre certaines transactions ou objets d’autorisation.
Lorsqu’un même utilisateur détient les droits lui permettant d’exécuter deux actions incompatibles, on parle de conflit SoD. Ce conflit peut être :
Théorique : l’utilisateur possède les droits nécessaires, mais ne les a pas exercés conjointement. Risque potentiel, non exploité à ce jour.
Avéré : l’utilisateur a effectivement réalisé les deux types d’opérations incompatibles. Risque actif, à traiter en priorité absolue.
Exemple concret : un utilisateur ayant accès à FK01 (création fournisseur) ET à F110 (validation paiement automatique) peut créer un fournisseur fictif et déclencher un virement en sa faveur sans aucun contrôle intermédiaire. C’est l’un des schémas de fraude les plus fréquents sur SAP.
Les 4 processus SAP les plus exposés aux risques SoD
Tous les processus SAP ne présentent pas le même niveau de risque.
Voici les domaines à couvrir en priorité, avec les exemples de conflits les plus courants :
| Processus | Exemple de conflit SoD | Criticité |
|---|---|---|
| Procure-to-Pay (P2P) | Création fournisseur (FK01) + validation paiement (F110) | Haute |
| Order-to-Cash (O2C) | Création client (FD01) + comptabilisation encaissement (F-28) | Haute |
| Record-to-Report (R2R) | Saisie d'écritures (FB01) + validation de clôture comptable | Moyenne |
| HCM / Ressources humaines | Création employé (PA40) + modification de salaire (PA30) | Haute |
Étape 1 — Construire une matrice SoD pertinente
La matrice SoD est le socle de toute la démarche. C’est elle qui définit quelles combinaisons de droits sont considérées comme incompatibles dans votre contexte. Une matrice générique téléchargée sur internet n’a aucune valeur opérationnelle si elle n’est pas adaptée à vos processus spécifiques.
Ce que doit contenir votre matrice : pour chaque règle SoD, préciser les transactions ou objets d’autorisation impliqués, le processus métier concerné, le niveau de criticité (Haute / Moyenne / Basse), la justification du risque, et le propriétaire de la règle côté métier.
⚠️ Erreur fréquente : une matrice validée uniquement par l’équipe IT sera systématiquement contestée lors d’un audit externe. Les propriétaires de processus (DAF, Responsable Achats, DRH…) doivent impérativement co-valider les règles qui concernent leur périmètre.
À quel niveau analyser les droits SAP ?
La grande majorité des outils d’analyse SoD travaillent au niveau des t-codes (codes transactions SAP). C’est insuffisant. Un même t-code peut être parfaitement inoffensif pour certaines valeurs de champs d’autorisation (société, centre de coût, activité…) et dangereux pour d’autres.
L’analyse au niveau des objets d’autorisation (ACTVT, BUKRS, KOSTL…) est le seul niveau qui permet d’éliminer réellement les faux positifs — qui représentent souvent entre 40 et 60 % des conflits remontés par une analyse t-code classique.
Étape 2 — Analyser les accès SoD dans SAP
Une fois la matrice construite, l’analyse des accès consiste à la croiser avec les droits effectivement attribués dans SAP. Voici les points de vigilance essentiels.
Filtrer le bon périmètre d’analyse.
Contrairement à ce qu’on pourrait penser, les comptes désactivés doivent être inclus dans l’analyse SoD. Si des conflits apparaissent sur des comptes inactifs, cela révèle que la procédure d’archivage est incomplète : les droits n’ont pas été retirés au moment de la désactivation. L’analyse SoD devient alors un outil de contrôle de l’archivage, permettant d’identifier les comptes à finaliser. La transaction SU01 permet de les repérer et de les traiter en conséquence.
Concernant les comptes techniques, la distinction est plus fine. Les comptes techniques de type « dialogue » — où une connexion interactive est possible — doivent être inclus dans l’analyse SoD, car un utilisateur peut s’y connecter directement et exploiter les droits associés. En revanche, les comptes de type « System » ou « Communication » (types S et B dans SAP), dont la connexion est strictement non interactive et automatisée, présentent un profil de risque différent et peuvent être traités séparément. Cette distinction permet d’éviter à la fois les angles morts et les faux positifs inutiles dans vos rapports.
Distinguer droits théoriques et usage réel.
Le croisement des habilitations avec les logs d’activité (SM20, STAD) permet d’identifier les conflits réellement exploités. Un utilisateur qui dispose de droits incompatibles mais n’en a pas utilisé un depuis 12 mois présente un risque d’une nature différente d’un utilisateur qui les exerce régulièrement. Cette distinction est déterminante pour prioriser les remédiations.
💡 Bonne pratique : avant d’implémenter toute remédiation, simulez son impact sur le périmètre d’autorisation. Une modification de rôle peut créer de nouveaux conflits si elle n’est pas testée en amont. SWAWE RISK intègre cette fonctionnalité de simulation préventive.
Étape 3 — Remédier et gouverner les risques identifiés
La remédiation SoD repose sur trois leviers principaux :
1. La suppression du conflit : retirer l’un des droits incompatibles à l’utilisateur. C’est la solution idéale, mais elle n’est pas toujours possible sans impacter l’activité opérationnelle.
2. La dérogation documentée & contrôle compensatoire : lorsque le conflit est structurellement inévitable, formaliser une dérogation approuvée avec un contrôle compensatoire (revue périodique par un tiers, alertes automatiques, journalisation renforcée). Cette dérogation doit être datée, signée et traçable.
3. La refonte des rôles SAP : dans certains cas, le conflit révèle une mauvaise conception du modèle de rôles. Une refonte partielle des rôles SAP (PFCG) peut résoudre plusieurs conflits simultanément de façon pérenne.
Quelle que soit l’approche retenue, chaque action corrective doit être tracée avec la date d’intervention, le responsable, la justification et le résultat constaté. C’est cette traçabilité qui rend votre démarche opposable à un auditeur.
Étape 4 — Industrialiser et automatiser la détection
Une analyse SoD ponctuelle, même bien menée, ne suffit pas. Les mouvements de personnel, les évolutions de rôles et les changements de processus créent en permanence de nouveaux conflits. La vraie maturité SoD, c’est la détection continue.
Les limites de l’approche manuelle sont bien connues : les extractions SUIM massives vers Excel génèrent des erreurs sur les grands volumes, les analyses prennent des jours, et un seul fichier corrompu peut invalider tout un audit.
Une solution de détection automatisée doit permettre de : analyser en continu sur l’ensemble du périmètre SAP (ECC, S/4HANA, BW…), déclencher automatiquement une vérification SoD à chaque modification de rôle, produire des rapports exploitables par les managers métiers sans intermédiaire IT, et conserver l’historique complet des analyses et remédiations.
Où en êtes-vous sur votre maturité SoD ?
Répondez à 19 questions (Oui / Partiel / Non) et obtenez en 5 minutes un score de maturité personnalisé avec vos priorités d'action concrètes.