Quand l'ERP (Enterprise Resource Planning) change, les contrôles doivent suivre

Anticiper l'impact des changements sur les contrôles accélère l'implémentation et renforce la conformité.

Contactez-nous
Les gens qui regardent les écrans
Chaque projet de transformation ERP génère un effet tunnel : l’équipe de projet se concentre principalement sur la fourniture de nouvelles fonctionnalités, la migration des données ou le respect des délais de mise en service. Parallèlement, les contrôles critiques, ceux qui protègent le reporting financier, introduisent la séparation des tâches ou s’assurent de l’existence de pistes d’audit fiables, doivent eux-aussi être repensés, testés et documentés - bien souvent par des acteurs extérieurs à l’équipe principale de projet. 

Le manque d’attention porté à la conception de ces contrôles, n’étant pas la priorité de l’équipe projet, explique pourquoi tant d’organisations ne découvrent des failles de conformité qu’après le déploiement complet du nouvel outil, au moment où toute nouvelle modification entraine des coûts de remédiation élevés et que l’attention pour les audits de conformité est maximale. 

Bonne nouvelle : ce scénario peut être évité. 

Le coût réel de l’attente

Les systèmes ERP sont, par essence, des environnements de contrôle. La manière dont les flux de transactions s’effectuent, les pouvoirs de signature, la journalisation des opérations et la justification des exceptions, ou encore le caractère obligatoire de certains champs de données : ces exemples de configurations déterminent si vos contrôles fonctionneront comme prévu. 

Lorsque les objectifs de ces contrôles sont intégrés insuffisamment ou tardivement, les équipes de projet sont confrontées à des choix difficiles. Ajouter a posteriori des restrictions d’accès dans un système déjà configuré sur d’autres bases crée de la complexité. Prévoir une journalisation d’audit à posteriori de la structuration des données entraîne une couverture incomplète. En ultime recours, les contrôles compensatoires (procédures manuelles pour combler les lacunes) ont tendance à devenir la norme.

Cependant, le raisonnement économique est simple : combler une lacune de contrôle lors des phases préliminaires de définition des besoins et de conception n’est qu’une question de documentation et de décisions de configuration. En revanche, remédier à la même lacune après la mise en service implique des demandes de modification, des tests de (non-) régression, une nouvelle formation des utilisateurs et, souvent, une fenêtre pendant laquelle les risques d’audits sont élevés tandis que la mise en œuvre des correctifs est encore en cours.

Notre approche en 7 phases pour une intégration efficace des contrôles de votre ERP

Comme règle générale, la prise en compte des contrôles est faite à chaque étape. Il est primordial que les questions de conformité soient abordées au moment où elles sont les plus simples à résoudre (et les moins coûteuses à mettre en œuvre) – et c’est exactement le fil rouge de notre approche en 7 étapes.

1
Lancement et planification du projet

L’intégration efficace des contrôles commence par l’établissement lors de la planification avec l’attribution de responsabilités claires. La responsabilité d’un volet spécifique dédié aux contrôles est attribuée à un groupe de travail concerné à la fois par les aspects de gouvernance du projet et aux aspects relatifs aux audits, ce qui évite que cette responsabilité soit diluée à travers les autres équipes de projet. Ce groupe de travail comprend généralement les auditeurs internes, les responsables SOX, les spécialistes de la conformité, de la sécurité informatique et les responsables de première ligne qui maîtrisent le fonctionnement opérationnel des contrôles. 

Le premier produit fini de ce groupe de travail est une évaluation de l’impact des contrôles : il s’agit d’établir une analyse entre les contrôles existants et leur intégration future dans les processus ERP afin d’identifier ce qui est directement intégrable, ce qui doit être repensé et la création de nouveaux contrôles. 

2
Exigences et conception

À ce stade, les besoins en matière de contrôle se traduisent par des spécifications fonctionnelles. Des exigences générales telles qu’une « séparation des tâches appropriée » sont traduites dans des configurations concrètes du système : définition de seuils d’approbation spécifiques, création de règles en matière de séparation des tâches, obligation de compléter certains champs, intégration exhaustive des informations nécessaires dans les pistes d’audit.  

La séparation des tâches ( « Segregation of Duties SOD ») mérite ici une attention particulière. La conception des différents rôles dans les systèmes ERP modernes est relativement complexe, et les conflits qui peuvent sembler théoriques lors de la configuration deviennent des problèmes ou des failles de sécurité réelles en production. Définir une « matrice SoD » claire, précise et exhaustive avant le début de la configuration effective permet d’éviter l’exercice fastidieux de devoir restreindre les accès une fois que les utilisateurs sont déjà actifs dans le système. 

3
Configuration et développement

Cette étape exige une gestion rigoureuse des changements en ce qui concerne les contrôles. La gestion des versions, un lien clair entre les demandes de modifications et les exigences de contrôle, ainsi qu’une documentation de référence, constituent autant d’éléments de preuves que les auditeurs pourront examiner par la suite. 

4
Migration des données

