Le fichier qui coûtait 55 000 tokens avant ma première question

221 679 octets. C'est ce que pesait, fin août, le fichier de règles de mon dépôt d'assistant personnel — le document qu'un agent de codage lit intégralement à l'ouverture de chaque session. À quatre octets par token, estimation que j'affiche comme telle, cela représente environ 55 000 tokens dépensés avant que j'aie tapé le premier mot de ma demande. Que je vienne corriger une faute de frappe dans un libellé ou refondre un module entier, la facture était la même.

Je l'ai ramené à 7 875 octets, soit −96,4 %, sans perdre une seule ligne. J'ai la preuve, et j'y reviens plus bas, parce que c'est la partie qui compte.

Ce qu'est un fichier de règles, et pourquoi il se paie à chaque session

Quand on installe un agent de codage sur un projet, on lui écrit un fichier de règles — CLAUDE.md, AGENTS.md, le nom varie selon l'outil : la carte du dépôt, les conventions maison, les commandes à lancer, la manière dont on veut qu'il travaille. Le malentendu commence juste après : on traite ce fichier comme de la documentation. Or une documentation, on l'ouvre quand on en a besoin ; un fichier de règles, l'agent l'avale en entier, au démarrage, systématiquement. Ce n'est pas un document de référence, c'est un péage.

Deux mots de vocabulaire : un token est un fragment de mot, la plus petite unité que le modèle manipule ; la fenêtre de contexte, c'est tout ce qu'il a sous les yeux à un instant donné. Elle est bornée, mais la limite dure n'est pas le vrai problème — bien avant de l'atteindre, autour de 200 000 à 300 000 tokens, un modèle devient mesurablement moins bon. Tout ce que vous rendez permanent est prélevé sur ce budget à chaque session, y compris pour les tâches qui n'ont rien à voir avec ce que le fichier raconte.

Ce n'est pas un stock, c'est une pente

En relevant la taille du fichier au dernier commit de chaque journée, j'ai obtenu ceci :

Trois mois à environ 0,4 Ko par jour, puis 149 Ko en trois jours, dont douze commits sur la seule dernière journée. La pente a été multipliée par une centaine, et je ne m'en suis rendu compte qu'en la mesurant.

Un fichier de règles ne devient pas obèse par une décision, il le devient par accumulation. Chaque ajout, pris isolément, était justifié : un piège rencontré, un arbitrage à ne pas rejouer, une commande qui ne s'invente pas. Personne ne se dit « je vais gonfler le contexte », on se dit « ça, il faut que l'agent le sache ».

Le diagnostic contre-intuitif : la cause n'est pas la taille

L'intuition dit : c'est trop long, il faut couper. La vérification préalable a renversé le diagnostic. Ce dépôt n'avait aucun dossier de références. Aucun. Il n'existait pas un seul endroit où envoyer un contenu conditionnel — une convention qui ne sert que sur un domaine précis, un piège qui ne se présente que sur une opération rare.

La cause n'était pas la verbosité, c'était un palier manquant. Quand il n'existe pas d'ailleurs où aller, tout s'accumule dans ce qui est toujours chargé. Créer cet ailleurs est le préalable de l'élagage, pas sa conséquence.

Trois paliers de chargement, et l'erreur de n'en utiliser qu'un

• Palier 1 — le fichier de règles. Toujours chargé, à chaque session, quoi qu'il arrive.
• Palier 2 — les références à la demande. Des documents par domaine, chargés uniquement quand l'agent travaille ce domaine. Ce sont des règles aussi : des conventions, des contraintes.
• Palier 3 — les compétences empaquetées. Seule une description d'une centaine de tokens reste chargée en permanence ; le mode d'emploi complet n'arrive qu'à l'invocation. Là, on parle de procédures, pas de conventions — c'est le sujet d'un autre article sur le chargement à la demande.

L'erreur n'est pas d'écrire trop, c'est de n'utiliser que le premier palier : la discipline n'est pas d'écrire moins, c'est d'écrire au bon niveau.

La question unique qui trie : « l'agent en a-t-il besoin quoi qu'il fasse ? »

Tout le tri tient dans cette question, posée ligne par ligne. Si la réponse est non, la ligne descend d'un palier. Une seconde question finit le travail : « l'agent le saurait-il sans que je l'écrive ? » Si oui, on coupe : un rappel générique sur la lisibilité du code, le modèle le suit déjà sans qu'on le paie à chaque session.

Ce qui reste au palier 1 tient en quatre familles : la carte du dépôt, les règles de terrain propres au projet, les commandes que l'agent doit lancer lui-même, et le pilotage de l'agent. Cette dernière est la seule qu'aucune analyse du code ne peut produire : elle ne se lit nulle part, elle s'énonce.

Élaguer, c'est déplacer : les quatre destinations d'une ligne

Élaguer ne veut pas dire supprimer : toute ligne a exactement quatre issues.

Dans mon cas, 214 Ko sont partis dans neuf fichiers de références, déplacés verbatim par extraction de plages de lignes, jamais retapés. Ce qui reste au palier 1 pointe vers eux par un index de 1 339 octets, formulé par le déclencheur et non par le sujet : la forme est « avant d'entreprendre ce type de travail, lis ce document », et non une liste de titres rangés par thème. Un palier 2 qu'aucune phrase ne désigne au bon moment n'est pas un palier : c'est un dossier que personne n'ouvrira.

