Tokens d’entrée
Tout ce que tu envoies : ton message, l’historique, les fichiers lus, les instructions permanentes, la description des outils branchés. C’est renvoyé à chaque tour, d’où le coût qui grimpe sur une longue session.
1 · L’unité de base
Le token, l’essence que tu paies
Un modèle ne lit pas des mots mais des tokens : des fragments de texte. En français, compte environ trois quarts de mot par token — un mot courant en fait un, un mot rare ou un identifiant de code peut en faire trois ou quatre.
Tokens de sortie
Ce que le modèle écrit. Généralement bien plus cher à l’unité que l’entrée, mais en volume beaucoup plus faible. Demander de la concision fait donc des économies réelles.
Tokens de raisonnement
Sur les modèles qui « réfléchissent », une partie du travail est produite avant la réponse visible. Tu ne la lis pas toujours, mais elle est comptée. C’est ce qui rend ces modèles meilleurs et plus coûteux.
La conséquence pratique : une conversation de cinquante messages ne
coûte pas cinquante fois un message. Elle coûte bien plus, parce que chaque nouveau
tour renvoie tout l’historique. C’est la vraie raison économique de repartir d’un
contexte propre entre deux tâches.
2 · La fenêtre
Le contexte, et pourquoi ce n’est pas de la mémoire
La fenêtre de contexte, c’est la quantité de texte que le modèle peut avoir sous les yeux en même temps. Au-delà, il faut couper, résumer, ou oublier.
Point crucial : entre deux sessions, un modèle ne retient rien. Ce qui donne l’impression de mémoire, c’est un mécanisme extérieur qui réinjecte du texte — ton fichier d’instructions, un résumé de session, une base vectorielle.
Autre point mal connu : une grande fenêtre ne garantit pas une bonne attention. Plus le contexte est chargé, plus les informations du milieu ont tendance à être négligées. Un contexte pertinent et court bat un contexte exhaustif et long.
1
Ce qui la remplit vite
Les gros fichiers lus en entier, les sorties de commandes verbeuses, les serveurs d’outils inutilisés, et l’historique accumulé.
2
Les signaux de saturation
Il oublie une consigne du début, refait ce qu’il a déjà fait, ou perd le fil d’un fichier qu’il vient de modifier.
3
Les remèdes
Repartir propre, résumer la session, indexer le code plutôt que tout relire, et n’activer que les outils utiles.
3 · Les limites
Pourquoi un modèle invente
L’hallucination n’est pas un bug qu’on corrigera un jour : c’est la contrepartie directe du mécanisme. Un modèle produit la suite la plus plausible — et le plausible n’est pas toujours le vrai.
La fonction qui n’existe pas
Une méthode au nom parfaitement logique, une option de librairie très crédible… mais inventée. Ça arrive surtout quand le modèle répond de mémoire au lieu de lire la source. Le remède : lui faire ouvrir la doc ou le code réel.
La confiance constante
Le ton reste assuré, que la réponse soit juste ou fausse. Il n’y a pas de signal de doute fiable dans la formulation. Ne prends jamais l’assurance pour de la certitude.
La date de coupure
L’entraînement s’arrête à un moment donné. Sur une librairie qui a changé depuis, le modèle donnera l’ancienne API en toute bonne foi. D’où l’intérêt de la recherche web et de la lecture de doc.
Le calcul et le comptage
Compter des occurrences, faire de l’arithmétique précise : c’est structurellement fragile. Pour ça, mieux vaut lui faire écrire et exécuter un script que lui demander la réponse.
La complaisance
Un modèle est optimisé pour être utile et agréable, ce qui le pousse à valider tes propositions. Il faut explicitement demander le désaccord pour obtenir un avis franc.
Le contexte manquant
Face à un trou, il comble avec le plus probable plutôt que de dire qu’il ne sait pas. La parade est dans le prompt : autoriser explicitement « je ne sais pas » et la question.
4 · Les familles
Choisir un modèle selon la tâche
Les noms changent tous les six mois, les catégories restent. Raisonne en familles plutôt qu’en versions.
| Famille | Bon pour | Éviter pour | Coût |
|---|---|---|---|
| Haut de gamme raisonnement |
Architecture, plans, refactos délicats, debug tordu, revue critique | Renommer des variables ou reformater un fichier | Élevé |
| Intermédiaire équilibré |
Exécuter un plan précis, écrire du code courant, tests, doc | Décisions d’architecture sans plan préalable | Moyen |
| Léger et rapide volume |
Tâches mécaniques, extractions, classification, reformatage en masse | Tout ce qui demande du jugement | Faible |
Le bon réflexe : gros modèle pour décider, petit modèle pour exécuter.
Et si un plan est assez précis pour être exécuté par un modèle plus faible, c’est le
signe que le plan est bon.
5 · Le portefeuille
Où part l’argent, et comment le garder
Deux façons de payer, avec des logiques opposées. Choisir la mauvaise pour son usage coûte cher.
Abonnement
Prix fixe, limites d’usage. Prévisible, idéal pour un usage quotidien et intensif. C’est le mode par défaut de la plupart des agents grand public.
API à l’usage
Tu paies au token. Imbattable pour un usage ponctuel ou automatisé, mais sans plafond naturel : une boucle mal cadrée peut coûter très cher en une nuit.
1
Ne relis pas tout le repo
Un agent qui ouvre trente fichiers pour une correction d’une ligne brûle ton budget. Indexer le code ou pointer les fichiers réduit énormément la facture.
2
Coupe les sessions
Le coût croît avec l’historique renvoyé à chaque tour. Une session propre par tâche, c’est autant de l’économie que de la qualité.
3
Répartis les modèles
Faire exécuter un plan par un modèle intermédiaire au lieu du haut de gamme divise la note sans perte notable.
4
Mesure avant d’optimiser
Regarde ce qui remplit réellement ton contexte : souvent, un serveur d’outils bavard ou un gros fichier lu en boucle représente la majorité du gaspillage.
Un ordre de grandeur concret : sur la page Ressources, un outil qui
réduit la verbosité des commandes de dev affiche 608 millions de tokens économisés sur
34 000 commandes, soit près de 98 %. Ça donne une idée de ce que représente le
« bruit » dans une utilisation non optimisée.
Vérifie que c’est acquis
Pourquoi une longue conversation coûte-t-elle proportionnellement plus cher qu’une série de sessions courtes ?
Un modèle n’a pas de mémoire entre les tours : pour qu’il « se souvienne », toute la
conversation lui est réenvoyée à chaque message. Le coût d’un tour croît donc avec la
longueur de la session — et la qualité baisse en parallèle, puisque le contexte se
charge.
À retenir
Trois idées qui changent la pratique
Le modèle prédit le plausible, donc il faut lui donner du réel et exiger des preuves. Il n’a pas de mémoire, donc la persistance vient de tes fichiers et de tes outils. Et tout ce que tu envoies est repayé à chaque tour, donc un contexte court et pertinent est à la fois meilleur et moins cher.