Combien coûtent les tokens : calculer les dépenses API OpenAI, Claude et Gemini

La facture API surprend souvent plus que le tarif affiché : le modèle facture chaque token d’entrée et de sortie, pas « une requête ». Ci-dessous - comment fonctionne le billing OpenAI, Claude et Gemini, comment estimer le budget mensuel, et où les entreprises paient trop.

• Token - unité de tarification : environ 3-4 caractères ou une partie de mot
• L’input gagne en volume ; l’output est plus cher par 1M - un long contexte frappe plus fort qu’une réponse courte
• Formule - (input_tokens / 1M) × prix_input + (output_tokens / 1M) × prix_output
• Repères juillet 2026 - GPT-5.6 Luna/Terra/Sol, Claude Sonnet 5 / Opus 4.8 / Fable 5, Gemini 3.5 Flash / 3.1 Pro
• Coûts cachés - system prompt, historique du chat, chunks RAG, retries, tool calls
• Économies - petit modèle pour la routine, caching/batch, contexte allégé, escalade vers le flagship seulement sur les cas difficiles

Qu’est-ce qu’un token - et pourquoi ce n’est pas un « mot »

Un token est un fragment de texte après la tokenisation du modèle. Ce n’est pas forcément un mot entier : « programmation » peut devenir 2-3 tokens ; espaces et ponctuation comptent aussi. Pour estimer le volume :

Le découpage exact dépend du tokenizer du fournisseur - pour le billing, utilisez usage dans la réponse API, pas une estimation au feeling. Pour la limite d’une requête : fenêtre de contexte.

Comment le prix API est calculé

Les trois vendors partagent le même schéma :

1. Compter les input tokens (system + user + historique + pièces/chunks).
2. Compter les output tokens (réponse ; parfois reasoning/thinking à part).
3. Le tarif est par 1 million de tokens (1M), séparé pour input et output.
4. Coût par appel :

cost = (input_tokens / 1_000_000) × price_input
     + (output_tokens / 1_000_000) × price_output

Nuances importantes :

• L’output est presque toujours plus cher par 1M - souvent 4-6× - réponses longues et « raisonnements » gonflent la facture.
• Contexte long coûte plus au-delà d’un seuil sur certains modèles (OpenAI GPT-5.6 au-dessus de 272K ; Gemini 3.1 Pro au-dessus de 200K).
• Batch API et prompt caching baissent le prix sur un contexte system/RAG répété - si l’architecture le permet.
• Les seats ChatGPT / Claude / Gemini Workspace sont une autre ligne de coûts - ne les confondez pas avec l’API au token. Comparaison : ChatGPT vs Claude vs Gemini.

Tarifs juillet 2026 : bases de calcul

Les prix changent - vérifiez la liste officielle avant la production. Ci-dessous - repères issus du tour d’horizon des modèles juillet 2026 (USD pour 1M de tokens, standard).

OpenAI (GPT-5.6)

Au-delà de 272K d’input, GPT-5.6 applique un tarif long-context (repère : input ×2, output ×1.5).

Anthropic (Claude)

À partir du 01.09.2026, Claude Sonnet 5 : $3.00 / $15.00 pour 1M.

Google (Gemini)

Gemini 3.1 Pro au-delà de 200K tokens - tarif majoré (repère : $4.00 / $18.00 pour 1M).

Exemples de calcul

Exemple 1. Réponse support : dialogue court

Par ticket :

• input : 1 200 tokens (instruction + question + 2 tours d’historique) ;
• output : 400 tokens ;
• volume : 50 000 tickets / mois.

En support L1, le flagship ne s’amortit presque jamais : qualité du retrieval et droit de dire « je ne sais pas » battent le top benchmark.

Exemple 2. Synthèse de contrat avec gros contexte

Par document :

• input : 80 000 tokens (PDF + system) ;
• output : 2 000 tokens ;
• volume : 2 000 documents / mois.

Ici, la ligne dominante est l’input. Moins cher n’est pas « répondre plus court », mais ne pas envoyer tout le PDF si des chunks RAG pertinents suffisent.

Exemple 3. Agent avec tools : le multiplicateur caché

Une « requête utilisateur » d’agent fait souvent 5-20 appels modèle (plan → tool → observation → plan). Si chaque étape porte le système + l’historique complets :

coût_agent ≈ coût_d_un_appel × nombre_d_étapes

10 étapes à 8K input / 500 output sur Terra, ce n’est plus « un chat pour quelques centimes », mais de vrais dollars par cas difficile. Budgétez les traces d’agent, pas les messages UI.

Où l’on paie trop

1. Un seul flagship pour tout. Sol / Fable 5 pour classer les mails et la FAQ - fuite budgétaire classique.
2. System prompt lourd + historique complet à chaque appel. Contexte répété sans caching multiplie l’input.
3. RAG sans limite de chunks. Dix morceaux « au cas où » coûtent plus que deux pertinents - et la qualité baisse.
4. Retries et fallback non comptés. Timeout → retry → second modèle = double facture pour un clic.
5. Output long « au cas où ». max_tokens élevé + prompt flou = le modèle écrit un roman.
6. Confusion seat vs API. L’abonnement Team n’annule pas la facture tokens du produit, des bots et des automatisations.
7. Tarifs long-context ignorés. Au-delà de 200K/272K, le tarif saute tandis que le dashboard montre encore un prix « moyen ».

Comment calculer le budget mensuel

Modèle pratique pour la finance et le CTO :

1. Découpez le trafic en scénarios (chat support, synthèse, agent, embeddings à part).
2. Pour chaque scénario, prenez la médiane input/output des logs (pas la démo idéale).
3. Multipliez par le volume mensuel de requêtes / étapes d’agent.
4. Ajoutez une marge de 20-40% pour retries, pics et expériences.
5. Prévoyez le changement de modèle : pilote sur le moins cher + escalade par règles.

