Comment réduire l'impact environnemental des data centers : 7 leviers

Le chiffre qui m'a fait changer d'avis sur les data centers, ce n'est pas le PUE. C'est le compteur d'eau. J'étais assis dans une salle de réunion à Roubaix, un après-midi de novembre, en face d'un ingénieur qui gérait un petit colocation de 400 baies. On parlait refroidissement, il me sort une capture d'écran. Le relevé de la veille. Et là je vois le volume d'eau évaporé sur vingt-quatre heures pour maintenir ses allées froides à 22 °C. Je me souviens d'avoir demandé s'il s'agissait d'un mois. Non. La journée. Ce jour-là, j'ai arrêté de croire que la question du numérique responsable se réglait avec un onduleur et une ligne verte sur une plaquette commerciale.

L'impact environnemental d'un data center : trois postes qu'on regarde trop tard

Quand on parle de l'impact environnemental des data centers, la conversation part presque toujours par l'électricité. C'est logique, c'est le poste le plus visible sur une facture. C'est aussi celui qu'on sait le mieux optimiser. Le problème, c'est que la pollution d'un centre de données ne se limite pas à ce qu'il tire du réseau. Il y a trois postes qui pèsent, et qu'on découvre souvent après avoir signé le bail.

La consommation électrique : loin d'être un détail

Un serveur qui tourne consomme, évidemment. Mais ce qui m'a marqué en visitant plusieurs sites, c'est le rapport entre ce que fait la machine et ce que coûte le fait de la garder vivante. Sur un vieux rack que j'ai audité l'an dernier pour un client e-commerçant, on était sur 55 % de la puissance totale dédiée au calcul, le reste partait en alimentation, ventilation, onduleurs, pertes diverses. C'est une proportion courante sur du matériel non renouvelé. Le reste, c'est de la chaleur qu'on fabrique et qu'il faut évacuer.

La consommation d'eau : le poste aveugle

Un data center refroidi par évaporation, c'est une centrale qui consomme de l'eau potable pour fonctionner. Pas pour nettoyer, pas pour les sanitaires : pour transférer de la chaleur. Sur un site de taille moyenne que j'ai suivi sur plusieurs mois, l'eau faisait plus de la moitié de l'empreinte environnementale totale une fois comptée la charge sur la ressource locale. Et personne dans l'équipe dirigeante n'avait ce chiffre en tête avant l'audit.

Le matériel qu'on jette trop tôt

Un serveur peut tourner dix ans. Il en tourne rarement plus de cinq dans un parc bien géré, parce qu'on préfère acheter neuf plutôt que de remplacer trois disques. Les DEEE des data centers restent un flux difficile à tracer une fois sortis de la salle. J'ai une fois récupéré un lot de cartes mères sorties de production « parce qu'elles étaient lentes ». Trois ans après, elles tournaient encore dans une PME locale.

Pourquoi l'IA aggrave le problème au lieu de l'atténuer

Il y a deux ans, un responsable infrastructure m'a expliqué qu'il avait dû refaire la moitié de ses allées froides. Motif : ses clients voulaient faire tourner des modèles. Pas des petits. Des clusters GPU qui tirent chacun l'équivalent de huit à douze baies classiques en puissance crête. Sauf que le refroidissement avait été dimensionné pour l'ancien monde.

La densité énergétique casse les modèles

Un rack serveur web bien rempli, on est autour de 5 à 8 kW. Un rack GPU dédié à l'entraînement, on grimpe facilement à 40, 60, parfois plus. Vous ne refroidissez pas ça avec la même recette. L'air froid soufflé par le plancher technique ne suffit plus. Il faut passer au refroidissement liquide direct, ou à l'immersion, et budgéter l'infrastructure associée.

L'inférence coûte aussi, tous les jours

