Vous ouvrez votre éditeur et démarrez une session. Avant que vous ne tapiez quoi que ce soit, avant même que le curseur ne se stabilise dans le champ de saisie, l'agent a déjà lu énormément de choses. Il a absorbé son prompt système, la définition de chaque outil qu'il peut appeler, ses instructions de comportement, le CLAUDE.md de votre projet (ou .cursorrules, ou AGENTS.md), toutes les règles limitées à certains chemins qui s'appliquent, et tout ce qui se trouve dans son fichier mémoire. Au moment où vous prononcez votre premier mot, l'agent a déjà un modèle de vous, de votre projet et de la façon dont il est censé se comporter.
Le modèle mental naïf, c'est : vous tapez, l'agent répond. La vraie séquence, c'est : l'agent lit votre contexte, vous tapez, l'agent répond. Cette première étape silencieuse, l'agent qui vous lit avant que vous ne parliez, décide d'une part étonnamment grande du résultat. Et les données sur l'utilité réelle du contexte que vous lui donnez sont plus dérangeantes que la plupart d'entre nous ne le supposent.
La version courte
- Les agents de codage IA chargent un contexte pré-écrit avant votre premier message : prompts système, définitions d'outils et fichiers d'instructions propres à l'outil comme CLAUDE.md, les règles Cursor, les instructions GitHub Copilot ou AGENTS.md là où il est pris en charge ou importé. Ce n'est pas vous qui lancez la conversation, c'est la lecture faite par l'agent.
- Ce préchargement consomme une part importante de la fenêtre de contexte utilisable avant même que vous ayez tapé un seul caractère : votre budget de travail réel est donc plus petit que ne le laisse croire la fenêtre annoncée du modèle.
- Le résultat empirique est la partie contre-intuitive : les fichiers de contexte écrits par des développeurs aident un peu (environ +4 % de réussite des tâches) pour un coût réel (environ +19 % de coût d'inférence), tandis que les fichiers de contexte générés par un LLM ou copiés-collés peuvent en fait rendre les résultats légèrement pire.
- L'auto-hébergement de votre modèle change ce que vous pouvez voir, pas ce que vous devez do. L'architecture pré-session est la même partout ; les outils locaux vous permettent seulement de l'inspecter et de l'auditer. La discipline qui consiste à écrire du contexte que vous comprenez réellement ne disparaît pas.
Le modèle naïve est faux : l'agent lit en premier
Imaginez l'instant précis où une session Claude Code démarre. Le prompt système entre. Les définitions d'outils entrent. Puis, avant que vous n'ayez dit quoi que ce soit, votre CLAUDE.md est livré, et le détail mécanique compte ici. La documentation d'Anthropic dit explicitement que Le contenu de CLAUDE.md est « transmis en tant que message utilisateur après le prompt système, » chargé « au début de chaque conversation. » Ainsi, le tout premier tour de l’utilisateur dans la transcription, ce n’est pas vous. C’est votre fichier, qui parle en votre nom, fixant les termes avant que vous n’arriviez.
Ce qui se charge réellement à cet instant initial, c'est une pile : le prompt système, les définitions d'outils, les instructions de comportement, vos fichiers de contexte projet et utilisateur, toutes les règles limitées à certains chemins qui correspondent aux fichiers concernés, et un fichier mémoire que l'agent tient lui-même. Dans Claude Code, les fichiers de contexte se résolvent selon une hiérarchie à quatre niveaux (politique gérée, puis utilisateur (~/.claude/CLAUDE.md), puis projet (./CLAUDE.md), puis local (./CLAUDE.local.md)), concaténés dans cet ordre. La mémoire automatique ajoute sa propre part : les 200 premières lignes (ou 25 Ko) d'un MEMORY.md que l'agent écrit et lit de son côté, chargé à chaque session.
Rien de tout cela n'est gratuit. Le surcoût d'infrastructure (prompt système, définitions d'outils, instructions de comportement) consomme une part importante de la fenêtre de contexte effective avant même que votre premier message n'arrive. C'est la taxe que vous payez pour que l'agent sache être un agent, et elle est invisible tant que vous n'allez pas la chercher.
Un nom émerge autour de la discipline qui consiste à gérer tout cela. L'équipe d'IA appliquée d'Anthropic l'appelle ingénierie de contexte : « l'ensemble des stratégies pour sélectionner et maintenir l'ensemble optimal de tokens (d'informations) pendant l'inférence d'un LLM ». C'est un terme utile car il fait passer le fichier que vous écrivez du statut de note au robot à celui de décision d'architecture sur ce qui occupe une ressource rare et coûteuse.
Quatre agents, quatre façons de vous lire en premier
Les agents ne vous lisent pas tous de la même manière. Ils se divisent selon deux axes qui méritent d'être nommés : ce qui est chargé au démarrage de la session (une hiérarchie organisée de fichiers, par opposition aux règles toujours actives ou à l'analyse de l'ensemble du dépôt), et dans quelle mesure vous pouvez l'inspecter, c'est-à-dire si le mécanisme est un artefact déterministe et auditable ou un index sémantique qu'il faut croire sur parole. C'est sur ces deux axes que Claude Code, Cursor, GitHub Copilot et Aider divergent vraiment.
| Outil | Ce qui se charge au démarrage de la session | Mécanisme | Auditabilité |
|---|---|---|---|
| Claude Code | CLAUDE.md hierarchy + .claude/rules/ + mémoire auto ; AGENTS.md uniquement si importé ou lié symboliquement | Hiérarchie basée sur les fichiers ; les règles à portée de chemin peuvent se charger à la demande ; le comportement de compaction et de relecture varie | Élevé pour vos fichiers et votre mémoire ; le prompt système reste propriétaire |
| Cursor | Règles de projet, d'équipe et d'utilisateur ; support AGENTS.md ; index de base de code pour le contexte sémantique | Fichiers de règles lisibles et indexation sémantique du code | Mixte : les règles sont lisibles, mais la récupération de l'index est moins transparente |
| GitHub Copilot | À l'échelle du dépôt copilot-instructions.md plus spécifiques au chemin .instructions.md si pris en charge | Fichiers d'instructions personnalisés appliqués dans les flux de travail Copilot | Modéré : les fichiers sont lisibles, mais le périmètre dépend de la surface produit |
| Aider | Un repo-map compact dérivé du dépôt git, plus les fichiers ajoutés/lus manuellement | Carte de dépôt basée sur les symboles/graphes, optimisée pour un budget de jetons | Élevée : le repo-map peut être inspecté, mais c'est toujours une carte sélectionnée, pas l'intégralité du dépôt mot pour mot |
La séparation de Cursor est la plus instructive. Ses règles résident dans des fichiers lisibles que vous contrôlez, mais il construit également une index sémantique de l'ensemble de votre base de code, les embeddings vectoriels qui alimentent la recherche @codebase et que vous ne pouvez pas vraiment inspecter. Aider se situe à l'autre extrémité : il lit l'intégralité de votre dépôt git et crée un repo-map, de façon déterministe, sans aucun embedding. Vous pouvez auditer exactement ce qu'il a transmis au modèle. Même inversion architecturale, visibilité très différente sur celle-ci. Pour la comparaison détaillée outil par outil, nous avons couvert le paysage des CLI agentiques dans notre affrontement des CLI de codage agentique et se sont directement affrontés dans OpenCode vs Claude Code ailleurs.
Sous les formats propres à chaque outil, un standard commun se consolide. AGENTS.md est né dans l'écosystème des outils d'agents (OpenAI Codex, Amp, Jules de Google, Cursor et Factory) et est désormais géré par l'Agentic AI Foundation sous la Linux Foundation, adopté par plus de 60 000 dépôts. C'est le fichier de contexte pré-session qui passe du statut de commodité propre à un outil à celui d'artefact portable de premier ordre : le secteur reconnaît que « ce que l'agent lit avant que vous ne parliez » mérite sa propre norme.
Ce que disent les données sur l'utilité de tout cela
C'est ici que la version confortable des choses s'effondre. Une équipe de l'ETH Zurich (Gloaguen, Mündler, Müller, Raychev et Vechev) a mené une évaluation contrôlée, « Évaluation d'AGENTS.md, » pour déterminer si ces fichiers de contexte au niveau du dépôt améliorent réellement les performances des agents de codage. Pour l'ensemble des agents et des modèles étudiés, le résultat n'était ni « les fichiers de contexte fonctionnent » ni « les fichiers de contexte échouent ». Le résumé actuel indique que les fichiers de contexte n'améliorent généralement pas la réussite des tâches et augmentent le coût d'inférence de plus de 20 % en moyenne. Dans les résultats détaillés de l'article, les fichiers fournis par les développeurs faisaient exception : ils amélioraient les performances d'environ 4 % en moyenne, mais augmentaient le coût jusqu'à 19 %. Les fichiers générés par un LLM allaient dans le mauvais sens, réduisant les performances d'environ 3 % en moyenne tout en augmentant le coût de plus de 20 %. Un troisième constat affine le tableau : les agents appellent un outil 1,6 à 2,5 fois plus souvent lorsque cet outil est nommé dans un fichier de contexte, ce qui aide ou nuit entièrement selon que ces appels supplémentaires étaient justifiés ou non.
Arrêtez-vous une seconde sur la ligne des fichiers générés par LLM, car c'est elle qui porte tout le reste. Un fichier que vous n'avez pas écrit, qu'il soit produit par un modèle ou téléchargé depuis un pack communautaire des « meilleures configs CLAUDE.md » puis déposé dans votre dépôt, se lit pour l'agent comme des instructions venant de quelqu'un qui ne connaît pas vraiment votre base de code. Dans les modèles étudiés, le bilan était négatif : vous payiez plus de tokens pour des résultats légèrement moins bons. Le article sur Augment Code à ce sujet le résume bien en qualifiant le résultat accumulé de « fourre-tout du contexte de votre agent ». Chaque instruction d'apparence plausible que vous y entassez a un coût, et celles que vous n'avez pas écrites, pour une base de code qu'elles ne comprennent pas, coûtent en général plus qu'elles ne rapportent.
Je ne lis pas cela comme « les fichiers de contexte sont mauvais », ni comme « les fichiers de contexte sont bons ». Ce sont exactement les cadrages du tout ou rien qui s'effondrent au contact des données. La lecture plus étroite est celle-ci : le contexte est une infrastructure que vous concevez délibérément, et un fichier que vous n'avez pas écrit, pour une base de code qu'il ne comprend pas, est un coût plutôt qu'un cadeau. La réserve sur la portée compte aussi. C'est ce que l'article a constaté pour les modèles et les agents qu'il a testés, pas une loi universelle valable pour tous les LLM. Mais cela pointe fortement dans une direction, et c'est corroboré du côté des éditeurs : l'équipe IA appliquée d'Anthropic a noté le glissement vers un chargement du contexte « juste à temps » via des outils à l'exécution, plutôt qu'un préchargement complet en amont, et décrit une approche hybride qui récupère une partie des données en amont et explore le reste à l'exécution. Quand l'entreprise qui livre CLAUDE.md penche pour précharger moins, l'instinct du copier-coller d'un fichier de contexte géant mérite un second regard.
À retenir de cette section : la paternité du fichier est le signal qui prédit si le contexte est rentable. Le coût en tokens est le même dans les deux cas ; ce qui change le rendement, c'est de savoir si les instructions viennent de quelqu'un qui connaît vraiment le code.
Le contexte qui s'efface : pourquoi le début de session n'est pas toute l'histoire
Le préchargement pose la contrainte. Il ne la maintient pas. Ce sur quoi les développeurs butent sans cesse, c'est la seconde moitié de l'histoire : le contexte soigneusement mis en place au début de la session s'érode au fil de la session, et il le fait en silence.
Une façon utile de se représenter cela vient du cadrage de l'équipe Mem0, selon lequel un la fenêtre de contexte est de la RAM, pas du stockage, éphémère et bornée, pas un endroit permanent où vivent vos instructions. Chargez quelque chose au début et c'est présent ; continuez assez longtemps sans y faire appel et cela s'estompe, comme une variable qu'on cesse de référencer et qui finit par être écrasée. C'est le mécanisme derrière un phénomène que les chercheurs appellent la dégradation des instructions. Une étude de 2026 par Gamage et ses collègues a constaté que les contraintes d'omission sont particulièrement fragiles : dans un cas testé, le respect des consignes est passé de 73 % au tour 5 à environ 33 % au tour 16. C'est un résultat de laboratoire, pas une constante universelle, mais cela correspond à ce que beaucoup de gens ressentent lors des longues sessions.
La limite de session est là où cela devient plus précis. Des développeurs dans une discussion Hacker News signalent que les sous-agents lancés peuvent souffrir de problèmes de transfert de contexte : un travail délégué en cours de tâche peut arriver avec moins de contexte de la session parente que vous ne le pensiez. Et le temps d'inactivité a son propre coût : dans un fil où Boris Cherny d'Anthropic est intervenu, la discussion explique comment une session inactive peut déclencher une reconstruction massive après échec de cache, des centaines de milliers de tokens, sans le moindre avertissement. Le fil rouge que la communauté rapporte sans cesse, c'est le silence : le compactage s'exécute, les raisonnements antérieurs sont rognés, la qualité baisse, et rien à l'écran ne vous dit que c'est arrivé. Vous remarquez simplement que le résultat est moins bon.
L'auto-hébergement vous donne-t-il plus de contrôle ?
Faites tourner l'ensemble vous-même (Ollama plus Open WebUI, ou un agent comme Aider ou Continue.dev pointé vers un modèle local) et la réponse honnête à « est-ce que j'ai plus de contrôle maintenant ? » est : vous obtenez plus de visibilité, pas plus de contrôle intrinsèque. C'est toute la nuance.
Ce que l'auto-hébergement vous apporte réellement, c'est l'inspection. Aucune donnée de conversation ne quitte votre infrastructure. Vous pouvez lire l'intégralité du prompt système au lieu d'accepter un prompt propriétaire sur parole. Avec un outil déterministe comme Aider, vous pouvez auditer exactement ce qui est entré dans chaque appel au modèle : le repo-map est un artefact lisible, pas une boîte noire sémantique comme l'index d'embeddings de Cursor. Pour quiconque tient à l'auditabilité et à la reproductibilité, à pouvoir répondre à la question « qu'est-ce que l'agent a réellement vu ? », cette inspectabilité est bien réelle, et ce n'est pas rien.
Mais l'inversion architecturale se moque de l'endroit où tourne le modèle. Que vous utilisiez un modèle local via Ollama, Claude Code sur une API cloud ou Cursor par abonnement, l'agent lit toujours son contexte de pré-session avant que vous ne parliez, et vous devez toujours concevoir ce contexte de façon délibérée. La discipline est identique. L'auto-hébergement vous donne une fenêtre plus claire sur le mécanisme ; il ne vous donne pas un mécanisme différent, et il ne vous dispense certainement pas de la leçon d'ETH Zurich sur ce qui arrive quand vous chargez un contexte que vous n'avez pas écrit. Le seul changement à retenir de tout cela : cessez de voir le fichier de contexte comme un cadeau que vous offrez à l'agent, et voyez-le comme une infrastructure avec un coût de fonctionnement. Écrivez ce que vous comprenez vraiment de votre base de code, chargez moins plutôt que plus, et rappelez-vous que l'agent vous a lu en premier : la version de vous qu'il a lue devrait donc être une version que vous assumez.
Foire aux questions
Les agents IA de codage lisent-ils vos fichiers avant que vous ne tapiez quoi que ce soit ?
Oui. Au démarrage d'une session, un agent de code IA charge son prompt système, ses définitions d'outils et vos fichiers de contexte (CLAUDE.md, .cursorrules ou AGENTS.md), ainsi que le repo-map ou le fichier mémoire éventuels, le tout avant votre premier message. Dans Claude Code en particulier, le CLAUDE.md est transmis comme un message utilisateur juste après le prompt système : la conversation commence donc en pratique par votre fichier, et non par vous.
Les fichiers de contexte comme CLAUDE.md améliorent-ils vraiment les performances de l'agent ?
En partie, et moins que la plupart des gens ne le supposent. Dans le Évaluation par ETH Zurich des fichiers de style AGENTS.md, le résumé actuel indique que les fichiers de contexte n'améliorent généralement pas la réussite des tâches et augmentent le coût d'inférence de plus de 20 % en moyenne. Les résultats détaillés sont plus utiles aux praticiens : les fichiers fournis par les développeurs ont amélioré les performances d'environ 4 % en moyenne, mais ont augmenté le coût jusqu'à 19 %, tandis que les fichiers générés par un LLM ont réduit les performances d'environ 3 % en moyenne et augmenté le coût de plus de 20 %. La lecture pratique : un fichier que vous avez écrit et que vous comprenez peut aider un peu ; un fichier que vous n'avez pas écrit peut vous coûter cher en silence.
Quelle part de la fenêtre de contexte est utilisée avant d'envoyer un message ?
Une part importante. Le prompt système, les définitions d'outils et les instructions de comportement se chargent avant la moindre saisie de l'utilisateur, et ensemble ils consomment une portion notable de la fenêtre de contexte effective. Votre budget de travail utilisable est plus petit que la fenêtre de contexte annoncée du modèle à cause de ce surcoût fixe au démarrage.
L'hébergement personnel d'un modèle IA vous donne-t-il plus de contrôle sur le contexte ?
Plus de visibilité, pas plus de contrôle intrinsèque. L'auto-hébergement vous permet d'inspecter le prompt système complet, garde les données de conversation sur votre propre infrastructure et (avec un outil déterministe comme Aider) vous laisse auditer exactement ce qui est parti dans chaque appel. Mais l'architecture du contexte pré-session est la même que dans les outils cloud, et vous devez toujours concevoir votre contexte de façon délibérée.
Qu'est-ce qu'AGENTS.md ?
AGENTS.md est un format ouvert qui explique aux agents de code comment travailler avec une base de code, l'équivalent d'un README destiné à l'agent. Il a émergé dans tout l'écosystème d'outillage pour agents (OpenAI Codex, Amp, Jules de Google, Cursor et Factory) et il est aujourd'hui géré par l'Agentic AI Foundation sous l'égide de la Linux Foundation, avec une adoption dans plus de 60 000 dépôts, ce qui en fait le standard inter-outils émergent pour le contexte d'agent avant session.
