Le prix par token est une illusion : mesurer le coût par résultat

Posez la question à une direction technique qui évalue les modèles de fondation en 2026, et vous obtiendrez presque toujours le même artefact : un tableau. En colonnes, les fournisseurs ; en lignes, le prix du million de tokens en entrée, celui du million en sortie, la fenêtre de contexte. On surligne la case la moins chère, on tranche. C'est propre, c'est chiffré, c'est rassurant. Et c'est, à peu près, sans rapport avec ce que la DSI paiera réellement à la fin du trimestre.

Le réflexe est compréhensible. Depuis que les prix des modèles frontier s'effondrent, chaque annonce se présente comme une affaire à saisir : un modèle puissant, à un tarif qui aligne le fournisseur sur les moins chers du marché. Mais comparer des prix unitaires suppose une hypothèse cachée : que la quantité consommée soit à peu près la même d'un modèle à l'autre, d'une tâche à l'autre. Sur un usage conversationnel, l'hypothèse tient à peu près. Sur un usage agentique (celui qui produit vraiment de la valeur en 2026), elle est fausse au point de rendre la comparaison trompeuse. Il faut déplacer la focale : du prix affiché par le fournisseur vers le coût réel d'un résultat, et de la variable qu'on croit dominante vers celle qui l'est vraiment.

Le prix affiché n'est pas la facture

Un prix par token est un prix unitaire. Une facture est un prix unitaire multiplié par un volume. Tant qu'on ignore le second terme, on ne compare rien. Or ce volume, en régime agentique, est colossal et d'une grande variabilité. Quand on instrumente un cycle de développement piloté par des agents, une tâche de codage consomme en moyenne de l'ordre de 4,17 millions de tokens, soit près de mille fois plus qu'un simple échange conversationnel¹. On ne raisonne plus en centimes par requête ; on raisonne en millions de tokens par unité de travail livrée.

Pire pour l'illusion tarifaire : ce volume n'est pas stable. Deux exécutions de la même tâche de débogage peuvent varier d'un facteur trente en tokens consommés¹. Autrement dit, l'écart de consommation entre deux runs identiques est d'un ordre de grandeur supérieur à l'écart de prix entre deux fournisseurs concurrents. Optimiser la troisième décimale du tarif quand la quantité fait le yo-yo d'un facteur trente, c'est peaufiner le prix du carburant en ignorant que le trajet change de longueur à chaque fois. La grille tarifaire donne l'illusion d'un critère de décision limpide (le moins cher gagne), parce qu'elle escamote la seule variable qui pèse : combien de tokens il faudra réellement pour arriver au résultat.

La dépense suit l'ingestion, pas la génération

Reste à comprendre d'où vient ce volume. L'intuition spontanée l'attribue à la production : un agent qui écrit beaucoup de code coûterait cher. La mesure dit le contraire : le ratio entre ce que l'agent lit et ce qu'il écrit atteint 153 pour 1 en codage agentique, contre 1,33 pour 1 pour un simple chat de code¹. La facture suit l'ingestion, pas la génération.

Ce que le modèle relit sans cesse (la base de code, la mémoire rechargée à chaque tranche, les logs capturés, les résultats d'outils, les diffs) pèse cent cinquante fois plus lourd que ce qu'il produit. Dans une session type, les relectures de fichiers représentent à elles seules près de 96 % du contexte¹ : l'agent ré-ingère en boucle ce qu'il a déjà vu, parce que c'est ainsi qu'il maintient sa compréhension du terrain. Le code produit est le sous-produit ; le contexte avalé est la facture.

Cette bascule renverse complètement l'arbitrage tarifaire. Un modèle deux fois moins cher au token, mais qui relit deux fois plus de contexte pour atteindre le même résultat (parce qu'il cadre moins bien, se perd davantage, itère plus longtemps), ne fait économiser rien du tout. Le prix unitaire descend, le volume ingéré monte, la facture reste identique, voire empire. À l'inverse, un modèle légèrement plus cher qui arrive au but en avalant moins de contexte est, en coût réel, le moins cher des deux. Le tableau comparatif ne verra jamais cet effet : il compare des prix, alors que la dépense se joue sur des volumes d'ingestion que la grille tarifaire ne mentionne même pas.

Ce qui brûle vraiment les tokens

Si l'ingestion domine à ce point, autant savoir ce qui la nourrit. Quatre moteurs concentrent l'essentiel de la combustion, et aucun ne figure sur une fiche produit.

