La documentation n’est pas le contexte produit.
Concevoir le contrat qui réunit règles stables, données actuelles, écran ouvert, identité, droits et outils autorisés.
Réponse courte
La documentation décrit le fonctionnement attendu. Le contexte produit décrit ce qui arrive maintenant à cette personne. Gardez les deux couches distinctes, puis réunissez-les dans un objet structuré : identité validée, page, dossier actif, organisation ou site, droits effectifs, connaissances pertinentes, observations en direct et outils autorisés. La recherche ne commence qu’une fois les limites d’accès établies. Le modèle reçoit une vue contrôlée. Il ne décide pas de ce qu’il peut consulter.
À retenir
- 01
Les connaissances stables et l’état changeant ont des sources et des règles de fraîcheur différentes.
- 02
Le contexte doit être structuré, minimal et construit côté serveur.
- 03
Les filtres de sécurité s’appliquent avant l’assemblage du contexte envoyé au modèle.
01 / SITUATION
Un article juste peut tout de même produire une mauvaise réponse
Un article d’aide peut décrire correctement une validation alors que le dossier actuel est incomplet, que le parcours a évolué ou que l’utilisateur n’a pas le bon rôle. Une meilleure recherche documentaire ne corrige pas ce décalage puisque l’information absente ne se trouve pas dans les documents.
L’architecture doit donc traiter les documents, l’état en direct et les outils comme des sources de nature différente. Chacune a son autorité, sa fraîcheur, ses contrôles d’accès et ses propres pannes.
02 / MECHANISM
L’enveloppe de contexte
Construisez côté serveur un seul objet qui décrit ce que l’assistant peut savoir et faire pour cet échange.
- 01Identité
Utilisateur, organisation, espace ou site et rôle effectif, tous issus de la session authentifiée.
- 02Navigation
Page, module, dossier sélectionné et version du produit ou état de la fonction lorsque cela compte, après validation côté serveur.
- 03Accès
Limites de lecture et d’écriture calculées par l’application. Ce sont des règles exécutées, pas des conseils placés dans un prompt.
- 04Connaissances
Sources stables autorisées avec leurs identifiants, leurs versions et les scores de recherche utiles à l’évaluation.
- 05Observations
Résultats d’outils en direct avec leur périmètre, leur date, leur état vide ou partiel et une provenance exploitable.
- 06Outils autorisés
Une liste réduite d’opérations structurées pour ce rôle et ce parcours, avec les situations où elles ne doivent pas être appelées.
03 / Dans le travail réel
Règle et état actuel
Un document définit la règle de validation. Un outil de lecture indique si la demande actuelle la respecte.
Navigation et autorité
La page du navigateur suggère un dossier. Le serveur le retrouve à nouveau dans l’organisation connectée avant de le charger.
Connaissance et outil
Un guide explique le processus. Un outil confirme si l’étape suivante est réellement disponible.
Pièges fréquents
- Mélanger toutes les entrées dans une longue chaîne de texte sans structure.
- Utiliser le périmètre envoyé par le navigateur sans validation côté serveur.
- Permettre à un texte retrouvé de remplacer une règle d’accès déterministe.
- Mettre en cache un état en direct sans règle de fraîcheur.
- Transmettre un résultat d’outil sans statut, origine ni sens clair en cas d’erreur.
Checklist d’implémentation
- Chaque catégorie de contexte est nommée et structurée.
- L’identité et le périmètre viennent de l’application authentifiée.
- Les connaissances stables et l’état en direct ont des règles de fraîcheur distinctes.
- La recherche applique les droits avant la génération.
- Les résultats d’outils conservent les états vide, refusé, partiel et échoué.
- La liste des outils est réduite avant la sélection par le modèle.
- L’enveloppe finale peut être examinée dans des traces expurgées.
Ce que cette approche ne promet pas
- Le contrat de contexte doit s’adapter aux données et aux droits propres au logiciel hôte.
- Connaître la provenance ne garantit pas que la source elle-même soit juste.
- Certaines questions exigent encore une précision humaine parce qu’aucun système ne détient l’information manquante.
Sources et nature des références
- 01Retrieval-Augmented Generation for Knowledge-Intensive NLP TasksLewis et al. · 2020Recherche
- 02ReAct: Synergizing Reasoning and Acting in Language ModelsYao et al. · 2023Recherche
- 03Model Context Protocol specificationMCP maintainers · 2025-11-25Référentiel
- 04AgentDojo: A Dynamic Environment to Evaluate Prompt Injection AttacksDebenedetti et al. · 2025Recherche
Questions fréquentes
Faut-il montrer toute l’enveloppe de contexte à l’utilisateur ?
Non. Montrez les preuves et les limites qui l’aident à juger la réponse. Gardez les identifiants internes, les règles sensibles et les traces techniques hors de l’interface.
Un même service de contexte peut-il servir plusieurs assistants ?
Oui, si chaque interface demande une vue adaptée à son objectif et conserve ses propres limites d’identité et d’outils.
Est-ce simplement un pipeline RAG plus riche ?
Non. La recherche n’est qu’une étape. L’état du produit, les droits, les outils, les validations d’action et les traces appartiennent à un système de contrôle plus large.