Piste d'audit ERP : quelles traces conserver et combien de temps (SOX, RGPD, GoBD, FEC)

Tout ERP est un système d’enregistrement (system of record). Ce que la plupart des projets d’implémentation n’établissent pas clairement : ce qui doit être enregistré, combien de temps et dans quel format. Les conséquences d’une piste d’audit insuffisante sont concrètes : rejet de déduction fiscale lors d’un contrôle, impossibilité de régénérer un FEC conforme, échec d’un audit SOX, amende RGPD pour absence de journalisation des accès aux données sensibles. Cet article établit un référentiel pratique, structuré par réglementation puis par configuration ERP, à destination des DSI, RSSI et responsables conformité opérant dans plusieurs pays européens.

Qu’est-ce qu’une piste d’audit dans un ERP ?

Une piste d’audit (audit trail) est un enregistrement chronologique et immuable de qui a fait quoi, quand, dans le système. En pratique, elle recouvre trois niveaux distincts, souvent confondus dans les projets d’implémentation.

Les 3 niveaux de traçabilité ERP

1. Traçabilité transactionnelle : enregistrement des opérations métier (création, modification, suppression de factures, de paiements, de mouvements de stock). C’est le niveau le plus souvent activé par défaut dans les ERP.

2. Traçabilité des accès et des droits : journal des connexions, des écrans consultés, des données accédées par chaque utilisateur. Critique pour RGPD et SOX, ce niveau est rarement activé par défaut.

3. Traçabilité de configuration : modifications des paramètres système, des règles de validation, des workflows d’approbation. Indispensable pour SOX et GoBD, quasi toujours désactivé par défaut dans les configurations standard.

Ce que l’ERP trace par défaut vs. ce qu’il faut configurer

La plupart des ERP tracent les transactions financières par défaut : création d’une facture, validation d’un paiement, clôture de période. La traçabilité des accès et des modifications de configuration nécessite une activation explicite :

• SAP : les change documents (tables CDHDR/CDPOS) couvrent les données maîtres configurées, mais le Security Audit Log (transactions SM19/SM20) doit être activé et dimensionné séparément.
• Odoo : le module Audit (version Enterprise) doit être installé manuellement. La version Community ne couvre pas tous les scénarios réglementaires.
• Dynamics 365 : les audit logs se configurent table par table dans les paramètres de sécurité ; ils sont désactivés par défaut.
• Sage X3 : la journalisation des connexions se paramètre dans la configuration sécurité, sans activation automatique.

Ce gap entre ce que l’ERP trace par défaut et ce que les réglementations exigent est la source principale des problèmes découverts lors d’un contrôle fiscal ou d’un audit externe.

Les principales réglementations imposant une piste d’audit

FEC : Fichier des Écritures Comptables (France)

Instauré par la loi de finances rectificative pour 2012, le FEC est obligatoire depuis 2014 pour toutes les sociétés soumises à l’IS ou à l’IR avec bénéfices industriels et commerciaux. Il s’agit d’un fichier texte structuré (séparateurs |) contenant l’intégralité des écritures comptables de l’exercice, dans le format normalisé par la DGFiP.

Durées de conservation :

• 6 ans pour les documents fiscaux, à compter de la dernière opération (article L102 B du Livre des procédures fiscales, Légifrance).
• 10 ans pour les livres comptables et pièces justificatives (article L123-22 du Code de commerce).

Ce que l’ERP doit garantir : la capacité à régénérer un FEC conforme pour tout exercice passé, dans le format DGFiP, y compris depuis les archives. Un ERP incapable de produire ce fichier pour un exercice archivé expose l’entreprise à une amende de 5 000 euros par exercice contrôlé et, dans les cas graves, à une taxation d’office.

Point critique de configuration : l’immuabilité des écritures validées. Une fois une pièce comptable validée dans l’ERP, elle ne doit plus pouvoir être modifiée directement. Toute correction passe par une écriture d’extourne ou un document correctif traçable. Toute modification directe invalide la conformité FEC.

