Les tokens, le nouveau pétrole que vous brûlez sans le savoir

Gagnons tous un peu de temps: Vous utilisez l'IA tous les jours ?! Vous la trouvez puissante, rapide, bluffante. Vous l'avez intégrée dans vos workflows, vos outils, peut-être même vos pipelines de production. Et quelque part, sans vraiment vous l'avouer, vous avez fini par la considérer comme quelque chose d'évident. De disponible. D'illimité.

C'est là que le problème commence.

Parce que derrière chaque réponse générée, chaque ligne de code produite, chaque document résumé, il y a une ressource qui est consommée. Une ressource qui se mesure, qui se facture, et qui s'épuise. On l'appelle le token. Et la grande majorité des équipes qui utilisent l'IA aujourd'hui n'ont aucune idée de combien elles en brûlent, ni pourquoi, ni à quel coût (jusqu’au moment où la DSI présente la facture ^^).

Faisons une comparaison avec une autre ressource que tout le monde connaît:

Le Pétrole

(source wikipédia : Pétrole)

Dans un pays producteur de pétrole, l'essence est quasi gratuite. On laisse le moteur tourner à l'arrêt. On ne choisit pas son itinéraire pour économiser du carburant. On ne pense pas à optimiser, pourquoi le ferait-on ? La ressource est là, abondante, bon marché, apparemment inépuisable.

Dans un pays importateur ? Chaque litre compte. On conduit différemment. On choisit un véhicule plus sobre. On réfléchit avant d'appuyer sur l'accélérateur. Comme avec l'éco-conduite par exemple (source wikipédia : Éco conduite).

La plupart des équipes tech se comportent aujourd'hui comme si elles vivaient dans un pays producteur. Elles vivent en réalité dans un pays importateur**.** Elles ne le savent pas encore ou elles font semblant de ne pas le savoir.

Maintenant, revenons à nos tokens, car cela va devenir plus intéressant. Certains abonnements IA rechargent un quota de tokens toutes les 8 heures, toutes les 24 heures, tous les mois. Et cette mécanique de recharge crée une illusion particulièrement dangereuse : "de toute façon ça se recharge, c'est comme une énergie renouvelable, non ?"

Non. Il ne faut pas confondre renouvelable et renflouement.

Les tokens ne poussent pas dans un champ. Ils ne tombent pas du ciel entre deux sprints. La recharge est un mécanisme commercial, une façon pour les providers de lisser leur facturation. Ce n'est pas une promesse de ressource infinie. Ce n'est pas du solaire ni de l'éolien.

C'est un réservoir. Et les réservoirs se vident. Comme pour un barrage hydraulique, s’il ne pleut pas assez, alors on aura plus d’eau pour produire de l’électricité.

Alors posons la question qui fâche : et si vous brûliez tout votre quota en cinq jours ? Vous faites quoi le reste du mois ? Vous attendez la recharge en regardant le plafond ? Vous expliquez à votre équipe que l'IA est "indisponible" jusqu'au 1er ? Vous sortez la carte bleue pour acheter des tokens supplémentaires, en vous demandant pourquoi vous avez un abonnement fixe ? (C’est le principe des abonnements Claude Max 5x ou 20x).

C'est l'équivalent de faire le plein le 1er janvier et d'avoir le réservoir à sec le 6. Techniquement, vous pouvez encore vous déplacer. À pied. À vélo. Pratique pour faire les courses du quartier. Nettement moins pratique pour livrer un projet en production.

La recharge ne change pas la nature de la ressource. Elle donne juste l'illusion qu'elle est inépuisable. Et c'est précisément cette illusion qui génère le gaspillage.

Cet article ne va pas vous demander de consommer moins. Il va vous demander de consommer mieux.

Comprendre ce qu'est un token. C’est :

• savoir comment les différents providers vous facturent et pourquoi les modèles ne se valent pas tous selon votre usage.
• identifier où partent vos tokens sans que vous le voyiez.
• mettre en place les bons réflexes, les bons outils, les bonnes pratiques pour ne plus jamais brûler ce qui n'a pas besoin de l'être.