La preuve qu'on n'a rien perdu — et le contre-test sans lequel elle ne vaut rien

Un élagage qui perd un piège mesuré coûte plus cher que les tokens qu'il économise : il fallait une preuve, pas une impression. J'ai comparé le multiensemble des lignes de l'original avec celui du corpus final : zéro ligne perdue. Les 233 lignes ajoutées sont intégralement classées — 93 pour le palier 1 réécrit, 135 pour les chapeaux des neuf références, 5 pour un erratum.

Et surtout, j'ai contre-testé le vérificateur avant de le croire : j'ai amputé volontairement 21 Ko du corpus final, et l'outil a bien rendu 271 lignes perdues et un contrôle en échec. C'est la partie qu'on saute presque toujours. Un vérificateur qui n'a jamais échoué ne prouve rien : il peut très bien être vert parce qu'il ne regarde rien.

Le piège d'apparence : 30 octets qui en chargent 84 000

Le même jour, j'ai mesuré un outil open source que j'utilise tous les jours. Son fichier de règles racine fait 30 octets et dit, en substance, « lis cet autre fichier » — lequel en pèse 84 009. Total chargé à chaque session : 84 039 octets, dont 99,96 % par l'import.

Un import dans un fichier de règles n'est pas un lien, c'est une inclusion résolue en ligne et récursivement au chargement : un fichier « modulaire » ne charge donc pas moins qu'un bloc unique. L'exemple livré par le cours d'agentic coding que je suis le démontre à rebours de son intention : la version monolithique pèse 247 lignes, la version dite modulaire 53 lignes de fichier racine plus 221 lignes réparties en dix morceaux, soit 274 lignes réellement chargées. Dans ce cas mesuré, le découpage coûtait plus cher que le bloc. Le fichier a changé de nom, pas de palier.

Mon premier outil de contrôle, lui, mesurait le disque. Il classait « très court, probable stub » ce fichier de 30 octets qui en charge 84 000 — un stub n'est pas un fichier vide, c'est un fichier qui délègue, et c'est précisément ce que l'outil ne voyait pas — et validait « conforme » un fichier de 221 Ko faute de borne haute : deux faux résultats symétriques, une seule cause racine. Rapporter « 30 octets, conforme » ne mesure pas la sobriété, cela certifie le contournement.

La règle d'admission, sans quoi le fichier est rattrapé

Un tri sans règle d'admission est cosmétique. Au rythme constaté — 149 Ko en trois jours — un fichier ramené à 24 Ko est rattrapé en une journée de travail. Ce qu'il faut écrire, ce n'est pas où va le contenu existant, c'est où ira le contenu nouveau. Une phrase suffit, à condition qu'elle tranche : tout ce qui ne sert pas à toutes les tâches part en référence, et l'index gagne une ligne.

Dernière honnêteté, parce qu'elle limite la portée de tout ce qui précède : une règle est une consigne, pas une garantie. L'agent peut passer outre, comme un humain saute une étape d'une procédure — je l'ai montré ailleurs, sur une consigne de sécurité qui cède à la deuxième demande. Sur ce même dépôt, un mécanisme automatique injecte 47 573 octets de contexte au démarrage, plafonné dans son propre code, pas par une phrase de mon fichier de règles. Ce qui borne un mécanisme déterministe, c'est du code.

Ce que je fais chez un client, et ce que je ne fais pas

Quand j'interviens sur l'outillage IA d'une équipe, je commence par mesurer la taille chargée du fichier de règles, imports résolus — cela suffit à savoir si le problème est là ou ailleurs. Ensuite seulement : créer le palier 2, élaguer, prouver qu'on n'a rien perdu, écrire la règle d'admission, poser un garde-fou observateur — chez moi, un avertissement au-delà d'environ 40 Ko, jamais bloquant.

Ce que je ne fais pas : imposer un plafond, réécrire les règles à la place de l'équipe, ou installer un kit générique payé à chaque session et sur chaque dépôt. Comment vous voulez que l'agent travaille chez vous, personne ne peut l'écrire à votre place : c'est le travail que je mène sur un assistant IA personnel, et ce qu'un audit et diagnostic sert à cadrer avant la première ligne.

Je mesure aussi chez moi, et je publie les mauvais chiffres avec les bons — même exigence que sur mes réalisations, dont les chiffres sortent des livrables. Trois dépôts de travail relevés le même jour : 11 798, 12 223 et 37 901 octets de règles, zéro import, un palier 2 habité et atteignable dans les trois cas. Le troisième charge environ 9 475 tokens par session ; c'est le seul qui mérite un nouvel arbitrage. Le dépôt de ce site, lui, porte 15 281 octets de règles et aucun dossier de références : le palier 2 n'y existe pas non plus. Je le sais parce que je l'ai mesuré, et ce n'est pas encore corrigé.

Si vous équipez vos développeurs d'un agent de codage, la première mesure est celle-là : combien votre fichier de règles charge-t-il réellement, imports résolus, avant la première question. Le chiffre surprend presque toujours celui qui l'a écrit. Si vous voulez qu'on regarde le vôtre, réservez 30 minutes.