Le premier est l'ingestion de contexte elle-même : rechargement de la mémoire des leçons avant chaque tranche de travail, relecture du code existant pour en comprendre les patterns. C'est le moteur des 96 %. Le deuxième est le parallélisme multi-agents : chaque sous-agent maintient sa propre fenêtre de contexte, si bien que N agents lancés en parallèle consomment de l'ordre de sept à quinze fois les tokens d'une session simple¹. Le troisième est la boucle de debug (reproduire, localiser, corriger, recommencer), la source première de cette variance ×30 entre deux exécutions. Le quatrième est la recherche web : une seule page pèse des dizaines de milliers de tokens en entrée, et activer l'outil ajoute déjà, à lui seul, quelque 4 300 tokens de contexte permanent¹.

La leçon de décideur est double. D'abord, ces quatre moteurs sont pilotés par la conception du système agentique (le cadrage des tâches, le nombre de sous-agents, la discipline des boucles), pas par le choix du fournisseur. Ensuite, ils ne sont pas des gaspillages à éradiquer : le parallélisme, par exemple, se paie en tokens mais réduit le temps réel de moitié et améliore la qualité. Certaines phases méritent qu'on paie leur multiplicateur, d'autres non. La question n'est donc jamais « quel modèle est le moins cher », mais « où et quand vaut-il la peine de brûler des tokens », un arbitrage qui relève de l'architecture du harnais, pas de la page de tarifs.

Le bon indicateur : le coût par résultat

De ce diagnostic découle un changement d'unité de mesure. Le prix par token est un indicateur d'intrant ; il renseigne sur le coût d'une matière première, pas sur celui d'un livrable. Le bon indicateur est un indicateur de sortie : le coût par résultat (le cost-per-outcome), c'est-à-dire ce que coûte, bout à bout, une unité de valeur métier produite. Combien coûte une fonctionnalité livrée. Combien coûte une revue de code menée à son terme. Combien coûte un correctif validé.

On dispose déjà de premiers points de repère chiffrés. Une revue de code multi-agents (plusieurs relecteurs parallèles auditant qualité, sécurité, tests et performance sur un même pull request) revient à l'ordre de 15 à 25 dollars par PR, pour environ 3 millions de tokens¹. Voilà un chiffre exploitable par une DSI, parce qu'il rapporte un coût à un résultat qu'elle comprend et budgète (une revue), pas à une abstraction comme le million de tokens. C'est sur cette base qu'on peut enfin décider : ce résultat vaut-il ce prix ? Peut-on le produire moins cher sans dégrader sa qualité ? Le prix par token, lui, est incapable de répondre à ces questions, car il ignore par construction combien d'unités il faudra consommer.

Raisonner en coût par résultat impose aussi une honnêteté méthodologique. La répartition de la dépense sur un cycle complet donne une carte précieuse du terrain : de l'ordre de 78 % concentrés sur quatre phases seulement, construction (30 %), revue (19 %), planification (17 %) et vérification (12 %)¹. Mais ces pourcentages sont des ordres de grandeur dérivés, pas des mesures universelles : aucune source publique ne ventile finement les tokens sur un cycle de développement, et le profil réel varie fortement d'un projet à l'autre. Ils indiquent où creuser en priorité ; ils ne remplacent pas l'instrumentation de votre pipeline.

Les leviers FinOps de l'IA

Une fois qu'on mesure le coût par résultat, on découvre que les leviers d'économie sont presque tous situés du côté de l'ingestion, donc chez soi. Trois familles sortent du lot.

Le premier levier, et de loin le plus puissant, est la mise en cache du contexte. Puisque l'agent relit sans cesse les mêmes fichiers, les faire passer par un cache change tout : les relectures mises en cache reviennent à environ 10 % du tarif d'entrée, soit jusqu'à −90 % sur le premier poste de coût¹. Un seul réglage, sur la variable dominante, produit un effet qu'aucune renégociation de tarif fournisseur n'approchera jamais. Qui parle de prix par token avant d'avoir activé le prompt caching optimise la mauvaise variable.

Le deuxième levier est le cadrage du périmètre pour limiter l'ingestion à la source. Un scope strict défini en amont, des sous-agents isolés dans leur propre fenêtre pour que le détail ne pollue pas le contexte principal, une tâche découpée pour éviter les relectures massives inutiles : autant de décisions qui réduisent le volume avalé avant même que le premier token ne soit facturé. C'est l'objet du context engineering (l'art de composer l'environnement de l'agent), et c'est là que se joue la part la plus élastique de la facture.

