L'impact énergétique d'une génération
Un chiffre réel, une méthode publiée, et l'honnêteté de dire ce qu'on ne sait pas mesurer.
Ce qu'on peut affirmer avec certitude
Chaque génération Blueprint Maker consomme un nombre de tokens IA borné et connu à l'avance — c'est d'ailleurs pour cette raison que le coût en crédits est publié avant de lancer une génération, plutôt que découvert après usage.
- Sketch : 5 500 à 8 500 tokens (modèle Claude Haiku) pour concevoir la spécification.
- Craft et Masterpiece : 6 000 à 8 500 tokens (modèle Claude Sonnet) pour concevoir la spécification.
- Le socle de l'application — schéma de base de données, routes d'API, formulaires, navigation, structure des pages — est ensuite produit par des builders déterministes : des programmes, pas un modèle de langage.
- Certains blocs d'écran sont, eux, écrits par un modèle : le tableau de bord, les zones de synthèse des listes, les données d'exemple, et les vues signature au niveau Masterpiece. Ces passes consomment des tokens supplémentaires. Le nombre d'appels est borné à l'avance et les reprises sont plafonnées — ce n'est pas une boucle de correction ouverte — et chaque bloc doit passer la compilation et la validation à l'exécution, sans quoi il est remplacé par sa version déterministe.
Ce que ça représente en énergie : une estimation, pas une mesure
La littérature académique publiée sur le coût énergétique de l'inférence des grands modèles de langage situe ce coût entre 0,0001 et 0,002 Wh par token de sortie, selon la taille du modèle : une fourchette large, faute de chiffres publics par modèle chez les fournisseurs (Anthropic ne publie pas ces données pour Claude, comme la plupart des laboratoires).
Appliquée aux volumes ci-dessus, l'étape de spécification se situe dans une fourchette de 0,55 Wh à 17 Wh. À titre de comparaison, la même littérature situe la consommation d'une requête unique à un grand modèle de langage entre 0,3 et 1 Wh.
Les passes d'écriture d'écrans qui suivent ajoutent des tokens que nous ne mesurons pas encore génération par génération. Nous ne publions donc pas de total, pour exactement la raison exposée à la section suivante : un total obtenu en additionnant une mesure et une supposition reste une supposition.
Pourquoi on ne publie pas de chiffre CO2 ou eau
Convertir cette énergie en émissions de CO2 ou en consommation d'eau exige de connaître l'intensité carbone du réseau électrique et l'efficacité (PUE pour l'énergie, WUE pour l'eau) du datacenter qui exécute réellement l'inférence : des données qu'Anthropic ne publie pas publiquement par région.
Tout chiffre qu'on afficherait serait une supposition maquillée en fait. On préfère ne rien publier plutôt que d'inventer une précision qu'on n'a pas. La méthode de conversion existe et est documentée dans les sources citées plus bas, pour qui veut la refaire avec ses propres hypothèses d'infrastructure.
Ce qui change structurellement la donne, ailleurs
La consommation devient difficile à borner dès qu'un modèle de langage écrit le code lui-même et doit se corriger après coup : des cas documentés publiquement rapportent plus de 20 millions de tokens consommés pour corriger un seul bug d'authentification chez un générateur concurrent, et jusqu'à la moitié des tokens dépensés en boucles de correction plutôt qu'en construction.
Ce n'est pas une comparaison chiffrée : nous n'avons pas de visibilité sur leur consommation moyenne réelle, et nous ne prétendons pas en avoir. C'est un contraste structurel, et il ne tient pas au fait qu'aucun modèle n'écrirait de code chez nous — on vient de dire le contraire. Il tient à ce qui borne la dépense : le socle est produit par des programmes, les passes de modèle portent sur des blocs délimités, leur nombre d'appels est fixé et leurs reprises sont plafonnées. Une architecture où le modèle écrit l'application entière et se relit lui-même peut, par nature, boucler sur ses propres erreurs ; une architecture où chaque passe a un plafond et un compilateur pour juge ne le peut pas.
Sources et méthode
- LLM Inference: Energy, Water & Carbon Footprint : emergentmind.com/papers/2505.09598
- Quantifying the Energy Consumption and Carbon Emissions of LLM Inference via Simulations : arxiv.org/pdf/2507.11417
- From Prompts to Power: Measuring the Energy Footprint of LLM Inference : arxiv.org/html/2511.05597
- Making AI Less « Thirsty »: Uncovering and Addressing the Secret Water Footprint of AI Models : arxiv.org/pdf/2304.03271
- LLMCO2: Advancing Accurate Carbon Footprint Prediction for LLM Inferences : arxiv.org/pdf/2410.02950