J'ai mesuré ce que pèsent mes articles

⚠️ Mise à jour du 25 juillet 2026 — une cinquième erreur, et pas la plus petite

Les chiffres affichés sous cet article étaient faux. Pas d'un peu : d'un facteur qui se compte en dizaines.

Le compteur que j'avais mis en place pour mesurer le coût de mes articles est resté branché sur celui-ci après sa publication. Pendant cinq jours, il a accumulé les tokens de toutes mes sessions de travail — y compris celles qui n'avaient aucun rapport — et les a additionnés ici. Au moment où je m'en suis aperçu, il affichait 424 sessions et 3,4 milliards de tokens en relecture de cache.

Pire : en réécrivant le fichier à chaque fin de session, ce même outil a fini par effacer le corps de l'article. Il ne restait qu'un en-tête de compteurs et une page blanche. Le texte a été restauré depuis une sauvegarde du 24 juillet.

Ce que j'ai corrigé. Le compteur est débranché. Les valeurs affichées ci-dessous sont désormais une estimation assumée du coût de la seule session d'écriture de cet article, calée sur une session comparable mesurée le 25 juillet — et non plus un cumul parasite. Je préfère un ordre de grandeur honnête et signalé comme tel à un chiffre précis et faux.

C'est exactement le sujet de cet article : un instrument de mesure qu'on ne vérifie pas produit des chiffres qui rassurent. Y compris quand on l'a écrit soi-même, et qu'on croyait avoir déjà trouvé les quatre erreurs.

Merci

Sur mon article consacré à l'horloge florale, plusieurs personnes m'ont fait remarquer que je critiquais l'usage de l'eau tout en utilisant l'IA — et en illustrant l'article avec une image générée. L'échange était courtois et argumenté. Il m'a fait rouvrir le capot.

J'y ai passé une journée. J'ai trouvé quatre erreurs dans mes propres calculs. Je les ai corrigées, et les chiffres affichés sous mes articles ont changé — dans le sens qui m'arrange le moins. Ils ont été multipliés par des ordres de grandeur.

Alors merci, sincèrement. Sans ces commentaires, je serais resté avec une méthode fausse et des chiffres flatteurs. Cet article n'est pas une défense : c'est ce que j'ai trouvé en regardant vraiment.

La première chose que j'ai découverte, c'est que je ne mesurais pas

J'affichais sous chaque article un nombre de tokens consommés. Je croyais que c'était une mesure.

En remontant les traces, j'ai constaté que mon outil de suivi n'avait tourné que deux fois en treize articles. Tout le reste, ce sont des estimations que j'avais saisies à la main, de mémoire, en me disant que l'ordre de grandeur devait être à peu près bon.

Il ne l'était pas. Sur les trois articles pour lesquels j'ai pu retrouver la trace complète du travail, l'écart entre ce que j'affichais et ce que ça avait réellement coûté va de cinquante à mille sept cents fois.

Ce n'est pas un détail méthodologique. C'est la différence entre publier un chiffre et publier une impression.

Ce que personne ne publie

Pour convertir des tokens en énergie, en eau et en carbone, il faut un coefficient. Et là, le problème est collectif.

Aucun fournisseur ne publie sa consommation par token, pour un modèle donné. Google publie un chiffre agrégé — 0,24 Wh et 0,26 mL pour une requête médiane sur Gemini, tous modèles confondus, entraînement exclu, eau de production électrique exclue. OpenAI annonce 0,34 Wh par requête dans un billet de blog personnel de son dirigeant, sans méthodologie. Anthropic, dont j'utilise les outils pour l'essentiel de mon travail d'analyse, ne publie rien du tout.

Une seule exception, et elle est française : Mistral a fait réaliser par le cabinet Carbone 4 une analyse de cycle de vie complète de son modèle, relue par deux cabinets indépendants et déposée à la Base Empreinte de l'ADEME. C'est aujourd'hui le seul chiffre du secteur qu'on puisse réellement discuter — et c'est aussi le seul modèle dont on peut télécharger les poids.

Le piège du périmètre

C'est la chose la plus importante que j'aie apprise, et elle invalide la moitié de ce qu'on lit sur le sujet.

