La séparation des tâches (SoD, Segregation of Duties) est l’une des premières zones que les auditeurs vérifient dans un ERP. Ce n’est pas un sujet “IT pur”. C’est un sujet de contrôle interne, de fiabilité financière et de réduction du risque opérationnel.
Dans beaucoup d’entreprises, le problème n’est pas l’absence de règles SoD sur le papier. Le problème est l’écart entre la matrice de rôles théorique et les droits réellement actifs dans l’ERP, surtout après plusieurs années d’évolutions, de dérogations et d’urgences.
Cet article propose une checklist de 12 contrôles SoD à implémenter avant l’audit annuel, avec une logique simple: sécuriser les flux critiques sans bloquer l’activité.
Pourquoi les audits ERP échouent encore sur la SoD
Les constats reviennent souvent sous des formes différentes, mais la cause est similaire:
- Des rôles cumulés au fil du temps sans revue globale.
- Des accès d’urgence jamais retirés.
- Des contrôles manuels non tracés.
- Une gouvernance IAM/ERP pas clairement attribuée.
Quand ces points se combinent, l’auditeur voit un risque de fraude interne, d’erreur de comptabilisation ou de manipulation non détectée. Le sujet dépasse la conformité: c’est la qualité de votre pilotage financier qui est en jeu.
Les 12 contrôles SoD à déployer avant l’audit
1. Cartographier les processus et transactions sensibles
Commencez par limiter le périmètre à ce qui compte vraiment: achats, fournisseurs, paiements, ventes, avoirs, journal général, immobilisations, trésorerie.
Objectif: associer chaque processus à ses transactions ERP clés, puis identifier les couples d’actions incompatibles (exemple: création fournisseur + validation paiement).
Sans cette cartographie, la SoD reste une liste abstraite et impossible à opérer.
2. Formaliser une matrice SoD versionnée
Votre matrice SoD doit être un référentiel vivant, versionné et approuvé. Elle doit préciser:
- La fonction métier concernée.
- Les transactions ERP autorisées et interdites.
- Les conflits bloquants.
- Les conflits tolérés avec contrôle compensatoire.
Une matrice non versionnée devient vite inopérante en audit, car personne ne peut prouver quelle règle était en vigueur au moment d’une opération.
3. Séparer strictement création et validation des tiers
Le cycle fournisseur et le cycle client sont des zones à haut risque. Un même utilisateur ne doit pas pouvoir créer ou modifier un tiers, puis approuver des transactions financières associées.
Contrôles minimaux:
- Séparer la maintenance des tiers et la validation comptable.
- Séparer la maintenance des coordonnées bancaires et l’exécution des paiements.
- Forcer une preuve de revue sur toute modification sensible de RIB/IBAN.
4. Bloquer le cumul commande-réception-facture-paiement
Le principe de base du contrôle achat est de distribuer les étapes du flux P2P:
- Émission de commande.
- Réception de marchandise ou service.
- Validation de facture.
- Paiement.
Dans une PME, les équipes sont parfois réduites. Si la séparation complète est impossible, il faut au minimum limiter le cumul dans l’ERP et documenter un contrôle compensatoire mensuel par un responsable indépendant.
5. Verrouiller les écritures manuelles en journal général
Les écritures manuelles peuvent corriger des anomalies réelles, mais elles sont aussi une porte d’entrée pour maquiller un résultat ou déplacer des charges.
À mettre en place:
- Droits d’écriture manuelle limités.
- Validation séparée pour les écritures hors modèles standards.
- Journal d’audit actif avec motif obligatoire.
L’auditeur regardera surtout les écritures de fin de période et les annulations inhabituelles.
6. Séparer droits de paramétrage et droits d’exploitation
Un administrateur fonctionnel qui peut à la fois modifier des règles de contrôle et exécuter des opérations métiers critiques crée un risque élevé.
Bonne pratique:
- Les profils de configuration ERP ne postent pas d’écritures opérationnelles.
- Les profils métiers n’ont pas accès aux paramètres de sécurité, workflows et règles d’approbation.
C’est une frontière souvent négligée dans les projets de migration ou de reprise de données.
7. Encadrer les comptes à privilèges et accès d’urgence
Les comptes “super user” sont utiles en incident, mais dangereux en exploitation courante.
Exigences minimales:
- Coffre d’accès (ou mécanisme équivalent) pour les privilèges élevés.
- Durée d’accès limitée.
- Justification obligatoire.
- Revue post-utilisation.
Un accès d’urgence non journalisé est une faiblesse majeure en audit.
8. Imposer une revue périodique des habilitations
La SoD n’est jamais “faite une fois pour toutes”. Les rôles dérivent avec les mouvements d’équipe.
Mettez en place une revue trimestrielle ou semestrielle, pilotée par le métier et la finance, avec validation explicite:
- Qui garde ses accès.
- Qui change de périmètre.
- Qui doit être retiré immédiatement.
Conservez une preuve signée ou horodatée. Sans preuve, le contrôle est considéré comme non-opérant.
9. Automatiser la détection des conflits SoD actifs
Un contrôle manuel ponctuel ne suffit pas. Il faut un scan régulier des conflits entre rôles et droits effectivement attribués.
Résultat attendu:
- Liste des conflits ouverts.
- Niveau de criticité.
- Propriétaire de remédiation.
- Date cible de correction.
Même un export mensuel structuré vaut mieux qu’un audit ad hoc sans historique.
10. Gérer formellement les dérogations SoD
Certaines dérogations sont légitimes (absence temporaire, pic d’activité, transition d’organisation). Le problème n’est pas la dérogation, c’est l’absence de cadre.
Chaque exception doit inclure:
- Motif business.
- Périmètre exact.
- Date de fin.
- Approbateur nommé.
- Contrôle compensatoire associé.
Une exception sans date d’expiration devient une règle cachée.
11. Tracer les preuves de contrôle dans un dossier d’audit
Avant l’audit, préparez un dossier unique contenant:
- Matrice SoD en vigueur.
- Comptes à privilèges et usages récents.
- Revues d’habilitation signées.
- Dérogations ouvertes/fermées.
- Journal des conflits et remédiations.
But: réduire le temps passé à reconstruire des preuves pendant l’audit et éviter les réponses improvisées.
12. Attribuer un propriétaire SoD unique
La SoD échoue souvent par dilution de responsabilité. IT pense que c’est un sujet finance; finance pense que c’est un sujet IT.
Désignez un propriétaire unique (souvent contrôle interne, finance transformation ou PMO ERP), avec mandat clair:
- Maintenir la matrice.
- Arbitrer les conflits.
- Suivre les remédiations.
- Préparer le comité d’audit.
Sans gouvernance claire, même un bon outil SoD finit par dériver.
Plan d’exécution en 30 jours avant audit
Si votre audit est proche, vous pouvez avancer avec une approche pragmatique:
- Semaine 1: cadrage des flux critiques et extraction des rôles actifs.
- Semaine 2: mise à jour de la matrice SoD et qualification des conflits majeurs.
- Semaine 3: remédiation rapide des conflits critiques + formalisation des dérogations.
- Semaine 4: constitution du dossier de preuves et répétition de la revue avec finance/IT.
Cette séquence ne remplace pas un programme de contrôle interne pérenne, mais elle réduit fortement le risque de non-conformité immédiate.
Erreurs fréquentes à éviter
Trois erreurs reviennent dans les audits ERP:
- Traiter la SoD comme un exercice documentaire sans correction réelle des droits.
- Confondre complexité organisationnelle et absence de règles.
- Attendre l’ouverture de l’audit pour nettoyer les conflits.
Le bon réflexe: traiter la SoD comme un processus continu de gouvernance, pas comme un livrable de fin d’année.
Ce qu’un DSI et un CFO doivent suivre ensemble
La SoD ERP fonctionne quand la gouvernance est partagée:
- Le DSI garantit l’architecture des rôles, la traçabilité et l’automatisation des contrôles.
- Le CFO garantit la pertinence des règles vis-a-vis des risques financiers.
- Le sponsor de direction arbitre les exceptions quand l’opérationnel et le contrôle entrent en tension.
Cet alignement évite le double écueil classique: un ERP “sécurisé” mais inutilisable, ou un ERP fluide mais non maîtrisé.
Conclusion opérationnelle
Un audit annuel ne se prépare pas avec une présentation, mais avec des droits nettoyés, des exceptions encadrées et des preuves exploitables.
Les 12 contrôles ci-dessus constituent un socle réaliste pour une PME ou une ETI qui veut sécuriser son ERP sans transformer l’organisation en usine à gaz.
Téléchargez notre grille d’évaluation ERP — 30 critères sur 100 points pour benchmark 3 éditeurs côte à côte.