La migration des données présente toujours des risques de contrôle spécifiques que les équipes de projet ont souvent tendance à sous-estimer. Les éléments clés relatifs aux données (tels que les hiérarchies d’approbation, le mapping des comptes et les champs historiques d’audit) entrainent des implications majeures en termes de contrôle. Les procédures de réconciliation vérifiant que les données pertinentes pour le contrôle ont bien été migrées correctement (testées de bout en bout, de la source à la cible, en passant par la phase de préparation) garantissent que le nouveau système démarre sur des bases saines. 

5
Tests 

Les phases de test devraient inclure une validation explicite des contrôles, parallèlement aux tests fonctionnels et d’intégration. Cela implique l’application de scénarios de test conçus pour confirmer que les contrôles fonctionnent comme attendus, y compris des tests dits « négatifs », simulant des entrées invalides, des actions interdites ou des conditions d'erreur, pour vérifier que le système bloque correctement ce qu’il est censé empêcher. Ces tests doivent être organisées de manière cohérente : liées aux identifiants de contrôle, avec des métadonnées indiquant qui a exécuté les tests, quand et dans quel environnement. 

6
Basculement et mise en service

L’étape de planification du basculement et de la mise en service se concentre souvent sur la conversion des données et la disponibilité du système, mais l’activation des contrôles mérite une attention égale. Le guide de basculement (« cutover runbook ») doit préciser le moment où chaque contrôle devient actif, qui est en charge de leur supervision, les éléments déclencheurs d’un retour en arrière (« rollback ») et les vérifications à effectuer immédiatement après la mise en service. 

7
Stabilisation post-mise en service

Les 90 premiers jours constituent une période de risque accru en matière de contrôles. Les flux de transactions interviennent désormais dans le nouvel ERP, les utilisateurs sont encore en phase de prise en main du système, et des imprévus (« edge cases »), non anticipés lors des tests, font leur apparition. Un plan de vérification structuré, axé sur les types de transactions à haut risque et leur réconciliation, permet d’identifier les problèmes au plus tôt de la mise en service. Des capacités de surveillance continue assurent quant à elles un suivi constant et alimentent le processus de résolution des problèmes. 

Indices qui indiquent un risque accru 

Certaines caractéristiques de projets sont étroitement liées avec les difficultés liées à la conformité après la mise en service.  

  • Une intervention tardive des spécialistes du contrôle
    Lorsque les spécialistes en matière de contrôles n’interviennent qu’au moment des tests d’acceptation utilisateur (UAT), les décisions majeures de conception sont déjà prises, ce qui limite leur marge de manœuvre. La valeur ajoutée de ces spécialistes en contrôle est plus importante lors de la phase de conception, lorsque les interventions façonnent les résultats plutôt que de simplement les documenter. 
  • Forte dépendance à l’égard des contrôles compensatoires manuels
    Si les contrôles compensatoires ont une utilité légitime, un environnement dominé par des procédures manuelles suggère que le système ERP n’apporte pas l’automatisation des contrôles qui était pourtant un des arguments justificatif à son investissement initial. 
  • Gestion désorganisée des preuves
    Une documentation des tests dispersée dans des chaînes d’e-mails et dans des espaces de stockage personnels, un contrôle de version peu clair et des lacunes dans les pistes d’audit créent un risque, même lorsque les contrôles eux-mêmes fonctionnent correctement. 
  • Absence de traçabilité
    Les projets qui n’établissent pas de liens clairs entre les exigences de contrôle et les décisions de mise en œuvre peinent à démontrer une conception intentionnellement génératrice de valeur, ce qui crée des zones d’ombre dans le dispositif de maîtrise. 

L’opportunité inhérente à la transformation

Toute migration ERP représente une réelle opportunité de renforcer son environnement de contrôle, à condition que ce renforcement soit planifié plutôt qu’espéré. Les systèmes existants cumulent souvent des années de solutions bis et de contrôle devenus inutiles. Une nouvelle mise en œuvre permet de repenser la conception et intégré des contrôles relevant, adaptés aux risques, aux attentes réglementaires et aux besoins opérationnels actuels.

La discipline requise pour documenter, tester et justifier les contrôles au cours de la mise en œuvre crée les fondations solides qui soutiendront la conformité pendant des années. Elle nécessite un investissement : l’engagement des personnes dévouées, une gouvernance explicite et la volonté de traiter les exigences de contrôle avec le même sérieux que les exigences fonctionnelles. Le retour sur investissement se traduit par des audits plus fluides, une réduction des coûts de remédiation et la certitude que le nouveau système tient réellement les promesses en matière de retour sur investissement.

Apporter l’expertise en contrôle à votre transformation ERP

Notre équipe Risk Advisory accompagne les organisations tout au long du cycle de vie de l’ERP, des évaluations initiales d’impact des contrôles jusqu’à la vérification post-mise en service. Nous apportons une expérience pragmatique en matière de sécurité des applications, d’intégration des contrôles et de préparation à l’audit sur les principales solutions ERP. 

Si vous envisagez une transformation ou si vous êtes déjà engagé dans ce type de projet, n’hésitez pas à contacter notre expert pour discuter de la manière dont les contrôles s’intègrent dans votre approche.