Context engineering: rendre l'IA déterministe en production

Prod, pas session IDE

Le context engineering en production, ce n'est pas compact/clear dans Claude Code. C'est concevoir tout ce qui arrive dans le modèle quand un agent métier tourne: system, outils, documents, historique, politiques. L'hygiène de session IDE a son article dédié.

En 2025-2026, le consensus des équipes qui opèrent des agents est clair: la plupart des échecs ne sont plus « le modèle est nul », ce sont des échecs d'assemblage de contexte. Le prompt peut être correct; ce qui entre dans la fenêtre est faux, bruyant ou trop long.

En prod, le goulot n'est plus seulement quel modèle, mais quel contexte, à chaque requête, de façon rejouable. Sans la troisième brique (contrôle: allowlist, logs, HITL), tu as juste un POC / une démo.

Quatre stratégies: Write, Select, Compress, Isolate

Un cadre largement repris (formalisation LangChain pour agents) organise le travail en quatre mouvements:

Write: persister le contexte hors fenêtre (state machine, base de tickets, handoff fichier, mémoire projet). La fenêtre est finie; ce qui doit survivre entre appels s'écrit ailleurs.

Select: ne récupérer que le pertinent (RAG borné, filtres, top-k, règles d'inclusion). Un Drive entier n'est pas un contexte.

Compress: résumer, tronquer les sorties d'outils, hybrid sliding window (N derniers tours bruts + résumé de l'ancien). Sur tâches longues, compresser d'abord.

Isolate: contextes séparés par agent ou sous-tâche (subagents). L'orchestrateur n'avale pas l'historique de recherche complet.

Ce qu'il y a dans une context window

Quatre piliers pratiques reviennent dans les guides agents: instructions (system et framing), retrieval (RAG / docs), mémoire (court terme conversation, long terme projet), outils (function calling, de plus en plus via MCP).

Les tools bruyants (JSON énormes, logs bruts) pourrissent le contexte aussi vite qu'un chat trop long. On filtre, on résume, on borne la taille des réponses outils.

Si tu branches plusieurs serveurs MCP, compte les tokens des schémas d'outils avant toute requête utilisateur. Ce coût d'entrée est souvent sous-estimé.

Pourrissement de contexte et qualité

Les LLM s'appuient surtout sur le début et la fin du contexte. Le milieu s'érode. Après un certain remplissage, la qualité chute (même physique que la dump zone côté coding agents).

En agent métier: prix inventé, policy oubliée, doc obsolète citée. Contre-mesure: corpus versionné, citations obligatoires, max documents, reset d'état entre tickets, isolate pour la recherche lourde.

Versionne prompts, templates, pipelines de retrieval et définitions d'outils comme du code. Un « petit changement » non daté rend le debug impossible.

Skills, routing, évaluation

Skills et playbooks versionnés battent les prompts jetables. Trigger explicite quand tu veux du déterminisme.

Si l'agent sert plusieurs domaines, ajoute du routing (même des règles mots-clés au début) pour couper le bloat avant d'investir dans un classifieur LLM.

Évalue: jeu de 30-50 cas gold (entrée → sortie ou classe d'action). Mesure tokens par ticket, taux d'échec, taux d'edit humain. Sans golden set, chaque « amélioration » est une opinion.

Checklist prod

1) Sources listées. 2) Write/Select/Compress/Isolate appliqués. 3) Cap taille outils. 4) Tokens des schémas MCP comptés. 5) Versioning. 6) HITL sur sorties à impact. 7) Budget mensuel. 8) Cas gold.

Si un point manque, tu optimises encore au feeling. Acceptable en spike, pas en production client.

Si vous voulez un audit de contexte sur un agent métier, on peut cadrer en 20-40 minutes.