Pour les fournisseurs d'IA

Ce qu'on demande

Un fichier JSON public sur votre domaine, décrivant l'énergie que consomme votre inférence :

https://api.exemple.ai/.well-known/ai-impact.json

Pas d'en-tête HTTP, pas de champ dans la réponse d'API : CarboneWatch n'inspecte aucun trafic. Il observe des destinations et des volumes d'octets depuis le poste de l'utilisateur, sans déchiffrer quoi que ce soit — c'est une promesse produit, pas une limite d'implémentation. Un drapeau dans votre réponse serait parfait pour un SDK ; il nous est invisible.

D'où : publié, pas transmis.

La règle qui structure le format

Vous déclarez des wattheures. Nous convertissons en carbone.

L'énergie est mesurable et contredisable ; le facteur carbone ne l'est pas de la même façon. Si chacun choisit le sien, les fournisseurs cessent d'être comparables — un chiffre market-based ramène n'importe quel site à près de zéro, et l'exercice perd son sens.

Nous appliquons donc des facteurs location-based, identiques pour tous. Vous pouvez déclarer votre chiffre market-based en plus : affiché à part, jamais substitué.

Même règle pour les émissions que vous calculez vous-même, par token et sur les deux bases : emissions_declarees les accueille, affichées pour recoupement, jamais employées. Et pour l'entraînement : entrainement s'affiche en ligne séparée, jamais ajouté au chiffre ni à sa fourchette, puisque aucune convention d'amortissement ne fait consensus.

Le format

{
  "version": "cw2",
  "fournisseur": "Exemple",
  "publie_le": "2026-08-25",
  "valide_jusqu_au": "2026-12-31",
  "modeles": ["exemple-large", "exemple-small"],

  "energie": {
    "wh_par_ktoken_genere": 1.8,
    "wh_par_ktoken_lu": 0.15,
    "wh_par_ktoken_relu": 0.04,        // relu depuis votre cache de préfixe
    "lu_inclut_le_cache": false,
    "par_contexte": [                  // le coût de sortie croît avec le contexte
      { "contexte_ktokens": 8, "wh_par_ktoken_genere": 1.8 },
      { "contexte_ktokens": 128, "wh_par_ktoken_genere": 3.1 }
    ],
    "mesure_au": "compteur-du-site",   // gpu | serveur | baie | compteur-du-site
    "pue_inclus": true,
    "periode_reference": "2026-T2",    // quand le chiffre a été pris
    "methode": "https://exemple.ai/impact/methode"
  },

  "site": {
    "pue": 1.24,
    "pue_periode": "2026-T2",
    "zone_electrique": "FR",
    "zones": [                         // si le calcul est réparti
      { "zone": "FR", "part": 0.7 },
      { "zone": "SE", "part": 0.3 }
    ],
    "region_service": "fr-par",        // contexte ; le calcul prend la zone
    "part_production_sur_site": 0      // électricité produite hors réseau
  },

  "materiel": {
    "gpu": "H100 SXM",
    "lot_moyen": 24,
    "tokens_par_seconde": 5200,        // débit d'un serveur complet
    "occupation_service": 0.62,        // part du temps où il sert
    "duree_de_vie_h": 43800,
    "incorpore_kgco2e": 3800
  },

  "entrainement": { "localisation": 0.12, "marche": 0.03 },   // ligne à part
  "emissions_declarees": {                                     // recoupement
    "entree": { "localisation": 0.006, "marche": 0.001 },
    "sortie": { "localisation": 0.07, "marche": 0.01 }
  },

  "preuve": "mesure-au-compteur",      // mesure-au-compteur | modelise | affirme
  "assurance": "Organisme exemple",

  "market_based": { "gco2e_par_kwh": 0, "instrument": "garanties d'origine" }
}

Les choix qui méritent une ligne

