Votre facture d'API LLM a triplé : d'où vient l'argent et comment le récupérer

---

title: "Votre facture d'API LLM a triplé : d'où vient l'argent et comment le récupérer" seoTitle: "Facture API LLM : reprendre le contrôle des coûts" description: "Un POC IA à 40 € par mois devient une facture à 6 000 € en production. Où part réellement l'argent, comment le mesurer, et six leviers pour diviser le coût." date: "2026-09-08" author: "Équipe Raicode" tags: ["IA", "automatisation", "coûts", "architecture"] category: "IA & Automatisation" keywords: ["coût API LLM", "réduire coûts OpenAI", "cache de prompt", "tokens en production", "FinOps IA", "optimisation LLM", "coût par requête", "RAG coût", "routage de modèles"]

La facture arrive en général au troisième mois. Le POC tournait à 40 € par mois, tout le monde a validé, la fonctionnalité est passée en production, et voilà 6 200 € sur le relevé — pour un usage que personne ne trouve excessif. Le réflexe classique est de demander au fournisseur une remise ou de chercher un modèle moins cher. Dans la quasi-totalité des cas que nous reprenons, ce n'est pas le bon levier : le problème n'est pas le prix du token, c'est le nombre de tokens que l'application consomme sans que personne ne l'ait décidé.

Cet article décrit ce qui se passe réellement entre le POC et la production, comment instrumenter le coût avant de l'optimiser, et les six leviers qui donnent des résultats — classés par rapport entre le gain et l'effort. Il s'adresse à une équipe qui a déjà une fonctionnalité LLM en ligne et qui découvre sa facture, pas à quelqu'un qui envisage d'en construire une.

Pourquoi le POC ne prédit jamais la facture

Le POC ment sur trois dimensions à la fois, et ces erreurs se multiplient entre elles.

Le volume. C'est la seule que tout le monde anticipe, et généralement mal. On teste avec 200 requêtes par jour en interne, la production en fait 4 000. Facteur 20.

La taille du contexte. En test, on envoie un prompt système de 300 tokens et une question de 50 tokens. En production, le prompt système a grossi — on y a ajouté les règles métier, le ton, les cas particuliers, quelques exemples — et il pèse 2 800 tokens. Le contexte récupéré par le RAG ajoute 4 000 tokens. L'historique de conversation en ajoute 3 000 au cinquième tour. On est passé de 350 à 10 000 tokens d'entrée. Facteur 28.

Le nombre d'appels par interaction. Le POC faisait un appel par question. La version production en fait quatre : une reformulation de la requête, un appel de récupération, la génération, puis une passe de vérification qu'on a ajoutée le jour où un client a reçu une réponse fausse. Facteur 4.

Multipliez : 20 × 28 × 4 = 2 240. Un POC à 40 € par mois arrive à 89 000 € par mois à ce régime. Dans la vraie vie les facteurs sont plus modestes et se compensent partiellement, mais l'ordre de grandeur explique pourquoi une facture est passée de 40 € à 6 200 € sans que le trafic n'ait été multiplié par 155.

Le calcul que personne n'a fait

Avant toute optimisation, il faut un chiffre : le coût unitaire d'une interaction métier. Pas le coût par token, pas le coût mensuel — le coût d'une réponse de chatbot, d'un résumé de ticket, d'une extraction de facture.

Le calcul tient en une ligne. Pour un modèle facturé, disons, 3 € par million de tokens d'entrée et 15 € par million de tokens de sortie — les ordres de grandeur des modèles haut de gamme actuels, à vérifier chez votre fournisseur au moment où vous lisez — une interaction à 10 000 tokens d'entrée et 600 de sortie coûte :

(10 000 / 1 000 000) × 3 €  = 0,030 €
(600 / 1 000 000) × 15 €    = 0,009 €
                    total   = 0,039 € par interaction

Quatre appels par interaction, et on est à environ 0,13 €. À 4 000 interactions par jour, cela fait 15 600 € par an. Ce chiffre-là, un comité de direction sait le lire. « On consomme beaucoup de tokens », non.

Notez au passage l'asymétrie : la sortie coûte cinq fois l'entrée au token, mais l'entrée représente ici 77 % de la dépense parce qu'elle est vingt fois plus volumineuse. C'est presque toujours le cas dans les applications RAG et agentiques, et c'est la raison pour laquelle « demander des réponses plus courtes » ne règle rien.

Les cinq postes qui font gonfler la facture

Le contexte renvoyé intégralement à chaque tour

Une conversation multi-tours renvoie tout l'historique à chaque appel : c'est le fonctionnement normal d'une API sans état. Une conversation de dix tours ne coûte donc pas dix fois un tour, elle en coûte environ cinquante-cinq — la somme des dix premiers entiers. C'est le poste le plus sous-estimé de tous, et il est purement quadratique.

