Accueil › Glossaire › Usage Metering

Usage Metering

L’usage metering (mesure de consommation) est le processus de capture, d’agrégation et de quantification en temps réel de l’utilisation d’un service (requêtes API, tokens IA, temps de calcul, stockage) afin de facturer les clients proportionnellement à leur consommation réelle.

Pourquoi mesurer la consommation

Le modèle historique du SaaS, l’abonnement fixe par siège, s’effrite face aux produits IA. Un utilisateur qui envoie 500 tokens par jour et un autre qui en consomme 500 000 paient le même prix sur un plan fixe. C’est injuste pour le petit consommateur et non rentable pour le fournisseur face au gros consommateur. L’usage metering résout ce déséquilibre en facturant chaque client selon ce qu’il consomme réellement.

Les raisons d’adopter un metering précis vont au-delà de la facturation :

Alignement prix-valeur. Le client paie pour ce qu’il utilise. Plus il tire de valeur du produit, plus il paie. Moins il utilise, moins il paie. Cette transparence réduit le churn et facilite l’adoption initiale (pas de gros engagement dès le départ).

Expansion naturelle (net revenue retention). Quand l’usage d’un client augmente, le revenu augmente automatiquement sans intervention commerciale. Les modèles hybrides (abonnement + usage) affichent une croissance médiane d’environ 21 %, contre 13 % pour les modèles purement par abonnement.

Maîtrise des coûts infrastructure. Chaque token LLM consommé par un client génère un coût côté fournisseur (appel OpenAI, Anthropic, ou inférence sur GPU). Sans metering, impossible de savoir si un client est rentable ou s’il coûte plus qu’il ne rapporte.

Détection des anomalies. Un metering en temps réel détecte les boucles d’agents IA qui consomment des milliers de tokens sans fin, les intégrations défaillantes qui envoient des requêtes en boucle, ou les abus de clients qui exploitent un plan gratuit au-delà de sa vocation.

Architecture d’un système de metering

Un pipeline de metering en production se décompose en cinq étapes. La fiabilité de chaque étape est critique : un événement perdu, c’est du revenu perdu. Un événement compté deux fois, c’est une surfacturation et un client mécontent.

1. Capture des événements

Chaque action facturable génère un événement envoyé au pipeline de metering. L’événement est un objet structuré avec au minimum : un identifiant client (customer_id ou tenant_id), un timestamp, un type d’événement, et les données de consommation (nombre de tokens, durée en secondes, taille en octets).

// Événement de metering typique (format CloudEvents)
{
  "specversion": "1.0",
  "type": "ai.completion",
  "source": "/api/v1/chat/completions",
  "subject": "customer_abc123",
  "time": "2026-03-21T14:32:05.123Z",
  "data": {
    "model": "claude-sonnet-4",
    "input_tokens": 2450,
    "output_tokens": 680,
    "cached_tokens": 1200,
    "latency_ms": 1340,
    "status": "success"
  }
}

L’émission de l’événement doit être asynchrone et non bloquante. Si l’envoi au pipeline de metering échoue, la requête du client ne doit pas échouer. L’événement est mis en file d’attente locale et retransmis ultérieurement (pattern « fire and forget » avec retry).

2. Ingestion et buffering (Kafka)

Les événements sont publiés dans un broker de messages, typiquement Apache Kafka. Kafka sert de buffer entre l’application (qui produit des événements à un rythme imprévisible) et le pipeline de traitement (qui consomme à son propre rythme). Les avantages de Kafka pour le metering : débit très élevé (millions d’événements par seconde), durabilité (les événements sont persistés sur disque), rejouabilité (possibilité de relire les événements si un bug est détecté dans le traitement).

Les événements sont partitionnés par customer_id pour garantir l’ordre de traitement par client et faciliter le parallélisme.

3. Agrégation

Stocker chaque événement brut individuellement coûterait une fortune en stockage et rendrait les requêtes analytiques trop lentes. L’agrégation pré-calcule les métriques par client, par fenêtre de temps, et par dimension pertinente.

Deux approches dominent :