wh_par_ktoken_genere et wh_par_ktoken_lu séparés. Vous le voyez mieux que nous sur vos propres charges agentiques : sur une session de codage réelle observée en août, trente mille tokens en entrée pour huit cent trente-trois en sortie. Un chiffre unique rapporté à la génération rate le terme dominant. Si vos mesures ne distinguent pas les deux phases, dites-le — c'est une information en soi. Un chiffre mixte, entrée et sortie confondues, est admis dans wh_par_ktoken_mixte avec la part de sortie de votre charge (part_sortie) : nous l'affichons, nous ne pouvons pas calculer avec, puisqu'une moyenne de deux tarifs ne donne ni l'un ni l'autre.

wh_par_ktoken_relu, le champ qui manquait le plus. Sur seize cents réponses d'un agent mesurées en continu, la quasi-totalité des tokens d'entrée sont relus depuis le cache du fournisseur. Le tarif d'une lecture fraîche ne s'applique donc presque jamais, et la première version de ce format ne demandait que lui. Si vous ne pouvez en publier qu'un des deux, publiez celui-là. Si votre chiffre est une moyenne sur votre charge réelle, dites-le avec lu_inclut_le_cache : une moyenne est utilisable, une moyenne prise pour un tarif unitaire ne l'est pas.

par_contexte. Notre modèle facture un token de sortie au même prix, que le contexte pèse mille tokens ou cent mille. C'est faux, et le cache de préfixe n'y change rien — il évite le préremplissage, pas l'attention sur ce qui précède. Deux ou trois points suffisent à nous donner une pente.

tokens_par_seconde et occupation_service ne sont pas du contexte de lecture : ils entrent dans le calcul depuis que la fabrication du serveur est comptée. L'amortissement est incorporé ÷ (durée de vie × occupation × débit), et le débit décide du résultat à un facteur vingt près. occupation_service est la part du temps où le serveur sert, pas le taux d'occupation d'un GPU pendant qu'il sert — c'est l'ambiguïté qui a fait disparaître taux_occupation. Si vous ne voulez publier ni l'un ni l'autre, incorpore_kgco2e_par_mtoken_genere porte la fabrication déjà amortie — par token généré, la base de notre calcul.

mesure_au décide de ce que le chiffre contient. pue_inclus évite qu'on l'applique deux fois.

zone_electrique est celle du calcul, et zones la remplace quand il est réparti. Pour un fournisseur européen ce n'est pas un raffinement : notre barème donne 41 gCO₂e/kWh à la France et 210 à la moyenne de l'Union. Déclarer une zone unique quand le calcul est réparti se paie d'un facteur cinq, dans un sens ou dans l'autre — et ni l'un ni l'autre n'est votre chiffre.

valide_jusqu_au — passée cette date nous revenons à notre estimation et l'indiquons. Sans échéance, une déclaration devient permanente. Elle est ramenée à deux trimestres au plus après la fin de periode_reference : une énergie par token vieillit avec la flotte et le logiciel qui la sert.

familles porte plusieurs familles de modèles dans un seul fichier, chacune avec ses propres blocs ; ce qu'une famille ne redéfinit pas lui vient de la racine.

part_production_sur_site, avec combustible_sur_site : l'électricité produite sur place, hors réseau, que notre barème de zone ne voit pas. Affichée à côté du chiffre, pas convertie.

preuve : mesure-au-compteur (relevé sur matériel réel, méthode publiée), modelise (calculé depuis les specs et la charge), affirme (chiffre sans méthode). Aucun n'est disqualifiant, mais la valeur s'affiche à côté du chiffre. Ce qui ne porte pas sa méthode ne peut être contredit par personne, donc n'informe pas — c'est une propriété du format, pas un jugement sur qui le remplit.

Un seul fichier pour deux cadres

Les champs que le cadre de comptabilité de l'IA publié par Watershed en juillet 2026 demande aux fournisseurs ont leur place dans ce même fichier : un lecteur cw2 ignore ce qu'il ne connaît pas. La correspondance est dans la spécification complète ; c'est une correspondance, pas une compatibilité revendiquée.