Parce qu'une équipe qui ne pilote pas sa consommation de tokens aujourd'hui, c'est une équipe qui va avoir une très mauvaise surprise sur sa facture, sur ses performances, ou sur les deux dans un avenir proche.

Le réservoir ne se remplit pas tout seul. Autant savoir ce qu'on y met.

C'est quoi, un token ? La base avant tout

Avant de parler d'optimisation, de coûts, de stratégie, nous devons commencer par les bases. Parce que le mot "token" est partout :

• dans les interfaces,
• dans les documentations,
• dans les factures

Et pourtant, si vous demandez à dix personnes de l'expliquer, vous obtenez dix réponses différentes. Souvent vagues. Parfois fausses.

Ce qu'un token n'est pas

Un token, ce n'est ni un mot, ni un caractère, ni une ligne. ni une requête.C'est une unité de traitement. La plus petite brique que le modèle utilise pour lire ce que vous lui envoyez et pour construire ce qu'il vous répond.

En pratique, nous pouvons utiliser une règle approximative pour se représenter ce à quoi correspond un token : 1 token ≈ 0,75 mot en anglais (source OpenAi : le token). Pour la langue française, c'est légèrement moins favorable. Cette dernière étant plus riche en caractères, et les modèles ont été majoritairement entraînés sur de l'anglais. Tout cela conduit une consommation en moyenne de 10 à 20% en plus de tokens que son équivalent anglais.

Quelques repères concrets :

• "Bonjour" → 1 token
• "L'optimisation des tokens est cruciale" → ≈ 8 tokens
• Un prompt de 500 mots → ≈ 650 à 700 tokens
• Ce paragraphe que vous venez de lire → ≈ 120 tokens

Ce n'est pas énorme. Jusqu'à ce que vous multipliez ça par des milliers d'appels par jour. L’effet de masse produit une augmentation de l’échelle très importante.

Les deux compteurs qui tournent en permanence

Deux compteurs ? Cela peut sembler déroutant au premier abord, mais quand vous interagissez avec un modèle, il y a toujours deux compteurs actifs simultanément (source OpenAi : différences entre les tokens). Et ils ne coûtent pas la même chose.

Le premier compteur : les tokens entrants. Il prend en charge tout ce que vous envoyez à votre modèle, en résumé cela correspond à votre prompt, bien sûr. Mais aussi le contexte de la conversation, les fichiers que vous joignez, les instructions que vous avez configurées (les règles), l'historique des échanges précédents. Tout ce que le modèle doit lire avant de pouvoir répondre. Et cela peut vite monter, plus vous lui demandez de choses en même temps, plus le compteur tourne.

Le deuxième compteur : les tokens sortants. Tout ce que le modèle génère. Sa réponse, le code produit, le document rédigé, l'explication fournie, les images, etc...

Pourquoi cette distinction est-elle importante ? Parce que les tokens sortants coûtent généralement plus cher que les tokens entrants. La logique est simple : lire demande moins d'effort que produire. Pour le modèle comme pour vous, il est plus facile de lire cet article que de devoir l’écrire, je peux vous en assurer.

Chez la plupart des providers, le ratio est de l'ordre de 1 pour 3 à 1 pour 5. Un token en sortie coûte trois à cinq fois plus qu'un token en entrée. Ce que ça signifie concrètement : demander à l'IA de produire des réponses longues et détaillées quand une réponse courte suffit, c'est de l'argent jeté par la fenêtre.

La fenêtre de contexte, le concept que tout le monde ignore jusqu'à ce que ça pose problème

Chaque modèle a une limite. Un nombre maximum de tokens qu'il peut traiter en une seule fois ce qu'on appelle la fenêtre de contexte.

GPT-4o : 128 000 tokens (source OpenAI developers). Claude 3.5 Sonnet : 200 000 tokens. Certains modèles plus récents poussent au-delà du million. Les chiffres donnent le vertige et c'est exactement le problème.

