Un bilan carbone produit avec l'IA peut être exact et invérifiable en même temps. C'est le piège : le chiffre final s'affiche vite, mais rien ne garantit qu'il tienne devant un vérificateur BEGES ou un OTI si la donnée d'activité, le facteur d'émission et la version de la base utilisée ne sont pas documentés à chaque ligne.
Cet article traite la fiabilité et l'auditabilité d'un bilan carbone IA : ce qu'il faut anticiper avant de lancer une démarche outillée, ce qu'il faut vérifier sur un résultat déjà produit, et ce que change une architecture MCP (Model Context Protocol) dans la traçabilité des calculs. Il ne traite pas l'automatisation de la collecte ni le calcul des scopes en tant que tels : ce sujet est couvert dans notre guide sur le bilan carbone avec l'IA.
Sommaire
Ce qu'il faut anticiper avant de lancer une démarche outillée par l'IA
Trois questions se posent avant le premier calcul, pas après.
Quelle base de facteurs, quelle version, quelle géographie
Un facteur d'émission n'est pas une constante universelle. Une même dépense de gaz naturel calculée avec la Base Carbone ADEME, avec DEFRA ou avec EPA ne donne pas le même résultat en tCO2e, parce que ces bases reflètent des mix énergétiques et des méthodologies différentes. À l'intérieur d'une même base, le millésime compte aussi : un facteur électricité mis à jour l'année suivante peut changer significativement le résultat d'un poste sans qu'aucune donnée d'activité n'ait bougé.
Avant de lancer un calcul, il faut donc pouvoir répondre à trois questions simples pour chaque poste :
Un facteur électricité appliqué au mauvais pays fausse le résultat d'un ordre de grandeur, pas d'un pourcentage marginal.
La reproductibilité du calcul
Un bilan carbone n'a de valeur comparative que s'il peut être refait à l'identique. Si le même jeu de données d'activité, recalculé six mois plus tard, produit un chiffre différent sans qu'aucun changement méthodologique ne soit documenté, la comparaison d'une année sur l'autre perd son sens. La reproductibilité suppose que chaque calcul historique reste figé avec la version de facteur qui a servi à le produire, même quand la base évolue ensuite.
La séparation entre ce que la machine propose et ce que l'humain valide
Un système qui suggère un facteur, une catégorisation ou une valeur estimée n'a pas la même autorité qu'un système qui écrit directement le résultat final sans validation. Avant de démarrer, il faut savoir où se situe la frontière : quelles étapes restent une proposition soumise à validation humaine, et lesquelles sont automatisées sans repasser par un contrôle. Plus cette frontière est floue, plus le bilan est difficile à défendre en cas de contestation.
Ce qu'il faut vérifier sur un résultat produit avec de l'IA
Une fois le bilan produit, la vérification porte sur cinq points.
La traçabilité jusqu'à la pièce justificative
Chaque ligne de calcul doit pouvoir remonter jusqu'à sa source : la facture, le relevé, la déclaration fournisseur. Un chiffre sans document attaché n'est pas vérifiable, même s'il est probablement juste. C'est particulièrement sensible sur les données extraites automatiquement par OCR, où le mapping d'une facture vers une catégorie GHG Protocol doit rester consultable et corrigible, pas figé en boîte noire.
La justification du facteur retenu, pas seulement sa valeur
Il ne suffit pas d'afficher le facteur utilisé. Il faut pouvoir expliquer pourquoi ce facteur a été choisi plutôt qu'un autre pour cette donnée d'activité précise : correspondance de catégorie, de géographie, d'unité. Un facteur juste choisi pour une mauvaise raison reste un point faible en audit.
Les hypothèses, exclusions et critères de coupure documentés
Tout bilan comporte des postes exclus ou simplifiés, des seuils de matérialité, des hypothèses de calcul. Ces choix doivent être écrits noir sur blanc, pas déduits a posteriori. Un vérificateur qui découvre une exclusion non documentée pendant l'audit remet en question l'ensemble de la méthodologie.
Le traitement des valeurs estimées
Une donnée estimée (facteur monétaire, valeur par défaut, extrapolation) n'a pas la même fiabilité qu'une donnée mesurée. Elle doit être identifiée comme telle dans le résultat, pas mélangée aux données primaires sans distinction visuelle ou documentaire.
La cohérence des unités et l'absence de doublons
Une unité mal convertie (kg contre tonne, kWh contre MWh) ou une même facture comptée deux fois dans deux catégories sont des erreurs fréquentes dans les imports volumineux. Elles doivent être détectées avant validation, pas découvertes en audit.
MCP : pourquoi un assistant qui appelle des outils est plus fiable qu'un assistant qui répond de mémoire
Le Model Context Protocol (MCP) est un protocole qui permet à un assistant conversationnel d'appeler des outils externes, par exemple une base de facteurs d'émission ou les données réelles d'un projet carbone, au lieu de générer une réponse uniquement à partir de ce qu'il a mémorisé pendant son entraînement.
La différence est concrète. Un modèle de langage interrogé seul, sans accès à une base de données, peut produire un facteur d'émission qui a l'air plausible mais qui est faux : ce n'est pas un bug isolé, c'est une conséquence structurelle du fonctionnement des LLM, qui génèrent la réponse la plus probable statistiquement plutôt que la réponse vérifiée dans une source. Avec une architecture MCP, ce même assistant interroge un outil qui pointe vers une base de facteurs identifiée et versionnée, et retourne une valeur sourcée, avec sa base d'origine et sa version.
Trois conséquences pour l'auditabilité :
Cette architecture ne supprime pas le besoin de validation humaine. Elle change la nature de l'erreur possible : au lieu d'un chiffre halluciné et indétectable, on obtient un chiffre sourcé, contestable ou corrigible sur la base identifiée.
Sauvegarder et historiser : la condition d'un bilan défendable
Un bilan carbone n'est pas seulement un résultat final. Ce qui rend un chiffre défendable en vérification tierce, c'est la conservation de quatre éléments pour chaque ligne de calcul :
Sans cette historisation, un bilan recalculé plus tard perd la trace de la méthodologie qui a produit le chiffre initial. Un tableur où seul le résultat final est conservé, sans figer la version du facteur utilisée à l'époque, ne permet pas de reconstituer le raisonnement six mois ou un an après. C'est un point que les référentiels de vérification examinent directement : la norme ISO 14064-3 encadre la validation et la vérification des déclarations de gaz à effet de serre, avec deux niveaux d'assurance (assurance limitée et assurance raisonnable), et la CSRD impose une assurance par un tiers sur les données d'émissions et démarre au niveau de l'assurance limitée. Le passage à une assurance raisonnable est envisagé par la Commission à l'horizon d'octobre 2028, sous réserve de faisabilité, et n'est donc pas acquis à ce jour. ISO 14064-3 n'est pas imposée explicitement par la CSRD, mais c'est le référentiel communément retenu pour conduire cette vérification, aux côtés du GHG Protocol Corporate Standard pour la comptabilisation elle-même. Un vérificateur qui applique ce type de cadre demande précisément la reconstitution de chaque assertion, pas seulement le total.
Ce que fait Kabaun pour l'auditabilité
Kabaun construit son architecture IA autour de ce principe de contrôle, pas de délégation aveugle :
FAQ : IA et fiabilité du bilan carbone
Un bilan carbone calculé avec l'IA peut-il être audité comme un bilan manuel ?
Oui, à condition que chaque ligne de calcul reste traçable jusqu'à sa source et que le facteur utilisé soit documenté avec sa version et sa base d'origine. L'auditeur ne certifie pas l'outil, il certifie la qualité et la traçabilité des données produites. Un système qui ne conserve que le résultat final, sans historiser les paramètres du calcul, est plus difficile à défendre qu'un tableur bien documenté.
Pourquoi un même poste calculé avec deux bases de facteurs différentes donne des résultats différents ?
Chaque base de facteurs (ADEME, DEFRA, EPA, Ecoinvent, etc.) reflète des hypothèses méthodologiques et des mix énergétiques propres à sa zone géographique et à sa date de publication. Utiliser un facteur électricité français pour un site situé en Allemagne, par exemple, applique un mix de production différent et fausse le résultat. Documenter la base et la géographie retenues pour chaque poste est indispensable pour comprendre et défendre un écart.
Un modèle d'IA générative peut-il inventer un facteur d'émission ?
Oui. Un modèle de langage interrogé sans accès à une base vérifiée génère la réponse statistiquement la plus probable, pas une valeur vérifiée dans une source. Il peut produire un facteur d'émission plausible mais faux. C'est pour cette raison qu'une architecture qui connecte l'assistant à une base de facteurs identifiée, via un protocole comme MCP, réduit ce risque en donnant à l'assistant un accès direct à une source versionnée au lieu d'une réponse générée librement.
Qu'est-ce que le Model Context Protocol (MCP) appliqué au bilan carbone ?
Le MCP est un protocole qui permet à un assistant conversationnel d'appeler des outils externes, par exemple une base de facteurs d'émission ou les données d'un projet carbone, plutôt que de répondre uniquement à partir de sa mémoire d'entraînement. Appliqué au bilan carbone, il permet à l'assistant de retourner une valeur sourcée et traçable, avec l'authentification déléguée à l'utilisateur qui l'interroge.
Quelles données faut-il conserver pour qu'un bilan carbone reste défendable dans le temps ?
Pour chaque ligne de calcul : la donnée d'activité brute, le facteur d'émission utilisé avec sa version et sa base d'origine, la source documentaire (facture, relevé, déclaration) et la date du calcul. Sans cette historisation, un bilan recalculé plus tard perd la trace de la méthodologie qui a produit le chiffre initial, ce qui complique toute vérification tierce.
Une valeur estimée par l'IA doit-elle être traitée différemment d'une donnée mesurée ?
Oui. Une valeur estimée (facteur monétaire, extrapolation, valeur par défaut) porte une incertitude plus élevée qu'une donnée mesurée directement. Elle doit être identifiée comme telle dans le résultat et validée explicitement par un utilisateur avant d'être intégrée au bilan final, plutôt que d'être mélangée aux données primaires sans distinction.
Conclusion
La confiance dans un bilan carbone IA ne se décrète pas, elle se vérifie : base de facteurs documentée, calcul reproductible, traçabilité jusqu'à la pièce justificative, et séparation claire entre ce que l'IA propose et ce que l'humain valide. Une architecture MCP renforce cette auditabilité en connectant l'assistant à des sources identifiées plutôt qu'à sa seule mémoire, mais elle ne remplace pas le contrôle humain sur les choix méthodologiques.
Avant de valider un bilan produit avec de l'IA, reprenez la checklist de cet article poste par poste : base et version du facteur, source documentaire, traitement des valeurs estimées, cohérence des unités.
**Kabaun vous accompagne dans un bilan carbone auditable → www.kabaun.com/contact**
