Méthodologie_

Version : v4.0-methodology-2026-08 Mise à jour : 2026-08-27 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. La structure de ce document suit la check-list AFNOR Spec 2314 §4.1 :

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 selon le rapport Arcep de mai 2026 : le tiers datacenter n'est qu'une partie du tout), et l'entraînement des modèles (non alloué à l'inférence, répartition non publiée par Anthropic).

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. 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 xAI portant sur la totalité de la capacité de Colossus 1, près de Memphis, soit 300 MW, jusqu'en mai 2029. 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, et dont nous n'avons pas ouvert le facteur d'émission de sous-région à la source primaire.

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 et pour chiffrer la sous-région TVA.

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 la v3 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.

Deux raisons de ne pas corriger tout de suite plutôt qu'une : le ratio consommation sur prélèvement dépend du facteur de concentration du site, que nous ne connaissons pas, et la base définitionnelle exacte du chiffre WRI de 5.11 L/kWh n'est pas documentée dans notre méthodologie. 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 de production de l'électricité, où le doute est d'un autre ordre : deux publications récentes situent la consommation moyenne des centrales américaines entre 1,8 et 2,3 L/kWh, contre 5,11 retenu ici. Si ce point se confirme, l'eau affichée baissera fortement. Nous ne changerons pas la valeur avant d'avoir rouvert la source WRI primaire.

É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 11.9 % du CO₂e total (0.044 / 0.37118). Le CO₂e total vaut donc le CO₂e d'usage × 1.1345.

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.37118 = 49.76 g   (usage 43.86 g + embodied 5.90 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, l'EWIF et l'embodied restent épinglés sur Jegham N., Abdelatti M., Hendawi A., "How Hungry is AI? Benchmarking Energy, Water, and Carbon Footprint of LLM Inference", arXiv:2505.09598, version v6, Table 1.

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 pondéré par les régions AWS d'inférence (« mix-weighted across AWS inference regions »).

É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, dans le tableau du hub et dans le Bilan IA, 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 relevée par Artificial Analysis étant le seul intrant empirique. 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 mesuré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). 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 %.

Date de validité des énergies

Ces énergies sont valides au 2026-07 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 mesures de novembre 2025. Elles sont renouvelées au moins une fois par an, et plus tôt si une source épinglée bouge.

Note de sensibilité : le procès en surestimation

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

Microsoft (arXiv:2509.20241) mesure 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é publiquement ses estimations à la baisse en mars 2026 pour cause de surestimation, et une mesure sur B200 place un modèle frontier autour de 111 Wh/Mtok.

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 mesuré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 mesuré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 / Mythos 5. 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 :

Trois réserves avant d'en tirer une valeur. La mesure est faite à 4 096 tokens de préfixe, 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 (Solovyeva & Castor), un KV cache plus gros amplifie l'énergie de décodage par token de 1.3 à 51.8 %, et l'énergie par token triple environ entre 2K et 10K de contexte (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.5x). 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 voit dans son Bilan.

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 d'environ 40 % (trace Mooncake, arXiv:2407.00079) à 75-95 % en production (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 (43 développeurs, octobre 2025 à juin 2026) : 95,5 % du volume total en lectures de cache, 0,34 % en output, taux de hit du cache de préfixe 95,7 %.
• 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 (le profil agent retient ~109, conservateur), ~4,17 M tokens par tâche.

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. Le Bilan IA mesure ce ratio sur les données réelles de l'organisation (part du cache lu affichée dans le rapport).

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 l'exigence de l'AFNOR Spec 2314 (§4.3) et 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 déclare 2.80 MtCO₂e de scope 2 market-based résiduel en 2024 et 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. Google et Mistral restent entièrement sourcés depuis EcoLogits 0.10.2 (repo mlco2/ecologits, release du 2026-06-04, version épinglée) : PUE google 1.09, mistral 1.16, énergies output dérivées de leur modèle paramétrique (par exemple gpt-4o : 1676 Wh/Mtok IT, encore sourcé EcoLogits, voir OpenAI ci-dessous). La famille gemini-1.5-* est absente d'EcoLogits 0.10.2 : ses valeurs restent marquées tokenclimate-manual avec une confiance low.

OpenAI et DeepSeek ont été recalibrés en 2026-07 sur Jegham et al. v6, Table 1 et Table 4 (la même source primaire que les paramètres Anthropic) :

