Context Engineering : l'art de nourrir tes agents IA

#Au-delà du prompt engineering

Tu as probablement entendu parler de prompt engineering — l'art de formuler des instructions claires pour un LLM. Mais quand tu construis des agents IA qui enchaînent des dizaines d'appels, résolvent des problèmes complexes et travaillent sur de longues sessions, les prompts seuls ne suffisent plus.

C'est là qu'intervient le context engineering : la discipline qui consiste à gérer stratégiquement l'ensemble des informations qui entrent dans la fenêtre de contexte d'un modèle à chaque étape d'inférence.

La différence est fondamentale. Le prompt engineering, c'est rédiger une bonne consigne. Le context engineering, c'est orchestrer tout ce que le modèle voit — system prompts, outils, exemples, historique de conversation, données récupérées dynamiquement — pour qu'il ait exactement ce dont il a besoin, ni plus ni moins.

#Pourquoi le contexte est une ressource précieuse

Les LLM ont une fenêtre de contexte limitée. Même avec des modèles qui acceptent des centaines de milliers de tokens, la qualité des réponses se dégrade quand le contexte s'allonge. C'est ce qu'Anthropic appelle le context rot : le modèle doit distribuer son attention entre toujours plus de tokens, ce qui dilue sa capacité à se concentrer sur l'essentiel.

C'est comparable à la mémoire de travail humaine. Tu peux avoir accès à une bibliothèque entière, mais quand tu résous un problème, tu travailles avec un nombre limité d'informations en tête. Ajouter des documents non pertinents ne t'aide pas — ça te ralentit.

Le principe fondamental du context engineering tient en une phrase : trouver le plus petit ensemble de tokens à haute valeur qui maximise la qualité des résultats.

#L'anatomie d'un contexte efficace

Un contexte bien conçu se compose de quatre éléments, chacun jouant un rôle distinct.

#Le system prompt

C'est la fondation. Il définit le comportement, le ton et les contraintes de l'agent. Anthropic recommande de trouver une zone Goldilocks — ni trop rigide, ni trop vague :

Trop rigide : tu codes en dur une logique fragile qui casse dès qu'un cas imprévu se présente
Trop vague : le modèle manque de repères concrets pour adopter le comportement voulu

L'idéal, c'est un prompt suffisamment spécifique pour guider le comportement, mais assez flexible pour que le modèle puisse s'adapter.

Organise ton system prompt en sections distinctes avec des headers Markdown ou des balises XML. Par exemple : ## Contexte, ## Instructions, ## Outils disponibles, ## Format de sortie. Ça aide le modèle à naviguer dans les instructions.

#Les outils