On parle beaucoup de l'entraînement, moins de l'inférence. Et pourtant, c'est là que passe la majorité du temps machine sur un service IA en production. Chaque requête utilisateur réveille un modèle, parfois plusieurs. Un service qui sert un million de requêtes par jour fait bosser des GPU en permanence, pas seulement le week-end du lancement.

Ma conviction, et je l'assume : la sobriété d'un service IA ne se décide pas au niveau de la salle, elle se décide au niveau du produit. La taille du modèle, la fréquence d'appel, la mise en cache des réponses — ça, ça pèse plus lourd que le choix d'un onduleur.

Les leviers concrets pour réduire réellement l'impact

Passons à ce qui marche. J'ai testé, raté, recommencé. Voici ce que j'en retiens, dans l'ordre d'efficacité réelle observée sur mes derniers projets.

Commencer par le logiciel, pas par la clim

Counter-intuitif. Mais le meilleur ROI que j'ai vu sur un data center ne venait pas du matériel. Il venait d'une équipe qui a supprimé 70 % de ses logs de debug en production. Ces logs représentaient, une fois agrégés, un volume de stockage et de traitement qui consommait plus que le service lui-même. Trois semaines de travail, un gain mesuré de 12 % sur la consommation électrique du cluster applicatif.

Dans la même veine :

• Purge automatique des données froides (personne ne lit un log de 2021).
• Dimensionnement honnête des modèles — un modèle de 7 milliards de paramètres suffit pour beaucoup de cas d'usage.
• Cache agressif côté API. Sur un projet, on est passé de 34 % à 78 % de hit rate en deux semaines.
• Éviter les réveils inutiles : un service qui poll toutes les 5 secondes pour rien, c'est du gaspillage pur.
• Mutualiser les environnements de test (qui souvent tournent 24h/24 pour rien).

Refroidir autrement, mais lucidement

Sur le refroidissement, les options se classent en trois familles. Voici comment je les compare après les avoir vues à l'œuvre sur des sites de tailles différentes.

Approche	Gain typique observé	Investissement	Limite principale
Free cooling (air extérieur)	20 à 40 % sur le poste froid	Faible à moyen	Dépend du climat local
Refroidissement liquide direct	30 à 50 % sur le poste froid	Élevé	Complexité d'exploitation
Immersion	40 à 60 % sur le poste froid	Très élevé	Rupture technique pour l'équipe
Circuit fermé (dry cooler)	Supprime le prélèvement d'eau	Moyen à élevé	Consomme plus d'électricité, rejette la chaleur dans l'air

Le circuit fermé revient souvent dans les discussions. Sachez ce qu'il fait vraiment : il arrête le prélèvement d'eau potable, mais il augmente la consommation électrique des ventilateurs et des pompes. On déplace le problème, on ne le supprime pas. Sur un site en zone de stress hydrique, ça peut valoir le coup. Ailleurs, ça se discute.

Valoriser la chaleur fatale : beau sur le papier

Récupérer la chaleur d'un data center pour chauffer des logements, c'est une idée ancienne. Sur le terrain, ça marche quand trois conditions sont réunies : un data center à température d'eau suffisamment élevée, un réseau de chaleur existant à moins d'un kilomètre, et un opérateur de réseau prêt à signer. J'ai vu un projet capoter pour la deuxième raison. Le data center était en zone d'activité, le quartier d'habitation à quatre kilomètres. Faire courir 4 km de tuyauterie isolée, ça mange la rentabilité du dispositif.

Allonger la durée de vie, sérieusement

Le geste le plus sous-estimé. Un serveur qu'on garde deux ans de plus, c'est un serveur qu'on ne fabrique pas. Sur l'empreinte carbone totale d'un équipement, la phase de fabrication pèse souvent plus lourd que toute sa vie en exploitation. Changer la politique d'achat pour intégrer un critère de réparabilité, ça ne coûte rien et ça change tout sur cinq ans.

Mesurer avant d'agir : sans chiffres, vous naviguez à vue

