La question revient à chaque réunion de comité de direction : “Nos données carbone, elles viennent d’où ?” La réponse honnête, dans la plupart des ETI industrielles, est la suivante : d’un fichier Excel alimenté à la main deux fois par an, à partir de factures PDFs que personne ne retrouve en cas d’audit.
Or les données dont vous avez besoin pour calculer vos émissions Scope 1, 2 et 3 existent déjà dans votre ERP. Elles ne sont pas étiquetées “carbone”, mais elles y sont : les factures d’énergie dans le module achats, les consommations de carburant dans la gestion des actifs, les quantités achetées par fournisseur dans la supply chain. Le problème n’est pas l’absence de données, c’est leur absence de connexion avec un référentiel de facteurs d’émission.
Ce guide explique comment activer cette connexion, module par module, selon le protocole GHG Corporate Standard, qui est la référence mondiale en matière de comptabilité carbone.
Comptabilité carbone et ERP : pourquoi les données sont déjà là
Le protocole GHG en 3 scopes : ce que l’ERP sait (et ce qu’il ne sait pas encore)
Le GHG Protocol Corporate Standard, publié par le WRI (World Resources Institute) et le WBCSD, définit trois périmètres d’émissions pour une entreprise :
- Scope 1 : émissions directes issues des sources détenues ou contrôlées par l’entreprise (chaudières, véhicules de flotte, procédés industriels, fluides frigorigènes).
- Scope 2 : émissions indirectes liées à l’énergie achetée et consommée : électricité, vapeur, chaleur, froid.
- Scope 3 : toutes les autres émissions indirectes en amont et en aval de la chaîne de valeur (achats de biens et services, transport de marchandises, utilisation des produits vendus, fin de vie, trajets domicile-travail, etc.).
Ce que votre ERP maîtrise nativement : le Scope 1 (via la gestion des actifs et les consommations industrielles) et le Scope 2 (via les achats d’énergie). Ce qu’il ne sait pas encore : relier ces données à un facteur d’émission (en kgCO2e par kWh, par litre, par km) pour produire un résultat en tonnes de CO2 équivalent.
Pour le Scope 3, le chantier est plus profond : l’ERP contient les volumes (quantités achetées, distances transportées, montants fournisseurs) mais pas les empreintes unitaires. Ces empreintes doivent être importées depuis des bases de référence comme la Base Carbone de l’ADEME (France, gratuite et publique), ecoinvent (Suisse, référence académique et industrielle) ou DEFRA (Royaume-Uni).
Pourquoi relier comptabilité carbone et ERP plutôt qu’un outil isolé
La tentation est de déployer un outil ESG dédié, connecté à un export mensuel de l’ERP. Cette approche fonctionne pour un premier rapport, pas pour une comptabilité carbone opérationnelle pérenne.
Les trois arguments décisifs en faveur d’une intégration ERP native :
- Auditabilité : chaque donnée ESG doit être traçable jusqu’à sa facture ou son ordre de production source. Un ERP offre cette piste d’audit, un outil tiers alimenté par export CSV non.
- Fréquence : piloter ses émissions en temps réel (ou mensuel) nécessite un flux de données continu. L’export trimestriel vers un outil isolé ne permet pas de détecter une dérive en cours d’exercice.
- Coût de maintenance : deux référentiels de données à maintenir en parallèle, c’est deux fois plus de risques de divergence et de ressaisie.
Scope 1 dans l’ERP : les émissions directes
Gaz naturel, fuel, fluides frigorigènes : comment les modules énergie et actifs tracent les consommations
Le Scope 1 est le plus simple à intégrer car il correspond à des consommations physiques mesurables et facturées. Dans un ERP industriel, les sources de données pertinentes sont :
- Module gestion des actifs (EAM/CMMS) : relevés de compteurs gaz et fuel par équipement, ordres de maintenance avec consommation associée.
- Module achats : lignes de facture fournisseur énergie (gaz naturel, fioul domestique, propane) avec volume en m³ ou en litres.
- Module stocks : consommation de matières premières impliquant une combustion (coke, charbon, biomasse).
Pour les fluides frigorigènes, souvent invisibles dans les systèmes de gestion courants, le module de maintenance est la seule source fiable : chaque intervention de recharge doit générer un ordre de travail avec le volume rechargé en kg, le type de fluide (R410A, R32, HFO) et le PRG (potentiel de réchauffement global) associé.
La clé de l’intégration : créer dans l’ERP une nomenclature “facteur d’émission” associée à chaque type d’énergie ou de fluide, puis calculer automatiquement le résultat en tCO2e à partir du volume consommé.
Flottes de véhicules : l’ERP comme source de vérité kilométrique
Pour les flottes d’entreprise intégrées à l’ERP (via un module transport ou gestion des notes de frais), les kilométrages parcourus constituent la base du calcul Scope 1. La méthode de calcul : kilométrage x facteur d’émission par type de véhicule (essence, diesel, électrique, hybride) et par catégorie (VP, utilitaire léger, poids lourd).
Les facteurs d’émission véhicule sont disponibles dans la Base Carbone ADEME pour le périmètre français, et dans le référentiel DEFRA pour le périmètre international.
Scope 2 dans l’ERP : l’électricité et la chaleur achetée
Intégrer les factures énergétiques et les facteurs d’émission (marché vs localisation)
Le calcul des émissions Scope 2 repose sur deux méthodes officielles définies par le GHG Protocol :
- Méthode localisation (location-based) : on applique le facteur d’émission moyen du réseau électrique national au kWh consommé. Pour la France, le facteur d’émission de l’électricité est l’un des plus bas d’Europe grâce au parc nucléaire (environ 50 gCO2e/kWh en 2024 selon RTE).
- Méthode marché (market-based) : on applique le facteur d’émission spécifique du contrat d’énergie souscrit, notamment si l’entreprise a souscrit des garanties d’origine (GO) ou des contrats d’achat d’énergie renouvelable (PPA).
L’ERP doit stocker, pour chaque site et chaque compteur, les kWh consommés par période, le type de contrat (réseau standard, GO, PPA) et le facteur d’émission applicable. Ce paramétrage se fait généralement dans le module gestion des sites ou dans la comptabilité analytique par centre de coûts.
La difficulté des contrats d’énergie verte : traitement dans le module achats
Les garanties d’origine et les PPA créent une complexité comptable : l’électricité physiquement consommée provient toujours du réseau, mais le contrat “label” permet de revendiquer des émissions nulles selon la méthode marché. Cette distinction doit être tracée dans l’ERP pour être défendable en audit.
Concrètement : le module achats doit distinguer les lignes de facturation “énergie” standard des lignes “garanties d’origine” associées, et le calcul Scope 2 doit pouvoir produire les deux méthodes en parallèle. Le CSRD et le GHG Protocol exigent la publication des deux.
Scope 3 dans l’ERP : le défi des émissions indirectes
Selon les données publiées par CDP en 2024, les émissions de chaîne d’approvisionnement des entreprises sont en moyenne 26 fois supérieures à leurs émissions opérationnelles directes (Scopes 1 et 2). Pour une ETI industrielle, le Scope 3 représente l’essentiel de l’empreinte carbone totale, et la catégorie “achats de biens et services” (catégorie 1) en constitue souvent la part la plus importante.
Catégorie 1 (achats) : enrichir les articles et fournisseurs avec des facteurs d’émission
La méthode la plus opérationnelle pour calculer le Scope 3 catégorie 1 dans l’ERP consiste à enrichir le référentiel articles et fournisseurs avec des facteurs d’émission unitaires. Deux niveaux de granularité sont possibles :
- Facteur par catégorie d’achat : on attribue un facteur d’émission moyen (en kgCO2e/€ ou kgCO2e/kg) à chaque famille d’achat, issu de la Base Carbone ADEME ou d’ecoinvent. C’est la méthode “spend-based”, rapide à déployer, moins précise.
- Facteur par fournisseur spécifique : le fournisseur communique son bilan carbone produit et l’ETI intègre ce facteur dans la fiche fournisseur de l’ERP. C’est la méthode “supplier-specific”, plus précise mais qui suppose un engagement de la chaîne d’approvisionnement.
Un point de vigilance sur le “double counting” : les émissions Scope 3 catégorie 1 d’un acheteur correspondent aux Scopes 1 et 2 de son fournisseur. Ce chevauchement est voulu par le GHG Protocol et n’est pas une erreur, mais il doit être documenté pour éviter de mal interpréter les agrégats sectoriels.
Catégories transport et logistique : intégration TMS et ERP pour les émissions fret
Le transport de marchandises (catégorie 4, amont, et catégorie 9, aval) est une source significative pour les ETI industrielles distributrices. Le calcul repose sur : distance x poids transporté x facteur d’émission par mode (camion, train, avion, maritime).
Si l’entreprise dispose d’un TMS (transport management system) connecté à l’ERP, les données de transport sont déjà structurées. L’enrichissement en facteurs d’émission peut se faire via les référentiels FRET21 (initiative sectorielle française) ou les facteurs DEFRA pour les transports internationaux.
Sans TMS, les lignes de facturation transporteur dans le module achats constituent la base de calcul, à condition de capturer le mode de transport et le poids sur chaque ligne.
Catégorie 11 (usage des produits vendus) : simulation dans le module commercial
Pour les industriels dont les produits consomment de l’énergie pendant leur utilisation (équipements électriques, véhicules, systèmes thermiques), la catégorie 11 du Scope 3 peut dépasser en volume toutes les autres catégories réunies.
L’ERP, via le module commercial, contient les volumes vendus par référence produit. Pour calculer les émissions d’usage, il faut modéliser la consommation annuelle par unité vendue (en kWh ou en litres) et la durée de vie moyenne du produit, puis appliquer les facteurs d’émission correspondants.
Cette simulation doit être versionnée annuellement car les facteurs d’émission des réseaux électriques évoluent.
Solutions du marché : modules natifs vs outils dédiés
SAP Sustainability Footprint Management : points forts et limites
SAP propose depuis 2022 une solution dédiée, SAP Sustainability Footprint Management, conçue pour calculer l’empreinte carbone au niveau produit et entreprise en s’appuyant sur les données SAP S/4HANA. Les mises à jour Q1 2026 ont notamment amélioré les calculs de transport et l’attribution entre Scope 3.1 et 3.2 pour les achats de produits.
Les points forts : nativité avec l’écosystème SAP, conformité GHG Protocol et PACT V3, calcul en temps réel, piste d’audit intégrée. Les limites : tarification additionnelle significative, pertinente principalement pour les grands comptes et ETI déjà sur S/4HANA, courbe de paramétrage non négligeable.
Microsoft Sustainability Manager (intégré à Dynamics 365) : pertinence pour ETI
Microsoft Sustainability Manager est intégré à la plateforme Dynamics 365 et Cloud for Sustainability. Les versions 2025-2026 incluent le product carbon footprinting via nomenclatures (bills of materials), l’allocation d’émissions par unité organisationnelle, le verrouillage de périodes de reporting et le suivi du mix réseau électrique.
Pour une ETI sous Dynamics 365 Business Central ou Finance, c’est l’option la plus naturelle pour éviter un silo ESG externe. La maturité fonctionnelle est moindre que SAP SFM sur les scénarios industriels complexes, mais elle couvre la grande majorité des besoins d’une ETI de services ou de distribution.
Alternatives middleware et outils dédiés
Pour les ETI dont l’ERP ne propose pas de module sustainability natif mature, des outils dédiés s’intercalent en middleware :
- Persefoni : plateforme cloud orientée finance, forte en Scope 3 catégories financières (investissements, crédits), utilisée par des groupes financiers et leurs filiales industrielles.
- Watershed : orienté automatisation des collectes via API et connecteurs ERP standards, fort en Scope 3 supply chain.
- Plan A : éditeur européen (Berlin), fort en conformité CSRD/ESRS, bon rapport fonctionnalité/prix pour les ETI 200-2000 salariés.
Le critère de choix entre module natif et outil dédié dépend principalement du niveau d’intégration requis : si vous avez besoin d’une piste d’audit native et d’une mise à jour en temps réel des données ERP, le module natif s’impose. Si vous avez des sources hétérogènes (ERP + Excel + fournisseurs en CSV), un middleware peut s’avérer plus souple à court terme.
Mettre en place la comptabilité carbone dans l’ERP : plan en 4 phases
Phase 1 : cartographier les flux de données existants dans l’ERP
Avant tout paramétrage, documentez précisément quelles données existent dans votre ERP, leur qualité et leur granularité. Questions clés : les consommations d’énergie sont-elles saisies par site ou globalement ? Les achats de matières premières sont-ils distingués par type dans le plan comptable ou dans le référentiel articles ? Les kilométrages de flotte sont-ils tracés ou uniquement les remboursements en euros ?
Cette cartographie prend généralement deux à quatre semaines avec un consultant fonctionnel ERP et un expert carbone. Elle détermine le périmètre réaliste de la version 1 de votre comptabilité carbone ERP.
Phase 2 : enrichir les référentiels (articles, fournisseurs, sites) avec les facteurs d’émission
C’est le chantier de données le plus long. Il s’agit d’ajouter dans l’ERP des champs de facteur d’émission (en kgCO2e par unité) sur les articles achetés, les types d’énergie, les véhicules et les sites de production.
La Base Carbone ADEME est le point de départ pour les entreprises françaises. Gratuite, régulièrement mise à jour, elle couvre des centaines de catégories de matières, d’énergies et de services. Pour les achats importés ou pour les fournisseurs actifs sur d’autres marchés, ecoinvent et DEFRA complètent la couverture.
Phase 3 : automatiser la collecte et les calculs (connecteurs API, batch)
Une fois les référentiels enrichis, les calculs d’émission doivent tourner automatiquement à chaque transaction pertinente (réception d’une facture d’énergie, validation d’un bon de commande fournisseur, clôture d’un ordre de fabrication). C’est le rôle des règles de calcul configurées dans le module sustainability ou dans un middleware connecté à l’ERP.
L’objectif final : produire un tableau de bord mensuel des émissions par scope, par site, par famille d’achat, sans aucune intervention manuelle, avec un lien traçable jusqu’à la transaction source.
Phase 4 : valider et auditer (alignement avec le CSRD et les experts tiers)
La première version des calculs doit être passée en revue par un expert carbone externe avant d’être intégrée dans un rapport CSRD officiel. Les points de contrôle clés : cohérence des périmètres (exclusions justifiées documentées), sources des facteurs d’émission (date, version, base de référence), traitement des émissions biogéniques, et conformité à la méthode GHG Protocol retenue (location-based ou market-based pour le Scope 2).
Pour les ETI soumises au CSRD dès l’exercice 2025, le rapport sera audité par un OTI (organisme tiers indépendant). La piste d’audit ERP est un argument fort face à l’auditeur : chaque chiffre doit être raccordé à une transaction, pas à un tableur.
Ce que l’ERP change dans le bilan carbone
L’ERP ne simplifie pas la comptabilité carbone, il la rend soutenable dans la durée. Sans lui, la collecte de données reste manuelle, fragmentée et non auditée. Avec lui, elle devient un processus de gestion comme la comptabilité financière : structuré, traçable, et exploitable pour piloter des décisions (substitution de fournisseurs, électrification de flotte, renégociation de contrats d’énergie).
Ce que l’ERP ne change pas : la complexité intrinsèque du Scope 3, notamment la dépendance aux données fournisseurs. Un ERP parfaitement paramétré avec de mauvais facteurs d’émission produit un mauvais bilan carbone. La qualité des données en entrée reste le facteur limitant numéro un.
Pour approfondir, découvrez notre guide complet sur le CSRD et le reporting durabilité dans l’ERP et notre article sur la taxe carbone aux frontières de l’UE (CBAM) et les obligations ERP associées.
