Pilier Sustainability sur OUTSCALE

Le pilier Sustainability couvre l’empreinte environnementale d’une architecture cloud : right-sizing comme levier vert (moins de CPU alloué = moins d’énergie consommée), lifecycle agressif sur le stockage froid, choix d’instances efficaces, mesure régulière des émissions. Sur OUTSCALE, l’API ReadCO2EmissionAccount retourne une estimation des émissions de gaz à effet de serre exprimée en kg CO₂e, sur les régions eu-west-2 (commerciale) et cloudgouv-eu-west-1 (SecNumCloud), depuis janvier 2024 avec une rétention de 36 mois. Cette page formule les questions clés, propose une checklist actionnable, deux ADR types et les points d’audit correspondants.

Le pilier en deux phrases

Sustainability évalue la capacité d’une organisation à mesurer l’empreinte environnementale de son infrastructure cloud, à la réduire par des choix architecturaux et opérationnels, et à rendre des comptes sur cette posture (rapports CSRD, communication interne, contrats clients). Sur OUTSCALE, il se matérialise par un suivi régulier via ReadCO2EmissionAccount, une discipline de right-sizing comme premier levier de réduction, et une lifecycle agressive sur les données peu chaudes pour libérer du stockage allocataire d’énergie.

Les questions clés

Une architecture qui revendique une posture Sustainability doit pouvoir répondre aux questions suivantes :

Mesure — l’équipe collecte-t-elle régulièrement les émissions estimées via ReadCO2EmissionAccount (région eu-west-2 ou cloudgouv-eu-west-1) ?
Suivi temporel — un dashboard suit-il les émissions mois après mois ? Sait-on si la tendance est à la hausse ou à la baisse ?
Catégorisation — les émissions sont-elles catégorisées par type de service (compute, stockage, réseau) pour identifier les principaux contributeurs ?
Right-sizing comme levier vert — l’équipe traite-t-elle le right-sizing non seulement comme un sujet de coût mais aussi comme un sujet d’empreinte ?
Lifecycle agressive — les buckets OOS de logs, archives et sauvegardes anciennes ont-ils des politiques d’expiration appliquées pour libérer le stockage ?
Choix d’instances — l’équipe privilégie-t-elle les générations TINA récentes (qui offrent généralement un meilleur rapport performance/énergie) lors des renouvellements ?
Workloads batch — les charges asynchrones (rapports, batchs ETL) sont-elles ordonnancées sur des fenêtres où l’intensité carbone du réseau électrique est plus basse ?
Reporting — les émissions sont-elles intégrées dans le reporting RSE / CSRD annuel de l’organisation ?

Sur les organisations soumises à la directive CSRD, ce pilier devient une obligation de reporting documentée, pas seulement une bonne pratique.

Application sur OUTSCALE

Carbon Footprint et `ReadCO2EmissionAccount`

OUTSCALE expose une API native d’empreinte carbone : ReadCO2EmissionAccount. Selon la documentation officielle, l’estimation couvre les 36 derniers mois à partir de janvier 2024 et est disponible sur les régions eu-west-2 et cloudgouv-eu-west-1. L’unité est exprimée en kilogrammes de CO₂ équivalent (kg CO₂e) et couvre le cycle de vie complet : usage de l’infrastructure, provisionnement matériel, maintenance.

Les paramètres de l’API (validés sur la spec OAPI) :

FromMonth — premier mois du calcul, format YYYY-MM-DD (ex. 2026-01-01).
ToMonth — dernier mois, format YYYY-MM-DD (ex. 2026-04-01).
Overall — booléen ; si true, retourne une valeur agrégée sur la période.

oapi-cli ReadCO2EmissionAccount \
  --FromMonth 2026-01-01 \
  --ToMonth 2026-04-01 \
  --Overall true

La réponse contient un champ Value (en KG), un CategoryDistribution qui ventile par catégorie de service (par exemple compute), et un FactorDistribution qui ventile par facteur (par exemple electricity). Un script qui appelle cette API mensuellement et alimente un dashboard donne à l’équipe une vision longitudinale de son empreinte.

Right-sizing comme levier vert

Une instance TINA surdimensionnée consomme du CPU, de la mémoire et de l’énergie sans valeur applicative. Sur le pilier Cost, le right-sizing libère du budget. Sur le pilier Sustainability, il libère directement des émissions évitées : moins d’instances actives, moins de courant consommé.

Le gisement type sur un parc mal entretenu : 15 à 30 % du compute est surdimensionné. Le right-sizing trimestriel adresse simultanément les deux piliers, ce qui en fait l’action prioritaire quand on démarre une démarche durabilité cloud.

Lifecycle agressive sur le stockage froid

Sur OOS, les buckets de logs anciens, d’archives historiques et de sauvegardes obsolètes accumulent des téraoctets qui consomment de l’énergie pour rester disponibles, sans valeur métier proportionnelle. Une politique Expiration automatique sur les buckets non critiques :

Logs applicatifs — expiration à 13 mois (rétention métriques typique).
Logs d’audit non réglementés — expiration à 13 mois.
Sauvegardes anciennes — expiration alignée sur la politique 3-2-1 documentée.
Versions non courantes — suppression après une fenêtre courte sur les buckets versionnés.

Le détail technique de la lifecycle OOS Outscale est dans Stockage — OOS, versioning, lifecycle : le mécanisme couvre l’expiration via Days ou Date, sans transition entre classes (Outscale ne propose pas plusieurs classes de stockage différenciées).

Choix de génération TINA