La première fois que j'ai voulu auditer un data center, je n'ai trouvé que trois compteurs dans la salle. Trois. Pour un site de 200 baies. Impossible de distinguer ce qui consommait quoi. On ne peut pas optimiser ce qu'on ne mesure pas. Point.

PUE, WUE : ces métriques qu'on vous sert partout

Le PUE (Power Usage Effectiveness) compare la puissance totale du site à la puissance consommée par l'informatique. Un PUE de 1,2 est bon. Un PUE de 2 signifie que vous consommez autant pour faire tourner la clim et les onduleurs que pour faire tourner les serveurs. Le WUE (Water Usage Effectiveness) fait le même rapport sur l'eau.

Ces deux chiffres sont utiles. Ils sont aussi faciles à maquiller : on déplace des charges hors périmètre, on arrête une partie du site pendant la mesure, on change la définition. J'ai vu passer un PUE annoncé de 1,15 sur une plaquette, alors que le site réel tournait à 1,6. La différence : le calcul excluait la climatisation technique de la zone bureau.

Deux recommandations concrètes :

1. Exiger la méthode de calcul, pas seulement la valeur.
2. Installer des compteurs sur chaque allée. Le surcoût est marginal, l'information est précieuse.

Ce que vous pouvez demander à votre hébergeur dès demain

Si vous êtes client d'un hébergeur et que vous ne gérez pas la salle, vous n'êtes pas sans levier. Vous pouvez demander :

• La valeur de PUE et WUE, avec la méthode de calcul.
• L'origine de l'électricité (mix, garanties d'origine).
• Le taux d'eau évaporée par mois, en litres.
• La politique de réemploi des équipements sortis.
• La localisation des sites qui hébergent vos données.

Les hébergeurs sérieux répondent. Ceux qui refusent ou qui bottent en touche vous disent en creux qu'ils n'ont rien à montrer.

Ce qui ne marche pas, malgré ce qu'on lit partout

Deux ans de tests m'ont laissé des certitudes négatives. Les compter évite de perdre du temps.

La compensation carbone seule

Planter des arbres pour compenser un data center qui tourne vingt-quatre heures sur vingt-quatre, c'est un pansement sur une hémorragie. La compensation a sa place, à la marge, une fois que vous avez fait le vrai travail de sobriété. Avant, c'est de la communication. J'ai vu des entreprises claquer 40 000 € en crédits carbone et ne pas vouloir mettre 4 000 € dans des compteurs d'énergie.

« On tourne avec de l'électricité verte, donc tout va bien »

Non. L'électricité renouvelable a une empreinte, elle est produite quelque part, elle consomme des ressources à la fabrication des panneaux et des éoliennes. Et surtout : votre data center consomme de l'eau, occupe du foncier, produit des déchets électroniques. Le contrat d'électricité verte ne règle aucun de ces trois postes.

« Mon site est petit, ça ne compte pas »

Un data center de 50 baies mal refroidi consomme proportionnellement plus qu'un hyperscale bien conçu. Les nombreux sites de petite taille, disséminés dans les zones d'activité et les sous-sols d'immeubles, pèsent lourd dans le total. Et ils sont rarement audités.

Ce que je regarderais si je recommençais aujourd'hui

Si je devais reprendre un projet d'optimisation à zéro demain matin, je commencerais par une semaine d'instrumentation pure. Pas de plan d'action avant ça. Puis j'attaquerais dans cet ordre : d'abord le logiciel (c'est gratuit ou presque), ensuite l'allongement de la durée de vie du matériel, enfin le refroidissement. Et je mettrais un veto ferme sur tout argumentaire qui commence par « on va compenser ».

La question que je me pose encore, et que je n'ai pas résolue : à partir de quel volume de charge IA un référentiel de sobriété devient-il vraiment contraignant pour un hébergeur ? Personne n'a de réponse nette. Ni les exploitants, ni les clients, ni moi. C'est probablement là que se jouera la prochaine bataille réglementaire.