Méthodologie

Pipeline en un coup d'œil

events -> normalize -> correlate -> detect -> score -> report

Chaque étage est une fonction pure sur les données, avec des traits uniquement aux frontières d'I/O (IngestSource, ReportSink). Un finding produit par detect est apparié avec une estimation green-impact issue de score, puis agrégé par l'aggregator de transparence périodique sur une période calendaire.

Introduction : énergie et SCI v1.0

Si vous n'avez jamais implémenté un scoring carbone pour des workloads logiciels, cette introduction courte est un préalable pour les formules de la suite du document. Elle ne suppose pas de familiarité préalable avec les cadres réglementaires (CSRD, GHG Protocol, RGESN) ni avec la stack outillage énergie (SCI v1.0, RAPL, Scaphandre, SPECpower, Boavizta, API Electricity Maps). Chaque terme est défini en une ligne à sa première apparition. Les autres docs perf-sentinel renvoient ici pour les concepts de scoring vert, voir Configuration et Schéma.

Les cadres réglementaires en jeu. perf-sentinel aligne son modèle carbone sur trois cadres dont les lecteurs ont pu entendre parler, aucun n'est requis pour suivre la suite du document.

• CSRD (Corporate Sustainability Reporting Directive) est le régime obligatoire UE 2024 de reporting de durabilité. Les grandes entreprises européennes doivent publier des inventaires d'émissions audités selon trois scopes (directes, électricité achetée, chaîne de valeur). perf-sentinel peut alimenter une pipeline CSRD en données d'activité, mais n'est pas en soi un outil de reporting CSRD.
• GHG Protocol (Greenhouse Gas Protocol) est le standard international de comptabilité des émissions corporate publié par le WRI/WBCSD, la référence de facto derrière la CSRD et la plupart des régulations nationales. Le Scope 2 couvre l'électricité achetée, le Scope 3 couvre tout le reste en amont et aval, y compris le calcul logiciel acheté en cloud.
• RGESN (Référentiel Général d'Écoconception de Services Numériques) est le cadre français d'écoconception des services numériques publié par ARCEP, Arcom et ADEME en 2024. Il vérifie 78 critères couvrant architecture, contenu, hébergement et cycle de vie. perf-sentinel associe chaque détecteur aux critères qu'il sert, voir la correspondance RGESN 2024 ci-dessous.

Pourquoi SCI v1.0. Software Carbon Intensity est le standard développé par la Green Software Foundation et publié comme ISO/IEC 21031:2024 (ISO/IEC JTC 1, mars 2024). L'artefact publié par la GSF est la SCI Specification, révision courante v1.1. Il définit un score carbone par unité fonctionnelle pour le logiciel, SCI = (E * I) + M, exprimé en gCO2eq par requête (ou par toute unité fonctionnelle choisie). Les trois termes correspondent à trois phénomènes physiques distincts mesurés chacun par un outillage différent. perf-sentinel utilise SCI v1.0 parce que (a) c'est la méthodologie la plus largement adoptée pour comparer les émissions logicielles entre organisations, (b) elle sépare proprement l'optimisation marginale/évitable de la comptabilité d'inventaire totale, (c) elle est référencée par RGESN et alignée sur les frontières GHG Protocol Scope 2/3.

Les trois termes SCI.

• E (Énergie) est l'électricité consommée par opération, en kWh. perf-sentinel substitue une des quatre sources de mesure au runtime : un proxy I/O (io_proxy_v3, environ 1e-7 kWh par opération d'I/O, directionnel uniquement), des lectures RAPL via Scaphandre, le pourcentage CPU fourni par le cloud projeté sur des tables SPECpower, ou des coefficients de calibration fournis par l'opérateur via [green] calibration_file. La source retenue est exposée dans methodology.calibration.energy_source_models pour qu'un auditeur vérifie quel chemin a produit E.
• I (Intensité du réseau) est le carbone émis par kWh par le réseau électrique local, en gCO2eq/kWh. perf-sentinel embarque une table statique rafraîchie annuellement (couvrant toutes les régions cloud majeures et les principaux réseaux nationaux) et accepte un override en direct via l'API Electricity Maps quand [green.electricity_maps] est configuré. La source est exposée dans methodology.calibration.carbon_intensity_source comme une des valeurs static_tables, electricity_maps, ou mixed.
• M (Carbone embarqué) couvre les émissions de fabrication du silicium sous-jacent (CPU, RAM, réseau, construction datacentre), amorties par requête. perf-sentinel utilise un coefficient par défaut dérivé de Boavizta plus le papier HotCarbon 2024, surchargeable via [green] embodied_carbon_per_request_gco2. M est indépendant de la région et s'ajoute après E * I.

