Les centres de données ont un problème d'eau. Le refroidissement détermine l'ampleur de ce besoin.
Imaginez un maire dans le sud de l'Europe au mois d'août.
Les réservoirs sont au plus bas. Les agriculteurs surveillent la météo. Les habitants ont été invités à réduire leur consommation d'eau. C'est alors que quelqu'un propose l'installation d'un nouveau centre de données en périphérie de la ville.
Des questions se poseront inévitablement sur l'emploi, l'électricité, le foncier, les nuisances sonores et les recettes fiscales. Mais l'eau possède une charge politique particulière, car tout le monde comprend ce qu'implique une pénurie.
La question qui s'impose est donc la bonne : quelle quantité d'eau ce centre de données va-t-il consommer ?
La réponse, frustrante, est qu'il n'existe pas d'empreinte hydrique standard significative pour « un centre de données ».
Une étude de 2025 du Lawrence Berkeley National Laboratory a révélé que la quantité d'eau utilisée pour traiter une charge de travail informatique peut varier dans un rapport de plus de 10 000. Cette différence s'explique par l'efficacité des serveurs, leur taux d'utilisation, le système de refroidissement, le climat, l'infrastructure environnante et même l'eau nécessaire à la production de leur électricité.
Cette fourchette est suffisamment large pour rendre presque inutiles la plupart des généralités sur les centres de données et l'eau.
Elle révèle également quelque chose de plus intéressant.
Une grande partie du problème de l'eau n'est pas inhérente à l'informatique. Elle est intégrée à la conception même de l'infrastructure.
L'eau est utilisée parce que la chaleur doit bien aller quelque part.
Les serveurs n'ont pas besoin d'eau pour effectuer des calculs.
Ils ont besoin d'électricité. La difficulté réside dans ce qui se passe ensuite.
La quasi-totalité de l'énergie électrique utilisée par un processeur finit par se transformer en chaleur. Si l'on réunit des milliers de processeurs, en particulier les systèmes GPU haute densité installés pour les charges de travail liées à l'IA, l'évacuation de cette chaleur devient l'un des problèmes fondamentaux de l'exploitation de l'installation.
Une solution courante est remarquablement efficace. La chaleur est transférée des serveurs vers la salle, puis vers de l'eau glacée, circule dans un second circuit hydraulique et finit par atteindre une tour de refroidissement. Au niveau de cette tour, une partie de l'eau s'évapore et évacue la chaleur dans l'atmosphère.
Le rapport du département de l'Énergie des États-Unis sur les tours de refroidissement des centres de données décrit l'évaporation comme l'étape finale de l'évacuation de la chaleur dans ce type de système. De l'eau doit également être évacuée périodiquement pour éviter une concentration excessive de minéraux ; ainsi, de l'eau « d'appoint » fraîche remplace à la fois l'eau évaporée et l'eau évacuée. citeturn836585search7
C'est une solution d'ingénierie efficace. L'évaporation permet d'évacuer de grandes quantités de chaleur de manière performante.
Mais cette efficacité a un coût physique : une partie de l'eau est perdue.
C'est de là que viennent les titres familiers sur les centres de données « assoiffés ». Ils décrivent un problème réel, mais traitent souvent un choix de refroidissement comme s'il s'agissait d'une loi immuable de l'informatique.
Ce n'est pas le cas.
Les centres de données peuvent évacuer la chaleur de plusieurs manières. Ils peuvent utiliser davantage l'air extérieur, des refroidisseurs secs, la réfrigération mécanique, des systèmes par évaporation, des liquides caloporteurs ou une combinaison de ces méthodes. Notre analyse approfondie sur le fonctionnement des systèmes de refroidissement des centres de données suit tout le cheminement thermique, du processeur jusqu'à l'air extérieur.
Cette distinction est importante car l'eau peut jouer des rôles très différents tout au long de ce processus.
Un système peut consommer de l'eau par évaporation. Un autre peut faire circuler un liquide en boucle fermée. Un serveur refroidi par liquide peut, en fin de compte, rejeter sa chaleur vers une tour de refroidissement par évaporation. À l'inverse, un système peut utiliser un liquide en interne et rejeter sa chaleur vers l'air extérieur sans flux continu d'eau douce sur le site.
Même les étiquettes peuvent être trompeuses. « Refroidi par liquide » ne vous indique pas la quantité d'eau consommée par une installation. « Refroidi par air » ne garantit pas l'absence totale de liquide dans le système de refroidissement. Et « boucle fermée » décrit la circulation, pas l'empreinte hydrique globale.
Nous explorons cette distinction séparément dans notre guide sur le refroidissement en boucle fermée pour les centres de données.
C'est pourquoi la question initiale, « Quelle quantité d'eau un centre de données consomme-t-il ? », ne peut recevoir de réponse responsable en se basant sur une simple moyenne.
Il faut savoir comment il évacue la chaleur.
Et où.
Un bon indicateur d'efficacité peut encore masquer le véritable problème.
La question de l'eau devient plus complexe lorsqu'elle se heurte à une autre obsession du secteur des centres de données : l'efficacité énergétique.
Pendant des années, le PUE (Power Usage Effectiveness) a été l'indicateur de référence. Il compare l'électricité totale entrant dans un centre de données à celle consommée par ses équipements informatiques. Plus le résultat se rapproche de 1,0, moins l'électricité est gaspillée dans le refroidissement, la conversion de puissance, l'éclairage et les autres systèmes auxiliaires.
Il est utile car ces frais généraux ont leur importance.
Mais imaginez deux installations.
L'une obtient un PUE plus faible en partie grâce à un refroidissement par évaporation très efficace. L'autre utilise une architecture qui consomme moins d'eau sur site, mais nécessite davantage d'énergie électrique pour évacuer la chaleur lors des périodes de forte chaleur.
Laquelle est la plus efficace ?
Le PUE donne une réponse. L'eau en donne une autre.
Aucune n'est nécessairement fausse.
Le problème survient lorsqu'on laisse un seul chiffre résumer l'ensemble de la situation en matière de ressources.
Le Green Grid a introduit le WUE (Water Usage Effectiveness) spécifiquement comme complément au PUE. Plus récemment, il a développé un indicateur d'impact de la consommation d'eau qui combine la quantité d'eau consommée avec le niveau de stress hydrique de la zone où elle est utilisée.
Un litre d'eau n'a pas les mêmes conséquences partout.
Utilisez-le dans une région où l'approvisionnement est abondant et l'impact local sera peut-être minime. Utilisez-le pendant une sécheresse dans un bassin versant déjà sous tension, et ce même litre s'inscrit dans une réalité politique et physique très différente.
C'est ici que le maire revient dans l'histoire.
Une statistique à l'échelle du continent peut lui indiquer si les centres de données représentent une part importante ou négligeable de la consommation d'eau en Europe. Elle ne peut pas lui dire si une autre installation industrielle a sa place à côté de sa ville.
Cela nécessite une carte.
Cela nécessite de savoir d'où provient l'eau, quelle quantité le système de refroidissement consomme réellement, ce qui se passe durant les semaines les plus chaudes de l'année, quels autres utilisateurs dépendent de la même source, et si l'installation peut fonctionner différemment lorsque les conditions changent.
La réglementation européenne commence à refléter cette vision plus large. Une proposition de la Commission européenne pour 2026 visant à instaurer un système commun de notation de la durabilité attribuerait aux centres de données des classes distinctes de A à G pour le PUE et le WUE, plutôt que de fusionner l'énergie et l'eau en une seule mesure. La proposition utilise également l'apport en eau douce, et non simplement l'eau potable, et précise que les flux de retour des systèmes de refroidissement fermés et semi-fermés ne doivent pas être simplement ajoutés à l'apport en eau douce. Le système de notation proposé par l'UE rend cette distinction explicite.
Le langage réglementaire est aride. Ses implications ne le sont pas.
Une installation ne peut pas faire disparaître sa problématique liée à l'eau simplement en changeant sa source d'approvisionnement.
Et elle ne peut pas faire disparaître sa problématique globale de ressources en publiant un PUE impressionnant.
Nous approfondissons ce problème dans notre article sur ce que mesure le PUE et ce qu'il omet.
Dès lors que l'eau devient une question locale, le centre de données tout entier devient local.
« Le cloud » a donné à l'informatique un vocabulaire étrangement immatériel.
Les données vivent dans des régions. La capacité évolue. Les charges de travail se déplacent. L'infrastructure devient un service qui apparaît lorsqu'un utilisateur clique sur un bouton.
Le système physique sous-jacent n'a jamais été aussi abstrait.
Un centre de données occupe un terrain. Il est raccordé à un réseau électrique spécifique. La fibre doit y parvenir. L'équipement produit de la chaleur dans un climat donné. Les camions ont besoin d'un accès. Les règles d'urbanisme s'appliquent. Des gens vivent à proximité.
L'eau figure sur cette même liste.
Une fois que l'on voit les choses sous cet angle, la question intéressante n'est plus « Les centres de données consomment-ils trop d'eau ? », mais « Quels sont les besoins de cette infrastructure spécifique pour cet emplacement précis ? »
C'est une question beaucoup plus difficile à transformer en slogan.
C'est aussi une bien meilleure façon de concevoir une infrastructure.
L'IA rend la question plus urgente, car les GPU concentrent des quantités énormes de calcul et de chaleur dans un espace réduit. Mais même ici, l'équation populaire « plus d'IA = plus d'eau » omet l'étape intermédiaire décisive : la manière dont l'infrastructure est conçue pour refroidir la charge de travail.
Notre article sur la consommation d'eau des centres de données d'IA aborde ce problème directement.
Pour Policloud, cette relation entre la charge de travail et le lieu est centrale.
Policloud développe une infrastructure de centre de données physique et modulaire pour des sites définis. L'architecture de refroidissement ne peut pas être séparée de manière sensée de la charge de travail, de l'énergie disponible, du climat, du réseau, de la réglementation, du modèle opérationnel et des conditions physiques entourant le déploiement.
Cela peut sembler moins spectaculaire que de déclarer une technologie de refroidissement gagnante.
C'est plus utile.
Un site confronté à un stress hydrique doit rendre cette contrainte visible dès le départ, plutôt que de la découvrir après qu'une installation a été conçue autour d'une méthode de refroidissement gourmande en eau.
Une charge de travail GPU à haute densité doit influencer la conception thermique avant même que l'on compte combien de racks peuvent tenir à l'intérieur.
Si la chaleur récupérable a une destination pratique à proximité, cela doit également faire partie de la discussion sur le site.
C'est ce que signifie la frugalité dans l'infrastructure physique : ne pas utiliser le moins de ressources possible dans l'abstrait, mais refuser de concevoir comme si les ressources étaient illimitées et les lieux interchangeables.
Le meilleur système de refroidissement n'est donc pas celui qui affiche la mesure la plus attrayante.
C'est celui qui s'adapte à la charge de travail et au lieu sans créer une contrainte que quelqu'un d'autre devra résoudre plus tard.
C'est aussi pour cela que le débat sur l'eau dépasse le cadre de l'eau.
Il nous oblige à considérer à nouveau les centres de données comme des systèmes physiques.
En août, le maire n'a pas besoin d'une promesse selon laquelle l'infrastructure proposée est efficace, durable ou à la pointe de la technologie. Ces mots condensent trop de choix dans trop peu d'informations.
Elle a besoin de savoir ce que l'installation exigera de la localité qui l'accueille.
Quelle quantité d'énergie.
Quelle surface de terrain.
Quel type de refroidissement.
Ce qui se passe lorsque les températures augmentent.
Et quelle quantité d'eau.
Ces réponses existent.
Elles ne se cachent simplement pas derrière une moyenne sectorielle.
