Votre ERP concentre vos données financières, vos flux achats, vos processus RH et vos transactions clients. Il est aussi, par nature, le premier outil que les auditeurs scrutent quand ils évaluent votre exposition au risque opérationnel. Pourtant, dans la plupart des ETI, le risk management reste structuré en dehors de l’ERP : dans un tableur, un outil de ticketing ou, pire, dans les têtes de deux ou trois personnes clés.
En 2026, cette approche est devenue une faiblesse réglementaire autant qu’une fragilité opérationnelle. Le Règlement DORA (UE) 2022/2554 s’applique depuis le 17 janvier 2025 sans période de grâce pour les entités financières. La Directive NIS2 (UE) 2022/2555 va soumettre environ 15 000 entités françaises à des obligations de cartographie des risques SI, dont les ETI de secteurs considérés comme “importants” : santé, énergie, transport, eau, infrastructures numériques.
Ce guide s’adresse au DSI, RSSI ou directeur général qui sait ce que “risk management” signifie, mais n’a pas encore structuré son approche dans son ERP. Objectif : un état des lieux réglementaire précis, une lecture comparative des options logicielles, et une feuille de route à trois niveaux de maturité pour passer de l’intention à l’action.
Risques opérationnels et ERP en 2026 : le contexte réglementaire qui change tout
Les 5 catégories de risques opérationnels que l’ERP centralise (ou devrait centraliser)
La définition bâloise du risque opérationnel (risque de perte résultant de processus internes inadéquats, de personnes, de systèmes ou d’événements externes) correspond précisément au périmètre fonctionnel d’un ERP.
Concrètement, cinq catégories de risques opérationnels s’inscrivent naturellement dans le SI de gestion :
- Risques de processus : erreurs de saisie, doublons de paiement, approbations manquantes ou contournées, séquençage incorrect des validations.
- Risques liés aux accès : droits incompatibles (créer un fournisseur et valider un paiement), comptes dormants actifs, accès administrateurs non surveillés.
- Risques de continuité : perte de données, indisponibilité du système lors d’une clôture mensuelle, absence de plan de reprise documenté.
- Risques réglementaires : non-respect d’une obligation de traçabilité (FEC, SOX, RGPD), absence de piste d’audit sur une transaction modifiée, délai de conservation non respecté.
- Risques tiers : défaillance d’un éditeur SaaS critique, faille dans un connecteur EDI, incident chez un prestataire d’infogérance.
Un ERP configuré pour le risk management ne supprime pas ces risques. Il les rend visibles, mesurables et auditables.
DORA (Digital Operational Resilience Act) : ce qu’il exige des SI de gestion depuis janvier 2025
Le Règlement (UE) 2022/2554 dit DORA est entré en application le 17 janvier 2025. Contrairement à NIS2, c’est un règlement : directement applicable dans les 27 États membres, sans transposition nationale, sans variante locale.
Environ 22 000 entités financières européennes sont concernées : banques, assureurs, sociétés de gestion, prestataires de services de paiement, fintechs réglementées, contreparties centrales, dépositaires. Les petites entités bénéficient d’un régime simplifié (article 16), mais les obligations socles restent : cartographie des risques TIC, registre des prestataires, clauses contractuelles obligatoires.
Ce que DORA exige concrètement pour les ERP :
Registre des prestataires TIC (Register of Information) : tout prestataire fournissant un service TIC à une entité financière doit être répertorié. Cela inclut l’éditeur ERP, l’hébergeur, l’intégrateur TMA et chaque connecteur critique. Ce registre est soumis annuellement aux autorités de supervision compétentes au 31 mars.
Gestion des incidents majeurs : un incident affectant le SI de gestion doit être notifié à l’autorité compétente (ACPR, AMF en France) selon des délais stricts : alerte initiale sous 4 heures, rapport intermédiaire sous 72 heures.
Tests de résilience : les entités significatives doivent réaliser des tests de pénétration avancés (TLPT, Threat-Led Penetration Testing) sur les systèmes critiques. Un ERP qualifié de système critique entre dans le périmètre.
En 2026, les autorités de supervision sont passées de la phase documentaire à la phase de contrôle approfondi. Si votre établissement n’a pas finalisé son registre ICT ni mis à jour ses contrats éditeurs, la situation de non-conformité dure depuis plus d’un an.
NIS2 : les ETI “entités importantes” désormais dans le champ
La Directive (UE) 2022/2555 dit NIS2 élargit considérablement le périmètre de NIS1 : environ 15 000 entités françaises seront soumises à ses obligations contre environ 500 précédemment, selon les projections de l’ANSSI.
La France a manqué l’échéance de transposition du 17 octobre 2024 et fait l’objet d’une procédure d’infraction. Le projet de loi “résilience des infrastructures critiques et renforcement de la cybersécurité” était en discussion à l’Assemblée nationale à l’automne 2026. La transposition définitive n’est pas encore en vigueur, mais les obligations de fond sont connues et les préparations doivent être engagées.
Pour une ETI qualifiée “entité importante” (50 salariés minimum, CA supérieur à 10 millions d’euros, dans les secteurs santé, énergie, transport, eau, infrastructure numérique, services postaux, fabrication critique), NIS2 impose :
- Une cartographie des risques SI documentée et révisée régulièrement.
- Des mesures de sécurité proportionnées couvrant la gestion des accès, la sécurité de la chaîne d’approvisionnement, et la formation des personnels.
- Une notification d’incident sous 24 heures (alerte initiale) puis 72 heures (rapport détaillé).
- Une responsabilité personnelle des dirigeants : les organes de direction sont tenus d’approuver et de superviser les mesures de cybersécurité.
Les sanctions en cas de non-conformité atteignent jusqu’à 7 millions d’euros ou 1,4 % du chiffre d’affaires annuel mondial pour les entités importantes, et 10 millions d’euros ou 2 % du CA pour les entités essentielles (source : fidens.fr, Directive NIS2 sanctions).
Le registre des risques dans l’ERP : fonctionnalités natives vs modules GRC dédiés
SAP GRC (Governance, Risk and Compliance) : périmètre réel et seuil de pertinence
SAP GRC est la solution de référence pour les grandes organisations qui utilisent SAP S/4HANA ou ECC. Elle couvre quatre domaines principaux : contrôle des accès (Access Control), gestion des risques (Risk Management), audit interne (Audit Management) et conformité SOX. L’intégration native avec le core SAP est son principal atout : les flux transactionnels alimentent automatiquement les contrôles.
En revanche, SAP GRC est calibré pour les grandes entreprises. Les coûts de licence s’échelonnent dans une fourchette de 150 000 à 550 000 dollars annuels pour un déploiement enterprise, auxquels s’ajoutent des coûts d’implémentation représentant souvent 50 à 200 % de la licence (source : vendorbenchmark.com, GRC Pricing 2026). Pour une ETI en dessous de 500 collaborateurs, le ROI est difficile à justifier sans une pression réglementaire forte (groupe coté, filiale d’un groupe soumis à SOX, entité sous supervision ACPR).
Si votre organisation est cliente SAP mais ne peut pas engager le budget GRC, le module SAP Access Control seul (pour la SoD) est plus accessible et résout le risque le plus fréquemment audité.
Oracle Risk Management Cloud : positionnement et cible
Oracle Risk Management Cloud (anciennement Oracle GRC) est intégré dans Oracle Fusion Applications. Son architecture est orientée contrôle continu : les règles de risque s’exécutent en temps réel sur les transactions, pas seulement lors d’audits périodiques.
Sa cible naturelle est l’organisation qui utilise Oracle ERP Cloud ou Oracle Fusion Financials. Pour les clients Oracle, la valeur est dans l’intégration native : un conflit SoD détecté déclenche directement une alerte dans le workflow de validation Oracle. Pour les organisations non-Oracle, le coût d’intégration rend la solution moins compétitive face à des outils GRC tiers plus agnostiques.
Dynamics 365 + Power Platform : construire un registre des risques sans module dédié
Microsoft Dynamics 365 ne dispose pas de module GRC natif équivalent à SAP GRC. Mais la combinaison D365 + Power Platform (Power Apps + Dataverse + Power Automate) permet de construire un registre des risques fonctionnel à un coût nettement inférieur.
L’approche typique en ETI sous Dynamics :
- Power Apps pour créer un formulaire de saisie des risques et un tableau de bord de suivi.
- Dataverse pour stocker le registre (catégorie de risque, probabilité, impact, propriétaire, plan de traitement, statut).
- Power Automate pour automatiser les alertes (revue trimestrielle, dépassement de seuil, incidents).
Cette approche couvre le niveau 1 de maturité (voir plus bas) et se déploie en 2 à 4 semaines avec un développeur Power Platform de niveau intermédiaire. Elle ne remplace pas une solution GRC intégrée pour les organisations soumises à une pression réglementaire forte, mais elle est suffisante pour répondre aux premiers contrôles ANSSI ou à un audit ISO 27001 de scope limité.
Solutions GRC tierces connectées à l’ERP : quand connecter plutôt qu’intégrer
Quand la pression réglementaire justifie un outil GRC mais que l’ERP ne dispose pas d’un module natif adapté, trois plateformes tierces se positionnent en “hub” connecté à l’ERP :
- ServiceNow GRC : connu pour ses workflows ITSM, ServiceNow a développé un module GRC solide, avec des connecteurs vers SAP, Oracle et Dynamics. Point fort : l’unifor organisation des risques IT et non-IT dans un seul registre. Point faible : le coût de la plateforme ServiceNow est significatif pour une ETI.
- MetricStream : spécialiste GRC historique, positionné sur les secteurs fortement réglementés (finance, santé, énergie). Riche en fonctionnalités de reporting réglementaire (SOX, DORA, ISO 27001).
- Pathlock (ex-Greenlight Technologies) : spécialiste de l’analyse SoD multi-ERP, avec des connecteurs vers SAP, Oracle, Dynamics et Workday. Pertinent si vous gérez plusieurs instances ERP ou si vous venez d’acquérir une filiale avec un SI hétérogène.
La règle de décision : connectez un outil tiers quand votre ERP couvre plusieurs instances hétérogènes, quand vous devez produire un reporting réglementaire structuré (registre DORA, rapport NIS2), ou quand le niveau de contrôle continu requis dépasse ce que le module natif peut produire.
Séparation des tâches (SoD) et contrôle interne dans l’ERP
La SoD en pratique : quels conflits de droits bloquer
La séparation des tâches (Segregation of Duties) est le premier contrôle interne que tout auditeur SAP, Oracle ou Dynamics vérifie. Le principe : une même personne ne doit pas pouvoir initier et valider la même transaction sensible.
Exemples de conflits de droits interdits en pratique :
- Créer un fournisseur et valider un virement vers ce fournisseur.
- Créer une commande d’achat et valider la réception des marchandises.
- Paramétrer un compte bancaire fournisseur et lancer un paiement.
- Modifier le prix d’un article et valider une facture d’achat.
- Créer un utilisateur et lui attribuer des droits d’administration.
Ces conflits sont détectables nativement dans la plupart des ERP modernes via leur outil de gestion des habilitations. Mais la détection native identifie les conflits théoriques dans le référentiel de droits : elle ne détecte pas les conflits exercés en pratique, c’est-à-dire les cas où un utilisateur a réellement utilisé deux droits incompatibles dans la même transaction.
C’est précisément là qu’interviennent des outils d’analyse SoD comme SAP Access Control, Pathlock Assure ou Fastpath Assure : ils croisent le référentiel de droits avec les journaux de transactions pour produire une liste des conflits actifs, non plus théoriques.
Passer du contrôle périodique au contrôle continu : outils natifs vs add-ons
Le contrôle périodique est l’approche classique : un audit trimestriel ou annuel passe en revue la matrice de droits et identifie les conflits SoD. C’est la pratique minimale exigée dans un audit SOX ou ISO 27001.
Le contrôle continu va plus loin : chaque transaction est vérifiée en temps réel contre les règles de contrôle interne. Si un utilisateur tente d’exécuter une transaction en conflit, il reçoit une alerte (ou la transaction est bloquée automatiquement).
La plupart des ERP du marché proposent un contrôle continu natif pour les scénarios les plus critiques (flux de paiement, modifications de données maîtres fournisseurs). Pour les scénarios plus sophistiqués (croisement multi-modules, analyse comportementale), un add-on est nécessaire.
Pour une ETI, la recommandation pratique : commencer par activer les contrôles natifs de l’ERP, documenter les résultats pour l’audit, puis évaluer si les incidents récurrents justifient l’investissement dans un outil d’analyse SoD dédié.
Lien avec FEC, SOX ITGC et ISAE 3402
Trois référentiels réglementaires se croisent avec la SoD dans l’ERP :
FEC (Fichier des Écritures Comptables) : obligatoire pour les entreprises françaises soumises à vérification fiscale. Chaque écriture comptable doit être tracée avec son auteur, son horodatage et son journal source. Un ERP correctement paramétré produit le FEC automatiquement. Un ERP mal configuré (modifications manuelles sans trace, suppressions d’écritures) génère un FEC non conforme.
SOX ITGC (IT General Controls) : pour les filiales françaises de groupes cotés aux États-Unis, la section 404 de la loi Sarbanes-Oxley impose des contrôles sur l’accès aux systèmes financiers. Les ITGC couvrent exactement la SoD : qui peut accéder à quoi, qui peut modifier quoi, qui approuve les changements.
ISAE 3402 / SOC 1 : pour les prestataires qui hébergent ou opèrent un ERP pour le compte d’un client, ce rapport d’assurance certifie que les contrôles internes du prestataire sont suffisants. Un éditeur SaaS ERP sérieux doit pouvoir fournir son rapport SOC 1 Type II annuellement.
Pour approfondir le sujet des pistes d’audit et des obligations de traçabilité, l’article Piste d’audit ERP : obligations légales SOX, RGPD, GoBD, FEC détaille les exigences par juridiction.
ERP et plan de continuité d’activité (PCA/PRA) : les 4 fonctionnalités à configurer
RTO et RPO dans les contrats SLA ERP cloud : ce qu’il faut négocier
Deux indicateurs structurent tout plan de continuité :
- RTO (Recovery Time Objective) : durée maximale d’interruption tolérable avant que l’activité soit gravement impactée. Pour la comptabilité en période de clôture mensuelle, un RTO de 4 heures peut être acceptable. Pour une ligne de production pilotée par l’ERP, 4 heures peuvent représenter des centaines de milliers d’euros de perte.
- RPO (Recovery Point Objective) : quantité maximale de données perdues tolérable. Un RPO de 1 heure signifie que les sauvegardes sont effectuées toutes les heures. Un RPO de 24 heures signifie qu’une journée entière de transactions peut être perdue en cas d’incident.
La plupart des contrats SLA des éditeurs ERP cloud affichent des RTO de 4 à 8 heures et des RPO de 1 à 4 heures. Mais ces valeurs sont généralement garanties sur l’infrastructure standard. Pour les scénarios de reprise après sinistre complet (datacenter inaccessible), les RTO contractuels réels peuvent dépasser 24 à 72 heures si vous n’avez pas souscrit à une option de haute disponibilité géographique.
Points à négocier avec votre éditeur ERP cloud : RTO et RPO distincts par tier de criticité (production, clôture, reporting), pénalités contractuelles mesurables en cas de dépassement, droit d’audit sur les procédures de reprise.
DORA impose précisément ce niveau de précision contractuelle pour les entités financières : les contrats avec les prestataires TIC critiques doivent inclure des objectifs de niveau de service documentés, des procédures de reprise testées et des droits d’audit.
Sauvegardes, chiffrement et cloisonnement des données sensibles dans l’ERP
Les bonnes pratiques minimales pour un ERP en 2026 :
- Sauvegardes : fréquence horaire pour les transactions critiques (comptabilité, paie), quotidienne pour les données maîtres. Conservation : au moins 10 ans pour les données comptables en France (Article L123-22 du Code de Commerce).
- Chiffrement : chiffrement des données au repos (AES-256 minimum) et en transit (TLS 1.2 minimum). Pour les éditeurs SaaS, vérifier que votre clé de chiffrement est séparée de celle de l’éditeur (BYOK, Bring Your Own Key) si vous traitez des données sensibles.
- Cloisonnement : les données RH et paie doivent être cloisonnées des données production dans l’ERP. Les accès aux données financières consolidées doivent être restreints aux rôles qui en ont réellement besoin.
Exercice annuel de basculement : protocole recommandé
Un plan de reprise non testé n’est pas un plan de reprise : c’est un document. DORA l’a formalisé pour les entités financières, mais la pratique vaut pour toute ETI dont l’ERP est critique.
Protocole recommandé pour un exercice annuel :
- Définir le scénario : panne datacenter principal, ransomware sur l’environnement de production, défaillance d’un connecteur critique.
- Tester le basculement technique : vérifier que l’environnement de reprise démarre effectivement dans le RTO contractuel.
- Tester les processus métier : un chef comptable peut-il clore une journée sur l’environnement de reprise ? Les approbations de paiement fonctionnent-elles ?
- Documenter les écarts : noter ce qui ne s’est pas passé comme prévu et tracer les actions correctives.
- Notifier la direction : DORA exige que les dirigeants soient informés des résultats des tests de résilience.
Feuille de route risk management ERP : 3 niveaux de maturité
Niveau 1 - Basique : les fondations non négociables
Ce niveau couvre les obligations minimales d’une ETI qui commence à structurer son risk management ERP.
- Registre des risques manuel : tableau documenté (Excel ou Power Apps) avec au moins les catégories, probabilité, impact, propriétaire et statut de chaque risque identifié. Revue trimestrielle minimum.
- Matrice SoD documentée : liste des combinaisons de droits incompatibles dans l’ERP, avec les dérogations actives et leur justification. Revue semestrielle.
- Revue des habilitations : audit annuel des comptes actifs vs collaborateurs présents, avec suppression immédiate des comptes des départs. Ce point simple élimine l’une des vulnérabilités les plus fréquemment exploitées.
- Sauvegardes testées : vérification trimestrielle que les sauvegardes sont restaurables.
- Documentation PCA : description écrite du scénario de reprise, même sommaire.
Ce niveau ne nécessite pas de budget logiciel supplémentaire. Il exige une organisation et une discipline de suivi.
Niveau 2 - Avancé : contrôles automatisés et KRI dans le tableau de bord
Ce niveau convient à une ETI dont l’ERP est critique pour la continuité et qui doit produire une documentation structurée pour un audit externe.
- Contrôles SoD automatisés dans l’ERP : activation des règles natives de détection de conflits, avec alertes vers le propriétaire du processus.
- KRI (Key Risk Indicators) dans le tableau de bord de direction : nombre de dérogations SoD actives, taux de comptes dormants avec accès ERP, nombre de transactions rejetées par les contrôles automatiques, délai moyen de résolution des incidents.
- Piste d’audit complète : chaque transaction sensible (modification de données maîtres, paiement, clôture) est tracée avec auteur, horodatage et valeur avant/après.
- Test de reprise annuel documenté avec résultats transmis à la direction.
- Registre des risques dans l’ERP ou connecté à l’ERP : sortie du tableur vers un outil intégré (module natif ou Power Platform sous Dynamics).
Niveau 3 - Expert : GRC intégré, corrélation SIEM et reporting réglementaire automatisé
Ce niveau correspond aux entités soumises à DORA, aux filiales de groupes SOX, ou aux organisations certifiées ISO 27001 avec un périmètre ERP inclus dans le scope.
- Module GRC dédié (SAP GRC, Oracle Risk Management Cloud, ServiceNow GRC, MetricStream) avec intégration transactionnelle native.
- Corrélation ERP + SIEM : les événements de sécurité de l’ERP (connexions inhabituelles, modifications de droits, tentatives d’accès refusées) alimentent le SIEM (Security Information and Event Management) pour une détection des menaces en temps réel.
- Reporting réglementaire automatisé : génération du registre DORA, du rapport NIS2 et des attestations SOX ITGC directement depuis l’ERP, sans retraitement manuel.
- Tests TLPT (Threat-Led Penetration Testing) pour les entités DORA.
- Revue formelle des risques en COMEX : rapport trimestriel au Conseil d’administration ou à la Direction Générale, avec suivi des KRI et des incidents majeurs.
Checklist : 15 points pour auditer la maturité risk management de votre ERP
- Avez-vous une liste documentée des risques opérationnels liés à votre ERP, avec propriétaires identifiés ?
- La matrice SoD est-elle formalisée et révisée au moins annuellement ?
- Les comptes des collaborateurs partis sont-ils désactivés dans l’ERP le jour même du départ ?
- Les dérogations SoD actives sont-elles documentées, justifiées et signées par un responsable ?
- Votre ERP génère-t-il une piste d’audit complète sur les transactions financières (FEC-conforme pour la France) ?
- Connaissez-vous le RTO et le RPO de votre contrat SLA ERP cloud ?
- Ces valeurs ont-elles été testées lors d’un exercice de reprise dans les 12 derniers mois ?
- Vos données ERP sont-elles chiffrées au repos et en transit ?
- Disposez-vous d’un registre des prestataires TIC critiques (éditeur, hébergeur, intégrateur TMA) avec leurs obligations contractuelles ?
- Si vous êtes une entité financière : votre registre DORA est-il à jour et a-t-il été soumis à votre autorité de supervision ?
- Si vous êtes dans le périmètre NIS2 : avez-vous initié votre pré-enregistrement sur MonEspaceANSSI (plateforme ANSSI) ?
- Vos KRI (Key Risk Indicators) sont-ils visibles dans le tableau de bord de direction ?
- Les tests de résilience de votre ERP sont-ils documentés et transmis à la direction ?
- Avez-vous réalisé une analyse SoD sur les transactions réelles (et pas seulement sur le référentiel théorique de droits) dans les 12 derniers mois ?
- Votre politique de sécurité ERP a-t-elle été formellement approuvée par la direction générale ou le Conseil d’administration ?
Structurer le risk management dans votre ERP n’est plus une démarche de gouvernance avancée réservée aux grandes entreprises. C’est une exigence réglementaire croissante pour les ETI des secteurs réglementés, et un signal de maturité opérationnelle pour tous les autres.
Pour approfondir les deux sujets les plus directement liés, consultez nos guides dédiés : ERP et Zero Trust : sécuriser les accès avec IAM, PAM et MFA et DORA et ERP : ce que les DSI du secteur financier doivent exiger de leurs éditeurs en 2026.