Mini-tableau de planning :

Sans ce tableau, choisir « le modèle le plus intelligent » est une loterie, pas de la finance.

Comment baisser les coûts sans perdre en qualité

• Routage de modèles. Classification et brouillons - Luna / Flash / Sonnet ; code dur et chaînes agentiques longues - Sol / Fable 5.
• Ingénierie du contexte. Coupez l’historique, system court, pas de doublons d’instructions. Voir ingénierie du contexte.
• RAG plutôt que « tout dans le prompt ». Moins d’input - facture plus basse et moins de risque d’hallucinations à cause du bruit.
• Prompt caching et batch. Instructions répétées et jobs de nuit sont souvent moins chers que le realtime.
• Plafond dur d’output. Structured output (JSON) plutôt que des essais ; limite de longueur explicite.
• Escalader, pas défaut flagship. D’abord le modèle bon marché ; le cher si confiance faible ou tâche difficile.
• Observabilité. Loggez usage par feature/tenant : sinon, rien à optimiser.

Quand l’optimisation des tokens ne vaut pas l’effort

• Faible volume de requêtes. Si la facture API représente quelques dollars par mois, pas un poste de coût significatif, le temps de l’équipe passé sur le routage de modèles et le caching coûtera plus cher que l’économie réalisée.
• Phase pilote ou MVP. Tant que le produit n’a pas prouvé la demande, la vitesse d’itération compte plus que le coût exact par token - optimisez une fois le trafic stabilisé.
• Personne pour maintenir le dispositif. Le routage de modèles, le RAG et les limites de chunks demandent quelqu’un qui surveille les logs usage et les règles d’escalade - sans cela, un dispositif complexe finit par coûter plus cher et moins bien fonctionner qu’un seul modèle flagship.
• Le coût d’une erreur dépasse celui d’un token. Pour des réponses juridiques, médicales ou financières, ne basculez pas vers un modèle moins cher pour gagner quelques pourcents - la qualité et la prévisibilité comptent davantage ici.

En résumé

Le coût des tokens n’est pas « le prix du modèle sur la grille », mais volume d’input × tarif + volume d’output × tarif × nombre d’appels. En 2026, un stack sensé ressemble souvent à : modèle rapide et bon marché pour le flux, mid-tier pour les documents de travail, flagship seulement ponctuellement. Calculez sur des scénarios issus des logs réels, incluez chaînes agentiques et retries - l’API cesse alors d’être une surprise de fin de mois.

Si vous avez besoin d'aide pour le développement, l'intégration de l'IA ou la maintenance de site pour votre projet - contactez-moi.

Foire aux questions

En quoi le prix des tokens input diffère-t-il de l’output ?

L’output est presque toujours plus cher par 1M, parfois 4-6×. Mais la facture finale est souvent gonflée par l’input : longs documents, historique et chunks RAG. Regardez les deux parties de usage, pas seulement « combien le modèle a écrit ».

Combien de tokens dans un message utilisateur moyen ?

Une question courte en français fait souvent 30-120 tokens. Avec system prompt, politiques et 10 tours d’historique, un « chat » devient facilement 1 000-5 000+ d’input avant la réponse. Pour le budget, mesurez la requête complète, pas seulement la phrase client.

Quoi choisir pour un fort trafic : Gemini Flash, GPT Luna ou Claude Sonnet ?

Pour classification de masse, FAQ et réponses courtes, Gemini 3.5 Flash et GPT-5.6 Luna gagnent souvent. Claude Sonnet 5 s’impose quand style, instructions et soin du texte comptent à un prix encore modéré. Validez en A/B sur votre dataset, pas seulement avec le tableau de prix.

Faut-il toujours prendre le modèle le plus cher « au cas où » ?

Non. Un modèle cher s’amortit sur les tâches difficiles : long code, chaînes agentiques, exigences strictes de raisonnement. Sur un flux de requêtes similaires, le surcoût est gaspillé - mieux vaut routage et escalade par règles.

Comment estimer la facture mensuelle sans logs ?

Prenez 20-50 prompts réels, passez-les par l’API, capturez usage, moyennez input/output, multipliez par le volume prévu et ajoutez 30% pour retries et croissance. Après 1-2 semaines, remplacez l’estimation par les médianes de production - l’erreur chute souvent de plusieurs fois.

Termes de l'article

system prompt — hidden instructions that steer the model for a task — instructions cachées qui orientent le comportement du modèle

chunks — small text pieces indexed for retrieval — petits fragments de texte indexés pour le retrieval

RAG — Retrieval-Augmented Generation — génération augmentée par récupération

tokenizer — splits text into model tokens

prompt caching — reuse of a cached prompt prefix to cut cost and latency — réutiliser un préfixe de prompt en cache: moins cher et plus rapide

production — live environment serving real users — environnement live avec de vrais utilisateurs

long-context — model that can take a very large prompt in one go — modèle qui accepte un très long prompt d'un coup

retrieval — finding relevant context before generation — recherche de contexte pertinent avant génération

fallback — backup path used when the primary option fails — voie de secours si l'option principale échoue

timeout — max wait before aborting

retry — automatic repeat of a failed request or job — répétition automatique d'une requête ou tâche échouée

dashboard — metrics/status panel

structured output — model response forced into a fixed schema (JSON etc.) — réponse du modèle forcée dans un schéma fixe (JSON…)

tenant — isolated customer account in a shared platform — client isolé sur une plateforme partagée

MVP — Minimum Viable Product — produit minimum viable