La méthodologie

Deux estimateurs, chacun adossé à sa physique

Services distants — au volume échangé. L'énergie d'une inférence distante suit le nombre de tokens produits, dont les octets reçus sont le meilleur indice accessible sans lire le trafic. Un flux de génération arrive token par token : le débit d'octets est le débit de la réponse. Et pour un agent, elle suit aussi le nombre de tokens lus, dont les octets émis sont l'indice : un agent renvoie tout son contexte à chaque tour.

Facturer le temps de connexion, comme le faisait le prototype, surévalue lourdement : claude.ai et ChatGPT gardent des sockets HTTP/2 ouvertes en keep-alive, si bien qu'un onglet ouvert et inactif reste établi des heures. Sur un delta d'octets, il pèse zéro.

Modèles locaux — au temps d'inférence. L'énergie est ici celle de cette machine : puissance appelée × durée. Les octets, qui circulent sur la boucle locale, n'y changent rien. Le tarif retenu vient d'une mesure au capteur de la machine, en charge.

La lecture n'est comptée que là où son rapport octets par token a été mesuré sur trafic réel — un seul service à ce jour. Elle est facturée à une fraction du tarif de génération, et la part relue depuis le cache du fournisseur, qui est l'essentiel de l'entrée d'un agent, à une fraction de cette fraction. Ailleurs, les octets émis ne sont pas facturés : sans mesure, rien sur le fil ne distingue un contexte d'un fichier téléversé, et un plancher nommé vaut mieux qu'un chiffre inventé.

Trois garde-fous encadrent le volume

Plafond de débit. Un modèle ne génère pas plus vite qu'un certain débit de tokens, et les octets facturables sont plafonnés au débit que cela représente, par connexion et par échantillon. Sans quoi charger l'interface de claude.ai — plusieurs mégaoctets de scripts — coûterait plus qu'une heure de conversation. C'est une borne haute assumée, pas un tri des octets.

Plancher de bruit. En dessous d'un seuil par service et par échantillon, le trafic est du protocole : trames de keep-alive, PING TLS, renouvellements de session. Sans ce plancher, une application ouverte facturerait en permanence.

Borne horaire du média. Le plafond de débit ne convient pas à une image ou à une vidéo, qui arrivent en rafale et sont la charge utile elle-même. Ce qui distingue une génération d'un faux positif n'est pas son débit mais sa durée : au-delà de cent mégaoctets par heure et par service, les octets restent notés et cessent d'être facturés. Une visioconférence dépasse cette borne en quelques minutes ; une heure de génération intense reste largement en dessous.

Ce que fait le calcul

CarboneWatch part de ce que le système d'exploitation expose — des octets échangés avec des adresses connues, ou à défaut un temps de connexion établie — et en déduit un volume de tokens, puis une énergie, puis un carbone, avec l'intensité électrique de la zone où le service calcule et non celle de votre machine. La fabrication du serveur s'ajoute au carbone sans passer par l'électricité.

Chaque conversion repose sur un coefficient, tiré d'une source publiée ou d'une mesure faite ici sur du trafic réel, et chacun porte un intervalle. Le détail — les valeurs, les protocoles de mesure, les bornes et ce qui reste sans borne — est dans le dossier méthodologique, remis sur demande. Ce qui suit dit le périmètre, les sources et les limites : de quoi juger le chiffre, et le contredire.

L'électricité comptée est celle du fournisseur, pas la vôtre

L'énergie est convertie en CO₂e au réseau électrique de la région où le service calcule, et non à celui de l'utilisateur. L'inférence distante ne se produit pas ici : parler à un service américain depuis la France brûle du courant américain, à 384 gCO₂e/kWh et non 41.

Chaque service porte donc une région dans le registre. Une région absente ou inconnue est comptée au tarif mondial, 458 g/kWh — jamais au plus favorable. Le réseau choisi dans les réglages ne vaut que pour les modèles locaux : eux seuls consomment le courant de cette machine.

Périmètre : ce qui est compté, ce qui ne l'est pas

L'électricité de l'inférence et, depuis la 0.2.14, la fabrication du serveur d'inférence, amortie sur les tokens qu'il sert, d'après l'incorporé publié par BoaviztAPI et les durées de vie de ses propres archétypes. Ce terme est une hypothèse en relecture — le débit d'un serveur et son taux d'occupation ne sont publiés nulle part — et il ne dépend pas du pays : négligeable face au mix américain, il peut atteindre des dizaines de pour cent face au mix français. Restent exclus : l'entraînement amorti sur les requêtes, le réseau de transport, la fin de vie, et la fabrication du terminal.