GoBD (Allemagne)

Les Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff (GoBD) s’appliquent à toutes les entreprises assujetties en Allemagne, sans seuil de chiffre d’affaires. La doctrine GoBD, mise à jour par le BMF en 2019, est contraignante pour tout ERP utilisé sur le territoire allemand, quelle que soit sa nationalité.

Durées de conservation applicables en 2026 :

• 10 ans : livres de comptes, inventaires, bilans, rapports de gestion (§ 147 AO, § 257 HGB).
• 8 ans : pièces justificatives comptables (Buchungsbelege), dont les factures, depuis le 1er janvier 2025. La loi Bürokratieentlastungsgesetz IV a réduit ce délai de 10 à 8 ans (fiskaly, GoBD archiving compliance).
• 6 ans : correspondance commerciale reçue et envoyée.

Exigences spécifiques GoBD à retenir pour un DSI :

• Immuabilité (Unveränderlichkeit) : toute correction doit passer par un document de correction traçable, jamais par modification directe de l’écriture originale.
• Accès en temps réel : lors d’un contrôle fiscal (Betriebsprüfung), l’administration allemande peut exiger un accès direct en lecture à l’ERP via le protocole IDEA. L’ERP doit être capable de fournir cet accès sans délai.
• Cloud hors Allemagne : si les données sont hébergées à l’étranger, elles doivent rester accessibles et lisibles depuis le territoire allemand. Cette clause est souvent sous-estimée lors des migrations vers des clouds américains ou asiatiques.

L’ERP doit être documenté comme conforme GoBD, idéalement avec une attestation d’un auditeur ou un certificat éditeur reconnu (GoBD-zertifiziertes System).

SOX Section 404 (États-Unis)

La loi Sarbanes-Oxley s’applique aux sociétés cotées sur les marchés américains (NYSE, NASDAQ) et à leurs filiales significatives. Pour un groupe européen avec une cotation US, ou cherchant à lever des fonds aux États-Unis, la conformité SOX touche directement la configuration ERP.

La Section 404 exige que les contrôles internes sur le reporting financier (Internal Controls over Financial Reporting, ICFR) soient documentés, testés et certifiés chaque année par la direction et l’auditeur externe.

Durée de conservation des preuves : 7 ans minimum pour les documents d’audit, pièces justificatives et journaux financiers (Section 802, codifiée en 15 U.S.C. § 7242). La destruction intentionnelle de documents dans le but d’entraver une enquête fédérale expose à des sanctions pouvant inclure 20 ans d’emprisonnement.

Ce que l’ERP doit tracer pour SOX :

• Séparation des tâches (SoD) : aucun utilisateur ne doit pouvoir créer un fournisseur ET valider un paiement. L’ERP doit journaliser toute violation de ces règles, même accordée à titre exceptionnel.
• Modifications des données maîtres sensibles : tout changement d’IBAN fournisseur, de compte bancaire client, de limite de crédit doit être tracé avec l’identifiant de l’auteur, l’horodatage et la valeur avant/après.
• Overrides de workflow : si un approbateur contourne un circuit de validation, ce contournement doit être enregistré avec le motif justificatif.

RGPD : données personnelles dans l’ERP

Les ERP concentrent massivement des données personnelles : salariés (modules SIRH/paie), clients et prospects (CRM intégré), contacts fournisseurs. Deux tensions réglementaires s’y croisent.

Obligation de journaliser les accès : l’article 32 RGPD impose des mesures de sécurité appropriées pour protéger les données personnelles, ce qui inclut la journalisation des accès aux données sensibles. La CNIL recommande une conservation des logs d’accès de 6 mois (délibération n°2021-122 du 14 octobre 2021, legiscope.com), extensible à 1 an avec une justification documentée fondée sur une analyse de risques. Au-delà, la conservation de logs doit être adossée à une finalité de sécurité identifiée : conserver des journaux d’accès “par précaution” pendant plusieurs années sans justification documentée viole le principe de minimisation de l’article 5.1.e du RGPD.

