Le numérique représente 4 % des émissions mondiales de CO2. Le cloud peut être un levier de réduction d'empreinte carbone — à condition d'adopter les bonnes pratiques Green IT.
Le cloud est-il vert ? Les chiffres à connaître
Le secteur numérique représente aujourd'hui 4 % des émissions mondiales de gaz à effet de serre, selon l'Agence Internationale de l'Énergie (AIE). Les datacenters constituent une part significative de cette empreinte, avec une consommation électrique mondiale estimée à 200 TWh par an. La bonne nouvelle : le cloud public est structurellement plus efficace que l'infrastructure on-premise, avec des taux d'utilisation de 65 à 80 % contre 10 à 15 % en datacenter privé.
Les hyperscalers affichent des indicateurs d'efficacité énergétique (PUE — Power Usage Effectiveness) bien inférieurs à la moyenne mondiale (1,58 selon Uptime Institute) : AWS atteint un PUE moyen de 1,2, Google Cloud de 1,1 (meilleur de la classe), et OVH de 1,3 sur ses datacenters les plus récents. Un PUE de 1,0 serait parfait (100 % de l'énergie va au calcul) ; 1,2 signifie que 20 % est perdu en refroidissement et distribution électrique.
Mais migrer vers le cloud ne suffit pas à verdir votre SI. L'usage que vous faites du cloud détermine votre empreinte réelle.
Mesurer son empreinte avec l'AWS Customer Carbon Footprint Tool
AWS Customer Carbon Footprint Tool, disponible depuis la console AWS Cost Management, fournit une estimation mensuelle de vos émissions de CO2 par service et par région, exprimée en tonnes de CO2 équivalent (tCO2e). L'outil calcule également l'économie réalisée par rapport à un datacenter on-premise équivalent.
# Accès via AWS CLI
aws ce get-carbon-footprint-summary --billing-period-start 2024-01-01 --billing-period-end 2024-12-31 --region eu-west-1
# Exemple de sortie
{
"carbonFootprintSummary": {
"estimatedCarbonAbated": {
"amount": 12.4,
"unit": "METRIC_TON_OF_CO2E"
},
"estimatedCarbonEmissions": {
"amount": 3.2,
"unit": "METRIC_TON_OF_CO2E"
}
}
}Utilisez cet outil pour établir votre baseline trimestrielle et définir un objectif de réduction (par exemple -10 % par an). Réduction carbone et réduction de coûts sont généralement corrélées : moins vous gaspillez, moins vous payez et moins vous émettez.
Choisir les régions à faible intensité carbone
L'intensité carbone de l'électricité varie considérablement selon les régions AWS, en fonction du mix énergétique local. Déployer des workloads sensibles à la latence dans eu-north-1 plutôt que ap-southeast-1 peut diviser l'empreinte carbone par 30.
| Région AWS | Localisation | Intensité carbone (gCO2eq/kWh) | Source principale |
|---|---|---|---|
| eu-north-1 | Stockholm | ~12 | Hydraulique |
| eu-west-1 | Irlande | ~240 | Éolien offshore |
| us-west-2 | Oregon | ~275 | Hydraulique + éolien |
| eu-central-1 | Francfort | ~338 | Mix allemand |
| us-east-1 | Virginie | ~415 | Mix américain Est |
| ap-southeast-1 | Singapour | ~408 | Gaz naturel |
Stratégie pratique : déployez vos workloads critiques et sensibles à la latence dans votre région principale (eu-west-1 pour la plupart des entreprises françaises), et vos workloads batch et de traitement différé dans eu-north-1 ou us-west-2.
Graviton3 : 60 % plus économe en énergie
Les processeurs AWS Graviton3 (architecture ARM) offrent jusqu'à 60 % de meilleures performances par watt par rapport aux instances x86 équivalentes (m6i, c6i, r6i). Cette efficacité se traduit par une double économie : moins d'énergie consommée et un prix AWS inférieur de 15 à 20 %.
# Comparaison m6i.xlarge (x86) vs m7g.xlarge (Graviton3)
# m6i.xlarge : 4 vCPU, 16 GB RAM → ~0.192 $/h (eu-west-1)
# m7g.xlarge : 4 vCPU, 16 GB RAM → ~0.163 $/h (eu-west-1)
# Économie : ~15 % sur le coût + 60 % sur la conso énergie/watt
# Terraform : forcer Graviton3 pour un groupe de nœuds EKS
resource "aws_eks_node_group" "graviton" {
cluster_name = aws_eks_cluster.main.name
node_group_name = "graviton3-workers"
instance_types = ["m7g.xlarge"] # Graviton3
ami_type = "AL2_ARM_64"
scaling_config {
desired_size = 3
max_size = 10
min_size = 1
}
}Migration progressive recommandée : commencez par les workloads sans dépendances binaires x86 (applications compilées en Go, Python, Node.js), puis migrez les applications Java (les JVM modernes sont entièrement compatibles ARM).
Rightsizing avec AWS Compute Optimizer
Une instance surdimensionnée consomme de l'énergie inutilement — un serveur EC2 à 15 % de CPU utilisation consomme néanmoins 60 à 70 % de sa puissance de pic. AWS Compute Optimizer analyse les métriques CloudWatch des 14 derniers jours et identifie les instances EC2, groupes Auto Scaling et fonctions Lambda sous-utilisés.
aws compute-optimizer get-ec2-instance-recommendations --filters name=Finding,values=OVER_PROVISIONED --region eu-west-1 --output json | jq '.instanceRecommendations[] | {
instance: .instanceArn,
current: .currentInstanceType,
recommended: .recommendationOptions[0].instanceType,
saving: .recommendationOptions[0].estimatedMonthlySavings.value
}'En moyenne, 30 % des instances EC2 sont surdimensionnées. Appliquer systématiquement les recommandations Compute Optimizer réduit la facture compute de 20 à 30 % et diminue d'autant l'empreinte carbone associée.
S3 Intelligent-Tiering : réduire l'empreinte du stockage
Le stockage S3 consomme de l'énergie proportionnellement au volume stocké, indépendamment de la fréquence d'accès. S3 Intelligent-Tiering déplace automatiquement les objets non accédés depuis 30 jours vers un tier à faible coût (et faible empreinte), puis vers Glacier si l'inactivité dépasse 90 jours.
# Lifecycle rule S3 vers Intelligent-Tiering puis Glacier
resource "aws_s3_bucket_lifecycle_configuration" "green" {
bucket = aws_s3_bucket.data.id
rule {
id = "intelligent-tiering-and-archive"
status = "Enabled"
transition {
days = 30
storage_class = "INTELLIGENT_TIERING"
}
transition {
days = 90
storage_class = "GLACIER_IR"
}
expiration {
days = 2555 # 7 ans — conformité légale
}
}
}Architectures Green : event-driven vs always-on
Un conteneur ECS Fargate qui tourne 24h/24 pour traiter en moyenne 2 requêtes par heure consomme de l'énergie en continu. Une fonction Lambda ne consomme de l'énergie que pendant l'exécution — typiquement quelques millisecondes par invocation. Pour les workloads irréguliers, serverless est systématiquement plus vert.
De même, les Spot Instances utilisent la capacité AWS inutilisée. Du point de vue carbone marginal, cette capacité serait consommée de toute façon — utiliser des Spots pour vos jobs batch revient à réutiliser une ressource déjà allouée, tout en réduisant votre facture de 60 à 90 % par rapport aux instances on-demand.
# Planification des workloads non-critiques hors heures de bureau
# EventBridge Scheduler : éteindre les instances dev la nuit
resource "aws_scheduler_schedule" "stop_dev" {
name = "stop-dev-instances"
flexible_time_window { mode = "OFF" }
schedule_expression = "cron(0 19 ? * MON-FRI *)" # 19h en semaine
target {
arn = "arn:aws:scheduler:::aws-sdk:ec2:stopInstances"
role_arn = aws_iam_role.scheduler.arn
input = jsonencode({
Filters = [{
Name = "tag:Environment"
Values = ["development"]
}]
})
}
}CSRD et émissions Scope 3 : vos obligations en 2025
La directive européenne CSRD (Corporate Sustainability Reporting Directive), obligatoire pour les grandes entreprises françaises dès l'exercice 2024 (publication en 2025), impose de déclarer les émissions de gaz à effet de serre selon les scopes 1, 2 et 3. Les émissions liées à l'usage du cloud sont classifiées en Scope 3 — catégorie 11 (utilisation des produits vendus) pour vos clients, ou en Scope 2 (consommation d'énergie indirecte) si vous êtes l'utilisateur final.
L'AWS Customer Carbon Footprint Tool fournit les données nécessaires pour alimenter votre reporting CSRD cloud. Exportez les rapports mensuels, consolidez-les par année civile, et intégrez-les à votre rapport de durabilité. Move2Cloud peut vous accompagner dans la mise en place d'un tableau de bord Green IT automatisé via AWS QuickSight.
Conclusion
Le Green IT cloud repose sur quatre leviers concrets : mesurer (Customer Carbon Footprint Tool), choisir les bonnes régions (eu-north-1, eu-west-1), adopter Graviton3 et supprimer le gaspillage (rightsizing, extinction automatique, S3 Intelligent-Tiering). Ces actions sont à la fois écologiquement responsables et financièrement bénéfiques — une rare convergence d'intérêts. Dans un contexte CSRD, elles vous donnent également la traçabilité nécessaire pour vos obligations de reporting.