• 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 (Table 1, ligne OpenAI/Azure, verbatim). 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 (confiance low, architectures non publiées) ; o3, o4-mini, gpt-4.1-nano, gpt-4-turbo et o1 passent en mesure directe Table 4 (fit OLS 3 points, même méthode que le seed Anthropic). 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 (repo genai-impact/ecologits, 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 est extrapolé par ratio de prix de sortie depuis gpt-5.4 (6/15 = 0,4×). Confiance low pour les trois, à remplacer dès couverture EcoLogits. Les dix modèles OpenAI précédents (gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, gpt-4-turbo, o1, o3, o3-mini, o4-mini) passent legacy : dépréciés ou absents du pricing OpenAI (page deprecations et pricing, relevées 2026-07-19). Leurs fiches et facteurs restent publiés pour chiffrer un usage passé, mais ils sortent du tableau /models, des classements et des comparatifs.
• 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) - remplace 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 ne sont plus des estimations maison, ils reprennent les estimations par requête de la Table 4, rows 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 pour l'instant : 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.

Meta (nouveau provider) : llama-3.1-8b-instant et llama-3.3-70b-versatile, mesurés Table 4 avec un fit propre à deux coefficients (pas de convention E_in = E_out/6 ici). Groq, l'hébergeur tarifé, ne publie ni PUE ni mix électrique : la décompression utilise un PUE générique 1.2 (placeholder mi-gamme hyperscale, non spécifique à Groq), et le CIF et l'EWIF sont proxés depuis la ligne AWS/Anthropic de la Table 1 (0.287 kgCO₂e/kWh, 5.11 L/kWh) et le WUE suit la même ligne AWS, donc le millésime 2025 de première main (0.12 L/kWh), faute de mieux. Confiance medium : PUE et grille non sourcés pour Groq, infra de mesure Jegham (GPU) différente du matériel de service réel (LPU Groq).

Le ratio E_in = E_out/6 et le cache_read_factor 0.08 appliqués à ces providers non-Anthropic sont des extensions TokenClimate, quelle que soit la source de l'énergie output (EcoLogits ou Jegham).

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é. Tarif public Anthropic en vigueur au 2026-06-12, en USD par million de tokens, tier 1, hors discount Entreprise négocié.

Note : Opus 4.6+ est à 5/25. Les 15/75 mentionnés dans la v1 de ce document correspondaient aux Opus 4.0/4.1, retirés du catalogue.

Pour une session :

cost_usd = (
    input_tokens * input_price
  + cache_creation_tokens * (input_price * 1.25)
  + cache_read_tokens * (input_price * 0.1)
  + 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.

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 bilan : « comptez-vous le chat claude.ai ? Claude Cowork ? ». Voici la réponse, surface par surface. Deux chemins de collecte existent :

• Le Bilan IA part d'une clé admin Anthropic (sk-ant-admin01-...), 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, y compris les sièges d'abonnement Team et Enterprise).
• 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 bilan 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.
• Chaque ligne du bilan 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.

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 affiche des équivalences. Toutes sont sourcées :

• Eau : douches de 60 L (équivalence primaire affichée, round(water_ml / 60_000), fonction waterToShowers de lib/co2.ts ; en dessous d'une douche, aucune équivalence n'est affichée).
• CO₂e, voiture : 120 gCO₂e par kilomètre, facteur ADEME pour une voiture particulière européenne moyenne (well-to-wheel, mix essence-diesel-hybride pondéré). car_km = round(co2_grams / 120), fonction co2ToCarKm de lib/co2.ts.
• CO₂e, prompt de référence : un prompt Gemini médian émet 0.09 gCO₂e en location-based (Google 2025, arXiv:2508.15734).

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.
• 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 E_out/26 à E_out/4, choix dans la moitié haute. Pour Anthropic, le ratio ~1/21 est récupéré du fit v6, ce n'est plus une hypothèse libre.
• EMB (44) : 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.
• 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 mesuré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 que mesure le Bilan.

Annexe : ADPe (informationnel)

L'épuisement des ressources abiotiques, éléments (ADPe) est le troisième indicateur prioritaire de l'AFNOR Spec 2314 (priorité 1). La v3 le documente à titre informationnel : pas de colonne en base, pas d'UI.

Usage : adpe = energy_kwh × 9.855e-8 kgSbeq/kWh (facteur ADEME Base Empreinte, via EcoLogits). Par million de tokens, sur les énergies IT v3 :

Ce terme ne couvre que la part « usage » (électricité). La part fabrication de l'ADPe, dominante pour cet indicateur, demanderait une ACV matérielle complète que la v3 ne fait pas.

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, et déclare 2,80 MtCO₂e de scope 2 market-based résiduel en 2024. 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 (rapport Arcep, mai 2026).
• 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 constructeur de bout en bout : PCF NVIDIA + BoaviztAPI, amorti 5 ans, sensibilité 22-66 gCO₂e/kWh.
• 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.

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. 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.

L'outil EcoLogits, épinglé ici en release 0.10.2, est cité par la fiche MiNumEco de novembre 2025, dont l'exigence de mesure prend plein effet en août 2026. Les formulations livrées avec le Bilan IA renvoient à cette section pour vérification.

Historique :

• 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.