Chris June, IntelliSync : Les systèmes de contexte sont les interfaces qui conservent les bons éléments—dossiers, consignes, exceptions et historique—attachés à un workflow lorsque le travail passe entre personnes, outils et agents IA. Cette définition est cruciale, car la plupart des pannes opérationnelles ne viennent pas du modèle : elles viennent du contexte.Sur le terrain, les dirigeants observent les symptômes : réponses incohérentes, retouches, escalades évitables. Les équipes techniques voient la cause : prompts fragiles, preuves de recherche manquantes, et trajectoires d’agents difficiles (ou impossibles) à auditer. La réponse architecturale consiste à traiter le contexte comme un objet opérationnel de première classe—capturé, normalisé, préservé et réutilisé par conception.
Pourquoi le contexte disparaît entre les passages de relais
Le contexte
se perd quand un workflow traverse des frontières conçues pour des humains, pas pour une décision traçable. Un relais au service client laisse derrière lui ce qui “fait référence” en situation normale. Un ticket transféré entre outils perd la logique d’exception qui avait servi à conclure. Un agent termine sa tâche et le suivant “repart à zéro”, alors que la décision métier n’a pas changé. Cette logique correspond à la façon dont l’observabilité des workflows multi-étapes est construite : le modèle de traçage des OpenAI Agents SDK capte la hiérarchie d’exécution (exécutions d’agents, appels d’outils, spans) afin d’inspecter ce qui s’est réellement passé dans une unité de travail, et de gérer proprement l’export au bon moment (dont un flush final). Sans conservation du contexte d’exécution à travers les passages de relais, on ne peut pas reconstruire les entrées de décision et les règles métier appliquées. (openai.github.io)
Conséquence : si on ne conçoit pas la préservation du contexte comme un système, on continue de payer la “taxe opérationnelle” de l’inconstance : plus de revues, un débit plus lent, et les mêmes erreurs qui reviennent.
Les systèmes de contexte améliorent la qualité via la réutilisation
ancréeUn système de contexte améliore la qualité des sorties lorsqu’il transforme la connaissance implicite en données opérationnelles attachées au workflow. Au lieu de tout empiler dans un prompt ponctuel, on attache des artefacts structurés : consignes en vigueur, exceptions applicables, le dernier résultat de décision, et les éléments de preuve qui ont étayé cette décision. On retrouve ce principe dans la manière dont les runtimes d’agents composent leurs entrées. Dans OpenAI Agents SDK, l’agent en cours reçoit un contexte et une forme d’historique lié à la session (par exemple via conversationId ou previousResponseId dans le guide d’exécution). (openai.github.io) Ensuite, le traçage rend la trajectoire obtenue vérifiable—ce qui est indispensable quand la qualité dépend de “ce que l’agent savait” à chaque étape. (openai.github.io)
Conséquence : la réutilisation ancrée réduit la variance. Elle réduit aussi la charge de revue, car on peut auditer précisément quelles consignes et quelles preuves ont mené à la réponse.
Systèmes de contexte et mémoire organisationnelle pour l’historique décisionnel
La mémoire organisationnelle n’est pas “des documents dans un dépôt”. En IA opérationnelle, la mémoire organisationnelle correspond à l’historique décisionnel—et aux règles qui ont gouverné ces décisions : ce qui a été décidé, pourquoi, quelles exceptions s’appliquaient, quelles preuves ont été utilisées, et ce qui a été appris.Le cadrage NIST de la gestion des risques en IA insiste sur des fonctions transversales (dont la gouvernance) pour rendre les activités répétables et pilotables. (nist.gov) En architecture, c’est exactement la même logique : il faut des mécanismes cohérents de documentation et de réutilisation pour gérer le risque en sachant ce qui a été appliqué, quand, et dans quelles conditions.Conséquence : si les systèmes de contexte persistent la lignée décisionnelle, vous évitez que la même défaillance se répète au moment où le workflow change d’agent, d’équipe ou d’outil.
Question d’acheteur : comment mettre en pratique une décision architecture
Comment
mettre en pratique une decision architecture sans construire un “monolithe de prompts” fragile ? Commencez par séparer les entrées de décision en quatre voies opérationnelles, avec un responsable et une politique de conservation explicites :1) Consignes : la politique en vigueur pour le workflow (qui peut approuver quoi, à quoi ressemble une bonne décision).2) Exceptions : règles de dérogation, contraintes d’éligibilité, conditions de risque.3) Dossiers : les faits utilisés pour décider (données de cas, réclamations, contexte client, état des systèmes).4) Historique : les décisions antérieures liées au même workflow ou au cycle de vie du compte.Ensuite, imposez ces voies de deux façons.
- Attacher le contexte au moment de la frontière : quand un agent appelle des outils ou transfère à un autre agent, le système de contexte doit attacher les données pertinentes à l’unité de travail suivante. Des frameworks d’agents mettent de plus en plus l’accent sur des intégrations standardisées : OpenAI documente notamment que le Model Context Protocol (MCP) standardise l’exposition des outils et du contexte aux modèles. (openai.github.io) L’idée opérationnelle reste la même : le contexte doit circuler via les interfaces, pas être “reconstruit” par inférence.
- Rendre l’exécution audit-able : implémentez un traçage pour vérifier quel contexte a été utilisé, quels appels d’outils ont eu lieu et à quel moment l’unité de travail a démarré/terminé. La documentation de traçage des Agents SDK explique comment l’export est déclenché et comment un flush est géré. (openai.github.io)
Conséquence : la decision architecture devient vérifiable et améliorable. Vous pouvez router les exceptions vers les bons propriétaires, escalader avec preuves, et mesurer où les manques de contexte persistent.
Arbitrages et modes de défaillance des systèmes de contexte
Les systèmes de contexte coûtent quelque chose. Le principal arbitrage oppose complétude et contrôle.Mode de défaillance 1 : gonflement du contexte et dérive. Si vous conservez trop—sorties brutes d’outils, trop d’historique conversationnel, exceptions obsolètes—vous risquez de dégrader la décision (et d’augmenter les coûts). OpenAI souligne aussi que les tâches longues remplissent la fenêtre de contexte, et que préserver le contexte entre tours et appels d’outils exige une stratégie (compaction). (openai.com)Mode de défaillance 2 : fuite de données sensibles. Les traces et les attachements de contexte peuvent inclure des arguments et résultats d’outils. Les modules de traçage prévoient des options pour inclure ou non les données sensibles, ce qui impose des choix explicites sur ce qui est sûr à enregistrer. (deepwiki.com)Mode de défaillance 3 : lignée incomplète. Si les spans ne couvrent pas toute l’arborescence du workflow, ou si les traces ne sont pas vidées au bon moment, vous perdez une partie des preuves. La documentation de traçage traite précisément ce comportement de cycle de vie. (openai.github.io)
Conséquence : traitez le système de contexte comme un système de contrôle. Définissez ce qui est stocké, pendant combien de temps, sous quelles règles de sécurité, et comment vous résumez ou compactez.
Voir Operating Architecture
Si votre objectif est l’amélioration de la decision_quality_improvement, ne commencez pas par “de meilleurs prompts”. Commencez par l’architecture opérationnelle du contexte : les voies de consignes, exceptions, dossiers et historique ; les interfaces qui attachent ces voies lors des passages de relais ; et le traçage qui rend les décisions auditables.View Operating Architecture pour découvrir la maquette cible des systèmes de contexte, de la mémoire organisationnelle et de la decision architecture pour l’IA opérationnelle.