Méthodologie_

Version : v4.15-methodology-2026-10 Mise à jour : 2026-10-14 Statut : document versionné, chaque modification produit une nouvelle version.

TokenClimate produit une estimation de l'impact environnemental de l'usage des LLM par équipe, sur trois grandeurs : l'énergie consommée (Wh), les émissions de gaz à effet de serre (gCO₂e) et la consommation d'eau estimée (mL). Ce ne sont pas des mesures, ce sont des estimations dérivées du volume de tokens consommés et de paramètres publics sourcés. Ce document décrit le périmètre, les hypothèses, les équations, les sources, les limites connues, et comment vérifier les valeurs.

Cadrage normatif et périmètre

La méthodologie est fondée sur les principes ACV (ISO 14040), en approche attributionnelle, et alignée sur l'AFNOR Spec 2314 pour le tiers datacenter. Ce n'est pas une ACV complète vérifiée par tierce partie. Le tableau ci-dessous relie les points de cadrage du §4.1 de l'AFNOR Spec 2314 aux sections de ce document. Deux lignes sont des pratiques propres à cette méthodologie, pas des exigences du référentiel : la présentation min-best-max des incertitudes et le versionnement de la méthode (le §4.1 demande des hypothèses documentées et des sources datées, sans imposer ces formes).

Unité fonctionnelle

Le token. Toutes les grandeurs sont exprimées par million de tokens (Mtok), déclinées par type de token (input non caché, cache write, cache read, output) et par famille de modèle.

Frontières du système

Le périmètre couvert est le tiers datacenter, inférence seule :

• électricité IT des serveurs d'inférence, majorée du PUE (cooling et overhead datacenter) ;
• carbone embodied du matériel d'inférence (GPU + serveur hôte), amorti ;
• eau de refroidissement on-site (WUE) et eau incorporée dans l'électricité achetée (EWIF, off-site).

Sont exclus : les terminaux utilisateurs et les réseaux (respectivement ~50 % et ~4 % de l'empreinte du numérique en France, les datacenters faisant ~46 %, selon l'actualisation ADEME-Arcep de janvier 2025 sur données 2022 : le tiers datacenter n'est qu'une partie du tout), l'entraînement et le développement des modèles (non alloués à l'inférence, répartition non publiée par Anthropic), la construction des datacenters, et le surprovisionnement.

Ces exclusions n'ont pas le même poids. Le développement des modèles peut être gros : Epoch AI estime les dépenses de calcul de R&D d'Anthropic en 2025 à 4,1 Md$ contre 2,7 Md$ pour l'inférence, une estimation qu'il qualifie lui-même de « somewhat speculative », et celles d'OpenAI en 2024 à 5 Md$ contre 1,8 Md$, soit 1,5 à 2,8 fois l'inférence. Ce sont des dollars, pour deux acteurs et deux années : ils ne se convertissent pas en énergie sans hypothèse, et nous ne les appliquons à aucun fournisseur. Une méthode qui ajoute ce poste à l'inventaire obtient, pour le même usage, un chiffre sensiblement plus haut que le nôtre. La construction des datacenters est petite : Google l'amortit sur 20 ans et la chiffre à 59 à 218 kgCO₂e par machine TPU sur six ans de service (Schneider et al., arXiv:2502.01671, Table 1 et annexe A.5), soit de l'ordre de 1 à 2 gCO₂e par kWh consommé par la machine, moins de 1 % de notre intensité totale. Le surprovisionnement, c'est-à-dire la capacité gardée en réserve pour absorber les pics et les pannes, n'est pas dans notre source, qui ne compte que les GPU affectés aux requêtes. Google le chiffre à 10 % de l'énergie d'un prompt médian (voir « Hypothèses et incertitudes », capacité inactive).

Allocation

L'impact d'une infrastructure mutualisée est alloué au prorata de l'énergie IT attribuable aux tokens de la session. L'embodied est amorti sur 5 ans de service du matériel puis alloué au kWh IT. Cette durée est celle qu'Amazon a retenue au 1er janvier 2025, en ramenant de 6 à 5 ans la durée de vie utile comptable d'un sous-ensemble de ses serveurs et équipements réseau, motif invoqué : « the increased pace of technology development, particularly in the area of artificial intelligence and machine learning ». Deux contrepoints existent, et ils tirent dans des sens opposés : la méthodologie Customer Carbon Footprint d'AWS (Model v3.0, octobre 2025, §3.3.4.3) aligne les racks sur 6 ans, EcoLogits retient 3 ans. L'ACV des GPU de l'ADEME, d'où vient notre terme GPU, retient elle aussi 3 ans (« nous choisissons pour cette étude une durée de 3 ans ») : à 3 ans, la même dérivation donne 82 gCO₂e/kWh au lieu de 49, au-dessus de la plage publiée 22-66 (voir « Hypothèses et incertitudes »). Les tokens des sous-agents Claude Code sont agrégés à la session parente (voir Caveats). Aucun offset, aucune compensation : les instruments de marché sont hors du calcul, conformément au SCI.

Vocabulaire SCI (ISO/IEC 21031)

Le calcul se décrit dans le vocabulaire du Software Carbon Intensity for AI : un score de type Consumer (usage de l'inférence, pas l'entraînement), par token (R = le token). Les trois composantes sont publiées séparément et jamais fusionnées en un score opaque :

• E (énergie) : energy_wh, l'énergie IT estimée ;
• I (intensité) : PUE × CIF, en location-based ;
• M (embodied) : EMB, le terme matériel.

Soit SCI = (E × I) + M par token. Les offsets sont exclus par construction.

Localisation supposée

On ne sait pas dans quelle région chaque requête est servie. L'hypothèse retenue reste US multi-cloud, AWS-dominant : le CIF est le mix pondéré des régions AWS d'inférence (voir section suivante). Elle est aujourd'hui partielle, et il faut le dire.

Le 6 mai 2026, Anthropic a annoncé un accord avec SpaceX (qui a absorbé xAI) portant sur la totalité de la capacité de Colossus 1, près de Memphis, soit 300 MW. L'échéance de mai 2029 ne figure pas dans l'annonce, elle est rapportée par TechCrunch. La communication mentionne explicitement l'inférence pour les abonnés. Le réseau électrique concerné est celui de la Tennessee Valley Authority, qui n'entre pas dans la pondération des régions AWS sur laquelle notre CIF est construit. Son facteur de sous-région (SRTV) vaut 0,429 kgCO₂e/kWh dans eGRID2024.

Ajouté à GCP et Azure, sur lesquels Anthropic opère aussi sans répartition publiée, cela laisse la sensibilité du CIF à cette inconnue à ±30 %, une estimation que nous n'avons pas les moyens de resserrer aujourd'hui. Un chantier est ouvert pour reconstruire nous-mêmes le mix pondéré depuis Electricity Maps.

Repères eGRID2024 pour les sous-régions des régions AWS d'inférence, en émissions de combustion, sans amont ni pertes de réseau (recalcul du code de l'EPA publié par la Cornerstone Sustainability Data Initiative, Zenodo, mars 2026, feuille SRL24) : Virginie (SRVC, us-east-1) 0,291, Ohio (RFCW, us-east-2) 0,406, Nord-Ouest (NWPP, us-west-2) 0,264, moyenne des États-Unis 0,341, Tennessee Valley (SRTV) 0,429 kgCO₂e/kWh. Notre 0,287 est au niveau de la Virginie et du Nord-Ouest ; plus de poids donné à l'Ohio ou à Memphis le ferait monter. La borne haute de notre plage (0,287 × 1,3 = 0,373) ne couvre ni la sous-région TVA ni un site alimenté au gaz sur place. La révision de la plage devra les inclure.

Sur l'eau

On parle de consommation d'eau estimée, jamais d'« empreinte eau ». Une empreinte eau au sens ISO 14046 exigerait une caractérisation d'impact (par exemple AWARE, pondération par stress hydrique local), que cette méthodologie ne fait pas faute de connaître la localisation des requêtes.

Le chiffre d'eau additionne deux grandeurs qui ne sont pas de même nature, et nous le déclarons plutôt que de le masquer. L'équation est water_ml = energy × (WUE + PUE × EWIF). Or AWS définit son WUE en eau prélevée (« liters of water withdrawn per kilowatt-hour »), tandis que les facteurs EWIF de la famille WRI mesurent une consommation. Additionner un prélèvement et une consommation n'est pas homogène.

