La couche de contexte que personne n'a construite

La plupart des conversations sur les agents sont des conversations sur les modèles. Lequel raisonne le mieux, lequel coûte le moins, sur lequel se standardiser. C'est l'endroit naturel où regarder, parce que le modèle est la partie qui paraît neuve.

Sauf que le modèle détermine rarement si un agent est utile dans votre entreprise. Un agent ne vaut que le contexte qu'il peut atteindre, et votre contexte ne vit pas dans le modèle. Il vit à travers vos personnes, vos processus et vos systèmes : le CRM, le système central, la GED, la file de tickets, la personne qui connaît l'exception qui compte. La plupart des organisations n'ont jamais construit la couche qui permet à un agent d'atteindre ce contexte en sécurité. L'agent ne voit donc pas assez pour être utile, ou bien on le câble avec des credentials larges et permanents qu'aucun comité de sécurité n'approuverait.

Cette couche manquante est la raison discrète pour laquelle la plupart des projets s'enlisent. Ce n'est pas un problème de modèle. C'est un problème d'interopérabilité et d'identité, et c'est assez peu glamour pour que presque personne ne le budgète avant de s'y heurter.

Cette couche n'est pas de la plomberie d'intégration

Le mouvement tentant est de confier ça à une équipe d'intégration en parlant de plomberie. Résistez, parce que chaque choix de conception dans cette couche est un choix de sécurité, et la traiter comme de la plomberie, c'est ainsi que les trous de sécurité sont construits par des gens à qui on n'a jamais demandé d'y penser.

La couche de contexte a trois parties, et chacune est l'endroit où une architecture sérieuse et une architecture optimiste divergent.

Partie un : des capacités typées, pas un tas de clés d'API

Un agent doit lire et écrire dans vos systèmes de référence. La façon paresseuse d'accorder ça, c'est un paquet de clés d'API et un accès large. La bonne façon, ce sont des capacités explicites et typées.

Voyez chaque capacité comme une porte étroite et nommée : read_dossier, request_document, post_decision_for_review. L'agent reçoit les portes précises dont il a besoin pour une tâche précise, et rien d'autre. Chaque porte est journalisée.

Ce n'est pas une différence cosmétique. Cela change la phrase que votre comité de sécurité doit évaluer. « L'agent peut toucher nos systèmes » est inauditable, et personne ne devrait le signer. « L'agent peut exécuter ces sept actions nommées, chacune journalisée » est un contrôle qu'un comité peut approuver. Les capacités typées sont ce qui transforme une intégration ouverte en une surface bornée et révisable.

Partie deux : une identité non humaine, éphémère et à moindre privilège

Un agent n'est pas une personne, et il ne doit jamais emprunter les credentials d'une personne.

C'est la façon la plus courante dont les projets échouent au comité de sécurité, parce que le chemin rapide, faire tourner l'agent sous le jeton personnel d'un développeur avec un accès permanent à la production, est exactement le constat qui arrête le projet. Ce jeton est un passe-partout. Il n'est pas restreint, il n'expire pas vite, et il ne distingue pas les actions de l'agent de celles du développeur.

Dans une architecture correcte, chaque agent tourne sous sa propre identité non humaine, avec des credentials à courte durée de vie et à moindre privilège, et une allow-list de sortie explicite. La conséquence mérite d'être dite clairement : un credential d'agent volé ne vaut presque rien. Il n'y a pas de secret statique à voler, et l'identité ne peut faire que les quelques choses pour lesquelles elle a été cadrée, vers les quelques destinations qu'elle a le droit d'atteindre. L'une de ces conceptions passe l'homologation. L'autre est le constat qui met fin à la mission.

L'identité est aussi ce qui rend la piste d'audit significative. Quand chaque action porte l'identité propre de l'agent et ses capacités cadrées, « qui a fait ça ? » a une réponse précise, et l'enregistrement que vos auditeurs inspectent reconstitue réellement ce qui s'est passé.

Partie trois : la frontière de contamination, où une donnée non fiable ne peut pas devenir un privilège

C'est la partie qui sépare une architecture sérieuse d'une architecture optimiste, et elle mérite du soin, parce que c'est la façon la plus courante dont les agents se font compromettre en production.

Un agent lit du contenu qu'il n'a pas écrit : un e-mail client, un contrat scanné, un PDF d'un tiers. Ce contenu n'est pas fiable. Si un document empoisonné contient du texte qui ressemble à une instruction, et que l'agent le traite comme telle, le document vient de détourner un agent ayant accès à vos systèmes centraux. C'est l'injection de prompt indirecte, et aucun prompt, filtre ou réglage de configuration ne l'arrête de façon fiable.

La réponse structurelle est une frontière de contamination : une donnée non fiable ne devient jamais un privilège exécutable. En pratique, on l'applique en scindant les rôles de l'agent, le motif connu sous le nom de CaMeL, une conception à deux LLM. Un planificateur privilégié décide quoi faire et appelle les outils typés, mais ne lit jamais directement le contenu non fiable brut. Un lecteur en quarantaine lit bien le contenu non fiable, mais ne peut appeler aucun outil ni agir. Il renvoie une référence, pas une instruction. À la moindre ambiguïté, le système échoue en fermé.

Il y a un coût honnête. Scinder les rôles coûte à peu près quelques points d'utilité. C'est le marché : un prix modeste en précision contre une garantie structurelle qu'un document ne peut pas prendre le contrôle d'un agent câblé dans vos systèmes centraux. Dans un travail réglementé, l'arbitrage n'est pas serré.

Aucune couche seule n'est censée tenir seule. La frontière de contamination s'inscrit dans une défense en profondeur : le spotlighting pour réduire la surface d'attaque, l'isolation CaMeL, des guardrails de détection, et un point de décision de politique au-dessus de tout. Le spotlighting réduit la surface d'attaque. Il ne l'élimine pas, et c'est exactement pourquoi il n'est jamais la seule couche.

Pourquoi cette couche mérite d'être construite sur vos processus réels

Vous ne pouvez pas acheter cette couche sur étagère, parce qu'elle est façonnée par vos systèmes, vos identités et vos frontières de données. Elle doit être construite sur vos processus réels, sur le terrain, sur le travail effectif, pas sur un schéma de référence.

C'est aussi pourquoi c'est la couche qui décide discrètement de tout le reste. Le meilleur modèle du monde, routé par la passerelle la plus portable, gouverné par l'échelle d'autonomie la plus rigoureuse, ne sert à rien si l'agent ne peut pas atteindre en sécurité le contexte dont il a besoin pour agir. À l'inverse, dès que la couche de contexte existe, les agents n'atteignent que ce qui leur est permis, agissent sous leurs propres identités à moindre privilège, et ne peuvent jamais être amenés à traiter une donnée non fiable comme une instruction, avec une trace complète que vos auditeurs peuvent inspecter. Tout le reste d'une architecture agentique suppose que cette couche existe déjà.

Le recadrage n'est donc pas « quel modèle nos agents devraient-ils utiliser ? ». C'est : pour chaque système que nos agents doivent atteindre, quelle est la capacité typée, quelle identité l'agent porte-t-il, et où est la frontière entre le contenu qu'il lit et les actions qu'il peut faire ? Si vous ne pouvez pas répondre système par système, le choix du modèle n'a pas encore d'importance. La couche en dessous n'a pas été construite.

Si vous voulez cartographier la couche de contexte d'un processus à fort enjeu, prenez rendez-vous.