Agrégation en streaming. Un processeur de flux (Kafka Streams, Apache Flink, ou le consumer Go d’OpenMeter) agrège les événements en fenêtres glissantes (tumbling windows). OpenMeter, par exemple, pré-agrège les événements en fenêtres d’une minute. L’avantage : données disponibles quasi instantanément. L’inconvénient : complexité opérationnelle (gestion des watermarks, des événements tardifs, des fenêtres partielles).

Agrégation à l’écriture dans la base. ClickHouse offre une alternative élégante via ses Materialized Views et l’engine AggregatingMergeTree. Les événements sont écrits bruts dans ClickHouse, qui maintient automatiquement des vues agrégées. Mux (plateforme vidéo) a remplacé Apache Flink par ClickHouse pour son pipeline de metering, améliorant la fraîcheur des données de « plusieurs heures » à « quelques minutes » tout en simplifiant l’architecture.

4. Stockage (ClickHouse)

ClickHouse est devenu le standard de facto pour le stockage des données de metering. C’est une base de données colonne optimisée pour les requêtes analytiques sur de grands volumes. Les raisons de sa domination dans ce domaine : ingestion à très haut débit (des centaines de milliers d’écritures par seconde), requêtes analytiques en millisecondes sur des milliards de lignes, compression efficace (les données de metering compressent typiquement à 10-20 % de leur taille brute), et support natif de Kafka via le Kafka Table Engine.

