L'IA ne se facture pas au poste, mais au compteur
Les entreprises budgétisent l'IA comme un logiciel par utilisateur. Ce qu'elles achètent est un service facturé au compteur, et presque personne côté acheteur ne modélise ce compteur.
La plupart des organisations qui achètent de l'IA à grande échelle sont incapables de calculer leur coût par tâche. Elles connaissent le prix au poste de chacun de leurs autres outils, et elles connaissent le tarif affiché sur la page de prix du fournisseur. Ce qui se trouve entre ces deux chiffres, le coût réel de production d'une tâche livrée, tient généralement en un haussement d'épaules et une facture mensuelle que personne ne sait décomposer.
Cet angle mort n'est pas un détail de contrôle de gestion, c'est une erreur de catégorie. Le logiciel d'entreprise se vend au poste depuis trente ans, si bien que les achats le modélisent par réflexe au poste : une ligne de prévision, multipliée par les effectifs. Ce que vous avez réellement acheté, c'est un service facturé au compteur. Le compteur compte des tokens, et le nombre de tokens que consomme une tâche n'a presque rien à voir avec le nombre de personnes connectées.
Le compteur mesure ce que le vendeur a défini
Un token n'est ni un mot, ni une syllabe, ni quoi que ce soit qu'un humain reconnaîtrait comme une unité linguistique. C'est un fragment produit par un algorithme de compression recyclé en vocabulaire. La technique qui sert aujourd'hui de base à la facturation du secteur a été adaptée d'une méthode de compression par paires d'octets (byte-pair encoding) par Rico Sennrich, Barry Haddow et Alexandra Birch, de l'université d'Édimbourg, en s'appuyant sur les travaux de compression de Philip Gage datant de 1994. Elle a été retenue parce qu'elle gérait bien les mots rares, personne ne l'a choisie pour en faire une unité de compte. Elle l'est devenue quand même.
L'acheteur signe un contrat libellé dans une quantité qui est un sous-produit d'une session d'entraînement, tandis que le vendeur publie le prix au million d'unités sur une page de tarification publique susceptible de changer à tout moment. Le tarif est visible d'une façon dont le volume ne l'est jamais. Vous ne maîtrisez ni le nombre de tokens que devient votre requête, ni le nombre que le système décide de produire en réponse, et la facture est le produit des deux.
Comment calculer son coût par tâche IA ?
Il faut partir du mécanisme : le modèle n'a aucune mémoire entre deux requêtes. La continuité de la conversation est une illusion produite en renvoyant l'intégralité de l'échange précédent, plus les instructions système cachées et les définitions d'outils, à chaque tour. La documentation des fournisseurs est explicite sur ce point : les sorties d'un tour deviennent les entrées du tour suivant.
L'arithmétique en découle sans qu'il soit besoin d'un seul benchmark. Si chaque tour ajoute environ k tokens et que chaque tour accumulé est retraité en entier, le volume total de contexte traité sur n tours vaut k(1+2+…+n), soit kn(n+1)/2 : une croissance quadratique avec le nombre de tours. Concrètement, pour une session de dix échanges ajoutant chacun un millier de tokens environ, la facture porte sur près de 55 000 tokens en entrée, contre 10 000 que prédirait un raisonnement linéaire, parce que le dixième échange repaie l'intégralité des neuf précédents. Un simple assistant conversationnel répond une fois et s'arrête ; un agent boucle, et c'est la boucle qui fait la courbe de coût.
Ajoutez maintenant les frais fixes. Les instructions système et les schémas d'outils voyagent à chaque appel, si bien que les tâches courtes affichent un ratio de charge déplorable : on peut dépenser l'essentiel d'une requête à redécrire les outils disponibles plutôt qu'à exécuter le travail. Divisez enfin par le taux de réussite. Si sept tentatives sur dix produisent un résultat exploitable, le coût réel par tâche aboutie est la dépense totale divisée par 0,7, soit environ 43 % de plus que le chiffre naïf.
Le compteur tourne à chaque tentative, la valeur ne s'accumule qu'aux réussites, et tout business case IA qui suppose implicitement que ces deux nombres sont identiques surestime sa marge.
Pourquoi la même tâche coûte-t-elle plus cher dans certaines langues ?
Parce que le vocabulaire a été appris, en grande partie sur un web dominé par l'anglais, et qu'il compresse bien mieux ce qu'il a beaucoup vu que ce qu'il a peu vu. Des travaux indépendants présentés à NeurIPS par Petrov et ses coauteurs, comparant des textes parallèles multilingues, documentent des écarts substantiels de longueur tokenisée selon la langue, l'ampleur variant selon le tokeniseur et la paire de langues retenue.
Le résultat est une structure de marge que personne n'a choisie. Pour une scale-up de la French Tech qui sert ses clients francophones tout autant que ses clients anglophones, la même interaction de service client, rendue au même niveau de qualité, coûte systématiquement plus cher dans certains marchés que dans d'autres, et l'écart reste invisible dans tout tableau de bord raisonnant en coût par utilisateur. Les produits multilingues ont un problème d'économie unitaire par marché qui n'est jamais entré dans le modèle de tarification, et les charges de travail riches en code héritent de la même asymétrie, en sens inverse.
Le plafond qui échoue en silence
La fenêtre de contexte est une limite dure, et la dépasser signifie que quelque chose est écarté. Le symptôme, des réponses qui se dégradent loin dans une session longue, ressemble à s'y méprendre à un problème de fiabilité, si bien que les équipes migrent vers un modèle plus gros ou un autre fournisseur alors qu'elles avaient en réalité mal provisionné une capacité. Poser ce diagnostic suppose de connaître les limites publiées de ce que l'on a acheté, et publié signifie énoncé et daté par le fournisseur, à l'image de l'article d'OpenAI de mai 2020 identifiant GPT-3 comme un modèle autorégressif de 175 milliards de paramètres. Tout ce qui provient d'un agrégateur de blogs relève du folklore. C'est le genre de sujet à trancher avant de s'engager sur un projet, pas pendant la réunion de retour d'incident.
Ce qui casse quand les remises s'arrêtent
L'objection évidente : les prix des tokens n'ont cessé de baisser, alors pourquoi modéliser tout cela ? Parce que le prix unitaire et le volume consommé évoluent en sens opposés. Le tarif au token baisse pendant que les usages agentiques poussent la consommation par tâche à la hausse, d'un ordre de grandeur, et le second effet dépasse aujourd'hui le premier. Des prix qui baissent sont un argument pour connaître sa courbe, pas contre. Cette courbe indique quels usages basculent de non viables à viables à quel prix, et lesquels n'étaient solvables que parce que quelqu'un d'autre absorbait la différence.
Savoir si les tarifs actuels sont au-dessus ou en dessous du coût réel de service n'est pas quelque chose qu'un acheteur peut vérifier de l'extérieur. La structure, elle, est bien visible : le vendeur définit l'unité, fixe le tarif, et révise les deux, tandis que l'acheteur n'a aucun moyen indépendant d'auditer la quantité facturée. C'est une asymétrie inhabituelle à accepter sur un poste opérationnel, et la réponse sensée relève de l'ingénierie, pas de la plainte : mesurer les tokens par tâche aboutie et par usage, instrumenter le taux d'échec, plafonner délibérément la longueur des conversations, et concevoir des boucles d'agents qui ne traînent pas tout leur historique derrière elles. Ce sont des décisions d'architecture sur la façon dont les agents sont construits, et elles relèvent de la stratégie technique, pas de la revue budgétaire.
Une entreprise capable de chiffrer son coût par poste, par appel ou par mois a mesuré quelque chose. Elle n'a simplement pas mesuré ce qu'elle achète.
Questions fréquentes
Que faut-il mesurer à la place des tokens par appel API ?
Les tokens par tâche aboutie, ventilés par usage, avec le taux d'échec associé. Un chiffre par appel masque à la fois le contexte renvoyé des sessions multi-tours et le coût des tentatives qui n'ont rien produit d'exploitable, or c'est précisément là que se loge le dérapage budgétaire.
La mise en cache ou le raccourcissement des prompts corrige-t-il la croissance super-linéaire du coût des longues sessions d'agents ?
Cela réduit la constante, pas la forme de la courbe. Alléger les instructions système ou réutiliser du contexte mis en cache abaisse le coût par tour, mais tant que l'historique accumulé est renvoyé intégralement à chaque tour, le volume total de contexte traité continue de croître avec le carré du nombre de tours. Seuls le plafonnement de la longueur des sessions et le résumé de l'historique modifient la courbe elle-même.
Pourquoi nos dépenses IA augmentent-elles sans que le nombre d'utilisateurs progresse ?
Parce que la dépense suit le travail effectué, pas les postes occupés. Un seul utilisateur qui lance des tâches plus longues et plus agentiques, avec davantage d'appels d'outils, peut consommer bien plus que plusieurs utilisateurs posant chacun une question ponctuelle : les prévisions fondées sur les effectifs dérivent presque immédiatement dès que les agents remplacent le chat.
À lire aussi
- L'oligopole de la mémoire qui fait grimper la facture de l'IA
- Le moindre privilège pour les agents IA : un principe de 1975 que votre pilote court-circuite
- L'IA à prix cassé, c'est fini : les investisseurs de votre fournisseur payaient votre facture
- AI & Automation
Rédigé par un persona éditorial IA du système éditorial propriétaire d'Abyshire et relu par notre équipe.