La fin du bar ouvert : penser en tokens, pas seulement en heures

Pendant deux ans, on a consommé l'IA comme on consomme l'électricité en logement : sans regarder le compteur. Cette époque tire à sa fin.

---

Le bar ouvert, c'est terminé

On le sentait venir. Les modèles sont devenus trop efficaces, trop puissants, trop coûteux à opérer pour que leur usage continue d'être servi en buffet à volonté. Les derniers modèles peuvent rouler des heures sans interruption, produire des résultats d'une précision étonnante, mobiliser des chaînes d'agents complètes — et chacune de ces secondes a un coût bien réel quelque part.

La nouvelle norme n'est plus de demander n'importe quoi à n'importe qui à n'importe quel moment. C'est d'utiliser le bon modèle pour la bonne tâche, en lui fournissant suffisamment d'informations pour qu'il livre ce résultat sans se perdre, et sans faire abstraction du contexte dans lequel on travaille.

L'époque où l'on pouvait démarrer une conversation le matin avec une tâche et la terminer le soir avec la même tâche, sans réfléchir à ce qu'on consomme entre les deux, est révolue.

Une nouvelle façon d'utiliser les modèles

Utiliser les modèles aujourd'hui, c'est un exercice pragmatique. Pas idéologique, pas paresseux. Pragmatique.

Cela veut dire :

• Comprendre la quantité d'information que le modèle utilise réellement pour accomplir la tâche.
• S'assurer qu'il utilise les bons outils — pas tous les outils, pas le plus puissant par défaut, mais ceux qui ont du sens.
• Se rapprocher des métriques que les fournisseurs nous rendent disponibles pour en apprécier la profondeur.

La notion de token faisait déjà partie de notre vocabulaire technique. Mais demain, elle va faire partie de notre façon de penser, au même titre que la notion d'heure-personne fait partie de la façon dont on chiffre un projet aujourd'hui.

Le token n'est pas un détail d'implémentation. C'est l'unité de coût d'une nouvelle classe de travail intellectuel.

L'unité de gestion change

Avant, notre unité de gestion, c'était le temps.

Le temps qu'on consacrait à développer une feature. Le temps qu'on consacrait à analyser le besoin d'un client. Le temps qu'on passait à livrer de la valeur. Toute notre gestion — projets, budgets, capacité, vélocité — reposait sur cette unité familière.

Ce temps n'a pas disparu. Mais il n'est plus seul.

La transition entre le moment où l'on n'utilisait pas l'IA et celui où l'on doit l'utiliser de la bonne façon est, elle aussi, terminée. Le confort de la pause d'apprentissage est passé. Aujourd'hui, il faut prendre en considération deux métriques en parallèle :

1. Le temps qu'on passe avec l'IA — parce qu'un humain est toujours dans la boucle, à orchestrer, à valider, à décider.
2. Le nombre de tokens que l'IA consomme pour atteindre l'objectif qu'on lui a donné.

C'est la combinaison de ces deux métriques qui nous permettra de mettre un coût réaliste sur chacune de nos interventions. L'une sans l'autre donne une vision faussée. Une tâche peut prendre 10 minutes humaines mais consommer pour 40 $ de tokens. Une autre peut tourner 2 heures en arrière-plan pour 0,80 $. Les deux scénarios existent, et ils n'ont pas la même logique de gestion.

La fin des forfaits qui cachent la vérité

Les forfaits et licences qui nous permettaient de prédire notre utilisation des modèles vont devenir de moins en moins présents. Pas parce que les fournisseurs sont méchants, mais parce que la mécanique économique ne tient plus.

Probablement qu'on va continuer à payer pour l'outil qui nous donne accès au modèle — l'IDE, l'agent, l'extension, la plateforme — sans que la consommation soit incluse dans cet abonnement. On va payer Copilot. On va payer Claude Code. On va payer la mensualité de l'outil. Mais l'utilisation qu'on en fera dépendra :

