Le coût des tokens ne dit pas combien coûte vraiment votre IA

Le prix d’un million de tokens ne suffit pas à savoir combien coûte réellement un usage d’intelligence artificielle. Pour une requête simple, la facture peut rester lisible. Avec un agent qui relit des documents, appelle des outils, recommence une étape et attend une validation humaine, le tarif du modèle ne représente qu’une partie de la dépense.

Un token mesure une consommation, pas une performance

Un token est une unité de texte traitée par un modèle. Ce n’est ni toujours un mot ni toujours un caractère entier. La tokenisation varie selon les fournisseurs et les modèlesce qui rend les comparaisons imparfaites entre deux grilles tarifaires.

Les services facturés à l’usage distinguent généralement les tokens d’entrée et les tokens de sortie. Les premiers correspondent à la demande, aux documents et au contexte transmis au modèle. Les seconds correspondent à la réponse produite. Les tarifs peuvent différer entre ces deux catégories.

Le volume envoyé compte autant que la réponse finale. Une instruction courte accompagnée d’un historique volumineux, de fichiers ou de journaux techniques peut consommer bien plus de tokens qu’une question isolée. La taille du contexte, le modèle choisi, la présence d’un cache et les conditions du fournisseur modifient également le montant facturé.

Avec un agent, la facture suit la boucle

Un chatbot répond généralement à une demande. Un agent suit une séquence plus longue : il interprète l’objectif, consulte une mémoire ou une base documentaire, appelle un outil, analyse le résultat, puis décide de poursuivre ou de s’arrêter. Une seule demande peut ainsi déclencher plusieurs appels au modèle.

Le coût complet inclut alors les modèles, les API tierces, l’orchestration, le stockage, l’observabilité, la durée d’exécution et les reprises après erreur. Il faut aussi compter le temps d’une personne qui vérifie une réponse, corrige une donnée ou reprend un dossier que l’agent n’a pas correctement traité.

Pour obtenir une estimation utile, séparez le coût des appels du coût complet de l’exécution :

coût des appels modèle = somme des appels (tokens d'entrée x tarif d'entrée + tokens de sortie x tarif de sortie)

coût complet d'une exécution = coût des appels modèle + outils et infrastructure + temps humain de supervision et de correction

Ces formules ne remplacent pas une facture comptable complète. Elles montrent cependant pourquoi une baisse du tarif unitaire peut être absorbée par une hausse du contexte, des relances ou du parallélisme. Pour convertir le temps humain en montant, il faut lui appliquer un coût horaire cohérent avec le suivi interne. Un agent qui échoue rarement mais traite de gros dossiers peut coûter davantage qu’un agent plus cher à l’appel, mais capable de terminer la tâche en moins d’étapes.

Le bon indicateur est le résultat validé

Compter les requêtes permet de surveiller une dérive technique. Cela ne permet pas de juger la valeur produite. Un agent de support n’est pas performant parce qu’il génère beaucoup de réponses, mais parce qu’il résout correctement des demandes. Un agent documentaire doit être évalué sur les dossiers acceptés, et non sur le nombre de fichiers créés.

L’indicateur le plus utile devient alors :

coût par résultat validé = coût complet des exécutions / nombre de résultats acceptés

Le mot validé change la lecture de la facture. Une sortie rejetée, une correction manuelle ou une nouvelle exécution font partie du coût réel. Il faut aussi associer ce coût à un niveau de qualité et à un délai. Un document exact mais livré trop tard ne produit pas la même valeur qu’un document utilisable dans le délai prévu.

Un tableau de bord opérationnel devrait au minimum suivre :

• les tokens d’entrée et de sortie par modèle;
• le nombre d’appels d’outils, de reprises et d’échecs;
• le coût par équipe, application et cas d’usage;
• le nombre de résultats acceptés et rejetés;
• le temps de supervision et de correction humaine;
• la médiane et les cas extrêmes par workflow.