Nous ne corrigeons pas tout de suite : le ratio consommation sur prélèvement dépend du facteur de concentration du site, que nous ne connaissons pas. Ce qui borne le problème : le terme on-site pèse 2,0 % du millilitre affiché (0.12 sur 5.9454), donc l'inhomogénéité porte sur 2 % du chiffre, pas sur le chiffre. Les 98 % restants sont l'eau consommée pour produire l'électricité, et là le chiffre est homogène : Jegham déclare son 5,11 L/kWh comme une consommation (la part prélevée puis évaporée), dérivée du guide WRI sur l'eau incorporée dans l'électricité achetée et pondérée sur les régions AWS d'inférence, pondération qu'il ne publie pas. Ce 5,11 paraît haut à côté des 1,8 L/kWh que Grubert et Sanders donnent pour la moyenne des centrales américaines, mais les deux ne comptent pas la même chose : les facteurs WRI incluent l'évaporation des réservoirs hydroélectriques (moyenne nationale 3,1 L/kWh consommés pour 43,8 prélevés, d'après Li et al., arXiv:2304.03271), le 1,8 l'exclut explicitement. Un parc hébergé en partie dans l'Oregon, où l'hydraulique domine, tire la moyenne vers le haut. L'écart est une convention d'allocation, pas une erreur à corriger : nous gardons 5,11 et nous le disons. Vérifié sur les annexes du guide WRI (modélisation GaBi, mix eGRID 2018, gallons convertis à 3,785 L) : la Virginie (sous-région SRVC) est à 2,37 L/kWh consommés, l'Ohio (RFCW) à 2,22, la Californie (CAMX) à 5,19 et le Nord-Ouest (NWPP, Oregon) à 9,48 ; la moyenne américaine est à 3,13 et la moyenne mondiale à 4,81. Le 5,11 de Jegham se reproduit avec environ 40 % de Nord-Ouest et 60 % de Virginie, c'est-à-dire un parc partagé entre us-west-2 et us-east-1 : plausible, mais la pondération exacte reste celle de Jegham, pas la nôtre.

Équations

Pour une session, avec les énergies E_in et E_out en Wh par million de tokens (énergie IT, côté serveur) :

energy_wh = (
    (input_tokens + cache_creation_tokens) * E_in
  + cache_read_tokens * E_in * 0.08
  + output_tokens * E_out
) / 1_000_000

co2_grams = energy_wh * (PUE * CIF + EMB)
water_ml  = energy_wh * (WUE + PUE * EWIF)

Avec les paramètres Anthropic de la section suivante, les constantes composites valent :

L'embodied représente 13.0 % du CO₂e total (0.049 / 0.37618). Le CO₂e total vaut donc le CO₂e d'usage × 1.1498.

L'équation est implémentée dans lib/co2.ts, fonction computeImpact, qui retourne { energyWh, co2Grams, waterMl }. Les trois valeurs sont stockées par ligne d'usage (energy_wh, co2_grams, water_ml). Le coût USD est calculé à part (voir "Coût USD").

Exemple

Une session Sonnet avec 50 000 tokens d'input, 200 000 de cache write, 3 000 000 de cache read et 30 000 d'output :

energy_wh = (250_000 * 119 + 3_000_000 * 119 * 0.08 + 30_000 * 2525) / 1e6
          = 134.06 Wh
co2_grams = 134.06 * 0.37618 = 50.43 g   (usage 43.86 g + embodied 6.57 g)
water_ml  = 134.06 * 5.9454  = 797.0 mL

Paramètres Anthropic

Bloc params de lib/providers/seed/anthropic.json. Depuis la v3.8 ce bloc est composite : le PUE et le WUE viennent d'une déclaration AWS de première main (millésime 2025), le CIF et l'EWIF restent épinglés sur Jegham N. et al. (Jegham N., Abdelatti M., Koh C. Y., Elmoubarki L., Hendawi A.), "How Hungry is AI? Benchmarking Energy, Water, and Carbon Footprint of LLM Inference", arXiv:2505.09598, version v6, Table 1. L'embodied n'est pas dans cette Table 1 (le papier exclut le scope 3) : c'est une constante TokenClimate, dérivée ci-dessous, la même pour tous les fournisseurs.

Tiers de source : T1 = mesure ou rapport primaire publié, T2 = dérivation documentée à partir de sources T1, T3 = estimation d'ingénierie.

Reclassement des tiers en v3.8

Trois lignes changent de tier, et aucune valeur ne bouge avec elles.

Le CIF et l'EWIF passent de T1 à T2. Le tier T1 est défini ici comme « mesure ou rapport primaire publié ». Jegham et al. est un préprint non revu par les pairs qui republie des paramètres tiers (Electricity Maps pour le CIF) et modélise le reste : c'est une dérivation documentée, donc T2. Le PUE et le WUE restent T1 parce qu'ils sont désormais sourcés sur une déclaration publiée par l'exploitant de l'infrastructure lui-même, et non plus sur le préprint.

Le cache_read_factor passe de T3 à T2 : il existe depuis mai 2026 une mesure directe du rapport hit/miss (voir « Énergie du cache »), ce qui le fait sortir du statut d'estimation d'ingénierie sans en faire une mesure de notre grandeur exacte.

Le ratio E_in / E_out passe de T2 à T3, et sa plage s'élargit dans le sens inverse de la convention (voir « Le ratio input/output »).

Pin de version sur la source primaire

Le CIF a changé pendant la vie du papier source : 0.385 kgCO₂e/kWh jusqu'à la v4, 0.287 depuis la v5 (sourcé Electricity Maps). La valeur utilisée ici est épinglée sur la v6, Table 1. À noter : 0.287 n'est pas « le mix électrique global », c'est un mix calculé sur les régions AWS d'inférence (« based on the regional distribution of AWS data centers used for inference », §4.1), avec des poids non publiés.

Énergie par famille de modèle

Source : lib/providers/seed/anthropic.json, bloc energy par modèle. Valeurs en Wh par million de tokens, énergie IT.

Une seule des quatre familles Claude est estimée directement par la source. Les niveaux de confiance suivent la dérivation et non le fournisseur : Sonnet porte l'estimation publiée, Opus et Haiku en sont extrapolés en un saut, Fable en deux sauts et sans aucune donnée publique sur le modèle. Ces niveaux sont affichés sur chaque fiche /models et dans le tableau du hub, et l'API v1 les rend dans le champ co2_confidence.

Aucun facteur du registre n'est une mesure, et high ne veut pas dire « mesuré ». La source primaire ne relève rien : sa section 4.2 s'intitule « Per-Query Energy Consumption Estimation » et ses valeurs sortent d'une simulation Monte Carlo (10 000 tirages, copule gaussienne) sur une puissance de plaque constructeur, un taux d'utilisation supposé et un batch fixé à 8, la latence et le débit relevés par Artificial Analysis étant les seuls intrants empiriques. Cela vaut pour toutes les lignes de la Table 4, Sonnet compris. L'échelle de confiance classe donc des estimations entre elles : high = estimation publiée pour ce modèle précis et ajustée sur ses propres points, medium = dérivée d'un modèle ajusté ou ajustement partiel complété par une convention, low = extrapolée d'un autre modèle ou produite par un outil paramétrique. Jusqu'à la v4.0, le produit écrivait « mesure directe » à plusieurs endroits, ce qui sur-qualifiait la source.

Recalibration 2026-07 : les trois énergies par requête estimées par Jegham v6 pour Claude 3.7 Sonnet (0.950 / 2.989 / 5.671 Wh, PUE inclus) sont ajustées par régression OLS passant par l'origine, ce qui donne les facteurs d'usage 39/826 gCO₂e/Mtok du plugin OSS ; les énergies IT ci-dessus en sont dé-compoundées (E = facteur / (PUE × CIF), arrondi à l'entier). Haiku part lui aussi du facteur OSS déjà arrondi, pas de l'énergie Sonnet : 10 / 0,32718 = 30,56 en entrée, 207 / 0,32718 = 632,7 en sortie. Il garde une décimale en entrée (30,6) : l'entier 31 s'écarterait de 1,4 % du facteur du plugin, hors de la tolérance de 0,5 % du contrôle de cohérence. La calibration précédente (tokenclimate-v3-2026-06, Sonnet 580/3480) reposait sur les composites pré-v6 (190/1140). Ces énergies restent alignées sur celles du plugin open source claude-carbon (même auteur), un contrôle automatique hebdomadaire vérifie la cohérence à ±0.5 %.

Le rapport Haiku / Sonnet

Depuis la v4.15, Haiku vaut 0,25 fois Sonnet : 30,6 / 633 Wh/Mtok, soit les facteurs 10 / 207 gCO₂e/Mtok du plugin claude-carbon (version 1.12.0 du 14 octobre 2026). Jusqu'à la v4.14, il valait 0,5 fois Sonnet (61 / 1 262 Wh/Mtok). Anthropic ne publie ni taille, ni calcul, ni énergie pour aucun Haiku, et Haiku 5.5, sorti le 7 octobre 2026, n'a encore aucune estimation d'énergie indépendante. La valeur se place donc entre deux bornes publiques.

• Borne basse, environ 0,07. EcoLogits 0.11.2 (données modèles du 29 septembre 2026), pour 1 000 tokens de sortie : 0,06 à 0,16 Wh pour Claude Haiku 4.5, 1,16 à 1,82 Wh pour Claude Sonnet 5.5, un rapport de 0,076 au milieu des deux plages. Les tailles y sont des hypothèses marquées « architecture not released » (Haiku 4.5 dense de 10 à 35 milliards de paramètres, Sonnet 5.5 en mélange d'experts avec 29 à 88 milliards actifs), et l'essentiel de l'écart vient de ce pari dense contre mélange d'experts.
• Borne haute, environ 0,57. Vitesse de sortie relevée par Artificial Analysis sur l'API d'Anthropic le 14 octobre 2026 : 237,3 tokens/s pour Haiku 5.5, 134,9 pour Sonnet 5.5. Sur le même matériel et le même batch, l'énergie par token suivrait l'inverse de la vitesse. Un modèle plus petit tourne en général sur moins de puces, donc ce rapport ne sert que de plafond.
• 0,25 : le milieu géométrique des deux bornes vaut 0,21, arrondi au-dessus. Haiku 5.5 s'approche de Sonnet 5.5 en capacités (indice Artificial Analysis 43 contre 56) et son rapport de vitesse à Sonnet 5.5 (0,57) dépasse celui de Haiku 4.5 à Sonnet 4.5 (0,47). Il peut donc être plus gros que le modèle décrit par EcoLogits, et on préfère ne pas sous-estimer. L'ancien 0,5 reste la lecture haute.

Deux signaux sont écartés. Le rapport des prix publics (0,10 / 0,50 $ contre 2 / 10 $, soit 0,05) reflète la baisse de prix de 90 % entre Haiku 4.5 et Haiku 5.5, qui ne dit rien du matériel. La Table 4 de Jegham v6 estime Claude 3.5 Haiku au-dessus de Claude 3.7 Sonnet (0,975 / 4,464 / 8,010 Wh contre 0,950 / 2,989 / 5,671), parce qu'elle range les modèles sans taille publiée dans sa grande classe à 8 GPU et fait suivre l'énergie à la latence. Plage de sensibilité : 0,07 à 0,57 fois Sonnet, la plus large du registre. La confiance reste medium, qui désigne une extrapolation en un saut depuis Sonnet. À revoir quand EcoLogits couvrira Haiku 5.5.

Date de validité des énergies

Ces énergies sont valides au 2026-07 (Haiku au 2026-10) et se périment mécaniquement, dans le sens de la surestimation. À matériel identique, sur H100, l'énergie par token a baissé de 15 à 41 % selon la taille de modèle entre vLLM 0.5.4 (septembre 2024) et vLLM 0.11.1 (décembre 2025), sans qu'aucun modèle ne change : c'est le seul progrès de la pile de service (ML.ENERGY, analyse longitudinale). Nos valeurs sont un fit sur des estimations de novembre 2025. Elles sont renouvelées au moins une fois par an, et plus tôt si une source épinglée bouge.

Réserve tokenizer. Anthropic indique que les modèles Claude 4.7 et suivants, ainsi que Claude Mythos, utilisent un nouveau tokenizer qui produit environ 30 % de tokens de plus à texte égal (platform.claude.com/docs/en/about-claude/pricing, note tokenizer). Les énergies par token ci-dessus sont ajustées sur Claude 3.7 Sonnet. À texte égal, un facteur par token calibré avant 4.7 peut donc surestimer d'environ 30 % sur Sonnet 5, Opus 5 et Fable. Aucun facteur correctif n'est appliqué tant qu'aucune mesure ne le fonde ; la réserve est publiée.

Note de sensibilité : le procès en surestimation

Quatre signaux disent que ces énergies pourraient être trop hautes. Nous les publions plutôt que d'arbitrer en silence.

Microsoft (arXiv:2509.20241, v2 ; la v1 disait 0,34) estime une médiane de 0,31 Wh par requête pour les modèles de plus de 200 milliards de paramètres sur nœuds H100, et écrit mot pour mot que « widely cited estimates are overstated by 4-20x ». La famille d'estimations visée est celle dont Jegham fait partie, c'est-à-dire notre source primaire. Notre Sonnet à 2 525 Wh/Mtok donne environ 1,26 Wh pour une réponse de 500 tokens, soit à peu près 4 fois leur médiane : nous serions donc dans le bas de la fourchette de surestimation alléguée. Deux autres signaux vont dans le même sens. EcoLogits a corrigé en mars 2026 son calculateur en ligne, dont l'estimation de latence surestimait l'énergie. Et le leaderboard ML.ENERGY v3.0 mesure Qwen3-235B-A22B en FP8 sur 4×B200, au batch maximal, autour de 111 Wh/Mtok : un modèle à poids ouverts dans des conditions de débit optimales, pas un modèle frontier propriétaire, mais un ordre de grandeur vingt fois sous notre Sonnet.

Le quatrième vient de la source elle-même. Jegham v6 fixe le batch à 8 requêtes simultanées pour toutes ses estimations, en justifiant ce choix par la latence (« a practical midpoint between common deployment scenarios », §4.3), et sa propre analyse de sensibilité (annexe A, GPT-4o) montre qu'un batch de 16 abaisse l'énergie par requête d'environ 43 %. Le même papier range les modèles phares dont la taille n'est pas publiée, Claude 3.7 Sonnet compris, dans sa classe la plus lourde (8 GPU, « classified as Large »), et compte le sous-système hors GPU du nœud à une utilisation fixe de 0,5 : l'hôte est donc déjà dans nos énergies. Le débit retenu par Microsoft, lui, « approximates the throughput of a fully saturated node with high concurrency ». Aucune source publique ne dit quel batch Anthropic tient en production. S'il est plus élevé que 8, nos énergies sont hautes d'un facteur que nous ne savons pas chiffrer.

Nous ne basculons pas la valeur. Le papier Microsoft est un modèle bottom-up sous hypothèses de déploiement, produit par un acteur partie prenante, pas une mesure de nos modèles. Mais le conflit existe, il est documenté, et un lecteur qui l'apporte en réunion doit le trouver ici avant de le trouver ailleurs.

Le ratio input/output

Depuis la recalibration v6, le ratio n'est plus une hypothèse : il est récupéré du fit sur les trois points estimés, soit ~21:1 output:input (2525 vs 119 Wh/Mtok pour Sonnet). Un long contexte ajoute peu d'énergie par rapport au même volume de tokens générés, ce qu'un ratio plat bas manquerait. Pour les providers non-Anthropic dont l'énergie input n'est pas estimée (énergies EcoLogits, qui ne publie que du output, ou fit Jegham dont le coefficient d'input est forcé à 0 par NNLS), la convention E_in = E_out/6 reste appliquée.

Cette convention est désormais présentée pour ce qu'elle est : une hypothèse contestée, pas une valeur consensuelle. La plage défendable dans la littérature est bien plus large que ce que la v3.7 publiait. Elle va de 1/21, notre propre fit sur Jegham v6, à 1,2, c'est-à-dire un input plus coûteux qu'un output, valeur donnée par Vartziotis et al. (arXiv:2607.26571, équation 29). Leur estimateur est analytique, explicitement « compute-dominated » et posé en régime de prompt court : il rate le mur de bande passante mémoire qui domine le décodage, donc il n'est pas transposable à notre cas. Mais il est publié, il va dans le sens inverse de notre convention, et le taire reviendrait à publier une plage qui n'existe pas.

Le cas Fable

Aucune source publique ne documente la taille ou l'énergie de Fable 5 et 5.1 / Mythos 5 et 5.1. L'ancre retenue est le proxy prix : 2x Opus, le ratio des prix publics (10/50 vs 5/25). À réviser dès qu'une estimation indépendante est publiée.

Énergie du cache (cache_read_factor = 0.08)

Un token cache_read est un token de contexte déjà traité dont les tenseurs key/value sont réutilisés : son compute de prefill est évité. Il n'est pas gratuit pour autant.

Ce que le terme capture, et ce qu'il ne capture pas

L'équation applique cache_read × E_in × 0.08, c'est-à-dire une fraction de l'énergie d'un token d'entrée non caché. C'est donc un résidu de prefill : ce qui reste à payer, au prefill, quand le préfixe est déjà en cache.

Jusqu'à la v3.7, ce même terme était justifié par le résidu de relecture du KV cache en phase de décodage. Les deux ne sont pas le même objet, et le second n'est pas linéaire en cache_read : chaque token généré relit l'intégralité du KV cache depuis la HBM, tokens cachés inclus (GreenCache, SIGMETRICS : « caching does not reduce computation in the decode phase »). Ce coût est bilinéaire, il dépend du produit (taille du contexte × nombre de tokens générés). Aujourd'hui il est absorbé dans un E_out supposé constant, calibré à des longueurs de contexte que la source ne publie pas et qui sont vraisemblablement courtes. Conséquence, à écrire sans détour : en régime de contexte long, donc en usage agentique, notre chiffre sous-estime ce poste.

Ce que mesure la littérature

Une mesure directe du rapport hit/miss existe depuis mai 2026. Irminsul (arXiv:2605.05696, Table 1) instrumente l'énergie de prefill par événement de cache, compteurs matériels NVML, à 4 096 tokens de préfixe (2 048 pour DeepSeek-MoE-16B) :

Trois réserves avant d'en tirer une valeur. La mesure est faite à 4 096 tokens de préfixe (2 048 sur la ligne MHA), alors que la médiane d'un pas de session Claude Code est de 126 180 tokens (TraceLab, arXiv:2606.30560v2, Table 8) : à cette échelle les coûts fixes de lancement de kernel s'amortissent et le rapport réel descend, ce que le papier reconnaît lui-même pour ses petites cellules. Les deux lignes hautes, MLA et MHA, sont mesurées sur des modèles de 16 milliards de paramètres, là où ces coûts fixes pèsent le plus. Enfin, l'architecture d'attention de Claude n'est pas publiée : rien ne dit laquelle des trois lignes s'applique.

La valeur retenue

0.08, inchangée, plage publiée 0.05-0.20. Le tier passe de T3 (estimation d'ingénierie) à T2 : il existe désormais une mesure directe, sur un objet voisin et dans un régime différent du nôtre, ce qui est une dérivation documentée et non une mesure de notre grandeur.

Nous n'avons pas basculé sur 0,14 malgré Irminsul. Appliquer une mesure faite à 4 K de contexte à un usage qui tourne à 126 K déplacerait de 25 à 30 % le chiffre d'une organisation dominée par Claude Code, sur une base que nous ne saurions pas défendre. La borne haute publiée passe en revanche de 0,15 à 0,20, parce que deux des trois architectures mesurées sont au-dessus de l'ancien plafond : notre incertitude affichée sous-estimait le risque à la hausse.

Les mesures adjacentes qui fondaient l'estimation d'origine restent valables comme encadrement : le prefill représente au plus 3.4 % de l'énergie totale d'inférence sur des charges de génération, et un KV cache plus gros amplifie l'énergie de décodage par token de 1.3 à 51.8 % (les deux chez Solovyeva & Castor) ; l'énergie par token triple environ entre 2K et 10K de contexte sur Llama 3 70B (TokenPowerBench, H100).

Le vrai correctif n'est pas une nouvelle constante, c'est une nouvelle forme d'équation, avec un terme de prefill résiduel et un terme de décodage fonction de la longueur de contexte. Tant que nous n'aurons pas mesuré cette courbe nous-mêmes, la constante reste.

Ce facteur n'est pas le ratio de facturation 0.1x d'Anthropic. C'est un prix, pas une mesure d'énergie (OpenAI facture le même mécanisme à 0.1x sur sa gamme courante, 0.5x sur gpt-4o). Mettre cache_read_factor à 0 serait une borne basse défendable, mais traiterait un system prompt de 100K tokens réutilisé comme neutre en carbone, ce qui ignore un coût réel de bande passante mémoire.

Sources : Irminsul (arXiv:2605.05696), GreenCache (arXiv:2505.23970), TokenPowerBench (arXiv:2512.03024), Solovyeva & Castor (arXiv:2602.05712), From Prompts to Power (arXiv:2511.05597), TraceLab (arXiv:2606.30560v2).

Le facteur vit dans lib/providers/seed/anthropic.json (clé cacheReadFactor) et est exposé par lib/providers/registry.ts.

Profils d'usage du calculateur public

Le calculateur public (/calculator) demande un volume de tokens générés par mois. Historiquement il ne comptait que ce volume. Or les tokens générés ne sont qu'une partie de ce que la machine traite : en usage agentique, le contexte relu depuis le cache domine très largement le volume (voir l'exemple de la section Équations : 3 000 000 de lectures de cache pour 30 000 tokens générés, soit environ 91 % des tokens traités).

Un profil d'usage rend cette hypothèse explicite au lieu de la laisser implicite. Chaque profil est un jeu de volumes de référence par classe de tokens, stocké verbatim depuis sa source dans lib/calculator/profiles.ts. La sélection d'un profil met ces volumes à l'échelle du volume de tokens générés saisi (règle : facteur = volume saisi / volume output de référence). Le profil par défaut « Sortie seule » reproduit le comportement historique : les liens déjà en circulation produisent les mêmes chiffres qu'avant.

Le profil agent est donné en agrégats bruts pour rester littéralement la source. Ramené à un million de tokens générés, cela donne 4,8 M de tokens d'entrée fraîche, 19,3 M de cache write et 269,7 M de cache read, soit 270 tokens relus du cache par token généré et 91,5 % du volume total réellement lu du cache.

Ce que ça change par rapport à la v3.7 : le profil valait 100 tokens relus par token généré, tiré de l'exemple chiffré de la section Équations et corroboré a posteriori. Il vaut désormais 270, recopié d'agrégats mesurés. Le chiffre affiché par le calculateur pour ce profil est multiplié par environ 1,78 (4 468,7 → 7 961,1 Wh par million de tokens générés en Sonnet). Le calculateur sous-estimait ce qu'une organisation mesure sur ses propres données.

Le partage du volume frais entre entrée non cachée et cache write (1:4) est la seule dérivation restante : TraceLab ne sépare pas les deux. Il est sans effet sur l'énergie, les deux classes coûtant E_in plein, et ne joue que sur le coût en dollars.

Un profil intermédiaire (assistant avec contexte en cache) a été envisagé puis écarté : aucune source publiée ne ventile ce workload par classe de tokens, et le calculateur n'affiche pas d'hypothèse qu'il ne peut pas sourcer. Le mode de saisie manuelle couvre ce cas ; les plages de cache publiées pour les services conversationnels vont de 30 à 50 % selon la capacité (trace Mooncake, arXiv:2407.00079) à 75-95 % en production (CharacterAI et Kimi, cités par TokenLake, arXiv:2508.17219).

Sources des profils :

• Splitwise : Patel P. et al., "Splitwise: Efficient Generative LLM Inference Using Phase Splitting", ISCA 2024, arXiv:2311.18677. Traces de production Azure (novembre 2023) : service conversation, médiane 1 020 tokens de prompt et 129 tokens générés par requête. Corroboration côté longueurs de réponse : WildChat (arXiv:2405.01470, 441 tokens par réponse en moyenne) et LMSYS-Chat-1M (arXiv:2309.11998, 215).
• TraceLab : Zhu J. et al., "TraceLab: Characterizing Coding Agent Workloads for LLM Serving", arXiv:2606.30560. Trace de 2 676 sessions Claude Code réelles (37 développeurs, colonne Claude Code de la Table 1 ; les 43 du papier sont le total dédupliqué Claude et Codex ; octobre 2025 à juin 2026) : 95,5 % du volume total en tokens de préfixe, dont 91,5 % réellement relus du cache, 0,34 % en output, taux de hit du cache de préfixe 95,8 % sur la colonne Claude de la Table 11 (95,7 % toutes colonnes).
• Bai et al. : "How Do AI Agents Spend Your Money?", arXiv:2604.22750. OpenHands sur SWE-bench Verified : ratio input/output moyen de 153,85 en coding agentique, ~4,17 M tokens par tâche. Le profil agent est à 294, tous tokens d'entrée confondus (frais, écriture et lecture de cache) sur tokens de sortie : plus haut, parce que TraceLab compte le préfixe relu à chaque pas.

Estimation par unité d'usage (mode simplifié)

Le calculateur demande un volume de tokens générés par mois, or personne ne connaît ce nombre de tête et personne n'ouvre sa console de facturation pendant une visite. Le mode simplifié le déduit de trois questions : ce que le visiteur délègue à l'outil, combien de personnes l'utilisent, et à quelle cadence.

Ce mode ne publie aucune cadence. C'est la différence avec le tableau de volumes par tâche retiré en v3.7, jugé trop imprécis pour une surface publique. Ici la cadence est saisie par le visiteur et reste modifiable dans le champ de volume ; seuls les tokens par unité sont dérivés de la source.

Les 36 211 tokens par session sont dérivés, jamais recopiés : 96 900 000 / 2 676. Côté chat, l'unité de la source EST la requête, les 150 tokens de sortie de référence sont donc déjà « par échange » et il n'y a rien à diviser. Cadence mesurée par TraceLab, publiée ici comme repère : 2 676 / 37 / 9 mois, soit 1,9 session par développeur et par semaine (8,0 par mois, à 4,33 semaines par mois). L'écran ne l'affiche plus depuis le 2026-09-02 : la valeur est saisie par le visiteur, ce document publie celle de la source. Splitwise ne mesurant pas de population, aucun repère de cadence n'existe pour le chat.

sortie/mois = personnes × cadence × périodes par mois × tokens par unité, avec 4,33 semaines ou 21 jours ouvrés par mois selon le profil.

La cadence mesurée n'est pas un plafond, c'est un repère pour que le visiteur se situe. Les 37 développeurs de TraceLab tournent à 8,0 sessions par mois, soit un usage occasionnel ; une équipe qui code avec Claude tous les jours est plusieurs fois au-dessus.

Le résultat est arrondi à deux chiffres significatifs et présenté en T3 : l'incertitude dominante vient de la cadence déclarée, pas des agrégats. Deux réserves s'y ajoutent. La durée d'une session TraceLab n'est pas publiée, et la session que le visiteur compte n'est pas forcément le même objet. Côté chat, la longueur de réponse retenue (129 tokens, médiane Splitwise 2023, arrondie à 150) est la plus basse des trois citées plus haut : à 215 (LMSYS-Chat-1M) ou 441 (WildChat), le même nombre d'échanges donnerait un volume jusqu'à trois fois supérieur.

Niveaux de délégation

Une constante unique par session ne décrit pas la réalité. Sur un corpus de 184 sessions Claude Code d'un seul développeur (août 2026, mesurées par claude-carbon), la sortie par session s'étale du premier au neuvième décile d'un facteur 100, et 10 % des sessions portent 66 % de la sortie totale. Ce corpus n'est pas reproductible par un tiers : il vit dans la base locale carbon.db de l'auteur, aucun script ni export anonymisé n'est publié à la date de cette version. Les percentiles ci-dessous sont donc à lire comme une observation privée, pas comme un jeu de données vérifiable. Une session moyenne n'existe pas : ce qui varie, c'est la taille de ce qu'on délègue.

Le mode simplifié demande donc ce que le visiteur confie à l'IA, et en tire la taille d'une session.

Ce corpus compte un seul développeur, contre 37 pour TraceLab. C'est peu, et rien ne dit que cette distribution vaille pour une autre organisation. Ce qui justifie malgré tout de la publier : la médiane du corpus, 36 750, tombe à 1,5 % de la moyenne que TraceLab mesure sur 2 676 sessions, 36 211 (96,9 M / 2 676 ; TraceLab ne publie pas de médiane par session). Une médiane et une moyenne indépendantes se rejoignent sur le centre de la distribution, ce qui donne du crédit à l'étalement que seule la première documente. Tier T3.

Le niveau de délégation ne change que la taille d'une session. Il ne touche pas au ratio contexte/sortie du profil : sur le même corpus, ce ratio ne suit pas la taille de façon nette (170, 90, 168 puis 234 fois la sortie, par quartile croissant de taille).

Le niveau conversationnel ne vient pas de ce corpus : son unité reste la requête médiane de Splitwise, 150 tokens de sortie.

Limites

Ces profils sont des ordres de grandeur, pas des mesures. Le ratio réel entre classes de tokens varie fortement d'une organisation à l'autre selon les outils, la taille des contextes et la part d'usage agentique. Seule la mesure sur les données réelles de l'organisation le donne.

Dual reporting : location-based et market-based

Le CO₂e affiché par défaut est location-based : l'intensité carbone du réseau électrique réel des régions où l'inférence tourne. C'est la convention retenue par l'AFNOR Spec 2314 (en note du §4.3) et l'exigence du SCI, qui excluent les instruments de marché (PPA, RECs, offsets) du score.

Le market-based est publié à titre de comparaison, jamais comme valeur par défaut :

• Google 2024 : 94 gCO₂e/kWh market-based vs 345 location-based (arXiv:2508.15734). L'écart 3.7x montre ce que les instruments de marché masquent.
• AWS (l'hypothèse de localisation dominante de TokenClimate) : revendique un matching 100 % renouvelable, mais Amazon dans son ensemble déclare 2.80 MtCO₂e de scope 2 market-based résiduel en 2024 (chiffre groupe, AWS n'est pas isolé) et AWS ne publie aucun facteur kg/kWh market-based. La valeur market-based AWS est donc « non publiée par AWS ». On n'écrira jamais « market-based = 0 ».

Providers tiers (EcoLogits + Jegham v6)

TokenClimate est construit multi-provider (OpenAI, Google, Mistral, DeepSeek, Meta), même si le produit vendu est Claude-first. Les énergies de sortie viennent de trois voies : le modèle paramétrique d'EcoLogits (dépôt genai-impact/ecologits, release 0.10.2 du 2026-06-04 épinglée pour Google et Mistral, 0.11.1 pour la gamme OpenAI courante), les estimations par requête de Jegham et al. v6, Table 4 (la même source primaire que les paramètres Anthropic), ou la règle du proxy prix de la section « Modèles hors catalogue » appliquée à la main. Le ratio E_in = E_out/6 et le cache_read_factor 0.08 appliqués à ces providers sont des extensions TokenClimate, quelle que soit la source de l'énergie de sortie. Un modèle legacy est retiré ou en cours de retrait par son fournisseur (date d'arrêt affichée sur la fiche quand elle existe) : ses énergies et ses derniers prix publics sont conservés pour chiffrer un usage passé, et il sort du tableau /models, des classements et des comparatifs. État par fournisseur au 2026-09-07.

Google. Infra : PUE 1,09, WUE on-site 1,15 L/kWh et CIF 0,345 kgCO₂e/kWh location-based, divulgations Google 2024 rapportées par Elsworth et al. 2025 (arXiv:2508.15734) ; EWIF hors site 3,13 L/kWh, moyenne américaine de l'annexe 2 du guide WRI 2020, cohérente avec un parc d'inférence surtout américain. Énergies : gemini-2.5-pro et gemini-2.5-flash entrent au catalogue le 2026-09-07, proposés par pnpm catalog:propose depuis EcoLogits 0.10.2 (énergie de sortie au milieu de la plage de paramètres actifs, la convention des seeds Google et Mistral). 2.5 Pro = mixture d'experts de 2 000 milliards de paramètres, 200 à 600 actifs, 89,6 tokens/s, plage 10 347 à 24 924, milieu 17 636 Wh/Mtok. 2.5 Flash = 440 milliards, 44 à 132 actifs, 64,6 tokens/s, plage 1 211 à 2 012, milieu 1 611 Wh/Mtok. EcoLogits prête à 2.5 Flash les mêmes hypothèses d'architecture qu'à 2.0 Flash, les deux fiches portent donc la même énergie : limite de la source, publiée telle quelle. E_in = E_out/6, confiance low (architecture non publiée). Prix relevés le 2026-09-07 sur ai.google.dev/gemini-api/docs/pricing : 2.5 Pro 1,25 $ / 10 $ pour les prompts jusqu'à 200 k tokens (2,50 / 15 au-delà, non modélisé), lecture de cache 0,125 ; 2.5 Flash 0,30 / 2,50, lecture de cache 0,03 ; Google facture le stockage du cache à l'heure, pas l'écriture au token. gemini-2.0-flash (arrêt le 2026-06-01, page deprecations), gemini-1.5-pro et gemini-1.5-flash (absents des pages deprecations et pricing, déjà retirés, date non affichée) sont legacy. La famille gemini-1.5-* est absente d'EcoLogits 0.10.2 et garde ses valeurs tokenclimate-manual en confiance low. Extension 2026-10-09 : six modèles Gemini 3.x entrent au catalogue. Prix relevés le 2026-10-09 sur ai.google.dev/gemini-api/docs/pricing (palier payant Standard, texte, aucun palier selon la longueur du prompt), dates de disponibilité générale tirées du changelog de l'API Gemini (ai.google.dev/gemini-api/docs/changelog) : gemini-3.1-flash-lite (2026-05-07) 0,25 $ / 1,50 $, lecture de cache 0,025 ; gemini-3.5-flash (2026-05-19) 1,50 / 9, lecture 0,15 ; gemini-3.5-flash-lite (2026-07-21) 0,30 / 2,50, lecture 0,03 ; gemini-3.6-flash (2026-07-21), gemini-3.7-flash (2026-08-13) et gemini-3.8-flash (2026-09-02) à un prix de lancement de 0,75 / 3,75, lecture 0,075, jusqu'au 31 décembre 2026, puis 1,50 / 7,50, lecture 0,15, à partir du 1er janvier 2027. Le seed facture le prix de lancement, celui payé aujourd'hui. Le prix normal ne peut pas être saisi d'avance (la période la plus récente de pricingHistory doit être égale au prix courant) : il entrera le 2027-01-01 comme nouvelle période. Le tarif audio de 3.1 Flash-Lite (0,50 $ en entrée) n'est pas modélisé. Google ne publie aucune de ces architectures et EcoLogits 0.10.2 ne les couvre pas : la règle du proxy prix est appliquée à la main (priceProxy() de scripts/catalog/add-model.mjs) sur le seed d'avant l'ajout, avec deux règles fixées à cette version pour tout proxy appliqué à la main. L'ancre est prise dans la même gamme : un modèle Flash ou Flash-Lite s'ancre sur gemini-2.5-flash (0,3 / 2,5 $, 269 / 1 611 Wh/Mtok), jamais sur gemini-2.5-pro, qui reste l'ancre de la gamme Pro. Et le ratio se calcule sur le prix catalogue, jamais sur un prix promotionnel ou de lancement : une promotion ne change pas le modèle, comme pour DeepSeek V4.1 Flash et Mistral Large 4. Le ratio garde la borne publiée de ×0,1 à ×4. 3.5 Flash : ratio √(5 × 3,6) = 4,243 borné à 4, soit 1 074 / 6 444 Wh/Mtok. 3.6, 3.7 et 3.8 Flash, sur le prix catalogue de 1,50 / 7,50 : ratio √(5 × 3) = 3,87, soit 1 040 / 6 239. 3.5 Flash-Lite, vendu au prix de 2.5 Flash, en reprend l'énergie (269 / 1 611). 3.1 Flash-Lite : ratio √(0,833 × 0,6) = 0,71, soit 190 / 1 139. Confiance low pour les six, factorVersion tokenclimate-v4-2026-10. La fin du prix de lancement, le 1er janvier 2027, change le prix facturé, pas l'énergie. Alias : la forme OpenRouter google/<id> seulement. gemini-3.1-flash-lite-preview, arrêté le 2026-05-25 et absent de la page pricing, n'en est pas un.

Mistral. Infra : PUE 1,16, la constante EcoLogits pour Mistral (EcoLogits localise Mistral en Suède), pas une déclaration de Mistral ; CIF France 0,056 kgCO₂e/kWh (Ember 2024) ; WUE on-site 0,18 L/kWh, valeur AWS 2023 reprise faute de publication de Mistral ; EWIF hors site 3,67 L/kWh depuis la révision eau du 2026-09-07, facteur France de l'annexe 2 du guide WRI 2020 (consommation, nucléaire et hydraulique compris), à la place de la moyenne américaine de 3,13 que le seed portait par défaut. Prix relevés le 2026-09-07 sur mistral.ai/pricing/api : mistral-large-latest (Mistral Large 3) 0,5 $ / 1,5 $, mistral-medium-latest (Mistral Medium 3.5) 1,5 / 7,5, mistral-small-latest (Mistral Small 4) 0,15 / 0,6 ; la page n'affiche pas de tarif de cache par modèle. Énergies. mistral-large-latest sert Mistral Large 3 (mistral-large-2512) depuis décembre 2025, dont Mistral publie l'architecture (huggingface.co/mistralai/Mistral-Large-3-675B-Instruct-2512 : 675 milliards de paramètres, 41 actifs, mixture d'experts). EcoLogits 0.10.2 n'a pas mis à jour sa fiche et garde le dense 123B de Large 2 pour mistral-large-2512 : TokenClimate rejoue le modèle paramétrique EcoLogits (whPerMtokOut de scripts/crosscheck-ecologits.mjs) sur l'architecture publiée, avec le débit EcoLogits de mistral-large-2512 (41,5 tokens/s) : 2 546 Wh/Mtok en sortie, 424 en entrée, confiance medium, factorVersion ecologits-0.10.2-replay-2026-09. Cinq fois Large 2 pour un modèle quatre fois moins cher : le modèle EcoLogits dimensionne la flotte de GPU sur les paramètres totaux résidents en mémoire, le prix reflète les choix de marge de Mistral, et cette méthodologie publie l'estimation côté physique. mistral-medium-latest (Medium 3.5, dense 128B publié sur Hugging Face, entrée EcoLogits mistral-medium-3-5, 48,1 tokens/s) entre au catalogue par pnpm catalog:propose : 508 Wh/Mtok en sortie, 85 en entrée, confiance medium (architecture publiée, seul avertissement EcoLogits : multimodal). mistral-small-latest garde 35 / 207 : l'entrée EcoLogits 0.10.2 est déjà Small 4 (mixture d'experts de 119 milliards dont 8 actifs, 98,8 tokens/s), rejeu vérifié à 206,7. La fiche de Mistral Large 2 devient mistral-large-2411 (legacy, retrait de Large 2.1 le 2026-05-31 selon docs.mistral.ai/models/overview), énergie EcoLogits Large 2 dense 123B (86 / 515) et derniers prix 2 / 6 conservés. Extension 2026-10-09 : mistral-large-4-0 (Mistral Large 4, version 26.10, sorti le 2026-10-06) entre au catalogue. Mistral publie l'architecture sur docs.mistral.ai/models/mistral-large-4-0 et huggingface.co/mistralai/Mistral-Large-4-1T-A52B : 52 milliards de paramètres actifs, 1 050 milliards au total, mixture d'experts, plus un encodeur de vision de 1,6 milliard que le calcul ignore (seuls les tokens de texte sont comptés). EcoLogits 0.10.2 n'a pas d'entrée Large 4. TokenClimate rejoue donc le modèle paramétrique comme pour Large 3 (whPerMtokOut(52, 1050, 41.5)) : 2 746 Wh/Mtok en sortie, 458 en entrée, confiance medium, factorVersion ecologits-0.10.2-replay-2026-10. Le débit de 41,5 tokens/s est une hypothèse : EcoLogits le retient pour mistral-large-2512 (Large 3), et il est repris faute de mesure pour Large 4. Prix relevés le 2026-10-09 sur docs.mistral.ai/inference/pricing. Mistral y affiche un prix promotionnel de 0,68 $ en entrée, 0,07 $ en lecture de cache et 2,09 $ en sortie, à côté d'un prix catalogue de 1,36 / 0,14 / 4,18. Le seed facture le prix promotionnel, celui payé aujourd'hui. La fin de la promotion entrera comme une nouvelle période de pricingHistory. Limite ouverte : aucune page publique ne donne l'identifiant exact du modèle dans l'API Mistral, ni ne dit si mistral-large-latest sert désormais Large 4. Cet alias reste donc rattaché à Large 3, et mistral-large-4-0 reprend l'identifiant de la fiche du modèle.

L'ACV Mistral : de première main, mais pas décomposable. Mistral a publié en juillet 2025, avec Carbone 4 et le soutien de l'ADEME (méthode AFNOR « IA frugale », ISO 14040/44, GHG Protocol Product Standard), une analyse de cycle de vie de Mistral Large 2 : 20,4 ktCO₂e et 281 000 m³ d'eau consommée après 18 mois d'exploitation, entraînement compris, et pour une réponse de 400 tokens sur Le Chat, 1,14 gCO₂e et 45 mL d'eau. C'est la seule publication de première main sur un modèle Mistral. Elle ne fournit aucun des termes de cette méthodologie : ni Wh par requête, ni PUE, ni WUE, ni litres par kWh, ni localisation des datacenters. Elle ne peut donc pas alimenter le seed, et l'énergie Mistral reste sourcée EcoLogits ou rejouée sur son modèle. Ce qu'elle permet quand même de vérifier, c'est le rapport entre l'eau et le carbone : 45 mL pour 1,14 g, soit 39 mL par gramme. Les paramètres France de cette méthodologie (EWIF 3,67 L/kWh, CIF 0,056 kgCO₂e/kWh, fabrication 49 gCO₂e/kWh) donnent 39 mL par gramme. L'écart est de 1 %, ce qui conforte le facteur pays retenu à cette révision. Le niveau, lui, ne se recoupe pas. L'ACV porte sur Mistral Large 2, c'est-à-dire la fiche mistral-large-2411 (86 / 515 Wh/Mtok) : pour 400 tokens en entrée et 400 en sortie, cette méthodologie donne 0,027 gCO₂e et 1,1 mL d'eau, quarante-deux fois moins que l'ACV. Sur mistral-large-latest (Large 3, 424 / 2 546 Wh/Mtok), la même réponse vaut 1,19 Wh, soit 0,14 gCO₂e, et l'écart tombe à environ 8×. Ramené à nos facteurs, le chiffre de Mistral vaut environ 10 Wh par réponse, soit 25 000 Wh par million de tokens contre 515 pour Large 2 chez EcoLogits. Un écart de cet ordre ne vient pas du mix électrique. L'explication la plus probable est un périmètre différent : une ACV complète compte en principe la fabrication des serveurs et l'eau de production de l'électricité, et celle-ci amortit selon toute vraisemblance l'entraînement sur chaque réponse, là où cette méthodologie exclut l'entraînement et n'amortit que le matériel. Mistral ne publie pas la part de l'entraînement dans son chiffre par réponse, et les résultats annoncés dans la Base Empreinte de l'ADEME n'y sont pas lisibles sous une forme décomposée à la date de cette version. Tant que cette décomposition n'existe pas, l'écart est publié ici plutôt que lissé, et les fiches Mistral y renvoient.

OpenAI. Infra : PUE 1.12, CIF 0.35 kgCO₂e/kWh, WUE on-site 0.30 L/kWh, EWIF off-site 4.35 L/kWh (Jegham v6 Table 1, ligne OpenAI/Azure, verbatim ; l'embodied 49 n'en fait pas partie, c'est la constante TokenClimate). Corrige une citation erronée de cette même Table 1 dans le seed précédent (PUE 1.20, CIF 0.3844, EWIF 3.13 : seul le WUE on-site était juste). Énergies : gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini et o3-mini restent sourcés EcoLogits 0.10.2 (confiance low, architectures non publiées) ; o3, o4-mini, gpt-4.1-nano, gpt-4-turbo et o1 reprennent les estimations par requête de la Table 4 (fit OLS 3 points, même méthode que le seed Anthropic ; la ligne utilisée pour o4-mini est « o4-mini (high) », appliquée quel que soit l'effort de raisonnement demandé). o3 et gpt-4-turbo ont un fit propre à deux coefficients (confiance high) ; o4-mini, gpt-4.1-nano et o1 donnent un coefficient d'input négatif sous contrainte, forcé à 0 par NNLS, d'où E_in = E_out/6 et une confiance medium. Extension 2026-07-19 : la gamme courante OpenAI entre au catalogue. gpt-5.5 et la famille gpt-5.4 (mini, nano) sont sourcés EcoLogits 0.11.1 (tag 0.11.1) : énergie output au milieu de la fourchette de paramètres actifs estimés, latence 1/tps, batch 64, replay validé en reproduisant gpt-4o (1676), gpt-4.1 (1536) et gpt-4o-mini (71 Wh/Mtok) depuis les données 0.10.2 ; E_in = E_out/6, confiance low. La famille gpt-5.6 (sol, terra, luna ; GA 2026-07-09) n'est pas encore couverte par EcoLogits 0.11.1 : sol reprend l'énergie de gpt-5.5 et terra celle de gpt-5.4, les modèles qu'ils remplacent au même tarif (page pricing OpenAI, relevée 2026-07-19) ; luna reprend depuis le 2026-09-23 l'énergie de gpt-5.4-nano, au même tarif (voir la correction de la v4.6). Confiance low pour les trois, à remplacer dès couverture EcoLogits. Extension 2026-09-07 : gpt-6-astra (annoncé le 2026-09-03 en aperçu limité, API ouverte les jours suivants ; 10 $ en entrée et 50 $ en sortie par Mtok) entre au catalogue, toujours hors EcoLogits : ses énergies sont celles de gpt-5.5, le modèle catalogué le plus proche en prix de sortie, multipliées par 1,83, moyenne géométrique des ratios de prix (10/5 et 50/30), c'est-à-dire la règle du proxy prix appliquée à la main pour lui donner une fiche ; confiance low. Les prix de la gamme gpt-5.6 sont relevés à la même date sur la page pricing OpenAI : Sol 4 $ / 20 $ (tarif promotionnel jusqu'au 21 novembre 2026), Terra 2 $ / 12 $, Luna 0,2 $ / 1,2 $, écritures de cache facturées 1,25× l'entrée ; les énergies de ces trois modèles ne bougent pas. Correction 2026-09-07 sur les modèles legacy : les pages deprecations et pricing relues, gpt-4o, gpt-4o-mini, gpt-4.1 et gpt-4.1-mini ne figurent pas sur la page deprecations (seul l'ancien instantané gpt-4o-2024-05-13 y est) et restent sur la page pricing standard à leurs prix du seed : ils redeviennent courants, le passage en legacy du 2026-07-19 sur leur absence de la page models était une erreur. Restent legacy, avec leur date d'arrêt : o1, o3-mini, o4-mini, gpt-4-turbo et gpt-4.1-nano (2026-10-23), o3 (2026-12-11). Lectures de cache ajoutées au seed depuis la page pricing : gpt-4o-mini 0,075, gpt-4.1 0,5, gpt-4.1-mini 0,1, o3-mini 0,55. Extension 2026-09-23 : gpt-6-sol (2 $ en entrée, 10 $ en sortie par Mtok, lecture de cache 0,20, écriture 2,50) et gpt-6-luna (0,10 $ / 0,50 $, lecture 0,01, écriture 0,125), sortis le 2026-09-22, entrent au catalogue. Ni EcoLogits 0.11.1 ni la branche principale d'EcoLogits ne les couvrent : même règle du proxy prix appliquée à la main que pour Astra, ancre cherchée parmi les modèles non legacy. Sol s'ancre sur gpt-4o (2,5 / 10 $, même prix de sortie) : ratio √(0,8 × 1) = 0,89, soit 250 / 1 499 Wh/Mtok. Luna s'ancre sur gpt-4o-mini (0,15 / 0,6 $) : ratio √(0,667 × 0,833) = 0,75, soit 9 / 53 Wh/Mtok. Confiance low pour les deux. Prix d'Astra relus le même jour, inchangés. Extension 2026-09-29 : gpt-6.1-sol (2 $ / 10 $, lecture de cache 0,1, écriture 2,5), sorti le 2026-09-29, entre au catalogue hors EcoLogits : même règle du proxy prix appliquée à la main, ancre gpt-6-sol (le modèle non legacy le plus proche en prix de sortie), ratio 1, soit 250 / 1 499 Wh/Mtok ; confiance low.

DeepSeek. Infra : PUE 1.27, CIF 0.6 kgCO₂e/kWh, WUE on-site 1.20 L/kWh, EWIF off-site 6.016 L/kWh (Table 1, ligne DeepSeek/China, verbatim), qui remplacent depuis 2026-07 les anciens chiffres génériques « colo Chine / IEA » (PUE 1.30, CIF 0.555, WUE 0.18, EWIF 3.13), dont le WUE on-site était sous-estimé d'environ 7x. Énergies : deepseek-chat et deepseek-reasoner reprennent les estimations par requête de la Table 4, lignes DS (China-hosted, l'API réellement facturée par ces modèles), dont nous dérivons 6940 et 17442 Wh/Mtok en sortie. Confiance medium depuis la v4.0 : le fit NNLS force le coefficient d'input à 0 pour les deux modèles, et l'énergie d'entrée est alors posée par convention à E_out/6. C'est exactement le cas qui vaut medium aux modèles OpenAI ci-dessus ; la v3.2 leur avait laissé high par inadvertance. Deux réserves publiées plutôt qu'arbitrées en silence. DeepSeek est la ligne la plus fragile du panel de Jegham : matériel inféré des contraintes à l'export, PUE et WUE pris comme la moyenne des trente centres les plus efficients de Chine, et R1 porte la dispersion la plus large de la table (±9,449 sur 19,251, soit 49 %). Et le fit de deepseek-reasoner est mal spécifié : un modèle de raisonnement porte un coût fixe par requête (~16,7 Wh ici) au-dessus d'une pente de ~8154 Wh/Mtok, or une droite forcée par l'origine reverse ce coût fixe dans la pente et la gonfle d'environ 2,7× (R² centré -2,76, soit moins bon que la moyenne de ses trois points source). Nous conservons 17442 : un facteur en Wh/Mtok ne sait structurellement pas porter une constante par requête, corriger demande une autre forme d'équation, pas une autre constante. Extension 2026-09-07 : deepseek-chat et deepseek-reasoner ont été retirés par DeepSeek le 2026-07-24 (api-docs.deepseek.com/news/news260424) et passent legacy, énergies et derniers prix conservés. deepseek-v4-flash et deepseek-v4-pro (aperçu V4 du 2026-04-24, versions servies V4-Flash-0731 et V4-Pro-0813) entrent au catalogue. Ils ne sont pas couverts par EcoLogits 0.10.2 : la règle du proxy prix est appliquée à la main, ancre = modèle DeepSeek seedé le plus proche en prix de sortie, ratio = moyenne géométrique des ratios de prix d'entrée et de sortie, borné [0,1 ; 4]. Les prix d'ancre sont ceux des seeds (liste DeepSeek de l'ère V3-0324 / R1-0528, la même que les estimations de la Table 4 qu'ils portent). deepseek-v4-flash (0,44 / 1,32 $) s'ancre sur deepseek-chat (0,27 / 1,1) : ratio √(1,630 × 1,2) = 1,398, soit 1 618 / 9 705 Wh/Mtok. deepseek-v4-pro (1,32 / 3,96 $) s'ancre sur deepseek-reasoner (0,55 / 2,19) : ratio √(2,4 × 1,808) = 2,083, soit 6 056 / 36 335 Wh/Mtok. Confiance low pour les deux. Deux réserves publiées : v4-pro hérite de l'ajustement mal spécifié de R1 (pente gonflée d'environ 2,7×), ce qui en fait l'énergie de sortie la plus fragile du catalogue ; et DeepSeek publie les architectures V4 (Pro 1 600 milliards de paramètres dont 49 actifs, Flash 284 dont 13), un rejeu paramétrique type EcoLogits serait une meilleure dérivation dès qu'un débit en tokens/s sera disponible. Prix relevés le 2026-09-07 sur api-docs.deepseek.com/quick_start/pricing, tarif de pointe (heures creuses à moitié prix, non modélisé) : v4-flash 0,44 $ entrée hors cache / 0,014 lecture de cache / 1,32 sortie ; v4-pro 1,32 / 0,044 / 3,96. Prix 2026-10-09 : V4.1 Flash. DeepSeek a sorti V4.1 Flash le 2026-09-10 (api-docs.deepseek.com/updates). V4 Flash est retiré, et le nom deepseek-v4-flash est routé vers V4.1 Flash et facturé au prix Flash. Le nouveau nom est deepseek-flash. La page pricing relue le 2026-10-09 donne 0,30 $ en entrée hors cache, 0,006 en lecture de cache et 1,20 en sortie (tarif de pointe). La fiche garde son identifiant et prend une période de prix datée : ce tarif à partir du 2026-09-10, l'ancien avant (0,44 / 0,014 / 1,32). Une ligne d'usage antérieure garde donc son prix. La date de début de l'ancienne période (2026-04-24, aperçu V4) est une borne basse, pas une date de prix vérifiée. deepseek-flash, deepseek-v4.1-flash et deepseek-v4-flash-vision-exp deviennent des alias de la fiche, affichée « DeepSeek V4.1 Flash ». L'énergie n'est pas recalculée : elle reste le proxy calculé sur le prix de V4 Flash (1 618 / 9 705 Wh/Mtok). DeepSeek ne publie pas l'architecture de V4.1 Flash, et une baisse de prix ne mesure pas une baisse d'énergie. Reprendre le proxy au nouveau prix la baisserait d'environ un cinquième (ratio 1,10 au lieu de 1,40) sur un seul signal commercial. Elle sera re-dérivée quand l'architecture sera publiée. deepseek-v4-pro (version V4-Pro-0813), relu le même jour, est inchangé à 1,32 / 0,044 / 3,96.