Ces fenêtres immenses créent l'illusion qu'on peut tout envoyer sans réfléchir :

• la codebase entière
• tous les documents du projet
• l'historique complet des conversations depuis le début du sprint.

Et on finit par se dire : "Tout tient dans le contexte du modèle, autant en profiter."

Mauvaise idée. À plusieurs niveaux.

D'abord, le coût. Chaque token dans la fenêtre de contexte est un token facturé, qu'il soit utile ou non. Envoyer 50 000 tokens de contexte pour poser une question qui en nécessitait 500, c'est payer cent fois trop cher et consommer des ressources pour rien.

Ensuite, la qualité. Contre-intuitivement, plus la fenêtre de contexte est remplie, moins le modèle est précis. Noyé sous un volume d'informations dont une grande partie n'est pas pertinente, le modèle dilue son attention. Les chercheurs appellent ça le problème du "lost in the middle" (source Cornell University), les informations placées au milieu d'un contexte très long sont statistiquement moins bien traitées que celles placées au début ou à la fin.

Plus de contexte ne veut pas dire meilleure réponse. Ça veut dire plus de bruit pour le même signal. C’est comme les études de texte à l’école, il faut trouver l’information dans un texte qui fait une page. Souvenez vous du temps que cela prend et de l’énergie dépensée.

Les tokens invisibles, ce que l'IA consomme avant même de commencer

Et maintenant, le point passé sous silence quand vous souscrivez un abonnement.

Lorsque vous lancez une session, démarrez un agent, ou ouvrez un outil comme Cline ou Cursor, le modèle ne part pas du tout de zéro. La première chose qu’il va faire c’est de construire son contexte de travail. Il en a besoin pour comprendre dans quel écosystème il va devoir “travailler” :

• Identifier les outils à sa disposition.
• Lire les fichiers de configuration.
• Saisir les contraintes du projet.
• Comprendre qui fait quoi dans le projet.
• Lire les règles disponibles de façon générale ou pour le projet.

Tout ça se paie en tokens. Avant que vous ayez tapé la moindre instruction.

C'est l'équivalent de ce qui se passe quand vous arrivez sur un nouveau sujet ou projet. Avant d’écrire du code ou de la documentation, vous allez être “onboardé” sur le projet par les membres de l’équipe :

• une présentation de l'entreprise,
• du projet,
• des parties prenantes,
• des contraintes techniques.

Ce temps existe, il a un coût et personne ne s'en étonne.

La différence avec l'IA : ce coût est invisible, vous ne voyez que le petit loader qui tourne dans le meilleur des cas, ou vous ne voyez rien car cela est fait en arrière plan. Il ne s'affiche pas dans une ligne dédiée survotre facture. Il ne s'annonce pas avant de se produire. Il se prend silencieusement sur votre quota, à chaque session, à chaque redémarrage d'agent, à chaque nouvelle conversation.

Ce que ça implique concrètement :

• Un contexte mal structuré au démarrage = des tokens brûlés pour reconstruire un contexte de zéro à chaque session
• Un agent mal configuré qui relit tout l'environnement à chaque appel = une fuite lente, régulière, invisible
• Des instructions système trop longues et mal ciblées = un ticket d'entrée trop cher avant même d'avoir posé la première question

La bonne nouvelle : c'est l'un des gaspillages les plus faciles à corriger. Bien structurer son contexte initial une fois, c'est économiser des tokens à chaque interaction qui suit. L'investissement de départ est minimal. Le retour est immédiat. Cela se traduit souvent par plus de tâches réalisées ou des sessions de token qui durent plus longtemps.

Ce que vous venez de lire, c'est la mécanique de base. Pas glamour. Pas spectaculaire. Mais indispensable, parce qu'on ne peut pas optimiser ce qu'on ne comprend pas.

La suite, c'est de regarder comment les différents providers vous facturent cette mécanique. Et là, les écarts commencent à devenir sérieusement intéressants.

Le panorama des modèles de facturation

Tous les providers d'IA ont un point commun : ils vous vendent des tokens.

