J'ai vu trop souvent des équipes productives renoncer à mesurer l'empreinte carbone de leurs pipelines de machine learning faute de temps ou de ressources. Leur raisonnement est simple : ajouter des métriques environnementales semble synonyme de complexité opérationnelle, d'outils supplémentaires et d'une nouvelle charge de maintenance. Pourtant, il est possible de mettre en place un observatoire d'empreinte carbone pour pipelines ML qui apporte de la visibilité utile sans alourdir l'exploitation. Dans cet article, je partage une démarche pragmatique et éprouvée pour intégrer cette visibilité de manière incrémentale et automatisée.

Pourquoi un observatoire et pas une simple estimation ponctuelle

Une estimation ponctuelle — par exemple calculer l'empreinte d'un entraînement une fois — a sa valeur pédagogique. Mais un observatoire vise autre chose : suivre l'évolution dans le temps, corréler aux versions de modèles, aux jeux de données, aux coûts et aux KPIs business, et enfin permettre des décisions opérationnelles (mettre un entraînement hors-pic, optimiser une architecture, choisir une instance moins énergivore). Sans cette continuité, on risque d'accumuler des actions isolées sans mesurer leur impact réel.

Principes pour éviter la complexité opérationnelle

Voici les principes que j'applique systématiquement pour ne pas alourdir le quotidien des ingénieurs :

  • Automatiser la collecte au maximum : ne rien demander manuellement aux développeurs.
  • Intégrer aux pipelines existants (CI/CD, orchestrateurs comme Airflow, Kubeflow, MLflow) plutôt que de créer un système parallèle.
  • Reporter des métriques simples et actionnables plutôt que des dizaines d'indicateurs théoriques.
  • Utiliser des estimations robustes quand la mesure directe est impossible (ex. consommation d'un GPU dans un cluster partagé).
  • Rendre les données utiles au-delà du reporting — corrélations avec coût, latence, précision.

    • Quelles métriques suivre — et pourquoi

    Plutôt que de chercher l'exhaustivité, je me concentre sur ce qui permet des décisions rapides :

  • kWh consommés par tâche (entraînement, inférence batch, évaluation). C'est la base pour convertir en émissions CO2e.
  • CO2e estimé (gCO2e ou kgCO2e) par tâche et par version de modèle.
  • Durée de la tâche et type d'instance (CPU, GPU, mémoire), qui expliquent en grande partie la consommation.
  • Localisation (région cloud) pour appliquer des facteurs d'émission électriques locaux.
  • Utilisation GPU/CPU (si disponible) pour affiner l'estimation.
  • Coût cloud corrélé pour prioriser actions à fort impact CO2e/cout.

    • Ces métriques suffisent à produire des tableaux de bord pertinents et à lancer des actions d'optimisation. Voici un tableau simple récapitulatif que j'utilise souvent dans les premiers déploiements :

    Indicatif Type Usage
    kWh Mesure/Estimation Base pour calcul CO2e
    gCO2e Calcul Reporting et comparaisons
    Instance Type Étiquette Optimisation infra
    Duration Mesure Diagnoser long runs
    Region Étiquette Appliquer facteurs d'émission

    Architecture cible — légère et incrémentale

    Je recommande une architecture composée de trois briques simples :

  • Instrumentation légère dans les jobs ML (scripts, containers) pour émettre des métriques.
  • Un collector centralisé (peut-être Prometheus, InfluxDB ou même des events vers un data lake) qui stocke et normalise.
  • Un moteur de calcul pour convertir kWh en CO2e (facteurs d'émission par région, mix énergétique) et produire des dashboards (Grafana, Metabase, ou un notebook).

    • Concrètement : un hook à la fin d'un job (ou un signal périodique) envoie un événement JSON au collector contenant : durée, ressources allouées, métriques d'utilisation (si disponibles), et région. L'event est enrichi par le collector (lookup du facteur d'émission) puis stocké et affiché.

    Mesure vs estimation — comment choisir

    La mesure directe (compteurs d'énergie sur bare-metal, métriques d'hyperviseur) est idéale mais rarement accessible dans le cloud public. J'opte donc pour une hiérarchie :

  • Si vous êtes on-premise et avez accès à la consommation électrique : mesurer directement.
  • Si vous utilisez des instances dédiées (ex : instances réservées GCP/AWS) : utiliser le TDP/consommation fournie par le vendor et affiner avec l'utilisation CPU/GPU.
  • Si vous êtes en Kubernetes partagé : estimer via durée * instance nominale * facteur d'utilisation moyen (p. ex. 50–70%).

    • Pour réduire l'erreur, je recommande de calibrer l'estimation initiale : comparer pour quelques runs la valeur estimée à une mesure plus précise (ex. instance dédiée ou benchmark local) et ajuster le coefficient d'utilisation. Une fois calibré, le modèle d'estimation devient fiable pour suivre les tendances.

    Automatisation : où coller l'instrumentation

    Les points d'intégration les plus efficaces :

  • En fin de job d'entraînement : un script post-run envoie métriques.
  • Dans les opérateurs Airflow/Kubeflow : ajouter un hook commun qui capture start/end/labels.
  • Au niveau du runtime container : un sidecar léger qui lit cgroups/cpuacct et expose utilisation pour le collector.

    • J'ai utilisé avec succès des solutions simples : un petit conteneur Python qui lit /sys/fs/cgroup, calcule la consommation estimée et poste un event dans un topic Kafka. Pour les petites équipes, un webhook vers un endpoint central REST suffit.

    Facteurs d'émission et sources de vérité

    La conversion kWh → gCO2e dépend du mix énergétique régional. Plusieurs sources existent : l'AIE, les bases ouvertes comme "ElectricityMap", ou les datasets fournis par les clouds (AWS, GCP) qui donnent des indices régionaux. Je conseille :

  • Prioriser des sources publiques transparentes et versionnées.
  • Stocker les facteurs avec un horodatage pour garantir que les calculs historiques restent reproductibles.
  • Permettre d'appliquer différents scénarios (pessimiste, réaliste) — utile pour les réunions stakeholders.

    • Dashboards et usages pratiques

    Un bon dashboard permet de répondre aux questions suivantes en un coup d'œil :

  • Quels entraînements émettent le plus ? (top 10)
  • Évolution mensuelle du CO2e par modèle/projet
  • CO2e vs coût cloud : où optimiser pour un double dividende
  • Impact d'une optimisation : combien de CO2e sauvé si on change d'instance ou réduit l'epochs ?

    • J'intègre aussi des alertes simples : par exemple, si un run dépasse 3x la consommation habituelle pour un même job, une alerte Slack est envoyée au propriétaire du modèle — souvent l'origine est une boucle infinie ou un dataset mal filtré.

    Bonnes pratiques opérationnelles

    Quelques habitudes à mettre en place pour que l'observatoire devienne utile et adopté :

  • Tagger systématiquement les runs avec : équipe, projet, version de modèle, dataset.
  • Documenter la méthode d'estimation et la mettre dans le repo infra.
  • Rendre les dashboards accessibles aux PMs et responsables R&D pour ancrer la responsabilité.
  • Reporter le CO2e dans les PRs majeures de modèles (comme un KPI additionnel).

    • Outils et bibliothèques utiles

    Si vous voulez commencer vite, voici quelques outils qui m'ont aidée :

  • CodeCarbon — pour une estimation locale et cloud, simple à intégrer dans des scripts Python.
  • ElectricityMap API — pour facteurs d'émission régionaux.
  • Prometheus + Grafana — pour collecter et visualiser métriques en temps-réel.
  • MLflow — pour enrichir les runs avec métriques CO2e et corréler à l'hyperparamétrie.

    • Ces outils réduisent la mise en place initiale et s'intègrent bien dans des pipelines déjà en place.

    Mesurer et suivre l'empreinte carbone d'un pipeline ML n'est pas un luxe : c'est une compétence opérationnelle qui permet de mieux prioriser les optimisations techniques et économiques. En respectant les principes d'automatisation, d'incrémentalité et de métriques actionnables, on peut bâtir un observatoire utile sans ajouter de complexité insurmontable à l'équipe.