L'Ingénierie de Contexte : Ce Que C'est et Comment Je L'Utilise pour Construire de Meilleurs Agents IA

Table des matières

Publié en juillet 2026.

TL;DR : L’ingénierie de prompts concerne le choix des mots ; l’ingénierie de contexte concerne l’architecture de l’information. Vous disposez d’une fenêtre de contexte finie et chaque token est un compromis. Je structure le contexte de l’agent en quatre couches — le prompt système, l’historique de conversation, le contenu récupéré et les sorties des outils — et je traite la fenêtre comme un budget, pas comme une toile vierge.

[Note d’opérateur] Je gère plus de 30 agents en production. L’amélioration qui a le plus fait avancer les choses cette année n’est pas un meilleur modèle ni un framework plus sophistiqué — c’est être plus délibéré sur ce qui entre dans la fenêtre de contexte et ce qui en reste dehors. L’ingénierie de contexte est maintenant la compétence principale que je recherche lors de l’évaluation du travail sur les agents.

La plupart des gens parlent encore de “l’ingénierie de prompts” comme de la compétence critique pour travailler avec l’IA. L’ingénierie de prompts est réelle et elle compte. Mais c’est un sous-ensemble d’une discipline plus large — et la traiter comme le travail complet explique pourquoi beaucoup d’agents qui semblent bons en démo s’effondrent en production.

Pourquoi “l’ingénierie de prompts” est devenue le mauvais cadre

“L’ingénierie de prompts” implique que le levier clé est le texte que vous écrivez dans le prompt système ou le message utilisateur. Passez suffisamment de temps à élaborer les bonnes instructions, la bonne formulation, le bon format, et le modèle fera ce dont vous avez besoin.

C’est vrai jusqu’à un certain point. Un prompt système bien rédigé est nécessaire. Mais le comportement du modèle est déterminé par tout ce qui se trouve dans la fenêtre de contexte — pas seulement par votre prompt système. Il est façonné par :

• L’historique de conversation (ce qui s’est passé lors des tours précédents)
• Les documents ou données que vous avez récupérés et injectés
• Les résultats des appels d’outils que le modèle a vus jusqu’à présent
• Le nombre de tokens et la position de chaque information

Si vous pensez uniquement à la formulation du prompt et ignorez le reste de ce qui remplit la fenêtre de contexte, vous optimisez une entrée tout en laissant les autres non gérées. C’est pourquoi “l’ingénierie de contexte” est le cadre plus précis pour le travail sérieux sur les agents.

Ce qu’est réellement l’ingénierie de contexte

L’ingénierie de contexte est la discipline qui consiste à décider quelles informations entrent dans la fenêtre de contexte du modèle, dans quel ordre, à quel moment de la conversation.

La fenêtre de contexte est la mémoire de travail du modèle. Elle est finie. Chaque token que vous y mettez déplace quelque chose d’autre — ou augmente le coût. Et contrairement à la mémoire de travail humaine, le modèle n’a aucun moyen d‘“aller chercher quelque chose” en dehors de ce qui se trouve dans la fenêtre (sauf si vous lui donnez des outils pour le faire). Ce qu’il voit, c’est tout ce qu’il a.

L’ingénierie de contexte est la pratique qui consiste à traiter cette fenêtre comme une ressource à gérer délibérément :

• De quoi le modèle a-t-il besoin pour accomplir cette étape ?
• De quoi avait-il besoin à une étape précédente mais dont il n’a plus besoin ?
• Qu’est-ce qui est stable d’une exécution à l’autre vs. dynamique par requête ?
• Où dans la fenêtre chaque information doit-elle apparaître ?

Ce ne sont pas des questions de formulation de prompts. Ce sont des questions d’architecture de l’information. Et les réponses déterminent la fiabilité de l’agent autant que la sélection du modèle.

Les quatre couches que j’architecture

Chaque agent que je construis comporte quatre couches de contexte distinctes. Je pense à chacune d’elles séparément.

Couche 1 : Le prompt système

C’est le fondement stable et indépendant du tour. Il définit qui est l’agent, ce qu’il peut faire, ce qu’il ne peut pas faire et comment il doit gérer les cas limites.

L’erreur que la plupart des gens font ici est d’écrire le prompt système une fois et de le considérer comme terminé. En pratique, le prompt système doit répondre explicitement à trois questions :

1. À quoi sert cet agent ? (Le modèle a besoin d’une portée précise, pas d’une mission vague.)
2. Que doit-il faire lorsque l’entrée est ambiguë ou incomplète ?
3. Que ne doit-il jamais faire ? (Les contraintes négatives comptent.)

Gardez le prompt système minimal. Chaque phrase inutile est une surcharge qui rivalise avec le contenu dynamique où le raisonnement réel se produit.

Un conseil pratique : si vous utilisez Claude avec l’API, utilisez cache_control sur votre prompt système. Un prompt système volumineux et stable mis en cache coûte environ 10% de ce qu’un prompt non mis en cache coûterait par tour.

Couche 2 : L’historique de conversation

Dans un agent multi-tours, l’historique de conversation est dynamique et croît à chaque tour. Sans gestion, il devient le principal facteur d’inflation du contexte.

