Audit SAP SoD : comment résoudre 1 440 conflits avant l’audit SOX
Un audit SOX raté sur le volet accès SAP coûte bien plus qu’un projet de remédiation : réserve du commissaire aux comptes, perte de confiance des investisseurs, risque de déclassement. Sans compter le risque de fraude interne — un conflit SoD non détecté signifie qu’un seul utilisateur peut créer un fournisseur fictif ET valider le paiement.
Ce qui est en jeu
Un conflit de séparation des tâches dans SAP n’est pas un sujet technique — c’est un risque de fraude direct. Quand le même utilisateur peut créer un fournisseur (XK01), modifier un prix (ME12) et valider un paiement (F110), le contrôle interne n’existe plus. C’est la porte ouverte à des détournements qui peuvent passer inaperçus pendant des années.
Le problème tel qu’on le rencontre en mission
Un groupe de services financiers nous a contactés 4 mois avant son audit SOX annuel. Leur problème : 2 400 rôles SAP accumulés sur 12 ans de vie du système, jamais audités sérieusement. Ils savaient qu’il y avait des conflits de séparation des tâches (SoD), mais pas combien.
Un cabinet de conseil leur avait produit un rapport d’audit 6 mois plus tôt. Le rapport était excellent : 120 pages, cartographie des risques, recommandations structurées. Mais personne ne pouvait l’implémenter. Le cabinet n’avait pas de compétence SAP GRC Access Control et l’équipe interne n’avait pas les ressources.
C’est exactement le scénario que nous adressons : le rapport existe, les recommandations sont bonnes, mais personne n’exécute.
Notre intervention — 12 semaines
**Phase 1 (semaines 1-3) : cartographie.** Extraction et analyse complète des 2 400 rôles SAP. Identification de 1 440 conflits SoD sur les modules FI, CO, MM, SD. Classification par criticité : 340 critiques (accès création fournisseur + validation paiement), 680 élevés, 420 moyens.
**Phase 2 (semaines 4-7) : rationalisation.** Refonte de 60% des rôles. Pas de réécriture complète — c’est un piège classique qui prend 18 mois et coûte une fortune. Nous avons ciblé les 340 conflits critiques en priorité, puis cascadé les corrections sur les rôles dérivés.
**Phase 3 (semaines 8-10) : déploiement GRC Access Control.** Mise en production de SAP GRC 12.0 avec règles SoD configurées selon le référentiel du client, workflows de validation automatisés, et dashboard en temps réel.
**Phase 4 (semaines 11-12) : reporting SOX.** Configuration des rapports de conformité, test avec l’équipe audit interne, formation des key users. L’auditeur externe a reçu le dashboard GRC comme élément de preuve.
Résultats
• AVANT : 1 440 conflits SoD actifs — un utilisateur pouvait créer un fournisseur fictif ET valider son paiement sans aucun contrôle. APRÈS : 1 240 conflits résolus, les 42 restants sous contrôle compensatoire
• AVANT : zéro automatisation des contrôles — vérification manuelle par sondage une fois par an. APRÈS : 83% des contrôles automatisés, exécutés en continu
• AVANT : les risques critiques n’étaient même pas identifiés. APRÈS : 91% des risques critiques traités, dashboard visible en temps réel
• AVANT : audit SOX en danger — le commissaire aux comptes avait signalé des faiblesses l’année précédente. APRÈS : audit passé sans réserve
• Dashboard GRC opérationnel utilisé au quotidien par l’équipe conformité
Les pièges à éviter
**Piège 1 : vouloir tout refondre.** La réécriture complète de la matrice de rôles est le meilleur moyen de ne jamais terminer. Priorisez les conflits critiques, corrigez-les, puis élargissez.
**Piège 2 : séparer l’audit de l’implémentation.** Si le cabinet qui audite ne sait pas déployer GRC Access Control, vous aurez un rapport de plus et zéro résultat de plus.
**Piège 3 : ignorer les rôles de service.** Les comptes techniques (batch, interfaces, RFC) ont souvent des droits SAP_ALL ou des profils génériques. Ils sont invisibles dans les audits classiques mais représentent un risque majeur.
**Piège 4 : ne pas impliquer les métiers.** Un conflit SoD n’est pas un problème technique — c’est un risque métier. Le responsable comptable doit valider que la correction ne bloque pas ses processus.