La façon dont ils s'y prennent, en revanche, est très différente. Et ces différences ne sont pas sans conséquences, elles ont un impact direct sur la façon dont vous (et vos équipes) allez consommer ces tokens pour travailler avec l’IA. Parce que la structure de facturation influence le comportement. Toujours.

Le modèle à l'usage

C'est le modèle le plus simple dans sa facturation. Et potentiellement le plus dangereux pour votre porte monnaie si vous ne le pilotez pas.

AWS Bedrock, Vertex AI (Google Cloud), Azure OpenAI fonctionnent sur ce principe : chaque token consommé est un token facturé. Pas de forfait, pas de quota, pas de plafond.

Vous consommez, vous payez. En temps réel. Au centime près.

L'avantage est simple : la flexibilité, c’est prévisible sur le papier, et parfaitement adapté aux usages irréguliers. Une équipe qui utilise l'IA de façon intensive en début de sprint et presque pas en fin de cycle ne paie que ce qu'elle utilise vraiment.

Mais voilà le revers de ce système : L'absence de limite n'est pas une protection => c'est une exposition.

Un agent mal conçu qui boucle sur lui-même. Un pipeline qui ré-envoie tout le contexte à chaque étape. Une automatisation lancée en production sans avoir été testée à l'échelle. Dans ces cas-là, le compteur tourne. Sans s'arrêter. Sans vous prévenir. Jusqu'à ce que vous ouvriez la facture du mois. Certains fournisseurs proposent des systèmes pour limiter ou prévenir de l’utilisation tout de même.

Certaines équipes ont découvert des additions à cinq chiffres pour des workloads qu'elles pensaient maîtriser. Pas parce que l'usage était illégitime, parce que personne n'avait mis d'alerte, ni de budget, ni de limite. Le modèle à l'usage est un outil puissant entre les mains de ceux qui le pilotent. C'est une bombe à retardement pour les autres. Comme pour d’autres aspects quand on utilise l’IA sans la maîtriser.

Le modèle par abonnement avec quota rechargeable

C'est le modèle que vous connaissez probablement le mieux. Claude (Anthropic), ChatGPT (OpenAI) en version grand public, et leurs déclinaisons Pro ou Team : vous payez un forfait mensuel fixe, vous obtenez un quota de tokens, et ce quota se recharge à intervalles réguliers : toutes les 8 heures, toutes les 24 heures, ou en début de mois selon les offres.

C'est rassurant. C'est simple. C'est prévisible budgétairement.

Et c'est exactement ce qui rend ce modèle trompeur si on ne fait pas attention.

Parce que le forfait fixe crée un biais cognitif très puissant : "j'ai payé, donc je peux consommer". On ne pense plus en termes de coût marginal. On pense en termes de droit acquis. Et ce glissement mental est le début du gaspillage.

La réalité : votre quota est un réservoir, pas un robinet ouvert en permanence. Et comme tous les réservoirs, il se vide. Brûlez vos tokens trop vite parce que vous avez laissé un agent tourner sans supervision. Et vous vous retrouvez à attendre la prochaine recharge les bras croisés (si c’est mensuel, l’attente va être très longue).

Certains d’entre vous ont probablement connu ça par le passé, avec le forfait data mobile. Le 20 du mois, les données sont épuisées, et on passe en 128 Kbps (avant l’adsl et les forfaits illimités). Techniquement, vous êtes toujours connecté. En pratique, vous ne l'êtes plus vraiment.

Avec l'IA, c'est pareil, sauf que votre productivité, elle, n'attend pas la recharge.

Le modèle hybride

C'est le modèle que les organisations sous-estiment le plus systématiquement.

GitHub Copilot Enterprise, Cline connecté à une API backend, certaines offres Azure : une base fixe mensuelle, rassurante, prévisible et à laquelle s'ajoute une consommation variable selon l'usage réel.

Le problème : le coût fixe rassure le décideur, le variable surprend le comptable.