• Du nombre de tokens consommés.
• De l'ampleur de l'utilisation des modèles.
• Et surtout du choix des modèles que l'on va activer derrière l'outil.

C'est un changement structurel. Les organisations qui négociaient des licences globales et oubliaient le sujet jusqu'au renouvellement vont devoir mettre en place une vraie gouvernance de la consommation. Pas juste une politique d'usage. Une gouvernance, avec des seuils, des alertes, des budgets par équipe, et des arbitrages réguliers.

L'éducation à la consommation

Dans le futur — un futur très proche — il y aura une part d'éducation à faire. Pour les développeurs, mais aussi pour les individus en général.

Une éducation à la consommation de tokens.

Un peu comme aujourd'hui on regarde sa facture d'électricité, ou comme dans certaines régions on regarde sa facture d'eau potable, on va regarder sa facturation de tokens. Et avec cette habitude viendra une nouvelle compétence : choisir le meilleur modèle en fonction de ses propres besoins, de ses propres usages et de son propre budget.

Cela suppose de savoir lire ce qu'on consomme. De comprendre pourquoi un prompt mal cadré coûte trois fois plus cher qu'un prompt précis. De réaliser qu'un agent qui boucle pendant une heure parce qu'on l'a mal configuré, c'est l'équivalent d'avoir laissé le climatiseur en marche tout l'été dans une pièce vide.

Tant qu'on ne lit pas la facture, on ne change pas le comportement. Et tant qu'on ne change pas le comportement, la facture continue de monter.

Est-ce vraiment un changement de paradigme?

D'un autre côté — soyons honnêtes — est-ce qu'on parle vraiment d'un changement de paradigme? Ou est-ce qu'on parle d'un paradigme qu'on connaît déjà et qu'on n'a simplement pas encore appliqué à l'IA?

Quand on a besoin d'un professionnel, on prend celui qui est le plus en adéquation avec le besoin. On ne va pas chercher le meilleur avocat de la province pour gérer une chicane de clôture avec le voisin. On ne va pas réserver le meilleur préparateur physique olympique pour une douleur à l'épaule.

On choisit toujours le professionnel le plus adapté à notre besoin et à notre budget.

Pourquoi cela serait-il différent avec l'IA? Pourquoi enverrait-on systématiquement la tâche la plus triviale au modèle le plus puissant et le plus coûteux, simplement parce qu'on a accès à un bouton qui le permet?

Il y aura toujours certaines organisations qui vont préférer prendre le meilleur des meilleurs, tout le temps, parce que l'avantage qu'elles en tirent est tellement flagrant qu'elles refusent de se préoccuper du coût. C'est un choix légitime, et pour certains marchés, c'est même probablement le bon.

Mais la majorité des organisations vont devoir développer une gestion des IA à la même hauteur que la gestion de leurs fournisseurs : avec des grilles de sélection, des contrats, des alternatives, des évaluations périodiques, et un sens aigu du rapport qualité-prix.

Sonnet ou Opus? La vraie question

La question revient sans cesse dans les équipes : est-ce qu'il y a vraiment une différence majeure, ou même assez marquée, entre un modèle plus standard comme Sonnet et un modèle plus premium comme Opus, quand on veut faire une tâche simple?

La réponse honnête est nuancée. Il y a probablement un léger avantage à utiliser un gros modèle, même sur une tâche simple. Une formulation un peu plus juste, une réponse un peu mieux structurée, une compréhension marginalement plus fine du contexte. Mais ce n'est pas toujours le cas, et même quand ça l'est, l'écart est souvent invisible à l'œil nu.

La vraie question n'est donc pas « est-ce que le gros modèle est meilleur? ». C'est « est-ce qu'il est meilleur assez pour justifier de payer le premium de tokens, parfois 5 à 10 fois plus cher, sur ce cas d'usage précis? »

Pour la grande majorité des cas simples, la réponse est non. On ne va probablement pas payer le premium pour :

• Une traduction d'un courriel.
• Une correction de texte ou de grammaire.
• Une reformulation plus claire d'un paragraphe.
• Une classification simple ou un résumé court.
• Un refactor mécanique ou une transformation de format.

