L'empreinte physique de l'IA : électricité, eau, matériel

CONCEPTS — SOUS LA SURFACE · EMPREINTE PHYSIQUE

Sources vérifiées au 20 juillet 2026.

Deux chiffres circulent sur la consommation d'eau d'une requête à un assistant. Le premier annonce vingt-six centièmes de millilitre — cinq gouttes. Le second annonce quarante-cinq millilitres, plus de cent soixante-dix fois davantage. Les deux proviennent d'opérateurs qui ont publié leur méthode, ont été relus, et ne se trompent pas. Ils mesurent simplement deux choses différentes.

C'est tout le problème de ce sujet. L'empreinte physique de l'intelligence artificielle est saturée de nombres qui voyagent sans leur mode d'emploi : on retient la valeur, on perd le périmètre, et le débat devient une compétition d'anecdotes. Cet article prend le chemin inverse. Il ne cherche pas le chiffre définitif — il n'existe pas — mais l'ordre de grandeur honnête : ce qui est mesuré, par qui, sur quel périmètre, et ce qui reste hors du cadre. Puis il regarde ce qui, côté ingénierie, change réellement quelque chose.

Un chiffre sans périmètre ne veut rien dire

Reprenons les deux valeurs d'ouverture. Google a publié en août 2025 une mesure instrumentée en production de son assistant Gemini : la requête texte médiane consomme 0,24 Wh d'énergie et 0,26 mL d'eau. Le périmètre y est décrit explicitement : puissance active de l'accélérateur, énergie du système hôte, capacité machine inactive, surcoût énergétique du centre de données. L'eau comptée est celle consommée sur site pour refroidir. En sont exclus la fabrication du matériel, la construction du bâtiment et l'entraînement amorti.

Mistral a publié en juillet 2025 une analyse de cycle de vie de son modèle Large 2, menée avec Carbone 4 et l'ADEME, alignée sur la méthodologie Frugal AI de l'AFNOR et relue par deux cabinets d'audit environnemental. L'impact marginal d'une réponse de 400 tokens y est chiffré à 1,14 gCO₂e, 45 mL d'eau et 0,16 mg d'équivalent antimoine — hors terminal de l'utilisateur, mais en incluant la chaîne amont, matériel et infrastructure compris.

Deux mesures rigoureuses, deux modèles distincts, deux périmètres incompatibles. Les mettre en concurrence pour désigner un gagnant serait une faute de méthode. Les lire côte à côte, en revanche, enseigne l'essentiel : c'est la frontière du calcul, bien plus que la performance de la machine, qui fait varier le résultat de deux ordres de grandeur. Toute discussion sur l'empreinte de l'IA qui ne commence pas par cette frontière est une discussion sur rien.

Une précision s'impose au passage, car elle est régulièrement escamotée : la mention littérale du rapport Mistral situe ses 20,4 ktCO₂e et 281 000 m³ d'eau « à janvier 2025, après 18 mois d'usage ». La formulation ne permet pas de trancher entre entraînement seul et entraînement cumulé à dix-huit mois d'exploitation. Nous la reprenons telle quelle plutôt que d'arbitrer à la place de son auteur — c'est exactement le genre d'ambiguïté qu'une reprise pressée transforme en chiffre faux.

Le socle se paie une fois, l'inférence se paie toujours

L'empreinte d'un modèle se décompose en deux régimes. Un socle, réglé avant la première requête : fabriquer les accélérateurs, construire le site, entraîner le modèle. Puis un flux, qui recommence à chaque appel : l'inférence.

Le socle d'entraînement est documenté quand le producteur le déclare. La fiche du modèle Llama 3.1 annonce un cumul de 39,3 millions d'heures de calcul sur des accélérateurs de 700 W d'enveloppe thermique, dont 30,84 millions pour la seule variante à 405 milliards de paramètres. Les émissions associées y figurent deux fois : 11 390 tonnes d'équivalent CO₂ en comptabilité location-based, et zéro en comptabilité market-based. Ce zéro n'est pas une absence de consommation ; c'est le résultat d'un adossement contractuel à de l'électricité renouvelable. Un joule reste un joule : la méthode de comptabilité change le chiffre affiché, pas la charge appelée sur le réseau.

Le flux, lui, ne cesse jamais — et il finit par l'emporter. Un travail publié par Meta sur son infrastructure décrivait une capacité électrique dédiée à l'IA répartie selon un rapport de 10 pour l'expérimentation, 20 pour l'entraînement et 70 pour l'inférence. Le chiffre date d'avant la vague générative et ne se transpose pas tel quel à 2026, mais il illustre une structure qui, elle, tient : un modèle est entraîné une fois et servi des milliards de fois.

