Un agent qui a accès à vos données peut trouver des choses. Un agent qui a du contexte sait ce que ces choses signifient dans votre opération : à quoi sert la tâche, où en est le workflow, quelles définitions s'appliquent, quelle source est autoritaire et à jour, ce qu'il est autorisé à voir et à faire, quelles actions nécessitent une approbation, et comment l'organisation a décidé la dernière fois. La recherche fournit la matière ; le contexte est la couche conçue d'état, de provenance, de permissions et de règles de décision qui l'entoure. Sans cette couche, plus d'accès produit plus d'erreurs assurées.
Prenons une équipe d'appels d'offres à titre d'illustration. Leur nouvel agent est connecté au lecteur partagé, au CRM, à la bibliothèque de politiques et à trois ans de propositions passées. Invité à rédiger une réponse, il produit en quelques minutes un document fluide et bien référencé. Il cite un engagement de livraison tiré d'une offre de 2023 que l'entreprise ne propose plus, invoque une politique de sécurité remplacée au printemps, et promet une remise que seul un directeur peut approuver. Rien n'a échoué techniquement. Chaque recherche a réussi.
L'agent avait l'accès. Il n'avait pas le contexte. C'est l'écart qui décide si l'on peut confier à un agent d'entreprise une étape d'un vrai workflow, et il ne se comble pas en connectant davantage de sources. Il se comble en concevant ce que l'agent sait de l'opération avant d'agir.
Qu'est-ce que le contexte d'entreprise ?
Le contexte d'entreprise est la compréhension opérationnelle dont un agent a besoin pour agir correctement au sein d'une organisation donnée : la finalité de la tâche, l'état actuel du workflow et ses dépendances, les définitions métier en usage, quelles sources sont autoritaires et à jour, ce que l'agent est autorisé à voir et à faire, quelles décisions requièrent une approbation, et comment des situations comparables ont été tranchées auparavant. Il se distingue de la matière brute des documents et des systèmes ; c'est ce qui rend cette matière utilisable pour une action lourde de conséquences.
Anthropic décrit l'ingénierie du contexte comme la relève de l'ingénierie des prompts : la question n'est plus comment formuler une instruction mais « quelle configuration de contexte est la plus susceptible de produire le comportement souhaité de notre modèle ». Dans une entreprise, cette configuration n'est pour l'essentiel pas du texte que l'agent lit. Ce sont l'état, les permissions et les règles que le système environnant fait respecter.
Accès, recherche, mémoire et contexte sont des choses différentes
L'accès aux données est une connexion. La recherche trouve des passages pertinents pour une demande. La mémoire transporte l'information d'une étape et d'une session à l'autre. Le contexte est la couche conçue qui dit à l'agent ce qu'un passage signifie, s'il est à jour, qui peut l'utiliser et ce qu'on peut en faire. Chaque couche est nécessaire ; aucune des trois premières ne remplace la quatrième.
| Couche | Ce qu'elle donne à l'agent | Ce qu'elle ne peut pas lui dire seule |
|---|---|---|
| Accès aux données | Une connexion à un lecteur, une base de données, une API ou une application | Lesquels des milliers d'éléments accessibles comptent pour cette tâche |
| Recherche (RAG) | Des passages classés par pertinence pour la demande | Si un passage est à jour, remplacé, dans le périmètre ou autorisé pour ce demandeur |
| Mémoire | Faits et historique transportés d'une étape et d'une session à l'autre | Lesquels des faits mémorisés sont encore vrais, et lesquels étaient des décisions plutôt que des faits |
| Contexte opérationnel | État du workflow, définitions, provenance, permissions, règles d'approbation, précédents | Rien qu'il n'ait été conçu pour contenir : il ne vaut que ce que valent les sources et les règles derrière lui |
La génération augmentée par la recherche, introduite par Lewis et al. (2020), reste la bonne façon d'apporter à un modèle de vastes corpus changeants au moment de l'usage. L'erreur de conception consiste à traiter le passage retrouvé comme la réponse plutôt que comme une preuve qui doit encore passer un contrôle : est-ce la version actuelle, le demandeur y a-t-il droit, et agir dessus exige-t-il une décision humaine.
Sept choses qu'un agent doit savoir avant d'agir
- Finalité et critères de succès. À quoi sert l'étape et à quoi ressemble un résultat acceptable, pour que l'agent distingue un résultat complet d'un résultat plausible.
- État du workflow et dépendances. Où en est le dossier, ce qui a déjà été décidé en amont, ce qui attend en aval, et ce qui ne doit plus être modifié une fois qu'une étape ultérieure l'a consommé.
- Définitions métier. Ce que « client actif », « fournisseur approuvé » ou « date de livraison » signifie ici, pas en général. La plupart des termes d'entreprise ont une définition locale et un propriétaire.
- Provenance, version et fraîcheur. D'où vient chaque entrée, quelle version c'est, quand elle a été confirmée pour la dernière fois, et quelle source l'emporte quand deux divergent.
- Rôles, permissions et limites. Ce que l'agent peut lire et écrire, pour le compte de qui, et quels systèmes sont hors périmètre pour cette tâche même s'ils sont techniquement accessibles.
- Politiques et exigences d'approbation. Quelles actions reviennent à l'agent, lesquelles requièrent un approbateur nommé, et lesquelles ne sont jamais automatisées.
- Décisions, exceptions et résultats. Comment l'organisation a traité des cas comparables, quelles exceptions ont été accordées et pourquoi, et ce qui s'est passé ensuite.
Et une règle pour quand la liste n'est pas satisfaite : si une information manque, est périmée ou contradictoire, l'agent doit s'arrêter et escalader avec ce qu'il a trouvé, pas combler le vide. Un agent fiable est un agent dont les refus sont aussi bien conçus que les réponses.
Pourquoi stocker plus d'information n'est pas automatiquement mieux
Parce que l'attention est un budget fini, pas un entrepôt. Anthropic note qu'un transformer forme n² relations par paires sur n tokens, si bien que chaque token supplémentaire dilue la capacité du modèle à suivre ceux qui comptent. Liu et al. ont constaté que la performance des modèles suit une courbe en U selon la position : la plus forte pour l'information au début ou à la fin d'une entrée longue, la plus faible au milieu, même pour les modèles conçus pour les longs contextes. Le contexte en vrac élargit aussi la surface d'attaque et de fuite. Un contexte curé, soumis à permissions et étiqueté vaut mieux que davantage de contexte.
Les conséquences en matière de sécurité sont documentées. Le Top 10 OWASP pour les applications LLM (2025) répertorie l'agentivité excessive comme un agent doté de plus de fonctionnalités, de permissions ou d'autonomie que sa tâche ne l'exige, de sorte qu'une sortie manipulée ou simplement erronée devient une action dommageable ; et les faiblesses des vecteurs et embeddings couvrant les dépôts de recherche empoisonnés et les fuites inter-locataires dans les pipelines RAG. L'injection de prompt indirecte, où des instructions cachées dans un document retrouvé redirigent l'agent, est précisément un problème de contexte : l'agent n'a pas su distinguer une preuve d'une instruction.
La conséquence pratique pour un DSI ou un responsable des opérations : la question à poser à un fournisseur ou à une équipe n'est pas « combien l'agent peut-il voir ? » mais « comment l'agent sait-il ce qui, parmi ce qu'il voit, est à jour, autorisé et autoritaire pour cette étape ? »
Exemple : un agent de réponse aux appels d'offres qui doit distinguer cinq choses
Scénario illustratif. Il reflète la structure d'un workflow de propositions, pas les données ou résultats d'un client particulier. Le cas Intelligence des propositions par l'IA de World AI X décrit une version déployée de ce workflow.
Un appel d'offres arrive. Le travail de l'agent est de bâtir la matrice de conformité et de rédiger une réponse à partir de matériel approuvé. Pour le faire de façon fiable, il doit distinguer cinq types d'entrées qui se ressemblent sur un lecteur partagé :
| Entrée | Comment l'agent doit la traiter |
|---|---|
| Exigences actuelles de l'appel d'offres | Le périmètre autoritaire de cette réponse. Chaque exigence devient une ligne de la matrice ; rien d'autre ne définit ce que « conforme » signifie. |
| Capacités approuvées de l'entreprise | Les seules affirmations que le brouillon peut poser comme des faits, tirées d'une bibliothèque gouvernée avec un propriétaire et une date de revue. |
| Une proposition plus ancienne | Preuve de la façon dont l'entreprise a répondu auparavant, utile pour la structure et le ton, jamais une source d'affirmations actuelles sans ré-approbation. |
| Une politique remplacée | Doit être reconnue comme retirée par sa version et sa date d'effet, et exclue même si c'est le passage sémantiquement le plus proche. |
| Un engagement commercial | Prix, dates de livraison et responsabilités sont rédigés comme des espaces réservés et routés vers l'approbateur nommé ; l'agent ne les affirme jamais. |
Remarquez qu'aucune de ces distinctions n'est faite par la qualité de la recherche. Un meilleur modèle d'embedding trouvera la politique remplacée plus vite. Les distinctions viennent des métadonnées que le système maintient (statut, version, propriétaire, date d'effet), des permissions qui délimitent ce que l'agent peut affirmer, et d'une règle d'approbation qui transforme certaines sorties en demandes plutôt qu'en affirmations.
La liste de contrôle du contexte : avant qu'un agent entreprenne une action lourde de conséquences
Quatre questions, posées pour chaque entrée sur laquelle l'agent s'appuiera et pour chaque action qu'il pourrait entreprendre. Si une réponse est « non » ou « inconnu », l'étape n'est pas prête pour l'autonomie.
✓La finalité de la tâche et les critères de succès sont énoncés, pas déduits
✓L'état actuel du workflow et les décisions en amont sont lisibles par l'agent
✓Des définitions métier locales existent pour les termes dont dépend l'étape
✓Chaque source porte une version, un propriétaire et une date d'effet ou de revue
✓Le matériel remplacé et les brouillons sont marqués et exclus par défaut
✓Une règle de précédence dit quelle source l'emporte quand deux divergent
✓L'agent agit sous une identité nommée avec un accès au moindre privilège
✓Les systèmes en lecture, en écriture et hors périmètre sont définis par étape, pas par agent
✓Les actions lourdes de conséquences ont un approbateur nommé ; certaines ne sont jamais automatisées
✓Chaque sortie peut être tracée jusqu'aux sources et versions utilisées
✓Décisions, exceptions et approbations sont journalisées avec un motif
✓Une information manquante ou contradictoire déclenche une escalade, elle aussi journalisée
Comment savoir si l'agent a utilisé le bon contexte ?
Testez le contexte, pas seulement la réponse. Construisez des cas d'évaluation qui incluent du matériel périmé, remplacé et hors périmètre à côté des bonnes sources, et notez si l'agent a choisi, cité et respecté les bonnes. Mesurez le comportement d'escalade quand l'information manque ou se contredit. Et examinez les résultats métier acceptés, pas les appels d'outils réussis ; un agent qui a achevé chaque étape et produit un brouillon inutilisable n'a pas réussi.
- Couverture de provenance. Part des affirmations lourdes de conséquences d'une sortie qui remontent à une source approuvée et à jour.
- Tests de distracteurs. Tâches représentatives semées de politiques retirées et de vieilles propositions ; la condition de réussite est qu'elles soient reconnues, pas simplement évitées par chance.
- Taux et qualité d'escalade. À quelle fréquence l'agent s'arrête quand il le devrait, et si ce qu'il transmet suffit à une personne pour décider rapidement.
- Conformité aux permissions. Zéro lecture ou écriture hors du périmètre défini de l'étape, vérifié dans les journaux plutôt que supposé d'après la configuration.
Ces mesures ont leur place dans le business case avant la construction, pas dans un post-mortem après. Elles font la différence entre un agent que l'on peut auditer et un agent que l'on peut seulement observer.
Où cela se situe dans World AI OS
Dans World AI OS, cette couche est Brain, la couche de contexte opérationnel. Elle fait trois choses qui correspondent directement à la liste de contrôle ci-dessus. L'intégration du contexte connecte l'information structurée et non structurée à travers documents, bases de données, applications, API et systèmes opérationnels, en laissant l'information dans ses systèmes existants tout en donnant à l'OS le contexte dont il a besoin pour travailler à travers eux. Le graphe opérationnel structure cet environnement autour de relations plutôt que d'enregistrements isolés : workflows et tâches, personnes et décisions, systèmes et données, actifs et événements, actions et résultats. La mémoire opérationnelle préserve les preuves, hypothèses, décisions, changements et résultats créés à mesure que le travail traverse Studio, Factory et la production, de sorte que chaque nouvelle transformation démarre avec plus de contexte que la précédente.
L'intérêt d'une couche de contexte partagée est que Studio, qui refond le workflow, et Factory, qui le construit et l'exploite, travaillent à partir du même modèle évolutif de l'opération au lieu que chacun reconstruise le sien. La part de l'opération modélisée, et la vitesse à laquelle elle l'est, est cadrée à chaque mission ; l'architecture est conçue pour que le contexte s'accumule au lieu d'être reconstruit à chaque projet.
Questions fréquentes
Qu'est-ce que le contexte d'entreprise pour un agent IA ?
La compréhension opérationnelle dont un agent a besoin pour agir correctement au sein d'une organisation donnée : la finalité de la tâche, l'état actuel du workflow, les définitions métier en usage, quelles sources sont autoritaires et à jour, ce que l'agent est autorisé à voir et à faire, quelles décisions requièrent une approbation, et comment des situations similaires ont été traitées auparavant. L'accès aux documents et aux systèmes fournit la matière brute ; le contexte dit à l'agent ce que cette matière signifie et ce qu'il peut en faire.
La génération augmentée par la recherche (RAG) suffit-elle à donner du contexte à un agent ?
Non, mais c'est une partie nécessaire de la réponse. La recherche trouve des passages pertinents au moment de la demande. Elle ne sait pas, à elle seule, si un passage est à jour ou remplacé, si le demandeur a le droit de le voir, si agir dessus exige une approbation, ni ce qui s'est passé la dernière fois que l'organisation a affronté la même situation. Cela doit être conçu autour de la couche de recherche.
Pourquoi donner plus d'information à un agent n'est-il pas automatiquement mieux ?
Les modèles de langage ont un budget d'attention fini : plus il y a de tokens dans le contexte, plus l'attention se dilue, et la recherche montre que le rappel se dégrade pour l'information enfouie au milieu des entrées longues. Un contexte non filtré élargit aussi la surface d'injection de prompt indirecte et de récupération de données que le demandeur ne devrait pas voir. Un contexte curé, soumis à permissions et bien étiqueté surpasse le contexte en vrac.
Comment évaluer si un agent a utilisé le bon contexte ?
Tracez chaque sortie lourde de conséquences jusqu'aux sources, versions et permissions sur lesquelles elle s'est appuyée ; exécutez des tâches représentatives incluant du matériel périmé, remplacé et hors périmètre pour voir si l'agent les reconnaît ; mesurez à quelle fréquence il escalade quand l'information manque ou se contredit plutôt que de deviner ; et examinez les résultats acceptés, pas seulement les appels d'outils réussis.