Les tokens sont la mauvaise unité
Plaidoyer pour un pricing par conversation

Imagine que tu entres dans un resto et que la carte liste les prix au gramme de bouffe. Pas au plat. Pas à la portion. Au gramme.

Tu ne sais pas combien pèse un steak. Tu ne sais pas combien la sauce ajoute. Le serveur ne peut pas te dire combien le dîner coûtera avant que tu aies mangé, quand il pèse tes restes et fait la soustraction.

C'est à ça que ressemble le pricing LLM. Les tokens sont des grammes. Tu es le client. Et la facture est toujours une surprise.

Le problème d'unité

Chaque provider LLM majeur facture au token : 3 $ par million de tokens input, 15 $ par million de tokens output, surcharges variables sur les reasoning tokens. C'est comme ça que marche l'API, donc c'est comme ça que marche le pricing.

Le problème c'est que personne qui build une app ne se soucie des tokens. Ce qui les intéresse :

• Combien coûte une conversation ?
• Combien coûte un utilisateur par mois ?
• Combien coûte faire tourner mon produit par transaction ?

Convertir le pricing au token en ces réponses demande des maths qui dépendent de :

• La forme exacte de tes prompts (apps différentes = shapes per-token radicalement différentes)
• Ton taux de cache hit (qui varie chaque semaine selon les changements de prompt)
• Ton taux de retry (qui varie selon la santé du provider)
• Tes patterns de tool use (qui gonflent les token counts de façon non linéaire)
• Ton usage d'extended thinking (tokens de raisonnement invisibles que tu payes quand même)

Aucun de ces éléments n'est prédictible à l'inscription. Tu les découvres sur des mois de trafic prod. Au moment où tu peux répondre à "combien coûte une conversation ?", tu as déjà payé pour la réponse.

Pourquoi les tokens persistent comme unité

La raison honnête : c'est pratique pour le provider.

Les tokens sont comment le modèle traite le texte. Les tokens sont ce que les GPU facturent en compute. Du point de vue d'Anthropic ou d'OpenAI, facturer au token est l'abstraction naturelle. Ils te repassent leur unité d'entrée brute.

Mais les unités d'entrée brutes sont rarement la bonne unité de pricing pour un client. Les fournisseurs d'électricité ne facturent pas au nombre d'électrons. Les providers cloud facturent à l'instance-heure, pas au cycle CPU. Stripe facture par transaction, pas par byte de requête API. Dans chaque cas, l'industrie a mûri vers une unité qui correspond à la valeur client, pas aux opérations internes du provider.

Le pricing LLM est coincé au stade "nombre d'électrons". Ça va mûrir. La question c'est de savoir si les clients attendent ou poussent.

À quoi ressemblerait un pricing par conversation

Imagine à la place : "0,04 $ par conversation complétée, pour du trafic typique de support client".

D'un coup :

• Tu peux budgéter. 10 000 conversations × 0,04 $ = 400 $. Fini.
• Tu peux comparer les providers sur des unités apples-to-apples.
• Tu peux construire le pricing de ton propre produit par-dessus (facture ton client par conversation, avec la marge que tu veux).
• Tu peux détecter les anomalies. Si une conversation coûte soudain 0,40 $, quelque chose ne va pas avec cette conversation, et tu le vois immédiatement.

"Ah," diras-tu, "mais les conversations varient sauvagement, un chat de trois tours coûte différemment d'un chat de 30 tours". Exact. Donc tu tires. Le playbook SaaS pour ça a trente ans :

• Conversation simple (0,02 $) : <4 tours, <5K tokens total
• Standard (0,05 $) : <10 tours, <20K tokens
• Complexe (0,15 $) : <30 tours, <80K tokens
• Entreprise (0,50 $) : au-delà

Stripe ne te facture pas au byte. Stripe classifie les transactions par type et tarife en conséquence. C'est réglé.

Les objections

Quand je parle de ça avec des founders techniques, trois objections reviennent :

"Les conversations ont des coûts sauvagement différents." Oui, et c'est pour ça que tu as des tiers. Stripe facture un taux différent sur cartes internationales vs domestiques. AWS facture un taux différent sur instances compute-optimized vs general-purpose. La variabilité est la feature, pas un bug.

"Le pricing au token est plus transparent." Celle-là est à l'envers. Le pricing au token est transparent pour le provider, pas pour toi. Tu peux voir exactement combien de tokens le provider a traité, mais tu ne peux pas facilement traduire ça en "combien cette session utilisateur a coûté". Le pricing par conversation est opaque au niveau token mais transparent au niveau qui t'intéresse vraiment.

"Mon app est un edge case bizarre et ne rentrerait pas dans les tiers." Peut-être. Alors négocie un tier custom. Chaque vendor d'infra a des deals enterprise pour workloads inhabituels. C'est normal.

Où ça arrive déjà

Quelques providers avancent vers ce modèle. Replicate facture par génération pour les modèles image. Perplexity a du pricing API tiré pour les requêtes de recherche. Certains produits récents d'assistance code (Cursor, Aider) tarifent effectivement par session, en bundlant le compute en-dessous.

Le pattern est toujours : l'API commodité facture à l'unité brute, la couche au-dessus facture à l'unité signifiante pour le client. C'est pour ça que la couche infra existe.

L'angle BYOK

C'est aussi pour ça que BYOK + infra à fee fixe est un si bon match. Le provider te facture toujours au token (parce que c'est son modèle). Mais ton middleware peut abstraire ça en fee par conversation ou par seat qui a vraiment du sens pour ton produit.

Ta couche infra prend la charge de la prédiction. Elle dit : "la plupart de tes conversations rentrent dans le tier B, qu'on facturera 0,05 $ chacune. On mange la variance ; tu as la prédictibilité". C'est un vrai service. C'est ce qu'un abonnement à fee fixe t'achète.

Les providers n'offriront jamais ça eux-mêmes parce que prédire un coût variable par conversation contre leur propre revenu variable par token est un hedge qu'ils ne peuvent pas prendre. Seule une couche au-dessus peut.

Le futur

Je parie que dans trois ans, les APIs LLM sérieuses offriront du pricing par conversation ou par session comme option principale, avec le per-token en fallback pour les utilisateurs batch/pipeline. Les couches infra l'offriront de plus en plus par défaut. Le modèle de facturation grammes-de-bouffe paraîtra aussi primitif en 2030 que le longue-distance à la minute paraît en 2026.

En attendant, l'unité qui t'intéresse, conversations, utilisateurs, sessions, doit être reconstituée à partir de l'unité sur laquelle tu es facturé. Cette reconstitution est un boulot à plein temps, et c'est le boulot qu'une couche d'infra BYOK fait pour toi.

Les tokens sont l'unité du provider. Les conversations sont la tienne. Tant que le pricing ne converge pas vers l'unité client, tu as besoin d'une couche qui fait la conversion.

---

À lire aussi : Les maths cachées du pricing LLM montre pourquoi la conversion coût-par-token vers coût-par-conversation est plus dure qu'elle n'en a l'air.