Le circuit

vous publiez  →  notre agrégateur lit et valide  →  registre  →  postes

Les postes installés n'appellent jamais votre domaine pour ça. Sinon chacun vous exposerait son IP en révélant qu'il fait tourner CarboneWatch — la fuite que le produit existe pour éviter. Notre agrégateur lit une fois pour tous ; le registre est distribué avec l'application et se met à jour tout seul.

Corollaire : rien de ce que vous publiez ne transite par vos utilisateurs, et nous ne demandons aucun accès privilégié — le fichier est public, lisible par n'importe quel autre outil. Nous préférerions d'ailleurs qu'il le soit.

L'agrégateur n'existe pas encore, mais le registre porte déjà les cases : un rendement de centre par fournisseur, une répartition pondérée entre zones, et la provenance de chaque valeur — publiée, mesurée, estimée. Elles ne sont plus toutes vides : depuis le 20 septembre 2026, Scaleway et OVHcloud y portent le rendement de centre qu'ils publient ; les autres fournisseurs restent à l'hypothèse globale. Une déclaration reçue peut donc être saisie et affichée sans attendre le circuit complet.

Variante DNS

_ai-impact.api.exemple.ai  TXT  "v=cw2; url=https://api.exemple.ai/.well-known/ai-impact.json"

Utile comme pointeur — nous résolvons déjà les domaines du registre toutes les cinq minutes. Pas comme porteur : 255 caractères ne documentent pas une méthode.

Affichage

Votre déclaration et notre estimation, côte à côte, avec l'écart et la provenance de chacune. Nous ne remplaçons pas la seconde par la première.

Si vous déclarez le tiers de ce que nous estimons, c'est cet écart qui est intéressant : soit notre modèle est faux, soit la déclaration l'est, et les deux sont vérifiables. Vous ne demandez pas qu'on vous croie.

Ce que nous savons mal

Par réciprocité. Notre méthodologie publique porte ces limites :

• Octets vers tokens. Faute de source publiée, nous avons mesuré — et d'un serveur local à une API de recherche qui répète ses résultats à chaque fragment SSE, le rapport change de deux ordres de grandeur, le trafic réel d'un agent de codage donnant encore autre chose. Il n'existe pas de constante — d'où le champ bytesPerToken par service dans notre registre. C'est notre plus grosse incertitude, et elle repose sur quatre points de mesure, dont un seul sur du trafic réel.
• Le contexte envoyé n'est compté que mesuré. Depuis la 0.2.10, les octets émis sont facturés comme tokens lus pour les services dont le rapport octets/token a été mesuré sur trafic réel — un seul à ce jour —, avec un modèle de cache explicite : la quasi-totalité des tokens lus d'un agent sont relus depuis le cache du fournisseur. Le coût d'un token lu et celui d'un token relu sont deux hypothèses sans mesure chez vous — d'où la question 2 ci-dessous, qui est celle à laquelle nous tenons le plus.
• Le coût du contexte en décodage n'est pas modélisé. Un token de sortie est facturé au même prix quel que soit ce qu'il faut relire pour le produire. Trois sources disent que c'est faux ; aucune ne le mesure à l'échelle d'un contexte agentique. La lacune est nommée dans notre dossier et exclue de l'intervalle que nous affichons, faute de borne.
• La fabrication du matériel est comptée depuis peu, et mal. Un serveur 8 × H100 emporte plusieurs tonnes de CO₂e avant son premier token ; amorti par token, le terme varie d'un facteur vingt selon un débit de serveur que personne ne publie. C'est une hypothèse en relecture, pas une mesure.
• La détection porte sur des adresses, avec les faux positifs que ça implique — un service servi derrière un CDN mutualisé nous a déjà fait compter une visioconférence.
• Le modèle est multiplicatif, donc les incertitudes se composent au lieu de s'additionner. Sur un échange de référence, le coin extrême des trois paramètres principaux couvre un facteur deux cents. Et rien ne borne la sous-estimation, là où trois garde-fous bornent la surestimation : nos chiffres sont structurellement des planchers.

