Un guide pratique pour réduire les tokens consommés par les agents IA sans les rendre aveugles : contexte minimal, outils ciblés et mesures.
Pourquoi les agents IA consomment autant de tokens
Un agent de développement ne reçoit pas uniquement notre question. À chaque étape, il peut aussi traiter ses instructions permanentes, l’historique de la session, les fichiers consultés, les résultats des commandes et la description de ses outils.
Sur un gros projet, le prompt utilisateur représente parfois une toute petite partie de la consommation totale. Le vrai problème est souvent le contexte chargé automatiquement ou accumulé pendant la session.
Réduire les tokens ne consiste donc pas à écrire des demandes télégraphiques. Il faut surtout éviter d’envoyer des informations inutiles au modèle.
AGENTS.md n’améliore pas forcément les résultats
Une étude publiée en février 2026 a évalué l’utilité des fichiers comme AGENTS.md et CLAUDE.md sur SWE-bench Lite et sur AGENTBENCH, un benchmark de 138 tâches Python provenant de 12 dépôts.
Les fichiers générés automatiquement par une IA ont légèrement réduit le taux de réussite moyen. Les fichiers écrits par les développeurs ont apporté une amélioration modeste, mais les fichiers de contexte ont augmenté les coûts d’inférence de plus de 20 %.
Les agents ne les ignoraient pas. Au contraire, ils suivaient leurs consignes, lisaient davantage de fichiers et lançaient plus de tests. Cette exploration supplémentaire coûtait plus cher sans garantir un meilleur correctif.
Cette étude ne prouve pas qu’AGENTS.md est inutile. Elle montre surtout qu’un mauvais fichier de contexte peut ajouter du travail sans ajouter d’information réellement utile.
Garder un fichier d’instructions minimal
AGENTS.md ne devrait pas devenir une seconde documentation du projet. Il doit contenir uniquement les règles utiles à presque toutes les tâches :
- les commandes fiables pour installer et tester le projet ;
- les contraintes techniques inhabituelles ;
- les fichiers générés qui ne doivent pas être modifiés ;
- les règles de sécurité importantes ;
- les critères permettant de considérer une tâche comme terminée.
Les descriptions détaillées de l’architecture, les procédures rarement utilisées et les longues conventions déjà imposées par un linter peuvent rester dans une documentation séparée.
Exemple d’AGENTS.md concis
# Projet
- Installer les dépendances avec `npm ci`.
- Utiliser `npm test -- chemin-du-test` pendant le développement.
- Lancer `npm run lint` avant de terminer.
- Ne pas modifier les fichiers de `dist/`.
- Ne pas ajouter de dépendance sans justification.
- Limiter les changements au périmètre demandé.
Documentation à consulter uniquement si nécessaire :
- Base de données : `docs/database.md`
- Déploiement : `docs/deployment.md`
- Interface web : `docs/frontend.md`
Quelques dizaines de lignes précises sont souvent plus utiles que plusieurs centaines de lignes génériques.
Charger les connaissances à la demande
Les informations spécialisées ne doivent pas toutes vivre dans le contexte permanent. Il est préférable d’utiliser des fichiers associés à un sous-répertoire, des skills ou une documentation que l’agent consultera seulement lorsque la tâche le nécessite.
Codex permet notamment de répartir les instructions dans plusieurs AGENTS.md selon l’arborescence du dépôt. Les skills utilisent également une logique de divulgation progressive : leur description est visible au départ, mais leur contenu complet n’est chargé que lorsqu’ils sont utilisés.
Cette organisation évite de parler de Docker, de déploiement et de base de données à un agent chargé de corriger une couleur dans une feuille CSS.
Donner une mission étroite et vérifiable
Un prompt efficace précise l’objectif, le périmètre et la validation attendue.
Corrige l’erreur de validation du formulaire de connexion.
Périmètre :
- `src/auth/`
- les tests associés
Contraintes :
- ne pas modifier l’API publique ;
- éviter les refactorisations sans rapport avec le bug.
Validation :
- reproduire le problème ;
- ajouter ou adapter un test ;
- lancer uniquement les tests concernés, puis le linter.
Une mission précise réduit les recherches inutiles et permet à l’agent de savoir quand s’arrêter.
Limiter les sorties des outils
Les résultats de commandes rejoignent eux aussi le contexte. Un listing récursif, un journal complet ou une suite de tests entière peut consommer plusieurs milliers de tokens.
Il vaut mieux cibler les recherches, limiter les journaux aux dernières lignes, commencer par les tests concernés et n’afficher un diff complet que lorsqu’il est nécessaire.
Il faut toutefois éviter l’excès inverse : supprimer une information indispensable peut provoquer une mauvaise modification et coûter beaucoup plus cher en corrections.
Repartir sur une session propre
Une conversation consacrée successivement à un bug, une migration et une revue de sécurité accumule du contexte sans rapport avec la tâche actuelle.
Lorsqu’on change complètement de sujet, mieux vaut démarrer une nouvelle session. Pour une tâche longue, la compaction permet de conserver les décisions et les changements importants tout en supprimant une partie des échanges intermédiaires.
Choisir les outils et le modèle selon la tâche
Un modèle puissant n’est pas nécessaire pour corriger une faute ou renommer une variable. Il reste en revanche utile pour une migration complexe ou une décision d’architecture.
Même logique pour les outils MCP et les sous-agents : chaque outil possède une description, et chaque agent supplémentaire dispose de son propre contexte. Les activer sans besoin réel peut augmenter la consommation avant même le début du travail.
Profiter du cache sans compter uniquement dessus
Les fournisseurs proposent du prompt caching pour réduire le prix des contextes répétés. Le cache fonctionne mieux lorsque les instructions stables restent au début et que les données variables arrivent ensuite.
Le cache peut réduire la facture et la latence, mais il ne transforme pas un contexte inutile en bon contexte. Un agent peut toujours perdre du temps à suivre des instructions superflues, même lorsque leur lecture est facturée moins cher.
Mesurer avant et après
Pour vérifier une optimisation, il faut tester plusieurs tâches représentatives et relever :
- les tokens d’entrée, de sortie et ceux servis depuis le cache ;
- le nombre de fichiers lus et d’appels d’outils ;
- la durée et le coût de la session ;
- la réussite des tests ;
- les corrections manuelles encore nécessaires.
Le meilleur réglage n’est pas forcément celui qui utilise le moins de tokens. C’est celui qui obtient un résultat correct avec le moins de travail et de contexte inutiles.
Conclusion
Pour optimiser un agent IA, il faut surtout maîtriser ce qu’on lui donne à lire. Gardez les instructions permanentes courtes, déplacez les procédures spécialisées vers des ressources chargées à la demande et donnez des missions précises avec une validation claire.
Un AGENTS.md bien écrit peut éviter des erreurs. Un AGENTS.md trop bavard risque surtout de transformer chaque petite tâche en audit complet du dépôt.
Étude Evaluating AGENTS.md
Documentation Codex sur AGENTS.md
Documentation Claude Code sur les coûts
Documentation OpenAI sur le prompt caching