Le mot "tokenmaxxing" ressemble à une blague de bureau, mais il décrit un vrai changement dans les équipes tech. Après avoir poussé les développeurs à utiliser massivement les assistants IA, certaines entreprises commencent à regarder la consommation avec plus de précision. Atlassian suit davantage les usages internes, tandis que d'autres acteurs encouragent au contraire leurs employés à utiliser beaucoup de tokens pour accélérer le travail. Entre les deux, une question devient centrale : comment piloter l'IA quand l'expérimentation devient une facture récurrente ?
Pour les développeurs, le changement est concret. L'IA n'est plus seulement un abonnement mensuel à un assistant de code. Elle devient une ressource consommée à chaque requête avancée, chaque contexte long, chaque génération, chaque appel à un modèle plus coûteux. Les documents de GitHub autour de Copilot décrivent déjà des mécanismes de requêtes premium et de facturation à l'usage pour les organisations. Cela signifie que le coût n'est plus entièrement invisible.
Le sujet n'est pas de décourager l'usage. Au contraire, les assistants de code peuvent faire gagner beaucoup de temps lorsqu'ils sont bien intégrés. Le sujet est de comprendre où l'IA crée de la valeur et où elle devient une habitude coûteuse.
Le passage de l'outil au budget
Dans une première phase, les entreprises ont surtout cherché l'adoption. Il fallait que les équipes testent Copilot, Claude Code, Cursor, Gemini ou d'autres assistants, puis identifient les cas d'usage utiles : génération de tests, recherche dans un dépôt, documentation, refactoring, scripts, migration, revue de code.
Cette phase était nécessaire. On ne mesure pas la valeur d'un outil sans l'utiliser. Mais elle a aussi créé une zone grise. Un développeur peut lancer une grande quantité de requêtes sans que l'entreprise sache précisément si cela a produit du code maintenable, supprimé un blocage ou simplement remplacé une recherche classique.
Quand les coûts restent faibles, ce flou est acceptable. Quand les modèles deviennent plus puissants et plus chers, il ne l'est plus. Les directions techniques doivent alors trouver un équilibre : encourager l'usage pertinent sans transformer chaque interaction en demande d'autorisation.
Tous les tokens ne se valent pas
La mauvaise manière de piloter l'IA serait de compter uniquement le nombre de tokens consommés. Une requête longue peut être extrêmement rentable si elle résout un incident, accélère une migration ou évite plusieurs heures de recherche. À l'inverse, dix petites requêtes peuvent n'apporter aucune valeur si elles contournent une lecture attentive du code.
La bonne question est donc le ratio entre coût, risque et résultat. Un assistant utilisé pour produire une documentation interne à partir de sources contrôlées n'a pas le même profil qu'un agent qui modifie du code, lance des commandes et propose une pull request. Un contexte long sur un dépôt sensible n'a pas le même risque qu'une question générique sur une API publique.
Les équipes matures vont probablement créer des catégories d'usage : assistance légère, génération contrôlée, analyse profonde, agent avec outils, traitement de données sensibles. Chaque catégorie peut avoir ses propres règles, ses limites et ses métriques.
Le risque de la mauvaise métrique
Le danger est de transformer le pilotage en bureaucratie. Si les développeurs doivent justifier chaque requête, ils cesseront d'expérimenter ou déplaceront l'usage vers des comptes personnels moins visibles. L'entreprise perdra alors à la fois la productivité et la gouvernance.
L'autre danger est inverse : célébrer la consommation comme preuve de modernité. Le tokenmaxxing peut donner l'impression qu'une organisation avance vite, mais un volume élevé ne prouve pas la qualité. Il peut aussi signaler un manque de méthode, des prompts inefficaces, des outils mal configurés ou une absence de documentation.
Une bonne métrique doit relier l'usage à un résultat observable : temps de cycle, taux de tests, qualité des revues, incidents évités, dette réduite, satisfaction des équipes. Ce n'est pas parfait, mais c'est plus utile que de mesurer uniquement la quantité de requêtes.
Ce que les équipes peuvent mettre en place
La première étape est de rendre les coûts visibles sans les rendre culpabilisants. Un tableau de bord par équipe, par projet ou par type d'usage suffit souvent à ouvrir la discussion. L'objectif n'est pas de pointer un développeur, mais de comprendre les tendances.
La deuxième étape est d'établir des règles simples : quels dépôts peuvent être envoyés à quels outils, quelles données sont interdites, quels modèles sont autorisés, quand une revue humaine est obligatoire et comment gérer les logs. Les règles doivent être courtes, applicables et connues.
La troisième étape est d'investir dans les workflows. Un assistant bien connecté au dépôt, aux tests et à la documentation coûte parfois moins cher qu'un usage improvisé, parce qu'il a besoin de moins de contexte et produit des réponses plus directement exploitables.
Enfin, il faut accepter que l'IA devienne une ligne budgétaire normale du développement logiciel. Comme le cloud, l'observabilité ou la CI, elle doit être optimisée, pas simplement coupée.
Le tokenmaxxing est peut-être un terme passager. Le sujet, lui, restera. Les équipes qui gagneront ne seront pas celles qui consomment le plus de tokens, ni celles qui en consomment le moins. Ce seront celles qui sauront transformer ces requêtes en meilleurs produits, avec un coût et un risque compréhensibles.
