Publicité
ERP IMPLEMENTATION
🇬🇧 Read in English →

Pathlock, Saviynt, SAP GRC : quel outil de SoD choisir pour votre ERP en 2026 ?

Comparatif des outils SoD pour ERP : SAP GRC et Cloud IAG, Pathlock, Saviynt et contrôles natifs. Critères, tableau et choix par profil d'entreprise.

Pathlock, Saviynt, SAP GRC : quel outil de SoD choisir pour votre ERP en 2026 ?

Vous avez une matrice de séparation des tâches (SoD, Segregation of Duties), des rôles ERP documentés et une revue annuelle des droits. Pourtant, chaque audit remonte les mêmes écarts : cumuls de rôles apparus entre deux revues, comptes d’urgence jamais désactivés, exceptions non tracées. À un certain stade, le problème n’est plus la méthode, c’est l’outillage.

Les articles de ce blog expliquent la méthode (gouvernance des habilitations ERP, de l’arrivée au départ, 12 contrôles SoD avant l’audit). Celui-ci tranche sur l’outil : SAP GRC Access Control et SAP Cloud Identity Access Governance, Pathlock, Saviynt, ou les contrôles natifs de votre ERP.

Les caractéristiques ci-dessous reposent sur les pages publiques des éditeurs et sur des sources secondaires citées en ligne, consultées le 28 octobre 2026. Les éditeurs font évoluer leurs offres : vérifiez chaque point avec eux avant de décider. Aucun prix n’est publié ici, ces outils se vendent sur devis.

Quand la matrice Excel ne suffit plus

Un tableur suffit tant que trois conditions tiennent : peu d’utilisateurs à privilèges, un seul ERP, une revue annuelle sans surprise. Il casse dès que l’une d’elles saute. Voici les signaux qui doivent vous alerter, par ordre de gravité croissante :

  • Le calcul des conflits devient manuel. Croiser à la main des rôles composites et des transactions ou privilèges réels prend des jours, et le résultat est périmé à la prochaine mutation.
  • L’audit exige une preuve continue. Si votre commissaire aux comptes ou votre audit interne demande qui a approuvé quel cumul, quand et avec quel contrôle compensatoire, un fichier partagé n’est pas une preuve fiable.
  • Les accès d’urgence sont gérés par mail. Un compte « super utilisateur » prêté sans journal d’activité relu est l’une des premières observations des auditeurs.
  • Vous avez plusieurs systèmes. ERP, paie, achats, CRM : une SoD qui s’arrête aux frontières d’un seul système laisse passer les conflits transverses.
  • Vous êtes soumis à SOX ou à une exigence équivalente. Voir aussi notre article sur la conformité SOX dans l’ERP si votre groupe est coté aux États-Unis ou filiale d’un tel groupe.

Il n’existe pas de seuil universel d’utilisateurs au-delà duquel l’outil s’impose. Le bon indicateur est le temps que votre équipe passe à produire la preuve, comparé au risque de ne pas la produire.

Critères de comparaison

Sept critères ont réellement départagé les outils dans les projets que nous observons :

  1. Couverture ERP : connecteurs natifs pour vos systèmes, profondeur d’analyse (transactions, objets d’autorisation, privilèges fins) et non simple lecture de rôles.
  2. Analyse de risque : bibliothèque de règles SoD fournie, capacité à les adapter, simulation avant attribution d’un rôle.
  3. Remédiation : propositions de correction, contrôles compensatoires documentés, gestion des exceptions avec date d’expiration.
  4. Accès d’urgence (firefighter) : élévation temporaire, journalisation, revue du journal par un tiers.
  5. Intégration IGA : lien avec votre annuaire et votre outil de gestion des identités (arrivées, mutations, départs).
  6. Modèle de licence : par utilisateur, par système, par module, hébergement cloud ou sur site.
  7. Effort de mise en oeuvre : qualité de vos rôles de départ, ressources internes, recours à un intégrateur.

Les 4 candidats

