Loïc BoninLB
← Veille

tooling / ia

Context engineering: l'évolution du prompt engineering

9 juillet 2026·6 min de lecture

Introduction

Si votre stratégie pour guider une intelligence artificielle consiste uniquement à peaufiner des adjectifs dans un prompt système géant, vous gaspillez vos ressources. Avec l'avènement des agents autonomes fonctionnant sur de longs horizons et effectuant des dizaines d'appels d'outils, le véritable défi n'est plus de se focaliser que sur la formulation des instructions. Il réside surtout dans la gestion dynamique de la mémoire de travail du modèle. Bienvenue dans l'ère du _context engineering_.

Le terme a été popularisé en juin 2025. Tobi Lütke, PDG de Shopify, l'a défini comme _"l'art de fournir tout le contexte nécessaire pour que la tâche soit plausiblement résoluble par le LLM"_. Andrej Karpathy a précisé quelques jours plus tard : _"l'art délicat et la science de remplir la fenêtre de contexte avec exactement les bonnes informations pour l'étape suivante."_ Ce déplacement conceptuel est fondamental : il s'agit de passer de l'optimisation du langage à l'orchestration de l'information.

Le contexte désigne l'ensemble des jetons envoyés au modèle à chaque appel. Le gérer efficacement consiste à optimiser ces jetons face aux contraintes des grands modèles de langage. Bâtir des agents de production nécessite de penser en contexte : concevoir l'état global disponible pour le modèle à un instant précis et anticiper les comportements induits par cet état.

La RAM de l'IA : comprendre le budget d'attention

Les grands modèles de langage disposent de fenêtres de traitement de plus en plus vastes, atteignant parfois plus d'un million de jetons. Pourtant, l'attention du modèle n'est pas infinie. Chroma Research a documenté le phénomène de pourriture de contexte (_context rot_) en testant les principaux modèles du marché : tous sans exception voient leurs performances se dégrader à mesure que la fenêtre se remplit, et cette dégradation commence bien avant d'atteindre la limite maximale.