Google annonce 0,26 mL d'eau par requête. Mistral annonce 45 mL pour une réponse de 400 tokens. Un facteur 170.

Ce n'est pas un désaccord scientifique. C'est un choix de frontières :

• Google ne compte que l'eau qui refroidit le datacenter. Mistral y ajoute l'eau consommée pour produire l'électricité, qui dans la plupart des mix dépasse largement la première.
• Google exclut la fabrication des serveurs ; Mistral l'inclut.
• Et ce ne sont pas les mêmes unités : une « requête médiane » (courte) chez Google, une « réponse de 400 tokens » chez Mistral, sur des modèles et des matériels différents.

Un point que je ne sais pas encore trancher : les deux chiffres portent sur l'inférence. L'entraînement du modèle, Mistral le publie à part (281 000 m³ d'eau pour Mistral Large 2). Une part de cet entraînement est-elle amortie dans le 45 mL par requête ? Le résumé public ne le dit pas, et j'ai posé la question au cabinet qui a mené l'étude. En attendant, je considère que non — ce qui fait de mon chiffre une borne encore plus basse.

Aucun des deux ne ment. Ils ne répondent simplement pas à la même question. On ne peut donc pas répondre par un chiffre — seulement par un chiffre et sa frontière.

C'est exactement le même piège ailleurs. On lit qu'un litre de bière « coûte 298 litres d'eau ». C'est exact, et c'est trompeur : 85 % de ces litres sont de l'eau verte, la pluie tombée sur l'orge, qui serait tombée de toute façon. Seuls 16 litres sont de l'eau bleue, prélevée dans les nappes et les rivières — la seule qui entre en concurrence avec l'eau du robinet ou l'arrosage d'un massif municipal.

Et encore le même piège pour l'électricité française : le refroidissement des centrales représente 45 % des prélèvements d'eau douce du pays, mais 11 % de la consommation réelle, puisque 97 % de l'eau prélevée est restituée. Confondre les deux fait varier le résultat d'un facteur trente.

Ce que je mesure, ce que j'estime

Ce que je mesure désormais vraiment : les tokens réellement traités, le poids réel des fichiers transmis à chaque lecture, le nombre de lectures, la consommation de mon serveur, mon eau, mes kilomètres.

Ce que j'estime : tout ce qui se passe chez les autres. Combien d'énergie pour mille tokens, combien d'eau par kilowattheure dans un datacenter que je ne visiterai jamais.

Le premier bloc est vérifiable. Le second est une convention, appuyée sur les meilleures grilles publiques existantes. Pour l'écriture, je retiens le périmètre le plus complet que je puisse construire à partir de données auditées : l'impact marginal d'inférence mesuré par Mistral — fabrication des serveurs de service comprise, eau amont de l'électricité comprise, l'entraînement du modèle étant donné séparément (voir plus haut). Cette transposition d'un modèle à un autre est une approximation, signalée comme telle. Je la retiens parce que c'est le chiffre le plus défavorable que je puisse construire à partir de données publiées et auditées.

Les vrais chiffres

Voilà ce que pèsent mes articles — j'applique le coefficient d'inférence de l'ACV Mistral (45 mL pour 400 tokens de sortie) à mes propres tokens de sortie :

• Cet article-ci — près de 800 litres d'eau, 20 kg de CO₂e, et le compteur tourne encore
• L'horloge florale — 155 litres, 3,9 kg
• Le chaud : canicule et écoles — 120 litres, 3,0 kg
• Facturation électronique — 41 litres, 1,0 kg

Ces chiffres couvrent toute la session de travail : la recherche, les vérifications, les allers-retours, les visuels, les corrections. Pas seulement la rédaction finale. C'est le vrai coût de production d'un fact-check, et je préfère le compter en entier.

Et là, une surprise qui m'oblige à l'honnêteté : cet article-ci, celui sur la mesure, est le plus lourd que j'aie jamais écrit. Je l'ai réécrit dix fois, j'ai lancé des recherches, j'ai corrigé mes propres erreurs en cours de route. Ce n'est pas « l'IA » qui coûte cher — c'est de s'en servir comme je viens de le faire, en tâtonnant. Le coût vient des itérations, et la preuve est sous vos yeux.

Un avertissement, parce qu'il est essentiel : ces chiffres sont une borne basse. Les coefficients Mistral sont calibrés sur une réponse courte ; mon usage, lui, brasse un contexte des centaines de fois plus long. Le coût réel est probablement 30 à 100 fois supérieur à ce que j'affiche. Je le dis, parce qu'un plancher présenté comme un total serait exactement le genre de tromperie que cet article dénonce.

Ce que ça fait à ma comparaison

Je vais être direct, parce que c'est le passage qui compte.

L'article que j'ai écrit pour critiquer l'arrosage de l'horloge florale a coûté au moins 155 litres d'eau. L'arrosage qu'il dénonce en consomme 3 000.

Au plancher, un rapport d'environ dix-neuf. Mais je viens de le dire : ce 155 litres est une borne basse, et le coût réel se compte en dizaines de fois plus. Si l'on retient cette fourchette, l'écart ne se réduit pas, il s'inverse peut-être : il est possible que mon fact-check ait coûté autant d'eau que l'arrosage qu'il critiquait, voire davantage.

Je n'en sais rien, et c'est le fond du problème. Je ne peux pas trancher, parce qu'aucune donnée publique ne me le permet — il faudrait mesurer, et personne ne mesure. Ce que je peux dire, c'est que le « c'est négligeable » que j'aurais servi sans vérifier était faux. Ceux qui m'ont écrit que l'IA avait un coût réel avaient raison, et mes propres chiffres, même incertains, leur donnent raison. Je ne vais pas faire semblant du contraire.

Et l'image de couverture, justement

C'est le reproche précis qu'on m'a fait : illustrer avec une image générée par IA. Alors j'ai voulu la chiffrer. Résultat : on ne peut pas vraiment — et c'est déjà une information.

Ce que je n'ai pas trouvé. Aucun fournisseur ne publie l'empreinte d'une image générée. Ni Google — dont vient le modèle que j'utilise, Nano Banana Pro —, qui ne donne qu'un chiffre par requête texte. Ni OpenAI pour GPT Image. Ni même l'ACV Mistral / Carbone 4 / ADEME, qui porte uniquement sur un modèle de texte : la génération d'image en est absente. Et aucune étude à comité de lecture n'a mesuré l'eau par image.

Ce que j'ai trouvé. Une seule chose solide, et c'est de l'énergie : des mesures académiques à comité de lecture (Luccioni et al., ACM FAccT 2024) situent la génération d'une image entre 1,3 et 11 Wh selon le modèle. Une couverture 2K, c'est du haut de gamme : je retiens le majorant, ~11 Wh — l'ordre de grandeur d'une charge de smartphone. La valeur réelle est probablement plus proche de 5 Wh.

Ce que je ne fais pas. Convertir ces wattheures en litres d'eau. Je pourrais poser un facteur eau/kWh et sortir un chiffre en millilitres — mais je viens de l'écrire deux fois : aucune source officielle ne publie ce facteur pour l'électricité française, c'est précisément l'angle mort que je dénonce. En inventer un ici, juste pour l'image, serait exactement l'entourloupe que cet article combat. Je m'arrête donc à l'énergie, qui est mesurée, et j'assume de ne pas avoir le chiffre eau.

Et le « jusqu'à 5 litres par image » qu'on lit partout ? Il est faux. Aucune source primaire, et cent fois au-dessus du calcul physique : il provient d'une eau d'entraînement divisée on ne sait comment, exactement comme le « 500 mL par conversation ChatGPT » déjà démonté. Je ne le reprends pas — le reprendre, ce serait faire précisément ce que cet article dénonce.

Et surtout : cette poignée de wattheures est sans commune mesure avec le texte de cet article — des millions de tokens, des kilos de CO₂e. Le reproche visait le pixel ; l'empreinte était dans les mots. Je génère l'image une fois, en un prompt, sans jamais régénérer — et c'est, de loin, le moindre de mes coûts.

Où je place le curseur

C'est un tout. On ne peut pas isoler un usage et le juger seul.

Notre foyer — deux adultes, deux enfants — consomme environ 40 m³ d'eau par an. Rapporté à la personne, ça fait 27 litres par jour, contre 148 pour la moyenne française (ce chiffre-là est par habitant). On est donc à peu près cinq fois sous la moyenne — pour partie parce qu'un foyer partage certains usages, pour partie par choix assumé : toilette quotidienne au gant et au lavabo plutôt qu'à la douche, eau de vaisselle récupérée pour arroser, compteurs relevés. Ce chiffre est d'ailleurs lui-même une correction : je croyais qu'on était à 12 m³, mais c'était un forfait de copropriété faussé par les régularisations. La vraie moyenne, sur sept ans, est de 40. Encore une estimation qui s'est révélée fausse quand je suis allé vérifier.

Je fais 5 000 km en voiture par an, contre 11 500 en moyenne. Je ne prends pas l'avion — un seul aller-retour transatlantique pèse environ 1,8 tonne de CO₂e, soit plusieurs dizaines de fois l'empreinte carbone de tous mes articles mesurés réunis.

J'héberge mon serveur chez moi, sur une machine de récupération, 40 W en continu. Pas de refroidissement à eau. Cela dit, 40 W en continu, c'est 350 kWh par an, et à travers la production de cette électricité, environ 0,6 m³ d'eau — 1,5 % de la consommation d'eau du foyer. Non, l'informatique n'est pas immatérielle.

Et pour les images : un seul prompt, jamais de régénération. C'est là que se joue l'essentiel de l'écart — pas dans le fait de générer, mais dans le fait de relancer quinze fois par confort.

Par rapport à un foyer moyen de quatre personnes, on économise ainsi chaque année de l'ordre de 175 m³ d'eau — sans commune mesure avec ce que m'ont coûté mes articles. Ce n'est pas une absolution. C'est l'ordre de grandeur dans lequel je prends ma décision : je choisis de dépenser là, parce que j'ai réduit ailleurs, et parce que je crois que ce travail de vérification citoyenne a une valeur.

D'autres feront un autre choix. C'est légitime. Je demande seulement qu'on le fasse avec des chiffres.

Ce que je change

Mesurer sert à décider. Cinq conséquences concrètes.

Moins d'allers-retours. L'écart entre cet article et les autres ne vient pas du sujet, mais de mes tâtonnements. Le levier le plus efficace, et il ne coûte rien : mieux cadrer la demande au départ, plutôt que de corriger en quinze passes. Une consigne précise dès le premier prompt économise des dizaines d'échanges.

Travailler par sous-agents. Plutôt qu'une seule longue conversation qui traîne tout son contexte à chaque tour — c'est là que le coût explose, comme je l'ai découvert — découper le travail en tâches courtes et autonomes, chacune avec juste ce qu'il lui faut. On arrête de faire relire cent fois les mêmes pages à la machine.

Chercher mieux, pas plus. Les articles qui coûtent cher sont ceux où je cherche longtemps la donnée, où je fais lire des PDF entiers à l'IA pour en extraire deux chiffres utiles. C'est un gâchis. La réponse, c'est l'open data bien indexé, les bases vectorielles, et le fait de supprimer l'inutile en amont pour ne pas noyer la machine — et moi avec — sous des documents qu'on n'aurait jamais dû ouvrir. Moins de foin autour de l'aiguille, moins de calcul pour la trouver.

Le suivi devient automatique. Plus d'estimation à la main. Ce qui n'est pas mesuré sera désormais affiché comme non mesuré — et un tableau de bord public suivra, mois après mois, l'empreinte réelle des articles mesurés.

L'IA locale. Une partie des objections qu'on m'a faites ne sont pas environnementales : elles portent sur la concentration de la puissance de calcul entre quelques entreprises. Aucune mesure d'eau ne répond à ça. La seule réponse cohérente, c'est de pouvoir s'en passer — Ollama pour exécuter un modèle en une commande, llama.cpp comme moteur, Mistral et Hugging Face pour les modèles ouverts, vLLM ou LM Studio pour servir.

C'est mon chantier en cours : faire passer en local la majorité de mes usages quotidiens. Reformulation, classement, extraction, résumé — la plupart n'ont pas besoin d'un modèle géant.

Avec un bénéfice auquel je ne m'attendais pas : en local, on peut mesurer pour de vrai. Un wattmètre sur la prise, un compteur de tokens, et l'estimation devient une mesure. Des wattheures par token, sur ma machine, vérifiables par n'importe qui. C'est la seule façon que je voie de sortir de l'extrapolation, et ce sera probablement mon prochain article.

Deux précisions honnêtes. Le local n'est pas automatiquement plus écologique : une carte graphique personnelle sous-utilisée peut être moins efficace qu'un datacenter optimisé. L'argument est celui de l'indépendance, pas celui du carbone. Et ça prend du temps : mon serveur à 40 W ne fera jamais tourner l'équivalent des modèles que j'utilise pour analyser un budget de 124 pages. Je vise la majorité de mes usages, pas la majorité de mon volume de calcul.

Ce que j'ai corrigé

Je n'affichais pas de mesures. Onze articles sur treize portaient des estimations saisies à la main, sous-évaluées d'un facteur cinquante à mille sept cents.

Les images n'étaient pas comptées. Mon calcul ne pesait que le texte, alors que les images représentent 97 % de ce qui est réellement transmis à votre navigateur — et les images de couverture n'entraient dans aucun calcul.

Les valeurs étaient figées. Le calcul n'était pas relancé quand je modifiais un article après publication.

Mon périmètre était trop étroit — mes coefficients maison ne captaient qu'une fraction du coût réel de l'inférence, loin de ceux d'une analyse de cycle de vie auditée. C'est l'erreur la plus lourde.

Les articles dont l'empreinte n'a jamais été mesurée portent désormais une mention explicite. La méthode a un numéro de version. Elle en changera encore.

Pour aller plus loin

Cet article laisse trois chantiers ouverts. Je les liste, parce qu'une méthode honnête dit aussi ce qu'elle ne sait pas encore faire.

Mesurer pour de vrai, en local. Tout ce qui touche au coût réel d'une requête à long contexte, je l'estime, faute de mesures publiées. La seule façon d'en sortir : installer un modèle ouvert sur ma propre machine, brancher un wattmètre sur la prise, et mesurer les wattheures réellement consommés pour une requête courte puis pour une requête à long contexte. Le rapport entre les deux, mesuré, remplacera mon estimation. Un modèle local n'est pas celui que j'utilise au quotidien, et il plafonne avant les contextes que je manipule — je ne mesurerai donc pas le chiffre exact, mais la forme de la courbe. C'est déjà énorme, et ce sera le sujet d'un prochain article.

Obtenir le détail de l'étude Mistral. J'ai écrit au cabinet Carbone 4, qui a mené la seule analyse de cycle de vie auditée du secteur, pour demander ce que le résumé public ne dit pas : la part du datacenter face à celle du calcul, la séparation entre entraînement et inférence, et la consommation énergétique brute. J'ai aussi créé un compte sur la Base Empreinte de l'ADEME pour y chercher les données déposées. Je publierai la réponse — ou l'absence de réponse.

Un tableau de bord public. Plutôt que de recalculer à la main à chaque fois, je mets en place un suivi qui affichera, mois après mois, l'empreinte des seuls articles réellement mesurés — eau, énergie, carbone. Vérifiable en continu, par n'importe qui.

Je ne sais pas tout

Je n'ai pas d'expertise en analyse de cycle de vie. Je lis les grilles publiques, j'essaie de comprendre les périmètres, et je me trompe. Quatre fois dans cet article, sur mes propres calculs, découvertes en l'écrivant — et à chaque fois dans le sens qui ne m'arrangeait pas.

Ce que j'essaie de faire, c'est de me construire un avis éclairé plutôt qu'une opinion, et de le partager avec les chiffres qui vont avec — pour qu'on puisse me contredire précisément, et pas seulement en principe.

Alors je suis preneur. De toute étude, de toute donnée, de toute grille d'évaluation qui me permettrait d'affiner ma représentation et mes choix. Si vous avez des sources qui contredisent celles-ci, ou une méthode meilleure, écrivez-moi : je corrigerai, et je le dirai. C'est déjà arrivé une fois. Ça a donné cet article.

Le débat vaut mieux que nos certitudes respectives.