Un développeur a observé pendant un mois les agents dans son code : l'arbre de fichiers coûte plus cher que le JSON

Il y a un an, l'auteur de cet article sur Habr copiait ses fichiers un par un dans la fenêtre de chat. Aujourd'hui, des agents lisent eux-mêmes son projet via un serveur MCP, et il a passé un mois à observer ce qu'ils placent dans leur contexte. Ses conclusions sont très pratiques. L'arbre de fichiers en texte coûte plus cher que le JSON. On ne peut pas exclure le dossier build d'après son nom. Un mot de passe peut être caché de telle manière que le code cesse de fonctionner. Enfin, un agent livré à lui-même gère son contexte de façon bien plus gaspilleuse qu'on ne le pense.

L'article original n'est disponible que sous forme d'annonce. Nous détaillons donc ci-dessous les thèses annoncées et la logique d'ingénierie qui les sous-tend. Pour les mesures exactes de l'auteur, mieux vaut se reporter à la source primaire.

Pourquoi l'arbre coûte plus cher que le JSON

L'intuition dit l'inverse. Un arbre avec indentation et pseudo-graphismes se lit facilement à l'œil, tandis que le JSON, avec ses guillemets, ses accolades et ses clés répétées, paraît redondant. Mais le modèle compte des tokens, pas des caractères. Les symboles de ramification, les longues suites d'espaces et les préfixes de chemins répétés sont tokenisés de façon inefficace. Il s'agit de notre hypothèse sur le mécanisme : l'auteur a pu l'expliquer autrement. La conclusion elle-même mérite d'être vérifiée sur votre propre dépôt : pour un gros projet, l'écart de coût augmente avec le nombre de fichiers.

MCP joue ici un rôle particulier. Le protocole transforme la lecture du projet en une série d'appels d'outils : liste des fichiers, contenu, recherche. Le format de réponse de chacun de ces appels entre intégralement dans le contexte, et chaque requête de l'agent en paie le prix.

Dossier build et mots de passe

La deuxième leçon concerne le filtrage. La règle « ignorer les dossiers nommés build » semble raisonnable, jusqu'à ce qu'un répertoire du même nom apparaisse dans le projet et contienne du code source, et non des artefacts de compilation. Il est plus fiable de regarder ce que fait le dossier : figure-t-il dans le .gitignore, est-il généré par la compilation, quand a-t-il été modifié pour la dernière fois ?

Les secrets sont plus délicats. Si l'on se contente de supprimer la ligne contenant le mot de passe, la configuration ne se parse plus, et l'agent se met à réparer ce qu'il a lui-même cassé. La solution qui fonctionne est différente : remplacer la valeur par un substitut, en conservant la structure du fichier, la clé et le type de données. Le code reste alors lisible, et le secret réel reste hors du contexte.

L'agent sans surveillance

L'auteur décrit brièvement le sujet le plus intrigant : ce que fait l'agent du contexte quand personne ne le surveille. Les symptômes typiques sont connus de tous ceux qui ont lancé de longues sessions : relecture des mêmes fichiers, chargement de répertoires superflus, fenêtre gonflée par d'anciens résultats d'outils. Chacune de ces étapes coûte des tokens et dégrade la qualité des réponses, car le signal utile se noie dans le bruit.

• Format de description du projet : l'arbre texte coûte plus cher que le JSON.
• Filtres : le nom du dossier ne suffit pas comme critère unique.
• Secrets : masquer les valeurs plutôt que supprimer les lignes.
• Transport : le serveur MCP comme point de contrôle unique de ce que voit l'agent.
• Risque : croissance incontrôlée du contexte dans les longues sessions.

Par où commencer pour auditer son projet ?

Commencez par regarder ce qui part réellement dans le contexte. Si votre serveur MCP ou votre harnais d'agent ne journalise pas le volume des réponses, ajoutez un compteur de tokens à chaque appel. Sans lui, il n'y a rien à optimiser.

Comparez ensuite les formats. Passez le même dépôt à la fois en arbre et en JSON compact, puis comparez le nombre de tokens. Revoyez après cela vos règles d'exclusion : appuyez-vous sur le .gitignore et sur les marqueurs de fichiers générés, et non sur une liste de noms.

Enfin, mettez en place le masquage des secrets avant l'envoi des données à l'agent, et non après. Vérifiez que la configuration masquée passe toujours dans le parseur. Et donnez un budget à l'agent : une limite sur la taille du contexte et sur le nombre de relectures d'un même fichier. Ainsi, un mois d'observation se transforme en un ensemble de règles, et non en une surprise ponctuelle.