Gestion du contexte et fiabilité

L’API est sans état : chaque requête renvoie tout — toute la conversation, chaque résultat d’outil, chaque instruction — et le modèle ne voit que ce que contient cette requête. Une fenêtre de 200 000 tokens semble impossible à remplir jusqu’à ce qu’un après-midi de travail agentique s’en charge : les sorties d’outils sont énormes, les impasses y sont encore, et rien n’en sort à moins que vous ne le gériez. La gestion du contexte est l’ensemble nommé des leviers ; la fiabilité est ce que les leviers protègent.

01Les leviers nommés — et quand chacun s’applique

L’examen attend de vous l’appariement symptôme-levier, et les leviers ont des noms. Compaction : remplacez l’historique ancien par un résumé et continuez — la session reste une conversation, au dixième de la taille. Context editing : effacez les plus anciens résultats d’outils (en gardant les appels d’outils les plus récents et leurs résultats, la réflexion ancienne étant résumée par conception) — un soulagement chirurgical de l’enflure de sorties d’outils, sans réécrire tout le fil. Le memory tool : des notes durables stockées en fichiers sous /memories, écrites et lues à la demande — le savoir qui doit survivre aux sessions : préférences de l’utilisateur, décisions, la carte du code. La délégation : confier le travail à un subagent dont le bruit n’atteint jamais la fenêtre parent — l’isolation, première raison du domaine 1. Et le prompt caching se cite dans le même souffle pour une autre raison : il ne rétrécit rien, il rend le préfixe stable bon marché — écrire une fois avec prime, lire au dixième à chaque appel ultérieur, TTL de cinq minutes par défaut avec l’option une heure.

Le vocabulaire qui les organise — et une distinction déjà examinée : l’élagage (pruning) dégage le contenu après son arrivée (compaction, context editing) ; l’isolation l’empêche d’arriver (subagents, tool search). Deux cures différentes de la même enflure. Et le memory tool n’est ni l’un ni l’autre : c’est de la durabilité — la persistance entre sessions, pas le soulagement à l’intérieur d’une. Quand un scénario vous tend un symptôme, déroulez le cadre : la session est longue et doit continuer comme une seule conversation → compacter ; l’enflure est spécifiquement des vieux résultats d’outils → context editing ; le savoir doit survivre à demain → memory tool ; le bruit n’aurait jamais dû atteindre cette fenêtre → déléguer ; la fenêtre va bien mais pas la facture → caching. Une ligne chacune, et chaque question de ce sous-domaine est l’une des cinq.

02Escalade et résolution de l’ambiguïté

Les agents à longue exécution rencontrent des questions qu’ils ne peuvent pas régler seuls, et la formule de l’examen pour la conception est une échelle d’escalade : l’agent règle ce qu’il peut, diffère ce qu’il doit, et un humain règle ce qui monte. Les déclencheurs sont les décisions de conception : le rayon d’action (une action irréversible monte), l’ambiguïté que l’agent peut détecter (deux lectures d’une exigence, toutes deux plausibles), la confiance sous le seuil (section suivante), et la politique (les catégories de décisions qu’une organisation a décidé de réserver aux humains). Chaque échelon achète de la sûreté et coûte de la latence — le troc est explicite, et le scénario vous dit toujours le côté auquel l’entreprise est sensible.

La résolution de l’ambiguïté est l’échelon d’en dessous : la décision entre demander et trancher. La règle que l’examen récompense : demandez quand le coût de demander est inférieur au coût attendu de se tromper — une phrase de clarification contre une migration sur la mauvaise table. Mais demander n’est pas gratuit non plus (flux interrompus, fatigue humaine, agents qui demandent tout), donc l’art est de rendre les demandes rares et bon marché : régler ce que le brief règle ; énoncer à voix haute les hypothèses que l’utilisateur peut corriger au passage quand les enjeux sont bas ; regrouper les questions plutôt que de les laisser couler ; et réserver la vraie interruption à l’irréversible. Un agent qui ne demande rien est dangereux ; un agent qui demande tout est inutilisable — les scénarios de l’examen sont calibrés entre ces pôles.

03La propagation des erreurs dans les systèmes multi-agents

