Reasoning models en 2026 : pourquoi extended thinking explose votre budget carbone LLM (et comment le voir venir)

En 2024, un prompt Claude 3.5 Sonnet de 500 tokens d'output coûtait grosso modo 0,2 gCO₂e. En 2026, demander la même question à Claude Opus 4.7 en mode extended thinking ou à OpenAI o3 / DeepSeek R1 peut multiplier l'output (et l'énergie) par 5 à 50. Pour un RSE qui pose son budget carbone IA en début d'année, ce changement architectural est invisible dans la facturation token classique — mais il explose dans la consommation réelle. Voici ce qui se passe et comment le tracer.

Test-time compute : pourquoi les modèles « pensent »

Depuis OpenAI o1 (septembre 2024), une nouvelle famille de modèles apparaît : les reasoning models. Au lieu de répondre directement, ils génèrent en interne une longue chaîne de tokens « de raisonnement » non visible pour l'utilisateur. Le coût compute est proportionnel à la longueur totale de cette chaîne — qui peut atteindre 50 000 à 200 000 tokens pour une question complexe (math, code, recherche).

Anthropic a intégré cette logique en 2025 sous le label extended thinking(Claude Sonnet/Opus). Google l'a déployée dans Gemini 2.5 « Deep Research ». DeepSeek a publié R1 en open-weights début 2025 avec une chaîne de raisonnement explicite. xAI Grok 4 va dans la même direction. Tous ces modèles partagent une caractéristique : l'output token count n'est plus prédictible par l'utilisateur.

Le multiplicateur réel : combien d'énergie pour une question

Reprenons les chiffres connus. Une requête médiane GPT-4o : 0,3 Wh, 0,13 gCO₂e (kanoppi.co et Jegham et al. 2025). Une session Claude Code intensive avec extended thinking allumé :

• Output tokens visibles : ~500-2 000 par tour.
• Reasoning tokens cachés : 5 000-50 000 par tour difficile. Ces tokens sont facturés (Anthropic ajoute une ligne thinking_tokensdans l'usage response) mais souvent invisibles dans la lecture humaine.
• Total énergie: 5 à 30× plus que l'équivalent sans extended thinking. Pour un développeur qui code 8h avec Claude Code, 100-150 Wh/jour de consommation imputable au modèle, soit l'équivalent de plusieurs charges de smartphone.

À l'échelle d'une équipe engineering de 30 personnes utilisant Claude Code en production : environ 100 kWh/mois imputables au LLM en pic, soit 25-50 kgCO₂e/mois sur un grid US moyen. Pas catastrophique en absolu, mais à comparer aux 5-10 kgCO₂e/mois d'une utilisation Sonnet sans extended thinking. Le facteur 5 est réel et invisible si vous ne tracez pas.

Pourquoi votre dashboard Anthropic ne suffit pas

L'Anthropic Console et la commande /cost dans Claude Code retournent un coût $ par session. Trois limites pour le pilotage carbone :

• aucune conversion en énergie ou CO₂e ;
• agrégation par utilisateur uniquement (pas par projet, business unit, ou tenant client) ;
• pas de breakdown extended thinking vs réponse directe — ce qui empêche de mesurer le coût marginal du mode raisonnement.

C'est pour ça que des projets open source comme claude-carbon ou ccusage ont émergé. Mais ils restent per-developer, en SQLite local. Pour une équipe ou une organisation, il faut un canal d'agrégation et une attribution multi-tenant — c'est ce que fait notre intégration Claude Code Carbon via MCP et l' API /api/v1/track.

Trois gardes-fous pratiques pour 2026

1. Distinguer reasoning_tokens dans le tracking

L'Anthropic API retourne le breakdown dans le champ usage. Notre endpoint /api/v1/track accepte un champ optionnel reasoning_tokensqui est ajouté aux completion tokens pour le calcul carbone. Le dashboard montre alors clairement la part « raisonnement caché » dans l'empreinte totale.

2. Mettre un budget thinking par projet

Anthropic permet de limiter le max_thinking_tokenspar appel. C'est l'équivalent compute du quota. Posez par défaut 4 000 ou 8 000 tokens et exigez une justification produit pour passer au-dessus. Vous éliminez en moyenne 60 % des appels « budget illimité » qui finissent par dérouler 50k tokens pour 2 lignes de code de sortie.

3. Router intelligemment Haiku vs Sonnet vs Opus

Le pattern « tout sur Opus » est commun et coûteux. Le pattern frugal AI (voir notre comparatif de modèles) consiste à utiliser Haiku par défaut, basculer sur Sonnet pour les tâches non triviales, et n'activer Opus + extended thinking que sur les ~5 % de tâches qui en bénéficient réellement. Économies typiques : facteur 3-8 sur le coût et l'énergie.

Effet d'échelle : pourquoi le CFO va finir par regarder ça

Côté euros, le passage à Opus extended thinking sur une équipe de 30 dev fait passer la facture Anthropic de ~3-5 k$/mois à ~25-40 k$/mois. Ce saut est invisible jusqu'à ce que la facture arrive. Côté carbone, c'est exactement la même courbe : un facteur 5-8 d'émissions imputables. Le suivi financier et le suivi carbone partagent désormais la même métrique sous-jacente : tokens consommés × coefficient unitaire. Une seule infrastructure de mesure suffit à les couvrir.

Pour les équipes RSE, c'est l'occasion de transformer un sujet purement compliance en levier FinOps + GreenOps mesurable. Tous les KPIs que vous projetez pour la ligne LLMdu rapport ESRS E1 s'exportent vers le CFO comme indicateurs de gouvernance des coûts AI.

Et l'article 55 AI Act dans tout ça

L'article 55 demande aux fournisseurs GPAI à risque systémique de déclarer leur consommation d'énergie de training. Mais le considérant 116 et l'Annexe XI mentionnent aussi l'importance d'une efficacité d'inférencedocumentée. À mesure que les modèles avec test-time compute deviennent dominants, on peut s'attendre à ce que la Commission ou l'EFRAG demande, dans une révision, une déclaration explicite du ratio reasoning_tokens / output_tokensdans les rapports vendeur. Anticipez : trackez la décomposition dès aujourd'hui, vous serez prêt.