Les cas extrêmes méritent une attention particulière. Une boucle qui s’allonge, un contexte qui grossit à chaque tour ou une branche de recherche qui ne s’arrête pas peut peser davantage que des centaines d’exécutions normales. Une moyenne mensuelle peut masquer ce type d’incident.

Mesurer, cadrer, optimiser, arbitrer

Commencer par attribuer la dépense

La première étape consiste à relier chaque appel à une équipe, une application et un usage précis. Les abonnements doivent être distingués des appels API et des intégrations embarquées dans un outil métier. Sans cette attribution, une hausse de facture reste impossible à expliquer.

Les alertes doivent intervenir avant le dépassement, avec des plafonds adaptés au projet et à son niveau de risque. Une équipe peut conserver un espace d’expérimentation, tandis qu’un agent connecté à une base client doit respecter des règles plus strictes. Le but n’est pas de supprimer les essais, mais d’éviter qu’un prototype dispose d’un accès illimité à une ressource variable.

Choisir le modèle sur la tâche réelle

Le modèle le moins cher n’est pas automatiquement le meilleur choix. Pour une classification stable ou une extraction bien délimitée, un modèle léger peut suffire. Pour un dossier complexe, un modèle plus performant peut réduire les erreurs, les appels supplémentaires et le temps de vérification.

La comparaison doit donc porter sur une tâche identique, avec un jeu de cas représentatif. Il faut mesurer le taux de réussite, le nombre de reprises, le délai et le coût par résultat accepté. Une architecture en cascade peut réserver un modèle plus coûteux aux cas difficiles et traiter les demandes simples avec une solution moins chère.

Réduire le contexte inutile

Les prompts répétitifs, les historiques trop longs et les documents envoyés en totalité gonflent rapidement les tokens d’entrée. Un contexte mieux découpé, une récupération ciblée de l’information et des instructions normalisées réduisent le volume sans nécessairement dégrader le résultat.

Le cache peut aussi éviter de retraiter plusieurs fois un contexte identique. Son intérêt dépend toutefois du fournisseur, de la durée de conservation et de la tarification appliquée. Il doit être mesuré sur le coût total, pas présenté comme une économie automatique.

Pour les traitements qui ne nécessitent pas une réponse immédiate, le regroupement des tâches peut également réduire le coût unitaire lorsque le fournisseur prévoit une tarification adaptée. Cette méthode convient davantage à la classification, à l’enrichissement de données ou à la génération planifiée qu’à un échange en temps réel.

Le prix facial ne mesure pas la dépendance

Les tarifs des modèles évoluent rapidement. Une entreprise qui construit un processus critique sur une seule API s’expose à une modification de prix, de quota ou de conditions d’accès. Elle dépend aussi du format de sortie, des performances et de la disponibilité du fournisseur.

Les modèles open-weight peuvent offrir une autre voie, notamment lorsqu’une organisation peut les héberger ou les exécuter sur une infrastructure maîtrisée. Ils ne rendent pas l’usage gratuit : il faut ajouter les serveurs, l’intégration, la maintenance, la sécurité et la supervision. Leur intérêt se juge donc sur le coût complet et sur la possibilité réelle de les remplacer, pas sur l’absence de facture par token.

Cette dépendance doit être prise en compte dès le choix du premier périmètre. Un projet bien borné permet de mesurer la valeur avant de multiplier les intégrations. La démarche qui consiste à choisir un premier projet utile évite de confondre volume d’expérimentation et progrès opérationnel.

La responsabilité économique reste enfin liée à la responsabilité métier. Un agent peut recommander, classer ou rédiger, mais une personne doit définir les critères d’acceptation, contrôler les exceptions et décider quand l’automatisation doit s’arrêter. Pour les usages sensibles, la responsabilité reste humainemême lorsque le coût par appel semble faible.

Le premier chantier de pilotage est donc concret : identifier un workflow, lui attribuer ses appels et son temps humain, puis calculer le coût par résultat validé. Cette mesure donne une base pour choisir le modèle, fixer un plafond et décider si l’automatisation mérite d’être étendue.