Au domaine 1, le coordinateur recevait des rapports ; ici l’examen demande ce qui arrive quand un rapport est mauvais — ou ne vient jamais. La question de conception est toujours la même : quand un ouvrier échoue, qui apprend quoi, et qu’advient-il de la mission ? Les motifs de propagation sont trois postures. Échouer vite (fail fast) : le premier échec d’ouvrier avorte l’exécution — juste quand des résultats partiels sont pires que rien (un rapport financier de trois sources dont une est fausse est un rapport faux). Reprendre et continuer : les échecs transitoires (un timeout d’outil, une limite de débit) se reprennent avec temporisation et la mission suit son chemin — juste quand les unités sont indépendantes et que les probabilités favorisent la récupération. Dégénérer avec grâce (degrade gracefully) : la mission se termine moins la partie échouée, le manqué déclaré dans le résultat — juste quand 90 % de couverture aujourd’hui battent 100 % la semaine prochaine, à condition que la sortie dise quels 10 % manquent.

Trois règles de propagation gardent les motifs honnêtes. Remonter, jamais avaler : un ouvrier qui rattrape ses propres erreurs et rend « terminé, avec réserves » empoisonne chaque décision en aval — le coordinateur doit voir les échecs comme des échecs, structurés (le contrat d’erreur du domaine 2, d’agent à agent). Propager avec contexte : « l’ouvrier 3 a échoué : l’API paiements a renvoyé 429 pendant dix minutes ; les résultats partiels couvrent les services A à F » apprend quelque chose au coordinateur ; « erreur » non. Et marquer la confiance à la frontière : le rapport du coordinateur doit porter ce sur quoi il est bâti — quelles conclusions viennent de passes complètes, lesquelles de passes dégradées. Les symptômes-phrases de l’examen se mappent sur des règles brisées : « le coordinateur a rapporté un succès avec trois ouvriers en échec » = étouffement ; « on ne savait pas ce qui avait cloché » = propagation sans contexte ; « la réponse finale citait la source défaillante » = pas de marquage de confiance à la frontière.

04Le contexte dans l’exploration de grosses bases de code

On ne peut pas lire un dépôt entier dans une fenêtre, et la position de l’examen est qu’il ne faut pas essayer : l’exploration est une recherche agentique, pas une ingestion en vrac. La boucle du domaine 1, pointée sur une base de code : formuler une hypothèse sur où vit la réponse (Glob par motif de nom, Grep par contenu), lire étroitement (Read avec offset et limit sur les touchés), raffiner l’hypothèse, répéter. Chaque étape coûte une fraction d’une lecture en vrac, et les impasses — le grep raté, le mauvais répertoire — sont de l’information au lieu du bagage. C’est aussi pourquoi les subagents d’exploration en lecture seule existent (encore l’isolation) : laissez le bruit se produire dans une fenêtre que vous jetez, et gardez la carte distillée dans celle que vous gardez.

Les choix de l’architecte dans un scénario : la recherche ciblée plutôt que la lecture en vrac partout où la question est localisable (« où X est-il géré ? » n’a jamais besoin de tout l’arbre) ; les lectures étroites plutôt que fichiers entiers pour les gros (offset et limit sont des lignes de budget de contexte) ; la délégation quand le volume d’exploration est grand ou jetable ; la compaction ou le context editing quand l’exploration accumulée d’une session étouffe le travail ; et le memory tool (ou CLAUDE.md, ou un fichier de notes) quand la carte elle-même est l’actif durable — le plan que vous avez appris aujourd’hui est ce que la session de demain ne devrait pas avoir à réapprendre. Les réponses-pièges sont toujours le vrac : « tout lire puis décider », « augmenter la fenêtre de contexte », « coller le dépôt dans le prompt ».

05Revue humaine et calibration de confiance

Le domaine 1 mettait les humains en haut de l’échelle d’escalade ; ce sous-domaine est l’ingénierie de cet échelon. La conception a trois parties. Le filtrage : quelles sorties partent en revue — par rayon d’action (tout ce qui écrit, envoie, supprime ou dépense), par confiance (sous un seuil, paragraphe suivant), et par échantillonnage (une tranche aléatoire du flux confiant, auditée, parce que la dérive silencieuse est le mode d’échec que les filtres de confiance ne voient pas). La présentation : le relecteur voit la proposition avec ses preuves — le diff, les sources, la chaîne de décisions — de quoi juger vite sans refaire ; au moment où relire coûte autant que faire, l’échelon était mal tarifé. Le retour : chaque verdict humain reflue — dans le prompt, les exemples, les seuils — parce qu’une file de revue qui ne fait qu’attraper sans jamais enseigner est une subvention, pas un contrôle.

