Trois étapes. Le volume de tokens donne une énergie informatique, cette énergie devient l'énergie totale du site, puis on en tire le carbone et l'eau.
La formule fait cinq lignes, ce n'est pas là qu'est la difficulté. Le dur : choisir chaque paramètre, déclarer ce qu'on exclut, et accepter un fait contre-intuitif. Sur un usage agentique, la sortie pèse 0,73 % du volume et 48,5 % du carbone.
La formule
Les unités sont écrites à chaque ligne : c'est ce qui permet de repérer qu'une formule trouvée ailleurs ne ferme pas.
Bloc 1, du volume à l'énergie informatique.
E_IT = T_entrée × e_in + T_cache × e_in × f_cache + T_sortie × e_out
kWh = tokens × kWh/tk + tokens × kWh/tk × (sans) + tokens × kWh/tk
e_in et e_out sont les énergies unitaires, en kWh par token, mesurées sur le matériel de service. Ordre de grandeur sur H100 en lot unitaire : 6,05 × 10⁻⁸ kWh par token d'entrée contre 2,13 × 10⁻⁶ kWh par token de sortie, d'où le facteur 35 entre les deux.
f_cache est un rapport sans dimension : la fraction de l'énergie d'un token d'entrée frais que coûte encore un token relu depuis le cache. Valeur retenue 0,08, plage publiée de 0,05 à 0,20.
Bloc 2, de l'énergie informatique à l'énergie totale.
E_totale = E_IT × PUE
kWh = kWh × (sans dimension)
Bloc 3, de l'énergie aux impacts.
CO2e = E_totale × CIF + E_IT × EMB
gCO2e = kWh × gCO2e/kWh + kWh × gCO2e/kWh
Eau = E_IT × WUE_site + E_totale × WUE_amont
litres = kWh × L/kWh + kWh × L/kWh
Deux pièges d'unités, tous deux vus en mission. EMB s'applique à l'énergie informatique, pas à l'énergie totale : le carbone de fabrication est celui des accélérateurs, pas du groupe froid. Et WUE_site s'applique à l'énergie informatique quand WUE_amont s'applique à l'énergie totale, parce que l'eau de production électrique suit tout ce que le site tire du réseau.
Si vous voulez le facteur par token plutôt que le total, divisez la ligne carbone par le nombre de tokens et vous obtenez des gCO2e/token. C'est ce chiffre qui reste comparable dans le temps, là où un chiffre par requête vieillit.
Les grammes de CO2e émis pour produire un kilowattheure sur le réseau électrique où tourne le calcul. En 2025, environ 41 g en France, 384 aux États-Unis, 591 en Pologne, 459 en moyenne mondiale.
Seul ce terme dépend du pays, et le choisir demande trois décisions. Tous les autres sont des propriétés du matériel ou de l'exploitation.
Le carbone de fabrication du matériel, amorti sur sa durée de vie et ramené au kilowattheure informatique. Une carte de huit accélérateurs H100 porte 1 312 kgCO2e de fabrication, dont 42 % pour la seule mémoire (PCF NVIDIA HGX H100, juillet 2025, ISO 14067, cradle-to-gate, sans intervalle d'incertitude).
Ce terme ne dépend pas du réseau électrique. Plus le mix se décarbone, plus il domine le résultat.
Le composite, et ce qui bouge quand on change de pays
Les blocs 2 et 3 se résument utilement sur la partie carbone :
K_co2 = PUE × CIF + EMB
Exemple sur des valeurs réelles, celles de la méthodologie claude-carbon / TokenClimate. PUE de 1,14, valeur de flotte AWS déclarée pour 2025, donc une moyenne d'opérateur et non le PUE d'un site nommé. CIF de 287 gCO2e/kWh, intensité de la région AWS retenue par Jegham et al. pour Anthropic, dans la version 5 du papier ; la version 4 donnait 385 g, et personne d'autre ne publie la région d'hébergement. EMB de 44 g par kWh informatique, matériel amorti. Soit 1,14 × 287 + 44 = 371 gCO2e par kWh.
Le CIF est ici le paramètre le plus fragile : il repose sur une région inférée par un tiers, pas déclarée par le fournisseur, et il a bougé de 25 % entre deux versions du même article. Publiez-le avec sa version et sa date de relecture.
Passez le CIF à la France, 41,4 g chez Ember, et vous obtenez 91,2 g. Facteur 4,1 sur le composite, et 6,9 sur la seule composante d'usage. Pas 20, comme on l'entend parfois.
Un réseau plus propre, et le matériel pèse plus lourd dans le total. À intensité carbone nulle, le composite ne descend pas sous 44 g. On le retrouve ailleurs : l'analyse de cycle de vie de Lucie 7B (arXiv:2607.05408, juillet 2026) mesure sur la partition H100 du supercalculateur Jean Zay, alimentée par le réseau français, une empreinte annuelle de 417,5 tCO2eq répartie « almost equally between manufacturing and operation ».
Corollaire pour vos réunions : débattre du PUE, c'est chipoter sur 5 %. Débattre du CIF déplace le résultat d'un facteur 8. Orientez la discussion.
Ce que la formule écarte, et ce que ça coûte
Le bloc 1 retient deux des trois coefficients publiés par Delavande, Pierrard et Luccioni. Il laisse dehors le troisième, le terme croisé, qui compte la relecture du cache KV à chaque token produit.
Le modèle complet du papier, avec son contrôle d'homogénéité :
E = A × T_entrée + C × T_sortie + D × T_contexte × T_sortie
Wh = Wh/tk × tk + Wh/tk × tk + Wh/tk² × tk × tk
A = 6,05 × 10⁻⁵ Wh/token C = 2,13 × 10⁻³ Wh/token
D = 2,87 × 10⁻⁷ Wh/token²
Pourquoi on l'écarte. D vient d'un seul ajustement, sur un seul modèle en FP32, un seul H100, à lot unitaire. Aucune publication ne le donne pour une autre configuration, et surtout pas en régime de production groupée. L'appliquer à un service mutualisé reviendrait à transporter une mesure hors de son domaine de validité, ce que ce cours reproche par ailleurs à tout le monde.
Ce que l'omission coûte. Elle n'est pas neutre et elle va toujours dans le même sens, la sous-estimation. À lot unitaire, le terme croisé pèse environ 10 % de l'énergie sur un chat court, 46 % sur un chat long, et 68 % sur une session d'agent à 126 180 tokens de contexte. Sur ce dernier profil, il devient le premier poste et le terme de sortie tombe à 4 %.
Ce n'est pas non plus le même objet que le facteur de cache du bloc 1. f_cache est un résidu de préremplissage, compté une fois par requête. Le terme croisé est un coût de décodage, compté une fois par token produit. Les deux décrivent la même relecture vue de deux phases différentes, et les additionner ne serait pas un double comptage.
DONNÉE MANQUANTE. Personne n'a réajusté les trois coefficients à plusieurs tailles de lot. C'est le trou le plus gênant de la méthode, parce qu'il porte sur le terme dominant du seul profil qui monte, l'agentique. Protocole pour le combler : reprendre le protocole de Delavande et al., même modèle et même matériel pour rester comparable, et rejouer l'ajustement à des lots de 1, 8, 32 et 128, en balayant la longueur de contexte sur au moins deux ordres de grandeur. Publier les trois coefficients par taille de lot, et le rapport C/A associé.
Tant que ce travail n'est pas fait, la position tenable est celle-ci : la formule vaut pour du chat, elle sous-estime l'agentique, et l'ampleur de la sous-estimation est connue à lot unitaire seulement.
Le paramètre le plus incertain
Sur un usage agentique, la relecture de cache représente l'essentiel du volume. Le facteur f_cache devient donc structurant, et personne ne le mesure bien.
La fraction de l'énergie d'un token d'entrée frais que coûte encore un token relu depuis le cache de prompt. Valeur retenue par la méthodologie TokenClimate : 0,08, plage publiée de 0,05 à 0,20.
Ce facteur modélise ce qui reste du préremplissage, rien à voir avec la génération. Nommer correctement le terme physique évite d'orienter de travers ses révisions futures.
La seule mesure directe disponible, Irminsul (MLA-Native Position-Independent Caching, arXiv:2605.05696), compare l'énergie d'un succès et d'un échec de cache par compteurs NVML, sur un préfixe de 4 096 tokens :
| Architecture d'attention | Échec | Succès | Ratio |
|---|---|---|---|
| GQA, Qwen3-32B | 262,3 J | 37,5 J | 14 % |
| MLA, DeepSeek-V2-Lite | 47,1 J | 17,2 J | 37 % |
| Modèles à espace d'états | n.d. | n.d. | 0 % |
Pourquoi 0,14 n'a pas été adopté malgré une mesure plus récente : le protocole tourne à 4 096 tokens de préfixe quand le pas médian d'un agent de code en porte 126 180. À cette échelle, les coûts fixes de lancement qui dominent les petits cas s'amortissent et le ratio réel baisse, ce que les auteurs reconnaissent eux-mêmes.
Comportement à copier. Un facteur mesuré hors de son domaine de validité ne devient pas bon parce qu'il est récent. On élargit la plage publiée plutôt que de déplacer la valeur centrale.
La ventilation qui change les recommandations
Décomposition mesurée sur la base de sessions agentiques de claude-carbon, 17 402 millions de tokens de janvier à août 2026 :
| Classe de tokens | Part du volume | Part du carbone |
|---|---|---|
| Sortie | 0,73 % | 48,5 % |
| Lecture de cache, facteur 0,08 | environ 90 % | 22,7 % |
| Entrée fraîche et écriture de cache | environ 9 % | 28,8 % |
Trois lectures d'un seul tableau.
Un outil qui compterait toutes les lectures de cache au tarif d'un token d'entrée frais afficherait 5 à 10 fois plus. Voilà de combien se trompe un tableau de bord à compteur unique.
La part réellement compressible pèse 28,8 %, donc un compresseur parfait ne descendrait pas sous 71 % du total. Avec la borne haute du facteur de cache, ce plancher monte encore.
Ce qui déplace l'aiguille agit sur la sortie, moins d'un pour cent du volume et près de la moitié du carbone. Un modèle plus petit. Couper le raisonnement. Et surtout des réponses plus courtes.
Ce profil est propre à l'usage agentique. Sur du chat simple, environ 1 000 tokens d'entrée pour 150 générés, l'entrée pèse environ 16 % de l'énergie et la compression a beaucoup plus de prise. Dites toujours pour quel profil un pourcentage a été calculé.
Question
Sur un agent de code, quel levier faites-vous passer en premier dans vos recommandations ?
Choisissez une réponse pour voir l'explication.
Les méthodologies existantes, et ce qu'elles couvrent
| Méthode | Matériel | PUE | Inactif | Réseau | Entraînement |
|---|---|---|---|---|---|
| Google, 2025 | oui | oui | oui | non | non |
| EcoLogits | oui, sur 3 ans | oui | non | non | non |
| LLMCarbon | oui | oui | non explicite | non | oui |
| ML CO2 Impact | non | non | non | non | sans objet |
| SCI, ISO/IEC 21031 | oui | via l'énergie | selon l'unité | selon l'énergie | unité libre |
La formule normalisée par l'ISO tient en une ligne, SCI = (O + M) par R, où O est l'énergie multipliée par l'intensité carbone, M le matériel amorti, et R l'unité fonctionnelle. R est le paramètre libre, donc le premier levier de non-comparabilité : on ne peut pas comparer deux scores conformes calculés avec des R différents.
Deux propriétés distinguent ce cadre d'un reporting classique. Il exclut les compensations par construction, puisqu'il mesure un taux et non un total. Et son terme d'énergie doit couvrir le matériel réservé, pas seulement utilisé, ce qui change tout sur un parc sous-chargé.
Ce qu'il faut publier avec le chiffre
Un facteur n'est défendable que documenté. Le minimum, tel que l'exige la recommandation UIT de février 2026 : description du système, unité fonctionnelle, frontières avec exclusions justifiées, sources et qualité des facteurs, énergie séparée entre entraînement et inférence, et déclaration de conformité totale ou partielle avec les éléments exclus explicités.
La formule « conformité partielle avec exclusions explicites » est ce qu'une méthodologie honnête peut livrer aujourd'hui, sans plus. Et la seule position tenable, puisque aucun référentiel opposable n'impose de méthode.
Pour appliquer tout ceci à un usage réel sans repartir de zéro, la méthodologie TokenClimate publie ses paramètres, leurs plages et leurs sources, et le calculateur fait tourner la formule sur un mix de modèles.
FAQ
Comment calcule-t-on l'empreinte carbone d'un usage de LLM ?
En trois étapes. On convertit d'abord le volume de tokens en énergie informatique, en distinguant l'entrée fraîche, les lectures de cache et la sortie, chacune avec son coefficient. On multiplie ensuite par le PUE du site pour obtenir l'énergie totale. On applique enfin l'intensité carbone du réseau électrique concerné, plus un terme de carbone incorporé du matériel amorti.
Quel poids donner aux tokens lus depuis le cache ?
Environ 0,08 fois l'énergie d'un token d'entrée frais, dans une plage publiée de 0,05 à 0,20. La seule mesure directe disponible donne 14 à 37 % selon l'architecture d'attention, mais elle a été faite sur un préfixe de 4 096 tokens alors qu'une session d'agent en porte environ 126 000, échelle à laquelle le ratio réel baisse.
Quelle part de l'empreinte vient des tokens de sortie ?
Sur un usage agentique mesuré sur 17 milliards de tokens, la sortie représente 0,73 % du volume et 48,5 % du carbone. Les lectures de cache font environ 90 % du volume pour 22,7 % du carbone. Sur du chat simple, la répartition est très différente et l'entrée pèse environ un quart de l'énergie.
Changer de pays d'hébergement divise-t-il l'empreinte par 20 ?
Non. Sur un composite typique, passer d'une intensité carbone américaine à une intensité française donne un facteur 4,1 sur le total et 6,9 sur la seule composante d'usage. Le PUE et le carbone incorporé du matériel ne bougent pas avec le pays, et le second devient dominant à mesure que le réseau se décarbone.
Existe-t-il une norme pour calculer l'empreinte d'une requête d'IA ?
Aucune norme opposable n'impose de méthode. La spécification SCI, devenue ISO/IEC 21031 en 2024, fournit une formule mais laisse l'unité fonctionnelle libre et ne mentionne jamais l'inférence. La recommandation UIT-T L.1801 de février 2026 est la plus complète, sans être contraignante. La position tenable consiste à déclarer ses frontières et ses exclusions.