ediverse Explorer la plateforme

À la une PEPPOL BIS Billing 3.0 L’obligation européenne d’e-invoicing arrive : France sept 2026, Belgique janv 2026, Allemagne 2025.

— 18 mai 2026 · 9 min de lecture

Pipeline data CSRD/ESRS : architecture pour rapports 2026

La directive CSRD (Corporate Sustainability Reporting Directive, 2022/2464, adoptée le 14 décembre 2022) impose aux grandes entreprises européennes de publier des rapports détaillés conformément aux ESRS (European Sustainability Reporting Standards) édités par l'EFRAG. Premiers rapports dus en 2025 pour l'exercice 2024, élargissement progressif jusqu'en 2028.

Le scope des données ESRS

Les ESRS publiés par l'EFRAG (delegated act du 31 juillet 2023, applicable depuis 2024) couvrent douze standards : deux cross-cutting (ESRS 1 General Requirements, ESRS 2 General Disclosures) et dix topiques en E (environnement : E1-E5), S (social : S1-S4) et G (gouvernance : G1). Le plus volumineux est ESRS E1 Climate Change : émissions GHG Scope 1, 2 et 3, plan de transition, vulnérabilité aux risques physiques et de transition, internal carbon pricing, alignement Taxonomie EU.

La spécificité par rapport à un reporting financier : une grande partie des données vient de sources non comptables — capteurs IoT pour consommations énergétiques, BL de transporteurs pour Scope 3 amont, factures carburant flotte, données RH pour S1 (workforce), CMDB IT pour Scope 2 électricité. Cela impose une architecture data spécifique.

Architecture cible : trois couches

Une architecture éprouvée comprend trois couches : (1) Ingest layer — connecteurs vers ERP (SAP, Oracle, MS Dynamics) pour consommations facturées, vers GMAO (IBM Maximo, SAP PM) pour relevés compteurs, vers TMS pour Scope 3 transport, vers RH (Workday, SAP SuccessFactors) pour ESRS S1, vers EDI partenaires pour primary data Scope 3 amont. Format pivot recommandé : JSON avec schéma versionné stocké sur object lake (S3, Azure Blob, GCS) avec object lock pour immutabilité.

(2) Compute layer — moteur d'agrégation et de conversion GHG (multiplication par facteurs d'émission, gestion devises, conversions unités). Architectures typiques : data warehouse (Snowflake, BigQuery, Databricks) avec dbt pour les transformations versionnées, et un workflow orchestrator (Airflow, Dagster) pour pipelines avec gestion d'erreurs et retries. Les facteurs d'émission sont une bibliothèque dédiée (Base Carbone ADEME, EPA eGRID, IEA, DEFRA) qui doit être versionnée — une revalorisation annuelle des facteurs change tous les rapports historiques s'ils sont recalculés.

(3) Reporting layer — génération du rapport CSRD au format XHTML+iXBRL (inline XBRL) selon la taxonomie ESRS XBRL publiée par l'EFRAG (première version juillet 2024, mise à jour mai 2026). Production assistée par des outils spécialisés (Workiva, Diligent, Tagetik, IBM Envizi, SAP Sustainability, Microsoft Sustainability Manager) ou par génération custom via libraries XBRL (Arelle, FreedomXBRL).

Scope 3 : le défi central

Scope 1 (combustion directe) et Scope 2 (électricité achetée) sont relativement bien outillés depuis la mise en place de GHG Protocol Corporate Standard (2004). Scope 3 — les 15 catégories d'émissions indirectes amont et aval — reste l'enjeu majeur. Pour des grandes entreprises industrielles, Scope 3 représente typiquement 70-90 % du total. Les categories les plus critiques : cat. 1 Purchased goods & services, cat. 4 Upstream transportation, cat. 11 Use of sold products, cat. 12 End-of-life treatment.

Deux approches : (a) spend-based (multiplier l'achat en EUR par un facteur sectoriel monétaire — facile mais grossier), (b) activity-based (collecter la donnée primaire chez le fournisseur via EDI ou plateformes partagées comme Watershed, Persefoni, Sweep, Greenly). Les organisations matures de 2026 visent activity-based sur ≥ 50 % des achats critiques.

Pour récupérer la donnée primaire fournisseur, l'EDI ressort comme canal naturel : des messages spécialisés (CARBONIC en EDIFACT, extension UBL avec EmissionsReport custom, ou format CSV via PEPPOL) commencent à apparaître. Pas encore de standard universel en 2026 — la convergence est attendue 2027-2028.

La taxonomie XBRL ESRS

La taxonomie XBRL ESRS publiée par l'EFRAG est le pivot technique du rapport CSRD. Elle définit ~1 144 datapoints quantitatifs et ~3 000 datapoints qualitatifs. Le rapport est publié en xHTML avec inline XBRL (technique iXBRL), permettant lecture humaine ET extraction machine. Le commissaire aux comptes vérifie la conformité (assurance limitée depuis 2025, assurance raisonnable prévue à terme).

Pour les équipes data, le travail clé est le mapping des datapoints internes vers les datapoints ESRS taxonomy — typiquement 4-8 mois de chantier pour un grand groupe. Les outils Workiva ou Tagetik facilitent mais ne remplacent pas cette étape qui exige expertise comptable + ESG + IT.

Audit trail : l'invisible essentiel

La spécificité du reporting CSRD vs un reporting financier : les sources sont hétérogènes (capteurs, factures fournisseurs, déclarations RH, ETL d'ERP) et nombreuses (typiquement 50-200 sources pour un grand groupe). Le commissaire aux comptes va remonter chaque chiffre publié jusqu'à sa source primaire.

L'architecture data doit donc maintenir un data lineage immuable : chaque transformation versionnée (dbt avec ses snapshots, ou stocker chaque run d'Airflow), chaque facteur d'émission utilisé tracé par millésime, chaque retraitement humain enregistré. Outils types : OpenLineage, DataHub, Marquez. Sans cela, l'auditeur ne peut pas vérifier et oppose un refus de certification.

Conclusion : un sujet data avant tout

CSRD/ESRS est souvent perçu comme un sujet ESG ou comptable, et c'est en partie vrai. Mais opérationnellement, c'est un projet data : ingestion multi-source, transformation, traçabilité, gouvernance. Les équipes EDI ont un rôle naturel sur le pan Scope 3 amont, qui passera de plus en plus par des canaux EDI standardisés. Les choix d'architecture faits en 2025-2026 structureront la capacité de reporting des grands groupes pour la décennie.