Les générations récentes (tinav6, tinav5) offrent généralement un meilleur rapport performance/énergie que les anciennes (tinav4, tinav3). À l’occasion d’un renouvellement applicatif (mise à jour OS, refonte d’OMI), tester la génération supérieure et mesurer la consommation réelle. Si la performance est égale ou meilleure pour le même coût, la mise à jour libère également des émissions.

Workloads batch et intensité carbone

L’intensité carbone du réseau électrique français varie selon l’heure (et la saison), même si elle reste globalement basse comparée à d’autres pays grâce au mix nucléaire / hydraulique. Pour les workloads asynchrones (batchs ETL nocturnes, calculs de rapports mensuels, jobs d’analyse), planifier sur des fenêtres creuses réduit légèrement l’empreinte. C’est un levier marginal sur OUTSCALE — il devient pertinent dans la durée et sur des volumes importants.

Checklist Definition of Done

Suivi mensuel CO₂ automatisé via ReadCO2EmissionAccount, dashboard alimenté.
Catégorisation par service suivie — identification des principaux contributeurs.
Right-sizing trimestriel documenté avec mesure d’impact en émissions évitées.
Lifecycle Expiration appliquée sur tous les buckets non critiques.
Renouvellement TINA vers génération récente envisagé à chaque mise à jour OS.
Reporting CSRD intégrant les émissions cloud, alignement avec le scope 3 du bilan carbone.
Politique de rétention snapshots BSU documentée et appliquée par script automatisé.

ADR types

ADR-SUS-01 — Suivi mensuel automatisé du CO₂

Contexte : l’organisation s’engage sur un objectif de réduction d’empreinte carbone, mais ne mesure pas l’empreinte cloud. Les arbitrages se font sans visibilité.

Décision : automatiser un appel mensuel à ReadCO2EmissionAccount (régions eu-west-2 et/ou cloudgouv-eu-west-1), persister le résultat dans un bucket OOS de reporting, alimenter un dashboard Grafana qui trace la trajectoire mois par mois. Intégrer la donnée au reporting RSE / CSRD annuel.

Conséquences : 1 à 2 jours-homme de mise en place. Bénéfices durables : visibilité longitudinale, conformité reporting réglementaire, base factuelle pour les arbitrages durabilité.

ADR-SUS-02 — Lifecycle Expiration standard sur les buckets non critiques

Contexte : les buckets OOS de logs et d’archives accumulent depuis l’origine du compte sans politique d’expiration. La taille croît, les émissions associées au stockage aussi.

Décision : appliquer une règle Expiration standard sur tous les buckets de logs et archives non couverts par une obligation réglementaire — typiquement 13 mois pour les logs applicatifs, alignée sur la rétention des métriques. Les buckets de sauvegardes critiques restent exclus et suivent leur politique propre.

Conséquences : économie immédiate de stockage, diminution mesurable des émissions catégorisées storage. Bénéfice durable : croissance maîtrisée, base factuelle pour communication RSE.

Points d’audit correspondants

oapi-cli ReadCO2EmissionAccount \
  --FromMonth 2026-01-01 \
  --ToMonth 2026-04-01 \
  --Overall true

Récupère l’estimation agrégée sur la période. Croiser avec les volumes de ressources actives pour identifier les leviers de réduction.

oapi-cli ReadCO2EmissionAccount \
  --FromMonth 2026-01-01 \
  --ToMonth 2026-04-01 \
  --Overall false

Avec Overall: false, retourne le détail par mois et par CategoryDistribution — utile pour identifier le mois où une dérive a démarré.

oapi-cli ReadVms --Filters.VmStateNames[] running

Pour chaque VM, vérifier la génération TINA (VmType). Identifier les instances en générations anciennes candidates au renouvellement.

L’audit complet est traité dans une page dédiée du Volet 5, à venir.

Antipatterns à éviter

Pas de mesure. S’engager sur un objectif de réduction sans automatiser la collecte des émissions. Sans donnée régulière, l’objectif reste déclaratif.

Lifecycle réservée au pilier Cost. Considérer la lifecycle uniquement comme un levier d’économie. Sustainability et Cost sont alignés sur ce sujet — les arbitrages doivent les traiter ensemble.

Renouvellement TINA différé. Maintenir des instances en générations anciennes pour ne pas toucher à un environnement « qui marche ». Le coût caché en émissions s’accumule sur la durée.

Reporting CSRD à part du tableau de bord opérationnel. Préparer un reporting CSRD annuel à partir d’extractions ad hoc, sans intégration au dashboard quotidien. Les écarts entre la donnée annuelle et la réalité opérationnelle deviennent intenables.

À retenir

API ReadCO2EmissionAccount — disponible sur eu-west-2 et cloudgouv-eu-west-1, données depuis janvier 2024, rétention 36 mois.
Unité kg CO₂e — cycle de vie complet (infrastructure + hardware + maintenance).
Right-sizing = levier coût ET levier vert simultanément.
Lifecycle Expiration sur les buckets non critiques — pas de transition entre classes chez Outscale.
Génération TINA récente — meilleur rapport performance/énergie en général.
Reporting CSRD intégré au dashboard opérationnel.

Prochaines étapes

Volet 5 — Vue d'ensemble Le sommaire des 7 piliers Well-Architected appliqués à OUTSCALE.

Pilier Cost Optimization Le pilier jumeau du Sustainability — les leviers se recouvrent largement.

Calcul — instances TINA et sizing Le right-sizing comme levier coût ET vert.

Stockage — OOS, versioning, lifecycle Les politiques Expiration sur OOS.