Le prix du jeton s’effondre plus vite qu’aucune technologie avant lui. Un graphique diffusé par Andreessen Horowitz, construit sur des chiffres de Goldman Sachs et du département du Commerce américain, montre que l’IA a comprimé ses coûts unitaires en trois ans, là où l’informatique personnelle avait mis près de vingt ans pour y arriver. Les factures des entreprises, elles, ne suivent pas la même pente.
Les clés du coût de l’IA en 20 secondes
- Les modèles coûtent moins cher par jeton, mais les applications en consomment beaucoup plus.
- Les agents planifient, appellent des outils, vérifient leurs résultats et répètent des étapes.
- Une même tâche confiée à un agent peut varier jusqu’à 30 fois en consommation.
- La métrique qui compte n’est plus le prix de l’API, mais le coût par tâche réussie.
Les premiers chatbots traitaient une requête simple : recevoir une question, lire le contexte, répondre. Les agents actuels enchaînent des dizaines d’appels, gardent un historique détaillé, consultent des moteurs de recherche, exécutent du code, ouvrent des documents et font vérifier leurs résultats par d’autres agents. Le jeton coûte moins, mais chaque processus en réclame beaucoup plus.
Le prix par million de jetons ne dit plus grand-chose du coût réel
La concurrence entre OpenAI, Anthropic, Google, DeepSeek et les développeurs de modèles open-source a considérablement élargi la gamme de prix.
DeepSeek V4 Flash facture 0,14 dollar par million de jetons d’entrée sans cache et 0,28 dollar en sortie. Google positionne Gemini 2.5 Flash-Lite à 0,10 et 0,40 dollar. À l’autre bout de l’échelle, Claude Fable 5 demande 10 dollars en entrée et 50 dollars en sortie.
OpenAI a de son côté découpé GPT-5.6 en trois niveaux : Luna à 1 dollar d’entrée et 6 dollars de sortie, Terra à 2,50 et 15 dollars, Sol à 5 et 30 dollars. Les lectures via cache bénéficient d’une remise de 90 %, mais l’écriture dans ce cache coûte 1,25 fois le tarif normal d’entrée.
| Modèle | Entrée / million de jetons | Sortie / million de jetons |
|---|---|---|
| Gemini 2.5 Flash-Lite | 0,10 $ | 0,40 $ |
| DeepSeek V4 Flash | 0,14 $ | 0,28 $ |
| GPT-5.6 Luna | 1 $ | 6 $ |
| GPT-5.6 Sol | 5 $ | 30 $ |
| Claude Fable 5 | 10 $ | 50 $ |
Ce tableau ne classe pas la qualité. Les modèles diffèrent par leurs capacités, leur latence, leurs limites, leurs politiques de données et leur support. Une tâche qui réclame cinq tentatives avec un modèle économique peut coûter davantage qu’une exécution réussie du premier coup avec un modèle plus cher à l’achat. C’est tout le problème du prix par jeton comme seule boussole : il ignore combien de jetons il faut pour atteindre un résultat correct, combien d’appels à des outils sont nécessaires, et le temps humain passé à vérifier la réponse.
La métrique qui compte, c’est le coût par tâche accomplie avec la qualité attendue. En programmation, le coût par incident résolu ou par modification acceptée. En service client, le coût par conversation close sans intervention humaine. En analyse documentaire, le coût par dossier traité correctement.
Les agents transforment le contexte en boule de neige
Un chatbot classique répond en une ou deux requêtes. Un agent suit un cycle plus long : il interprète l’objectif, élabore un plan, choisit un outil, lit le résultat, met à jour son contexte, décide de l’étape suivante, et répète l’opération jusqu’à la fin ou jusqu’à une limite fixée. À chaque tour, il repasse par la question initiale, les instructions système, les documents consultés, les réponses précédentes et les résultats des outils. Le contexte grossit, même quand la réponse finale tient en trois lignes.
Une étude du Stanford Digital Economy Lab sur des agents de programmation a mesuré des tâches consommant jusqu’à 1 000 fois plus de jetons que de simples exercices de conversation ou de raisonnement sur du code, avec des écarts allant jusqu’à 30 fois en répétant la même tâche sur le même système. Consommer davantage de jetons n’améliore d’ailleurs pas forcément le taux de réussite. Ces chiffres concernent la programmation et ne se généralisent pas mécaniquement à toutes les applications, mais ils pointent un vrai problème opérationnel : les agents suivent des trajectoires variables et n’anticipent pas toujours leur coût final. La question de la sécurité de ces flux d’appels a d’ailleurs pris assez d’ampleur pour que Palo Alto Networks rachète Portkey pour surveiller le trafic généré par les agents IA en entreprise.
Les appels aux outils ajoutent leur propre facture. Une recherche web peut déclencher plusieurs requêtes facturables. L’exécution de code renvoie des résultats qui redeviennent des jetons d’entrée. Captures d’écran, PDF et images doivent aussi être convertis en représentations qui pèsent sur le contexte. Google facture à part certaines connexions à Search et Maps, OpenAI applique des frais par appel sur certaines API en plus du coût du modèle, et avec GPT-5.6 toute requête dépassant 272 000 jetons double le tarif d’entrée et augmente de 50 % celui de sortie.
Pourquoi la dépense grimpe même quand l’IA devient moins chère
La baisse des prix pousse à automatiser davantage de processus. Une entreprise qui résumait quelques documents avec l’IA peut désormais l’appliquer à tous ses emails, contrats, incidents, dépôts de code et réunions. Andreessen Horowitz parle d’un effet proche du paradoxe de Jevons : rendre une ressource plus efficace en augmente souvent la consommation totale, pas l’inverse.
Un glissement vers des travaux plus longs se dessine aussi. GPT-5.6 coordonne des sous-agents en parallèle. Claude Fable 5 est pensé pour des projets qui restent actifs plusieurs jours. Ces capacités gagnent en productivité, mais multiplient aussi les inférences, les appels d’outils et le traitement du contexte, un peu comme OpenAI mise sur le débit brut de Cerebras pour absorber des workloads de code de plus en plus lourds. Une baisse de 50 % du prix du jeton ne réduit donc pas le budget de moitié : si la nouvelle application multiplie les appels par dix, la dépense finale continue de grimper.
L’optimisation doit couvrir l’ensemble du flux, pas seulement le choix du modèle.
| Mesure technique | Effet attendu |
|---|---|
| Routage entre modèles | Réserver les modèles coûteux aux tâches complexes |
| Limites d’étapes et de tentatives | Éviter les boucles d’agents sans issue |
| Cache des prompts et documents | Réduire le traitement répétitif |
| Résumé de l’historique | Empêcher une croissance indéfinie du contexte |
| Traitement par lots | Réduire les coûts quand la réponse immédiate n’est pas nécessaire |
| Résultats structurés | Éviter des réponses longues et difficiles à valider |
| Évaluations automatiques | Identifier quel modèle résout le mieux chaque cas |
| Observabilité par tâche | Relier consommation, latence, erreurs et qualité |
La solution la moins chère n’est pas toujours le modèle le plus modeste : un modèle plus performant peut réduire le nombre d’appels, d’outils et de corrections nécessaires. La décision se prend sur des tests avec des tâches réelles, pas sur le seul prix affiché par le fournisseur.
Une architecture multimodèle pour limiter les coûts et la dépendance
La volatilité rapide des prix est une raison de plus pour éviter de bâtir une application sur une seule API. Une couche d’abstraction peut normaliser messages, outils, réponses structurées, métriques et politiques de reprise : la logique du produit reste en haut, les modèles en dessous changent selon le coût, la qualité, la latence, la localisation des données ou la disponibilité. Cette architecture permet d’affecter un modèle économique au tri des requêtes, un modèle spécialisé à la programmation, et un modèle de pointe réservé aux cas complexes. Elle facilite aussi l’intégration d’un modèle open-source en infrastructure propre quand les données doivent rester dans un environnement contrôlé.
La portabilité n’est jamais automatique : chaque fournisseur a ses propres fonctions pour les outils, le cache, le raisonnement, les sorties structurées et le contexte. Une application accrochée à des fonctionnalités exclusives continuera de générer des coûts de migration, même avec une interface compatible. D’où l’intérêt de tester la substitution de modèles avant d’en avoir besoin : constituer des jeux d’évaluation, enregistrer des réponses de référence, mesurer périodiquement le coût pour atteindre le même niveau de qualité chez différents fournisseurs.
Le coût de l’intelligence restera une métrique suivie de près, mais son importance relative diminue face à la maîtrise de la consommation, tâche par tâche.
Questions fréquentes
Pourquoi la facture grimpe-t-elle alors que les modèles sont moins chers ?
Parce que les systèmes agentiques multiplient les appels, accumulent des contextes plus riches et sollicitent davantage d’outils externes. Le volume croît souvent plus vite que le prix par jeton ne baisse.
Quelle est la meilleure métrique pour évaluer le coût d’une application IA ?
Le coût par tâche terminée avec succès, croisé avec le taux de réussite, la latence, le nombre de tentatives et le temps de vérification humaine.
Faut-il toujours choisir le modèle le moins cher pour réduire le budget ?
Pas forcément. Un modèle économique peut consommer plus de jetons, échouer plus souvent ou réclamer plusieurs tentatives. Le coût s’évalue sur l’ensemble du flux, pas sur le prix affiché.
Qu’apporte une architecture multimodèle ?
Elle permet d’affecter chaque tâche au modèle le plus adapté, de prévoir une alternative en cas de panne ou de changement de prix, et de réduire la dépendance technique à un seul fournisseur.
