Optimiser le contexte d'un agent IA : eco & logique

Chez mAIstrow, on a une expression qui revient souvent dans nos discussions internes : eco & logique. C'est un jeu de mots inventé par Vincent, un ami commun, qui dit deux choses à la fois. Économique, parce qu'on travaille avec peu de ressources et qu'on a toujours été attentifs à ce qu'on consomme. Écologique, parce que chaque token facturé correspond à du compute réel, quelque part dans un datacenter, qui consomme de l'énergie et émet du CO2. Et logique, parce qu'il se trouve que les deux sont alignés : moins vous gaspillez de contexte, plus votre agent est efficace, sur le résultat comme sur la vitesse.

Cette conviction n'est pas une lubie de frugalité. Elle est appuyée par une observation technique que je vois se confirmer à chaque fois que je travaille sérieusement avec un agent : plus la fenêtre de contexte est grande, plus le modèle perd en efficacité. La dégradation commence bien avant la limite théorique du modèle. À partir d'un certain volume, l'attention dérive, les instructions les plus anciennes deviennent floues, le modèle mélange des éléments qui n'auraient pas dû être mélangés. Vous payez plus cher pour obtenir une réponse moins bonne.

Dans cet article, je décris les trois techniques qui font la majeure partie de la différence dans ma pratique quotidienne. Toutes les trois découlent directement du principe 6 de l'article parent : concevoir pour le coût dès le départ. Ce n'est pas de l'optimisation tardive, c'est une discipline de conception.

Technique 1. Un CLAUDE.md qui dit ce qu'il faut charger, et surtout ce qu'il ne faut pas

La première chose que Claude Code fait en arrivant dans un projet, c'est explorer l'arborescence. Sans guidage, il va lire ce qui lui semble pertinent : fichiers README, fichiers de configuration, fichiers les plus volumineux à la racine. Cette exploration est utile dans un petit projet. Dans un gros projet, c'est une catastrophe économique.

La solution est un fichier CLAUDE.md à la racine du projet. Ce fichier n'est pas un manifeste d'intention générale, c'est une directive de chargement. Il dit explicitement à l'agent quels fichiers il doit lire au démarrage, et surtout quels fichiers il doit ignorer tant que vous ne les mentionnez pas explicitement.

Un exemple minimaliste :

# Project: MyApp

## Always load
- README.md (project overview)
- docs/architecture.md (system design)
- src/config.ts (configuration reference)

## Load on demand
- src/**/*.ts (only when working on specific modules)
- tests/**/*.ts (only when writing or debugging tests)
- data/**/*.json (only when explicitly referenced)

## Never load
- node_modules/
- dist/
- build/
- *.log

La section Always load doit rester minimaliste : trois à cinq fichiers maximum, les vraies entrées d'entrée du projet. La section Load on demand décrit des patterns que l'agent ne chargera que quand vous lui parlerez spécifiquement d'un fichier qui y correspond. La section Never load bloque les dossiers bruyants par principe.

L'effet concret : sans ce fichier, l'agent explore et charge facilement cinq à dix mille tokens de contexte à chaque début de session, dont la plupart ne servent à rien pour votre tâche du moment. Avec ce fichier, il lit trois à quatre fichiers essentiels, quelques centaines de tokens, et il s'arrête. Sur un projet avec beaucoup de fichiers, le facteur de réduction est significatif. Je ne vais pas donner un chiffre précis parce qu'il dépend entièrement de votre structure de projet, mais la différence est suffisamment visible pour qu'elle justifie de passer cinq minutes à écrire ce fichier avant de commencer à travailler.

Technique 2. Des sessions courtes, parce que l'historique se paie cher

Voilà un point qui est souvent mal compris, et que je veux prendre le temps d'expliquer précisément parce qu'il y a beaucoup d'approximations en circulation sur le sujet.

Quand vous discutez avec un agent, chaque nouveau message que vous envoyez ne contient pas seulement votre message. Il contient tout l'historique de la conversation jusqu'à ce point. Le système prompt, les messages précédents, les réponses précédentes, les résultats d'outils, tout est réinjecté à chaque tour. C'est la seule façon pour le modèle de se souvenir de ce qui s'est passé, puisqu'il n'a pas de mémoire persistante entre deux requêtes.