Le RAG qui récupère beaucoup trop

Le réglage par défaut de la plupart des implémentations récupère les 10 ou 20 meilleurs passages et les injecte tels quels. Nous mesurons systématiquement la même chose lors des audits : au-delà du cinquième passage, la qualité de la réponse ne bouge plus, mais le coût continue de monter linéairement. Passer de 20 à 5 passages retire souvent 5 000 tokens d'entrée par appel sans dégrader quoi que ce soit — ce qui se vérifie en une demi-journée avec un jeu d'évaluation.

Les retries invisibles

Un timeout, une réponse JSON malformée, un 429 — et le client HTTP retente. Trois tentatives configurées par défaut dans la bibliothèque, une génération longue qui échoue à 90 % de sa complétion : vous payez trois générations pour une réponse. Ces appels n'apparaissent nulle part dans les logs applicatifs mais figurent bien sur la facture. Sur un projet repris l'an dernier, les retries représentaient 22 % de la dépense mensuelle et personne ne le savait.

Un seul modèle pour toutes les tâches

Le même modèle haut de gamme sert à classifier un ticket en trois catégories, à extraire une date, et à rédiger une synthèse de dix paragraphes. La première tâche est faite correctement par un modèle dix à trente fois moins cher. Ce n'est pas un débat de qualité, c'est un débat d'adéquation.

Les boucles d'agent sans plafond

Un agent qui appelle des outils tourne jusqu'à ce qu'il estime avoir terminé. Sans limite dure d'itérations et de budget, une requête ambiguë peut tourner quinze fois avant d'abandonner. Le coût médian reste raisonnable, la queue de distribution est ruineuse : sur un système que nous avons repris, 3 % des requêtes consommaient 40 % du budget. C'est aussi le mécanisme qui rend les agents difficiles à exposer à des clients, un sujet que nous avions abordé sous l'angle de la fiabilité dans notre article sur les chatbots et l'IA conversationnelle.

Instrumenter avant de toucher au code

Aucune de ces optimisations ne se pilote sans mesure. Le minimum vital tient en une table.

Chaque appel au modèle écrit une ligne : identifiant de trace, fonctionnalité appelante, modèle, tokens d'entrée, tokens en cache, tokens de sortie, latence, statut, coût calculé. Le champ feature est le plus important de tous : c'est lui qui permet de dire « la synthèse de tickets coûte 4 100 € et le chatbot 900 € », donc de savoir où chercher. Sans cette colonne, vous avez une facture globale et aucune décision possible.

Trois vues suffisent ensuite :

| Vue | Ce qu'elle révèle | | --- | --- | | Coût par fonctionnalité et par jour | Quelle fonctionnalité paie réellement, et depuis quel déploiement | | Distribution du coût par requête (p50 / p95 / p99) | La queue coûteuse que la moyenne dissimule | | Part des appels en échec ou retentés | Le budget dépensé pour rien |

Comptez une journée de développement. C'est le meilleur investissement du chantier : sans ces vues, chaque optimisation suivante est un pari, et vous ne saurez pas si elle a marché.

Les six leviers, par rapport gain/effort

1. Le cache de prompt — gain immédiat, effort minimal

Tous les grands fournisseurs facturent les portions de prompt déjà vues à une fraction du prix (souvent autour d'un dixième du tarif d'entrée). La condition est structurelle : le préfixe doit être strictement identique d'un appel à l'autre, octet pour octet.

D'où la règle d'ordonnancement du prompt : ce qui est stable en premier (instructions système, définitions d'outils, documents de référence), ce qui varie en dernier (question de l'utilisateur, horodatage, nom du client). L'erreur la plus courante consiste à injecter la date du jour ou l'identifiant de session en tête de prompt système : le préfixe change à chaque appel, et le cache ne se déclenche jamais. Un simple réordonnancement fait souvent 40 à 60 % de baisse sur un chatbot à prompt système lourd, pour une demi-journée de travail.

2. Plafonner l'historique — gain fort, effort faible

Fixez une fenêtre : les six derniers tours en clair, et un résumé compact des précédents régénéré tous les cinq tours. Le coût redevient linéaire au lieu de quadratique. Sur des conversations longues, c'est le levier le plus rentable après le cache.

3. Le routage par difficulté — gain fort, effort moyen

Un classifieur en amont — souvent un petit modèle, parfois de simples règles — envoie les demandes triviales vers un modèle économique et ne réserve le modèle haut de gamme qu'aux cas qui le justifient. La répartition typique que nous observons est de 70 / 30, pour une baisse de facture de 50 à 65 %.

