Token burning : quand les factures de tokens explosent

Le constat : les tokens changent la logique budgétaire

Une licence SaaS classique est relativement prévisible. Une facture IA au token suit le comportement des utilisateurs, des agents et du code. Si un assistant résume des documents longs, si un agent boucle sur une tâche, si un outil de code relance des appels ou si une clé API est mal protégée, la consommation peut monter très vite.

La difficulté vient du fait que le coût n’est pas toujours lisible pour l’utilisateur. Une réponse semble instantanée et immatérielle, mais elle mobilise de l’inférence, du contexte, parfois des embeddings, des recherches documentaires et des appels intermédiaires. Le modèle économique au token déplace donc une partie du risque vers l’usage réel. Plus les équipes adoptent l’IA, plus la facture dépend de comportements difficiles à prévoir sans instrumentation.

Des exemples publics montrent le risque

La presse spécialisée a rapporté qu’Accenture a demandé à certains employés de réduire les usages IA non essentiels face à une hausse rapide de la dépense en tokens. Des articles récents citent aussi des entreprises comme Uber ou Microsoft qui ont mis des garde-fous sur certains outils IA de développement. Un cas extrême, attribué à une entreprise non nommée, évoque une facture Claude de 500 millions de dollars sur un mois faute de limites suffisantes.

Les agents accentuent ce phénomène. Un utilisateur pense parfois avoir posé une seule question, alors que le système a effectué plusieurs recherches, reformulations, appels d’outils et vérifications. Cette chaîne invisible peut être utile, mais elle rend la consommation plus difficile à anticiper. Sans limites et sans observabilité, l’entreprise découvre le coût après coup, lorsque la facture est déjà générée.

Il faut lire ces exemples pour ce qu’ils sont : des signaux de marché. Le problème n’est pas qu’une technologie serait mauvaise ; le problème est qu’un modèle de coût variable, sans garde-fou, peut surprendre même des organisations matures.

Pourquoi la surprise arrive

Le mécanisme est cumulatif : les prompts longs augmentent les tokens d’entrée, les réponses détaillées accroissent les tokens de sortie, les agents répètent des étapes invisibles pour l’utilisateur et les outils de code ou de RAG multiplient les appels en arrière-plan. Les équipes financières découvrent souvent le niveau réel de dépense après que l’usage a déjà eu lieu.

La surprise vient aussi du succès. Une expérimentation qui fonctionne attire plus d’utilisateurs, puis plus de documents, puis plus de workflows. Ce qui était un test devient une habitude. Si l’architecture n’a pas prévu de quotas, de modèles adaptés, de cache ou de règles de routage, chaque nouveau cas d’usage augmente la dépendance à une facturation variable.

Pourquoi OPA est une réponse

OPA réduit le risque en déplaçant les charges récurrentes vers une infrastructure IA privée. Le coût devient lié à une capacité serveur connue plutôt qu’à une addition ouverte de tokens. Les usages internes lourds, le RAG, les assistants métier et certains workflows agentiques peuvent être exécutés localement, avec des règles, des quotas, des journaux et une meilleure visibilité.

Cette approche permet de penser l’IA comme une infrastructure plutôt que comme une simple consommation API. Les modèles peuvent être choisis selon la tâche, les embeddings mutualisés, les documents indexés localement et les usages mesurés. Le coût devient lié à un investissement et à une capacité connue, plutôt qu’à une consommation qui augmente silencieusement avec chaque prompt.

Sources : ITPro sur Accenture et la hausse des tokens, Yahoo Finance sur une facture Claude rapportée à 500 M$, GAP sur les coûts tokens incontrôlés.

Tom Cheniaux - rephrased using AI