Chaque outil que tu donnes à un agent consomme des tokens (sa description, ses paramètres, ses instructions d'utilisation). Des outils bien conçus doivent être :

Autonomes : chaque outil gère ses propres erreurs et retourne des résultats exploitables
Sans chevauchement : si un humain ne sait pas quel outil choisir entre deux options, le modèle non plus
Clairement décrits : des noms explicites, des paramètres documentés, des cas d'usage précis

Un excès d'outils crée une paralysie décisionnelle chez l'agent. Mieux vaut cinq outils bien ciblés que vingt outils qui se recoupent.

#Les exemples (few-shot)

Plutôt qu'une longue liste de règles couvrant tous les cas limites, quelques exemples bien choisis montrent au modèle exactement ce que tu attends. Les exemples sont les images valant mille mots pour un LLM.

La clé : sélectionne des exemples diversifiés et représentatifs. Un petit nombre d'exemples canoniques est plus efficace qu'une dizaine d'exemples trop similaires.

#L'historique de conversation

Au fil des échanges, l'historique accumule des tokens. Chaque message, chaque résultat d'outil, chaque réflexion du modèle reste dans le contexte. Sans gestion active, cet historique finit par noyer les informations importantes sous une masse de données obsolètes.

#Stratégies de récupération de contexte

Comment décider quelles informations charger dans le contexte, et à quel moment ? Deux approches complémentaires existent.

#Récupération pré-inférence

L'approche classique : tu charges toutes les données pertinentes avant de lancer l'agent. C'est simple et prévisible, mais ça consomme beaucoup de tokens et tu risques de charger des informations qui ne serviront jamais.

#Récupération juste-à-temps

L'approche agentique : plutôt que de tout charger d'avance, l'agent récupère les données au moment où il en a besoin, via des outils. Tu maintiens des références légères (chemins de fichiers, URLs, requêtes stockées) et tu laisses l'agent aller chercher le contenu quand c'est pertinent.

C'est exactement ce que fait Claude Code au quotidien. Plutôt que de charger un dataset entier dans le contexte, il utilise des commandes ciblées (head, tail, grep) pour examiner sélectivement les données.

L'approche hybride est souvent la meilleure : charger un minimum de contexte au départ pour la vitesse, et laisser l'agent explorer en profondeur quand il en a besoin.

#Progressive disclosure

Ce concept mérite une mention spéciale. L'idée : l'agent découvre progressivement le contexte pertinent par exploration autonome. Les noms de fichiers, la structure des dossiers, les conventions de nommage sont autant d'indices implicites qui guident l'agent vers l'information utile.

C'est le principe derrière les Skills de Claude Code : au démarrage, seuls les noms et descriptions des Skills sont chargés (~100 tokens chacun). Le contenu complet n'est chargé que si le Skill est pertinent pour la tâche en cours.

#Techniques pour les tâches longues

Les agents les plus utiles sont ceux qui travaillent sur des tâches qui s'étalent dans le temps — refactoring de codebase, analyse de données, développement de features. Mais plus la session est longue, plus le contexte se remplit. Trois techniques permettent de gérer ce défi.

#La compaction

La compaction consiste à résumer l'historique de conversation pour libérer de l'espace. Le modèle condense les échanges passés en un résumé compact, puis repart avec ce résumé comme base.

Les priorités quand tu compactes :

Maximiser le rappel d'abord — capturer toutes les informations potentiellement utiles
Améliorer la précision ensuite — éliminer le superflu
Jeter sans risque : les sorties d'outils redondantes, les logs d'interactions passées
Préserver absolument : les décisions architecturales, les bugs non résolus, les détails d'implémentation

La Developer Platform de Claude propose un mécanisme de "tool result clearing" — la forme la plus légère de compaction. Au lieu de résumer tout l'historique, tu effaces simplement les résultats d'outils volumineux qui ne sont plus nécessaires.

#La prise de notes structurée

Plutôt que de tout garder en mémoire de travail, l'agent maintient des notes persistantes dans un fichier externe (un NOTES.md, une todo list, un carnet de bord). Ces notes sont rechargées dans le contexte quand c'est nécessaire.

Un exemple concret : dans les expériences d'Anthropic, Claude jouant à Pokémon a maintenu des compteurs précis sur des milliers d'étapes — objectifs d'entraînement, régions explorées, succès débloqués — le tout grâce à un fichier de notes mis à jour régulièrement.

C'est le même principe que les fichiers CLAUDE.md : un contexte persistant rechargé à chaque session pour maintenir la cohérence.

#Les architectures multi-agents

La technique la plus puissante pour les tâches complexes. Au lieu d'un seul agent qui fait tout, tu décomposes le travail :

Un agent principal qui coordonne le plan d'ensemble
Des sous-agents spécialisés qui exécutent des tâches ciblées avec un contexte propre
Chaque sous-agent retourne un résumé condensé (1 000 à 2 000 tokens) au lieu de tout son historique de travail

Technique	Meilleur pour	Avantage principal
Compaction	Conversations longues avec beaucoup d'allers-retours	Libère de l'espace sans perdre le fil
Prise de notes	Développement itératif avec des jalons clairs	Persistance entre les sessions
Multi-agents	Recherche et analyse complexe	Parallélisation et isolation du contexte

En pratique, les trois techniques se combinent. Claude Code utilise les trois simultanément : compaction automatique quand le contexte se remplit, fichier CLAUDE.md comme mémoire persistante, et sous-agents (Task) pour les tâches de recherche en profondeur.

#Mettre en pratique

Voici les principes à retenir quand tu conçois le contexte de tes agents :

1. Suffisance minimale. Commence avec le minimum de contexte nécessaire. Ajoute des informations seulement quand tu constates un manque. Chaque token superflu dilue la qualité.

2. La bonne altitude. Tes instructions doivent être au bon niveau de détail. Trop haut (vague), le modèle improvise. Trop bas (micro-management), tu perds en flexibilité et tu consommes du contexte inutilement.

3. Efficacité des outils. Conçois tes outils pour être économes en tokens. Des descriptions concises, des paramètres clairs, pas de redondance entre outils.

4. Complexité progressive. Commence avec un prompt minimal. Ajoute des exemples et des instructions au fur et à mesure que tu identifies des lacunes. Ne sur-ingénierie pas dès le départ.

5. Autonomie proportionnelle. Plus le modèle est capable, moins tu as besoin de le guider. Les modèles récents comme Claude nécessitent progressivement moins de curation prescriptive — fais-leur confiance sur les décisions qu'ils savent prendre.

#Ce qu'il faut retenir

Le context engineering est la compétence qui sépare un prototype qui marche en démo d'un agent qui fonctionne en production. Le prompt engineering te donne les bons mots. Le context engineering te donne le bon système.

Les points essentiels :

Le contexte est une ressource finie et précieuse — traite-le comme tel
Préfère la récupération juste-à-temps au chargement massif
Pour les tâches longues, combine compaction, notes structurées et sous-agents
Commence simple et itère — le meilleur contexte est le plus petit qui fonctionne

Pour approfondir, consulte l'article original d'Anthropic sur le context engineering pour les agents IA et le memory and context management cookbook de la Developer Platform.