Les conséquences sont importantes. Si votre conversation contient N tours et que chaque tour ajoute en moyenne K tokens (votre message plus la réponse de l'agent), alors la requête numéro N envoie en entrée l'équivalent de N × K tokens d'historique, plus votre nouveau message. Le coût cumulé de l'ensemble des N requêtes d'une conversation est donc en O(N²) en tokens d'entrée.

Concrètement, ça veut dire qu'une conversation qui a duré dix tours ne coûte pas dix fois une seule requête. Elle coûte beaucoup plus, parce que chaque tour porte tout le poids des précédents. Et si vous la laissez durer vingt tours, ce n'est pas deux fois le coût de dix tours, c'est plutôt quatre fois.

Le prompt caching atténue ce problème, et j'en parle dans la technique suivante, mais il ne l'élimine pas. Et surtout, il ne corrige rien au deuxième effet, qui est indépendant du coût : la dégradation de qualité. Plus vous empilez de l'historique, plus le modèle a de mal à garder son attention sur ce qui compte pour votre tâche actuelle. Il se rappelle de ce qu'il a fait au début de la conversation et essaie de rester cohérent avec, alors que votre besoin a peut-être évolué depuis. Il mélange des règles qui s'appliquaient à un ancien sous-sujet avec votre question actuelle. Il devient plus prudent, plus hésitant, plus bavard.

La règle que j'ai fini par adopter : nouvelle session dès que je change de tâche. Au minimum une nouvelle session par demi-journée, même si je reste sur le même projet. C'est contre-intuitif quand on vient d'une approche où "tout se passe dans une seule conversation", mais c'est là que se joue une grande partie à la fois du coût et de la qualité.

Un chiffre qui rend la règle plus parlante : deux requêtes de 3 000 tokens valent presque toujours mieux qu'une seule requête de 6 000 tokens. Trois raisons indépendantes pointent toutes dans la même direction.

D'abord, la couche d'attention du transformer a un coût en O(n²) par rapport au nombre de tokens de la séquence. Un prompt de 6 000 tokens coûte donc environ 36 millions d'unités d'attention, alors que deux prompts de 3 000 coûtent 2 × 9 = 18 millions. La moitié, pour le même travail utile. L'effet est modeste à cette échelle parce qu'en pratique c'est la bande passante mémoire qui domine sur les courtes séquences, mais il est toujours en votre faveur.

Ensuite, si vos deux requêtes partagent un préfixe stable (le system prompt, votre CLAUDE.md, votre index de documentation), le prompt caching facture ce préfixe à environ 10% de son prix sur la seconde requête. Si vos 3 000 tokens de contexte contiennent 2 000 tokens de préfixe partagé, la seconde requête ne paie qu'environ 1 200 tokens au tarif plein et 200 au tarif réduit, au lieu de 3 000. L'économie est cumulative sur la session de travail.

Enfin, le modèle reste focalisé. Sa fenêtre d'attention ne se disperse pas sur 6 000 tokens dont la moitié n'a plus rien à voir avec votre tâche courante. C'est l'argument qualitatif, et c'est probablement le plus important des trois à long terme.

Claude Code propose de reprendre depuis un résumé quand la session devient coûteuse : ici 206 000 tokens accumulés après presque trois jours.

Depuis la mise à jour d'avril 2026, Claude Code intègre d'ailleurs lui-même un mécanisme d'auto-compaction qui se déclenche automatiquement à l'approche de la limite du contexte. Le système résume la conversation et repart avec cette synthèse comme nouveau contexte. Les commandes /compact et /clear permettent aussi de le faire manuellement, la première en gardant un résumé, la seconde en repartant de zéro. C'est une reconnaissance explicite par Anthropic que le problème est réel. Mais il faut comprendre que l'auto-compaction est lossy : les instructions détaillées du début de conversation sont remplacées par un résumé, et si elles étaient importantes pour la suite, elles peuvent être perdues. La documentation officielle recommande d'ailleurs d'écrire les règles persistantes dans CLAUDE.md plutôt que de compter sur l'historique de conversation, ce qui est exactement la discipline que je défends ici.

Autrement dit, l'auto-compact est un filet de sécurité quand la discipline a échoué, pas une alternative à la discipline. La bonne stratégie reste la même : sessions courtes, règles persistantes dans des fichiers plutôt que dans la conversation, et reprise nette plutôt que compaction floue.

Et pour que cette discipline soit applicable sans perdre l'historique utile, il faut que la méthode soit en dehors de la conversation. Ce qui nous amène à la troisième technique.

Technique 3. Des fichiers découpés finement, pas des monolithes

Beaucoup de gens construisent leur documentation agentique comme un grand fichier monolithique : un projet.md de cinq cents lignes qui contient tout, la description du projet, les règles, les personas, les exemples, les playbooks, les décisions techniques, les notes de réunion. Ce fichier finit par faire dix ou quinze mille tokens. Chaque session où l'agent le charge, c'est quinze mille tokens qui pèsent sur le contexte, dont l'immense majorité n'a aucun rapport avec votre tâche du moment.

L'alternative est un découpage fin. Au lieu d'un gros fichier, vous avez :

docs/
  INDEX.md                   # 20 lignes, la carte du dossier
  architecture.md            # la vue système
  conventions.md             # les règles de code
  domain/
    entities.md
    workflows.md
    edge-cases.md
  agents/
    MANIFEST.md
    support-agent/
      ROLE.md
      playbook-escalade.md

L'index fait une vingtaine de lignes et liste les autres fichiers avec une phrase de description chacun. C'est le seul fichier qui est chargé systématiquement. Les autres sont chargés uniquement quand ils deviennent pertinents pour la conversation en cours.

Cette logique est exactement la même qu'en programmation : on ne charge pas toute la bibliothèque standard pour utiliser une seule fonction. On importe ce dont on a besoin, point. Les agents IA suivent la même logique, à condition qu'on leur en donne les moyens.

L'index est le pivot de cette organisation. Il doit rester court, et surtout il doit être écrit pour être lu par l'agent, pas par un humain qui parcourt une table des matières. Une phrase par entrée, qui décrit précisément quand ce fichier devient pertinent. Pas "description du domaine", mais "à charger quand on parle des règles métier, des workflows ou des edge cases client". L'agent lit cette phrase et décide de charger ou non le fichier. Plus l'indication est précise, plus la décision est bonne.

Le bonus : le prompt caching travaille pour vous

Si vous adoptez les trois techniques précédentes, vous bénéficiez en plus d'une optimisation que Claude fait automatiquement et que la plupart des utilisateurs ne connaissent pas : le prompt caching.

L'idée est simple. Si vos fichiers chargés restent stables entre deux requêtes consécutives, les tokens correspondants sont facturés à environ dix pour cent de leur tarif normal pour les requêtes suivantes. Anthropic les garde en cache côté serveur et les facture au rabais puisque le coût de compute correspondant a déjà été payé.

Cette optimisation est puissante, mais elle a une condition stricte : les fichiers doivent être strictement identiques entre les requêtes. Si vous réécrivez votre CLAUDE.md à chaque session, le cache saute. Si votre index change d'une ligne, le cache saute pour tout ce qui venait après. Le leak de Claude Code révèle que leur équipe surveille quatorze vecteurs différents qui peuvent invalider ce cache, et qu'ils ont conçu des mécanismes spécifiques pour l'éviter, notamment le marqueur SYSTEM_PROMPT_DYNAMIC_BOUNDARY qui sépare la partie statique cacheable de la partie dynamique.

La leçon pratique pour vous : ne touchez pas à vos fichiers de référence pendant une session de travail. Traitez-les comme du code en production. Les modifications se font entre les sessions, délibérément, pas au fil de l'eau. C'est une discipline d'hygiène qui paie deux fois : elle stabilise le comportement de l'agent, et elle fait travailler le cache pour vous.

Eco & logique

Ces trois techniques, combinées, transforment l'économie d'usage d'un agent IA. Mais le bénéfice le plus important n'est pas financier, il est qualitatif. Un agent avec un contexte bien géré est un agent qui répond plus vite, qui se trompe moins souvent, et qui reste focalisé sur votre tâche au lieu de dériver vers des sujets adjacents.

C'est exactement ce que j'appelais en ouverture eco & logique. Économique parce que vous dépensez moins. Écologique parce que vous consommez moins de compute, donc moins d'énergie, donc moins de CO2. Logique parce que c'est aussi la configuration dans laquelle le modèle est le plus performant. Les trois pointent dans la même direction, ce qui n'est pas toujours le cas dans l'industrie logicielle où les bonnes pratiques se contredisent parfois.

Il faut juste renoncer à un réflexe qui est très ancré chez les utilisateurs d'agents IA : l'idée que "plus je lui donne d'informations, mieux il comprend". C'est faux. Au-delà d'un certain seuil, plus vous lui donnez d'informations, moins il comprend. La compétence n'est pas de tout donner, c'est de donner exactement ce qu'il faut, au moment où il en a besoin.

Pour aller plus loin

Le prochain article de cette série traite du pendant stratégique de cette discipline : comment faire en sorte que le travail que vous faites pour un agent donné ne soit pas perdu le jour où vous changez d'outil. La portabilité de la méthode, et ce qui résiste ou non au changement de modèle.

Et si vous vous intéressez à la même obsession du coût appliquée à l'inférence elle-même, plutôt qu'à l'usage, herbert-rs travaille sur l'autre bout de la chaîne : éliminer les opérations inutiles au niveau matriciel, profiler chaque couche, et traiter le compute comme une ressource rare. Eco & logique, jusqu'au bout.

Des questions sur cet article ou votre propre projet ? Réserver une consultation