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.
- Au-delà de cette étape, zéro token IA supplémentaire pour écrire le code : il est produit par des builders déterministes, des programmes, pas un modèle de langage.
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 à nos volumes réels de tokens, une génération Blueprint Maker 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 : une génération d'application complète reste donc de l'ordre de grandeur de quelques requêtes IA, pas de centaines.
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. Une architecture où le code est écrit par une IA peut, par nature, boucler indéfiniment sur ses propres erreurs ; une architecture où le code est compilé par un programme déterministe 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