Ingénierie du contexte : pourquoi elle compte et comment bien la faire
L'ingénierie du contexte conçoit tout ce que le modèle voit, pas seulement le prompt. C'est ce qui rend les agents fiables.
Traduction produite automatiquement par IA. La version allemande est l'original vérifié par la rédaction.
La fiabilité d'un agent IA dépend moins du modèle que de ce que vous lui présentez. L'ingénierie du contexte est la pratique consistant à concevoir cet ensemble d'informations complet : le prompt système, la mémoire, les outils et les données que vous récupérez, pas seulement la question. D'après notre expérience, c'est le plus grand levier sur le fait qu'un agent fonctionne en production, et c'est une discipline différente de l'ingénierie des prompts (Context Engineering 2.0).
01. AU-DELÀ DU PROMPT
L'ingénierie des prompts règle la question. L'ingénierie du contexte conçoit l'environnement dans lequel le modèle décide. Pour une tâche ponctuelle, un bon prompt suffit. Pour un agent qui s'exécute sur de nombreuses étapes, lit des outils et porte une mémoire, le prompt n'est qu'une petite part de ce que le modèle voit. Le reste, ce que vous récupérez, ce que vous retenez, quels outils vous exposez et comment, c'est le contexte, et il décide bien davantage du résultat. C'est pourquoi étendre un harnais d'agent est surtout un travail de contexte.
02. LES QUATRE ÉCHECS À DÉJOUER PAR LA CONCEPTION
La plupart des échecs d'agents remontent à l'un de quatre problèmes de contexte :
- Surcharge du contexte. Trop dans la fenêtre. Le modèle perd le fil, et le coût comme la latence grimpent. Plus de contexte n'est pas un meilleur contexte.
- Empoisonnement du contexte. Un fait faux ou périmé entre dans la fenêtre et le modèle le traite comme vérité. Un seul mauvais extrait récupéré peut faire dérailler une réponse.
- Gestion des tokens. La fenêtre est finie. Sans plan pour ce qu'on garde et ce qu'on écarte, le détail important est chassé par le bruit.
- Mémoire périmée. Les agents à longue durée accumulent un contexte qui ne s'applique plus, et agissent dessus.
Nommer l'échec, c'est la moitié du remède. Chacun a une contre-mesure concrète.
03. DES PRATIQUES QUI TIENNENT
Quelques schémas reviennent dans les configurations qui restent fiables :
- Récupérer, ne pas déverser. Tirez les quelques passages pertinents avec un bon retrieval plutôt que de tout coller. C'est tout l'intérêt du RAG, et c'est l'ingénierie du contexte appliquée aux données.
- Élaguer au fil de l'eau. Appliquez une édition à base de règles au sein du harnais pour garder la fenêtre légère : écartez ce dont une étape n'a plus besoin.
- Résumer les longs historiques. Remplacez une longue transcription par un résumé fidèle avant qu'elle n'évince la tâche.
- Commencer simple, monter en charge au besoin. N'ajoutez mémoire et outils que quand un échec réel l'exige, pas par défaut.
L'instinct d'en ajouter davantage est le piège. La discipline, c'est la soustraction.
04. POURQUOI C'EST LA VRAIE INGÉNIERIE
Un modèle plus grand corrige rarement un problème de contexte ; il échoue juste plus cher. Le travail qui fait passer un agent de la démo au fiable est presque entièrement un travail de contexte : ce qu'il voit, quand, et ce qu'on lui fait oublier. Pour des entrées très longues, l'architecture du modèle compte aussi, et c'est là qu'interviennent les approches subquadratiques, mais pour la plupart des équipes le gain est dans le contexte, pas dans les paramètres.