Meta. llama-3.1-8b-instant et llama-3.3-70b-versatile, estimations de la Table 4 avec un fit propre à deux coefficients (pas de convention E_in = E_out/6 ici). Correction 2026-09-07 : la Table 1 de Jegham v6 a une ligne Meta/AWS propre (PUE 1,14, WUE 0,18, EWIF 5,11 L/kWh, CIF 0,287 kgCO₂e/kWh). Le seed disait l'hébergeur non nommé et décompressait les énergies de la Table 4 avec un PUE générique de 1,2 qui n'était celui de personne. Les ajustements (a = 21,5 et b = 151,9 Wh/Mtok avec PUE pour Llama 3.1 8B ; a = 35,2 et b = 729,7 pour Llama 3.3 70B) sont décompressés à 1,14 : 19 / 133 et 31 / 640 Wh/Mtok IT (au lieu de 18 / 127 et 29 / 608, sous-estimés de 5 %). Le PUE de service passe aussi à 1,14 : Groq, l'hébergeur tarifé, ne publie ni PUE ni mix électrique, la ligne AWS est le seul choix sourcé, et le CIF, l'EWIF et le WUE (0,12, millésime AWS 2025 de première main) suivaient déjà cette ligne. Confiance medium inchangée : infra AWS proxée pour un service Groq sur LPU, matériel différent de l'infra GPU des estimations de Jegham. Groq a retiré les deux modèles pour les paliers gratuit et développeur le 2026-08-16 (console.groq.com/docs/deprecations) ; groq.com/pricing redirige vers l'accueil et console.groq.com/docs/models les liste « Enterprise, contact sales » : les deux fiches passent legacy, derniers prix publics du 2026-07-03 conservés.