La condition non négociable : un jeu d'évaluation d'au moins 100 cas réels, avec la réponse attendue, exécuté avant et après. Sans lui, le routage est une dégradation de qualité déguisée en économie — et vous la découvrirez par une réclamation client, pas par un tableau de bord.

4. Discipliner la récupération — gain moyen, effort faible

Réduisez le nombre de passages, ajoutez un reranker, tronquez chaque passage à ce qui est utile. Mesurez la qualité à chaque cran : cinq passages rerankés battent presque toujours vingt passages bruts, en pertinence comme en coût.

5. Budgets et disjoncteurs — gain sur la queue, effort faible

Un plafond dur par requête (nombre d'itérations, tokens cumulés, temps) et un plafond quotidien par fonctionnalité. Au-delà, on dégrade proprement : réponse partielle, escalade vers un humain, message d'attente. Ce n'est pas une optimisation de coût moyen, c'est une assurance contre la facture d'un incident — le genre de garde-fou qui manque dans la plupart des projets IA repris après coup, au même titre que les erreurs d'architecture décrites dans notre article sur les erreurs coûteuses en développement SaaS.

6. Le traitement par lots — gain fort, mais seulement hors ligne

Les API de batch offrent typiquement 50 % de remise contre une latence de plusieurs heures. Inutilisable pour un chat, excellent pour tout ce qui est asynchrone : enrichissement de catalogue, classification nocturne, réindexation, génération de résumés. Beaucoup d'équipes paient le tarif temps réel pour des traitements que personne n'attend.

Ce qu'il ne faut pas faire tout de suite

Le fine-tuning pour économiser. Il réduit la longueur du prompt, donc le coût unitaire, mais ajoute un coût d'entraînement, un tarif d'inférence souvent supérieur, et surtout un cycle de mise à jour à chaque évolution métier. Cela devient rentable à très fort volume et sur une tâche stable. Avant d'y songer, appliquez les leviers 1 à 6 : ils coûtent quelques jours et ne créent aucune dette.

L'auto-hébergement d'un modèle ouvert. Le calcul par token est séduisant jusqu'à ce qu'on intègre les GPU réservés vingt-quatre heures sur vingt-quatre, la charge d'exploitation et le temps d'ingénierie. Le seuil de bascule se situe généralement au-delà de plusieurs dizaines de milliers d'euros mensuels d'API. En dessous, vous remplacez une facture visible par un coût humain invisible et plus élevé. Les critères de cet arbitrage ressemblent d'ailleurs beaucoup à ceux que nous détaillons pour le choix entre SaaS et développement sur mesure.

Baisser la qualité en silence. Passer tout le trafic sur un modèle économique sans évaluation fait chuter la facture et monter le taux d'escalade vers le support. Le coût se déplace, il ne disparaît pas.

Poser un budget qui tient

Une fois la facture redescendue, verrouillez-la. Trois éléments suffisent :

• Une cible de coût unitaire par fonctionnalité, exprimée en euros par interaction, décidée avec le métier. « Un résumé de ticket ne doit pas dépasser 0,02 € » est un objectif d'ingénierie exploitable.
• Une alerte sur la dérive, pas sur le total mensuel. Le coût unitaire moyen sur sept jours glissants qui dépasse la cible de 20 % doit déclencher une notification. C'est ce qui attrape le prompt système qu'un développeur a doublé en corrigeant un bug.
• Une revue du coût unitaire dans la définition de terminé de toute évolution touchant un prompt, une récupération ou une chaîne d'appels.

Les équipes qui tiennent leur budget dans la durée sont celles qui traitent le coût par interaction comme une métrique produit, au même titre que la latence ou le taux d'erreur — pas comme une ligne comptable qu'on découvre le 5 du mois.

Par où commencer lundi matin

Dans l'ordre, et sans sauter d'étape : instrumentez le coût par appel avec un champ feature (un jour) ; sortez la distribution p50 / p95 / p99 et la part de retries (une heure, une fois l'instrumentation en place) ; réordonnez vos prompts pour activer le cache (une demi-journée) ; plafonnez l'historique de conversation et le nombre de passages RAG (un jour) ; posez les budgets par requête (un jour). Cinq jours de travail au total, et une baisse de 50 à 70 % dans la plupart des cas — avant même d'avoir touché au choix des modèles.

Le routage par difficulté vient ensuite, une fois le jeu d'évaluation constitué. C'est le levier le plus puissant, et le seul qui puisse dégrader la qualité si vous l'appliquez à l'aveugle.

Si vous voulez creuser l'amont — comment une intégration LLM devrait être structurée dès le départ pour éviter cette situation — notre guide d'intégration de l'IA dans une application web couvre les fondations techniques.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.