Le budget physique d'un modèle sur sa durée de vie. Le socle — matériel, site, entraînement — est un montant fixe, indifférent au nombre d'utilisateurs. L'inférence, elle, s'accumule requête après requête et finit par le dépasser. La date de cette bascule n'a aucune valeur universelle : elle est entièrement dictée par le volume servi, ce que les deux pentes représentées rendent visible. Les axes sont volontairement sans échelle.

La même logique vaut pour le matériel lui-même. Une étude de cycle de vie des accélérateurs conduite chez Google et publiée en février 2025 aboutit à une règle de pouce : sur une machine amortie six ans, environ 10 % de l'empreinte de vie vient de sa fabrication et environ 90 % de son exploitation, la construction du centre de données pesant moins de 5 %. Une conséquence contre-intuitive s'ensuit : plus le réseau électrique se décarbone, plus la part relative de la fabrication remonte. Les proportions ne sont pas des constantes de la nature, elles bougent avec le mix énergétique.

Un modèle s'entraîne une fois et se sert des milliards de fois. Sur la durée de vie, la question n'est pas ce qu'a coûté l'entraînement, mais combien de requêtes seront servies avant la mise au rebut du matériel.
— Principe de lecture du budget physique d'un modèle

L'eau, le refroidissement, et ce que le PUE ne dit pas

L'électricité qui entre dans un centre de données en ressort intégralement sous forme de chaleur. Il faut donc l'évacuer, et c'est là que l'eau intervient — par évaporation dans des tours de refroidissement, technique très efficace en énergie mais consommatrice en eau, ou par systèmes fermés, plus sobres en eau et plus gourmands en électricité. L'arbitrage entre les deux est réel : il n'existe pas de refroidissement gratuit, seulement un déplacement de la contrainte.

L'écart de rendement entre installations est considérable. Le panorama annuel de l'Uptime Institute pour 2025 relève un PUE moyen pondéré de 1,54 sur les installations déclarées, quasi stable depuis six ans. Les sites construits depuis 2020 tombent à 1,48, ceux de 20 MW et plus à 1,44, et les installations récentes de haute latitude atteignent 1,3 ou mieux — 15 % des répondants cette année. En regard, un opérateur de très grande échelle publie une moyenne de flotte de 1,09. Entre 1,54 et 1,09, l'électricité qui ne sert pas au calcul passe de 54 % à 9 % de celle qui y sert. Le lieu d'exécution n'est donc pas un détail contractuel : c'est un facteur physique de premier rang.

Ce que le PUE ne dit pas mérite d'être énoncé. Il ignore l'eau. Il ignore le carbone du réseau alimentant le site. Et il ignore le stress hydrique local — prélever un mètre cube dans une région bien pourvue et dans une région en tension n'a pas le même sens, alors que le ratio, lui, est identique. Un site peut afficher un excellent PUE tout en pesant lourdement sur une ressource rare.

Le paysage global, et l'effet rebond qui l'emporte

Passons à l'échelle macroscopique, où une confusion domine : celle entre les centres de données et l'IA. L'Agence internationale de l'énergie estime la consommation électrique mondiale des centres de données à environ 415 TWh en 2024, soit près de 1,5 % de l'électricité mondiale, et projette environ 945 TWh en 2030 dans son scénario de base, soit un peu moins de 3 %. Ces chiffres couvrent tous les usages numériques : stockage, web, cloud, et IA. L'agence désigne l'IA comme le premier moteur de la croissance — les serveurs accélérés progressent d'environ 30 % par an contre 9 % pour les serveurs classiques — sans jamais isoler un sous-total « IA ». Ce sous-total n'est pas sourçable aujourd'hui ; quiconque le cite l'a reconstruit.

La mise à jour publiée par l'agence le 16 avril 2026 chiffre la croissance 2025 des centres de données à 17 %, contre 3 % pour la demande électrique mondiale toutes sources confondues, et maintient une trajectoire de doublement d'ici 2030, avec un triplement pour les installations dédiées à l'IA. Le même texte relève pourtant que la consommation par tâche décline rapidement, « à un rythme sans précédent dans l'histoire de l'énergie ».

