« C’est dans le cloud. » La formule a gagné, et avec elle une illusion confortable : le calcul n’aurait pas de lieu, pas de masse, pas de thermomètre. Il n’y a pas de nuage. Il y a des bâtiments, des transformateurs, des tours de refroidissement et des factures d’électricité.

Trois mensonges pratiques

Le premier est géographique. Les données « quelque part » sont en fait dans un département précis, souvent rural, souvent choisi parce que le foncier y est bon marché et l’eau disponible. La carte des datacenters est une carte de contraintes physiques déguisée en abstraction technique.

Le deuxième est énergétique. On résume la consommation au seul usage des serveurs. Or un datacenter consomme pour calculer, mais aussi pour refroidir, pour convertir le courant, pour maintenir la redondance — chaque niveau d’alimentation électrique s’accompagne d’une perte. Le fameux indicateur PUE, qui compare l’énergie totale à celle des seuls serveurs, tourne autour de 1,1 dans les installations les plus modernes et grimpe bien plus haut dans les plus anciennes. PUE de 1,5 signifie : pour chaque watt réellement utile, un demi-watt part en pure perte de transformation et de refroidissement.

Le troisième est matériel. On imagine le stockage comme immatériel. Il est fait de disques, de barrettes, de cartes accélératrices dont la fabrication concentre l’essentiel de l’empreinte — fabriquer une carte graphique demande des centaines de kilowattheures bien avant qu’elle n’ait exécuté un seul calcul.

L’entraînement, puis l’inférence

On parle beaucoup des modèles d’intelligence artificielle comme d’un gouffre énergétique. C’est vrai pour l’entraînement — un seul grand modèle représente des gigawattheures. Mais l’erreur de perspective est là : l’entraînement est un événement, l’inférence est un robinet.

Servir un milliard de requêtes coûte, cumulé, davantage que fabriquer le modèle qui les sert. Le coût réel du déploiement à grande échelle n’est pas dans le clou, il est dans l’usage quotidien. Et ce coût est directement proportionnel à une chose qu’on ne discute presque jamais : la taille du modèle qu’on choisit d’appeler.

La sobriété comme décision d’architecture

La frugalité n’est pas un renoncement. C’est un choix de conception, et il produit des compromis intéressants : un petit modèle, affiné pour une tâche précise, consomme une fraction d’un grand modèle généraliste et fait souvent aussi bien sur cette tâche. Le tri documentaire, la classification, l’extraction structurée n’ont pas besoin d’un milliard de paramètres.

La vraie question énergétique est rarement « peut-on faire mieux ? ». Elle est « est-ce qu’on a choisi le bon outil ? ». Un raisonnement tenu par un modèle cent fois plus gros que nécessaire n’est pas de la puissance, c’est du gaspillage déguisé en performance.

Ce que je fais de cette lucidité

Je tourne une partie de mes propres traitements sur des modèles que je peux héberger chez moi, sur une seule machine, dans une pièce chauffée comme une autre. Ce n’est pas une posture morale. C’est une décision d’ingénierie : je sais ce que ça coûte, je sais qui le paie, et je trouve sain de le savoir.

Le cloud n’est pas une abstraction heureuse. C’est un ensemble de tuyaux, de métaux et de compteurs. Regarder ces compteurs n’a rien de pessimiste. C’est simplement refuser de croire au ciel.