Deux lacunes que cette page annonçait encore ont été comblées en 0.2.7, le 27 août 2026 : le barème d'intensité carbone a désormais une source datée (Ember 2025 via Our World in Data, périmètre cycle de vie, comptabilité production), et le rendement du centre de données est compté — un facteur fixé par la méthode, le même sur toutes les installations, pris dans le haut des fourchettes publiées, jamais appliqué aux modèles locaux.

Depuis, chaque facteur porte ses bornes et leur provenance, et l'application affiche une fourchette sous chaque chiffre : un intervalle de sensibilité, pas de confiance. Il ne dit pas où est le vrai, il dit ce qu'on sait des paramètres.

Questions

1. Déclaration par modèle, par famille, ou par couple modèle-configuration ? familles permet désormais d'en porter plusieurs dans un seul fichier. Par modèle est plus juste et vieillit plus vite. Mais la question change pour qui héberge des modèles qu'il n'a pas entraînés : le même modèle ouvert servi par deux exploitants sur deux générations de matériel n'a pas la même énergie par token, et ce format suppose aujourd'hui que le fournisseur est l'auteur du modèle. C'est une faiblesse — et, pour un hébergeur efficace, la comparaison qu'il aurait le plus intérêt à rendre lisible.
2. Où tombez-vous dans notre intervalle ? Nous ne demandons plus « mesurez-vous le rapport entre préremplissage et décodage » : nous l'avons encadré : un intervalle pour le coût d'un token lu rapporté à un token généré, réajusté depuis les données brutes de sept modèles, un autre pour la relecture en cache, deux architectures à quelques milliers de tokens de préfixe — les bornes sont dans la spécification remise sur demande, et nous retenons une valeur dans chacun. Un seul point mesuré chez vous, à votre échelle de contexte, vaut mieux que cet encadrement entier. Les travaux publiés l'approchent sans le mesurer sur du matériel de production, et aucun n'atteint l'échelle d'un contexte agentique, de l'ordre de la centaine de milliers de tokens par pas. La question reste entière.
3. Le taux de regroupement varie avec la charge — moyenne, distribution, ou valeur par tranche horaire ?
4. Signature détachée : utile pour vous, ou le TLS du domaine suffit-il ?
5. Empreinte incorporée du matériel. Cette question disait, jusqu'au 10 septembre 2026, que nous ne la comptions pas. Nous la comptons désormais, et le paramètre qui décide du résultat est le débit d'un serveur, encadré faute de source — avec un facteur vingt entre ses bornes. Avec l'occupation de service, ce sont les deux nombres qu'un exploitant de ses propres machines a en supervision et que personne ne publie. C'est, de toute cette page, la demande la plus utile.
   
   Ce que ça change pour un fournisseur au réseau propre : sur le mix américain, la fabrication pèse de l'ordre du pour cent de la phase d'usage ; sur le mix français, elle en atteint la dizaine de pour cent. Plus votre électricité est décarbonée, plus la fabrication devient le terme qui décide. Votre avantage sur l'usage reste d'un facteur neuf ; ce qui change, c'est que ce terme-là cesse d'être négligeable chez vous alors qu'il l'est ailleurs.

Les valeurs de chacun de ces paramètres, leurs intervalles et les protocoles qui les ont produites sont dans la spécification complète, remise sur demande — c'est la contrepartie de ce que ce document vous demande de publier.

CarboneWatch — Clément Tournier, Agence NuCom. Proposition de travail, versionnée — cw2 — : toute évolution du format changera ce numéro. cw2 a remplacé cw1 le 24 septembre 2026 en ajoutant des champs facultatifs, sans en retirer ni en redéfinir aucun : un fichier cw1 reste lu.