Coût USD

Le coût est la valeur API théorique de l'usage (ce qu'il coûterait en pay-as-you-go), pas le prix d'abonnement réellement payé. Les prix sont la grille publique de l'API Claude (platform.claude.com/docs/en/about-claude/pricing), relue le 2026-09-07. Les paliers Start, Build et Scale ne fixent que les limites de débit, pas les prix. Depuis la v4.5 les prix sont datés : une ligne d'usage est facturée au tarif en vigueur le jour où elle a eu lieu, et le registre conserve les périodes de prix (pricingHistory dans les seeds, fonction pricingAt de lib/providers/registry.ts). Sans date, comme dans le calculateur public, c'est le tarif courant qui s'applique. L'énergie, le CO₂e et l'eau ne dépendent jamais de la date.

Le prix d'introduction de Sonnet 5 (2 / 10 $ au 30 juin 2026) est devenu définitif : la remontée à 3 / 15 prévue au 1er septembre a été annulée. Claude Fable 5.1, sorti le 1er septembre 2026, facture la lecture de cache à 0,025× l'entrée, contre 0,1× sur les autres familles.

Claude Opus 5.5 est sorti le 22 septembre 2026 à 4 / 20 $, lecture de cache 0,20 $ (0,05× l'entrée), prix inchangés depuis. Claude Sonnet 5.5 est sorti le 28 septembre 2026 aux prix de Sonnet 5, et le 7 octobre Anthropic a baissé sa lecture de cache de 0,20 $ à 0,10 $ (0,05× l'entrée). Claude Haiku 5.5 est sorti le 7 octobre 2026 à 0,10 / 0,50 $ (platform.claude.com/docs/en/release-notes/overview). Sur l'API Anthropic, les alias opus, sonnet et haiku de Claude Code pointent sur ces trois modèles (code.claude.com/docs/en/model-config). Une famille est facturée au prix de son modèle par défaut du moment, au jour UTC de la ligne. La famille Opus change le 2026-09-22 : environ 20 % de moins, 60 % sur la lecture de cache. Les familles Sonnet et Haiku changent le 2026-10-07 : la famille Haiku devient dix fois moins chère, la lecture de cache de la famille Sonnet est divisée par deux. Rien ne bouge avant cette date : Sonnet 5.5 et Sonnet 5 avaient les mêmes prix jusque-là. Limite : une ligne stockée au niveau de la famille (événements du CLI) prend le prix du nouveau modèle même si la session tournait sur l'ancien. Une ligne Haiku après le 7 octobre sur Haiku 4.5 (Claude Code avant la v2.1.293, ou Haiku 4.5 choisi explicitement) est jusqu'à dix fois trop basse, une ligne Opus après le 22 septembre sur Opus 5 ou 4.x l'est de 20 %.

