Votre ERP concentre la comptabilité, la paie, les achats et les données commerciales les plus sensibles de l’entreprise. Pourtant, une question revient systématiquement lors des audits internes : combien de comptes utilisateurs actifs dans l’ERP appartiennent en réalité à des personnes qui ont quitté l’entreprise depuis six mois, un an ou davantage ?
La gouvernance des habilitations ERP — c’est-à-dire le processus vivant qui définit qui obtient quels droits, quand et pour combien de temps — est l’angle mort de la plupart des projets d’implémentation. Les équipes IT configurent les rôles au go-live, puis la gestion quotidienne retombe sur des managers qui ne signalent pas les départs, des RH qui ont un process séparé, et une DSI surchargée qui valide les demandes d’accès sans en retirer les anciens. En quelques années, la réalité des droits actifs dans l’ERP s’éloigne complètement de la réalité organisationnelle.
Cet article ne couvre pas les contrôles de séparation des tâches (SoD) en eux-mêmes — pour cela, lisez notre guide des contrôles SoD à implémenter avant l’audit annuel. L’objet ici est le processus de gouvernance : comment organiser l’onboarding, la vie du compte, la revue périodique et l’offboarding pour que vos droits ERP reflètent en permanence votre réalité organisationnelle.
Pourquoi la gouvernance des habilitations ERP est négligée — et dangereuse ?
Les comptes fantômes : un risque concret et sous-estimé
Un “compte fantôme” désigne un compte utilisateur ERP toujours actif après le départ de son titulaire. Ce phénomène est beaucoup plus répandu qu’on ne le pense. Lors d’audits internes conduits dans des ETI sans process d’offboarding formalisé, il est courant de constater que des comptes correspondant à des salariés ou prestataires partis depuis plus de six mois restent actifs et dotés de droits non révoqués. Ce n’est pas une extrapolation théorique : c’est un constat fréquent des auditeurs internes et des intégrateurs ERP lors des phases de bilan pré-audit.
Ces comptes fantômes représentent plusieurs risques superposés :
- Risque de fraude : un salarié qui connaît ses anciens identifiants peut continuer à accéder à l’ERP après son départ. Si le compte n’est pas surveillé, l’activité peut passer inaperçue pendant des semaines.
- Risque réglementaire RGPD : un compte actif donne accès aux données personnelles des salariés, clients et fournisseurs. L’article 5(1)(f) du RGPD impose une protection de l’intégrité et de la confidentialité des données, ce qui inclut la limitation des accès aux seules personnes habilitées.
- Risque NIS2 : la directive NIS2, transposée en droit français en 2025, impose dans son article 21(2)(d) des contrôles d’accès et une politique de gestion des identités pour les entités essentielles et importantes. Les comptes orphelins constituent une non-conformité directe.
- Risque SOX : pour les groupes cotés aux États-Unis ou leurs filiales significatives, la section 404 de Sarbanes-Oxley exige des contrôles d’accès documentés et revus périodiquement. Des comptes non révoqués lors d’un départ constituent un finding d’audit avec impact sur le ICFR (Internal Control over Financial Reporting).
Ce qui distingue cet article des contrôles SoD
La matrice SoD définit quelles combinaisons de droits sont incompatibles. La gouvernance des habilitations définit quel processus assure que les bons utilisateurs ont les bons droits au bon moment. Les deux sujets sont complémentaires : une matrice SoD parfaite est inutile si une partie des comptes actifs sont des comptes fantômes, ou si les rôles se cumulent sans contrôle lors de chaque mobilité interne.
Phase 1 — Onboarding : créer un compte utilisateur ERP sans risque
La matrice RACI de la demande d’accès
La création d’un compte ERP ne devrait jamais être une action informelle déclenchée par un e-mail au service informatique. Pour qu’un compte soit créé avec les bons droits et rien de plus, quatre rôles doivent être clairement assignés selon une matrice RACI :
| Rôle RACI | Acteur | Action |
|---|---|---|
| Responsible | Admin ERP / DSI | Crée le compte, assigne les profils, documente dans le registre des accès |
| Accountable | DSI ou RSSI | Valide que la demande est conforme à la politique d’accès et à la matrice SoD |
| Consulted | Manager métier | Confirme la liste des modules et niveaux d’autorisation strictement nécessaires |
| Informed | RH | Reçoit confirmation que le compte est créé — synchronisation avec le dossier employé |
La fiche de demande d’accès doit comporter au minimum :
- Nom, prénom et identifiant RH du futur utilisateur
- Date de prise de poste et durée prévue (CDI, CDD, mission prestataire avec date de fin obligatoire)
- Module(s) ERP concernés et niveau d’autorisation demandé
- Profil ou template de rôle suggéré (jamais “accès complet à la comptabilité” mais “profil Controller Junior”)
- Signature du manager métier (approbation formelle)
Ce dernier point est clé : la demande ne doit pas être “donnez-lui accès à la comptabilité” mais “appliquez-lui le profil Controller Junior, qui donne accès en lecture aux journaux et en saisie aux notes de frais, sans droit de validation”. La précision du profil demandé est ce qui empêche la dérive des droits dès l’onboarding.
Modèles de rôles prédéfinis et règles de non-cumul
Les demandes d’accès “à la carte” sont l’ennemi de la gouvernance. Chaque exception crée un profil unique, difficile à maintenir et impossible à vérifier en masse lors d’une campagne de recertification. La bonne pratique est de définir des templates de rôles par métier, alignés sur votre matrice SoD :
- Acheteur junior : saisie des demandes d’achat, consultation du référentiel fournisseurs, pas de validation de commande ni d’accès au paiement
- Responsable achats : validation des commandes jusqu’à un seuil défini, gestion des fournisseurs hors création, pas d’accès au module paiement
- Contrôleur de gestion : lecture de tous les journaux, export vers BI, pas de saisie comptable ni de validation
- Magasinier : mouvements de stock entrant et sortant, pas d’accès aux prix d’achat ni aux conditions tarifaires
Dans SAP, ces templates correspondent aux rôles configurés via la transaction PFCG. Dans Odoo, ce sont les groupes d’accès paramétrables par module. Dans Dynamics 365, ce sont les rôles de sécurité.
Les règles de non-cumul fondamentales à intégrer dans vos templates dès le go-live :
- Création de fournisseur ET validation de paiement fournisseur : interdit
- Saisie de commande d’achat ET réception marchandises ET validation de facture fournisseur : au moins deux de ces fonctions doivent être portées par des profils distincts
- Création d’utilisateurs ERP ET validation des droits d’accès : l’administrateur ne doit pas être son propre valideur
Phase 2 — Vie du compte : gérer les changements de poste et périmètre
Process de modification lors d’une promotion ou mobilité interne
Le vrai problème de la gouvernance des accès n’est pas l’onboarding, géré au moins partiellement lors du go-live. C’est la modification silencieuse des droits lors des mouvements internes qui génère la dérive.
L’erreur fréquente : lors d’une promotion, le manager demande d’ajouter les nouveaux droits mais oublie de signaler les anciens droits à supprimer. Après deux ou trois mobilités, l’utilisateur accumule des droits qui ne correspondent plus à aucun de ses postes actuels. Dans les audits, ce phénomène porte le nom d’accumulation silencieuse (privilege creep) et constitue l’une des findings les plus courantes lors des revues d’accès.
Le processus recommandé pour toute modification de poste :
- Le manager ou les RH déclenche une demande de modification d’accès — via le même formulaire que la demande initiale, avec un champ explicite “anciens droits à supprimer”
- L’admin ERP applique le nouveau profil et retire explicitement l’ancien profil dans la même opération
- La modification est documentée avec date et approbation managériale
- L’utilisateur reçoit confirmation par e-mail (traçabilité et prise de conscience)
Dans SAP, la transaction SU01 permet de modifier les rôles d’un utilisateur et d’activer un verrouillage automatique après N jours d’inactivité (paramètre login/failed_user_auto_unlock et login/password_expiration_time côté profil de connexion). Dans Odoo, la gestion des utilisateurs se fait dans Paramètres > Utilisateurs et sociétés > Utilisateurs — l’archivage du compte préserve la piste d’audit ; la suppression, elle, l’efface.
Droits temporaires : accès de substitution et délégation
La gestion des absences longues est un cas particulier délicat. Quand un responsable achats part en congé maternité pour six mois, son remplaçant a besoin de ses droits — mais uniquement pour la durée de l’absence, et sans cumuler avec des droits incompatibles s’il occupe déjà un autre poste.
Règles recommandées pour les accès temporaires :
- Durée maximale sans renouvellement explicite : 3 mois. Au-delà, la demande doit être renouvelée avec une nouvelle approbation du manager, qui confirme que la situation n’a pas évolué.
- Revue obligatoire au retour de l’absent. Le compte temporaire doit être désactivé le jour même du retour — pas une semaine après.
- Pas de cumul avec des droits permanents incompatibles. Un responsable comptable qui remplace temporairement le directeur financier ne doit pas se retrouver à valider ses propres écritures.
Ces accès temporaires doivent être consignés dans un registre séparé (un tableur suffit pour les PME), avec date de début, date de fin prévue et identité du responsable de la revue.
Phase 3 — Revue périodique : organiser une campagne de recertification des droits
Fréquence recommandée
La revue des habilitations est une obligation pour les entités sous SOX, NIS2 et les référentiels ISO 27001 et SOC 2. La fréquence varie selon le profil de risque de chaque population :
| Profil utilisateur | Fréquence recommandée |
|---|---|
| Tous les utilisateurs actifs | Annuelle |
| Administrateurs ERP et super-utilisateurs | Trimestrielle |
| Profils à droits financiers étendus (direction financière, DAF, contrôle de gestion senior) | Trimestrielle |
| Comptes prestataires et intégrateurs | À chaque fin de mission + revue trimestrielle |
| Comptes de service et comptes batch | Semestrielle |
Une revue “continue” est déclenchée par événement pour les départs et les changements de poste. Elle ne remplace pas les revues périodiques planifiées ; elle s’y ajoute.
Comment conduire la revue avec les managers métier
La revue des habilitations ne peut pas être réalisée uniquement par la DSI : les managers métier sont les seuls à savoir si tel utilisateur a encore besoin de tel accès. Le processus recommandé en quatre étapes :
Étape 1 — Export des comptes actifs
Exportez depuis l’ERP la liste de tous les comptes actifs avec leur dernière date de connexion, leur profil de rôles et leur date de création. Dans SAP, la transaction SUIM permet de générer ce rapport. Dans Odoo, une extraction sur la table res.users filtrée sur active = true produit l’équivalent. Dans Dynamics 365, le rapport est accessible depuis le centre d’administration Power Platform.
Étape 2 — Envoi du questionnaire aux managers
Pour chaque utilisateur de leur équipe, le manager répond à une question simple : “Cet utilisateur a-t-il encore besoin de ces droits dans l’ERP ?” avec trois options :
- Maintien : les droits correspondent au poste actuel
- Modification : certains droits doivent être ajoutés ou retirés (avec précision)
- Révocation : l’utilisateur n’a plus besoin d’accès à ce module ou à l’ERP
Étape 3 — Application des décisions et documentation
Chaque décision de modification ou révocation est appliquée dans les cinq jours ouvrés et documentée avec la date, l’auteur de la modification et l’approbation managériale.
Étape 4 — Rapport de clôture de campagne
Un document de synthèse est produit : nombre de comptes revus, modifications appliquées, révocations, taux de réponse des managers. Ce document est la preuve que la revue a bien eu lieu — indispensable pour un audit ISO 27001, SOC 2 ou SOX.
Phase 4 — Offboarding : les 7 étapes pour désactiver un compte ERP sans laisser de trace
L’offboarding est l’étape la plus critique et la plus souvent bâclée. Voici le processus en 7 étapes :
-
Notification anticipée (J-5 à J-1 avant le départ) : les RH informent la DSI de la date de départ effective avec la liste des systèmes auxquels l’utilisateur a accès. Ce déclencheur ne doit pas dépendre de la bonne volonté du manager : il doit être automatique, via un workflow RH ou une intégration avec le SIRH.
-
Désactivation du compte ERP le jour J, avant que le salarié ne quitte les locaux : le compte est désactivé, pas supprimé. Dans SAP, la transaction SU01 permet de verrouiller un utilisateur (Lock user). Dans Odoo, on utilise l’archivage via Paramètres > Utilisateurs > Archiver. La suppression du compte est à proscrire : elle détruit la piste d’audit des actions passées, ce qui peut être problématique lors d’un contrôle fiscal ou d’une enquête interne.
-
Transfert des tâches en cours : vérification qu’aucune approbation ou workflow en attente n’est bloqué sur ce compte. Si oui, réassignation aux bons responsables avant la désactivation effective.
-
Révocation des accès connexes : tokens API, accès mobiles à l’ERP, sessions VPN liées, identifiants de portails fournisseurs ou clients. Ces accès périphériques sont souvent oubliés alors qu’ils permettent parfois d’accéder aux données ERP indirectement.
-
Archivage du compte : le compte désactivé et ses droits historiques sont conservés dans les logs ERP pour une durée correspondant aux obligations légales applicables. Pour le détail des durées par pays et référentiel, consultez notre guide des obligations de piste d’audit ERP.
-
Cas des prestataires — délai raccourci : la désactivation doit intervenir le jour même de la fin de mission, sans délai de grâce. Les accès VPN et les tokens API doivent être révoqués dans la journée. Un prestataire qui conserve un accès ERP actif après la fin de sa mission expose l’entreprise à un risque RGPD, contractuel et de responsabilité en cas d’incident.
-
Journalisation de la désactivation : la désactivation elle-même doit être tracée — date, heure, identité de l’admin qui a opéré, motif (départ volontaire, licenciement, fin de mission). Ce log est la preuve que le processus d’offboarding a fonctionné, vérifiable lors d’un audit.
Note sur les comptes de service : les comptes utilisés pour les batchs, les interfaces entre systèmes ou les API ne suivent pas le processus d’offboarding humain. Ils doivent être inventoriés séparément, protégés par une rotation de mot de passe régulière — idéalement via une solution PAM, comme décrit dans notre guide Zero Trust et IAM appliqués à l’ERP — et revus lors des campagnes semestrielles dédiées.
Gouvernance outillée : quel outil IGA pour automatiser ?
L’IGA (Identity Governance and Administration) désigne les solutions logicielles qui automatisent et centralisent la gestion des habilitations. Le marché se segmente en trois niveaux selon la taille de l’entreprise et le budget disponible :
Solutions natives dans les grands ERP :
- SAP GRC Access Control : solution complète pour les environnements SAP ECC et S/4HANA. Inclut l’analyse des conflits SoD en temps réel, les workflows d’approbation et les campagnes de recertification automatisées.
- Oracle Identity Governance (OIM) : équivalent Oracle pour les environnements E-Business Suite et Fusion Applications.
Solutions tierces en intégration ERP :
- Saviynt : plateforme cloud d’IGA avec connecteurs natifs SAP, Salesforce, ServiceNow et les principaux ERP.
- SailPoint IdentityNow : solution SaaS avec capacités de machine learning pour détecter les anomalies de droits.
- Omada : spécialisé sur les environnements Microsoft (Azure AD, Dynamics 365) et SAP, bien adapté aux ETI européennes.
Pour les PME et ETI sans budget IGA :
| Taille d’entreprise | Approche recommandée |
|---|---|
| PME (< 100 utilisateurs ERP) | Tableur de suivi des accès + export mensuel ERP + workflow e-mail formalisé |
| ETI (100-500 utilisateurs) | Outil de ticketing ITSM (GLPI, Jira Service Management) + export ERP + revue trimestrielle outillée |
| Grande ETI / Grand groupe | Solution IGA dédiée (Saviynt, SailPoint, Omada, SAP GRC) |
L’essentiel n’est pas l’outil : c’est l’existence d’un processus formel, documenté et réellement appliqué. Un tableur rigoureusement tenu est plus utile lors d’un audit qu’une solution IGA mal paramétrée et jamais utilisée.
Template — Fiche de processus habilitations ERP
Ce tableau récapitulatif peut servir de base à votre fiche de processus interne, versionnée et approuvée par le RSSI :
| Événement déclencheur | Action requise | Responsable | Délai maximal |
|---|---|---|---|
| Recrutement / prise de poste | Demande d’accès + validation manager + création compte | Admin ERP / DSI | Jour de prise de poste |
| Changement de poste interne | Ajout nouveaux droits + suppression anciens droits | Admin ERP / DSI | 5 jours ouvrés |
| Absence longue (> 1 mois) | Création accès temporaire remplaçant avec date d’échéance | Admin ERP / DSI | Avant le départ en absence |
| Retour d’absence | Désactivation du compte temporaire du remplaçant | Admin ERP / DSI | Jour du retour |
| Départ de l’entreprise | Désactivation compte, révocation accès périphériques, archivage | Admin ERP / DSI | Jour J du départ |
| Fin de mission prestataire | Désactivation compte, révocation VPN et tokens API | Admin ERP / DSI | Jour J de fin de mission |
| Revue trimestrielle | Export comptes actifs + questionnaire managers + application décisions | DSI / RSSI | Sous 15 jours calendaires |
Checklist de contrôle trimestrielle DSI/RSSI :
- Comptes actifs avec dernière connexion > 90 jours : identifier, envoyer aux managers pour décision de maintien ou révocation
- Comptes prestataires : vérifier que chaque compte a une date de fin de mission à jour dans le registre des accès
- Comptes de service et batch : vérifier que les mots de passe ont été renouvelés dans les six derniers mois
- Profils administrateurs ERP : vérifier que le compte admin n’est pas utilisé pour les opérations métier quotidiennes
- Nombre d’utilisateurs avec profil “super-utilisateur” ou équivalent : le maintenir au strict minimum justifié
- Comptes verrouillés depuis plus de 30 jours : décision de désactivation définitive ou de maintien justifié documenté
Bien conçue et réellement appliquée, la gouvernance des habilitations ERP est l’une des mesures de sécurité à meilleur rapport coût/efficacité. Elle ne requiert pas un budget logiciel important pour une PME ou une ETI : elle requiert un processus clair, des responsabilités assignées et une discipline d’exécution. C’est précisément ce qui manque dans la majorité des organisations lorsqu’un auditeur externe ouvre le registre des accès.
Pour approfondir le sujet, consultez notre guide Zero Trust et IAM appliqués à l’ERP et notre guide de la matrice RACI dans les projets ERP.
Téléchargez notre guide ERP complet — 60 pages de méthodologie, grilles de scoring et templates opérationnels pour cadrer votre projet ERP ou préparer votre prochain audit des accès.