-- Table de metering dans ClickHouse
CREATE TABLE usage_events (
    customer_id String,
    event_type LowCardinality(String),
    model LowCardinality(String),
    input_tokens UInt32,
    output_tokens UInt32,
    cached_tokens UInt32,
    timestamp DateTime64(3)
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(timestamp)
ORDER BY (customer_id, event_type, timestamp);

-- Vue matérialisée pour l'agrégation automatique
CREATE MATERIALIZED VIEW usage_hourly_mv
TO usage_hourly
AS SELECT
    customer_id,
    event_type,
    model,
    toStartOfHour(timestamp) AS hour,
    sum(input_tokens) AS total_input_tokens,
    sum(output_tokens) AS total_output_tokens,
    sum(cached_tokens) AS total_cached_tokens,
    count() AS request_count
FROM usage_events
GROUP BY customer_id, event_type, model, hour;

5. Rating et facturation

Le « rating » est la traduction des données de consommation agrégées en montants facturables selon les règles de pricing du client. Un client sur le plan « Standard » paie $0,003 par 1 000 tokens d’input. Un client enterprise avec un contrat négocié paie $0,002 avec un minimum mensuel de $5 000. Le rating engine applique les bonnes règles au bon client.

Les modèles de pricing courants que le rating doit gérer :

Usage metering pour les produits IA

Les produits IA ajoutent une couche de complexité au metering. Les unités de consommation sont multiples (tokens input, tokens output, tokens cachés, temps GPU, images générées), les coûts varient par modèle et par fournisseur, et les workflows agentiques enchaînent des dizaines d’appels pour une seule action utilisateur.

Mesurer les tokens

La métrique de base pour les LLM est le token. Mais tous les tokens ne se valent pas :

Input tokens vs output tokens. Les tokens d’output coûtent typiquement 3 à 5 fois plus cher que les tokens d’input chez les principaux fournisseurs. Votre metering doit distinguer les deux.

Tokens cachés. Les tokens servis depuis le cache du prompt coûtent beaucoup moins (jusqu’à 90 % de réduction chez Anthropic). Si vous refacturez vos clients sans cette distinction, vous surmargeez les requêtes cachées et sous-margez les requêtes froides.

Tokens de raisonnement. Les modèles avec « extended thinking » (Claude avec réflexion étendue, o1 d’OpenAI) génèrent des tokens internes de raisonnement. Selon le modèle et le fournisseur, ces tokens sont facturés ou non. Votre metering doit les capturer séparément pour une attribution de coûts précise.

Coûts variables par modèle

Un même produit IA peut router vers différents modèles selon la complexité de la requête. Une question simple passe par Claude Haiku ($0,80/M tokens input), une question complexe par Claude Sonnet ($3/M tokens input), et une tâche critique par Claude Opus ($15/M tokens input). Le metering doit capturer le modèle utilisé pour chaque requête, sinon l’attribution de coûts est impossible.

# Événement de metering enrichi avec le modèle
usage_event = {
    "customer_id": "cust_xyz",
    "timestamp": "2026-03-21T14:32:05Z",
    "model": "claude-sonnet-4-20250514",
    "provider": "anthropic",
    "input_tokens": 2450,
    "output_tokens": 680,
    "cached_input_tokens": 1200,
    "thinking_tokens": 0,
    "cost_input_usd": 0.00375,   # (2450-1200) * $3/M
    "cost_cached_usd": 0.00036,  # 1200 * $0.30/M
    "cost_output_usd": 0.01020,  # 680 * $15/M
    "total_cost_usd": 0.01431
}

Appliquer un markup

La plupart des produits SaaS qui utilisent des LLM en backend appliquent un markup sur le coût fournisseur : si le coût brut d’une requête est $0,015, le client final paie $0,015 × 1,3 = $0,0195 (markup de 30 %). Stripe Billing a ajouté en 2026 la possibilité de configurer automatiquement ce markup sur les coûts LLM, en suivant les prix des fournisseurs et en appliquant le pourcentage configuré à chaque facture.

Plateformes de metering et billing

Recommandation pragmatique : commencez par Stripe Billing si votre pricing est simple (pay-as-you-go ou abonnement + overage). Passez à Orb ou Lago quand vous avez besoin de pricing par paliers complexe, de crédits prépayés, ou de contrats enterprise négociés. OpenMeter se justifie si vous avez un volume d’événements très élevé (millions par seconde) et que vous voulez découpler le metering du billing.

Implémenter le metering : guide pratique

Définir les métriques facturables

Avant de coder quoi que ce soit, listez précisément ce que vous facturez. Pour un produit IA typique :

Pipeline minimal pour un MVP

Pour un produit IA en phase initiale, vous n’avez pas besoin de Kafka et ClickHouse. Un pipeline simple suffit :

# Pipeline de metering MVP (Python + PostgreSQL + Stripe)
import stripe
from datetime import datetime

stripe.api_key = "sk_xxx"

def record_usage(customer_id: str, input_tokens: int, output_tokens: int, model: str):
    """Enregistrer l'usage et l'envoyer à Stripe."""
    
    # 1. Calculer les unités facturables
    # Stripe meter en "unités" ; 1 unité = 1K tokens ici
    billable_units = (input_tokens + output_tokens) / 1000
    
    # 2. Envoyer à Stripe Billing (metered usage)
    stripe.billing.MeterEvent.create(
        event_name="ai_tokens",
        payload={
            "stripe_customer_id": get_stripe_id(customer_id),
            "value": str(int(billable_units)),
        },
        timestamp=int(datetime.now().timestamp()),
    )
    
    # 3. Logger en base locale pour l'analytics interne
    db.execute(
        "INSERT INTO usage_log (customer_id, model, input_tokens, "
        "output_tokens, created_at) VALUES (%s, %s, %s, %s, NOW())",
        (customer_id, model, input_tokens, output_tokens)
    )

Ce pipeline MVP fonctionne jusqu’à quelques milliers de clients et quelques millions d’événements par mois. Au-delà, migrez vers une architecture Kafka + ClickHouse avec un metering asynchrone.

Pipeline de production

À l’échelle, l’architecture cible suit le modèle utilisé par OpenMeter et les plateformes de metering matures :

Application (émetteur d'événements)
    │
    ▼
Kafka (ingestion, buffering, durabilité)
    │
    ▼
Consumer Go/Python (validation, déduplication, enrichissement)
    │
    ▼
ClickHouse (stockage + agrégation via Materialized Views)
    │
    ▼
Rating Engine (application des règles de pricing)
    │
    ▼
Plateforme de billing (Stripe, Orb, Lago) → Facture client

Les points critiques de ce pipeline :

Exactly-once processing. Un événement perdu = revenu perdu. Un événement dupliqué = surfacturation. Kafka offre des garanties « at-least-once » ; la déduplication se fait au niveau du consumer (via un identifiant unique par événement, typiquement stocké dans un set Redis ou directement dans ClickHouse via ReplacingMergeTree).

Idempotence. Si un événement est rejoué (après un crash du consumer, par exemple), le résultat final doit être identique. Chaque événement doit porter un identifiant unique (event_id) et le pipeline doit détecter et ignorer les doublons.

Latence acceptable. Pour l’affichage d’un compteur d’usage en temps réel dans le dashboard client, une latence de 1 à 5 minutes est acceptable. Pour l’enforcement (bloquer l’accès quand le quota est épuisé), la latence doit être inférieure à quelques secondes.

Éviter le « bill shock »

Le principal reproche des clients face au pricing à l’usage : la facture imprévisible. Un agent IA qui boucle, un batch mal configuré, ou simplement une croissance d’usage plus rapide que prévu peut générer une facture 10 fois supérieure aux attentes. C’est le « bill shock ».

Les mécanismes pour le prévenir :

Alertes de seuil. Envoyez une notification par email et in-app quand le client atteint 50 %, 80 %, et 100 % de son budget habituel ou d’un plafond configurable.

Plafonds de dépense (spending caps). Permettez au client de définir un plafond mensuel. Quand le plafond est atteint, le service est limité ou stoppé selon la configuration du client. C’est ce que font OpenAI et Anthropic avec leurs limites de dépense par tier.

Dashboards d’usage en temps réel. Le client doit pouvoir voir sa consommation à tout moment, avec une projection de la facture en fin de mois. Pas de surprise.

Crédits prépayés. Le client achète un bloc de crédits ($500) consommé au fil de l’usage. Quand le solde est bas, il recharge. Ce modèle élimine le bill shock par conception, car le client ne peut pas dépenser plus que ce qu’il a chargé.

Metering et entitlements (contrôle d’accès)

Le metering ne sert pas qu’à facturer. Il sert aussi à contrôler l’accès au produit en temps réel. Si un client a un plan « 100 000 tokens/mois » et qu’il a consommé 100 000 tokens, le système doit bloquer ou limiter ses requêtes suivantes. C’est la notion d’entitlements (droits d’accès).

La distinction entre metering pour le billing (tolérance à la latence, réconciliation en fin de mois) et metering pour les entitlements (temps réel strict, blocage immédiat) est importante. Les deux peuvent partager le même pipeline de capture d’événements, mais le chemin de vérification des entitlements doit être beaucoup plus rapide, typiquement via un compteur Redis interrogé à chaque requête API, plutôt que via une requête analytique dans ClickHouse.

Bonnes pratiques

Séparez le metering du billing. Le metering capture et agrège les données de consommation. Le billing applique les règles de pricing et génère les factures. En les découplant, vous pouvez changer votre pricing sans toucher au pipeline de metering, et inversement.

Utilisez le format CloudEvents. Le standard CloudEvents (CNCF) fournit une structure commune pour les événements de metering : specversion, type, source, subject, time, data. L’adoption de ce standard facilite l’interopérabilité avec les plateformes de metering tierces (OpenMeter l’utilise nativement).

Stockez les événements bruts. Même si vous agrégez pour la facturation, conservez les événements bruts pendant au moins 90 jours. Ils sont indispensables pour le debugging, les audits, les contestations de factures, et le recalcul en cas de bug dans l’agrégation.

Testez la facturation avant le lancement. Simulez un mois de facturation avec des données réelles avant de facturer un seul client. Comparez la facture simulée avec le coût réel côté fournisseur. Si les chiffres ne collent pas, il y a un bug dans le pipeline.

Documentez votre unité de facturation. « Tokens » ne suffit pas. Précisez : 1K tokens d’input au prix X, 1K tokens d’output au prix Y, tokens de raisonnement inclus ou non, tokens cachés facturés au tarif réduit Z. La transparence prévient les litiges.