SAP GRC Access Control et SAP Cloud Identity Access Governance

Ce que l’éditeur annonce. SAP présente SAP Access Control autour de cinq fonctions : analyse du risque d’accès, gestion des demandes d’accès, gestion des rôles métier, gestion des accès d’urgence et revue périodique des accès utilisateurs. Le périmètre couvre SAP ECC, SAP S/4HANA et des applications non SAP intégrées. SAP Cloud Identity Access Governance en est la déclinaison cloud, présentée comme un point d’entrée rapide à déployer (SAPinsider).

Forces.

  • Profondeur d’analyse sur les autorisations SAP, là où les outils tiers dépendent de la qualité de leurs connecteurs.
  • Gestion d’urgence (accès « firefighter ») intégrée, très connue des auditeurs habitués à SAP.
  • Cohérence avec la feuille de route SAP et avec les autres produits de la gamme.

Limites.

  • Pertinence plus faible hors écosystème SAP : l’intégration d’applications non SAP demande du travail.
  • La version sur site implique une infrastructure et une expertise spécifiques ; la trajectoire entre l’édition sur site et l’édition cloud doit être clarifiée avec SAP selon votre calendrier de migration S/4HANA.
  • Mise en oeuvre sérieuse, avec un volet de conception de rôles qui ne se contourne pas.

Pertinence cible. ETI très majoritairement SAP, déjà engagée dans un programme S/4HANA, avec une équipe autorisations SAP en interne ou chez son intégrateur. Le choix est moins évident si votre trajectoire SAP est incertaine ou si l’essentiel de vos risques se situe dans des applications non SAP.

Pathlock

Ce que l’éditeur annonce. Pathlock positionne sa plateforme d’orchestration des accès sur la SoD interapplicative, avec un seul jeu de règles appliqué à plusieurs applications. Sa documentation cite SAP (dont Ariba et SuccessFactors), Oracle (E-Business Suite, Fusion Cloud), Microsoft Dynamics 365, PeopleSoft, Workday et JD Edwards (Pathlock). Les capacités annoncées incluent l’analyse du risque avant attribution, la certification des accès, l’accès d’urgence avec workflow et la gestion de rôles (Pathlock, accès d’orchestration). Pathlock propose aussi une offre dédiée à Oracle E-Business Suite et Fusion Cloud ERP (Pathlock).

Forces.

  • Spécialisation GRC et SoD : le produit est centré sur ce besoin, pas sur l’identité en général.
  • Large couverture d’ERP et de SaaS métier, utile pour un parc hétérogène.
  • Un référentiel de règles commun, qui évite de maintenir une matrice par système.

Limites.

  • Ce n’est pas un IGA complet : la gestion du cycle de vie des identités reste à votre charge ou à celle d’un autre outil.
  • La profondeur réelle varie selon l’application ; demandez une preuve de concept sur vos propres rôles.

Pertinence cible. Entreprise multi-ERP (par exemple SAP plus Oracle ou Dynamics) qui veut une SoD unifiée sans refondre son IGA. Elle convient aussi aux équipes d’audit interne qui souhaitent maintenir un référentiel de règles unique, validé par les métiers, plutôt qu’une matrice par système. Elle convient moins si vous cherchez un outil unique pour tout le cycle de vie des identités.

Saviynt

Ce que l’éditeur annonce. La brique Application Access Governance de la plateforme Saviynt Enterprise Identity Cloud gère le risque SoD, la certification des accès et la conformité sur SAP, Oracle, Workday, Salesforce et d’autres applications. L’éditeur l’inscrit dans une plateforme plus large : gouvernance et administration des identités, gestion des accès privilégiés et gouvernance des accès tiers (KuppingerCole, Executive View ; ERP Research). La SoD interapplicative est présentée comme une capacité dédiée, en lien étroit avec les initiatives IGA.

