Métriques-as-code

Les métriques-as-code consistent à définir les métriques métier — revenu, taux de conversion, utilisateurs actifs, churn — dans des fichiers de configuration versionnés (généralement YAML) qui vivent aux côtés du code de transformation des données. Les définitions de métriques passent par des pull requests, une revue de code, des tests automatisés et des pipelines CI/CD, exactement comme les modèles SQL dont elles dépendent.

C’est l’équivalent analytique de l’infrastructure-as-code. Au lieu que les métriques soient définies dans des outils BI (où elles sont invisibles pour les flux de travail d’ingénierie, difficiles à auditer et impossibles à tester systématiquement), elles deviennent des citoyens de première classe du codebase.

Pourquoi ce pattern existe

L’approche traditionnelle des métriques métier est la définition distribuée : chaque tableau de bord BI, chaque requête SQL, chaque notebook Python contient son propre calcul du « revenu » ou du « taux de conversion ». Ces définitions divergent silencieusement — la Finance peut calculer le revenu incluant les commandes en attente, le Marketing peut les exclure, et le tableau de bord exécutif peut utiliser une troisième définition. Les métriques-as-code centralisent les définitions dans un emplacement unique et auditable et les distribuent à tous les consommateurs en aval.

À quoi ça ressemble en pratique

Définitions de métriques dans dbt MetricFlow

L’implémentation la plus mature est le MetricFlow de dbt, où les métriques sont des définitions YAML dans le projet dbt :

metrics:
  - name: monthly_recurring_revenue
    description: >
      Total recurring revenue for the month, calculated from active
      subscriptions. Excludes one-time charges and usage-based fees.
    type: simple
    type_params:
      measure: mrr_amount
    filter: |
      {{ Dimension('subscription_id__status') }} = 'active'
    meta:
      owner: finance-analytics
      tier: certified
      last_reviewed: 2026-03-15

Le champ description sert à double usage : documentation pour les humains et contexte pour les copilotes IA qui ont besoin de comprendre ce que représente la métrique. Le bloc meta capture les informations de gouvernance — qui possède la définition, si elle est certifiée, quand elle a été dernièrement revue.

Métriques dérivées et ratio

Les métriques simples agrègent une seule mesure. Les métriques dérivées composent d’autres métriques :

metrics:
  - name: average_revenue_per_user
    description: "ARPU : revenu mensuel récurrent divisé par le nombre d'utilisateurs actifs"
    type: derived
    type_params:
      expr: monthly_recurring_revenue / active_users
      metrics:
        - name: monthly_recurring_revenue
        - name: active_users

  - name: gross_margin
    description: "Revenu moins COGS, divisé par le revenu"
    type: derived
    type_params:
      expr: (revenue - cost_of_goods_sold) / revenue
      metrics:
        - name: revenue
        - name: cost_of_goods_sold

Cette composabilité est critique. Quand la définition de revenue change (par exemple, on commence à exclure une nouvelle catégorie de remboursements), average_revenue_per_user et gross_margin se mettent à jour automatiquement. Pas de recherche de tableaux de bord. Pas de « avons-nous mis à jour tous les endroits qui référencent revenue ? »

Métriques cumulatives et période-sur-période

MetricFlow supporte nativement les agrégations avec fenêtres temporelles :

metrics:
  - name: trailing_12m_revenue
    description: "Fenêtre glissante de revenus sur 12 mois"
    type: cumulative
    type_params:
      measure: revenue_amount
      window: 12 months

  - name: revenue_growth_rate
    description: "Croissance des revenus mois-sur-mois en pourcentage"
    type: derived
    type_params:
      expr: (current_revenue - previous_revenue) / previous_revenue
      metrics:
        - name: current_revenue
          offset_window: 0
        - name: previous_revenue
          offset_window: 1 month

Ces définitions seraient du SQL complexe avec des fonctions de fenêtrage et de l’arithmétique de dates. Exprimées en YAML, elles sont lisibles par des parties prenantes non techniques qui peuvent vérifier si la logique métier est correcte même sans écrire du SQL.

Le flux de travail

Les métriques-as-code ne délivrent de la valeur que si le flux de travail applique la pratique. Le cycle de vie se présente ainsi :

1. Définir. Un analyste ou analytics engineer écrit le YAML de métrique dans une branche de fonctionnalité, incluant la description, le propriétaire et les filtres.

2. Réviser. Une pull request montre exactement ce qui a changé. Les relecteurs peuvent voir la formule de la métrique, la mesure sous-jacente, les filtres appliqués. Le diff est significatif :