Concrètement, voilà ce qui se passe dans beaucoup d'organisations. Le budget est validé sur la base de l'abonnement fixe. Les équipes déploient. L'usage monte. Les agents tournent. Les appels s'accumulent. Et en fin de mois, la facture réelle est deux à trois fois supérieure à ce qui avait été budgété parce que personne n'avait anticipé la partie variable.

Ce n'est pas un problème de mauvaise foi. C'est un problème de visibilité. Et la visibilité, ça se construit. C’est exactement la même problématique pour la surveillance de vos hébergements.

Quel mode de facturation correspond réellement à votre usage ?

Si votre consommation est régulière et prévisible, je vous conseille de prendre un abonnement avec quota qui peut être plus économique et plus simple à gérer.

Si elle est irrégulière, avec des pics liés à des phases de projet alors le mode de facturation à l'usage sera plus adapté.

Si vous avez des automatisations en production qui tournent en continu, vous aurez besoin d'un mode de facturation avec des garde-fous budgétaires, quelle que soit la structure tarifaire.

La plupart des organisations ne se posent pas cette question. Elles choisissent le provider qu'elles connaissent, souscrivent à l'offre qui semble raisonnable, et découvrent six mois plus tard que leur usage réel ne correspond pas du tout au mode de facturation qu'elles ont choisi.

Ce n'est pas une question de quel provider est le meilleur. C'est une question de : quel mode de facturation est aligné avec la façon dont vous travaillez vraiment ?.

Et pour répondre à ça, il faut d'abord comprendre pourquoi l'optimisation n'est pas qu'une affaire de budget — c'est une affaire de performance, de stratégie, et de responsabilité. C'est ce qu'on va voir maintenant.

Pourquoi optimiser et dans l'intérêt de qui ?

On pourrait résumer cette section en une phrase : parce que ça coûte de l'argent.

Ce serait vrai. Mais, si on ne se concentrait que sur cela, ce serait aussi passer à côté de l'essentiel.

Parce que le coût financier est la partie visible de l'iceberg.

C’est celle qui finit par convaincre les décideurs quand la facture arrive. Mais en dessous de la surface, il y a trois autres raisons d'optimiser et elles sont au moins aussi importantes. Parfois plus.

L'intérêt financier

Commençons par l'évident. Un prompt mal structuré qui envoie dix fois plus de tokens que nécessaire. Multiplié par mille appels par jour. Multiplié par trente jours. Multiplié par dix développeurs dans l'équipe. Le calcul devient très vite désagréable.

Ce n'est pas de la théorie. Les équipes qui ont commencé à mesurer leur consommation réelle de tokens ont régulièrement découvert des écarts qui font mal. Des pipelines qui re-envoyaient l'intégralité du contexte projet à chaque étape, alors qu'une fraction suffisait. Des agents configurés pour produire des réponses exhaustives systématiquement, alors que la tâche appelait une réponse courte et ciblée. Des workflows automatisés que personne n'avait optimisés depuis leur mise en production CAR "ça tournait" et que personne ne regardait la facture de près.

Résultat : des factures bien supérieures à ce qu'elles auraient dû être. Pas à cause d'un usage excessif. À cause d'un usage inefficace.

Pour les décideurs, le message est simple : les tokens sont un nouveau poste de coût d'infrastructure. Aussi réel que l’ordinateur, le stockage ou la bande passante. Et comme tous les postes d'infrastructure, il se pilote ou il dérive. A titre de comparaison, votre licence Intellij à 600e par an, cela donne 50e par mois, et l’abonnement Claude Max est à 100$ par mois soit 1200 $ par an. Soit pour simplifier, le double.

La bonne nouvelle : c'est aussi l'un des postes les plus faciles à optimiser une fois qu'on l'a identifié. Des gains de 40 à 60% sur la consommation sont atteignables sans changer de provider, sans changer d'outil, et sans réarchitecturer quoi que ce soit. Juste en travaillant mieux les prompts, le contexte, la structure des appels et en gérant bien ses extensions et serveurs MCP (on y reviendra dans un prochain article^^).

