L’empreinte carbone du cloud était un sujet RSE marginal jusqu’en 2020. En 2026, c’est devenu un sujet opérationnel sous l’effet conjugué de trois pressions : la directive CSRD européenne qui impose progressivement le reporting Scope 3 (qui inclut le cloud), les engagements Net Zero des grandes entreprises, et la conscience client qui questionne les choix d’hébergement. Cette page pose les fondamentaux mesurables (PUE, mix énergétique), liste les calculateurs CO₂ par fournisseur, propose une architecture durable concrète, et défend une opinion : la sustainability cloud est moins coûteuse qu’on ne le croit — l’alignement avec le pilier Cost Optimization est si fort que faire les deux séparément est inefficace.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Le PUE et le mix énergétique comme métriques fondamentales
- Les calculateurs CO₂ par fournisseur (AWS, Azure, GCP, OVH, Outscale)
- Les 8 leviers d’une architecture cloud durable
- L’anticipation CSRD : quels reporting attendus en 2026, 2028
- L’alignement Sustainability ↔ Cost Optimization
Prérequis : avoir compris les régions cloud et le Well-Architected. Si besoin, lisez d’abord Régions et zones de disponibilité et Well-Architected Frameworks.
1. Pourquoi le sujet monte en 2026
Section intitulée « 1. Pourquoi le sujet monte en 2026 »Trois pressions convergent qui rendent la sustainability cloud incontournable.
Pression 1 — La directive CSRD européenne
Section intitulée « Pression 1 — La directive CSRD européenne »La Corporate Sustainability Reporting Directive (CSRD), adoptée en 2022 et transposée en 2024 en droit français, impose progressivement aux entreprises européennes de rapporter leur impact environnemental, social et de gouvernance, audité par un commissaire aux comptes.
Calendrier d’application :
- 2025 (premier reporting) : entreprises cotées de plus de 500 salariés.
- 2026 : grandes entreprises non cotées (250+ salariés, > 50 M€ CA).
- 2027 : PME cotées (avec dérogations).
- 2029 : entreprises non-UE avec activité significative en UE.
Le périmètre inclut les Scope 1, 2 et 3 d’émissions de gaz à effet de serre. Le Scope 3 inclut le cloud (catégorie « biens et services achetés »). En pratique, les organisations concernées doivent mesurer et déclarer l’empreinte carbone de leur usage cloud.
Pression 2 — Engagements Net Zero des entreprises
Section intitulée « Pression 2 — Engagements Net Zero des entreprises »Plus de 4 000 entreprises mondiales se sont engagées vers Net Zero (PAC, Microsoft 2030, Google 2030, AWS 2040, Apple 2030). Ces engagements redescendent sur les fournisseurs et clients via les chaînes d’approvisionnement.
Une grande entreprise française qui a pris un engagement Net Zero demande à ses fournisseurs cloud des plans de décarbonation alignés. Le choix de fournisseur cloud devient un critère ESG dans les appels d’offres.
Pression 3 — Conscience client et collaborateurs
Section intitulée « Pression 3 — Conscience client et collaborateurs »Sondages 2025 : 70 % des consommateurs européens considèrent l’empreinte numérique d’une entreprise dans leurs choix. 65 % des collaborateurs IT déclarent prendre en compte la politique green IT de leur employeur dans leur choix de poste.
L’empreinte cloud devient un élément de marque employeur et de différenciation commerciale.
2. Les métriques fondamentales
Section intitulée « 2. Les métriques fondamentales »PUE — Power Usage Effectiveness
Section intitulée « PUE — Power Usage Effectiveness »Le PUE mesure l’efficacité énergétique d’un datacenter. C’est le ratio entre l’énergie totale consommée par le datacenter et l’énergie utile arrivée à l’IT.
PUE = Énergie totale datacenter / Énergie utile ITLecture :
- PUE = 1,0 : théorique, datacenter parfait (impossible en pratique).
- PUE = 1,1–1,2 : datacenters hyperscalers modernes (Google, AWS, Microsoft Azure).
- PUE = 1,3–1,5 : datacenters cloud souverains européens modernes.
- PUE = 2,0 : datacenter d’entreprise classique avec climatisation traditionnelle.
- PUE = 2,5–3,0 : salles serveur d’entreprise non optimisées.
Un PUE de 1,1 vs 2,0 signifie que pour chaque kWh utile consommé par les serveurs, le datacenter total consomme 1,1 kWh ou 2,0 kWh. Le PUE des hyperscalers explique mathématiquement pourquoi le cloud public est plus efficient énergétiquement qu’une salle serveur d’entreprise.
Mix énergétique de la région
Section intitulée « Mix énergétique de la région »Le mix énergétique détermine la quantité de CO₂ émise par kWh consommé. Il varie drastiquement selon la région.
| Région cloud typique | Mix énergétique | g CO₂ / kWh |
|---|---|---|
France (eu-west-3 AWS, eu-west-2 Outscale, francecentral Azure) | 70 % nucléaire + 20 % renouvelable | ~50 g |
Suède (eu-north-1 AWS) | 90 % renouvelable + nucléaire | ~30 g |
Pologne (eu-central-2 Azure) | 70 % charbon | ~700 g |
Allemagne (eu-central-1 AWS) | 30 % charbon + lignite | ~330 g |
États-Unis Virginie (us-east-1 AWS) | Mix charbon + gaz + nucléaire | ~370 g |
États-Unis Oregon (us-west-2 AWS) | 80 % hydroélectrique | ~140 g |
Singapour (ap-southeast-1 AWS) | Mix gaz + GNL | ~430 g |
Conséquence : déployer un workload identique en France (eu-west-3) ou en Pologne (eu-central-2) émet 14× plus de CO₂ en Pologne pour la même consommation kWh. Le choix de région est le premier levier de réduction d’empreinte.
Le calcul global
Section intitulée « Le calcul global »L’empreinte carbone d’un usage cloud se calcule grossièrement ainsi :
Empreinte CO₂ = Compute (kWh) × PUE × Intensité carbone (g CO₂ / kWh)Pour un workload de 10 instances tournant 24/7 pendant 1 an :
- Consommation annuelle : ~10 instances × 100 W × 8760 h = 8,76 MWh utiles.
- Avec PUE 1,2 : 10,5 MWh totaux.
- Mix France (50 g/kWh) : 525 kg CO₂/an.
- Mix Pologne (700 g/kWh) : 7 350 kg CO₂/an (× 14).
3. Les calculateurs par fournisseur
Section intitulée « 3. Les calculateurs par fournisseur »Tous les fournisseurs majeurs proposent des outils pour mesurer l’empreinte cloud.
| Fournisseur | Outil |
|---|---|
| AWS | AWS Customer Carbon Footprint Tool — disponible dans la console AWS, gratuit. Affiche l’empreinte par compte, région, service. Granularité mensuelle. |
| Azure | Microsoft Cloud for Sustainability + Emissions Impact Dashboard. Power BI intégré. |
| GCP | Google Cloud Carbon Footprint dans Cloud Console. Granularité par projet et région. |
| Outscale | Outils en cours de développement 2026, pas encore généralisés. |
| OVHcloud | Calculateur publique sur le site OVH, basé sur les valeurs PUE OVH (actuellement 1,28 moyen). |
Limites de ces outils : ils mesurent l’empreinte côté fournisseur (datacenter et électricité) mais ne couvrent pas la fabrication des serveurs (Scope 3 fournisseur), ni votre propre code mal optimisé. Considérer les chiffres comme une borne inférieure.
4. Architecture cloud durable — 8 leviers concrets
Section intitulée « 4. Architecture cloud durable — 8 leviers concrets »Au-delà du choix de région, voici les leviers concrets pour réduire l’empreinte d’une architecture cloud.
Levier 1 — Right-sizing systématique
Section intitulée « Levier 1 — Right-sizing systématique »Une instance qui tourne à 10 % CPU 24/7 consomme la même énergie qu’une instance à 80 %. Le right-sizing réduit la consommation tout en réduisant les coûts. Outils : AWS Compute Optimizer, Azure Advisor, GCP Recommender.
Impact : -30 à -50 % de consommation typique sur un parc non optimisé.
Levier 2 — Scale-to-zero quand inactif
Section intitulée « Levier 2 — Scale-to-zero quand inactif »Les workloads non critiques (dev, staging, batch) peuvent être arrêtés la nuit, le week-end, en dehors des heures ouvrées. Automation par CloudWatch Events / Azure Automation / Cloud Scheduler.
Impact : -60 à -75 % sur les environnements non-prod (8h × 5j vs 24h × 7j).
Levier 3 — Choix de région bas-carbone
Section intitulée « Levier 3 — Choix de région bas-carbone »Pour les workloads non sensibles à la latence (batch, ML training, archivage), déployer dans une région à mix énergétique faible.
Exemples :
- ML training :
europe-north1GCP (Finlande, 30 g) oueu-north-1AWS (Suède, 30 g) au lieu deus-east-1(370 g). - Batch quotidien : régions françaises (50 g) plutôt que polonaises (700 g).
Impact : -85 % de CO₂ pour le même workload.
Levier 4 — Spot et preemptible instances
Section intitulée « Levier 4 — Spot et preemptible instances »Les instances Spot/Preemptible utilisent la capacité résiduelle des datacenters — elles ont une empreinte marginale faible (le matériel tournerait de toute façon).
Impact : -60 à -90 % de coût et d’empreinte sur workloads tolérants à l’interruption.
Levier 5 — Stockage intelligent par tier
Section intitulée « Levier 5 — Stockage intelligent par tier »Les données froides en Standard storage consomment de l’énergie pour rester accessibles instantanément. Les déplacer en Glacier / Archive Storage réduit drastiquement l’empreinte.
Impact : -70 % pour les données rarement accédées.
Levier 6 — Containers et serverless
Section intitulée « Levier 6 — Containers et serverless »Les containers et fonctions FaaS ont une densité énergétique bien supérieure aux VMs (cf. Mutualisation et virtualisation). Un container à scale-zero consomme 0 quand inactif, une VM consomme 24/7.
Impact : variable, mais structurellement plus efficient pour les workloads sporadiques.
Levier 7 — Optimisation du code
Section intitulée « Levier 7 — Optimisation du code »Du code inefficient (requêtes N+1, calculs redondants, leaks mémoire) consomme directement plus d’énergie. Les outils de profilage (Datadog APM, AWS X-Ray) identifient les hot paths.
Impact : variable, mais 10 à 30 % d’économie sur applications mal optimisées.
Levier 8 — Egress minimisé
Section intitulée « Levier 8 — Egress minimisé »Chaque GB egress consomme de l’énergie réseau. CDN, compression, cache local réduisent les transferts (cf. Egress et data transfer).
Impact : -50 à -80 % sur les workloads à fort trafic sortant.
5. Anticipation CSRD — préparer le reporting
Section intitulée « 5. Anticipation CSRD — préparer le reporting »Les organisations concernées par CSRD doivent dès 2026 mettre en place le reporting cloud. Voici les étapes pratiques.
Étape 1 — Activer les calculateurs fournisseur
Section intitulée « Étape 1 — Activer les calculateurs fournisseur »Dès le J1, activer les outils de mesure native AWS / Azure / GCP. Ils livrent typiquement :
- CO₂ total par mois et par compte.
- Décomposition par service (EC2, S3, RDS).
- Décomposition par région.
- Tendance historique (parfois sur 24 mois).
Étape 2 — Tagger les ressources
Section intitulée « Étape 2 — Tagger les ressources »Pour ventiler l’empreinte par projet, équipe, BU, tagging obligatoire par policy (CostCenter, Project, Environment, Owner). Sans tagging, l’empreinte agrégée n’est pas allouable.
Étape 3 — Centraliser les données
Section intitulée « Étape 3 — Centraliser les données »Pour les organisations multi-cloud, agréger les empreintes dans un outil centralisé. Solutions 2026 :
- Cloud Carbon Footprint (open source, multi-cloud).
- Watershed (SaaS, audit-ready).
- Persefoni (SaaS, audit-ready).
- Sweep (français, audit-ready).
Étape 4 — Reporting auditable
Section intitulée « Étape 4 — Reporting auditable »Le reporting CSRD doit être auditable par un commissaire aux comptes. Les données doivent être :
- Traçables : source, date, méthode de calcul documentés.
- Cohérentes : mêmes méthodes d’une période à l’autre.
- Vérifiables : extraits bruts disponibles si demandés.
Les solutions Watershed, Persefoni, Sweep livrent des reporting CSRD-ready directement intégrables au rapport de gestion.
6. L’alignement Sustainability ↔ Cost Optimization
Section intitulée « 6. L’alignement Sustainability ↔ Cost Optimization »Le pilier Sustainability du Well-Architected Framework (cf. Well-Architected Frameworks) converge fortement avec le pilier Cost Optimization. Les actions qui réduisent l’empreinte carbone réduisent quasiment toujours la facture cloud.
| Action | Impact CO₂ | Impact coût |
|---|---|---|
| Right-sizing | -30 à -50 % | -30 à -50 % |
| Scale-to-zero (non-prod) | -60 à -75 % | -60 à -75 % |
| Choix région bas-carbone | -85 % | Souvent neutre, parfois -10 % |
| Spot/Preemptible | -60 à -90 % | -60 à -90 % |
| Stockage tier | -70 % | -70 % |
| Code optimisé | -10 à -30 % | -10 à -30 % |
Conséquence : faire FinOps et Sustainability séparément est inefficace. La discipline mature traite les deux conjointement, avec une équipe ou un programme unique. Le ROI cumulé est environ 2× supérieur à les traiter en silos.
7. Bonnes pratiques pour aligner sustainability et FinOps
Section intitulée « 7. Bonnes pratiques pour aligner sustainability et FinOps »La sustainability cloud et l’optimisation des coûts s’appuient sur les mêmes leviers techniques. Les traiter conjointement double l’efficacité de chaque action et évite les doublons d’effort. Trois axes structurent une démarche cohérente.
Traiter sustainability et FinOps dans un seul programme. Right-sizing, scale-to-zero, choix de région, instances Spot, optimisation du stockage : toutes ces actions réduisent à la fois la facture et l’empreinte carbone. Les traiter en silos (équipe FinOps d’un côté, équipe RSE de l’autre) crée des doublons d’effort et des KPI parallèles qui peuvent diverger. Les organisations matures intègrent les deux dimensions dans un même programme avec des indicateurs conjoints (par exemple, kg CO₂/€ de revenu, ou émissions par utilisateur actif).
Anticiper les obligations réglementaires. La CSRD (Corporate Sustainability Reporting Directive) impose progressivement à un nombre croissant d’organisations européennes un reporting structuré sur leur empreinte carbone, incluant le numérique. Activer dès maintenant les calculateurs carbone des fournisseurs cloud (gratuits sur les principales plateformes) et structurer le tagging des ressources pour pouvoir répartir les émissions par projet, par équipe, ou par activité demande quelques jours d’effort. Le faire dans l’urgence d’un audit demande beaucoup plus, et le risque de non-conformité est réel.
Exploiter le levier du choix de région. Le mix énergétique varie fortement entre régions : certaines sont alimentées principalement par des sources bas-carbone (hydraulique, nucléaire), d’autres par des sources fortement émettrices. Placer les charges non sensibles à la latence (traitements batch, analytics, environnements de pré-production) dans une région bas-carbone réduit fortement leur empreinte sans perte fonctionnelle. Ce levier est le plus impactant en gain unitaire et reste insuffisamment exploité, parce que le placement par défaut suit souvent l’inertie historique plutôt qu’un choix conscient.
Bonnes pratiques opérationnelles : right-sizing trimestriel sur tous les environnements, scale-to-zero systématique sur les environnements non-production, audit annuel du placement géographique des charges, tagging discipliné pour pouvoir attribuer les émissions à un propriétaire métier.
À retenir
Section intitulée « À retenir »- Trois pressions rendent la sustainability cloud incontournable en 2026 : CSRD, engagements Net Zero, conscience client.
- PUE mesure l’efficacité datacenter — hyperscalers à 1,1-1,2, datacenter d’entreprise à 2,0.
- Mix énergétique varie drastiquement par région : France 50 g CO₂/kWh, Pologne 700 g (× 14).
- Les calculateurs natifs (AWS Carbon Footprint, Azure Emissions, GCP Carbon Footprint) sont gratuits — à activer dès le J1.
- 8 leviers d’architecture durable : right-sizing, scale-to-zero, choix région, Spot, stockage tier, containers, code optimisé, egress minimisé.
- CSRD s’applique progressivement de 2025 à 2029 — anticiper en 2026 coûte 10× moins cher qu’en 2027.
- Sustainability et Cost Optimization convergent — les traiter conjointement double le ROI.