Forces.

  • Une seule plateforme pour l’identité et la gouvernance des accès applicatifs : les arrivées, mutations et départs alimentent directement les contrôles SoD.
  • Cohérent avec une stratégie cloud et avec la gouvernance de nombreuses applications au-delà de l’ERP.
  • Accès d’urgence traité dans le périmètre de la plateforme.

Limites.

  • Le périmètre large est aussi un risque de projet : mieux vaut cadrer d’abord le sous-ensemble ERP.
  • Si votre besoin se limite à la SoD ERP, vous payez peut-être pour des fonctions IGA que vous n’utiliserez pas tout de suite.

Pertinence cible. Groupe qui lance ou refond son programme IGA et veut y inclure la SoD ERP dès le départ, avec une gouvernance des accès au-delà de l’ERP (SaaS, infrastructure, tiers). Elle convient moins à une entreprise dont le seul besoin est un contrôle SoD sur un ERP unique, où un outil spécialisé ou le natif sera plus simple à cadrer.

Option native : Oracle, Dynamics 365, Odoo

Avant d’acheter, regardez ce que votre ERP sait déjà faire.

Dynamics 365 Finance. Microsoft documente des règles de séparation des tâches : pour chaque règle, l’administrateur définit les deux devoirs en conflit, une sévérité, une description du risque et des consignes de mitigation. L’affectation d’un rôle conflictuel déclenche un message d’erreur qui oblige à refuser ou à autoriser explicitement (Microsoft Learn). La validation des rôles et des affectations est une étape distincte à lancer vous-même.

Odoo. Le modèle repose sur des groupes d’utilisateurs, des droits d’accès par modèle et des règles d’enregistrement qui restreignent les enregistrements visibles (documentation Odoo). Nous n’avons pas trouvé de moteur SoD natif équivalent à celui de Dynamics dans la documentation consultée : la SoD y relève de la conception des groupes et d’un contrôle de revue.

Oracle. Les applications Oracle proposent des rôles et des contrôles intégrés, mais l’analyse transverse des conflits est généralement traitée par des outils complémentaires, dont Pathlock propose une version dédiée (voir plus haut). Vérifiez avec Oracle le périmètre exact de votre licence.

Forces. Aucun coût de licence supplémentaire, déploiement rapide, cohérence avec les rôles de l’ERP. Limites. Pas de vision transverse, preuve d’audit à assembler vous-même, accès d’urgence souvent à compléter par des procédures. Pertinence cible. PME mono-ERP avec peu d’utilisateurs à privilèges.

Tableau comparatif synthétique

CritèreSAP Access Control / Cloud IAGPathlockSaviyntNatif (Dynamics, Odoo, Oracle)
Couverture ERPSAP en profondeur, non SAP par intégrationSAP, Oracle, Dynamics, Workday, JD Edwards, PeopleSoftSAP, Oracle, Workday, Salesforce et autresUn seul ERP
SoD interapplicativeLimitée hors SAPOui (argument central)OuiNon
Accès d’urgenceOuiOuiOui (plateforme)Variable, souvent à compléter
Intégration IGAVia écosystème SAPPartielle, à confirmerNative (même plateforme)Non
Modèle de licenceSur devisSur devisSur devisInclus dans l’ERP
Effort de mise en oeuvreÉlevéMoyen à élevéMoyen à élevéFaible

Lecture du tableau : les appréciations d’effort sont des évaluations de notre part à partir des documents des éditeurs, pas des mesures. Aucune n’a valeur d’engagement.

Recommandation par profil

ETI 100 % SAP. Partez de SAP Access Control ou de Cloud IAG. Choisissez l’édition selon votre calendrier S/4HANA et votre hébergement, et faites confirmer par SAP la trajectoire de l’édition sur site. Un outil tiers ne se justifie que si vous prévoyez d’ajouter d’autres systèmes.

Parc multi-ERP. Pathlock si votre besoin est la SoD, Saviynt si vous refondez aussi la gestion des identités. Dans les deux cas, imposez une preuve de concept sur vos rôles les plus complexes avant de signer.