La performance

Voilà le point contre-intuitif. Celui qui surprend le plus souvent.

Comme déjà expliqué : “Plus de tokens ne veut pas dire meilleure réponse”.

C'est pourtant l'hypothèse implicite derrière beaucoup de pratiques. On envoie tout le contexte parce qu'on ne sait pas ce qui va être utile. On rédige des prompts longs et détaillés parce qu'on pense que plus d'informations produisent plus de précision. On laisse l'historique de conversation s'accumuler parce que "le modèle a besoin de mémoire".

En réalité, un modèle noyé sous un volume d'informations non pertinentes produit des réponses moins précises, moins fiables, et moins cohérentes qu'un modèle qui reçoit un contexte ciblé et bien structuré.

Résultat : vous payez pour des tokens qui non seulement ne servent pas, mais qui dégradent activement la qualité de ce que vous obtenez.

C'est le paradoxe de l'abondance appliqué à l'IA. Donner trop d'informations à un modèle, c'est comme briefer un collaborateur pendant quatre heures sur un sujet qui en demandait vingt minutes. À la fin du brief, il est submergé, confus, et moins efficace que s'il avait reçu les trois points essentiels et rien de plus.

Optimiser les tokens : C'est aussi améliorer ce qu'on reçoit en retour.

L'intérêt stratégique

Celui-là, les décideurs ont du mal à le voir venir. Jusqu'à ce qu'il soit trop tard.

Une organisation qui consomme des tokens sans les mesurer, sans les piloter, sans les comprendre construit une dépendance invisible. Elle s'habitue à un certain niveau de service, à un certain volume d'usage, à un certain modèle de provider. Et quand ce provider décide d'augmenter ses tarifs, ce qui arrive (et arrivera de plus en plus), elle se retrouve sans levier.

Pas de données sur sa consommation réelle. Pas de benchmark pour comparer. Pas de marge de manœuvre pour réduire rapidement sans casser ses workflows. Juste une facture qui augmente et une dépendance découverte trop tard.

Les providers le savent. C'est exactement pour ça que les offres d'entrée sont attractives, que les intégrations sont facilitées, que la migration vers un concurrent est rendue aussi complexe que possible. Le modèle économique repose sur votre inertie.

La seule façon de ne pas subir cette dynamique : connaître sa consommation, la mesurer, et maintenir la capacité de la réduire ou de la déplacer si nécessaire. Ce n'est pas de la paranoïa, c'est de la gestion de risque élémentaire. Le même raisonnement que vous appliquez déjà à vos fournisseurs cloud, à vos licences logicielles, à vos contrats d'infrastructure.

Les tokens ne font pas exception. Ils méritent le même niveau d'attention.

L'intérêt environnemental

On va en parler quand même, même si c’est inconfortable.

Derrière chaque token consommé, il y a du calcul réel. Des GPU qui tournent, dans des datacenters réels, qui consomment de l'électricité réelle, qui produisent de la chaleur réelle, qui nécessitent de l'eau réelle pour être refroidis (le refroidissement par eau est toujours plus performant que par air : source Intel).

L'entraînement des grands modèles de langage est documenté comme particulièrement énergivore, GPT-3 aurait consommé 1 287 MWh soit la consommation de 130 foyers français pour un an ou l'équivalent de plusieurs centaines de vols transatlantiques pour son seul entraînement (calculé par l’université de Californie). Mais l'inférence, c'est-à-dire chaque utilisation du modèle, chaque requête, chaque token généré quant à lui représente une consommation continue et cumulée qui commence à peser lourd à l'échelle de l'industrie.

Ce sujet est encore peu débattu dans les équipes de développement. Il ne le sera pas longtemps. Les régulateurs s'y intéressent. Les DSI de grands groupes commencent à intégrer l'empreinte IA dans leurs bilans carbone. Les clients et partenaires vont demander des comptes.

