Tokenmaxxing : pourquoi certains salariés brûlent des millions de tokens IA

Le tokenmaxxing est devenu l’un des phénomènes les plus étranges de la course à l’intelligence artificielle. Dans certaines entreprises technologiques, des salariés ne se contentent plus d’utiliser ChatGPT, Claude ou des agents de programmation : ils cherchent à consommer le plus grand nombre possible de tokens, parfois pour apparaître dans un classement interne.

Derrière ce jeu se cache un vrai sujet économique. Un token est une petite unité de texte traitée ou produite par un modèle. Une question posée à une IA, les documents transmis, l’historique de la conversation, le raisonnement du modèle et sa réponse peuvent tous alimenter le compteur. À l’échelle d’un utilisateur, le coût paraît souvent invisible. À l’échelle de milliers de salariés et d’agents fonctionnant en continu, il peut devenir considérable.

Qu’est-ce que le tokenmaxxing ?

Le terme « tokenmaxxing » associe « token » et le suffixe anglais « maxxing », utilisé sur Internet pour décrire le fait de pousser une pratique au maximum. Il désigne donc la consommation intensive, parfois volontairement excessive, de tokens d’intelligence artificielle.

Au départ, l’idée n’est pas forcément absurde. Une entreprise qui paie des licences IA coûteuses veut que ses salariés s’en servent. Mesurer l’adoption permet d’identifier les équipes qui expérimentent réellement les nouveaux outils. Certains défenseurs du tokenmaxxing considèrent même que l’exploration doit être encouragée, quitte à tester des pistes qui ne débouchent pas immédiatement sur un résultat.

Le problème apparaît lorsque la mesure devient un objectif. Si le nombre de tokens consommés influence le prestige interne, l’évaluation ou la visibilité d’un salarié, chacun est incité à faire grimper le compteur. C’est une application presque parfaite de la loi de Goodhart : lorsqu’un indicateur devient une cible, il cesse progressivement d’être un bon indicateur.

Un token IA, concrètement, c’est quoi ?

Les modèles de langage ne lisent pas un texte exactement mot par mot. Ils le découpent en fragments appelés tokens. Un token peut correspondre à un mot court, une partie de mot, un signe de ponctuation ou quelques caractères. Selon la documentation d’OpenAI, 100 tokens représentent grossièrement 75 mots en anglais, mais cette équivalence varie selon la langue et le modèle.

Microsoft précise dans sa documentation Azure que les modèles de raisonnement produisent des tokens de raisonnement en plus des tokens d’entrée et de sortie. La consommation visible ne se limite donc pas au texte finalement affiché. De son côté, Anthropic distingue également les tokens d’entrée, ceux utilisés pour créer un cache et ceux relus depuis ce cache.

Microsoft découvre les limites du tokenmaxxing

L’exemple de Microsoft illustre le passage de l’expérimentation à la maîtrise des coûts. En août 2026, 404 Media a rapporté que l’entreprise introduisait des limites budgétaires pour certains usages internes de l’IA. Le message transmis aux ingénieurs était clair : « tokenmaxxing is not what we are optimizing for », autrement dit Microsoft ne cherche pas à maximiser la consommation brute.

Un cas a particulièrement attiré l’attention : un salarié aurait généré environ 28 000 dollars de dépenses de calcul IA en seulement 28 jours. Les données provenaient d’un tableau partagé volontairement par plusieurs centaines d’employés américains. La dépense médiane était bien plus modeste, mais quelques utilisateurs atteignaient plusieurs milliers de dollars par mois.

Microsoft ne renonce pas pour autant à devenir une entreprise « AI-first ». La difficulté consiste plutôt à distinguer une utilisation intensive mais productive d’une consommation entretenue pour elle-même. Un agent qui analyse une base de code, exécute des tests et corrige plusieurs erreurs peut légitimement consommer beaucoup. Lancer des tâches artificiellement longues pour gonfler une statistique n’apporte rien.

Meta et les classements Token Legend

Il ne faut pas confondre l’affaire Microsoft avec le classement interne le plus médiatisé. Celui-ci concernait Meta. Un ingénieur y avait créé un tableau nommé « Claudeonomics », agrégeant l’usage de l’IA de dizaines de milliers de salariés.

