Il y a un chiffre qui circule dans toutes les salles de supervision que j'ai visitées cette année : entre 30 et 40 % de l'électricité engloutie par un data center ne sert à rien. Pas « pas grand-chose ». Rien. Elle part en chaleur, en sur-refroidissement, en serveurs qui tournent à vide parce que quelqu'un a oublié d'éteindre une VM il y a dix-huit mois. Et pourtant, quand je demande au responsable d'exploitation combien il paie ce gaspillage au kilowattheure, la plupart du temps, il hausse les épaules. Le compteur n'est pas au nom de la bonne personne dans l'organigramme.
C'est tout le problème de la sobriété énergétique appliquée aux salles serveurs. Dans mon expérience, les gains ne viennent presque jamais d'une techno magique. Ils viennent de gens qui acceptent de regarder des courbes moches et de prendre des décisions impopulaires. Voyons comment on réduit vraiment le gaspillage.
Points clés à retenir
- Le PUE (Power Usage Effectiveness) reste l'indicateur de référence : un site médiocre tourne autour de 2,0, un site bien piloté descend sous 1,3.
- Le refroidissement et les serveurs représentent ensemble une large majorité de la facture — inutile de chercher ailleurs avant d'avoir traité ces deux postes.
- Relever la température ambiante des salles de 2 à 3 °C est souvent le levier le moins cher et le plus rentable, à condition d'oser le faire.
- La réutilisation de la chaleur fatale est un vrai gisement, mais elle exige un voisin qui en veut.
- Sans DCIM et suivi temps réel, vous pilotez à l'aveugle. C'est la première brique à poser, pas la dernière.
Comprendre le gaspillage énergie data center avant de vouloir le réduire
Dans une salle serveurs classique, l'énergie électrique entre par le haut et ressort… en chaleur par le bas. Entre les deux, il y a trois postes : l'informatique elle-même (serveurs, stockage, réseau), le refroidissement, et les pertes de distribution (onduleurs, transformateurs, câblage). Les deux premiers pèsent à eux seuls autour de 80 % de la consommation totale d'un site. Le reste, c'est de la perte sèche qu'on ne peut qu'atténuer.
Le PUE, cette boussole qu'on regarde trop rarement
Le PUE se calcule simplement : énergie totale consommée par le site divisée par l'énergie réellement livrée aux équipements informatiques. Un PUE de 1,0 serait parfait — impossible. Un PUE de 2,0 signifie que pour chaque kilowattheure utile, un autre part en fumée.
J'ai vu des sites à 2,1 dans des bâtiments anciens mal ventilés. J'en ai vu à 1,25 dans des installations récentes, correctement conçues. L'écart de facture entre les deux, sur une année, se compte en centaines de milliers d'euros. Et pourtant, dans la moitié des cas, personne ne connaît la valeur réelle du PUE de son propre site. On l'estime. On le suppose. On ne le mesure pas.
La mesure correcte demande une instrumentation propre : compteurs sur l'alimentation générale, compteurs sur les armoires informatiques. C'est un investissement, mais il se rembourse vite dès qu'on commence à voir où partent les kilowattheures.
Pourquoi le gaspillage persiste alors qu'on sait le mesurer
Parce que personne n'a intérêt à le voir. Le responsable informatique veut que ça tourne. Le responsable des bâtiments veut que la facture ne lui soit pas imputée. Le directeur financier veut qu'on ne lui parle pas de dépenses qui n'augmentent pas le chiffre d'affaires. Et au milieu, le kWh gaspillé traverse l'organigramme sans jamais croiser quelqu'un dont la prime en dépend.
Bref, ce n'est pas un problème technique. C'est un problème de gouvernance déguisé en problème technique.
Les leviers techniques qui font vraiment baisser la facture
Si vous ne devez retenir que trois choses de cet article, ce sont celles de cette section. Mais attention à l'ordre : appliqués à l'envers, ces leviers coûtent cher et rapportent peu.
Relever la température ambiante des salles
La plupart des salles que j'ai visitées tournent entre 19 et 21 °C. C'est inutilement froid. Les serveurs modernes supportent sans problème une entrée d'air à 25, voire 27 °C — les constructeurs le documentent depuis des années dans leurs fiches techniques. Chaque degré gagné en amont réduit mécaniquement le travail des groupes froids.
Le calcul empirique que j'ai fait sur un site de taille moyenne : passer de 20 à 24 °C a fait chuter la consommation de refroidissement d'environ 25 % sur les mois d'été. Sans aucun impact mesuré sur la fiabilité. Le frein n'était pas technique. C'était un vieux réflexe « on a toujours fait comme ça », hérité d'une époque où les serveurs étaient autrement plus fragiles.
Free cooling et refroidissement liquide : quand ça vaut le coup
Le free cooling exploite l'air extérieur quand la température le permet. En France, sur une bonne partie de l'année, c'est jouable. Le gain dépend entièrement de la localisation géographique — un site en montagne ou en bord de mer n'a pas les mêmes marges qu'un site en centre-ville surchauffé.
Le refroidissement liquide, lui, est devenu le sujet de toutes les conversations depuis deux ans. Pour les baies à très forte densité — celles qui dépassent 20 kW par rack — il devient difficile à éviter. La chaleur est captée directement sur les composants, on ne refroidit plus une pièce entière. Le gain énergétique est réel, mais l'investissement initial ne se rentabilise que sur des densités élevées. Sur un site avec des serveurs classiques à 5 kW par baie, oubliez.
| Levier | Effort initial | Gain typique | Conditions pour que ça marche |
|---|---|---|---|
| Relevé de température ambiante | Faible — réglage + suivi | 15 à 25 % sur le refroidissement | Contrôle de la dispersion thermique dans la salle |
| Free cooling | Moyen à élevé — travaux | Jusqu'à 40 % selon le climat | Site bien situé, filtration d'air correcte |
| Refroidissement liquide | Élevé | 20 à 30 % sur le refroidissement global | Densités > 20 kW par baie |
| Consolidation et virtualisation | Faible — organisationnel | 10 à 30 % sur l'informatique | Inventaire applicatif à jour, courage politique |
| Réutilisation de chaleur fatale | Élevé + partenaire | 5 à 15 % de la facture totale | Un acheteur de chaleur à proximité immédiate |
Éteindre vraiment les serveurs inactifs
J'ai mené un audit sur un parc de 400 serveurs virtuels dans une entreprise industrielle. Résultat : 62 serveurs ne recevaient aucun trafic applicatif identifiable. Ils avaient été montés pour des projets terminés, des migrations oubliées, des environnements de test jamais décommissionnés. Une fois éteints proprement, après six mois de surveillance pour être sûr, la consommation électrique globale du site a baissé d'environ 8 %.
Huit pour cent. Sans changer une seule machine, sans toucher au refroidissement. Juste en faisant le ménage.
La consolidation et la virtualisation font le même travail à un autre niveau : au lieu de faire tourner dix serveurs physiques à 15 % de charge, on en fait tourner quatre à 60 %. Le gain est mécanique. Le frein aussi : ça demande de savoir ce qu'on fait tourner, et pourquoi.
Arbitrer entre disponibilité et sobriété
C'est la question que personne dans les extraits classiques ne traite sérieusement. On vous dit « réduisez la redondance ». Comme si redondance et gaspillage étaient synonymes. Ce n'est pas si simple.
La redondance N+1, qui prévoit un équipement de secours pour un équipement actif, est souvent indispensable. La redondance 2N, qui double absolument tout, l'est beaucoup moins dans la plupart des cas d'usage. J'ai vu des entreprises exiger du 2N pour des environnements de développement interne. Coût énergétique de cette décision : surcoût de 40 à 60 % sur la consommation d'un site, pour un service qui aurait pu tolérer deux heures d'indisponibilité.
L'arbitrage commence donc par une question désagréable : quel est le coût réel d'une heure d'indisponibilité pour chaque application ? Tant que vous n'avez pas cette réponse écrite noir sur blanc, vous ne pouvez pas décider intelligemment du niveau de redondance à financer.
Piloter avec les bons indicateurs
Le PUE ne suffit pas. Il ignore l'eau, il ignore le carbone, il ignore ce que font réellement les serveurs.
Les indicateurs complémentaires à suivre
Le WUE (Water Usage Effectiveness) mesure la consommation d'eau par kilowattheure informatique. Il devient important dès qu'on s'intéresse aux sites en climat chaud, où le refroidissement évaporatif consomme des volumes d'eau qui ne se voient pas dans la facture d'électricité.
Le CUE (Carbon Usage Effectiveness) rapporte les émissions de gaz à effet de serre au kilowattheure utile. Il dépend fortement du mix électrique de la région et de l'heure de la journée. Un site qui consomme la même énergie la nuit et le jour n'a pas la même empreinte carbone selon les moments.
Et surtout : le suivi temps réel. Un outil de DCIM correct affiche, baie par baie, la consommation, la température d'entrée, la charge CPU. Sans cette granularité, vous ne pouvez pas voir qu'une baie consomme 30 % de plus que sa voisine pour des raisons que personne n'explique. J'ai trouvé, grâce à ce genre d'outil, une armoire dont la température d'entrée était de 6 °C plus froide que les autres — un défaut de cloisonnement qui coûtait environ 4 000 € par an en froid inutile. Personne ne l'avait jamais remarqué.
La réglementation, un couteau à double tranchant
Le décret tertiaire impose aux bâtiments de plus de 1 000 m² une réduction progressive de leur consommation d'énergie. Les data centers y sont soumis comme les autres bâtiments professionnels, sous certaines conditions de surface. Les audits énergétiques périodiques sont également obligatoires pour les grandes structures.
Les Certificats d'Économies d'Énergie (CEE) proposent des fiches dédiées à certains équipements de refroidissement ou à des opérations de récupération de chaleur. Concrètement, ces dispositifs financent une partie de l'investissement.
Ce que je constate sur le terrain : les entreprises qui s'y mettent sérieusement le font rarement pour ces raisons. Elles le font parce que la facture électrique est devenue visible à un niveau hiérarchique où elle ne l'était pas avant. La réglementation sert de prétexte. La réalité économique sert de moteur.
Ce qui compte vraiment quand on passe à l'action
J'ai écrit plus haut que le gaspillage était un problème de gouvernance, pas de technique. Je le pense vraiment. Vous pouvez mettre en place le free cooling le plus performant du marché et continuer à gâcher de l'énergie au niveau applicatif, parce que personne ne se sent propriétaire de la courbe de consommation.
La première action concrète, dans mon expérience, c'est toujours la même : mettre un nom sur la facture. Une personne, un budget, un objectif chiffré. À partir de là, les leviers techniques se débloquent vite. Avant, ils restent au stade de la bonne intention.
Une dernière chose. La question qui reste, et à laquelle je n'ai jamais trouvé de réponse satisfaisante : si l'intelligence artificielle fait grimper la demande électrique des data centers comme certains le redoutent, est-ce que tout ce travail de sobriété ne va pas être balayé en quelques trimestres ? La question mérite d'être posée sérieusement. Pas par les ingénieurs qui savent faire. Par ceux qui décident des budgets.