Prix par modèle exact (depuis la v4.6). Le tableau ci-dessus donne le prix d'une ligne qui ne porte qu'une famille. Quand la ligne porte l'identifiant brut du modèle et que ce modèle a son propre prix, c'est ce prix qui s'applique, quelle que soit la date. Grille relue le 2026-09-23, puis le 2026-10-09 pour Opus 5 et 4.x, Sonnet 5 et Haiku 4.5 :

Haiku 5.5, prix de la famille Haiku depuis le 7 octobre, a deux grilles selon la longueur du prompt. Au-delà de 100 000 tokens d'entrée par requête, lectures et écritures de cache comprises, la requête paie 0,50 $ en entrée, 2,50 $ en sortie, 0,625 $ et 1 $ en écriture, 0,05 $ en lecture : cinq fois plus. Une ligne d'usage agrège une journée ou une session et ne dit pas la longueur de chaque prompt. Ce palier n'est donc pas modélisé : tout token Haiku 5.5 est facturé à la grille courte, et un usage Haiku 5.5 à longs prompts est sous-facturé, jusqu'à 5×.

Opus 5.5, Sonnet 5.5 et Haiku 5.5 sont les familles Opus, Sonnet et Haiku : leurs identifiants renvoient à la famille, et une ligne datée prend le prix de la famille à sa date. Un identifiant daté (claude-opus-4-8-20260501) prend le prix de son modèle ; claude-opus-5 n'attrape ni claude-opus-5-5 ni claude-opus-5-50, qui restent à la famille. L'énergie, le CO₂e et l'eau ne changent pas : un prix différent ne dit rien de l'énergie consommée, Opus 5.5 garde l'énergie de la famille Opus. Ces modèles ne sont pas des fiches publiques à part, leur fiche reste celle de leur famille.

Ce qui porte déjà l'identifiant brut : les synchronisations Admin API (rapport d'usage et Claude Code Analytics). Ce qui ne le porte pas encore : les événements du CLI. Le hook pousse la famille du modèle principal de la session, et les tokens des sous-agents y sont repliés sous ce même modèle. Une session Opus 5 poussée par le CLI est donc facturée au prix de la famille Opus (Opus 5.5 depuis le 22 septembre), et une session Sonnet 4.6 au prix de la famille Sonnet, jusqu'à la version du CLI qui poussera un détail par modèle. Opus 4.1 et 4 (15 / 75 $, retirés le 2026-08-05 et le 2026-06-15) et Haiku 3.5 (0,8 / 4 $, retiré) restent résolus au prix de leur famille : retirés avant le 22 septembre, ils gardent la période à 5 / 25 $, fausse pour un usage d'avant 2026. Haiku 3.5 et Haiku 3 ont été retirés avant le 7 octobre 2026 : leurs lignes gardent la période à 1 / 5 $.