PME Dynamics 365 ou Odoo. Commencez par le natif. Sur Dynamics 365, activez et validez les règles de SoD fournies. Sur Odoo, structurez les groupes et documentez une revue trimestrielle. N’achetez un outil que si l’audit ou le nombre de systèmes l’exige.

Groupe soumis à SOX. La preuve continue et l’accès d’urgence journalisé sont non négociables. Privilégiez l’outil le plus profond sur votre ERP principal, puis évaluez la couverture des systèmes périphériques. Impliquez l’audit interne et le commissaire aux comptes dans le choix : ce sont eux qui accepteront ou non les preuves.

Coût et déploiement

Aucun des trois éditeurs ne publie de grille tarifaire exploitable, et nous ne chiffrons pas leurs offres. Les postes de coût sont en revanche identifiables :

  • Licences ou abonnement, dont la métrique (utilisateurs, systèmes, modules) change fortement la facture selon votre taille.
  • Intégration et connecteurs, y compris les environnements de test.
  • Conception ou nettoyage des rôles, souvent le poste le plus sous-estimé.
  • Conduite du changement : formation des propriétaires de rôles et des approbateurs.
  • Exploitation : une personne ou une fraction d’équipe pour traiter alertes et exceptions.

Les délais dépendent presque entièrement de l’état de vos rôles, pas de l’outil. Une fourchette de plusieurs mois pour un premier périmètre est réaliste, à valider par devis et planning d’intégrateur. Demandez au moins deux devis détaillés, avec hypothèses de volumétrie.

Plan de déploiement en 3 phases

Phase 1 : assainir avant d’outiller. Inventoriez les rôles, supprimez les comptes dormants, retirez les rôles « passe-partout », validez la matrice SoD avec les métiers. Un outil appliqué à des rôles mal conçus ne produit que des milliers de faux conflits.

Phase 2 : périmètre pilote. Choisissez un processus à fort risque (achats vers paiement, par exemple) et un ERP. Chargez les règles, mesurez les conflits, traitez-les, mettez en place l’accès d’urgence avec revue du journal.

Phase 3 : extension et automatisation. Étendez aux autres processus et systèmes, branchez les demandes d’accès sur le workflow d’approbation, automatisez les revues périodiques et les rapports d’audit.

5 erreurs classiques à éviter

1. Acheter l’outil avant de nettoyer les rôles. Conséquence : des milliers de faux conflits, une équipe qui cesse de lire les alertes. Contre-mesure : terminer la phase 1 (inventaire, comptes dormants, rôles « passe-partout ») avant la signature.

2. Ne pas nommer de propriétaires de risques côté métier. Conséquence : les conflits restent sans arbitrage et l’IT décide seule de ce qui est acceptable. Contre-mesure : un responsable métier par processus, avec pouvoir d’accepter ou de refuser un cumul.

3. Accepter trop d’exceptions sans date d’expiration. Conséquence : la dérogation temporaire devient permanente et l’auditeur la retrouve d’une année sur l’autre. Contre-mesure : toute exception porte un contrôle compensatoire, un approbateur et une date de fin.

4. Sous-estimer l’exploitation après la mise en production. Conséquence : alertes non traitées, revues périodiques en retard. Contre-mesure : prévoir dès le devis une capacité d’exploitation (interne ou infogérée).

5. Choisir sur démonstration plutôt que sur preuve de concept. Conséquence : les écarts de couverture n’apparaissent qu’en projet. Contre-mesure : imposer à chaque éditeur un test sur vos rôles les plus complexes, avec critères de réussite écrits.

Pour aller plus loin

Pour cadrer votre choix, contactez DigitsLane : nous aidons à écrire le cahier des charges, à organiser la preuve de concept et à challenger les devis. Vous pouvez aussi télécharger notre grille d’évaluation ERP pour structurer votre comparaison.

Pour approfondir : gouvernance des habilitations ERP, de l’arrivée au départ, 12 contrôles SoD avant l’audit annuel et ERP et GRC : gouvernance, risques et conformité.