Le problème : les tours précédents contiennent des informations dont le modèle n’a plus besoin. Garder tout cela gaspille des tokens et peut confondre le modèle en lui donnant un contexte obsolète.

Ce que je fais :

• Tronquer ou résumer les anciens tours lorsque l’historique dépasse un seuil.
• Ne conserver que les résultats d’appels d’outils encore pertinents.
• Ne jamais laisser l’historique croître sans limite dans un agent longue durée.

Couche 3 : Le contenu récupéré

C’est la couche qui sépare les agents médiocres des bons. La plupart des agents ont besoin d’extraire des données externes à l’exécution.

Deux principes que j’applique :

Récupérer uniquement ce qui est pertinent pour l’étape actuelle. N’injectez pas un document de 50 pages quand l’étape actuelle n’a besoin que d’une section.

La position compte. Les informations au début et à la fin du contexte sont pondérées plus fortement que les informations au milieu. Si un fragment récupéré est absolument nécessaire, ne l’enterrez pas au milieu d’une longue injection.

Couche 4 : Les sorties des outils

Dans une boucle agentique, le modèle appelle des outils et reçoit des résultats. Ces résultats s’accumulent. Et contrairement à l’historique de conversation, les gens pensent rarement à les gérer.

La solution est la même : après qu’un résultat d’outil a rempli son rôle, vous n’avez pas besoin de le conserver dans la fenêtre. Dans un agent multi-étapes, je transmets un résumé structuré de “ce que nous avons établi jusqu’à présent” plutôt que la sortie brute de chaque étape précédente.

Le budget de contexte : quoi inclure et quoi supprimer

J’utilise un modèle mental simple : la fenêtre de contexte est un budget et chaque token est une dépense. Avant chaque tour de l’agent, je me demande :

• De quoi le modèle a-t-il besoin maintenant pour faire cette étape ?
• Que puis-je laisser de côté ou résumer sans perdre quoi que ce soit d’important ?
• Qu’est-ce qui est dupliqué entre les couches ?

L’objectif est d’emballer la fenêtre avec les informations au plus fort signal possible à chaque étape, pas d’être exhaustif.

Trois erreurs d’ingénierie de contexte que j’ai faites en production

1. Des horodatages flottants dans le préfixe stable. Je mettais Date actuelle : {{date}} en haut de mon prompt système. Cette chaîne change chaque jour, ce qui invalidait silencieusement mon cache de prompts toutes les 24 heures. Déplacez les informations volatiles — horodatages, ID utilisateur — à la fin du contexte, après le préfixe stable.

2. Traiter les sorties d’outils comme append-only. J’exécutais des boucles agentiques où chaque résultat d’appel d’outil restait dans le contexte. Au tour 8, le modèle raisonnait à partir d’un contexte composé à 80% de sorties d’outils obsolètes.

3. Ignorer l’évaluation lors des changements de contexte. Les changements de contexte sont des changements de comportement du modèle. J’exécute maintenant le même harnais d’évaluation sur les changements de contexte que sur les changements de prompt.

Mon flux de travail d’ingénierie de contexte en pratique

Avant d’écrire une seule ligne de code d’agent, j’esquisse les couches de contexte :

Prompt système :       ~500 tokens, stable, mis en cache
Budget historique :    ~2000 tokens max, résumé après chaque étape
Contexte récupéré :   ~1000-3000 tokens par étape, fragments pertinents uniquement
Budget sorties :      étape actuelle uniquement, résumé vers l'avant

La question de sélection du modèle vient après. Une fois que je sais quelle ingénierie de contexte je dois faire, je choisis le modèle le moins cher qui maintient le seuil de fiabilité.

FAQ

Quelle est la différence entre l’ingénierie de prompts et l’ingénierie de contexte ?

L’ingénierie de prompts se concentre sur la formulation de votre prompt système et des messages utilisateur. L’ingénierie de contexte est la discipline plus large : décider quelles informations entrent dans la fenêtre de contexte complète — y compris l’historique de conversation, les données récupérées et les sorties des outils — dans quel ordre et à quel coût en tokens.

Quelle doit être la taille de mon prompt système ?

Aussi petit que possible tout en étant spécifique. Je vise moins de 800 tokens pour la plupart des agents. Un prompt système qui essaie d’anticiper chaque scénario finit par être trop long pour être lu de manière fiable par le modèle.

L’ingénierie de contexte compte-t-elle plus pour certains modèles que pour d’autres ?

Elle compte pour tous, mais les enjeux sont plus importants avec les modèles plus petits. Un grand modèle frontier peut parfois se remettre d’un contexte mal structuré ; un modèle plus petit avec un budget plus serré ne peut pas.

Comment savoir si mon ingénierie de contexte fonctionne ?

Suivez les mêmes métriques que vous suivriez pour tout changement de fiabilité : taux de réussite sur votre ensemble d’évaluation, coût par résultat réussi et distribution des erreurs par étape.

Dois-je toujours compresser ou résumer l’historique ?

Pour les agents transactionnels courts : non. Pour les agents multi-tours qui s’exécutent sur plus de 5-6 échanges : oui, toujours. La règle générale que j’utilise — une fois que le budget d’historique dépasse 30% de mon budget de contexte total, je commence à résumer.