Les deux constats ne se contredisent pas : ils décrivent un effet rebond. Chaque gain d'efficacité abaisse le coût d'une requête, ce qui élargit les usages, en autorise de nouveaux — les enchaînements automatisés d'appels sont bien plus gourmands qu'une question isolée — et la demande supplémentaire absorbe le gain. C'est la nuance décisive de ce dossier : l'efficacité par requête et la consommation totale peuvent progresser dans des directions opposées, durablement. Optimiser reste utile ; croire que l'optimisation seule fera baisser le total est une erreur de raisonnement.

Les leviers qui comptent vraiment

Reste la question opérationnelle : sur quoi une équipe technique agit-elle réellement ? La hiérarchie n'est pas celle qu'on suppose, et elle commence par un levier qu'on oublie parce qu'il n'est pas technique.

Le premier est la taille du modèle. L'analyse de cycle de vie citée plus haut établit que les impacts sont approximativement proportionnels à la taille : un modèle dix fois plus grand produit des impacts d'un ordre de grandeur supérieurs pour un même volume de tokens générés. Router les tâches simples vers un petit modèle et réserver le grand aux cas qui l'exigent est, physiquement, la décision la plus lourde de conséquences — et c'est aussi ce qui rend la distillation intéressante bien au-delà de la latence.

Le deuxième est le lieu d'exécution, pour la raison développée plus haut : l'écart de PUE entre parc mondial et flotte optimisée, cumulé à l'écart d'intensité carbone entre réseaux électriques, dépasse largement ce que la plupart des optimisations logicielles rapportent. Un travail de recherche sur l'ordonnancement sensible au carbone décrit le mécanisme : les grammes de CO₂ par kilowattheure varient au fil de la journée et fortement selon la région, et décaler les charges différables vers les heures creuses en intensité produit un gain réel — pour les seuls traitements qui peuvent attendre.

Viennent ensuite les leviers d'ingénierie classiques, dont l'effet est net mais non chiffrable de façon générique. La quantization réduit la mémoire et le travail par token, au prix d'une dégradation inégale selon les tâches, qu'il faut mesurer plutôt que supposer. La mise en cache des préfixes supprime purement et simplement le recalcul d'un préambule partagé — effet nul si les requêtes n'en partagent aucun. L'augmentation de la taille de lot améliore le travail utile par accélérateur allumé, en dégradant la latence perçue. Aucun de ces trois leviers ne dispose d'une valeur de gain publiée à périmètre stable : nous n'en avancerons donc pas.

Les leviers de réduction classés par effet réel, avec la contrepartie de chacun. Deux d'entre eux sont décisifs et documentés : la taille du modèle et la région d'exécution. Les quatre autres — quantization, cache de préfixes, taille de lot, heure d'exécution — ont un effet net à modéré mais aucune valeur de gain publiée à périmètre comparable ; la figure l'indique explicitement plutôt que d'avancer un nombre inventé.

Un dernier levier échappe à qui écrit le code : l'opérateur qui sert le modèle agit sur toute la pile à la fois. La publication de Google fait état d'une réduction d'un facteur 33 sur l'énergie et 44 sur le carbone de sa requête texte médiane en douze mois. Choisir où l'on exécute pèse donc souvent plus lourd que tout ce qu'on optimise soi-même — et cette dépendance mérite d'être assumée comme telle. Sur le versant monétaire de la même équation, nous avions détaillé ce que coûte réellement un modèle en tokens et en euros ; les deux comptabilités suivent des logiques voisines mais ne se recouvrent pas.

Cette série aura passé cinq articles à ouvrir ce que l'usage courant laisse fermé : la mécanique qui fabrique une image, ce qu'un modèle simule d'un monde, ce qu'on parvient à lire dans ses activations, ce qu'il retient de ses données — et, pour finir, ce qu'il consomme en électricité, en eau et en métal. Un fil les relie : chaque fois, la question intéressante n'était pas « combien » mais « de quoi parle-t-on exactement ». C'est la même discipline qui distingue une mesure d'une impression, et un ordre de grandeur d'un slogan. Le reste du catalogue Concepts poursuit ce travail article par article, du fonctionnement interne des modèles aux systèmes qu'on bâtit autour d'eux.

Une question, un projet IA ?

Vous arbitrez entre plusieurs tailles de modèle, plusieurs régions d'exécution, ou vous devez documenter l'empreinte d'un usage interne — échangeons sur votre contexte.

Prendre contact →

Pour aller plus loin : côté pratique, nos décryptages d'outils IA précisent quels fournisseurs documentent leur infrastructure et leurs régions d'exécution ; et sur le versant technique, notre article sur la réduction de précision des modèles détaille le compromis entre allègement du calcul et perte de qualité qu'il faut mesurer avant de l'accepter.