Comment les agents IA économisent des tokens sur une grosse base de code : 5 patterns

Le problème : les tokens fondent dans l'exploration

Les agents IA s'intègrent de plus en plus profondément dans le processus de développement — ils ne se contentent plus de générer des fonctions, ils explorent les projets, cherchent des fichiers, analysent l'architecture, lancent des tests. Sur de grandes bases de code, un problème aigu apparaît : une part importante des tokens est consommée avant même l'écriture de la première ligne de code. Pour une modification mineure, l'agent peut avoir besoin d'étudier la structure du dépôt, de trouver le bon service, de lire la documentation, de comprendre les conventions, de regarder comment sont organisés les tests.

À la tâche suivante, une partie de cette exploration se répète. Sur un petit projet, cela passe inaperçu, mais plus le dépôt est volumineux, plus explorer le système devient coûteux.

Tenter de nourrir l'agent avec toute la documentation d'un coup, ou utiliser un modèle moins cher, produit soit un effet marginal, soit déplace simplement la dépense de tokens ailleurs. La bonne approche consiste à traiter la gestion des tokens comme un problème de gestion du contexte, en appliquant les principes de lazy loading, de localité des données, de mise en cache et de séparation des responsabilités au flux d'informations de l'agent IA.

Cinq patterns d'optimisation du contexte

1. Minimize Permanent Context

L'histoire de l'accumulation de connaissances se répète toujours de la même façon : on crée un AGENTS.md ou un CLAUDE.md et on commence à y entasser de plus en plus d'informations. D'abord l'architecture et la structure du dépôt, puis les règles d'écriture du code, les conventions des services, les spécificités de la base de données, des tests, du CI/CD et des intégrations.

Le problème : tout cet ensemble devient un contexte permanent. Pour modifier le service de facturation, l'agent n'a probablement pas besoin des règles de développement de l'application mobile, mais si elles figurent dans le contexte global, le modèle les reçoit encore et encore. Les instructions globales doivent être une carte du projet (où trouver l'information ?), pas une encyclopédie (que raconter en tout ?). L'AGENTS.md racine indique où se trouvent les instructions détaillées pour l'authentification, la facturation, la base de données, l'infrastructure — tout le reste se charge à la demande.

2. Progressive Context

Les connaissances s'organisent en couches : contexte global → contexte du domaine/service → instructions spécifiques à la tâche → implémentation de référence → code source pertinent. Pour une tâche d'ajout d'un nouveau fournisseur de paiement, l'agent suit le chemin : AGENTS.md → services/payments/AGENTS.

md → skills/add-payment-provider.md → implémentation existante du fournisseur → fichiers source pertinents. Pour une application mobile, le chemin est totalement différent, pour l'infrastructure, c'est un troisième chemin.

Au lieu de 20 000 tokens pour « tout sur le projet », on obtient : contexte global (500) + contexte du service (700) + instructions de tâche (600) + référence (800) + fichiers source (2500). La majeure partie des connaissances du projet existe séparément et n'entre dans le contexte que lorsqu'elle devient pertinente.

3. Reduce Exploration

Même avec un contexte permanent réduit, une source majeure de dépense subsiste : l'exploration de la base de code. L'agent doit découvrir où se trouvent les gestionnaires de paiement, quel service publie les événements, quel message broker est utilisé, où sont les consumers, comment les notifications sont créées, où se trouvent les templates, comment ils sont testés. Un bon dépôt fournit des points d'entrée : une carte du projet avec des sections (HTTP handlers : services//handlers/, Business logic : services//domain/, etc.)

, des exemples de référence (pour un nouveau consumer de messages, un lien vers services/orders/consumers/order-created/ montre la structure, le naming, la gestion des erreurs, le logging, l'interaction entre couches, les tests), et le principe « search before read » (d'abord une recherche via rg, git grep, outils LSP, puis la lecture).

4. Reuse Knowledge

Quand un agent explore le traitement d'une commande, il déroule toute la chaîne : requête HTTP → service de commandes → service de facturation → fournisseur de paiement → événement de paiement → message broker → consumer de commandes. Pour cela, il lit des centaines de fichiers. Puis la session se termine, une nouvelle tâche arrive une semaine plus tard, et un nouvel agent recommence l'exploration depuis zéro.

Cette duplication des connaissances doit être éliminée. Si l'exploration a révélé une particularité importante et stable du système, le résultat mérite d'être sauvegardé dans docs/payment-flow.md, avec une description courte, une liste de fichiers et un lien vers l'implémentation de référence.

La session IA suivante démarrera avec quelques centaines de tokens de description structurée au lieu de relire les fichiers. Les connaissances utiles se stockent dans l'AGENTS.md, les instructions de service, la documentation, les skills spécifiques aux tâches, les notes d'architecture, les exemples de référence ou les commentaires de code, selon le périmètre.

On obtient ainsi un cycle : découverte coûteuse → connaissance structurée → récupération future à bas coût.

5. Keep Context Clean

L'envers de l'approche précédente : si chaque découverte utile est sauvegardée, la documentation ne cesse de grossir et une pollution du contexte s'installe — instructions obsolètes, exemples dépassés, conventions oubliées coexistent avec les nouvelles. Le contexte doit être nettoyé régulièrement : supprimer les informations obsolètes, actualiser les exemples, éliminer les doublons. Comme pour le code, mieux vaut supprimer une documentation périmée que la laisser avec un commentaire d'avertissement.

Les cinq patterns fonctionnent ensemble : minimiser le contexte permanent, charger les connaissances par couches selon les besoins, aider l'agent à moins explorer grâce à des points d'entrée, ne jamais répéter une exploration coûteuse deux fois, et supprimer les informations obsolètes. Résultat : la baisse des coûts en tokens ne vient pas de modèles moins chers, mais de la maîtrise de l'information que voit l'agent, et du moment où il la voit.