Optimiser sa consommation de tokens, c'est aussi réduire son empreinte numérique. Pas de façon héroïque. Pas de façon suffisante à elle seule. Mais de façon réelle, mesurable, et directement liée à chaque décision de conception qu'on prend aujourd'hui.

Un prompt inutilement long n'est pas seulement un centime gaspillé. C'est aussi quelques watts gaspillés. Multipliés par des millions d'appels quotidiens à l'échelle d'une industrie entière, le calcul commence à avoir une signification qui dépasse la ligne budgétaire.

En résumé, nous avons quatre raisons d'optimiser. Quatre intérêts distincts : financier, performance, stratégique et environnemental. Quatre arguments qui s'adressent à des interlocuteurs différents dans votre organisation.

Vous n'avez pas besoin de tous les utiliser en même temps. Vous avez juste besoin de savoir lequel présenter à qui.

Ce qui compte maintenant, c'est de savoir comment optimiser. (on verra ça dans un prochain article^^)

Conclusion : Consommez mieux, pas moins !!

Faisons le bilan.

Les tokens ne sont pas une abstraction technique réservée aux ingénieurs qui configurent des pipelines. Ce sont des unités de valeur qui sont mesurables, facturables, épuisables. Ils ont un coût financier que vos équipes ne voient pas toujours.

Ils ont un impact sur la qualité de ce que vous produisez que personne ne vous a expliqué. Ils créent une dépendance stratégique que vous construisez silencieusement à chaque appel. Et ils ont une empreinte environnementale que l'industrie ne pourra pas ignorer encore très longtemps.

Ce n'est pas une ressource gratuite. Ce n'est pas une ressource renouvelable. Et ce n'est pas une ressource qu'on peut se permettre de gaspiller indéfiniment et inutilement.

Revenons à l'image du pétrole.

Les pays qui ont construit une économie durable autour de l'énergie ne sont pas ceux qui en avaient le plus. Ce sont ceux qui ont appris à en faire le meilleur usage. Qui ont investi dans l'efficacité, développé des pratiques sobres, construit des systèmes qui consomment juste ce dont ils ont besoin et rien de plus.

Les autres ont vécu sur une rente. Confortablement. Jusqu'à ce que les prix montent, que les réserves diminuent, ou que le monde change les règles du jeu. Et là, sans culture de l'optimisation, sans réflexes construits, sans données sur leur propre consommation ils se sont retrouvés exposés.

Vous voyez où ça mène, comme par exemple l’Île de Nauru.

L'IA générative est une technologie puissante. Transformatrice, on l'a dit dans un article précédent, et on le maintient. Mais puissant ne veut pas dire gratuit. Et transformer ne veut pas dire illimité.

Les équipes qui vont tirer le meilleur parti de cette technologie dans la durée ne sont pas celles qui vont consommer le plus. Ce sont celles qui vont consommer le mieux. Celles qui comprennent ce qu'elles utilisent, mesurent ce qu'elles dépensent, et font des choix conscients plutôt que de laisser la consommation se faire par défaut.

Ce n'est pas une contrainte. C'est une compétence.

Et cette compétence ne tombe pas du ciel. Elle se construit. Avec les bons réflexes sur la construction des prompts. Avec la bonne gestion du contexte. Avec les bons outils pour mesurer, alerter, arbitrer. Avec la bonne culture dans les équipes pour ne pas traiter l'IA comme un robinet ouvert en permanence.

C'est précisément ce qu'on va explorer dans un prochain article : les leviers concrets d'optimisation, les outils disponibles aujourd'hui, et les pratiques qui font la différence entre une équipe qui subit ses coûts IA et une équipe qui les pilote.

Parce qu'il y a une bonne nouvelle dans tout ça : les gaspillages les plus importants sont aussi les plus faciles à corriger, une fois qu'on sait où regarder.

En attendant, une seule question à vous poser ce soir.

Savez-vous combien de tokens votre équipe a consommés ce mois-ci ?

Si la réponse est non : vous savez par où commencer.

On ne gère bien que ce qu'on mesure.

Et on ne mesure bien que ce qu'on a décidé de prendre au sérieux.