Tension conservation vs. droit à l’oubli : un client peut exercer son droit à l’effacement. Mais les factures qui le concernent doivent être conservées 6 ou 10 ans pour des raisons fiscales. La solution technique consiste à pseudonymiser les données personnelles dans les archives comptables : les références nominatives sont remplacées par un identifiant anonyme, tandis que les pièces comptables (montants, dates, TVA) sont préservées pour la conformité fiscale. Cette architecture doit être planifiée avant le go-live, pas lors du premier exercice du droit à l’oubli.

NIS2 : événements de sécurité

La directive NIS2, applicable depuis octobre 2024, impose aux entités essentielles et importantes des obligations de journalisation des événements de sécurité. Contrairement aux réglementations précédentes, NIS2 ne fixe pas de durée minimale légale : la rétention doit être déterminée par une analyse de risques documentée. En pratique, les recommandations techniques convergent vers une fenêtre de 6 à 18 mois (nis-2-templates.com, logging requirements), organisée en tiers : accès rapide pour les investigations en cours, archive froide pour la reconstruction forensique.

Les durées exactes dépendent aussi de la transposition nationale de NIS2 et des obligations sectorielles applicables.

Référentiel consolidé : durées de conservation par réglementation

Réglementation	Pays	Type de données	Durée minimale	Pénalité principale
FEC (DGFiP)	France	Écritures comptables (fiscal)	6 ans	5 000 €/exercice + taxation d’office
Code de commerce	France	Livres comptables, pièces justificatives	10 ans	Rejet déductibilité
GoBD (BMF)	Allemagne	Livres, bilans, journaux	10 ans	Rejet déductibilité, accès IDEA forcé
GoBD (BMF)	Allemagne	Buchungsbelege, factures	8 ans (depuis janv. 2025)	Idem
GoBD (BMF)	Allemagne	Correspondance commerciale	6 ans	Idem
SOX s.802	USA (cotées)	Documents d’audit, journaux financiers	7 ans	Sanctions pénales, délisting
RGPD art. 32	UE	Logs d’accès aux données personnelles	6 mois (CNIL)	Jusqu’à 4 % CA mondial ou 20 M€
NIS2 art. 21	UE	Journaux de sécurité	6-18 mois (risk-based)	Amendes nationales variables

Configuration pratique de la piste d’audit dans les ERP majeurs

SAP S/4HANA et ECC

SAP dispose d’une architecture de traçabilité mature, mais ses composants sont distincts et doivent être activés séparément.

• Change documents (tables CDHDR/CDPOS) : activés par défaut pour les tables comptables principales. Pour les données maîtres sensibles (fournisseurs, clients, comptes bancaires), la traçabilité doit être étendue manuellement via la transaction SCDO.
• Security Audit Log (SM19/SM20) : à activer et dimensionner en capacité disque. Il journalise les connexions, les tentatives d’accès échouées et les transactions sensibles exécutées.
• GRC Access Control : module dédié à la gestion des violations SoD. Il génère un journal des accès à risque et des exceptions accordées, indispensable pour SOX.
• Export FEC et GoBD : SAP propose des rapports standards d’export FEC pour la France et un connecteur IDEA pour l’Allemagne. À tester sur l’environnement de production avant le premier contrôle, pas pendant.

Pour l’archivage long terme, SAP ILM (Information Lifecycle Management) permet de déplacer les change documents et les journaux vers un stockage archive en lecture seule, tout en maintenant l’accès légal requis.

Microsoft Dynamics 365 Finance & Supply Chain

D365 propose une journalisation native activable par entité de données.

