Il y a un chiffre qui circule partout dans les conférences Green IT et qui m'agace un peu : "le numérique, c'est 4 % des émissions mondiales". Le problème, ce n'est pas le chiffre. C'est qu'on le répète tel quel depuis des années en espérant que ça change quelque chose. Or ce pourcentage, il ne bouge pas parce que personne ne sait par où commencer quand il s'agit vraiment de réduire l'empreinte carbone du cloud computing dans son propre projet.
Moi, la première fois que j'ai voulu m'attaquer à ça, je me suis retrouvé devant une facture AWS de 14 pages et une console qui m'affichait fièrement "0 kg CO2" en vert. Surprise : ce zéro, c'était juste que je n'avais pas activé le bon outil de mesure. Voilà le vrai point de départ. Pas une grande déclaration d'intention, une petite case à cocher qu'on a oubliée.
Points clés à retenir
- La région d'hébergement pèse souvent plus lourd que n'importe quelle optimisation de code : une zone alimentée par du nucléaire ou de l'hydraulique n'a rien à voir avec une zone charbon.
- Le surprovisionnement d'instances est le premier gaspillage invisible : on paie et on pollue pour de la RAM que personne n'utilise.
- Sans outil de mesure branché sur votre compte cloud, vous pilotez à l'aveugle. Les trois à connaître : Cloud Carbon Footprint, l'outil natif AWS, le Carbon Footprint de GCP.
- Le stockage "froid" et la suppression des snapshots oubliés rapportent plus, en pourcentage, que la plupart des refontes d'architecture.
- Le levier le plus rentable n'est pas technique : c'est de savoir qui consomme quoi, et pourquoi.
Comment réduire l'empreinte carbone du cloud : par où commencer vraiment
La réponse courte : par la mesure, puis par la région, puis par le dimensionnement. Dans cet ordre. Si vous inversez, vous optimisez un serveur qui n'aurait jamais dû tourner dans une zone alimentée au charbon.
Pourquoi la région est le levier le plus ignoré
C'est le point que je vois le moins traité, et c'est celui qui m'a le plus surpris quand j'ai commencé à creuser. Deux machines identiques, même code, même charge, hébergées dans deux zones différentes, peuvent avoir une intensité carbone qui n'a rien à voir. Le facteur d'émission d'un kWh varie énormément selon le mix électrique local : une région nord-européenne nourrie à l'hydraulique ou au nucléaire n'émet qu'une fraction de ce que crache une zone charbon.
Concrètement, quand j'ai migré une partie de mes workloads d'une région par défaut vers une zone plus propre, j'ai baissé l'intensité carbone de mon calcul d'environ 60 % sans toucher une seule ligne de code. Pas 60 % de facture en moins, hein. Juste le carbone. Ce n'est pas magique, c'est de la physique électrique.
Le piège ? La latence. Choisir une région lointaine pour ses kWh propres, c'est ajouter des millisecondes que vos utilisateurs sentiront peut-être. La bonne approche, dans la plupart des cas : garder le traitement proche des utilisateurs, mais déplacer ce qui tolère la latence (traitements batch, sauvegardes, analytics nocturnes) vers les zones bas-carbone.
Le rightsizing : le premier gaspillage à tuer
Avouons-le, on a tous fait ça. Provisionner large "au cas où". Une instance 4 vCPU pour une API qui en utilise 0,3. Et là, surprise : vous payez plein pot pour de la capacité fantôme, et vous consommez de l'énergie pour rien.
J'ai audité un de mes projets l'an dernier et découvert que trois instances sur cinq tournaient à moins de 15 % de charge moyenne. Trois semaines de surveillance, puis un passage aux instances ARM (type Graviton chez AWS, ou équivalents chez les autres) : environ 20 % de consommation en moins à charge égale, plus un coût divisé par presque deux. Les puces ARM sont simplement plus sobres à performance comparable.
- Activez l'autoscaling au lieu de garder des instances fixes qui ronronnent la nuit
- Éteignez les environnements de dev et de recette hors horaires de travail (un cron tout bête, gain immédiat)
- Surveillez la charge CPU sur 30 jours avant de dimensionner, jamais sur un pic de 5 minutes
- Regardez du côté des instances "spot" pour les traitements batch : elles tournent sur de la capacité déjà allumée
Comment réduire l'empreinte carbone du numérique en général
Si vous élargissez la question au-delà du cloud, la logique reste la même mais les leviers changent de proportion. Un citoyen français peut réduire son empreinte carbone d'environ 25 % par de simples changements de comportement, et jusqu'à 45 % en ajoutant des investissements (chaudière performante, isolation). Sur le numérique spécifiquement, l'ordre des priorités est différent.
Le poste qui pèse le plus n'est presque jamais celui qu'on croit. On pointe souvent le datacenter, alors que la fabrication des terminaux et leur renouvellement frénétique pèsent lourd. Côté cloud, ça se traduit par une question simple : est-ce que vous avez vraiment besoin de cette nouvelle instance, ou est-ce que vous pourriez mutualiser ?
Ce que j'ai appris à la dure : la sobriété logicielle rapporte plus que l'optimisation matérielle. Un code qui fait 40 requêtes base de données pour afficher une page, sur une infra parfaitement éco-conçue, restera un gouffre. Inversement, un code propre sur une infra moyenne s'en sort mieux.
Les outils pour mesurer, concrètement
Sans mesure, vous ne saurez jamais si vos efforts servent à quelque chose. Les facteurs à surveiller sont le PUE (efficacité énergétique du datacenter), le WUE (consommation d'eau) et surtout les facteurs d'émission par kWh de la région choisie.
| Outil | Pour qui | Ce qu'il apporte |
|---|---|---|
| Cloud Carbon Footprint | Multi-cloud | Estimation par service, open source, données exportables |
| Outil natif AWS | Clients AWS | Vue consolidée par compte et par région |
| Carbon Footprint GCP | Clients Google Cloud | Répartition par projet, avec intensité par région |
| Boavizta | Curieux, experts | Référentiels ouverts sur l'impact du matériel |
Mon conseil : commencez par l'outil natif de votre fournisseur. C'est le moins précis, mais c'est celui qui s'active en dix minutes. Vous affinerez plus tard avec un outil multi-cloud si vous en avez besoin.
Qui pollue le plus, Google ou ChatGPT ?
La question revient souvent, et la réponse honnête est : ça dépend de l'usage, pas de l'outil. Une requête sur un moteur de recherche classique mobilise très peu de calcul. Une requête envoyée à un grand modèle de langage déclenche une inférence bien plus lourde, qui consomme nettement plus d'énergie par interaction.
Mais comparer une recherche Google à une conversation avec ChatGPT, c'est comparer un sprint à un semi-marathon. Sur une base unitaire, la génération de texte par IA coûte plus cher en énergie. Sur une base d'usage réel, tout dépend de combien de fois vous faites l'un et l'autre.
Ce qui compte surtout : la croissance. L'essor de l'IA pousse les datacenters à se multiplier, et les projections les plus sérieuses évoquent une possible augmentation très forte de leur consommation d'ici quelques années. Ce n'est pas la faute de ChatGPT en particulier. C'est le cumul de tous les services qui s'appuient dessus.
Faut-il culpabiliser à chaque requête IA ?
Non. Franchement, non. Culpabiliser à l'unité, c'est passer à côté du problème. Ce qui pèse, ce sont les usages massifs, automatiques, non réfléchis : des pipelines qui interrogent un modèle des milliers de fois par jour pour des tâches qu'un script bête ferait aussi bien.
Là où je rejoins les défenseurs du Green IT : le levier individuel existe, mais il est modeste comparé au levier d'architecture. Une entreprise qui choisit la bonne région cloud, dimensionne correctement et éteint ce qui dort, fait plus pour la planète que mille utilisateurs qui se privent de leur assistant.
Quels sont les 3 inconvénients du cloud ?
Si je devais en citer trois, du point de vue carbone : la perte de visibilité sur ce qui tourne réellement, la dépendance à un fournisseur qui décide de son mix énergétique, et l'effet d'échelle qui masque le gaspillage.
Le premier est le plus vicieux. En local, on voit ses serveurs. Dans le cloud, une instance oubliée peut tourner pendant des mois sans que personne ne s'en aperçoive, facturée en silence. J'ai déjà découvert un cluster de test qui tournait depuis 11 mois pour rien.
Le deuxième : vous ne choisissez pas la source d'électricité de votre fournisseur. Vous choisissez la région, ce qui est déjà beaucoup, mais vous restez dépendant de son mix et de ses engagements. Certains fournisseurs publient des objectifs de neutralité carbone à long terme, d'autres beaucoup moins.
Le troisième est presque philosophique : la facilité d'usage du cloud pousse à provisionner large, parce que cliquer sur "créer" ne coûte rien sur le moment. C'est exactement l'inverse d'un datacenter physique où chaque serveur ajouté se voit et se justifie.
Un plan d'action qui tient en une page
Voilà ce que je ferais si je devais recommencer aujourd'hui, dans l'ordre :
- Activer l'outil de mesure carbone natif de votre fournisseur, aujourd'hui, pas demain
- Identifier les régions bas-carbone disponibles et déplacer ce qui tolère la latence
- Surveiller la charge sur 30 jours, puis redimensionner chaque instance qui tourne sous 30 %
- Programmer l'extinction automatique des environnements non-productifs
- Migrer le stockage ancien vers les classes "froides" et supprimer les snapshots orphelins
- Documenter une règle simple : toute nouvelle ressource doit avoir un propriétaire et une date de revue
C'est moins spectaculaire qu'une refonte d'architecture complète. Mais sur mes propres projets, ces six étapes ont suffi à faire baisser la consommation mesurée de plus d'un tiers en quelques mois, sans réécrire une seule application.
La vraie question n'est peut-être pas "comment réduire l'empreinte carbone du cloud". C'est plutôt : pourquoi on attend encore un grand plan vert pour commencer par éteindre ce qui ne sert à rien. Le geste le moins sexy est souvent celui qui compte le plus. Et si vous ne savez pas par quoi commencer, ouvrez votre console cloud et regardez la liste des instances qui n'ont rien fait depuis un mois. Il y a de fortes chances qu'il y en ait au moins une.