metrics:
  - name: revenue
    type: simple
    type_params:
      measure: order_total
    filter: |
      {{ Dimension('order_id__status') }} = 'completed'
    filter: |
      {{ Dimension('order_id__status') }} IN ('completed', 'partially_refunded')

C’est un changement matériel sur une métrique métier centrale. Dans une métrique définie dans un outil BI, ce changement serait invisible lors de la revue de code. En YAML, c’est un diff de deux lignes qui déclenche la bonne conversation.

3. Tester. La CI exécute des validations sur la métrique :

# Dans les tests du projet dbt
unit_tests:
  - name: test_revenue_excludes_cancelled
    model: semantic_model_orders
    given:
      - input: ref('base__shopify__orders')
        rows:
          - {order_id: 1, amount: 100, status: "completed"}
          - {order_id: 2, amount: 50, status: "cancelled"}
    expect:
      rows:
        - {order_total: 100}

Les tests automatisés détectent les régressions : ce changement a-t-il cassé la sortie attendue ? La métrique correspond-elle encore aux chiffres validés par l’équipe Finance pour la période de référence ?

4. Déployer. Merger dans main. La couche sémantique intègre la nouvelle définition. Chaque consommateur en aval — tableaux de bord BI, copilotes IA, rapports planifiés, analyses intégrées — utilise automatiquement la métrique mise à jour sans aucune modification manuelle.

5. Découvrir. dbt génère de la documentation à partir du YAML, rendant les métriques cherchables. Les équipes peuvent parcourir les métriques disponibles, lire les descriptions, comprendre les filtres et voir les mesures sur lesquelles elles sont construites.

Quels outils le supportent

Le pattern métriques-as-code est passé de niche à attendu dans le paysage BI moderne :

Support natif complet :

Lightdash lit les définitions de métriques directement depuis le YAML du projet dbt. Pas de couche de modélisation séparée. Ce qui est défini dans dbt apparaît exactement dans l’outil BI.
Evidence utilise SQL + Markdown pour les rapports, avec des métriques définies en code et déployées en sites statiques. Les rapports sont littéralement des fichiers dans un dépôt Git.

Consommateurs de la couche sémantique :

Looker dispose d’un connecteur dbt Semantic Layer, bien que LookML reste son langage de modélisation principal.
Steep s’intègre avec l’API de la couche sémantique dbt Cloud.
Tout outil se connectant à l’API dbt Cloud Semantic Layer (JDBC/GraphQL/REST) consomme des définitions métriques-as-code.

En progression dans cette direction :

Power BI a adopté PBIR (Enhanced Report Format) comme format par défaut en janvier 2026. PBIR est basé sur des dossiers et compatible Git, rapprochant les définitions de rapports des flux de travail de code, bien que les définitions de métriques résident toujours dans le modèle Power BI plutôt que dans du YAML externe.
Tableau a livré un connecteur dbt Semantic Layer dans Tableau Cloud 2025.2.

L’écart de gouvernance sans métriques-as-code

Sans définitions de métriques centralisées et versionnées, la gouvernance se dégrade de façon prévisible :

Problème	Ce qui se passe
Dérive des métriques	5 tableaux de bord affichent 5 chiffres de revenu différents
Métriques fantômes	Les analystes créent des calculs ad hoc qui deviennent des standards de facto
Échec d’audit	Pas d’historique de quand ou pourquoi une définition de métrique a changé
Hallucination IA	Les copilotes inventent des calculs de métriques sans vocabulaire gouverné
Friction à l’intégration	Les nouveaux membres d’équipe passent des semaines à découvrir quelles métriques existent

Le taux d’échec d’implémentation BI de 73% (SR Analytics) est attribué à cet écart de gouvernance plutôt qu’au choix d’outils : les définitions de métriques ne sont pas standardisées et la confiance dans les tableaux de bord s’érode.

Patterns d’adoption

Commencer avec 5-10 métriques métier centrales qui causent le plus de confusion ou d’incohérence est plus pratique que de tout modéliser d’un coup.

La définition de métrique en code doit être faisant autorité. Une métrique concurrente définie dans l’UI d’un outil BI est un problème de cohérence à corriger. Les champs meta pour le propriétaire, le niveau (certified/exploratory/deprecated) et la date de dernière revue soutiennent la découvrabilité et la responsabilité.

Les valeurs de métriques doivent être testées contre des données de référence reconnues : si l’équipe Finance a validé le revenu du T4, la définition de métrique doit reproduire exactement ce chiffre.

Une modification d’une métrique centrale comme revenue est un changement cassant pour chaque tableau de bord qui l’affiche. Le versioning et la communication des changements s’appliquent aux modifications de métriques de la même façon qu’aux changements de schéma.