La calibration de confiance est le cœur technique du sous-domaine, et la formule de l’examen est sèche : la confiance auto-déclarée d’un modèle n’est pas, en soi, un chiffre fiable — elle doit être calibrée contre la précision mesurée sur votre tâche, avec vos données, via des jeux d’évaluation. La calibration, c’est la correspondance entre la confiance énoncée et l’exactitude observée : lancez un jeu étiqueté, regroupez les sorties par confiance énoncée, mesurez la précision par groupe, et fixez le seuil là où le troc mesuré (ratés contre charge de revue) correspond à la tolérance du métier. Une fois calibrée, le chiffre mérite son poste — auto-approuver la bande haute pour les actions à faible enjeu, réviser le milieu, bloquer ou reconcevoir le bas. Ce que la calibration interdit, c’est le motif naïf : « le modèle dit 95 % confiant, donc on lui fait confiance » — un chiffre non mesuré qui verrouille une action irréversible est la mauvaise réponse de l’examen, en costume.

06Traçabilité des sources et incertitude en synthèse

Le dernier sous-domaine concerne la sortie auditable : quand une réponse synthétise plusieurs sources — documents, résultats d’outils, rapports d’ouvriers — la conception doit transporter d’où vient chaque morceau et à quel point il est sûr. La traçabilité, c’est le suivi des sources au niveau de l’affirmation : les conclusions citent leurs sources (le document et le passage, le résultat d’outil, l’identifiant de l’ouvrier), de façon structurée plutôt que rhétorique — un tableau de conclusions avec un champ source, pas un paragraphe de clôture qui mentionne des fichiers. Le mécanisme se compose avec tout ce qui est en amont : les schémas peuvent exiger des champs de source (domaine 4), les ouvriers peuvent être tenus de renvoyer des preuves avec chaque affirmation (contrats d’interface du domaine 1), et les citations peuvent être verbatim ou liées plutôt que paraphrasées, parce que la paraphrase est là où la traçabilité meurt en silence.

L’incertitude est la sœur honnête de la traçabilité. Les sources se contredisent, les preuves sont minces, la recherche ne renvoie rien — et la synthèse doit le dire, dans la structure de la sortie, pas dans ses adjectifs : un champ de confiance, une liste des conflits ouverts, « non trouvé » comme conclusion à part entière plutôt qu’une devine habillée en fait. L’échec nommé de l’examen est le blanchiment d’incertitude : l’ouvrier A hésite, le coordinateur résume la prudence de A en phrase déclarative, et le rapport final affirme ce qui n’a jamais été établi — chaque saut de synthèse déshabille les précautions jusqu’à ce qu’un peut-être arrive en fait. Les remèdes de conception sont structurels : la confiance voyage avec l’affirmation à travers chaque interface ; les règles de synthèse disent quand présenter le désaccord comme un désaccord ; et le rapport réserve l’assertion à ce que les preuves soutiennent, le reste étant marqué. Cette dernière habitude n’est pas de la modestie — c’est la différence entre une réponse défendable ligne par ligne et une réponse qu’on ne peut qu’espérer.

07Les pièges de ce domaine

• —« La session est énorme — augmente la fenêtre de contexte. » La fenêtre est une donnée ; les leviers ont des noms. Compacter, élaguer, isoler ou persister — « une plus grande fenêtre » n’est jamais la réponse de l’examen.
• —« Utilise le memory tool pour sauver la longue session. » Le memory tool est de la durabilité entre sessions, pas du soulagement à l’intérieur d’une. Une session qui doit continuer elle-même veut compaction ou context editing.
• —« Cache pour rendre la longue session moins chère. » Le caching rend un préfixe stable bon marché à relire ; il ne rétrécit rien. L’enflure est un problème de gestion, pas de tarification.
• —« Le coordinateur a vu tous les ouvriers réussir — le rapport est juste. » Le succès de l’appel n’est pas l’exactitude du résultat ; marquez la confiance aux frontières et auditez par échantillon le flux confiant.
• —« Le modèle dit 99 % confiant. » Une confiance non mesurée est un chiffre, pas une mesure. Calibrez sur un jeu étiqueté avant qu’un seul de ces chiffres ne verrouille une action irréversible.
• —« Lis le dépôt d’abord, pour qu’il ait tout le contexte. » La lecture en vrac perd contre la recherche agentique en coût, focalisation et fraîcheur — et les impasses deviennent du bagage qui étouffe le vrai travail.
• —« La synthèse avait l’air confiante, donc on l’a livrée. » L’air n’est pas de la traçabilité. Les conclusions citent leurs sources ; les conflits sont listés ; les peut-être arrivent en peut-être — sinon le rapport est un espoir avec de la mise en forme.