Qui lit quelle valeur. Un auditeur durabilité qui prépare une soumission CSRD scope 2 se soucie de total_carbon_kgco2eq et du bloc methodology.* qui prouve la source de chaque terme. Un SRE qui optimise le système se soucie de estimated_optimization_potential_kgco2eq, qui est le terme opérationnel évitable (avoidable_io_ops * ENERGY_PER_IO_OP_KWH * I) et exclut M parce qu'on ne dé-fabrique pas du silicium en corrigeant un N+1. L'efficiency_score (0-100) est le résumé opérateur dérivé uniquement de io_waste_ratio, pas des émissions absolues.

Limite connue : intervalle d'incertitude 2x. L'estimation carbone est livrée avec une fourchette multiplicative 2x explicite. C'est un signal délibéré que le modèle directionnel (en particulier le proxy I/O et les tables statiques) ne convient pas au reporting d'émissions à valeur réglementaire. Resserrer la fourchette demande Scaphandre RAPL ou SPECpower cloud pour le terme E, et Electricity Maps en direct pour le terme I. La discussion complète sur l'incertitude vit dans Limites.

Termes connexes que vous rencontrerez dans les sections ci-dessous. Des one-liners seulement, les définitions complètes sont dans les références liées.

• RAPL (Running Average Power Limit) est une fonctionnalité CPU Intel qui expose un compteur d'énergie matériel lisible via /sys/class/powercap/intel-rapl/. Il donne la consommation électrique par package à granularité milliseconde, sans instrumentation côté application. Les CPU AMD exposent une interface similaire sous un MSR différent. RAPL est ce que Scaphandre lit.
• Scaphandre est un profileur d'énergie open source qui interroge les compteurs RAPL et expose les lectures de puissance par processus comme un endpoint Prometheus. perf-sentinel scrape Scaphandre et attribue les lectures aux services instrumentés OTel via correspondance PID. Projet.
• SPECpower (SPECpower_ssj2008) est une suite de benchmarks qui projette le pourcentage d'utilisation CPU sur la consommation électrique pour un SKU serveur publié. La méthodologie Cloud Carbon Footprint utilise les courbes SPECpower comme proxy quand la mesure directe n'est pas disponible. perf-sentinel embarque une table SPECpower pour les principaux SKU cloud. Benchmark.
• CCF (Cloud Carbon Footprint) est la méthodologie open source qu'Etsy a publiée en 2020, qui combine tables SPECpower, intensités de réseau par région cloud, et amortissement embarqué. Le chemin cloud-energy de perf-sentinel est compatible CCF, mêmes entrées, mêmes coefficients. Projet.
• Boavizta est l'association française qui publie des méthodologies ouvertes et des données de référence pour l'analyse de cycle de vie des équipements numériques, en particulier les coefficients de carbone embarqué pour CPU et serveurs. Le terme M par défaut dans perf-sentinel dérive de Boavizta plus le papier HotCarbon 2024. Projet.
• API Electricity Maps est le service commercial (avec offre gratuite côté API) qui publie l'intensité carbone horaire par zone (gCO2eq/kWh) pour plus de 250 zones dans le monde. perf-sentinel l'appelle à la demande quand [green.electricity_maps] est configuré. Chaque requête retourne soit un facteur direct (génération opérationnelle uniquement) soit un facteur lifecycle (opérationnel plus fabrication des actifs de production). perf-sentinel enregistre celui qui a été utilisé. Doc API.
• gCO2eq / kgCO2eq signifie "grammes (ou kilogrammes) de CO2 équivalent". Équivalent parce que les gaz à effet de serre autres que le CO2 (méthane, protoxyde d'azote, ...) sont pondérés par leur pouvoir de réchauffement global ramené à une base CO2. Unité standard utilisée dans CSRD, GHG Protocol, SCI.
• Émissions marginales vs moyennes. L'émission moyenne est l'intensité moyenne du réseau sur une fenêtre (ce que donnent les tables statiques et la plupart des réponses Electricity Maps). L'émission marginale est l'intensité du prochain kWh consommé (souvent une centrale fossile de pointe), pertinente pour des décisions de décalage de charge mais pas pour le reporting d'inventaire. perf-sentinel reporte la moyenne : SCI v1.1 (2024) autorise l'intensité marginale court terme, marginale long terme ou moyenne (le texte SCI v1.0 / ISO exigeait les taux marginaux). Le scoring marginal est une amélioration future.

Ancrage dans la littérature

Le choix méthodologique d'exposer un score directionnel (efficiency_score calculé sur io_waste_ratio) et de classer les endpoints par impact relatif, plutôt que de rapporter une valeur absolue en watts, s'appuie sur une littérature indépendante autour de la mesure énergétique logicielle.

• Les compteurs énergétiques matériels sont précis pour leur périmètre. Khan, Hirki, Niemi, Nurminen et Ou (RAPL in Action : Experiences in Using RAPL for Power Measurements, ACM TOMPECS 3(2):1-26, 2018) caractérisent RAPL comme une source d'énergie fiable pour les packages CPU et DRAM qu'il couvre, avec la réserve connue qu'il n'inclut pas la périphérie, le stockage ni les pertes d'alimentation.
• Les compteurs logiciels suivent fidèlement le signal matériel. Jay, Ostapenco, Lefèvre, Trystram, Orgerie et Fichel (An experimental comparison of software-based power meters : focus on CPU and GPU, IEEE/ACM CCGrid 2023) rapportent une forte corrélation entre les compteurs logiciels (dont Scaphandre) et un wattmètre externe, tout en montrant que l'écart résiduel entre matériel et logiciel est significatif et non constant selon les workloads. Les compteurs logiciels sont de bons porteurs de signal, pas des substituts à la mesure absolue.
• Le relatif l'emporte sur l'absolu, et les déterminants principaux sont les patterns de requêtes. Ruch (Towards Greener Software : Measuring Performance and Energy Efficiency of Enterprise Applications, Project Thesis MSE, OST Eastern Switzerland University of Applied Sciences, superviseur Prof. Dr. Olaf Zimmermann, 2025) établit que les valeurs absolues d'énergie ne sont pas comparables entre systèmes d'exploitation, applications et jeux d'instructions, alors que la distribution relative de la consommation l'est, à travers OS, applications et ensembles d'opérations. Ce même travail identifie les patterns d'accès base de données (nombre de requêtes, volume d'enregistrements lus, technologie d'accès) comme les déterminants énergétiques majeurs des applications enterprise.

perf-sentinel se situe dans cette tradition. Le pipeline classe les endpoints par IIS relatif, compare les runs par deltas d'io_waste_ratio, et détecte les patterns d'accès base de données et inter-services que la littérature identifie comme déterminants énergétiques majeurs (N+1 SQL, N+1 HTTP, redundant SQL, redundant HTTP, fetch-all, fanout, chatty services, appels sérialisés). Il ne revendique pas une précision absolue de niveau wattmètre. La fourchette multiplicative 2x sur l'estimation carbone, le positionnement explicite comme compteur de gaspillage directionnel, et la discussion complète du périmètre et de la précision vivent dans Limites.

I/O Intensity Score (IIS)

Le proxy de base pour l'énergie est le nombre d'opérations d'I/O par couple (service, endpoint). perf-sentinel compte chaque span SQL ou HTTP sortant comme une opération d'I/O.

• total_io_ops : nombre de spans d'I/O sur l'ensemble des traces de la fenêtre analysée.
• avoidable_io_ops : nombre de spans d'I/O attribués à des anti-patterns évitables. Les quatre patterns évitables sont N+1 SQL, N+1 HTTP, redundant SQL, redundant HTTP, tous énumérés par FindingType::is_avoidable_io() et listés dans core_patterns_required de chaque rapport officiel.
• io_waste_ratio = avoidable_io_ops / total_io_ops, dans [0, 1].

Énergie par opération

L'énergie opérationnelle est approximée par un proxy à coefficient unique :

energy_kwh = total_io_ops * ENERGY_PER_IO_OP_KWH

ENERGY_PER_IO_OP_KWH = 1e-7 kWh est documenté dans score/carbon.rs et étiqueté comme modèle io_proxy_v3. Le coefficient est une estimation directionnelle, pas une mesure.

Lorsque l'opérateur branche le scraper Scaphandre RAPL optionnel ou un scraper cloud SPECpower, perf-sentinel substitue une énergie mesurée par service et bascule le tag de modèle vers scaphandre_rapl ou cloud_specpower. La section méthodologie d'un rapport expose scaphandre_used et specpower_table_version pour que les consommateurs sachent quel chemin a produit les chiffres.

CO2 opérationnel

Le terme opérationnel SCI (Software Carbon Intensity) est O = E * I, où E est l'énergie par fenêtre en kWh et I est l'intensité carbone du réseau en gCO2eq/kWh pour la région de la charge.

perf-sentinel embarque une table d'intensité réseau statique rafraîchie annuellement et accepte une surcharge temps réel via l'API Electricity Maps quand [green.electricity_maps] est configurée. Le champ methodology.calibration.carbon_intensity_source d'un rapport vaut electricity_maps, static_tables ou mixed pour qu'un auditeur puisse vérifier quel chemin a produit le CO2 opérationnel.

CO2 embarqué

Le terme SCI M couvre les émissions du silicium fabriqué amorti par requête. perf-sentinel utilise un coefficient par défaut fixe documenté dans config.rs::DEFAULT_EMBODIED_CARBON_PER_REQUEST_GCO2, surchargeable via [green] embodied_carbon_per_request_gco2. Le CO2 embarqué est indépendant de la région, ajouté au CO2 opérationnel avant que le total par fenêtre ne soit sommé sur la période du rapport.

Agrégation sur une période

perf-sentinel disclose lit les enveloppes Report archivées par fenêtre ({ts, report}) et les replie en trois étapes.

1. Chaque enveloppe est filtrée pour ne garder que celles tombant dans la période calendaire demandée.
2. Les compteurs globaux additionnent total_io_ops, avoidable_io_ops, total.mid (gCO2), avoidable.mid (gCO2). gCO2 est divisé par 1000 pour obtenir kgCO2eq.
3. L'attribution par service utilise les maps runtime-calibrated per_service_* quand la fenêtre source les porte. Sinon les totaux globaux sont distribués proportionnellement à la part d'I/O par service lue depuis Report.per_endpoint_io_ops. Une fenêtre sans offenders par service est rangée sous _unattributed sauf si --strict-attribution a été passé.

efficiency_score = clamp(100 - 100 * io_waste_ratio, 0, 100). L'efficacité par service utilise la même formule sur le ratio évitable / total propre au service.

Les signaux de qualité (0.7.0+) résument quelle part de la période a été mesurée directement plutôt qu'inférée du proxy.

• period_coverage = runtime_windows / total_windows, dans [0, 1], avec runtime_windows_count et fallback_windows_count qui portent les compteurs absolus derrière le ratio.
• binary_versions est l'ensemble des versions du binaire perf-sentinel observées sur la période, une mise à jour de daemon en milieu de période faisant porter plus d'une entrée à cet ensemble.
• calibration_applied sur methodology.calibration_inputs bascule à true quand au moins une fenêtre a appliqué les coefficients de calibration opérateur à l'énergie proxy.
• per_service_energy_models et per_service_measured_ratio (à la fois dans GreenSummary par fenêtre et dans Aggregate sur la période) surfacent la vue de fidélité par service : quel modèle énergétique a alimenté chaque service et quelle fraction de ses spans a effectivement été mesurée.

Les définitions wire-format de ces champs vivent dans les sections "Agrégat" et "Méthodologie" de Schéma.