Une requête d'IA, deux estimations de consommation d'eau radicalement différentes
En 2023, un article de recherche largement cité a dressé un bilan hydrique frappant de l'IA conversationnelle.
Selon les chercheurs, une bouteille de 500 ml pourrait correspondre à environ 10 à 50 réponses de longueur moyenne générées par GPT-3, selon le lieu et le moment où le modèle a été exécuté.
Deux ans plus tard, une étude publiée par Google a abouti à un chiffre radicalement différent. La requête textuelle médiane envoyée au service Gemini Apps en mai 2025 a consommé environ 0,26 ml d'eau, soit à peu près cinq gouttes.
Une bouteille pour quelques dizaines de réponses. Cinq gouttes pour une requête.
Ces chiffres diffèrent de plusieurs ordres de grandeur. Dans le débat public, ils sont souvent présentés comme si l'un devait nécessairement infirmer l'autre.
Pourtant, ils ne mesurent pas la même chose.
L' estimation pour GPT-3 a été élaborée à partir d'informations publiques et d'hypothèses modélisées concernant la consommation d'énergie, le refroidissement des centres de données, la production d'électricité, l'emplacement et la période. Elle incluait l'eau consommée directement au sein du centre de données ainsi que l'eau liée à la production de son électricité.
Le chiffre pour Gemini provient de la télémétrie de production interne de Google. Il couvre une génération différente de modèles, de matériel, de logiciels et d'infrastructures de service, puis applique l'efficacité de l'utilisation de l'eau (WUE) à l'échelle du parc de Google pour estimer l'eau douce consommée pour le refroidissement des centres de données. Il n'inclut pas l'empreinte hydrique liée à la production d'électricité ou à la fabrication du matériel. Bien que cet article constitue une preuve de première main précieuse, les données opérationnelles sous-jacentes sont contrôlées par l'entreprise et ne peuvent être reproduites indépendamment dans leur intégralité.
L'écart entre ces deux estimations ne relève pas d'un simple désaccord arithmétique.
Il révèle un problème plus profond concernant l'une des questions les plus courantes sur l'infrastructure de l'IA :
Quelle quantité d'eau consomme une requête IA ?
Une requête est ce qu'une personne voit sur un écran.
Ce n'est pas une unité de calcul stable.
Le terme « requête » occulte la majeure partie du travail effectué.
Demander à un modèle linguistique de corriger une phrase ou de procéder à l'analyse d'un long document juridique constitue, dans les deux cas, une requête (prompt).
Ces deux opérations ne nécessitent pas la même puissance de calcul.
Le modèle peut traiter quelques mots ou des dizaines de milliers de jetons. Il peut générer une seule phrase ou plusieurs pages. Il peut répondre directement, effectuer des recherches dans des documents téléchargés, solliciter des outils externes, créer une image ou consacrer des ressources de calcul supplémentaires à un raisonnement en plusieurs étapes.
Le modèle utilisé derrière l'interface joue également un rôle déterminant.
Un petit modèle conçu pour des tâches de classification routinières ne se comporte pas comme un modèle généraliste de grande taille. Un modèle qui n'active qu'une partie de son architecture pour chaque requête sollicitera le matériel différemment d'un modèle qui active l'intégralité de son réseau. La quantification, la mise en cache, le décodage spéculatif et d'autres techniques logicielles permettent de réduire la charge de travail nécessaire à la production d'une réponse.
Vient ensuite la question du système de production.
Les fournisseurs d'IA ne dédient généralement pas un accélérateur à la requête d'un seul utilisateur. Les demandes peuvent être regroupées par lots afin qu'un matériel coûteux serve plusieurs utilisateurs simultanément. Une utilisation optimisée permet de répartir l'énergie consommée par la machine sur un volume de travail plus important. À l'inverse, une faible utilisation, des exigences strictes en matière de latence et le maintien d'une capacité de réserve pour répondre aux pics de demande peuvent faire grimper la consommation d'énergie par requête.
Une prépublication de 2025 portant sur l'analyse comparative de 30 modèles linguistiques a estimé une différence de consommation d'énergie supérieure à 70 fois entre certains modèles pour des requêtes longues. Les chercheurs ont également constaté que la modification de la taille des lots (batch size) altérait considérablement l'énergie estimée par requête. Leur méthode reposait en partie sur le comportement des API publiques, les spécifications matérielles et des hypothèses de déploiement déduites, plutôt que sur un accès direct à la télémétrie des fournisseurs ; les classements individuels ne doivent donc pas être considérés comme des mesures universelles. L'étude démontre néanmoins à quel point le choix du modèle, la longueur de la réponse et la configuration du service peuvent faire varier le résultat. Sa méthodologie et ses résultats sont disponibles ici.
Le propre rapport de Google révèle le même problème au sein d'un système de production.
Un calcul restreint, basé principalement sur l'énergie des accélérateurs actifs, a abouti à une estimation de 0,10 Wh pour une requête médiane sur Gemini. Une fois que les chercheurs ont inclus les processeurs hôtes, la mémoire, les machines maintenues en veille pour assurer la disponibilité et les frais généraux du centre de données, ce chiffre est passé à 0,24 Wh.
Le modèle et la requête n'avaient pourtant pas changé.
C'est le périmètre de mesure qui a évolué.
Un périmètre plus complet a fait apparaître la même requête comme étant 2,4 fois plus énergivore. Comme l'estimation de la consommation d'eau découlait en partie de ce chiffre énergétique, le résultat concernant l'eau a varié en conséquence.
C'est pourquoi tout chiffre exprimé par requête doit toujours être accompagné d'une description de la requête, du modèle, du matériel, du taux d'utilisation et de la méthode employée.
Sans ces précisions, l'unité de mesure semble bien plus concrète qu'elle ne l'est en réalité.
L'eau ne provient pas d'une source unique
La seconde source de confusion réside dans le terme « eau ».
L'infrastructure d'IA peut être associée à la consommation d'eau à plusieurs niveaux différents, et une étude peut en prendre en compte un, deux, ou la totalité.
L'utilisation la plus visible est celle de l'eau directement au sein du centre de données.
Les équipements informatiques transforment l'électricité en chaleur. Le système de refroidissement doit évacuer cette chaleur des processeurs vers l'extérieur de l'installation. Certains systèmes rejettent la chaleur par évaporation, consommant ainsi de l'eau qui doit être remplacée. D'autres font circuler un liquide en circuit fermé ou rejettent la chaleur dans l'air extérieur, nécessitant peu d'apport continu en eau douce sur le site.
Notre article sur le fonctionnement des systèmes de refroidissement des centres de données suit ce chemin thermique, du processeur jusqu'au système final d'évacuation de la chaleur. La distinction entre la circulation et la consommation d'eau est examinée séparément dans notre guide sur le refroidissement en circuit fermé des centres de données.
L'IA complexifie le problème du refroidissement car elle peut concentrer davantage de puissance électrique dans chaque baie. Les recommandations actuelles de l'ASHRAE préconisent un refroidissement liquide ou assisté par liquide pour les systèmes d'IA à haute densité et de calcul haute performance, tout en conservant le refroidissement par air pour les équipements qui en ont encore besoin. Une densité plus élevée modifie la manière dont la chaleur est captée et transportée, mais ne dicte pas la façon dont l'installation rejette finalement cette chaleur ni la quantité d'eau douce consommée.
L'eau intervient également en amont du centre de données.
La production d'électricité peut nécessiter le prélèvement et la consommation d'eau pour le refroidissement des centrales et d'autres processus. La quantité dépend de la technologie, de la région et du mix électrique alimentant l'installation. Un système d'IA ayant une faible consommation directe d'eau de refroidissement peut donc conserver une empreinte hydrique indirecte via son alimentation électrique.
L'estimation largement citée concernant GPT-3 incluait à la fois l'eau de refroidissement directe et cette eau liée à la production d'électricité hors site. Le chiffre des « cinq gouttes » de Google utilisait son WUE (efficacité de l'utilisation de l'eau) pour estimer la consommation directe d'eau de refroidissement, sans y ajouter l'eau utilisée pour produire l'électricité.
Cette seule différence rend les deux résultats inadaptés à une comparaison directe.
Une troisième couche apparaît avant même que les serveurs n'atteignent le centre de données.
La fabrication de semi-conducteurs nécessite de l'eau ultrapure, tandis que la production des serveurs, des équipements de refroidissement, des systèmes électriques et des bâtiments génère des besoins supplémentaires en eau et en matériaux. Les informations publiques sur cette eau « incorporée » restent beaucoup plus limitées que les données opérationnelles. Les recherches à l'origine de l'estimation pour GPT-3 identifient la fabrication du matériel comme une part importante, bien que mal mesurée, de l'empreinte hydrique de l'IA.
Ce périmètre élargi est développé dans notre article sur l'empreinte des centres de données que les indicateurs opérationnels omettent.
Ainsi, lorsqu'une estimation indique qu'une requête IA « consomme de l'eau », la première question à se poser est de savoir quel type d'utilisation de l'eau est inclus.
Refroidissement direct ?
Production d'électricité ?
Fabrication de matériel ?
Construction ?
Eau prélevée à la source ou eau consommée et non restituée ?
Notre article principal sur la consommation d'eau des centres de données explique pourquoi ces limites sont importantes au niveau des installations et des bassins versants.
L'entraînement n'est que l'événement le plus visible
Les premières discussions sur l'empreinte environnementale de l'IA se sont largement concentrées sur l'entraînement.
C'était logique. Un entraînement majeur mobilise des milliers d'accélérateurs pendant une période intensive et mesurable. Cela produit le genre de chiffre important qui peut être associé à la sortie d'un modèle.
Mais l'entraînement final ne représente qu'une partie de la création et de l'exploitation d'un système d'IA.
Les chercheurs testent des architectures de modèles, ajustent des paramètres, préparent des données, mènent des expériences infructueuses, évaluent des points de contrôle et répètent l'entraînement à différentes échelles avant que la version finale n'existe. Une grande partie de cette activité de développement est rarement incluse dans les divulgations publiques sur les modèles.
Une étude présentée à l'ICLR 2025 a mesuré le développement et l'entraînement d'une série de modèles de langage allant de 20 millions à 13 milliards de paramètres actifs. Pour ce programme spécifique, les chercheurs ont estimé une consommation totale d'eau de 2,769 millions de litres en incluant la fabrication du matériel, le développement du modèle et l'entraînement final. Le développement du modèle représentait à lui seul environ la moitié de l'impact des entraînements finaux.
Ces résultats décrivent un programme de développement de modèle plutôt qu'un ratio universel pour l'IA. Leur importance réside dans le fait qu'ils montrent à quel point une grande partie du travail peut passer inaperçue lorsque le reporting commence uniquement avec l'entraînement final. L'étude complète explique son périmètre et ses hypothèses.
Après le déploiement vient l'inférence : le travail répété consistant à générer des réponses, des classifications, des recommandations, des images ou des prédictions pour les utilisateurs.
L'entraînement peut se dérouler en une série limitée de campagnes. L'inférence, elle, a lieu à chaque utilisation du système. Un modèle peu sollicité peut ne jamais accumuler une empreinte d'inférence comparable à celle de son développement et de son entraînement. Un service faisant face à une demande énorme peut, à terme, consommer beaucoup plus d'énergie pour servir les utilisateurs qu'il n'en a dépensé pour créer le modèle.
Il n'existe pas de répartition fixe entre l'entraînement et l'inférence.
Cela dépend de la durée de vie du modèle, de son adoption, de la complexité des requêtes, de l'efficacité du matériel, du taux d'utilisation et de la fréquence à laquelle le système est mis à jour ou remplacé.
C'est une autre raison pour laquelle une seule requête ne peut pas résumer l'ensemble de l'impact environnemental. Le système concerné s'étend en amont jusqu'au développement du modèle et à la production du matériel, puis en aval sur chaque requête traitée tout au long de sa durée de vie opérationnelle.
Cinq gouttes peuvent tout de même former un grand système
Le chiffre de 0,26 ml avancé par Google semble rassurant par sa faiblesse.
Pour la médiane des requêtes textuelles Gemini mesurée en mai 2025, il s'agit peut-être d'une estimation précise dans les limites définies par Google.
Mais une médiane ne décrit pas chaque requête.
Google a choisi la médiane car la consommation d'énergie par requête était fortement asymétrique. Un groupe restreint de requêtes longues et de modèles à faible taux d'utilisation consommait proportionnellement beaucoup plus d'énergie. Une moyenne arithmétique aurait été tirée vers le haut par ces valeurs aberrantes, tandis que la médiane représentait mieux la requête type dans le mix de produits mesuré.
Cela rend ce chiffre utile pour répondre à une question :
À quoi ressemblait une requête textuelle type dans les applications Gemini au cours de cette période et dans ce système ?
Il est beaucoup moins pertinent pour calculer la consommation totale d'eau du service.
Multiplier la médiane par le nombre total de requêtes ne permet pas d'obtenir un total précis pour l'ensemble du parc lorsque la distribution est asymétrique. Ce chiffre ne peut pas non plus être transposé automatiquement à un autre modèle, fournisseur, région, système de refroidissement ou année.
C'est là que des unités apparemment infimes peuvent créer un faux sentiment de sécurité ou une alarme exagérée.
Un commentateur peut prendre une estimation élevée par requête, la multiplier par un volume mondial supposé et aboutir à un total annuel effrayant.
Un fournisseur peut publier une médiane de requête faible pour faire paraître l'infrastructure globale négligeable.
Les deux calculs peuvent utiliser des chiffres réels.
Aucun des deux ne décrit nécessairement l'ensemble du système.
Pour la communauté qui accueille un centre de données d'IA, les chiffres les plus utiles se situent à une autre échelle.
Quelle quantité d'eau le site prélèvera-t-il sur une année ?
Quelle quantité en consommera-t-il ?
Quelle est la demande prévue durant les semaines les plus chaudes ?
Quelle source alimente le site en eau ?
Comment le système de refroidissement se comporte-t-il en période de charge maximale ?
Quelle est l'empreinte hydrique liée à l'approvisionnement en électricité ?
Une estimation par requête peut aider les développeurs de modèles à suivre leur efficacité. Elle ne peut toutefois pas remplacer les rapports au niveau des installations.
Le même principe s'applique au Water Usage Effectiveness et au Power Usage Effectiveness. Ces ratios deviennent utiles lorsque leurs périmètres de mesure, leurs emplacements, leurs conditions d'exploitation et leurs périodes de référence restent transparents.
Ce qu'un chiffre fiable sur l'empreinte hydrique de l'IA devrait inclure
Une estimation sérieuse par requête commence par définir le travail effectué.
Elle identifie le modèle et sa version, le type de requête, la longueur des entrées et des sorties, la modalité, ainsi que l'utilisation éventuelle de raisonnements ou d'outils supplémentaires. Elle précise si le résultat représente une médiane, une moyenne, une référence ou une mesure issue d'une requête en production.
La description de l'infrastructure est tout aussi importante. Le type de matériel, l'énergie consommée par le système hôte, le taux d'utilisation, le traitement par lots, la capacité inutilisée, les frais généraux du centre de données et la méthode de refroidissement influencent tous le résultat.
Vient ensuite la géographie.
Une estimation de la consommation d'eau doit identifier le centre de données ou le mix énergétique régional utilisé pour le calcul, la période de référence, l'intensité de l'eau de refroidissement et l'approvisionnement électrique local. Les moyennes annuelles facilitent les comparaisons, tandis que les chiffres saisonniers et les pics peuvent être plus utiles pour comprendre la pression locale sur les ressources.
Enfin, le périmètre de la mesure de l'eau doit être clairement défini.
La consommation directe sur site ne doit pas être confondue avec l'eau liée à l'électricité ou l'eau incorporée. Le prélèvement ne doit pas être présenté comme une consommation. Un résultat portant uniquement sur le refroidissement ne doit pas être décrit comme l'empreinte hydrique totale de l'IA.
L'étude de 2025 du Lawrence Berkeley National Laboratory montre pourquoi ces détails sont cruciaux. Selon les charges de travail et les conditions d'infrastructure examinées, la consommation d'eau variait d'un facteur supérieur à 10 000. L'efficacité des serveurs arrive en tête des déterminants, suivie par l'intensité hydrique de l'électricité, le taux d'utilisation, le refroidissement, l'efficacité de l'infrastructure, le climat, les serveurs inactifs et les cycles de remplacement du matériel. Les chercheurs n'ont trouvé aucune solution miracle pour minimiser ce résultat.
Un chiffre fiable n'a pas besoin de couvrir parfaitement chaque étape.
Il doit en revanche préciser ce qui a été omis.
L'infrastructure porte l'empreinte
Pour Policloud, la question pertinente se pose bien avant de chercher à savoir combien de gouttes correspondent à une requête.
Quelle charge de travail sera exécutée ?
Quelle puissance de calcul est nécessaire ?
Quel site physique peut l'accueillir ?
Quelle architecture de refroidissement est adaptée à la densité et au climat ?
D'où provient l'électricité ?
Quelles sont les conditions d'exploitation applicables ?
Policloud développe et déploie des infrastructures de centres de données physiques et modulaires pour des sites définis. Chaque déploiement est façonné par l'énergie disponible, le réseau, la charge de travail, la propriété, la réglementation, les opérations et les conditions physiques. L'entraînement et l'inférence de l'IA peuvent constituer des charges de travail lorsque la configuration le permet, mais le terme « IA » ne définit pas une conception d'infrastructure unique ni un résultat unique en matière de consommation d'eau.
Cette approche axée sur le site rend la question de l'eau plus difficile à réduire à un slogan.
Elle rend également la réponse plus utile.
Un modèle n'arrive pas avec une quantité fixe d'eau associée à chaque requête. Son empreinte émerge du travail qu'il effectue et du système physique qui le dessert.
Le logiciel détermine le volume de calcul effectué.
Le matériel détermine l'efficacité de l'exécution de ce calcul.
Le taux d'utilisation détermine la part de travail productif qui partage l'équipement.
Le refroidissement détermine la manière dont la chaleur est évacuée de l'installation.
L'approvisionnement en électricité ajoute une dimension géographique supplémentaire.
La fabrication étend la limite au-delà des opérations.
L'utilisateur ne voit qu'une zone de saisie.
L'empreinte hydrique appartient à tout ce qui se trouve derrière.
Alors, quelle quantité d'eau consomme une requête d'IA ?
Cinq gouttes peuvent constituer une réponse défendable pour une requête médiane dans un système de production donné, selon un périmètre défini.
Une fraction de bouteille peut être une estimation modélisée défendable pour un autre système utilisant un périmètre de consommation d'eau plus large.
Aucun de ces chiffres ne s'applique à l'IA dans son ensemble.
La réponse la plus honnête consiste à décrire le modèle, la charge de travail, l'infrastructure, le lieu, le moment et la méthode de calcul utilisés.
Sans ces conditions, une requête n'a pas d'empreinte hydrique fixe.
Elle n'a qu'un chiffre marquant.