Les utilisateurs les plus actifs pouvaient obtenir des titres comme « Token Legend », « Session Immortal » ou « Cache Wizard ». D’après The Pragmatic Engineer, le classement répertoriait notamment les 250 plus gros consommateurs. Cette gamification a rendu visible un comportement déjà présent : multiplier les prompts, allonger les sessions et faire travailler plusieurs agents en parallèle.

Ces classements peuvent accélérer l’adoption au début. Ils rendent l’IA visible, encouragent les discussions et poussent les salariés à sortir de leurs habitudes. Mais ils mesurent un moyen, pas un résultat. Un développeur qui résout un incident critique avec 50 000 tokens peut avoir plus d’impact qu’un collègue qui en consomme 50 millions pour produire du code inutilisable.

Quels prompts consomment réellement beaucoup de tokens ?

Une formulation polie ou une consigne de quelques lignes ne suffit pas à créer une consommation spectaculaire. Les gros volumes viennent surtout du contexte transmis, de la longueur demandée et du nombre d’itérations. Voici plusieurs exemples concrets.

Analyser un grand ensemble documentaire

Analyse intégralement les 40 documents joints. Compare les clauses, les tarifs, les engagements de disponibilité et les pénalités. Cite chaque document, relève toutes les contradictions, puis rédige un rapport détaillé avec une matrice de conformité.

Si chaque document contient plusieurs dizaines de pages, le modèle doit absorber une masse importante de tokens d’entrée. Le rapport, les citations et le tableau comparatif ajoutent ensuite des tokens de sortie. Répéter cette requête après chaque modification multiplie encore la consommation.

Faire travailler plusieurs agents en parallèle

Lance 12 agents indépendants. Chaque agent doit proposer une architecture différente, analyser les risques, estimer les coûts sur trois ans et critiquer les choix des autres agents. Fais ensuite intervenir un agent arbitre qui consolide les résultats dans un dossier complet.

Ici, ce n’est pas la taille du prompt initial qui coûte cher. Chaque agent reçoit du contexte, produit sa propre réponse, lit éventuellement celles des autres puis participe à une synthèse. Une seule consigne humaine peut ainsi déclencher des dizaines d’appels au modèle.

Auditer et réécrire une grande base de code

Parcours l’intégralité du dépôt. Pour chaque module, analyse l’architecture, les dépendances, la sécurité et les performances. Exécute les tests, corrige les erreurs, relance les tests après chaque changement et poursuis jusqu’à ce que tous les contrôles réussissent.

Un agent de développement peut lire des milliers de fichiers, appeler des outils, interpréter leurs sorties et réinjecter les résultats dans son contexte. Les boucles lecture–modification–test sont utiles, mais elles peuvent consommer beaucoup plus que la réponse finale visible.

Demander des variantes puis des critiques successives

Rédige 30 versions de cette campagne. Fais évaluer chaque version par cinq profils différents. Réécris les dix meilleures après critique, organise un second vote, puis produis trois versions finales accompagnées d’une justification détaillée.

Le modèle génère ici un grand nombre de contenus intermédiaires qui ne seront peut-être jamais utilisés. Cette méthode peut aider à explorer un espace créatif, mais elle devient vite coûteuse si aucune limite n’est fixée.

Conserver un historique de conversation gigantesque

Reprends l’intégralité de nos échanges depuis six mois, ainsi que toutes les pièces jointes. Tiens compte de chaque décision antérieure et rédige une nouvelle version exhaustive du projet sans perdre aucun détail.

Lorsqu’une application renvoie l’historique complet à chaque appel, une partie du même contenu peut être retraitée de nombreuses fois. La mise en cache des prompts et la synthèse régulière du contexte permettent de réduire ce phénomène.

Pourquoi consommer davantage peut parfois être utile

Tous les gros consommateurs ne trichent pas. Les agents IA changent l’échelle d’utilisation. Une demande simple peut déclencher une recherche documentaire, des appels d’API, des calculs, plusieurs vérifications et une relecture automatique. Le volume de tokens reflète alors une tâche réellement plus ambitieuse.