Pour ces tâches, un modèle de base — voire un petit modèle local — fait le travail à une fraction du coût. Garder Opus pour ces cas-là, c'est exactement comme appeler un chirurgien pour mettre un pansement : techniquement il sait le faire, mais ce n'est pas une bonne allocation de la ressource.

À l'inverse, dès qu'on entre dans le raisonnement complexe, l'analyse architecturale, la synthèse de documents ambigus ou la prise de décision à fort enjeu, l'écart entre les modèles devient flagrant — et payer le premium devient évident.

Le piège n'est pas d'utiliser un gros modèle. C'est de l'utiliser par défaut, sans se poser la question.

L'intelligence a un coût

L'éducation à la consommation de tokens va se faire avec un parallèle naturel : l'humain.

C'est une intelligence artificielle, mais c'est quand même une intelligence. Et l'intelligence, qu'elle soit biologique ou silicée, a un coût.

On ne demande pas à un chercheur principal de répondre à un courriel de routine. On ne mobilise pas un consultant senior à 400 $ de l'heure pour rédiger un compte-rendu de réunion. On ne fait pas analyser un contrat trivial par un associé d'un grand cabinet juridique. Pas parce qu'ils en seraient incapables — au contraire — mais parce que la valeur produite ne justifie pas le coût mobilisé.

Cette intuition que nous avons tous, naturellement, pour les ressources humaines, il va falloir la développer pour les modèles d'IA. C'est exactement le même réflexe : adapter la qualité de l'intelligence mobilisée à la qualité de l'intelligence requise par la tâche.

Et comme pour les humains, cela ne veut pas dire mépriser les modèles plus modestes. Ça veut dire les utiliser pour ce qu'ils font bien, et réserver les modèles premium pour ce qui les justifie vraiment.

Concrètement, par où commencer?

Si tout cela vous parle, voici quelques pistes d'action immédiates :

Mesurer avant de juger. Avant de décider que l'IA coûte cher ou pas cher, instrumentez. Combien de tokens par développeur par jour? Quels modèles sont réellement utilisés? Quelles tâches consomment 80 % du budget? La plupart des organisations n'en ont aucune idée.

Cartographier les tâches selon le bon modèle. Toutes les tâches ne méritent pas le même modèle. Refactor trivial, génération de boilerplate, transformation de format : un petit modèle local ou un modèle d'entrée de gamme suffit. Analyse architecturale, refactor risqué, raisonnement complexe : là, le modèle premium se justifie.

Donner au modèle ce dont il a besoin, et rien de plus. Le contexte coûte des tokens. Un projet entier balancé en contexte « au cas où », c'est un gaspillage assumé. Apprenez à fournir le contexte minimal pertinent. Vos résultats seront meilleurs et moins chers.

Mettre en place une gouvernance légère. Budgets par équipe, alertes sur les dépassements, revues mensuelles. Pas pour fliquer, pour responsabiliser. Une équipe qui voit sa consommation est une équipe qui l'optimise.

Former les équipes à lire leur facture. Au sens propre. Comprendre la différence entre tokens d'entrée et tokens de sortie, entre prompt caché et prompt explicite, entre un appel synchrone et un agent qui itère. Cette littératie économique deviendra aussi fondamentale que la lecture d'un coût d'infrastructure cloud.

Et ensuite?

L'unité de gestion du travail intellectuel est en train de basculer. Le temps reste, mais il s'accompagne désormais d'une seconde dimension : la consommation. Les organisations qui vont réussir cette transition ne sont pas celles qui auront les plus gros budgets IA. Ce sont celles qui auront développé une culture de la mesure et du choix.

Le bar ouvert, c'était confortable. Mais le confort n'a jamais été un modèle d'affaires durable.

---

La prochaine fois que vous lancerez un agent sur une tâche, posez-vous la question : combien ça va coûter, vraiment? Si vous ne savez pas y répondre, c'est déjà la réponse.