Une analyse de cycle de vie complète, comme celle publiée par Mistral avec Carbone 4 et l'ADEME, ajoute typiquement 20 à 40 %. C'est ce qui explique qu'un chiffre constructeur puisse être trente fois plus élevé qu'un autre sans que le matériel y soit pour rien : ils ne mesurent pas la même chose. Ceux-ci comptent désormais une part de cette fabrication — le serveur d'inférence, pas l'entraînement ni le terminal — et ne sont donc comparables qu'à des chiffres de même périmètre, énoncé plus haut.

Le rendement du centre de données, lui, est compté. Le tarif au token est celui du calcul ; le refroidissement et les pertes d'alimentation s'y ajoutent par un facteur de rendement. C'est l'opération que pose EcoLogits, qui retient un rendement par fournisseur ; celui qui sert une requête étant inconnu depuis une machine, CarboneWatch retient le haut de la fourchette plutôt que le bas. Les modèles locaux en sont exemptés : leur consommation est déjà celle prise au mur.

Dans le bilan d'une organisation, ce chiffre relève des achats de services : scope 3, catégorie 1 du GHG Protocol, poste 4.5 du BEGES. C'est une correspondance proposée, que confirme la personne qui tient l'inventaire. Il est donné en énergie et en carbone, sur la base de localisation. Les cadres de comptabilité de l'IA d'entreprise publiés en 2026 font les mêmes choix de fond : l'électricité publiée à côté du carbone, l'entraînement tenu hors du chiffre principal.

Ce que cette estimation ne sait pas

Le rapport entre octets sur le fil et tokens produits est le paramètre le plus incertain de tout le modèle. Il ne tient pas au fournisseur mais au protocole : la trame qui encapsule chaque token pèse bien plus que le texte qu'elle porte, et la compression, quand le serveur l'accorde, divise le tout. Entre deux protocoles courants, l'écart mesuré est d'un facteur dix. Le registre rattache donc chaque service à une famille de protocole, mesurée une fois pour l'ensemble de ses membres ; une mesure propre à un service prime sur celle de sa famille, et les familles sans mesure restent à une valeur supposée, que le dossier de sensibilité nomme comme telle. Le rapport montant, lui, dépend du client et n'est mesuré que pour un seul.

Sur Windows, le système ne donne le volume échangé à aucune application sans droits administrateur. L'estimation y retombe sur le temps de connexion établie — un onglet laissé ouvert y compte comme s'il travaillait. Les chiffres y sont des bornes hautes, l'application le dit dans son interface, et l'empreinte partagée les compte à part.

Les facteurs sont les mêmes sur toutes les installations et ne se règlent pas. Ce sont des ordres de grandeur, pas des mesures — un estimateur, pas un compteur.

La détection porte sur des adresses, et plusieurs services d'IA sont servis par une infrastructure mutualisée — Cloudflare, CloudFront, Azure Front Door — dont les adresses portent aussi du trafic sans rapport. Un faux positif est donc possible. Le registre n'admet un domaine mutualisé que si son type est borné à l'heure, un service pris en défaut est retiré et son historique effacé. Une visioconférence a malgré tout été comptée comme de la génération d'images avant que le domaine en cause ne soit retiré : c'est ce faux positif qui a fait écrire la borne.

La lecture du contexte repose sur deux hypothèses sans mesure chez le fournisseur : l'énergie d'un token lu rapportée à un token généré vient d'une régression sur trois points publiés, et le coût d'un token relu depuis le cache d'une mesure sur des préfixes de quelques milliers de tokens, loin d'un contexte agentique. Rien sur le fil ne dit si un token est relu ou recalculé : la part de cache vient des comptes d'un seul poste. Selon ce dernier paramètre, le terme de lecture varie d'un facteur sept. Et pour tout service sans rapport montant mesuré — tous sauf Claude Code à ce jour —, la lecture n'est pas comptée du tout : ces usages restent sous-estimés, et c'est dit plutôt que deviné.

Ce qui n'est jamais lu

Aucun contenu n'est lu, aucune connexion n'est déchiffrée, aucun certificat n'est installé. La détection se fait par adresse et par nom de processus, jamais par nom d'hôte ni par inspection du trafic. Aucun droit administrateur, aucune extension réseau, aucun compte, aucune télémétrie — et rien ne quitte la machine tant que le partage vers le total mondial n'a pas été activé, ce qu'il n'est pas par défaut.