Le tokenmaxxing peut également servir de phase d’apprentissage. Une équipe qui expérimente beaucoup découvre plus rapidement les forces et les limites des modèles. Elle apprend à structurer son contexte, à découper les tâches et à contrôler les résultats. Refuser toute dépense au nom de l’efficacité immédiate peut empêcher cette montée en compétence.

La bonne question n’est donc pas « combien de tokens avez-vous consommés ? », mais « qu’avez-vous obtenu grâce à cette consommation ? ». Le coût doit être rapproché du temps économisé, de la qualité produite, du risque réduit ou du chiffre d’affaires généré.

Quand le tokenmaxxing devient un mauvais indicateur

La consommation brute mélange des usages très différents. Elle favorise les tâches verbeuses, les gros modèles et les agents mal optimisés. Elle pénalise au contraire un salarié qui utilise un modèle léger, réemploie un contexte mis en cache ou formule une demande précise obtenant le bon résultat du premier coup.

Elle peut aussi produire des coûts difficilement prévisibles. Les conversations longues grossissent progressivement. Les outils renvoient parfois des sorties volumineuses. Plusieurs agents peuvent se répondre sans contrôle humain. Une automatisation mal bornée peut continuer à travailler alors que le résultat est déjà suffisant.

Pour piloter correctement l’IA, une entreprise doit suivre plusieurs mesures : coût par tâche terminée, temps réellement économisé, taux de réussite, qualité des livrables, corrections humaines nécessaires et satisfaction des utilisateurs. Le nombre de tokens reste utile pour comprendre la dépense, pas pour désigner le meilleur salarié.

Comment utiliser beaucoup d’IA sans gaspiller

La première règle consiste à donner au modèle le contexte utile, pas tout le contexte disponible. Un document bien sélectionné vaut mieux que cinquante fichiers sans rapport direct. Une synthèse de l’historique peut remplacer des mois de conversation.

Il faut ensuite borner les agents : nombre maximal d’itérations, budget de tokens, durée d’exécution, critères d’arrêt et validation humaine avant les actions coûteuses. Le modèle le plus puissant n’est pas indispensable pour toutes les étapes. Un modèle rapide et économique peut trier les données, puis transmettre uniquement les cas complexes à un modèle plus avancé.

Le cache est également essentiel lorsque les mêmes instructions, documents ou définitions d’outils sont utilisés à répétition. Anthropic recommande notamment de mettre en cache les instructions système, les documents volumineux, les outils et l’historique récurrent. Cette optimisation réduit le coût du contexte répété sans diminuer la qualité de la demande.

Questions fréquentes

Qu’est-ce que le tokenmaxxing ?

Le tokenmaxxing consiste à utiliser volontairement de très grandes quantités de tokens avec des outils d’intelligence artificielle. Le terme désigne aussi la compétition entre salariés lorsque la consommation de tokens devient un indicateur visible ou valorisé par l’entreprise.

Un prompt long consomme-t-il forcément beaucoup de tokens ?

Oui, un prompt long augmente le nombre de tokens d’entrée. Mais les consommations les plus élevées viennent généralement de l’accumulation : documents volumineux, historique complet, réponses longues, raisonnement interne, appels d’outils et nombreuses itérations d’agents.

Pourquoi Microsoft a-t-il limité certains usages ?

Microsoft a commencé à encadrer davantage les budgets après avoir constaté des dépenses très élevées chez certains utilisateurs internes. L’entreprise a rappelé que son objectif était la valeur produite par l’IA, pas la consommation maximale de tokens.

Le tokenmaxxing améliore-t-il la productivité ?

Pas automatiquement. Une forte consommation peut correspondre à une analyse complexe et utile, mais elle peut aussi provenir de requêtes répétitives, de boucles mal contrôlées ou de tâches sans valeur. Le résultat obtenu reste plus pertinent que le volume consommé.

Comment éviter de gaspiller des tokens ?

Il faut limiter le contexte aux informations utiles, définir un résultat attendu, réduire les itérations inutiles, utiliser le cache lorsque c’est possible et choisir un modèle adapté à la difficulté réelle de la tâche.