L'écriture en cache d'une heure est facturée 2× l'entrée, contre 1,25× en cache 5 minutes. Le rapport d'usage de l'Admin API sépare les deux compartiments, mais le dashboard compte encore toute écriture à 1,25× pour l'instant. Une source ne les sépare pas du tout : Claude Code Analytics, qui porte l'usage sur abonnement (Claude Code y écrit en cache 1 h, ce coût est donc sous-estimé). Le calculateur public compte l'écriture au tarif 5 minutes par défaut ; en mode « J'ai mes volumes réels », une option sous le champ d'écriture sépare la part en cache 1 heure, facturée à son tarif (tw1h dans l'URL, une partie de tw). Les profils prédéfinis restent au tarif 5 minutes. L'énergie ne dépend pas de la durée du cache. Le coût est un équivalent API aux tarifs publics, pas le montant réellement facturé (abonnements, remises, engagement).

Pour une session, avec les prix de la période valide à sa date :

cost_usd = (
    input_tokens * input_price
  + cache_creation_tokens * cache_write_price
  + cache_read_tokens * cache_read_price
  + output_tokens * output_price
) / 1_000_000

Implémenté dans lib/co2.ts, fonction co2ToCostUsd, arrondi à 4 décimales. Les prix cache par modèle sont matérialisés dans lib/providers/seed/anthropic.json (cacheWriteUsdPerMtok, cacheReadUsdPerMtok). Sur des données dédupliquées, ce calcul se réconcilie à quelques pourcents près avec ccusage.

Affichage en euros. Le calculateur public et le cockpit affichent le coût en euros : le montant USD est converti à l'affichage au taux de référence de la BCE porté par lib/currency.ts (EUR_PER_USD, EUR_RATE_ASOF), soit 0,8729 au 2026-06-22 (1 EUR = 1,1456 USD). Le taux est rafraîchi à la main environ tous les mois ; les montants sont stockés en USD, jamais en euros, donc une ligne historique n'est jamais reconvertie. Le calculateur n'affiche ni le taux ni sa date : une ligne sous le cockpit dit que les chiffres sont des estimations aux tarifs publics, le détail de la conversion est écrit ici.

Comptage des tokens et déduplication

Les comptes viennent du parsing des transcripts JSONL (message.usage). Les messages assistant sont dédupliqués par (message.id, requestId) en gardant la dernière occurrence, avant sommation. C'est nécessaire parce que les sessions reprises ou compactées rejouent les messages précédents dans le même fichier, et que le streaming réécrit le même message plusieurs fois avec un output_tokens croissant. Sans dédup, la somme brute sur-compte d'environ 3x. Ce comportement correspond à la déduplication effectuée par ccusage.

Couverture des sources : ce que la mesure voit, ce qu'elle ne voit pas

On nous pose la question à chaque échange : « comptez-vous le chat claude.ai ? Claude Cowork ? ». Voici la réponse, surface par surface. Deux chemins de collecte existent :

• La clé admin Anthropic (sk-ant-admin01-...) se crée dans la console, par un administrateur de l'organisation. Elle expose deux APIs en lecture seule : l'Usage & Cost API (tokens et dépense de l'usage API, par modèle et par jour) et la Claude Code Analytics API (usage Claude Code par utilisateur et par jour). Nous ne gardons les tokens de cette seconde API que pour les sièges d'abonnement : le Claude Code facturé à l'API arrive déjà par le rapport d'usage, sur une ligne par clé, sans la personne. Sur un plan Team, la présence de ces sièges dans l'API n'a pas encore été vérifiée sur un compte réel.
• Le suivi continu ajoute le CLI TokenClimate installé sur les postes, qui mesure les sessions Claude Code localement (section « Comptage des tokens et déduplication »). Les recouvrements entre sources sont soustraits par réconciliation (jour, membre, famille de modèle) : un même token n'est jamais compté deux fois.

Les limites, en toutes lettres :

• Le chat claude.ai d'un plan Team n'a aucune API. Anthropic n'expose ni tokens ni compteurs pour le chat sous abonnement Team, et l'accès automatisé à claude.ai est interdit par ses conditions d'utilisation. Aucun outil du marché ne couvre cette surface. Le rapport la déclare hors périmètre, il ne l'estime pas.
• Claude Cowork suit la même règle sur un plan Team : usage sous abonnement, aucune API.
• Le cas Enterprise est différent. Les organisations Claude Enterprise disposent d'une Enterprise Analytics API qui expose l'activité du chat, de Claude Code et de Cowork par utilisateur (données depuis le 2026-01-01). Elle exige une clé Analytics créée sur claude.ai par le primary owner, distincte de la clé admin, et ne fournit des tokens que pour les plans facturés à l'usage : en plan à sièges, l'activité est disponible, mais le CO₂e y serait dérivé de compteurs d'activité et non de tokens réels, donc estimé. On active ce chemin sur demande.
• OpenRouter est un péage, pas un fournisseur. Chaque ligne est rattachée au fournisseur réel du modèle et chiffrée avec ses facteurs, sur résolution stricte de l'identifiant : un modèle absent du catalogue garde ses tokens et un CO₂e « non couvert ». Trois limites. Les écritures de cache ne sont pas distinguées au grain quotidien et sont comptées comme de l'input. Une ligne BYOK (clé Anthropic ou OpenAI propre à l'organisation, passée par OpenRouter) est ignorée quand l'Usage API du fournisseur alimente déjà l'organisation, pour ne pas compter deux fois. Claude Code ou un SDK pointés sur OpenRouter sont aussi vus par le CLI ou le SDK, sans réconciliation à ce jour.
• Chaque ligne du rapport a une étiquette : mesuré, estimé ou déclaré. Ce qui n'est pas mesurable est écrit « non couvert ». Aucune estimation implicite ne vient le remplacer.

Équipe. Le dashboard suit l'organigramme courant : une ligne d'usage compte dans l'équipe à laquelle la personne appartient aujourd'hui (employees.team_id), qu'elle vienne du CLI TokenClimate ou d'une clé admin. Une clé API ou un projet sans personne compte dans l'équipe déclarée dans ses réglages de source. L'export ESRS n'a pas de ventilation par équipe : il agrège par fournisseur et famille de modèle, et un changement d'équipe ne modifie aucun de ses totaux.

Clés et projets. Le rapport d'usage de l'API Anthropic n'identifie pas la personne, seulement la clé API et le workspace. Chaque ligne qu'on en tire porte sa clé (source_scope_id) et tombe sur une ligne collective propre à cette clé ; l'usage passé sans clé, depuis la Console ou le Workbench, reste sur la ligne collective de l'organisation. Le produit de la ligne (Claude Code, chat, Cowork, Office) vient du mapping de la clé, à défaut de celui de son workspace, et vaut claude_code quand aucun des deux n'en déclare. Côté OpenAI, source_scope_id porte le projet, et l'usage que l'API n'attribue à aucun membre tombe sur la ligne collective de son projet. Une ligne collective ne compte ni dans l'effectif ni dans la taille des équipes, mais son usage compte dans tous les totaux. Le recouvrement avec le CLI se calcule par jour et par famille de modèle, puis se répartit entre les clés au prorata de leurs tokens API.

Qualité de donnée. Chaque ligne d'usage porte un niveau de qualité de donnée (data_quality_tier). Tout ce qui est stocké aujourd'hui, depuis les API, le CLI ou le SDK, porte measured : des tokens comptés par la source. Quatre niveaux moins bons sont prévus pour les usages sans clé, et aucune ligne ne les porte encore : reconstructed (tokens reconstruits), dollars (un montant converti en tokens), counts (un compteur de messages ou de requêtes) et seat (un siège multiplié par un profil d'usage). Le niveau ne change aucun calcul à ce jour.

Visibilité des personnes. Chaque organisation est dans l'un de deux modes. En « agrégats seulement », le défaut de toute nouvelle organisation, l'administrateur voit l'organisation, les modèles, les projets, les clés et projets fournisseurs, et les équipes d'au moins 5 personnes. Les autres équipes sont repliées ensemble dans « Autres équipes », avec les personnes qui n'ont pas d'équipe. Quand ce repli contient des personnes, il en contient au moins 5 : les équipes sous le seuil, les personnes sans équipe et, s'il le faut, la plus petite des équipes affichées. Sans cette règle, le total de l'organisation moins les équipes affichées donnerait les chiffres d'un groupe plus petit. Seule exception, une organisation de moins de 5 personnes : toutes ses équipes sont repliées et elle n'affiche que son total. Le même repli vaut dans la comparaison entre équipes, sur la page d'une équipe et pour les campagnes d'email par équipe. Les fiches individuelles, le roster et le leaderboard par membre disparaissent, et aucun email ne peut viser une seule personne. Les lignes collectives (une clé API, un projet) restent nommées : une clé n'est pas une personne. Chaque salarié voit ses propres chiffres sur sa page personnelle, et le récap mensuel qui lui est adressé continue. En « personnes visibles », le produit affiche les noms sans seuil ; l'organisation y passe par une déclaration datée de l'information des salariés (CSE consulté, ou petite équipe où tout le monde est informé et d'accord), journalisée et reprise dans les exports. Limite : le nom d'un projet reste visible dans les deux modes, et un projet à un seul contributeur dans une petite organisation peut désigner quelqu'un. L'export CSV des appels reste disponible en mode agrégats sans la colonne personne ; chaque ligne garde son horodatage et son projet, même limite que le nom de projet.

Modèles hors catalogue : estimation par défaut

Un modèle absent du catalogue (lib/providers/seed/*.json) n'a ni énergie ni prix dans le registre. Jusqu'à la v4.2, ses tokens étaient comptés et son CO₂e affiché « non couvert ». Depuis la v4.3, deux temps.

Temps 1, le catalogue. Le script pnpm catalog:propose cherche le modèle dans le fichier models.json d'EcoLogits (release épinglée 0.10.2), rejoue leur modèle paramétrique sur les hypothèses d'architecture publiées (énergie de sortie au milieu de la plage min-max de paramètres actifs, la convention des seeds Google et Mistral), pose E_in = E_out / 6, prend le prix public dans le snapshot OpenRouter et imprime une entrée seed en confiance low, provenance incluse. Un humain la valide et la colle : le modèle entre au catalogue, avec sa fiche. Rien n'est écrit automatiquement.

Temps 2, le proxy prix. À l'ingestion, un modèle encore absent du catalogue mais dont le fournisseur est seedé (paramètres d'infra connus) et dont le prix public figure dans le snapshot OpenRouter (lib/providers/seed/openrouter-prices.json, régénéré par pnpm prices:refresh, périmé au-delà de 120 jours) est estimé depuis le modèle catalogué de son fournisseur le plus proche en prix de sortie (distance en logarithme) :

r_in  = prix_in(modèle)  / prix_in(ancre)
r_out = prix_out(modèle) / prix_out(ancre)
ratio = borné( racine(r_in × r_out), 0.1, 4 )
E_in  = E_in(ancre)  × ratio
E_out = E_out(ancre) × ratio

Les deux prix viennent de la même liste, le snapshot, l'ancre étant retrouvée par son identifiant ou ses alias OpenRouter ; le prix du seed ne sert qu'en dernier recours. Sur les modèles à poids ouverts, OpenRouter route vers l'hébergeur le moins cher et son prix diffère du seed jusqu'à 2,5× (Llama 70B : 0,32 contre 0,79 $ par Mtok en sortie) : mélanger les deux listes fausserait chaque ratio. La borne [0,1 ; 4] est un garde-fou, pas le résultat attendu : l'ancre étant la plus proche en prix, le ratio est en général proche de 1. Un prix nul (offre gratuite, facturation à la seconde) n'est pas un signal : le modèle reste non couvert.

Le résultat porte co2_confidence = low, factor_version = price-proxy-openrouter-<AAAA-MM> (mois du snapshot) et le nom de l'ancre. Il n'entre pas au catalogue public. Les exports ESRS listent la version de facteur par ligne, donc le proxy y est lisible. Exemple rejouable sur le snapshot du 2026-09-07 (deepseek-v4-flash, l'exemple de la v4.3, est entré au catalogue depuis) : deepseek-v3.2 (0,269 / 0,4 $ par Mtok) ancré sur deepseek-chat (0,32 / 0,89 $ sur la même liste) : ratio 0,61, soit 711 / 4 266 Wh par Mtok contre 1 157 / 6 940 pour l'ancre. Il est épinglé dans tests/unit/price-proxy.test.ts.

Ce que le proxy ne sait pas. Le prix reflète des marges, des prix d'appel et des choix commerciaux, pas seulement l'énergie : au sein du catalogue, les Wh par dollar de sortie varient d'un facteur 100 chez OpenAI (o3-mini contre gpt-4.1-nano), 6 chez Google, 4 chez Mistral. C'est la barre d'erreur du proxy, tier T3. Les fournisseurs sans seed (xAI, Qwen, Z.ai, MiniMax…) ne sont jamais estimés : il leur manque un PUE et un mix électrique sourcés, et un proxy ne les invente pas. Ils restent « non couverts » et remontent dans le résultat de synchronisation.

Ce qui change par rapport à la v4.2. Le rabattement par expression régulière de famille, qui prenait la première entrée de la famille (un Llama 70B chiffré en 8B, un Gemini Pro au prix Flash), est retiré pour tous les fournisseurs sauf Anthropic, dont le seed est par famille. Les identifiants non catalogués qui en dépendaient passent au proxy quand ils ont un prix public, et deviennent non couverts sinon ; le recalcul (pnpm recompute:co2) liste les uns et les autres.

Modèles exclus (non Anthropic)

Claude Code peut être pointé vers des modèles non Anthropic (par exemple un modèle local derrière ANTHROPIC_BASE_URL). Leur profil d'impact n'est pas celui d'un datacenter AWS : ni les énergies ni le pricing API ne s'appliquent. Les sessions dont le modèle dominant ne contient pas claude (y compris le marqueur <synthetic>) ne sont pas poussées par le CLI.

Équivalences affichées

Pour rendre les unités tangibles, le dashboard, le deck et les emails affichent des équivalences. Toutes sont sourcées et interpolées depuis lib/co2-equivalences.ts (ré-exporté par lib/co2.ts), jamais recopiées :

• Eau : douches de 5 minutes, environ 60 L. Source ADEME, agirpourlatransition.ademe.fr, page « Astuces pour réduire sa facture d'eau » : 35 L pour une douche rapide de moins de 5 minutes, 100 L pour 15 minutes ; 60 L est le haut de la fourchette ADEME (35 à 60 L) pour un débit courant de 12 L/min sur 5 minutes. round(water_ml / 60_000), fonction waterToShowers ; en dessous d'une douche, aucune équivalence n'est affichée.
• CO₂e, voiture : 142 gCO₂e par kilomètre pour une voiture thermique, fabrication incluse (111 g/km usage seul). Source Impact CO₂ (impactco2.fr/outils/transport/voiturethermique), ADEME, modélisation 2025. car_km = round(co2_grams / 142), fonction co2ToCarKm. Même facteur que le plugin OSS claude-carbon. L'ancien « 120 gCO₂e/km, facteur ADEME du puits à la roue » ne correspondait à aucune publication ADEME et a été retiré en v4.5 ; les kilomètres affichés baissent de 15 %.
• CO₂e, prompt de référence : Google publie 0,03 gCO₂e market-based pour un prompt Gemini médian de 0,24 Wh (arXiv:2508.15734). Le 0,09 gCO₂e location-based cité par le produit est une dérivation TokenClimate : 0,24 Wh × 345 gCO₂e/kWh, l'intensité location-based 2024 du même papier.

Recommandations du deck

La dernière slide du deck COMEX (export PPTX, lib/exports/deck-layout.ts, seuils dans lib/exports/deck-recommendations.ts) n'écrit jamais de phrase générique : chaque carte est déclenchée par un seuil nommé, chiffrée sur la période, et les points vérifiés sans alerte sont listés. Au plus trois cartes (MAX_RECOS = 3), triées carbone d'abord, euros ensuite. Les euros portent sur la part facturée à l'usage (meteredTotalUsd / apiEquivalentTotalUsd) : un détenteur de siège qui passe d'Opus à Sonnet n'économise pas un euro, le CO₂e s'applique en revanche à chaque token. Les gains sont des estimations, jamais des mesures.

Seuils :

• Opus sur des appels courts : appels Opus sous SHORT_OUTPUT_TOKENS tokens de sortie (lib/explorer/signals.ts), affichés quand ils pèsent au moins 10 % du coût de la période (OPUS_SHORT_MIN_COST_SHARE = 0.1). Gain calculé sur les facteurs et prix Opus moins Sonnet du registre, à volume constant. Sous 10 % du coût, la carte déplace du bruit ; au-dessus, le routage par défaut est la première décision d'un lead tech.
• Cache peu utilisé sur l'API : taux de lecture cache sur les sources cacheables sous 30 % (CACHE_LOW_RATE = 0.3), gain estimé jusqu'à 50 % (CACHE_TARGET_RATE = 0.5), seulement si ces lignes pèsent au moins 5 % du coût (CACHE_MIN_COST_SHARE = 0.05). Base Sonnet. 30 % est le point bas observé sur des agents avec system prompt stable, 50 % une cible atteignable sans réécriture de l'application.
• Un abonnement coûterait moins que l'usage : membres à l'usage seul dont la facture de la fenêtre dépasse un siège Max 20x (FinOps présent).
• Sièges sous-utilisés : sièges dont l'usage vaut moins de 50 % du prix (IDLE_SEAT_USAGE_RATIO = 0.5). Sous la moitié, le plan inférieur ou l'usage pur est moins cher au renouvellement.
• Concentration par projet : à partir de 5 projets actifs (CONCENTRATION_MIN_PROJECTS = 5), quand les trois premiers font au moins 60 % du CO₂e rattaché (CONCENTRATION_SHARE = 0.6). Gouvernance, pas de gain chiffré.
• Projection annuelle : seulement à partir de 14 jours écoulés (PROJECTION_MIN_DAYS = 14), facteur 365 / jours.

Hypothèse cache de la carte « Cache peu utilisé » : le gain suppose une lecture cache facturée au prix de lecture du registre (0,1× l'entrée sur Sonnet) et comptée à cache_read_factor (0,08) de l'énergie d'entrée, sans compter l'écriture de cache à 1,25× le prix d'entrée et à énergie pleine. Sur un préfixe relu moins de deux fois, l'écriture annule le gain en euros ; la carte surestime donc le gain sur les workloads à faible réutilisation. C'est assumé et écrit sur la slide (« Gains estimés, jamais mesurés »).

Hypothèses et incertitudes

Les plages min-best-max par paramètre sont dans le tableau "Paramètres Anthropic". Les leviers dominants sur le chiffre final, par ordre d'importance estimé :

• cache_read_factor (0.08) : les cache reads représentent plus de 90 % des tokens en usage Claude Code intensif. Plage 0.05-0.20, soit environ -40 %/+150 % sur le terme cache.
• Localisation (±30 % sur le CIF) : répartition AWS/GCP/Azure/Colossus non publiée par Anthropic. La plage ne couvre pas la sous-région TVA de Colossus 1 (0,429 kgCO₂e/kWh dans eGRID2024).
• Batch de la source (8) : Jegham v6 estime tout à 8 requêtes simultanées ; un batch de 16 abaisse l'énergie d'environ 43 % dans sa propre annexe A. Sens : surestimation possible, non chiffrée (voir « Note de sensibilité »).
• Capacité inactive (surprovisionnement) : exclue par Jegham v6 (« We exclude idle power consumption from unutilized GPUs in partially loaded nodes »). Google chiffre les machines provisionnées et inactives à 0,02 Wh sur les 0,24 Wh d'un prompt Gemini médian, soit 10 % (Elsworth et al., arXiv:2508.15734). Sens : sous-estimation de cet ordre, non ajoutée faute de donnée chez Anthropic.
• E_out Fable : proxy prix sans aucune mesure publiée, sur la famille la plus chère du catalogue.
• E_in = E_out/6 (providers non-Anthropic) : plage publiée 1/21 à 1,2 (voir « Le ratio input/output »), la convention 1/6 est dans le bas de cette plage. Pour Anthropic, le ratio ~1/21 est récupéré du fit v6, ce n'est plus une hypothèse libre.
• EMB (49) : sensibilité 22-66. Cet encadrement est présenté depuis la v3.7 comme une incertitude d'amortissement ; c'est inexact, il agrège plusieurs sources d'incertitude et le libellé « 3-6 ans » a été retiré du tableau plutôt que de laisser croire à une seule cause. À 3 ans, la durée retenue par l'ACV de l'ADEME, la dérivation donne 82 gCO₂e/kWh, hors de la plage.
• Silicium inconnu : toute la chaîne matérielle suppose un parc NVIDIA. Anthropic sert aussi sur Trainium2 et sur TPU, sans répartition publiée. Ni l'embodied ni les énergies estimées sur GPU ne couvrent ce cas.
• E_out constant en contexte long : l'énergie de décodage par token passe de 107 à 242 mJ entre 4K et 16K de contexte sur GQA (arXiv:2605.11999), soit un facteur 2,26, alors que notre E_out est plat. Le biais va dans le sens de la sous-estimation en régime agentique, précisément le régime de Claude Code.

Citations qui circulent fausses

En vérifiant nos propres sources, nous sommes tombés sur six affirmations qui circulent dans des articles, des mémoires techniques et des rapports, et qui sont fausses au regard du texte cité. Nous les publions parce qu'un lecteur peut nous les opposer, et parce que personne d'autre ne les corrige.

1. « L'article 53 de l'AI Act impose de documenter l'énergie. » L'article 53, paragraphe 1, point a) impose une documentation technique ; c'est l'annexe XI, section 1, point 2 e) qui porte l'obligation sur l'énergie. La formulation exacte à citer est « article 53, paragraphe 1, point a), et annexe XI, section 1, point 2 e) ».
2. « L'annexe XI porte sur l'énergie d'entraînement. » Le texte dit « known or estimated energy consumption of the model ». C'est le point précédent, 2 d), qui vise les ressources de calcul d'entraînement.
3. « SCI for AI donne 130 kgCO₂e par milliard de tokens. » Cette valeur est marquée EXAMPLE dans la spécification de la Green Software Foundation, à titre illustratif et non normatif. Elle n'est un facteur pour personne. La spécification ne fournit d'ailleurs aucune valeur par défaut, ni PUE, ni facteur réseau, ni durée d'amortissement.
4. Les tiers de la méthodologie Llopis (arXiv:2606.10660) cités à l'envers. L'ordre du papier est : Tier 3 = reporting carbone certifié du fournisseur, le meilleur ; Tier 2a = comptes de tokens exacts ; Tier 2b = tokens estimés ; Tier 1 = approche spend-based, la moins bonne. Il n'existe aucun Tier 4. Le papier note au passage qu'aucun grand fournisseur d'IA n'offrait de reporting carbone certifié en mai 2026.
5. « AWS market-based = 0. » AWS revendique un matching 100 % renouvelable mais ne publie aucun facteur kg/kWh market-based ; Amazon dans son ensemble déclare 2,80 MtCO₂e de scope 2 market-based résiduel en 2024, sans isoler AWS. La valeur juste est « non publiée par AWS ».
6. « Le cache est neutre en carbone. » Aucun référentiel normatif, SCI for AI compris, ne traite le cache. L'absence de règle n'est pas une règle : voir « Énergie du cache ».

Caveats

Ce qu'on ne mesure pas, et pourquoi.

• Ordre de grandeur seulement. Ces chiffres sont des estimations structurées et sourcées, pas un bilan réglementaire ni une ACV vérifiée.
• Périmètre tiers datacenter, inférence seule. Terminaux (~50 % de l'empreinte du numérique en France), réseaux (~4 %) et entraînement sont exclus (actualisation ADEME-Arcep de janvier 2025, données 2022), comme la construction des datacenters (moins de 1 %) et le surprovisionnement (de l'ordre de 10 %), voir « Frontières du système ».
• Le terme de cache n'a pas la bonne forme. Il capture un résidu de prefill ; le résidu de relecture KV en décodage, bilinéaire en (contexte × tokens générés), est absorbé dans un E_out constant. Voir « Énergie du cache ». C'est le levier le plus important du chiffre final.
• Le parc matériel réel d'Anthropic n'est pas publié (NVIDIA, Trainium2, TPU). Aucune de nos valeurs matérielles ne le couvre.
• Aucune vérité terrain n'existe sur l'énergie. Rien ne permet de réconcilier nos Wh avec une mesure. Le seul contrôle disponible porte sur le coût, via ccusage, et il ne valide pas la physique.
• Pas de couverture géo-spécifique. CIF appliqué uniformément, sensibilité ±30 % à la localisation réelle.
• Fable est une extrapolation prix. Aucune mesure publiée, à réviser dès publication indépendante (Epoch AI ou équivalent).
• L'embodied est une dérivation, pas une donnée publiée de bout en bout : ACV ADEME des GPU (hors phase d'usage) + BoaviztAPI pour le serveur hôte, amorti 5 ans, sensibilité 22-66 gCO₂e/kWh, 82 à 3 ans.
• L'eau est une consommation estimée, pas une empreinte ISO 14046 : pas de pondération par stress hydrique local, et le total additionne un prélèvement (WUE) et une consommation (EWIF), voir « Sur l'eau ».
• Market-based AWS non publié. AWS ne publie pas de facteur kg/kWh market-based : on l'écrit tel quel, on n'affiche jamais zéro.
• Pas de session annulée. Une session interrompue compte les tokens déjà générés, conformément à l'usage facturé Anthropic.
• Subagents agrégés au parent. Si Claude Code lance des sous-agents pendant une session, leurs tokens sont sommés dans la session parente au modèle dominant de celle-ci (voir cli/scripts/persist-and-push.sh). Petite approximation quand un sous-agent tourne sur une autre famille Claude.
• Historique antérieur au 2026-06-12. Les lignes ingérées avant cette date portent un input_tokens qui inclut les cache writes, et leur co2/coût ne comptait pas le terme cache_read. Elles sont conservées telles quelles (légère sous-estimation).

Comment vérifier

Le CLI TokenClimate expose une commande qui montre les valeurs locales avant push, identiques à ce qui sera ingéré côté dashboard :

tokenclimate org status

Vous y verrez par session : input_tokens, output_tokens, cache_creation_tokens, cache_read_tokens, modèle détecté, et l'impact calculé. Si vous voulez auditer le calcul end-to-end, comparez avec le détail session affiché sur /employee/[id] du dashboard.

Toutes les énergies, tous les paramètres et tous les prix utilisés sont publiés dans ce document, avec leurs sources. Des vecteurs de test donnent des valeurs attendues exactes pour energy_wh, co2_grams et water_ml, rejouées en CI à chaque changement. Aucune valeur n'est calculée côté client opaque.

Colonnes de l'export ESRS

L'export (lib/exports/esrs-export.ts, standard « ESRS E1, CO₂e, GHG Protocol scope 3 catégorie 1 ; ESRS E3, eau, informatif ») agrège les lignes d'usage par fournisseur et famille de modèle. Chaque colonne se relit avec ce document :

Pas de colonnes co2_total_kg_min / _max : une fourchette honnête part des tokens par modèle (le terme cache_read y est borné 0,05-0,20) ; l'export n'a que l'énergie et le CO₂e agrégés par ligne, la borne cache n'y est pas calculable. Une propagation sans terme cache (CIF ±30 % et embodied 22-66 seulement) donnerait une fourchette trop étroite pour être honnête ; ajouter les tokens cache aux lignes de l'export reste à décider.

Recomputabilité

Chaque ligne usage_events conserve ses composantes brutes (input, output, cache write, cache read) : energy_wh, co2_grams, water_ml et cost_usd restent re-dérivables à tout moment depuis la méthodologie courante. Toutes les sources rangent les tokens écrits en cache dans la même colonne, cache_creation_tokens ; la route SDK utilisait une colonne à part, cache_write_tokens, versée dans la première puis supprimée. Après un changement de paramètres ou de pricing, pnpm recompute:co2 (script scripts/recompute-co2.ts, dry-run par défaut, --apply pour écrire) recalcule tout l'historique avec les fonctions de lib/co2.ts et restampe factor_version. Les lignes dont le modèle ne résout pas dans le registry gardent un impact null, jamais inventé.

Versioning

La version courante est celle de l'en-tête de ce document. Les paramètres sont renouvelés au moins une fois par an (exigence AFNOR Spec 2314), et plus tôt si une source épinglée bouge : nouvelle version de Jegham et al., release EcoLogits, publication d'une mesure Fable, facteur market-based AWS. Chaque évolution produit une nouvelle version de ce document.

Depuis la v3.8, cette promesse a un mécanisme plutôt qu'une intention. Les sources épinglées vivent dans un registre versionné (data/sources/registry.json) qui dit, pour chacune, ce qu'on a épinglé, ce que ça alimente et quand un humain l'a relue pour la dernière fois. Un contrôle hebdomadaire interroge arXiv et les releases amont, et deux alertes bloquent la CI : une source dépassée par l'amont sans arbitrage explicite, et un facteur non relu depuis plus de douze mois. Le décalage volontaire est prévu : EcoLogits est épinglé en 0.10.2 pour Google et Mistral alors que la gamme OpenAI courante est sourcée 0.11.1, et c'est enregistré comme tel plutôt que signalé chaque semaine.

La fiche MiNumEco « IA frugale » de novembre 2025 ne cite ni EcoLogits, ni une date d'entrée en vigueur, ni l'article 53 de l'AI Act : la v3.3 de ce document le laissait entendre, c'est retiré. Les formulations de nos rapports renvoient à cette section pour vérification.

Historique :

• v4.15-methodology-2026-10 : Haiku passe de 0,5 à 0,25 fois Sonnet, comme le plugin claude-carbon 1.12.0 (10 / 207 gCO₂e/Mtok au lieu de 20 / 413). Énergie Haiku 61 / 1 262 → 30,6 / 633 Wh/Mtok. La valeur se place entre deux bornes publiques : EcoLogits 0.11.2, qui met Haiku 4.5 à environ 0,07 fois Sonnet 5.5 par token de sortie, et la vitesse de sortie relevée par Artificial Analysis sur l'API d'Anthropic (Haiku 5.5 237,3 tokens/s, Sonnet 5.5 134,9), qui borne le rapport à environ 0,57. Milieu géométrique 0,21, arrondi au-dessus. Le rapport des prix (0,05) n'est pas utilisé. Détail dans « Le rapport Haiku / Sonnet ». Ce qui bouge : l'énergie, le CO₂e et l'eau de toutes les lignes Haiku baissent de 49,8 %, toutes les autres lignes et tous les coûts restent identiques. Pour un million de tokens de sortie Haiku : 238 gCO₂e au lieu de 475. Recompute de la prod requis ; le factorVersion Anthropic passe à tokenclimate-v3-2026-10.
• v4.14-methodology-2026-10 : entrée au catalogue de six modèles Google absents d'EcoLogits : gemini-3.8-flash, gemini-3.7-flash et gemini-3.6-flash (prix de lancement jusqu'au 31 décembre 2026 : 0,75 $ en entrée, 3,75 $ en sortie par Mtok, lecture de cache 0,075, puis le double), gemini-3.5-flash (1,50 / 9, lecture 0,15), gemini-3.5-flash-lite (0,30 / 2,50, lecture 0,03) et gemini-3.1-flash-lite (0,25 / 1,50, lecture 0,025). Énergies par la règle du proxy prix appliquée à la main, avec deux règles désormais écrites pour tout proxy appliqué à la main : ancre dans la même gamme (tous les Flash et Flash-Lite sur gemini-2.5-flash, jamais sur gemini-2.5-pro) et ratio calculé sur le prix catalogue, jamais sur un prix promotionnel. gemini-2.5-flash × 4 pour 3.5 Flash (ratio 4,243 borné à 4, 1 074 / 6 444 Wh/Mtok), × 3,87 pour 3.6, 3.7 et 3.8 Flash sur leur prix catalogue de 1,50 / 7,50 (1 040 / 6 239), énergie de gemini-2.5-flash, vendu au même prix, pour 3.5 Flash-Lite (269 / 1 611), × 0,71 pour 3.1 Flash-Lite (190 / 1 139), confiance low. Aucun autre chiffre ne bouge.
• v4.13-methodology-2026-10 : entrée au catalogue de mistral-large-4-0 (Mistral Large 4, version 26.10), sorti par Mistral le 2026-10-06 et absent d'EcoLogits. Énergies par rejeu du modèle paramétrique EcoLogits sur l'architecture publiée (52 milliards de paramètres actifs, 1 050 au total), avec le débit de Large 3 : 458 / 2 746 Wh/Mtok, confiance medium. Prix promotionnel facturé au 2026-10-09 : 0,68 $ en entrée, 2,09 $ en sortie par Mtok, lecture de cache 0,07. mistral-large-latest reste Large 3. Même jour, grilles Anthropic et DeepSeek relues. Claude Opus 5.5 (sorti le 2026-09-22), Claude Sonnet 5.5 (sorti le 2026-09-28) et Claude Haiku 5.5 (sorti le 2026-10-07) sont les modèles des alias opus, sonnet et haiku de Claude Code : ils deviennent les prix des familles, Opus à partir du 2026-09-22 (4 / 20 $, lecture 0,20, environ 20 % de moins), Sonnet et Haiku à partir du 2026-10-07. La famille Haiku passe à 0,10 / 0,50 $ (lecture 0,01, grille des prompts jusqu'à 100 000 tokens), dix fois moins ; la lecture de cache de la famille Sonnet passe de 0,20 à 0,10, le jour où Anthropic l'a baissée sur Sonnet 5.5. Les lignes d'avant gardent leur prix. Claude Opus 5, 4.8, 4.7, 4.6 et 4.5 (5 / 25 $, toujours vendus), Claude Sonnet 5 (lecture 0,20) et Claude Haiku 4.5 (1 / 5 $) gardent leur propre prix comme modèles exacts. Le palier Haiku 5.5 au-delà de 100 000 tokens (5× plus cher) n'est pas modélisable sur des lignes agrégées. deepseek-v4-flash sert V4.1 Flash depuis le 2026-09-10 et passe à 0,30 / 1,20 $ (lecture 0,006) à partir de cette date, l'ancien prix restant valable avant. Son énergie n'est pas recalculée. Aucune énergie ne bouge.
• v4.12-methodology-2026-10 : le surprovisionnement est nommé. La capacité gardée en réserve pour les pics et les pannes figure désormais parmi les exclusions des « Frontières du système », avec son ordre de grandeur (10 % de l'énergie d'un prompt médian chez Google), et la ligne « Capacité inactive » des hypothèses porte ce nom. Aucun chiffre ne bouge.
• v4.11-methodology-2026-09 : entrée au catalogue de gpt-6.1-sol (2 $ en entrée, 10 $ en sortie par Mtok, lecture de cache 0,1, écriture 2,5), sorti par OpenAI le 2026-09-29 et absent d'EcoLogits. Énergies par la règle du proxy prix appliquée à la main : celles de gpt-6-sol, vendu au même prix (250 / 1 499 Wh/Mtok), confiance low. Aucun autre chiffre ne bouge.
• v4.10-methodology-2026-09 : limites de la source principale et périmètre, publiés. Aucun chiffre d'énergie, de CO₂e, d'eau ni de coût ne bouge, aucune plage de calcul ne change. Ajouts, tous relus à la source : le batch de 8 fixé par Jegham v6 et son effet dans sa propre annexe A (un batch de 16 abaisse l'énergie d'environ 43 %), la classe matérielle « Large » affectée faute de taille publiée et l'hôte compté à 0,5, dans la note de sensibilité ; la capacité inactive exclue par Jegham, environ 10 % chez Google ; le rapport Haiku / Sonnet, dont le 0,5 n'a pas de source primaire (plage de sensibilité 0,2 à 0,6) ; les repères eGRID2024 des sous-régions AWS et de la TVA (0,429), que la plage de ±30 % ne couvre pas ; l'amortissement à 3 ans de l'ACV ADEME (82 gCO₂e/kWh) ; le développement des modèles et la construction des datacenters, exclus, avec leur ordre de grandeur. Corrections : les 273 kgCO₂e de l'ACV ADEME sont fabrication, distribution et fin de vie, sans phase d'usage ; la Table 1 de Jegham cite Electricity Maps en référence [44], sans note de pondération, et la citation « mix-weighted across AWS inference regions », absente de la v6, est remplacée par le texte du §4.1. Couverture des sources : la clé Admin Anthropic n'attribue une personne qu'aux sièges d'abonnement, le Claude Code facturé à l'API reste par clé sauf via le CLI, les sièges d'un plan Team sont à vérifier sur un compte réel, et la ligne OpenAI manquante est ajoutée.
• v4.9-methodology-2026-09 : le Bilan IA est retiré. Ce produit en libre-service, qui lisait une clé admin Anthropic et rendait un rapport ponctuel, n'est plus proposé. Les passages qui le citaient parlent maintenant de la clé admin, du rapport ou du dashboard, sans changer ce qu'ils décrivent. Les plages d'incertitude publiées vivent dans lib/methodology/ranges.ts. Aucun chiffre d'énergie, de CO₂e ou d'eau ne bouge.
• v4.8-methodology-2026-09 : annexe ADPe retirée. Elle ne comptait que l'électricité, avec le facteur du mix américain de la Base IMPACTS de l'ADEME (millésime 2011), appliqué sans PUE, alors que la fabrication du matériel fait l'essentiel de cet indicateur (ACV des GPU de l'ADEME, mars 2026). L'indicateur reviendra quand la part fabrication pourra être allouée à l'usage à partir d'une source. Les deux mentions en Sb eq de l'ACV Mistral sont retirées avec elle. Aucun chiffre d'énergie, de CO₂e ou d'eau ne bouge.
• v4.7-methodology-2026-09 : fabrication du matériel re-sourcée. Le terme GPU de la constante de fabrication (EMB) quitte la déclaration du constructeur (PCF NVIDIA de la carte HGX H100 : 1 312 kgCO₂e pour huit GPU, du berceau à la sortie d'usine) pour l'ACV des GPU publiée par l'ADEME en mars 2026 (Lees-Perasso et al., Hubblo, TND, TIDE, CNRS et INRIA, Tableau 44 : 273 kgCO₂e par H100 SXM 80 Go, du berceau à la tombe, fabrication, transport et fin de vie compris), soit 2 184 kgCO₂e par nœud. Le serveur hôte, la durée de vie de 5 ans, la puissance et le taux d'utilisation ne changent pas. EMB passe de 44 à 49 gCO₂e/kWh IT, la plage publiée 22-66 reste la même. Pour Anthropic, K_co2 passe de 0,37118 à 0,37618 gCO₂e/Wh et la part de la fabrication de 11,9 % à 13,0 % du CO₂e total. Ce qui bouge : le CO₂e de toutes les lignes, de +1,35 % sur Anthropic et Meta, +1,15 % sur OpenAI, +1,19 % sur Google, +0,62 % sur DeepSeek et +4,6 % sur Mistral, dont le mix français bas laisse plus de poids à la fabrication. Recompute de la prod requis ; le factorVersion Anthropic passe à tokenclimate-v3-2026-09. L'énergie, l'eau et le coût ne bougent pas. Le recoupement avec l'ACV Mistral passe de 41 à 39 mL d'eau par gramme de CO₂e, contre 39 publiés par Mistral.
• v4.6-methodology-2026-09 : entrée au catalogue de gpt-6-sol (2 $ / 10 $) et gpt-6-luna (0,10 $ / 0,50 $), sortis par OpenAI le 2026-09-22 et absents d'EcoLogits. Énergies par la règle du proxy prix appliquée à la main : gpt-4o × 0,89 pour Sol (250 / 1 499 Wh/Mtok), gpt-4o-mini × 0,75 pour Luna (9 / 53), confiance low. Prix d'Astra relus, inchangés. Aucun autre chiffre ne bouge. Prix par modèle exact (même version, 2026-09-23) : une ligne qui porte l'identifiant brut d'un modèle ayant son propre prix est facturée à ce prix (Opus 5.5 à 4 / 20 $, lecture 0,20 ; Fable 5.1 et Mythos 5.1 lecture 0,25 ; Fable 5 et Mythos 5 lecture 1 $ ; Sonnet 4.6, 4.5, 4, 3.7 et 3.5 à 3 / 15 $), les familles gardent leurs prix datés, l'énergie de ces modèles est celle de leur famille. Les synchronisations Admin API stockent désormais l'identifiant brut. Les événements du CLI restent au modèle principal de la session. Ce qui bouge : le coût des lignes à identifiant brut concernées (recompute requis), aucune énergie, aucun CO₂e, aucune eau. Correction GPT-5.6 Luna (même version, 2026-09-23) : son énergie était extrapolée depuis gpt-5.4 sur un prix de sortie de 6 $ relevé le 2026-07-19 (6/15 = 0,4×, soit 118 / 706 Wh/Mtok). La relecture des prix du 2026-09-07 a corrigé ce prix à 0,2 $ / 1,2 $ sans recalculer l'énergie. Luna est au tarif de gpt-5.4-nano (0,2 $ / 1,25 $) : il en reprend l'énergie, 24 / 141 Wh/Mtok, comme Sol et Terra reprennent celle du modèle au même tarif. Confiance low inchangée. Le CO₂e et l'eau de GPT-5.6 Luna baissent de 80 %, aucun autre modèle ne bouge.
• v4.5-methodology-2026-09 : publication après l'audit de contenu du 2026-09-07 (743 affirmations vérifiées, 142 corrections, toutes surfaces). Prix Anthropic datés par famille (pricingHistory, pricingAt) : Sonnet à 2 / 10 $ depuis le 2026-06-30 (prix d'introduction de Sonnet 5 devenu définitif), lecture de cache Fable à 0,25 $ depuis le 2026-09-01 (Fable 5.1), 3 / 15 $ et 1 $ avant ; le coût USD de chaque ligne est celui du tarif de son jour, à tous les points d'ingestion et dans recompute:co2 ; la mention « tier 1 » est retirée (les paliers ne fixent que les débits) ; limite déclarée : une famille est facturée au prix de son modèle par défaut courant, Sonnet 4.6 reste à 3 / 15 chez Anthropic et n'est pas distinguable en base. Le coût affiché est en euros au taux BCE daté de lib/currency.ts, écrit dans la section « Coût USD » et sur la tuile du calculateur. Catalogue des fournisseurs tiers réécrit fournisseur par fournisseur : Google, gemini-2.5-pro (2 939 / 17 636 Wh/Mtok) et gemini-2.5-flash (269 / 1 611) par EcoLogits 0.10.2, confiance low, gemini-2.0-flash (arrêt 2026-06-01) et gemini-1.5-* legacy ; DeepSeek, deepseek-chat et deepseek-reasoner legacy (arrêt 2026-07-24), deepseek-v4-flash (1 618 / 9 705) et deepseek-v4-pro (6 056 / 36 335) par proxy prix à la main, confiance low, prix de pointe du 2026-09-07 ; Meta, PUE 1,14 (ligne Meta/AWS de Jegham v6 Table 1) à la place du placeholder 1,2, énergies Llama 19 / 133 et 31 / 640 Wh/Mtok (+5 %), CO₂e et eau par Wh alignés sur la ligne AWS, les deux Llama legacy (retrait Groq 2026-08-16) ; Mistral, prix du 2026-09-07 (Large 3 0,5 / 1,5, Medium 3.5 1,5 / 7,5, Small 4 0,15 / 0,6), mistral-large-latest = Large 3 rejoué sur l'architecture publiée (424 / 2 546, medium), nouvelle fiche mistral-medium-latest (85 / 508), Large 2 conservé en legacy sous mistral-large-2411 (retrait 2026-05-31), paragraphe ACV rattaché à cette fiche ; OpenAI, gpt-4o, gpt-4o-mini, gpt-4.1 et gpt-4.1-mini redeviennent courants (toujours vendus), o1, o3-mini, o4-mini, gpt-4-turbo, gpt-4.1-nano (arrêt 2026-10-23) et o3 (2026-12-11) legacy avec date, lectures de cache ajoutées ; legacy se lit désormais « retiré ou en cours de retrait par son fournisseur ». Exemple du proxy prix rejoué sur deepseek-v3.2. Profils d'usage : TraceLab compte 37 développeurs sur la colonne Claude Code (43 était le total Claude et Codex), cadence 1,9 session par développeur et par semaine (8,0 par mois) au lieu de 1,6 ; ratio entrée/sortie du profil 294 ; 95,5 % de préfixe, 91,5 % relus, 95,8 % de hit sur la colonne Claude ; la médiane du corpus privé se compare à une moyenne TraceLab ; la cadence n'est plus affichée à l'écran ; le corpus de 184 sessions est déclaré non reproductible ; trois questions en mode simplifié. Équivalences : voiture 142 gCO₂e/km (Impact CO₂, ADEME, modélisation 2025, thermique fabrication incluse, même facteur que le plugin OSS) à la place d'un 120 « ADEME du puits à la roue » qui ne correspondait à aucune publication, les kilomètres affichés baissent de 15 % ; douche requalifiée « douche de 5 minutes, environ 60 L » avec la page ADEME citée ; le 0,09 gCO₂e du prompt Gemini est présenté comme une dérivation du 0,03 market-based publié. Export ESRS : eau scindée prélèvement sur site / consommation hors site (E3-4), énergie IT et énergie site distinguées, qualité de donnée pondérée par le CO₂e, label sans liste de sources, colonnes documentées ici. Deck : nouvelle section « Recommandations du deck » (seuils et hypothèse cache), fabrication attribuée à NVIDIA PCF + BoaviztAPI. Rapport Bilan : plage du facteur de lecture cache injectée depuis le code (0,05-0,20), « résidu de prefill », « estime à partir de volumes mesurés », bibliographie complétée (Jegham cinq auteurs, AWS 2025, WRI 2020, Irminsul, Impact CO₂). Réserve tokenizer publiée dans « Date de validité des énergies » : les modèles 4.7 et suivants produisent environ 30 % de tokens de plus à texte égal, un facteur par token calibré avant peut surestimer d'autant, aucun correctif appliqué. Sourcing corrigé : l'embodied 44 n'est attribué à Jegham nulle part et sa dérivation est publiée (7 012 kg sur 43 800 h à 5,6 kW et 65 %) ; Jegham et al. cité avec ses cinq auteurs ; « mesures » devient « estimations » partout où la source est la Table 4 ; Artificial Analysis fournit latence et débit ; Microsoft « estime » 0,31 Wh (v2), le 111 Wh/Mtok est ML.ENERGY v3.0 sur Qwen3-235B en B200, EcoLogits a corrigé son calculateur en ligne ; Irminsul, ligne MLA moyennée et MHA mesurée à 2 048 tokens ; 1,3-51,8 % chez Solovyeva et Castor, triplement 2K→10K sur Llama 3 70B ; OpenAI facture la lecture de cache 0,1× sur sa gamme courante ; Mooncake 30 à 50 %, 75-95 % = CharacterAI et Kimi ; 2,80 MtCO₂e = Amazon entier, pas AWS ; Google 0,03 market-based publié, 0,09 location-based dérivé ; un seul nom de dépôt EcoLogits ; PUE Google sourcé Elsworth et al. ; répartition 50/46/4 sourcée sur l'actualisation ADEME-Arcep de janvier 2025 ; accord Colossus avec SpaceX (ex-xAI), échéance 2029 rapportée par TechCrunch ; AFNOR Spec 2314 : min-best-max et méthode versionnée requalifiés en pratiques propres, location-based en note du §4.3 ; la fiche MiNumEco ne cite ni EcoLogits ni l'article 53 ; gpt-6-astra « annoncé » le 2026-09-03 ; « la v3 » en dur retiré du corps ; Haiku 61 expliqué (facteur OSS arrondi) ; lien de prise de rendez-vous présent dans les deux langues. Ce qui bouge en chiffres : le coût des lignes Sonnet postérieures au 30 juin 2026 baisse d'environ un tiers, celui des lectures de cache Fable postérieures au 1er septembre de trois quarts (recompute prod requis) ; les énergies Meta montent de 5 % (aucune ligne Meta en base) ; les kilomètres affichés sont divisés par 1,18. Aucune énergie, aucun CO₂e, aucune eau Anthropic ne bouge.
• v4.4-methodology-2026-09 : entrée au catalogue de gpt-6-astra (annoncé le 2026-09-03, aperçu limité puis API ouverte les jours suivants), énergies de gpt-5.5 × 1,83 par la règle du proxy prix appliquée à la main, confiance low. Prix de la gamme gpt-5.6 relevés le 2026-09-07 (Sol 4 $ / 20 $ en promotion, Terra 2 $ / 12 $, Luna 0,2 $ / 1,2 $, écritures de cache facturées) : seuls les coûts USD de ces trois modèles changent, aucune ligne OpenAI n'existe en base. Section « Sur l'eau » réécrite : l'écart entre l'EWIF de 5,11 L/kWh et les 1,8 L/kWh de la littérature est une convention d'allocation (évaporation des réservoirs hydroélectriques comptée par WRI, exclue par Grubert et Sanders), pas une erreur à corriger, et le 5,11 est bien une consommation, déclarée comme telle par Jegham ; le guide WRI est daté 2020. Sources eau de Mistral corrigées dans le seed et sur la fiche : le WUE 0,18 est la valeur AWS 2023 reprise faute de publication (pas la Table 1 de Jegham, qui n'a pas de ligne Mistral), et l'EWIF passe de 3,13 (moyenne américaine) à 3,67 L/kWh, le facteur France de l'annexe 2 du guide WRI 2020 : l'eau des modèles Mistral monte de 16 %, aucune ligne Mistral n'existe en base. Le 5,11 d'AWS est vérifié reproductible sur ces mêmes annexes (environ 40 % Nord-Ouest à 9,48 et 60 % Virginie à 2,37). Le calculateur affiche sous l'eau la part du refroidissement sur site, calculée sur le mix. Nouveau paragraphe sur l'ACV Mistral (juillet 2025) dans « Providers tiers » : elle ne fournit aucun de nos termes, son rapport eau/carbone recoupe nos paramètres France à 3 %, son niveau par réponse est 44× le nôtre, écart de périmètre publié plutôt que lissé. Aucun changement d'équation ni d'énergie par modèle ; hors Mistral, aucun chiffre de CO₂e, d'eau ou d'énergie ne bouge.
• v4.3-methodology-2026-09 : nouvelle section « Modèles hors catalogue : estimation par défaut ». Temps 1, pnpm catalog:propose propose une entrée seed depuis EcoLogits 0.10.2 (validation humaine). Temps 2, proxy prix à l'ingestion : énergies du modèle catalogué du même fournisseur le plus proche en prix, × la moyenne géométrique des ratios de prix d'entrée et de sortie, bornée [0,1 ; 4], prix de la même liste (snapshot OpenRouter public, périmé à 120 jours), co2_confidence = low, factor_version = price-proxy-openrouter-<mois>. Le rabattement regex par famille est retiré pour les fournisseurs non Anthropic. Nouvelle ligne T3 « E_out proxy prix » dans le tableau des paramètres. Aucun changement pour les modèles au catalogue ; les lignes hors catalogue passent de « non couvert » à une estimation T3 ou restent non couvertes (fournisseur sans seed, prix absent ou nul), recalcul tracé.
• v4.2-methodology-2026-09 : ajout d'OpenRouter dans « Couverture des sources » : management key, une ligne par jour, personne et modèle, rattachée au fournisseur réel et chiffrée avec ses facteurs sur résolution stricte de l'identifiant. Limites déclarées : écritures de cache comptées en input, lignes BYOK ignorées quand le fournisseur est déjà mesuré, pas de réconciliation avec le CLI ou le SDK. Aucun changement d'équation, de facteur ni de prix : aucun chiffre existant ne bouge.
• v4.1-methodology-2026-09 : ajout de la section « Estimation par unité d'usage (mode simplifié) » : tokens de sortie par session (96 900 000 / 2 676) et par échange (150), et cadence mesurée de TraceLab (1,6 session par développeur et par semaine) affichée comme repère. Aucune cadence n'est publiée, à la différence du tableau de volumes par tâche retiré en v3.7 : la valeur est saisie par le visiteur et reste modifiable dans le champ de volume, seuls les tokens par unité sont dérivés d'agrégats déjà sourcés. Le résultat est arrondi à deux chiffres significatifs et présenté en T3, l'incertitude dominante venant de la cadence déclarée. Aucun changement d'équation, de facteur, de volume de référence ni de prix : à volume égal, aucun chiffre affiché ne bouge.
• v4.0-methodology-2026-08 : correction de sur-qualification des sources. La v6 de Jegham n'est pas une campagne de mesure : sa section 4.2, « Per-Query Energy Consumption Estimation », décrit une simulation Monte Carlo sur puissance de plaque, utilisation supposée et batch fixé à 8, la latence Artificial Analysis étant le seul intrant empirique. Toutes les lignes de la Table 4 sont des estimations modélisées. Le produit écrivait « mesure directe » sur les fiches /models, dans la glose du niveau high, dans les notes de seed publiées en JSON-LD et dans les infobulles du cockpit : tous ces textes sont repris, dans les cinq locales du Bilan. L'échelle de confiance est redéfinie et classe désormais des estimations entre elles. DeepSeek passe de high à medium, son fit étant output-only sous contrainte NNLS avec une convention d'entrée, c'est-à-dire le cas qui vaut déjà medium chez OpenAI. Deux réserves nouvellement publiées : DeepSeek est la ligne la plus dispersée du panel, et le fit de deepseek-reasoner est mal spécifié (R² centré -2,76, pente gonflée ~2,7× par le passage forcé à l'origine), le chiffre étant conservé et tracé plutôt que corrigé à la volée. L'embodied de 44 gCO₂e/kWh n'est plus attribué à Jegham dans deepseek.json et meta.json : la Table 1 n'a pas de colonne embodied et le papier exclut le scope 3, la constante vient de NVIDIA PCF plus BoaviztAPI. Suppression de la version écrite en dur au corps du document, qui annonçait v3.7 deux versions après. Aucun changement d'équation, d'énergie, de paramètre infra ni de prix : aucun chiffre de CO₂e, d'eau ou d'énergie ne bouge.
• v3.9-methodology-2026-08 : correction des niveaux de confiance Anthropic. Opus et Haiku passent de high à medium : leur énergie est extrapolée de Sonnet (×2 et ×0.5), seule la classe Sonnet est mesurée, et le registre les publiait en high par simple effet de sa valeur par défaut, faute de déclaration explicite dans le seed. Les quatre familles déclarent désormais leur confiance en clair (Sonnet high, Opus et Haiku medium, Fable low inchangé). Correction en parallèle de l'attribution des sources infra sur les fiches /models : le PUE et le WUE on-site d'Anthropic et de Meta sont crédités à la publication AWS de première main, et non plus à Jegham, ce que la v3.8 avait déjà acté ici sans le propager au copy public. Aucun changement d'équation, d'énergie, de paramètre infra ni de prix : aucun chiffre de CO₂e, d'eau ou d'énergie ne bouge, seules changent les étiquettes de confiance et deux phrases de sourcing.
• v3.8-methodology-2026-08 : WUE on-site 0.18 → 0.12 L/kWh, re-sourcé sur la publication AWS de première main (millésime 2025) au lieu du rapport Amazon 2023 ; PUE 1.14 inchangé mais re-sourcé de la même façon. Le bloc de paramètres devient explicitement composite. Reclassement des tiers : CIF et EWIF T1 → T2, cache_read_factor T3 → T2, ratio E_in/E_out T2 → T3. Plage publiée du cache_read_factor élargie de 0.05-0.15 à 0.05-0.20. Section « Énergie du cache » réécrite autour de la mesure Irminsul, avec le constat que le terme n'a pas la bonne forme. Sections « Sur l'eau » (addition prélèvement plus consommation) et « Localisation supposée » (Colossus 1, Memphis) réécrites. Amortissement 5 ans sourcé. Nouvelles sections « Date de validité des énergies », « Note de sensibilité : le procès en surestimation » et « Citations qui circulent fausses ». Trois caveats ajoutés. Aucun changement d'équation, d'énergie par modèle ni de prix ; le CO₂e ne bouge pour aucun modèle, l'eau baisse de 1,0 % côté Anthropic.
• v3.7-methodology-2026-08 : retrait de la section « Cas d'usage (une occurrence) » et du tableau associé sur le calculateur public : volumes par tâche jugés trop imprécis pour une surface publique (majorité T3). Les profils d'usage restent ; aucun changement d'équation, de facteur ni de prix.
• v3.6-methodology-2026-08 : ajout de la section « Profils d'usage du calculateur public » (volumes de référence par classe de tokens, cas d'usage token-based, sources et tiers) ; aucun changement d'équation, de facteur ni de prix.
• v3.5-methodology-2026-07 : ajout de la section « Couverture des sources » (surfaces mesurées par la clé admin, chat claude.ai et Cowork hors périmètre sur plan Team, cas Enterprise) ; aucun changement de calcul.
• v3.4-methodology-2026-07 : entrée au catalogue de la gamme OpenAI courante (gpt-5.6, gpt-5.5, gpt-5.4, sourcés EcoLogits 0.11.1 ou extrapolés prix en confiance low) ; les dix modèles OpenAI précédents passent en tier legacy, facteurs conservés pour chiffrer un usage passé.
• v3.3-methodology-2026-07 : ajout d'un paragraphe reliant explicitement EcoLogits (release épinglée) à la fiche MiNumEco de novembre 2025, citée par les formulations du Bilan IA ; aucun changement méthodologique.
• v3.2-methodology-2026-07 : recalibration DeepSeek (mesures directes Jegham v6 DS-native) et OpenAI (Table 1 verbatim), ajout du provider Meta.
• v3.1-methodology-2026-07 : recalibration des énergies Anthropic sur le fit OLS 3 points de Jegham v6 (Sonnet 119/2525 Wh/Mtok, précédemment 580/3480) ; le ratio input/output Anthropic devient une valeur mesurée (~1/21) au lieu de la convention 1/6 ; Opus passe de 3x à 2x Sonnet. Prix, paramètres infra, cache_read_factor et formules inchangés.
• v3.0-methodology-2026-06 : passage énergie-first (Wh/Mtok + paramètres infra), ajout eau et embodied.

Contact

Vous contestez une valeur, un paramètre, une hypothèse ? Écrivez à gaetan.wittebolle@gmail.com ou réservez un échange. Les corrections argumentées sont les bienvenues, le but n'est pas de défendre les chiffres mais d'avoir la meilleure estimation possible avec les données disponibles.