Agents de code : les 5 techniques incontournables pour économiser des tokens
Qui ne s’est jamais retrouvé à court de tokens après une journée de code intense ? Plus performants, mieux branchés à leurs outils, les agents de code (Claude Code, Codex, Antigravity) n’ont jamais été aussi gourmands en tokens. Il existe cependant des techniques bien étudiées qui permettent réellement de faire la différence sur la durée. Le JDN vous propose aujourd’hui 5 techniques éprouvées.
Une gestion du contexte au rasoir
C’est l’erreur courante des débutants. Utiliser un agent de code sans comprendre son fonctionnement intrinsèque augmente les chances d’atteindre rapidement les limites de son abonnement. Un agent de code n’est rien d’autre qu’un modèle d’intelligence artificielle générative connecté à une liste d’outils qu’il peut utiliser au sein d’un même framework. Exemple : Claude Code. Skills, MCP et autres outils prennent de la place dans le contexte envoyé au modèle. Premier réflexe : désactiver ceux dont vous ne vous servez pas, ou peu.
Par ailleurs, second conseil : n’attendez pas la compaction automatique de votre agent d’IA. Compactez manuellement le contexte lorsqu’une tâche donnée est terminée. Les résumés générés par l’agent sont largement suffisants pour que l’agent comprenne votre contexte global de projet. Dans la même veine, lors des grandes refactorisations ou pour des modifications d’ampleur sur un projet, privilégiez toujours l’ouverture d’une nouvelle session plutôt qu’un simple compact. Un contexte léger améliore aussi la qualité des réponses. Plus le contexte est chargé, plus le modèle a tendance à perdre en efficacité (c’est particulièrement le cas au-dessus de 80%).
Donner des prompts courts mais précis
Avec les dernières évolutions des agents de code, toujours plus optimisés chaque semaine, il est de moins en moins nécessaire de rédiger des prompts longs. Les modèles sont maintenant entraînés à être plus efficaces et autonomes dans leur réflexion, nous expliquait Thibault Sottiaux, directeur des produits cœur d’OpenAI (ChatGPT et Codex) en jun. Conséquence, des prompts courts mais cadrés suffisent souvent. Mieux vaut surtout leur donner des critères de réussite clairs. Exemple : “considère la tâche x comme accomplie lorsque les métriques atteignent y”. L’agent saura mieux s’orienter tout seul, sans que votre prompt ne grignote une grande partie du contexte. Bonus : moins de tokens, plus de précision, moins de temps perdu.
Utiliser des CLAUDE.md et AGENTS.md sobres
La sobriété doit également passer par des fichiers AGENTS.md ou CLAUDE.md sobres avec uniquement les instructions vitales pour l’agent. Ces fichiers de consignes agissent comme un prompt système : ils sont injectés avant chaque appel au modèle. C’est encore en 2026 l’une des principales causes de saturation de contexte, notamment si vos agents les éditent seuls. Pour rappel, un bon fichier CLAUDE.md ou AGENTS.md doit contenir :
- quelques lignes sur le contexte global du projet et ses principaux choix techniques
- les conventions de code que le modèle ne peut pas facilement déduire du repository
- les commandes essentielles de build, de test ou de validation
- les règles immuables que l’agent doit respecter
Utiliser un niveau de raisonnement adapté
Utiliseriez-vous un bazooka pour tuer un moustique ? Probablement pas. Avec un agent de code, c’est pareil. Outre le choix du modèle - Claude Sonnet 5, Claude Opus 5, GPT-5.6 Sol, Terra, Luna…, choisir le bon niveau de réflexion est l’un des gestes que les débutants peinent le plus à maîtriser. La pire décision étant d’utiliser le même niveau de réflexion pour toutes les tâches. Partant de là, comment choisir son modèle et le bon niveau de réflexion dans son agent d’IA ? Outre l’itération et l’expérience qui seront vos alliés les plus efficaces, quelques conseils de bon sens :
- Utilisez les modèles lourds avec des niveaux de réflexion avancés pour les tâches de planification, de choix d’architecture et de debugging complexe. Le mode opusplan sur Claude Code est particulièrement adapté.
- Utilisez des modèles moins lourds et/ou de niveaux de réflexion moindres pour les tâches d’édition de code simple.
Au quotidien (nouvelles fonctionnalités, refactoring…), le mieux reste d’utiliser le modèle phare (Opus chez Anthropic, Sol chez OpenAI) et d’adapter le niveau de réflexion en fonction des résultats produits par votre agent. Si vous observez des résultats médiocres, augmentez de façon incrémentale le niveau de réflexion. Enfin, réservez les modèles plus avancés (Fable 5.1 chez Anthropic) aux décisions critiques, aux projets très complexes ou au debugging avancé (assez rare pour 80% des projets). Le bon réglage s’apprend à l’usage.
Utiliser un graphe de connaissances
C’est une pratique encore peu connue et qui pourtant peut vous faire économiser jusqu’à 45% de tokens dans certains contextes : l’usage d’un graphe de connaissances. Le principe est assez simple. Le graphe de connaissances va identifier les relations entre vos fichiers et les dépendances entre eux. Une fois ce travail fait, il est possible de l’utiliser via un MCP. L’agent évite alors une exploration aveugle du dépôt pour comprendre le fonctionnement global de votre projet. Dans notre test, nous sommes parvenus à réduire de 45% la consommation. L’usage d’un graphe de connaissances est toutefois pertinent pour les cas où votre agent s’interroge sur les relations entre vos différents fichiers. C’est moins vrai pour construire au quotidien.