Calculer le coût carbone par fonctionnalité ml: méthode pratique pour prioriser les optimisations et convaincre les dirigeants

Quand j'accompagne des équipes produit et des dirigeants sur l'intégration de modèles d'apprentissage automatique, la question revient de plus en plus : quel est le coût carbone réel d'une fonctionnalité ML et comment le traduire en KPI actionnables pour prioriser les améliorations ? Plutôt que de rester dans l'abstrait, j'ai développé une méthode pratique, reproductible et communicable — une façon de chiffrer le coût carbone par fonctionnalité ML, prioriser les optimisations et convaincre les décideurs avec des chiffres clairs.

Pourquoi calculer le coût carbone par fonctionnalité ML ?

Les modèles ML ont deux dimensions d'impact : le bénéfice fonctionnel (meilleure recommandation, détection, personnalisation) et le coût — en énergie, en argent et en émissions. Sans métrique dédiée à la fonctionnalité, on ne sait pas quoi optimiser ni quel arbitrage prendre entre performance et impact environnemental.

Calculer le coût carbone par fonctionnalité permet :

• d'identifier les fonctionnalités « lourdes » en émissions ;
• d'estimer le bénéfice carbone des optimisations (quantité de CO2e économisée) ;
• d'intégrer le critère carbone dans les roadmaps produit et les revues de priorités ;
• de parler aux dirigeants avec une unité compréhensible (gCO2e par requête, par utilisateur actif, ou par mois).

Principes de base : ce que je mesure et ce que j'exclus

Je distingue systématiquement :

• Entraînement (training) : coût énergétique ponctuel mais potentiellement élevé pour modèles larges ou pour remises à jour fréquentes.
• Inférence (serving) : coût récurrent par requête, souvent le plus pertinent pour une fonctionnalité en production.
• Scopes : je me concentre d'abord sur les émissions opérationnelles (Scope 2 — électricité consommée par vos datacenters). On peut ensuite étendre à Scope 1 (direct) et Scope 3 (fabrication du hardware, cloud provider upstream).

Méthode pratique étape par étape

Voici la méthode que j'utilise avec les équipes produit et infra, étape par étape. Elle combine mesures, estimations et bonnes sources.

1. Définir la fonctionnalité et la frontière

Précisez la fonctionnalité (ex. : « recommandation personnalisée en temps réel ») et ce qu'elle englobe : pipeline de pré-traitement, modèle d'inférence, post-traitement, stockage de features. Cela évite de comparer des choses différentes.

2. Mesurer la consommation énergétique

Pour l'inférence, mesurez l'énergie consommée par requête. Deux approches :

• Mesure directe : instrumenter un serveur/instance (outil comme CodeCarbon ou des métriques de fournisseur cloud) pour obtenir Wh par requête en conditions réelles.
• Estimation : mesurer la consommation CPU/GPU et le temps d'exécution, puis convertir en énergie à partir de la puissance nominale (W).

Pour l'entraînement, capturez la durée totale (heures), le type de hardware (nombre de GPU/TPU), et la puissance moyenne par unité.

3. Appliquer le facteur d'émission électrique

Multipliez l'énergie consommée (kWh) par le facteur d'émission du lieu d'exécution (gCO2e/kWh). Sources courantes :

• Les bilans des fournisseurs cloud (AWS, GCP, Azure publient des facteurs régionaux et des trackers d'émissions).
• Calculateurs comme Green Algorithms, ML Emissions Calculator ou données nationales d'électricité.

N'oubliez pas le PUE (Power Usage Effectiveness) du datacenter pour intégrer les pertes d'infrastructure (cooling, UPS). Si vous ne connaissez pas le PUE, utilisez une valeur standard de 1.2–1.5 selon le datacenter.

4. Ajouter une couche d'incertitude et de scope

Documentez les hypothèses (PUE, utilisation moyenne de la machine, facteurs régionaux). Pour aller plus loin, vous pouvez ajouter :

• une estimation de Scope 3 (fabrication du GPU) répartie sur la durée de vie du matériel ;
• les émissions de stockage pour features volumineuses ;
• les déplacements/ opérations associées si pertinent.

5. Normaliser : gCO2e par unité métier

Convertissez le résultat en une unité utile pour le produit :

• gCO2e par requête (ex. : par prédiction) — utile pour mesurer l'impact quotidien.
• gCO2e par utilisateur actif par mois — utile pour le reporting produit.
• tCO2e par an pour la fonctionnalité — utile pour les rapports RSE.

Exemple chiffré

Voici un exemple synthétique que j'utilise lors d'ateliers. Les chiffres sont illustratifs.

Dans cet exemple, 0,13 gCO2e par requête est faible en apparence, mais à l'échelle (100k requêtes/jour) cela devient 13 kg CO2e/jour, soit ~4,7 tCO2e/an — chiffre utile pour les arbitrages.

Outils pratiques

• CodeCarbon — instrumentation Python qui mesure l'empreinte pendant training/inférence.
• ML Emissions Calculator (le calculateur de MIT/Berkeley) — utile pour estimer entraînements de gros modèles.
• Green Algorithms — guide et calculateur pour la recherche reproducible.
• Les dashboards cloud (AWS Customer Carbon Footprint Tool, GCP Carbon Footprint) pour des données régionales et historiques.

Comment prioriser les optimisations

Une fois que vous avez gCO2e par fonctionnalité, je recommande de comparer le gain carbone potentiel et le coût / effort des actions :

• Optimisation modèle : quantiser, distiller ou pruner peut réduire gCO2e/requête significativement. Évaluez le tradeoff performance vs. empreinte.
• Batching & caching : regrouper requêtes ou mettre en cache des prédictions coûte peu et peut diviser le coût par requête.
• Tailoring infra : choisir une instance CPU adaptée plutôt qu’un GPU sur-dimensionné pour l'inférence.
• Régionalisation : exécuter les inférences dans des régions à faible intensité carbone ou avec électricité renouvelable.
• Fréquence d'entraînement : limiter les retrainings à ce qui apporte une valeur mesurable.

Convaincre les dirigeants : le narratif à adopter

Les dirigeants répondent aux chiffres clairs et aux comparaisons business. Voici comment je présente les résultats :

• Montrer le gCO2e par KPI métier (par utilisateur actif, par transaction). Les chiffres deviennent tangibles.
• Comparer l'impact carbone aux coûts financiers : exemple, "1 kg CO2e équivaut à X CHF en taxe carbone future ou à la compensation".
• Prioriser les quick wins (caching, batching, configuration infra) avec ROI estimé en émissions évitées et réduction de coût cloud.
• Proposer une roadmap : mesurer, optimiser, monitorer — et fixer un objectif (ex. -30% d'émissions par feature en 12 mois).

Mesures sur le long terme et gouvernance

Je recommande d'intégrer le suivi dans les KPI produit : ajouter le coût carbone estimé dans les revues mensuelles, et automatiser la mesure via des outils (CodeCarbon + pipeline CI/CD, ou intégration dans Datadog/Prometheus). Enfin, documentez les hypothèses pour rendre le calcul auditable et itérable.

Si vous voulez, je peux partager un template de feuille de calcul Excel/Google Sheets qui automatise ces conversions (Wh → kWh → gCO2e), ou vous aider à faire un atelier avec vos équipes pour mesurer une fonctionnalité critique en conditions réelles. Je l'ai fait plusieurs fois et c'est souvent le déclic qui permet d'aligner produit, infra et direction autour d'objectifs concrets et atteignables.