Le troisième levier est l'instrumentation. Tant qu'on estime, on débat de brochures ; dès qu'on mesure, on décide. Des outils comme ccusage ou la commande /cost permettent de ventiler la consommation par tâche et par phase, et de remplacer les ordres de grandeur généraux par des chiffres maison. C'est la brique fondatrice d'un FinOps de l'IA digne de ce nom : sans mesure par résultat, il n'y a ni budget fiable, ni optimisation vérifiable, ni arbitrage rationnel. Reste un quatrième levier, le routage par tâche (un modèle de raisonnement pour la planification, un modèle rapide pour l'exploration), dont la mécanique fine mérite un traitement à part : nous la détaillons dans notre guide du routage multi-modèles.

Le point de vue SFEIR : le levier dominant est chez vous

Notre conviction, en tant qu'acteur « AI Only », se résume à un déplacement de responsabilité. Pendant deux ans, on a posé la question du coût de l'IA comme une question d'achat : quel fournisseur, à quel tarif. Les mesures montrent qu'elle est d'abord une question d'ingénierie : comment cadrer, mettre en cache, isoler, mesurer. Le prix affiché par le laboratoire est une variable qu'on subit et qu'on négocie à la marge ; le volume d'ingestion est une variable qu'on conçoit et qu'on maîtrise. Le levier dominant est dans le harnais, pas dans la colonne du tableau comparatif.

Cela ne veut pas dire que le choix du modèle est indifférent : il compte, notamment sur les tâches les plus dures. Mais il n'est pas le premier poste d'économie, et le traiter comme tel conduit à optimiser une variable secondaire en laissant intacte la variable principale. Pour une DSI, la bonne discipline est donc une gouvernance FinOps centrée sur le coût par résultat : instrumenter d'abord, cadrer ensuite, mettre en cache systématiquement, et ne discuter du tarif fournisseur qu'une fois ces trois chantiers menés. C'est cette bascule du prix vers le système que nous cartographions dans le panorama des modèles frontier, et qui fonde une architecture multi-LLM pensée pour la résilience autant que pour le coût.

Cesser de comparer des prix, commencer à mesurer des résultats

Revenons au tableau du début. Il n'est pas inutile : il faut bien connaître les tarifs. Il est mal cadré : il répond à la question « quel token est le moins cher ? » alors que la seule question qui engage un budget est « quel résultat coûte le moins cher à produire, chez nous, sur notre pile, avec nos données ? ». Entre les deux, il y a un facteur mille de volume, un ratio de 153 pour 1 en faveur de l'ingestion, une variance de trente entre deux runs, et un levier de mise en cache à −90 % qu'aucune grille tarifaire ne mentionne.

La conduite à tenir en découle sans détour. Arrêter d'arbitrer sur le prix affiché du fournisseur, qui déplace le curseur de quelques pourcents sur une variable secondaire. Instrumenter la consommation par résultat pour passer de l'estimation au chiffre maison. Concentrer l'effort d'optimisation là où il rapporte vraiment : la mise en cache, le cadrage du contexte, la discipline du harnais. Dans un marché où tous les modèles convergent vers le même prix à peu près au même moment, l'avantage se gagne en produisant le résultat au moindre coût, pas en achetant le token le moins cher. Le prix par token fera encore les gros titres. Ce n'est déjà plus l'indicateur qui compte.

---

Sources

1. Bai et al., « How Do AI Agents Spend Your Money? », arXiv 2604.22750 (2026) — mesures sur 8 modèles frontier (SWE-bench Verified). Analyse first-party SFEIR de la consommation d'un cycle de développement piloté par agents (matière interne « Tokens & SDLC v3 ») : ratio entrée/sortie 153:1 (vs 1,33:1 pour un chat de code), ~4,17 M tokens par tâche (~1000× un chat), variance ×30 entre deux exécutions, ~96 % du contexte en relectures de fichiers, répartition ~78 % sur 4 phases (BUILD 30 % · REVIEW 19 % · PLAN 17 % · VERIFY 12 %), prompt caching à ~10 % du tarif d'entrée (jusqu'à −90 %), ~15-25 $ par PR pour une revue multi-agents, 0 token LLM en OPS (monitoring runtime). Réserve méthodologique : les pourcentages de répartition sont des ordres de grandeur dérivés, pas des mesures directes — à instrumenter par projet (ccusage, /cost) pour passer de l'estimation au chiffre maison. arXiv 2604.22750