Une requête ChatGPT consomme environ dix fois plus d'énergie qu'une recherche Google. C'est une estimation publiée par Goldman Sachs en 2024, confirmée par les mesures de l'IEA la même année. Pris isolément, c'est négligeable. Multiplié par cent millions d'utilisateurs actifs quotidiens, par des milliers de workflows automatisés dans des entreprises qui déploient des LLM sur leurs processus, c'est une tendance structurelle.
Goldman Sachs projette que l'IA générative pourrait augmenter la consommation électrique des data centers de 160% d'ici 2030. Ce chiffre agrège tout, de l'entraînement des modèles à vos requêtes quotidiennes. Et c'est précisément là que se trouve la marge de manoeuvre.
Un projet IA bien dimensionné consomme cinq à vingt fois moins qu'un projet mal dimensionné, à résultat équivalent. Ce n'est pas une promesse. C'est de l'ingénierie.
Entraînement et inférence : deux réalités très différentes
L'empreinte environnementale d'un modèle IA se répartit très inégalement entre sa création et son usage quotidien.
L'entraînement d'un modèle comme GPT-3 a consommé environ 1 287 MWh selon les estimations publiées par Patterson et al. dans Carbon Emissions and Large Neural Network Training (2021). Pour ordre de grandeur : l'équivalent de la consommation annuelle d'une centaine de foyers français. Ce coût, vous ne le portez pas directement. Il a été payé une fois par le fabricant du modèle, avant que vous l'utilisiez.
L'inférence (vos requêtes quotidiennes) est une autre histoire. Une requête standard à GPT-4 consomme entre 0,001 et 0,01 kWh selon les mesures de l'IEA (2024). Contre 0,0003 kWh pour une recherche Google. L'écart est réel. Il reste gérable, à condition de ne pas gaspiller.
Le problème n'est pas l'IA en soi. C'est la somme des mauvaises décisions de conception qui s'accumulent à chaque appel : utiliser un modèle trop puissant pour une tâche simple, envoyer trois mille tokens de contexte pour une question de cinquante mots, relancer un entraînement complet là où une approche RAG aurait suffi.
Ces décisions paraissent anodines prises séparément. Sur un million d'appels, elles deviennent une charge carbone mesurable. Et dans le bilan carbone d'une organisation, elles commencent à peser.
Les trois comportements qui concentrent l'essentiel du gaspillage
Sur-dimensionner le modèle. Appeler GPT-4, Claude Opus ou Gemini Ultra pour des tâches qu'un modèle de sept à treize milliards de paramètres résout aussi bien. Un modèle léger consomme dix à cent fois moins d'énergie par requête. La règle est simple : utiliser le modèle le moins puissant qui répond correctement à la tâche. Sur un million d'appels, choisir le bon modèle fait la différence entre une empreinte négligeable et une empreinte visible dans votre bilan carbone.
Gonfler les prompts. Un prompt de deux mille tokens consomme proportionnellement plus qu'un prompt de mille tokens. Le padding involontaire (instructions redondantes, contexte non filtré, historique de conversation non purgé) représente souvent trente à cinquante pour cent du volume de tokens envoyés. Des équipes qui ont mis en place une revue systématique de leurs prompts ont constaté des réductions de vingt-cinq à quarante pour cent du volume de tokens, sans dégrader la qualité des sorties.
Ignorer le cache. Quand le même contexte est renvoyé à chaque requête (documentation produit, règles métier, base de connaissances), l'énergie est dépensée à chaque fois pour traiter ce qui ne change pas. Les systèmes avec caching sémantique réduisent leur consommation de quarante à soixante-dix pour cent sur des workflows répétitifs, selon les mesures publiées par les équipes engineering d'Anthropic et d'OpenAI.
Cinq pratiques concrètes pour diviser l'empreinte par dix
Cartographier vos cas d'usage par niveau de complexité requis. C'est la première action, et la plus impactante. Tous les cas d'usage IA ne nécessitent pas un modèle frontier. Classifier un email entrant, détecter une anomalie dans une série temporelle, résumer un document structuré : un modèle de taille modeste, éventuellement fine-tuné sur votre domaine, fait le travail à une fraction du coût énergétique. La règle de conception : définir pour chaque type de tâche le modèle minimal suffisant, pas le modèle maximal disponible.
Réduire la taille des prompts par design. Trente pour cent de tokens en moins sur un prompt, c'est trente pour cent de consommation en moins sur chaque appel. En pratique : supprimer les instructions déjà comprises par le modèle, filtrer le contexte pour n'injecter que ce qui est pertinent à la requête, limiter l'historique de conversation aux derniers échanges utiles. Ce n'est pas une contrainte. C'est une discipline de conception qui rend les systèmes plus rapides et moins coûteux simultanément.
Choisir RAG plutôt que fine-tuning inutile. Fine-tuner un modèle consomme en moyenne cent à mille fois plus d'énergie que l'inférence standard, selon les benchmarks publiés par Hugging Face (2023). Dans quatre-vingts pour cent des cas d'usage en entreprise (questions-réponses sur documentation interne, assistance métier, recherche dans une base de connaissances), une architecture RAG bien conçue donne des résultats équivalents sans aucun réentraînement. Le fine-tuning se justifie pour des domaines très spécialisés avec des données propriétaires volumineuses. Pas avant.
Mettre en place du caching sur le contexte statique. Identifier les portions de contexte qui ne changent pas entre deux requêtes (règles métier, documentation de référence, exemples few-shot) et les mettre en cache côté infrastructure. Le prompt caching, disponible nativement sur Claude et GPT-4 Turbo, évite de retraiter des milliers de tokens à chaque appel. Sur un système de support client ou d'assistance documentaire, l'économie est immédiate et mesurable dès la mise en production.
Choisir une infrastructure bas-carbone. À performance équivalente, un modèle hébergé dans une région Azure, AWS ou GCP alimentée à quatre-vingt-dix pour cent par des énergies renouvelables émet entre trois et vingt fois moins de CO₂ qu'une région à fort mix fossile. Microsoft, Google et AWS publient leur Power Usage Effectiveness et leur mix énergétique par région. Ces données permettent un choix éclairé lors du déploiement. C'est un critère que peu d'entreprises intègrent aujourd'hui dans leurs appels d'offres IA. C'est une lacune qui se corrige facilement.
Ce que ça veut dire pour votre organisation aujourd'hui
La plupart des organisations n'ont pas encore de ligne "empreinte IA" dans leur bilan carbone. C'est normal : les outils pour la mesurer n'ont émergé qu'en 2023. Mais la réglementation avance. La CSRD, applicable depuis 2024 pour les grandes entreprises européennes, impose de publier les impacts environnementaux de l'activité. L'IA en fait partie.
Trois choses à faire maintenant, sans attendre.
Commencer par mesurer. Les APIs des principaux fournisseurs exposent le nombre de tokens consommés par requête. Un token représente environ 0,000000007 kWh pour les modèles actuels, selon les estimations d'Epoch AI (2024). C'est imparfait, mais c'est l'unité de base pour construire un tableau de bord d'empreinte IA. Imparfait et actionnable vaut mieux qu'exact et inexistant.
Former les équipes au prompt frugal. Ce n'est pas un exercice réservé aux développeurs. Un directeur commercial qui apprend à structurer ses requêtes réduit sa consommation autant qu'une refonte infrastructure. Et ça se fait en deux heures de formation.
Intégrer le critère énergétique dans vos appels d'offres IA. La région d'hébergement et le mix énergétique du datacenter doivent figurer comme critères explicites, au même titre que le RGPD ou la sécurité. C'est une question de maturité, pas d'idéologie.
La sobriété IA n'est pas une contrainte
Les organisations qui construisent aujourd'hui des pratiques d'usage sobre réduisent leur empreinte ET leurs coûts d'inférence, souvent simultanément. Le gaspillage énergétique et le gaspillage budgétaire ont exactement les mêmes causes : mauvais dimensionnement du modèle, contexte mal filtré, absence de caching.
Ce n'est pas un arbitrage entre performance et responsabilité. Ce sont les mêmes décisions, prises correctement. L'IA sobre n'est pas l'IA lente. C'est l'IA bien conçue.