• Audit log : à activer dans Paramètres de sécurité > Configuration audit. Désactivé par défaut pour des raisons de performance. À configurer table par table selon la criticité.
• Database log : plus granulaire, il trace les opérations CREATE/UPDATE/DELETE sur les entités configurées. Le volume généré doit être anticipé lors du dimensionnement.
• Electronic reporting framework : contient des configurations standard pour l’export FEC (France) et les formats GoBD (Allemagne). Ces configurations doivent être importées et validées par pays d’opération.
• Rétention RGPD : pour les entités soumises au RGPD, la politique de rétention se configure via Microsoft Purview, qui gère le cycle de vie des données à l’échelle du tenant.

Odoo Community et Enterprise

Odoo présente un cas particulier : la version Community a des capacités de traçabilité limitées, insuffisantes pour les obligations réglementaires avancées.

• Module Accounting : l’audit trail natif verrouille les pièces comptables après validation. Une écriture validée ne peut plus être modifiée directement, ce qui garantit l’immuabilité requise par FEC et GoBD.
• Module Audit (Enterprise) : journalise les actions utilisateurs sur les modèles configurés. À activer et configurer manuellement.
• Limitation importante : les logs Odoo Community ne couvrent pas les scénarios GoBD complets ni la traçabilité SoD requise par SOX. Une ETI opérant en Allemagne ou soumise à SOX devra soit passer à Odoo Enterprise avec une configuration rigoureuse, soit adjoindre un SIEM externe pour compléter la journalisation.
• Export FEC : disponible nativement depuis Odoo 14 pour les sociétés françaises.

Sage X3 et Sage 300

• Piste d’audit native : les transactions comptables sont tracées nativement, avec l’auteur et l’horodatage de chaque modification.
• Export FEC : disponible en standard pour la France, à tester régulièrement y compris après une montée de version.
• Journaux de connexion : à activer dans la configuration sécurité. Non activés par défaut.
• GoBD : Sage X3 dispose de configurations adaptées au marché allemand, mais une validation par un cabinet spécialisé est recommandée pour les entreprises soumises à un contrôle fiscal allemand (Betriebsprüfung).

Recommandations pratiques pour les DSI

1. Cartographier les réglementations applicables par pays d’opération : un groupe franco-allemand de 500 salariés sans cotation US est soumis à FEC, GoBD et RGPD, mais pas à SOX. Cette cartographie conditionne toutes les décisions de configuration.

2. Activer les logs de modification sur les données maîtres sensibles : comptes bancaires fournisseurs, limites de crédit clients, comptes généraux. Ce sont les zones les plus souvent non tracées et les plus exposées en cas de fraude interne ou d’audit SOX.

3. Définir une politique de rétention documentée et approuvée : formaliser un tableau par type de données, durée de conservation, format d’archivage et responsable. Ce document doit être validé par le CFO et le DPO, et révisé à chaque changement réglementaire ou migration ERP.

4. Tester régulièrement la génération du FEC et des exports d’audit : une montée de version ERP peut silencieusement casser la chaîne d’export. Tester la production d’un FEC pour un exercice archivé avant chaque migration, pas après.

5. Prévoir la ségrégation des archives : les journaux d’audit archivés doivent être en lecture seule, sans possibilité de modification a posteriori. Une archive GoBD ou SOX modifiable n’a aucune valeur probante lors d’un contrôle.

6. Traiter la pseudonymisation RGPD en amont : concevoir la réponse au droit à l’oubli avant le go-live. La mise en place de la pseudonymisation dans les archives comptables coûte dix fois moins cher avant l’implémentation qu’après.

Conclusion

La piste d’audit ERP n’est pas une option de configuration : c’est une obligation légale dans la plupart des pays d’Europe et aux États-Unis pour les groupes cotés. Le problème est qu’elle est rarement correctement configurée lors de l’implémentation. Beaucoup de DSI le découvrent lors du premier contrôle fiscal ou du premier audit SOX. La bonne pratique : définir la politique de rétention avant le go-live, la tester régulièrement, et la réviser à chaque évolution réglementaire ou migration ERP.

Pour approfondir, consultez notre guide complet de l’archivage des données ERP, notre référentiel des 12 contrôles SoD avant audit annuel et notre guide Zero Trust et sécurité des accès ERP.