Votre ERP sait que Jean-Marc a passé une commande de 45 000 euros hier soir à 23 h 47. Il a enregistré la transaction, mis à jour le stock, déclenché la comptabilité. Ce qu’il ne sait pas : Jean-Marc valide lui-même ses propres commandes depuis six mois, car son responsable a quitté l’entreprise et personne n’a reconfiguré la matrice de droits. C’est un conflit SOD classique. Et c’est exactement la limite de l’ERP en matière de GRC.
La gouvernance, les risques et la conformité (GRC) constituent l’un des angles morts les plus coûteux des projets ERP. Les ETI investissent des centaines de milliers d’euros dans leur ERP, mais sous-estiment systématiquement ce qu’il ne fait pas nativement : cartographier les risques, produire un registre de conformité multiréglementaire, ou alerter le Risk Manager quand un pattern de transactions ressemble à une fraude.
Ce guide est destiné aux Risk Managers, Responsables Conformité, DSI et DAF d’ETI de 500 à 5 000 salariés qui doivent répondre aux exigences NIS2, CSRD, DORA ou aux audits commissaires aux comptes, et qui cherchent à structurer leur approche GRC sans dupliquer les données avec l’ERP.
L’essentiel en 30 secondes
- GRC = Gouvernance + Risques + Conformité : trois disciplines distinctes que l’ERP couvre partiellement, et non globalement.
- L’ERP est une couche de GRC essentielle (SOD, journaux, habilitations) mais insuffisante seule au-delà de 500 salariés ou de 3 entités.
- NIS2 (directive UE 2022/2555) et DORA (règlement UE 2022/2554) imposent une cartographie des risques formalisée que l’ERP ne produit pas seul.
- Les plateformes GRC dédiées (SAP GRC, ServiceNow, MetricStream) coûtent entre 50 000 et 300 000 euros par an selon la taille de l’entreprise.
- La fraude interne non détectée coûte en médiane 117 000 dollars par incident (ACFE, Occupational Fraud 2022: A Report to the Nations) — un coût que l’ERP seul ne prévient pas sans contrôles GRC actifs.
1. GRC : définition et pourquoi l’ERP seul ne suffit pas
Le sigle GRC recouvre trois disciplines souvent confondues dans la pratique.
Gouvernance (G) : contrôles internes, politiques et délégations de pouvoirs dans l’ERP
La gouvernance concerne les règles et les structures qui définissent comment les décisions sont prises, qui peut faire quoi, et comment les responsabilités sont tracées. Dans un ERP, cela se traduit par la matrice de rôles, les délégations de signature, les workflows d’approbation.
La plupart des ERP modernes (SAP S/4HANA, Sage 100, Odoo, Cegid XRP) permettent de configurer des règles d’approbation par montant, des workflows multi-niveaux et des profils de droits. Cette couche existe. Le problème est qu’elle se dégrade avec le temps : des dérogations accordées “temporairement” ne sont jamais retirées, des rôles cumulés s’accumulent après des réorganisations, et l’ERP ne produit pas de rapport de gouvernance consolidé lisible par un Risk Manager ou un commissaire aux comptes.
Risques (R) : la cartographie des risques, angle mort majeur de l’ERP
La gestion des risques consiste à identifier, évaluer et hiérarchiser les risques opérationnels, financiers, réglementaires et stratégiques. L’ERP génère une quantité considérable de données pertinentes pour l’analyse des risques : transactions anormales, accès hors horaires habituels, commandes en dehors des seuils approuvés.
Mais l’ERP ne cartographie pas les risques. Il n’a pas de module “Heat Map des risques”, pas de registre des risques avec cotation probabilité-impact, pas de mécanisme pour associer un risque identifié à une transaction ou à un processus métier. C’est un générateur de données sur le risque, pas un gestionnaire de risques.
Conformité (C) : la multiplicité réglementaire dépasse les capacités natives de l’ERP
La conformité, c’est la démonstration que l’entreprise respecte ses obligations légales et réglementaires. En 2026, une ETI européenne doit répondre simultanément à plusieurs cadres qui impliquent l’ERP : RGPD pour les données personnelles, NIS2 pour la cybersécurité des systèmes d’information, CSRD pour le reporting de durabilité, DORA si elle opère dans le secteur financier, Sapin II pour la prévention de la corruption.
L’ERP gère bien la conformité comptable (FEC en France, GoBD en Allemagne, SAF-T en Autriche et Portugal). Il est moins équipé pour maintenir un registre de conformité multiréglementaire, suivre l’avancement des plans d’action, et produire les preuves attendues lors d’un audit.
2. L’ERP comme première couche de GRC : ce qu’il fait déjà bien
Avant d’investir dans une plateforme GRC dédiée, il faut avoir exploité à fond ce que l’ERP offre nativement.
Séparation des droits (SOD) : la couche de contrôle la plus basique
La séparation des tâches (SOD, Segregation of Duties) est le premier principe de contrôle interne. Elle vise à s’assurer qu’une même personne ne peut pas à la fois initier une transaction, l’approuver et la comptabiliser. L’ERP implémente ce principe via sa matrice de rôles.
Tous les ERP de marché ont cette capacité. SAP S/4HANA propose un outil de simulation de conflits de rôles directement dans les transactions de gestion des autorisations. Odoo et Sage 100 permettent de définir des groupes d’accès avec des périmètres séparés. Cegid XRP propose des workflows d’approbation avec séparation des initiateurs et valideurs.
Le problème opérationnel n’est pas l’absence de configuration initiale, c’est la dérive dans le temps. Un article dédié sur ce site couvre les 12 contrôles SOD à implémenter avant l’audit annuel.
Pistes d’audit et journaux d’événements : la traçabilité native de l’ERP
L’ERP produit nativement des journaux de transactions. Chaque écriture comptable, chaque modification d’une commande, chaque changement de tarif est horodaté et associé à un utilisateur. Ces journaux constituent la base documentaire d’un audit.
Dans SAP S/4HANA, le journal des modifications (Change Documents) et la piste d’audit comptable (FI Audit Trail) permettent de retracer l’historique complet d’un document. Dans Odoo, le chatter enregistre toutes les modifications. Dans Sage 100, le journal des événements couvre les actions utilisateurs sensibles.
Ces traces sont précieuses mais non structurées pour une analyse GRC. Elles répondent à la question “qu’est-ce qui s’est passé ?” mais pas à “est-ce que ce qui s’est passé représente un risque ?”.
Gestion des habilitations et des rôles : l’ERP comme référentiel d’identité
L’ERP est souvent le système de référence pour les habilitations métier : qui a accès à la comptabilité fournisseurs, qui peut valider une facture, qui peut modifier un tarif client. Ce référentiel est précieux pour le GRC.
Un point critique à souligner : dans de nombreuses entreprises, l’ERP est le référentiel déclaratif des droits, mais ces droits fuient par d’autres canaux. Des accès directs à la base de données accordés à un intégrateur lors du projet initial, des exports massifs via des connecteurs BI configurés avec un compte technique suriprivilégié, des accès SSH sur le serveur applicatif. Le GRC doit couvrir ces vecteurs que l’ERP ne voit pas.
Les limites : ce que l’ERP ne peut pas faire seul
L’ERP ne consolide pas les risques de plusieurs entités dans une vue unique. Il ne produit pas de Heat Map des risques. Il ne maintient pas un registre de conformité pour NIS2 et CSRD simultanément. Il ne détecte pas les patterns de fraude dans les transactions. Il ne produit pas les rapports structurés attendus par un commissaire aux comptes dans un audit GRC.
Au-delà d’une certaine complexité — typiquement plus de 500 salariés, plus de 3 entités juridiques, ou une exposition réglementaire multi-cadres — une plateforme GRC dédiée devient nécessaire.
3. Quand investir dans une plateforme GRC dédiée ?
Quatre critères de déclenchement guident la décision :
Taille et complexité organisationnelle. Au-delà de 500 salariés ou de 3 entités, la gestion manuelle des risques dans Excel devient incontrôlable. La consolidation inter-entités d’un registre des risques et le suivi des plans d’action nécessitent un outil dédié.
Exposition réglementaire multiple. Si l’entreprise est soumise simultanément à NIS2, CSRD, DORA et à des audits CAC annuels, le coût de production manuelle des preuves de conformité dépasse rapidement le coût d’une plateforme GRC.
Profil de risque sectoriel. Un établissement financier soumis à DORA (règlement UE 2022/2554) doit tenir un registre des prestataires TIC, réaliser des tests TLPT et notifier les incidents dans des délais stricts. Ce niveau d’exigence requiert un outil structuré.
Résultats d’audit. Si un audit interne ou externe a identifié des lacunes dans la gestion des risques ou dans la traçabilité de la conformité, c’est un signal clair qu’un outil dédié est nécessaire.
ROI attendu. La réduction du coût d’audit est le retour sur investissement le plus direct. Les entreprises qui industrialisent la collecte de preuves de conformité réduisent typiquement le temps passé en préparation d’audit de 30 à 50 %. À cela s’ajoute la détection proactive des risques : selon l’ACFE, Occupational Fraud 2022: A Report to the Nations, la perte médiane par incident de fraude interne non détecté atteint 117 000 dollars. Un outil GRC qui détecte un seul incident majeur peut amortir plusieurs années de licence.
4. Panorama des plateformes GRC du marché et leur intégration ERP
Le marché GRC est segmenté en solutions intégrées à un ERP spécifique et en plateformes indépendantes.
| Solution | Éditeur | Force principale | Intégration ERP |
|---|---|---|---|
| SAP GRC Access Control | SAP | SOD, contrôles d’accès, remédiation | Natif SAP (S/4HANA, ECC) |
| ServiceNow GRC | ServiceNow | Cartographie risques, workflows | API vers tous ERP |
| MetricStream | MetricStream | Conformité réglementaire, audit | Connecteurs standards |
| OneTrust | OneTrust | RGPD, confidentialité, ESG | API |
| Diligent (ex-Galvanize) | Diligent | Audit interne, gouvernance | Connecteurs |
SAP GRC Access Control mérite une mention particulière. Il est nativement intégré à SAP S/4HANA et à SAP ECC, avec une lecture directe des rôles et des autorisations. Il permet de simuler des conflits SOD avant d’attribuer un rôle, de générer des rapports de conformité SOX ou ISAE 3402, et de déclencher des workflows de remédiation automatiques. Beaucoup d’entreprises SAP l’ont dans leur contrat de licence mais ne l’ont jamais activé — c’est l’un des outils GRC les plus sous-utilisés du marché.
ServiceNow GRC (désormais intégré dans ServiceNow IRM, Integrated Risk Management) est la solution de référence pour les entreprises qui veulent une plateforme GRC indépendante de l’ERP. Elle se distingue par ses capacités de cartographie des risques avec workflows automatisés et ses intégrations API vers SAP, Oracle, Microsoft Dynamics et les ERP mid-market.
MetricStream est positionné sur les grandes entreprises et les secteurs fortement réglementés (banque, assurance, pharma). Son module de conformité réglementaire suit automatiquement les mises à jour des cadres normatifs (ISO 27001, SOX, GDPR) et les mappe aux contrôles internes.
5. Architecture ERP-GRC : faire circuler les données dans les deux sens
L’intégration ERP-GRC ne se résume pas à un export périodique de données. Elle doit permettre des flux bidirectionnels.
Flux entrant GRC depuis l’ERP
La plateforme GRC se nourrit des données de l’ERP pour alimenter ses analyses de risques :
- Transactions financières : les montants, les fréquences, les contreparties inhabituelles sont des signaux de risque que le GRC analyse.
- Journaux d’accès et d’événements : les connexions hors horaires, les modifications de paramétrage sensibles, les accès à des modules inhabituels.
- Données d’habilitations : la liste des utilisateurs actifs avec leurs profils de droits, synchronisée régulièrement pour détecter les droits dormants ou cumulés.
- Données de référence : les entités juridiques, les centres de profit, les processus métier mappés dans l’ERP servent de référentiel pour la cartographie des risques.
Flux sortant de l’ERP déclenché par le GRC
Le GRC doit aussi pouvoir agir sur l’ERP :
- Blocage d’habilitations : quand le GRC détecte un conflit SOD avéré ou une tentative d’accès non autorisé, il doit pouvoir déclencher une modification d’habilitations dans l’ERP.
- Alertes de contrôle : les contrôles GRC qui échouent déclenchent des tâches de remédiation directement dans les workflows de l’ERP.
- Synchronisation du référentiel : les entités et les processus créés dans l’ERP doivent se refléter automatiquement dans la cartographie des risques GRC.
Gouvernance des données maîtres partagées
Un point structurant souvent négligé : l’ERP et la plateforme GRC partagent des données maîtres communes. Le référentiel des entités juridiques, le répertoire des utilisateurs, la liste des processus métier. Sans gouvernance claire de ces données, les deux systèmes divergent en quelques mois et les analyses GRC perdent leur fiabilité.
6. Cartographie des risques intégrée : du registre Excel à la plateforme intelligente
La maturité GRC d’une organisation se lit souvent à son outil de cartographie des risques.
Niveau 1 — Registre Excel ou module basique ERP. La cartographie des risques est tenue dans un tableur mis à jour une fois par an. Certains ERP proposent un module “Risques” minimal, souvent limité à une liste de risques avec cotation manuelle. Ce niveau est insuffisant pour NIS2 ou DORA.
Niveau 2 — Plateforme GRC avec alimentation automatique depuis l’ERP. Les transactions anormales détectées dans l’ERP alimentent automatiquement les risques identifiés dans la plateforme GRC. Les workflows de remédiation sont déclenchés automatiquement. La Heat Map des risques est mise à jour en continu plutôt qu’annuellement. C’est le niveau cible pour une ETI soumise à NIS2.
Niveau 3 — GRC avec IA et détection de patterns. Les plateformes les plus avancées intègrent des algorithmes de détection d’anomalies sur les flux ERP. Ils identifient des patterns de fraude potentielle (commandes fractionnées pour passer sous les seuils d’approbation, fournisseurs avec la même adresse bancaire qu’un employé, modifications de coordonnées bancaires suivies immédiatement d’un paiement). Ce niveau est pertinent pour les grandes ETI et les entreprises de secteurs à fort risque de fraude.
7. Plan de déploiement GRC-ERP en 90 jours
Un déploiement GRC ne se réalise pas en un seul projet. Il se fait par paliers. Voici un plan en trois mois pour les ETI qui partent d’une base ERP existante sans plateforme GRC.
Mois 1 — Audit des contrôles existants dans l’ERP
- Cartographier les rôles et droits actifs dans l’ERP : combien d’utilisateurs, combien de profils, combien de conflits SOD identifiés.
- Analyser les journaux d’accès des 12 derniers mois : connexions hors horaires, accès à des modules sensibles, modifications de paramétrage.
- Évaluer les habilitations dormantes : comptes actifs sans connexion depuis plus de 90 jours.
- Recenser les réglementations applicables et les preuves de conformité attendues.
Ce diagnostic prend 15 à 20 jours pour une ETI de 1 000 salariés. Il doit impliquer le DSI, le Risk Manager, le Responsable Conformité et le contrôleur interne.
Mois 2 — Choix et paramétrage de la plateforme GRC
- Sélection de la solution en fonction du périmètre réglementaire et de l’ERP en place (SAP GRC si l’entreprise est sur SAP, ServiceNow ou MetricStream sinon).
- Paramétrage du registre des risques avec la taxonomie adaptée au secteur.
- Configuration des flux d’alimentation depuis l’ERP : connexions API ou connecteurs ETL.
- Formation des Risk Managers et des responsables de processus.
Mois 3 — Intégration des flux et montée en puissance
- Activation des flux temps réel entre ERP et GRC.
- Premier run de cartographie des risques avec données ERP réelles.
- Mise en place des workflows de remédiation pour les conflits SOD détectés.
- Formation des auditeurs internes à l’utilisation des rapports GRC pour la préparation des audits CAC.
Ce que NIS2 et DORA changent concrètement pour votre GRC
Deux directives européennes rendent la formalisation GRC urgente pour de nombreuses ETI.
La directive NIS2 (2022/2555) impose aux entités essentielles et importantes une gestion des risques de cybersécurité formalisée : politiques de sécurité documentées, cartographie des risques liés aux systèmes d’information, procédures de réponse aux incidents. L’ERP, en tant que système d’information critique, est au coeur de cette obligation. NIS2 exige une cartographie de risque que l’ERP seul ne peut pas produire.
Le règlement DORA (2022/2554), applicable depuis le 17 janvier 2025, va plus loin pour le secteur financier. Il impose un registre des prestataires TIC, des tests de résilience, et une gouvernance des risques tiers qui couvre les éditeurs d’ERP eux-mêmes. Un article dédié détaille les obligations DORA pour votre ERP financier.
La dimension culturelle : un outil GRC ne remplace pas une culture du risque
Un point essentiel que les acheteurs de plateformes GRC oublient souvent : un outil ne crée pas une culture du risque. Il peut la révéler, la structurer et l’accélérer, mais il ne la remplace pas.
Les organisations qui échouent dans leurs déploiements GRC ont généralement installé un outil sans avoir clarifié au préalable qui est responsable de quoi dans la gestion des risques. Le Risk Manager est-il informé des incidents détectés ? Les responsables de processus renseignent-ils réellement les risques dans l’outil ou laissent-ils le registre se dégrader ? La direction générale consacre-t-elle 30 minutes par mois à la revue du tableau de bord des risques ?
L’outil GRC est un amplificateur. Si la culture du risque est faible, l’outil l’amplifie dans ses lacunes. Si la culture est forte, l’outil la rend visible, mesurable et auditable.
Pour aller plus loin, consultez nos articles complémentaires sur ce périmètre :
- Les 12 contrôles SOD ERP à implémenter avant l’audit annuel — le premier niveau de GRC dans l’ERP, opérationnel et actionnable
- DORA et ERP : obligations de résilience numérique pour le secteur financier — le cadre réglementaire DORA en détail
- NIS2 et ERP : conformité cybersécurité pour les ETI — obligations NIS2 et impact sur votre SI
- ERP et RGPD : protéger les données personnelles dans votre système de gestion — conformité RGPD dans l’ERP
