Comprendre l’impact de vos usages IA, et le réduire.
Mesurer la consommation d'un LLM : six voies, et ce que chacune prouve
Compteurs d'API, compteurs d'interface, estimation depuis la page, compteurs de prompts Microsoft 365, mesure matérielle. Chaque voie compte quelque chose de différent, et toutes ne valent pas la même chose devant un commissaire aux comptes.
On ne mesure presque jamais l'énergie d'une IA hébergée : on compte un volume d'activité, puis on lui applique un facteur publié. Toute la rigueur de l'exercice tient donc à deux questions, quelle unité est réellement disponible, et qui atteste de cette quantité. Les six voies ci-dessous répondent différemment aux deux.
Version de méthodologie appliquée aux exports : 2026.03.1.
1. La première question n'est pas « combien », c'est « en quoi »
Trois unités circulent, et elles ne sont pas interchangeables. Le token est l'unité de facturation des API : c'est la seule que le fournisseur compte lui-même et qu'il accepte de vous communiquer. Le prompt est l'unité des rapports d'usage des suites bureautiques : un prompt peut valoir cent tokens ou dix mille. Le wattheure est l'unité physique, accessible uniquement si la machine vous appartient.
Un outil qui affiche un chiffre sans dire laquelle de ces trois unités il a comptée ne permet pas de vérifier quoi que ce soit. C'est la raison pour laquelle chaque ligne de notre registre porte sa base de mesure, et pourquoi un total agrégeant plusieurs bases doit en indiquer la composition.
2. Les six voies de mesure
Classées par ce qu'elles permettent d'établir, pas par leur facilité de mise en œuvre.
La quantité vient de celui qui a rendu le service. C'est le niveau qu'un commissaire aux comptes rapprochera d'une facture.
Mesuré sur le matériel
La quantité est relevée sur la machine qui calcule. Niveau le plus élevé, mais disponible seulement sur un modèle auto-hébergé.
Estimé
La quantité est déduite de ce qui est observable. Acceptable la première année si la méthode est écrite, à condition d'être signalée comme telle.
2.1 Compteurs de l'API
Comment la valeur est obtenue
La réponse de l'API contient un bloc d'usage que le fournisseur remplit lui-même : `prompt_tokens` / `completion_tokens` sur les API compatibles OpenAI, `input_tokens` / `output_tokens` chez Anthropic, `promptTokenCount` / `candidatesTokenCount` chez Google. La valeur n'est pas reconstituée : elle est lue.
Où cette voie s'applique
Tout appel serveur à une API de complétion. C'est la seule voie disponible quand l'IA est appelée depuis votre code plutôt que depuis un navigateur.
Ce qu'elle prouve
Le volume exact facturé par le fournisseur pour cette requête, rapprochable de sa facture.
Ce qu'elle ne prouve pas
Ne dit rien de l'énergie consommée : il faut encore un facteur par modèle, qui lui n'est pas mesuré chez vous.
2.2 Compteurs exposés par l'interface web
Comment la valeur est obtenue
L'interface d'un assistant parle à son propre backend. Quand cette réponse contient le même bloc d'usage que l'API, le compte est lu à la source, sans estimation.
Où cette voie s'applique
Variable, et instable : les backends d'assistants grand public changent souvent de format. Une plateforme qui expose ses compteurs un mois peut cesser le mois suivant.
Ce qu'elle prouve
Le volume réel de l'échange, au même niveau de preuve qu'un appel API.
Ce qu'elle ne prouve pas
La disponibilité n'est pas contractuelle. Une méthode qui en dépend doit prévoir le cas où le compteur disparaît, et le signaler plutôt que de basculer silencieusement en estimation.
2.3 Estimation depuis le texte affiché
Comment la valeur est obtenue
Quand aucun compteur n'est exposé, le volume est déduit du texte déjà rendu dans l'onglet, à raison d'environ 4 caractères par token. Le texte est compté sur le poste et n'est ni stocké ni transmis.
Où cette voie s'applique
Les surfaces qui n'exposent pas d'usage. C'est notamment le cas des surfaces de travail Microsoft 365, dont le backend ne renvoie aucun bloc d'usage.
Ce qu'elle prouve
Un ordre de grandeur, et surtout une trace qu'une interaction a eu lieu.
Ce qu'elle ne prouve pas
Le ratio caractères/tokens varie avec la langue et le contenu ; un raisonnement non affiché n'est pas compté. Une ligne obtenue ainsi ne doit jamais être présentée au même niveau qu'un compteur fournisseur.
2.4 Compteurs de prompts du fournisseur
Comment la valeur est obtenue
Microsoft Graph expose des rapports d'usage de Microsoft 365 Copilot : combien de prompts, dans quelle application, par utilisateur et par jour. L'identifiant utilisateur est haché avant stockage.
Où cette voie s'applique
Les tenants Microsoft 365 avec licences Copilot, via une application Entra en permission applicative Reports.Read.All.
Ce qu'elle prouve
Un volume d'activité attesté par le fournisseur du service, à l'échelle d'une organisation entière, sans rien installer sur les postes.
Ce qu'elle ne prouve pas
Ce sont des prompts, pas des tokens. Aucune conversion fiable n'existe entre les deux : il faut passer par une énergie par prompt, pas par un facteur au token. Les rapports accusent par ailleurs un délai de l'ordre de deux jours.
2.5 Compteurs d'activité du fournisseur
Comment la valeur est obtenue
Certaines API d'administration ne comptent ni tokens ni prompts, mais des événements : suggestions acceptées, tours de chat, lancements d'agents, parfois des « crédits ». Le volume est attesté, son contenu énergétique ne l'est pas.
Où cette voie s'applique
Les agents tiers remontés par GitHub Copilot, l'analytique de ChatGPT Enterprise, et plus largement tout fournisseur qui publie de l'adoption plutôt que de la consommation.
Ce qu'elle prouve
Qu'une activité a eu lieu, dans quel volume, et chez qui, ce qui suffit déjà à borner un périmètre et à repérer un usage non déclaré.
Ce qu'elle ne prouve pas
Aucun facteur publié ne relie une interaction à une énergie : une suggestion ne dit ni la longueur du contexte envoyé, ni celle de la réponse, ni le modèle appelé, et une suggestion refusée a quand même été calculée. Nous reportons donc le volume et laissons l'empreinte non quantifiée, plutôt que d'inventer le chiffre que nous prétendons mesurer.
2.6 Mesure matérielle directe
Comment la valeur est obtenue
Lecture des compteurs du matériel pendant l'inférence : RAPL côté processeur, NVML côté GPU. C'est la seule voie qui mesure de l'énergie plutôt que de la déduire.
Où cette voie s'applique
Un modèle que vous exécutez vous-même, sur une machine à laquelle vous avez accès.
Ce qu'elle prouve
L'énergie réellement consommée par le calcul, sur ce matériel-là.
Ce qu'elle ne prouve pas
Inapplicable à un modèle hébergé : vous n'avez pas accès aux machines du fournisseur. Et la mesure brute ignore le refroidissement et le reste de l'infrastructure, c'est l'objet du périmètre choisi plus bas.
3. Du volume au gramme : le facteur par modèle
Compter des tokens ne donne pas des grammes. Il faut un facteur propre au modèle, et c'est là que la qualité des données se joue vraiment, bien plus que dans la précision du comptage. Notre table en contient 53, chacun portant un niveau de confiance explicite :
Mesuré, une analyse de cycle de vie publiée par l'opérateur du modèle. C'est rare : quatre entrées sur cinquante-trois. L'analyse de cycle de vie de Mistral Large 2, conduite avec Carbone 4 et l'ADEME, en fait partie.
Évalué, un travail académique mesurant plusieurs modèles sur un protocole commun. Vingt-six entrées, issues pour l'essentiel de Jegham et al. et de l'AI Index de Stanford.
Estimé, une dérivation par classe d'architecture, faute de publication sur ce modèle précis. Vingt-quatre entrées. À traiter comme un ordre de grandeur.
L'écart entre les modèles est considérable : de 0,05 à 6,97 gCO₂e pour 1 000 tokens selon la ligne, soit un facteur cent-quarante. Choisir un modèle plus sobre pour les tâches simples pèse donc beaucoup plus lourd que n'importe quelle optimisation de prompt.
4. Deux conventions de longueur, et pourquoi les chiffres divergent
Les publications expriment leurs résultats par requête, pas par token. Les ramener à 1 000 tokens suppose donc de fixer une longueur de requête, et deux conventions coexistent dans la littérature. C'est l'explication la plus fréquente des écarts entre outils, avant toute question de méthode.
Les deux sont défendables. Elles ne sont simplement pas additionnables : comparer un modèle normalisé sur 400 tokens à un modèle normalisé sur 2 000 produit un écart qui ne doit rien à la sobriété des modèles. Une table de coefficients honnête indique donc, pour chaque ligne, laquelle des deux elle applique.
5. Le cas Microsoft 365 : des prompts, pas des tokens
C'est le cas le plus courant en entreprise, et celui que la plupart des méthodes traitent mal. Les rapports d'usage de Microsoft Graph donnent un nombre de prompts par utilisateur et par jour. Le backend des surfaces de travail, lui, ne renvoie aucun bloc d'usage : il n'y a pas de tokens à lire, ni dans l'API de reporting, ni dans la page.
Appliquer un facteur au token à un parc Copilot revient donc à inventer la quantité qu'on prétend mesurer. La seule voie cohérente est une énergie par prompt, différenciée selon le type de requête :
Type de requête
Médiane
Fourchette (Wh)
Source primaire
Conversation (web)
0,31 Wh
0,16 – 0,60
OuiPubliée par Microsoft le 15 juin 2026. Auto-déclarée par le fournisseur du service mesuré, et intégrant déjà l'efficacité du centre de données : lui appliquer un multiplicateur d'infrastructure compterait deux fois.
Conversation ancrée sur vos données
0,31 Wh
0,16 – 0,60
NonAucune source primaire ne chiffre ce surcoût en Wh. La médiane reste alignée sur la conversation web ; seule la borne haute est élargie, d'après la tarification de Copilot Studio (12 crédits avec ancrage contre 2 sans) et le rapport d'environ 3 observé sur le RAG. Un prix n'est pas une énergie : la médiane ne bouge pas.
Action d'agent
3,91 Wh
2,15 – 7,05
OuiMême publication : réponse d'environ 5 000 tokens. Les tâches agentiques en plusieurs étapes sont annoncées comme plus coûteuses, sans chiffre.
La deuxième ligne mérite qu'on s'y arrête. Une conversation ancrée sur les documents d'une organisation déclenche une recherche puis une génération : elle consomme vraisemblablement plus qu'une conversation web. Aucune source primaire ne chiffre ce surcoût. Plutôt que de retenir un multiplicateur inventé, nous alignons la valeur sur la conversation web et nous déclarons la ligne comme dépourvue de source primaire. Le chiffre est probablement sous-estimé, et c'est écrit, ce qui vaut mieux qu'un chiffre plus flatteur que personne ne peut défendre.
6. Le périmètre : ce que le chiffre inclut
Même énergie de calcul, trois chiffres possibles selon ce qu'on y rattache. Le multiplicateur doit être choisi une fois, écrit, et tenu d'un exercice sur l'autre.
× 1,0
Dynamique
Aucun multiplicateur. C'est le périmètre à retenir quand la valeur du fournisseur intègre déjà l'infrastructure, comme celle de Microsoft pour Copilot : y ajouter un coefficient compterait deux fois.
× 1,6
Opérationnel
Le calcul, plus le refroidissement et l'infrastructure du centre de données.
× 2,05
Cycle de vie
L'opérationnel, plus la fabrication et la fin de vie du matériel amorties sur son usage. Le seul périmètre cohérent avec une approche ISO 14067 lorsque le coefficient de départ est de l'électricité seule. Un coefficient déjà issu d'une analyse de cycle de vie (Mistral Large 2) n'est pas multiplié : la source ne publie pas la part à retirer.
Le même prompt, chez le même fournisseur, vaut 0,10 ou 0,24 Wh
Google a publié les deux chiffres côte à côte pour un prompt texte médian de Gemini Apps. En ne comptant que les accélérateurs : 0,10 Wh et 0,02 gCO₂e. En comptant aussi le processeur hôte, la mémoire, les machines provisionnées mais inactives et l'efficacité du centre de données : 0,24 Wh et 0,03 gCO₂e, plus 0,26 mL d'eau. Un facteur 2,4 sur la même requête.
Google qualifie lui-même le périmètre restreint d'« optimiste au mieux ». Un chiffre de consommation sans périmètre déclaré est donc, au choix, invérifiable ou flatteur, et c'est la première chose qu'un lecteur attentif cherchera.
Le piège symétrique est le double comptage : appliquer le multiplicateur opérationnel à une valeur qui intègre déjà l'infrastructure gonfle le résultat de soixante pour cent sans justification physique. Quand le fournisseur ne dit pas ce que son chiffre couvre, c'est le cas de l'estimation Microsoft pour Copilot, la position défendable est de ne rien ajouter et de l'écrire, plutôt que de choisir en silence.
7. Ce qu'un auditeur regarde réellement
Le réflexe est de chercher le chiffre le plus juste. Ce n'est pas le critère. ESRS E1 admet l'estimation pour un premier exercice ; ce qu'il n'admet pas, c'est une valeur dont la provenance n'est pas documentée. Les quatre questions qui reviennent :
D'où vient la quantité ? Compteur du fournisseur, compteur de prompts, ou estimation, et dans quelle proportion dans le total.
D'où vient le facteur ? Une référence citable, avec sa date et sa convention de longueur.
Quel périmètre ? Et le même d'un exercice à l'autre, sinon la trajectoire de réduction ne veut rien dire.
Quelles hypothèses ? Écrites par ligne, pas en note de bas de page d'un rapport annuel.
Une méthode fondée sur la dépense, appliquer un ratio monétaire à une facture, ne répond à aucune des quatre.
Ce que coûte une estimation par la dépense : un Scope 3 gonflé de 5 à 9 fois
Un travail du MIT Center for Transportation & Logistics, publié en mai 2026, a comparé les deux approches sur le cloud du MIT. Pour l'exercice 2025, la méthode par la dépense aboutit à 1 140 tonnes de CO₂e. Les données d'usage réelles du fournisseur donnent 236 tonnes en approche géographique et 144 tonnes en approche de marché, soit une surestimation d'un facteur 5,3 à 8,8.
L'explication est prosaïque : les pics de dépense suivent les cycles de facturation consolidée, pas l'usage réel du calcul. Une organisation qui déclare sur cette base ne fait donc pas qu'être imprécise, elle gonfle son propre Scope 3, s'engage sur une trajectoire qu'elle devra corriger à la baisse, et expose exactement la ligne qu'un auditeur examinera de près.
Les auteurs ne concluent pas qu'il faut bannir la méthode par la dépense : ils recommandent une approche mixte, données d'usage pour les grands fournisseurs et estimation par la dépense pour la longue traîne des petits prestataires. C'est aussi la position défendable pour une ligne IA.
8. À qui l'empreinte appartient-elle ?
Deux questions distinctes, souvent confondues. La première : dans quelle catégorie déclarer. La seconde : comment répartir entre plusieurs missions, clients ou entités.
Catégorie 1 ou catégorie 11
Scope 3, catégorie 1
Biens et services achetés : l’IA consommée par l’organisation pour son propre compte.
Scope 3, catégorie 11
Utilisation des produits vendus : l’inférence déclenchée chez le client par un logiciel livré.
Pour une entreprise de services, la distinction est tout sauf théorique : l'IA consommée pendant le développement relève de la catégorie 1, l'inférence déclenchée ensuite chez le client par le logiciel livré relève de la catégorie 11. La frontière n'est pas tranchée pour tous les contrats, notamment quand le prestataire continue de payer l'inférence en production. Dans ce cas, la classification s'arbitre et s'écrit ; elle ne se devine pas.
La hiérarchie d'allocation, et pourquoi elle se vend
Aucun référentiel n'impose de clé pour répartir un outil partagé entre plusieurs missions. En revanche, ISO 14067 et le GHG Protocol Product Standard imposent l'ordre dans lequel on cherche :
1. Éviter l’allocation
Rattacher directement l’usage à la mission quand c’est possible, un identifiant de projet porté par l’événement vaut mieux que n’importe quelle clé de répartition.
2. Relation physique
À défaut, répartir selon une grandeur physique réellement liée à la consommation : tokens, prompts, heures d’usage mesurées. Mesurable et vérifiable.
3. Allocation économique
En dernier ressort seulement : chiffre d’affaires, jours facturés. À justifier explicitement, en indiquant pourquoi les deux niveaux précédents n’étaient pas praticables.
La conséquence est plus sévère qu'il n'y paraît. Une organisation qui répartit son empreinte IA au chiffre d'affaires sans avoir d'abord cherché une relation physique n'est pas imprécise : elle est hors méthode. Or une relation physique existe ici, les tokens et les prompts sont comptés par utilisateur et par jour. Le niveau 2 est donc atteignable, ce qui rend le recours au niveau 3 difficile à justifier.
Questions fréquentes
Peut-on mesurer la consommation d'un LLM hébergé par un fournisseur ?
Non, pas au sens d'une mesure physique : vous n'avez pas accès aux machines. Ce que vous pouvez faire, c'est compter exactement le volume traité, les tokens que le fournisseur déclare dans sa réponse d'API, puis lui appliquer un facteur d'énergie publié. La quantité est attestée, le facteur est estimé. Seul un modèle que vous exécutez vous-même permet une mesure matérielle directe, par RAPL ou NVML.
Pourquoi deux outils donnent-ils des chiffres différents pour le même modèle ?
Le plus souvent à cause de la longueur de prompt retenue pour normaliser. Un chiffre ramené à 400 tokens et un chiffre ramené à 2 000 tokens ne sont pas comparables, même issus de la même source. Ensuite vient le périmètre : l'énergie du calcul seul, l'infrastructure incluse, ou le cycle de vie du matériel compris. Les deux outils peuvent être honnêtes et afficher un écart d'un facteur deux.
Microsoft 365 Copilot fournit-il un comptage de tokens ?
Non. Microsoft Graph expose un nombre de prompts par utilisateur et par jour, pas un volume de tokens, et le backend des surfaces de travail ne renvoie aucun bloc d'usage. Un calcul fondé sur un facteur au token n'est donc pas applicable à Copilot : il faut passer par une énergie par prompt. C'est une base de mesure distincte, et inférieure, qui doit apparaître comme telle dans le registre.
Une estimation est-elle acceptable pour un rapport CSRD ?
Oui pour un premier exercice, à condition que la méthode soit documentée et que la part estimée soit identifiable. Ce qu'un auditeur refuse n'est pas l'imprécision, c'est un chiffre dont personne ne peut dire d'où il vient. L'exigence pratique est donc de pouvoir isoler, ligne à ligne, ce qui est attesté par le fournisseur et ce qui est déduit.
Faut-il compter l'entraînement du modèle ?
Pas dans la ligne d'usage. L'entraînement est un coût amorti côté fournisseur, que l'utilisateur ne peut ni mesurer ni répartir honnêtement entre ses propres requêtes. Ce qui relève de votre inventaire, c'est l'inférence que vous avez consommée, classée en Scope 3 catégorie 1, comme tout service acheté.
Vous devez produire une ligne IA dans un rapport de durabilité ?
Le registre de preuve applique ces règles ligne à ligne : base de mesure, fourchette, hypothèses et version de méthode pour chaque événement.