# 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.

Version 1.0 · 2026-07-29 · 8 min

## 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

- Les connaissances stables et l’état changeant ont des sources et des règles de fraîcheur différentes.
- Le contexte doit être structuré, minimal et construit côté serveur.
- Les filtres de sécurité s’appliquent avant l’assemblage du contexte envoyé au modèle.

## 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.

## 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.

### 1. Identité

Utilisateur, organisation, espace ou site et rôle effectif, tous issus de la session authentifiée.

### 2. Navigation

Page, module, dossier sélectionné et version du produit ou état de la fonction lorsque cela compte, après validation côté serveur.

### 3. Accè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.

### 4. Connaissances

Sources stables autorisées avec leurs identifiants, leurs versions et les scores de recherche utiles à l’évaluation.

### 5. Observations

Résultats d’outils en direct avec leur périmètre, leur date, leur état vide ou partiel et une provenance exploitable.

### 6. Outils 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.

## Exemples

### 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

1. Chaque catégorie de contexte est nommée et structurée.
2. L’identité et le périmètre viennent de l’application authentifiée.
3. Les connaissances stables et l’état en direct ont des règles de fraîcheur distinctes.
4. La recherche applique les droits avant la génération.
5. Les résultats d’outils conservent les états vide, refusé, partiel et échoué.
6. La liste des outils est réduite avant la sélection par le modèle.
7. L’enveloppe finale peut être examinée dans des traces expurgées.

## Limites

- 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

1. [Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks](https://arxiv.org/abs/2005.11401) — Lewis et al., 2020; nature: research.
2. [ReAct: Synergizing Reasoning and Acting in Language Models](https://openreview.net/forum?id=WE_vluYUL-X) — Yao et al., 2023; nature: research.
3. [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2025-11-25) — MCP maintainers, 2025-11-25; nature: standard.
4. [AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks](https://openreview.net/forum?id=m1YYAQjO3w) — Debenedetti et al., 2025; nature: research.

## 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.

---

Canonical: https://scoperail.fokalabs.io/fr/guides/documentation-contexte-produit
Author: Ramzi Laieb, FokaLabs