Dès qu’une entreprise se met sérieusement à l’IA, une ligne apparaît dans les tableaux de bord : la consommation de tokens. On compare les modèles, on surveille les volumes, on rogne la taille des prompts et du contexte. La discipline est saine — mais la vision est incomplète. Un token ne dit rien de la qualité d’une réponse, du temps gagné, ni de la valeur produite. Il dit une seule chose : combien vous avez dépensé.
Je le formule sans détour :
Le token est une unité de facturation, pas une unité de valeur.
C’est exactement l’erreur symétrique de celle que je décrivais à propos du coût invisible de l’IA : là, on oublie de compter ce qu’on paie vraiment ; ici, on compte parfaitement une dépense qui ne mesure pas ce qui compte. Dans les deux cas, on regarde le mauvais chiffre. (Le versant « coût caché » fait l’objet d’un autre article de cette série.)
Le modèle le moins cher peut coûter le plus cher
Voici le piège le plus fréquent, et le plus contre-intuitif pour un dirigeant qui pilote au prix unitaire. Un modèle économique — un Haiku, par exemple — affiche un tarif au million de tokens imbattable. On le choisit par réflexe de gestion : moins cher à l’unité, donc moins cher, non ?
Pas forcément. Un modèle bon marché peut produire une réponse qui exige une correction humaine, une deuxième tentative, un retraitement. Additionnez le temps de validation, les reprises, les allers-retours, et le coût réel grimpe bien au-delà de l’économie affichée. À l’inverse, un modèle plus lourd — un Sonnet, un Opus — qui réussit du premier coup peut se révéler plus rentable, parce qu’il ne déclenche aucune de ces reprises invisibles.
Le prix unitaire le plus faible n’est donc presque jamais le coût réel le plus bas. Ce qui compte, ce n’est pas le prix d’un million de tokens, c’est le coût d’une tâche correctement terminée. Et ce coût-là intègre le taux de réussite, le temps humain de validation, le nombre de reprises, la gravité d’une erreur qui passe en production. Choisir un modèle sur son tarif affiché, c’est comme recruter au salaire le plus bas sans regarder ce qui est livré.
Toutes les tâches n’ont pas la même valeur
Un tableau de consommation a un défaut de conception : il met tout sur le même plan. Générer un résumé interne et détecter une anomalie critique dans une infrastructure y apparaissent comme deux dépenses comparables — quelques milliers de tokens chacune. Or l’une fait gagner cinq minutes de lecture, l’autre évite peut-être une nuit d’incident et des clients perdus.
Le bon niveau de mesure ne se lit pas en tokens, il se lit en résultats. Combien coûte la qualification d’un prospect ? La génération et la validation d’un contenu réellement publié ? L’analyse d’un ticket effectivement résolu ? L’audit d’un développement qui a évité une erreur ? Une automatisation ramenée à l’heure de travail économisée ?
Ces indicateurs-là permettent de décider : maintenir un workflow, l’optimiser, ou le supprimer. Les tokens, eux, permettent surtout de facturer. Ce n’est pas la même fonction, et confondre les deux conduit à piloter son IA comme une ligne de dépense au lieu d’un portefeuille d’usages.
Chez nous, cette bascule est outillée plutôt que théorique. Nous suivons la valeur produit, pas seulement la dépense — via une pratique dédiée d’analyse d’usage et une analytics maison, sans cookie, conçue pour être conforme au RGPD dès l’origine. Elle mesure l’usage réel — ce qui est ouvert, utilisé, terminé — sans pister personne. Parce qu’un coût n’a de sens qu’en face de ce qu’on en fait vraiment.
Mesurer aussi ce que l’IA vous a évité
C’est la part la plus difficile, et la plus négligée. La valeur de l’IA n’est pas toujours une production supplémentaire — c’est souvent un problème qui n’a pas eu lieu.
Un audit qui évite un incident. Une analyse qui conduit à abandonner un développement inutile avant de l’avoir payé. Une détection précoce qui empêche une dérive de coûts. Rien de tout cela n’apparaît dans un compteur de tokens : ça ne produit pas de ligne, ça en supprime. Et ce qui ne se produit pas ne se compte pas spontanément.
Pourtant ces économies sont réelles, et on peut les approcher : le temps qui aurait été consacré au problème, le coût estimé de l’incident évité, le volume d’erreurs avant et après, les étapes de processus supprimées, le délai de résolution raccourci, la baisse des sollicitations du support. Aucun de ces chiffres n’est parfait. Tous valent mieux que de les ignorer — parce qu’ils sont souvent le vrai retour sur investissement de l’IA de contrôle.
Optimiser, oui — mais après avoir vérifié que c’est utile
Nous économisons beaucoup de tokens. Notre proxy interne de développement en supprime une large part sur les opérations quotidiennes des agents, avec des économies mesurées et affichées workflow par workflow. C’est concret, et je le recommande.
Mais je me méfie d’un raisonnement séduisant : optimiser la consommation d’un workflow ne le rend pas utile. On peut réduire de moitié le coût d’une automatisation que personne n’utilise — on aura juste rendu l’inutile deux fois moins cher. L’ordre des questions compte :
- Le besoin existe-t-il vraiment ?
- Le résultat est-il réellement utilisé, en aval ?
- Et seulement ensuite : peut-on le produire pour moins cher ?
Réduire les prompts, passer à un modèle plus léger là où la tâche le permet, mettre en cache — ce sont de vraies économies. À condition qu’elles portent sur un workflow qui crée plus de valeur qu’il n’en consomme. Optimiser d’abord, questionner ensuite, c’est peaufiner la trajectoire d’une fusée qui ne va nulle part.
Le bon indicateur change les décisions
Au fond, tout se joue là. Obsédé par les tokens, un dirigeant réduit sa facture — et peut, sans le voir, affamer les workflows qui rapportent le plus pour épargner sur ceux qui ne coûtent rien. Concentré sur la valeur, il fait l’inverse : il renforce ce qui produit un résultat utile et supprime le reste, y compris quand « le reste » tourne parfaitement bien.
C’est le vrai test. Un workflow IA ne doit pas rester actif parce qu’il fonctionne. Il doit rester actif parce qu’il crée plus de valeur qu’il n’en consomme. La nuance paraît mince ; elle sépare une entreprise qui pilote son IA d’une entreprise qui la subit.
Le tableau de bord que je défends tient en quelques colonnes, une par usage : l’objectif, le modèle employé, le coût technique, le taux de réussite, le temps humain, le volume traité, la valeur ou l’économie estimée, les incidents — et, au bout, une décision : maintenir, optimiser, ou supprimer. Ce dernier champ est le plus important. C’est lui qui transforme un compteur en outil de gestion.
L’IA n’est pas un poste de dépense à minimiser. C’est un investissement à mesurer correctement. Et on ne mesure pas correctement un investissement en comptant les unités qu’on consomme — on le mesure en regardant ce qu’elles rapportent, et ce qu’elles empêchent de perdre.
Et chez vous — sauriez-vous dire ce que coûte, non pas un million de tokens, mais une seule tâche menée jusqu’au résultat utile ?