Pour comprendre cette limite, il faut regarder sous le capot des modèles de type Transformer (l'architecture de réseau de neurones sur laquelle reposent presque toutes les intelligences artificielles actuelles). Leur mécanisme d'attention compare chaque mot avec tous les autres pour en saisir le sens global. Ce calcul croisé est de nature quadratique. Concrètement, si vous doublez la quantité de texte, le modèle ne fait pas simplement deux fois plus d'efforts : il doit réaliser quatre fois plus d'opérations. C'est cette explosion mathématique qui explique pourquoi le traitement s'alourdit si vite à mesure que la fenêtre se remplit. Le modèle ne s'arrête pas de fonctionner d'un coup ; sa capacité de raisonnement s'érode simplement de manière progressive.

Ce déclin s'accompagne d'un biais de position bien connu : le modèle retient très bien le début et la fin de ce qu'il lit, mais tend à oublier le milieu. Pour couronner le tout, la présence de données superflues agit comme un bruit de fond. Ces distracteurs parasitent l'attention du modèle et le poussent à l'erreur, même lorsque la réponse recherchée figure textuellement dans son contexte.

Le contexte doit donc être traité comme une ressource rare à rendement marginal décroissant. Le rôle du développeur est de trouver la plus petite quantité de jetons à forte valeur ajoutée pour obtenir le comportement attendu.

Les quatre piliers du context engineering

Pour structurer la gestion de la mémoire des agents, nous pouvons diviser les pratiques en quatre catégories : écrire, sélectionner, compresser et isoler.

Écrire : déporter l'information hors du contexte actif

Pour éviter de saturer la mémoire de travail, l'agent doit pouvoir écrire des informations dans un espace de stockage externe.

  • Les blocs-notes (_scratchpads_) : L'agent utilise des outils pour consigner son plan d'action et ses conclusions intermédiaires dans un fichier texte (comme un fichier de notes). Si la session doit être réinitialisée pour vider la mémoire, l'agent n'a qu'à relire ce fichier pour reprendre son travail.
  • La mémoire à long terme : L'agent peut synthétiser ses apprentissages à la fin d'une tâche pour les sauvegarder dans une base de données. Ces connaissances persistantes serviront lors des sessions futures.

Sélectionner : le chargement juste-à-temps

Remplir la mémoire du modèle avec l'intégralité d'une base de données ou d'un codebase serait, pour les raisons évoquées ci-dessus, une erreur de conception.

  • L'extraction juste-à-temps (_just-in-time_) : Au lieu d'injecter tous les fichiers d'un projet, l'agent dispose d'outils de recherche (comme la recherche textuelle ou sémantique) pour localiser et charger uniquement les extraits nécessaires au moment précis de leur utilisation.
  • La sélection dynamique d'outils : Présenter des dizaines d'outils différents au modèle sature son attention et provoque des erreurs de sélection. Filtrer dynamiquement les outils disponibles en fonction de l'étape de la tâche améliore significativement la précision de sélection et la non-surcharge du contexte.

Compresser : réduire la taille de l'historique

Les agents génèrent un volume considérable de jetons via les retours d'appels d'outils et les messages système.

  • Le nettoyage des outils (_tool clearing_) : Une fois qu'un outil a renvoyé ses données et que le modèle les a analysées, conserver l'intégralité du résultat brut dans l'historique est inutile. Le tool clearing permet de vider le contenu des appels passés tout en conservant la trace de l'appel pour maintenir la cohérence logique.
  • La compaction : Lorsque le contexte approche de sa limite, une routine capture l'historique, en extrait un résumé de haute fidélité (les décisions clés, les bugs non résolus, l'état d'avancement) et réinitialise une nouvelle session vierge contenant uniquement ce résumé.

Isoler : diviser pour régner

  • Les architectures multi-agents : Plutôt que de confier une tâche complexe à un unique agent dont le contexte va saturer, le travail peut être réparti entre plusieurs agents spécialisés dotés de contextes étroits et indépendants. L'agent coordinateur ne reçoit que des comptes-rendus synthétiques.
  • L'isolation par variable : Les données lourdes (comme le code source complet ou des fichiers lourds) restent confinées dans un environnement d'exécution sécurisé (_sandbox_). L'agent manipule ces données à travers des variables et des pointeurs, sans jamais charger les objets volumineux dans sa mémoire de travail.

Ce que le développeur doit garder à l'oeil

Bâtir un système avec des agents de code impose des choix d'ingénierie logicielle classiques pour faciliter le travail de l'IA :

  • L'organisation du projet : Des conventions de nommage strictes, des hiérarchies de dossiers claires (ou l'utilisation d'arbres syntaxiques par exemple) pour indexer le code sont essentiels. Si un développeur humain peine à naviguer dans votre architecture, un agent de code échouera également.
  • Les fichiers de contexte persistants : Des outils comme Claude Code (avec son fichier CLAUDE.md), Cursor (avec ses fichiers rules) chargent automatiquement des fichiers d'instructions dans la fenêtre de contexte à chaque session. Ces fichiers constituent une mémoire procédurale : les conventions du projet, les contraintes d'architecture et les processus à respecter. Maintenez-les courts et centrés sur ce qui change d'un projet à l'autre, pas sur ce que le modèle sait déjà faire.
  • La conception des outils pour la densité : Chaque résultat d'outil appelé par l'agent reste dans l'historique. Un outil qui retourne un dump brut de plusieurs milliers de caractères pollue le contexte durablement. Concevez vos outils pour qu'ils renvoient des résumés structurés et actionnables, puis utilisez le nettoyage de résultats pour éliminer le contenu des appels passés une fois consommés. Par exemple, au lieu de concevoir un outil de lecture de logs qui renvoie des milliers de lignes de serveur brutes, créez un outil qui filtre le fichier et retourne uniquement la liste des types d'erreurs uniques et les quelques dernières lignes de trace de la pile. L'agent obtient l'information clé en quelques mots plutôt que d'ingérer des blocs de texte inutiles.
  • L'évaluation du contexte : Concevez des batteries de tests pour mesurer la fidélité des informations conservées après une étape de compaction ou de nettoyage. Sans mesures, vous optimisez votre gestion de contexte à l'aveugle.

Exemple concret : un gestionnaire de contexte pour agent de recherche

Voici un exemple d'implémentation en Python illustrant comment un orchestrateur peut automatiser la compaction de l'historique des messages et le nettoyage des résultats d'outils volumineux.

python
import anthropic
 
class ContextManager:
"""
Gestionnaire de contexte pour agents de longue duree.
Automatise le nettoyage des resultats d'outils volumineux
et la compaction de l'historique en approche de la limite.
"""
def __init__(self, model="claude-5-sonnet-latest", token_threshold=250000):
self.client = anthropic.Anthropic()
self.model = model
self.token_threshold = token_threshold
self.message_history = []
 
def add_message(self, role, content):
self.message_history.append({"role": role, "content": content})
 
def count_tokens(self):
"""Compte les tokens de l'historique courant via l'API officielle."""
response = self.client.messages.count_tokens(
model=self.model,
messages=self.message_history
)
return response.input_tokens
 
def clean_tool_outputs(self, max_chars=1000):
"""
Efface le contenu des appels d'outils anciens pour liberer de l'espace.
Dans l'API Anthropic, les resultats d'outils sont des blocs de type
'tool_result' dans la liste 'content' des messages utilisateur.
"""
for message in self.message_history:
if message["role"] == "user" and isinstance(message.get("content"), list):
for block in message["content"]:
if (
isinstance(block, dict)
and block.get("type") == "tool_result"
and isinstance(block.get("content"), str)
and len(block["content"]) > max_chars
):
block["content"] = "[Contenu supprime par le gestionnaire de contexte]"
 
def compact_context(self):
"""
Invoque le modele pour synthetiser l'historique courant.
Le modele produit un resume de haute fidelite des echanges passes.
"""
prompt_compaction = (
"Resume la conversation ci-dessus de maniere concise. "
"Conserve les decisions techniques prises, les taches en cours "
"et les problemes ouverts. Ignore les echanges de bavardage."
)
 
response = self.client.messages.create(
model=self.model,
max_tokens=2000,
messages=self.message_history + [{"role": "user", "content": prompt_compaction}]
)
return response.content[0].text
 
def run_turn(self, user_message):
"""Execute un tour de conversation avec gestion automatique du contexte."""
# 1. Compacter preventivement l'historique existant si le seuil est depasse,
# avant d'ajouter le nouveau message utilisateur, pour ne pas perdre la requete courante
if self.message_history and self.count_tokens() > self.token_threshold:
summary = self.compact_context()
self.message_history = [
{"role": "user", "content": f"Contexte de la session precedente : {summary}"},
{"role": "assistant", "content": "Compris, je reprends avec ce contexte."}
]
 
# 2. Ajouter le nouveau message de l'utilisateur
self.add_message("user", user_message)
 
# 3. Nettoyer les anciennes sorties d'outils trop lourdes
self.clean_tool_outputs()
 
# 4. Appeler le modele avec le contexte optimal
response = self.client.messages.create(
model=self.model,
max_tokens=4096,
messages=self.message_history
)
 
# 5. Enregistrer la reponse de l'assistant pour le tour suivant
self.add_message("assistant", response.content[0].text)
return response

Dans ce code, le nettoyage des outils intervient pour supprimer les résultats de lecture de fichiers ou de requêtes réseau massives une fois qu'ils ont été consommés. Si le volume global de la conversation dépasse le seuil fixé, la méthode de compaction intervient pour condenser l'historique complet en un unique message de synthèse, libérant immédiatement de l'espace pour la suite de l'exécution.

L'intégration native dans les environnements de développement modernes

Bonne nouvelle pour les développeurs : ces mécanismes complexes de gestion de contexte ne doivent pas nécessairement être recodés à partir de zéro pour chaque projet. Les environnements de développement et les outils d'exécution agentiques modernes (_harnesses_) les intègrent désormais nativement sous le capot.

Des outils en ligne de commande comme Claude Code ou Gemini CLI, ainsi que les éditeurs intelligents tels que Cursor et Gemini IDE, appliquent ces stratégies de manière transparente. Ils analysent en arrière-plan votre historique de commandes, indexent la structure de vos projets et effectuent une sélection chirurgicale des extraits de code pertinents au moment exact où vous formulez une requête. Cette abstraction technique vous évite d'avoir à gérer manuellement la mémoire de travail de l'IA, vous permettant de vous concentrer sur la logique métier et la conception de vos applications.

Conclusion

Vouloir exploiter la puissance des grands modèles de langage en ignorant la physique de leur mémoire de travail est la recette assurée pour obtenir des agents instables en production. Le _context engineering_ n'est pas une simple technique d'optimisation : c'est un changement mature. Il nous force à traiter la fenêtre de contexte non pas comme un espace de stockage passif et infini, mais comme une ressource système dynamique, sujette à l'érosion de l'attention et au bruit de fond.

Bâtir des agents fiables sur le long terme exige une rigueur logicielle classique. En orchestrant l'écriture dans des blocs-notes déportés, en sélectionnant les données avec une extraction "juste-à-temps", en nettoyant l'historique des appels d'outils et en isolant les tâches complexes, l'IA a un cadre où elle peut raisonner avec clarté. Que vous choisissiez d'exploiter l'intégration native des éditeurs modernes ou de coder vos propres orchestrateurs, la règle d'or reste la même : la performance de vos agents dépend moins de la subtilité de vos prompts que de la bonne gestion de la propreté de leur mémoire de travail.

Sources pour l'écriture de l'article

IALLMPrompt EngineringContext HarnessAgent