Proposition, version cw2. Format ouvert, à discuter. Ce document s'adresse aux fournisseurs de services d'IA : il décrit ce que CarboneWatch leur demande de publier pour que son estimation cède la place à leur déclaration, et ce qu'il en fait.
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.
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.
{
"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" }
}
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.
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.
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.
_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.
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.
Par réciprocité. Notre méthodologie publique porte ces limites :
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.
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.