Claude, notre stagiaire connaît votre projet !
Du moins, il en donne vraiment l’impression…
En vérité, il n’en garde à chaque instant qu’un petit bout sous les yeux, sa fenêtre de travail, et tout ce qui n’y est pas n’existe pas pour lui. Comprendre ce contexte, sa taille, son prix, c’est lever d’un coup la moitié de ses mystères.
À commencer par le plus déroutant : « oublie-t-il » ce que je lui ai dit il y a vingt minutes ?
Le modèle ne lit pas des mots
Premier détour, parce qu’il définit tout le reste. Un modèle ne lit pas vos phrases mot à mot. Il les découpe en morceaux, des tokens.
« Je fiabilise la prod » ne fait pas quatre mots pour lui, mais six morceaux, dont trois pour le seul « fiabilise ».
Un token vaut, en gros, trois quarts d’un mot. Les mots courants tiennent en un seul morceau, les mots rares et les noms de variables à rallonge se brisent en plusieurs.
(La réalité est un poil différente, tout s’appuie sur comment l’algorithme transforme des mots en signal, mais en gros, c’est l’idée).
Pourquoi s’embêter avec ça ?
Parce que c’est l’unité de compte. Tout ce qui entre dans sa tête se mesure en tokens, et chacun se paie, deux fois plutôt qu’une : ce qu’il lit, et ce qu’il écrit (ce dernier, plus cher). Le coût d’une session, c’est une addition de morceaux qui grimpe à chaque échange, jamais un forfait tranquille.
Pour l’échelle : « je fiabilise la prod » pèse six tokens. Un fichier de quatre cents lignes que l’agent ouvre pour comprendre le terrain, c’est plutôt quelques milliers de morceaux qui atterrissent d’un coup sur la table.
Un mot pour vous, une facture pour lui.
La fenêtre : tout ce qu’il voit d’un coup
Ces morceaux s’entassent dans une fenêtre, sa fenêtre de contexte. C’est sa mémoire de travail, et rien d’autre : ce qui tient dedans, il le connaît ; ce qui déborde n’existe pas.
Le contexte, c’est la taille de sa tête.
- CLAUDE.md
- règles injectées
- les fichiers lus
- la conversation
- votre prompt le dernier arrivé
Cette tête a grossi, et c’est récent. Les modèles tiennent désormais un million de tokens, là où le standard plafonnait à deux cent mille il y a peu. Le petit dernier, Haiku, en reste d’ailleurs à ces 200K : la taille de la tête dépend du modèle qu’on lance.
Un million de tokens, c’est l’équivalent de 75 000 lignes de code d’un seul tenant.
De quoi voir gros.
Pas de quoi tout voir, et surtout pas de quoi tout y jeter sans compter, parce que cette place immense reste une place finie, et chère.
Ce qui squatte déjà le bureau
Le piège, c’est de croire la fenêtre vide quand vous arrivez. Elle est déjà bien encombrée avant votre première phrase.
Au démarrage de chaque session sur Granit, l’agent charge le CLAUDE.md : deux cents lignes de règles permanentes,
l’architecture en couches, les conventions de commit, l’interdiction de logger un email.
S’ajoutent des règles qui s’injectent toutes seules selon le fichier qu’il ouvre
(dès qu’il touche une requête SQL, une consigne sur le cloisonnement des données apparaît dans sa tête, sans que je la redemande). Puis les fichiers qu’il a lus pour comprendre le terrain. Puis toute la conversation depuis le début, la sienne comme la vôtre. Votre prompt, lui, n’est que le dernier arrivé sur une fenêtre déjà remplie.
Voyez la fenêtre comme un bureau, pas comme une bibliothèque. Ce qui est posé dessus, il l’a sous la main, tout de suite. Le reste dort sur les étagères, et il doit se lever pour aller le chercher. Lire un fichier, c’est exactement ça : le poser sur le bureau, et payer la place qu’il prend, trois cents lignes d’un coup pour une réponse qui en tenait sur une seule.
Tout l’art consiste à ne pas le faire se lever pour rien.
C’est d’ailleurs pour ça que je m’appuie sur des oracles déterministes : des garde-fous qui tranchent par oui ou non, un test, un build, un compilateur. Plutôt que de tout garder sur le bureau pour vérifier que rien ne casse, l’agent interroge le garde-fou et obtient une réponse nette. Moins de paperasse, plus de place pour réfléchir.
(Il existe une commande, /context, qui montre noir sur blanc ce qui occupe la table. La première fois, on est surpris de voir tout ce qui dort là avant même d’avoir parlé.)
Pourquoi il « oublie » ?
Une fois ce bureau en tête, ses ratés cessent d’être un mystère.
Il « oublie » une consigne donnée vingt minutes plus tôt ?
Quand la fenêtre sature, l’agent fait le ménage tout seul : il jette d’abord les vieux résultats de commandes, devenus inutiles, puis il résume la conversation pour la compresser. C’est la compaction, et votre consigne du début a très bien pu partir au résumé, fondue en une ligne ou disparue.
Rien à voir avec de la mauvaise volonté : c’est de la place qui manque, voilà tout.
Petit cas récurrent que beaucoup ont dû déjà rencontrer : en ouverture de session, je pose une règle simple :
« les migrations de base de données, c’est moi qui les lance, tu n’y touches pas ».
Une heure et deux /compact plus tard, l’agent m’en déroule une, tout fier de son initiative.
Il n’a pas désobéi : ma phrase avait fondu dans un résumé, et pour lui elle n’avait jamais existé.
Il répond à côté sur un gros projet ?
Tout ne tenait pas sur le bureau d’un seul coup, alors il a travaillé sur la moitié visible qu’il avait dans sa tête. Même s’il n’a lu que trois chapitres sur dix, il répond quand même.
D’où deux réflexes, que je garde pour la suite : découper le travail pour qu’un morceau tienne dans la fenêtre, et lui épargner les lectures inutiles.
Un agent qui déborde n’est pas bête, il est encombré
Reste à voir ce que l’agent fait de cette fenêtre une fois remplie. Comment découper un bloc en plus petits puis boucler, pour relire son propre résultat et recommencer.
C’est l’affaire d’un prochain carnet.