Le coût des jetons n’est qu’une ligne sur sept dans le coût total de possession d’une fonctionnalité LLM. Un compte complet inclut les jetons d’entrée et de sortie, les nouvelles tentatives, la recherche et les embeddings, une couche d’évaluation, la supervision, le contrôle humain et l’infrastructure. Le tarif public de l’API explique généralement moins de la moitié de ce que la fonctionnalité coûte réellement en production, et c’est pourquoi les marges brutes SaaS traditionnelles de 80 à 90 % se compriment à 50-60 % dès que des appels de modèle entrent dans le produit. La bonne question n’est pas ce que coûte un million de jetons, mais ce que coûte une unité de travail qu’un client acceptera de payer.
Les sept lignes de coût d’une fonctionnalité adossée à un modèle
La plupart des équipes tarifent une fonctionnalité IA directement sur la grille du fournisseur : tant de dollars par million de jetons d’entrée, tant pour la sortie. C’est une ligne. La production en fait apparaître six autres, dont plusieurs sont fixes plutôt que liées au volume, ce qui les rend d’autant plus lourdes au démarrage.
| Ligne de coût | Ce qu’elle couvre | Comportement |
|---|---|---|
| Jetons d’entrée et de sortie | Le prompt, le contexte récupéré et la réponse du modèle | Variable, linéaire avec le volume |
| Nouvelles tentatives et échecs | Délais dépassés, limites de débit, sorties rejetées par la validation et renvoyées | Variable, avec des pics sous charge |
| Recherche et embeddings | Génération des embeddings, stockage vectoriel, requêtes de recherche, réindexation | Mixte : indexation fixe, interrogation variable |
| Couche d’évaluation | Jeux de tests, exécutions d’évaluation avant chaque changement de prompt ou de modèle | Fixe par cycle de développement |
| Supervision et journalisation | Capture des entrées et des sorties, métriques de qualité, alertes, rétention | Fixe avec une composante volumétrique |
| Contrôle humain | Revue par échantillon, traitement des escalades, étiquetage des cas limites | Variable en heures-personne |
| Infrastructure et intégration | Couche d’abstraction fournisseur, files d’attente, cache, sécurité et permissions | Fixe, se dilue à mesure que vous grandissez |
Pourquoi le prix affiché des jetons induit en erreur
Trois écarts systématiques séparent la grille tarifaire de la facture.
La sortie coûte bien plus cher que l’entrée. Chez la plupart des fournisseurs, un jeton de sortie est facturé cinq à huit fois un jeton d’entrée. Une fonctionnalité qui génère de longues réponses paie cette longueur deux fois, ce qui fait du plafonnement de la longueur de sortie l’économie la moins chère disponible n’importe quel jour.
Le contexte grossit sans bruit. Dès que la recherche entre en jeu, chaque appel transporte des fragments de documents, l’historique de conversation et les instructions système. Un prompt qui tient en trois lignes dans le code représente plusieurs milliers de jetons en vol, et cet écart se multiplie sur chaque appel.
Les nouvelles tentatives ne figurent jamais dans le plan. Un appel qui échoue à la validation, au formatage ou par dépassement de délai est renvoyé et facturé deux fois. Sous charge réelle, le taux de réessai est généralement l’écart entre la prévision et la facture.
La formule : le coût par unité de travail
Au lieu de suivre la consommation totale de jetons, définissez une unité de travail qui a un sens métier : un ticket résolu, un document résumé, un lead enrichi, une ligne classée. L’arithmétique ressemble alors à ceci.
| Composante | Comment la calculer | Remarque |
|---|---|---|
| Coût moyen d’un appel | (jetons d’entrée × prix d’entrée) + (jetons de sortie × prix de sortie) | Mesurez-le, ne l’estimez pas |
| Appels par unité | Y compris les étapes de recherche, de routage, de classification et de vérification | Un agent typique fait 3 à 8 appels par unité |
| Multiplicateur de réessai | 1 divisé par le taux de réussite au premier essai | 85 % de réussite équivaut à un multiplicateur de 1,18 |
| Coût du contrôle humain | Taux d’escalade × coût horaire chargé × temps de traitement | Généralement la ligne la plus lourde |
| Répartition des coûts fixes | Coût fixe total divisé par le nombre d’unités mensuelles | Diminue à mesure que le volume augmente |
Les points de repère publiés jusqu’en 2026 dans le service client situent un ticket résolu par l’IA entre un demi-dollar et deux dollars à l’échelle de l’unité, contre six à douze dollars pour un contact traité par un humain. L’écart paraît décisif, mais il se resserre considérablement une fois le contrôle, l’évaluation et l’infrastructure réintégrés, et certains chiffres publiés situent le coût complet d’une résolution automatisée plus près de cinq dollars. La distance entre ces deux lectures est exactement la distance entre le coût des jetons et le coût de possession.
Les trois leviers qui font vraiment bouger la facture
Avant de changer d’architecture, trois remises que les fournisseurs proposent déjà restent sous-exploitées par la plupart des équipes.
| Levier | Ordre de grandeur | Quand il s’applique |
|---|---|---|
| Mise en cache des prompts | Lectures en cache facturées autour du dixième du tarif d’entrée standard | Instructions système stables, documents de base récurrents |
| Traitement par lots | Environ moitié prix | Tout ce qui n’exige pas une réponse en temps réel |
| Choix du modèle par tâche | Un facteur de plusieurs dizaines entre les gammes de modèles | Classification, extraction et routage n’ont pas besoin d’un modèle frontière |
Ce que cela fait au compte de résultat
Le logiciel traditionnel vit à 80-90 % de marge brute parce que le coût de servir un utilisateur de plus tend vers zéro. Une fonctionnalité adossée à un modèle brise cette hypothèse : chaque usage porte un coût de calcul réel. Les publications parues jusqu’en 2026 situent la marge brute de telles fonctionnalités dans la fourchette 50-60 %.
L’implication pratique n’est pas que la fonctionnalité ne vaut rien, mais que le modèle tarifaire doit bouger avec elle. Une tarification par siège, insensible à l’usage, transforme les utilisateurs intensifs en déficit silencieux : quand cinq pour cent des utilisateurs génèrent l’essentiel du coût de calcul, un prix forfaitaire ne fait que les subventionner. Nous traitons ce point séparément dans notre article sur la tarification d’un produit adossé à un modèle, et le lien entre coût unitaire et rentabilité globale dans le modèle unitaire d’une entreprise numérique.
Comment le mesurer en pratique
- Marquez chaque appel d’API avec l’identifiant de l’unité de travail qu’il sert, et pas seulement un identifiant utilisateur. Sans cela, vous ne pourrez pas reconstituer le coût par unité après coup.
- Stockez séparément les jetons d’entrée, les jetons de sortie et le nombre de tentatives. Un total de coût unique masque tout ce qui pourrait être corrigé.
- Traitez le taux de réussite au premier essai comme une métrique produit, pas comme une métrique d’infrastructure. Il multiplie directement le coût.
- Répartissez les coûts fixes sur les unités chaque mois, sinon une fonctionnalité en croissance paraîtra pire qu’elle ne l’est.
- Fixez un plafond de coût par unité comme critère de mise en production, au même titre qu’un critère de qualité. Une fonctionnalité qui dépasse le plafond ne sort pas.
Ce dernier point rejoint une question plus large : comment définir des conditions d’acceptation pour un système dont la sortie est probabiliste. Nous l’exposons dans notre article sur les critères d’acceptation d’une fonctionnalité IA, et le volet commercial plus large relève de nos domaines d’expertise.
Questions fréquentes
Quelle part du coût total de possession représente la facture d’API ?
Il n’existe pas de chiffre unique, mais dans les déploiements comportant un contrôle humain, une couche d’évaluation et de la supervision, la ligne API est généralement minoritaire dans le coût total. Plus le produit est automatisé et peu supervisé, plus sa part augmente. C’est pourquoi les sept lignes doivent être calculées et non déduites d’une grille tarifaire.
Comment estimer le coût avant qu’une production n’existe ?
Faites passer un échantillon représentatif de plusieurs centaines d’unités de travail réelles dans le pipeline complet et mesurez les jetons, les appels et les réessais tels qu’ils se produisent réellement. Une estimation faite à partir du seul prompt sous-évalue presque toujours, parce qu’elle ignore le contexte récupéré et les échecs.
Un modèle plus petit est-il toujours moins cher ?
Non. Un modèle bon marché qui échoue plus souvent produit des réessais, des sorties plus longues et des escalades vers des humains, qui coûtent tous plus que l’écart de prix des jetons. La bonne comparaison est le coût par unité de travail menée à bien, pas le prix par million de jetons.
Quand vaut-il la peine de passer à un modèle auto-hébergé ?
Quand la charge est étroite, répétitive et à fort volume, et quand le coût ou la latence de l’API est devenu la contrainte déterminante. À faible volume ou sur une tâche large, le coût d’ingénierie et de maintenance d’un modèle exécuté chez soi dépasse généralement l’économie réalisée.
Si vous ne suivez qu’une seule métrique, laquelle ?
Le coût par unité de travail menée à bien, revu chaque mois. Il absorbe le prix des jetons, le taux d’échec, les escalades et l’efficacité de la recherche, et c’est le seul chiffre directement comparable à votre tarification et au coût de l’alternative humaine.