# Un assistant utile commence par comprendre la situation. L’identité, l’écran, l’état du dossier et les droits changent la bonne réponse. Voici comment réunir le contexte utile avant de répondre. Version 1.0 · 2026-07-29 · 8 min ## Réponse courte La documentation décrit les règles stables. La bonne réponse dépend aussi de la personne, de l’écran ouvert, du dossier actif, de son état actuel et de ce que cette personne a le droit de faire. Ces faits doivent être établis avant de produire une réponse. Les informations protégées sont filtrées en amont, les sources sont choisies selon la question et seuls les outils autorisés dans ce parcours restent disponibles. Le contexte n’est pas un prompt plus long. C’est une vue maîtrisée de la situation. ## À retenir - Considérer les informations du navigateur comme des indices tant que le serveur ne les a pas validées. - Séparer les règles stables de l’état actuel du produit. - Construire le plus petit contexte utile au lieu d’envoyer tout ce qui existe. ## La même question peut appeler trois réponses différentes « Est-ce que je peux valider ? » n’est pas une simple question de documentation. Un client peut seulement consulter l’état. Un opérateur peut corriger les informations manquantes. Un administrateur peut examiner la demande. La phrase ne change pas, mais l’identité et l’état du dossier changent les preuves et la suite. Si ces distinctions sont confiées au prompt, on demande au modèle de reconstituer les droits d’accès à partir de texte. La base est fragile. Le logiciel hôte doit d’abord fixer les limites, puis fournir au modèle une vue qui les respecte déjà. ## Assembler le contexte dans un ordre fixe L’ordre compte : une étape probabiliste ne doit jamais rouvrir une limite fermée plus tôt. ### 1. Identifier Retrouver l’utilisateur connecté, son organisation, son site et son rôle effectif depuis l’application. ### 2. Valider l’écran Vérifier côté serveur la page, le module et le dossier sélectionné. Un identifiant transmis par le navigateur ne donne aucun droit à lui seul. ### 3. Chercher dans les connaissances Interroger uniquement la documentation et les connaissances auxquelles cette personne a accès, avec les filtres appliqués avant le classement. ### 4. Lire l’état actuel Utiliser des outils de lecture limités pour les faits qui peuvent changer : statut, historique, options encore disponibles. ### 5. Réduire les outils possibles Ne proposer que les opérations compatibles avec le module, le rôle et l’étape en cours. Une action interdite ne doit pas entrer dans la sélection. ### 6. Présenter les preuves et les limites Distinguer une absence de résultat, une information manquante, un accès refusé et une panne d’outil. La suite n’est pas la même. ## Exemples ### Procédure de maintenance La procédure reste stable. L’état de la machine, le site, l’habilitation de l’opérateur et l’ordre de travail évoluent. Une réponse fiable a besoin des deux. ### Exception comptable La règle explique le principe. L’écriture, la période, les pièces jointes et le rôle indiquent si cette personne peut traiter le blocage. ### Question dans un logiciel Le guide explique la fonction. L’abonnement, la configuration et l’écran ouvert déterminent les consignes qui s’appliquent maintenant. ## Pièges fréquents - Faire confiance au rôle, au site ou au dossier indiqués par le navigateur. - Envoyer toute la base documentaire au modèle et appeler cela du contexte. - Utiliser un document ancien pour une information qui doit être lue en direct. - Confondre absence de résultat et absence de droit. - Laisser un classement sémantique contourner une règle de sécurité déterministe. ## Checklist 1. L’identité est fournie par le produit hôte. 2. La page et le dossier sont validés côté serveur. 3. Les filtres documentaires s’appliquent avant la génération. 4. Les outils de lecture respectent les mêmes limites que l’interface. 5. La liste des outils est réduite selon le module ou le parcours. 6. Les preuves précisent leur nature et leur fraîcheur lorsque cela compte. 7. Les cas vide, refusé, partiel et en échec sont testés séparément. ## Limites - Ajouter du contexte peut dégrader la réponse si les détails inutiles noient les preuves pertinentes. - La recherche ne peut pas compenser des sources absentes ou contradictoires. - L’état peut changer entre la réponse et l’action. Toute écriture exige donc une nouvelle vérification côté serveur. ## Sources 1. [Guidelines for Human-AI Interaction](https://www.microsoft.com/en-us/research/wp-content/uploads/2019/01/Guidelines-for-Human-AI-Interaction-camera-ready.pdf) — Amershi et al., Microsoft Research, 2019; nature: research. 2. [Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks](https://arxiv.org/abs/2005.11401) — Lewis et al., 2020; nature: research. 3. [ReAct: Synergizing Reasoning and Acting in Language Models](https://openreview.net/forum?id=WE_vluYUL-X) — Yao et al., 2023; nature: research. 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 ### Quelle quantité de contexte faut-il envoyer au modèle ? Uniquement ce qui sert à la question et au parcours en cours. Testez la qualité quand le contexte varie plutôt que de supposer qu’un volume plus grand est plus sûr. ### Le modèle peut-il décider des droits qui s’appliquent ? Non. Il peut expliquer le résultat d’une règle, mais l’application doit calculer et faire respecter les accès de manière déterministe. ### Que faire si l’écran actuel ne suffit pas ? Il reste un signal parmi d’autres. Le système peut poser une question ciblée ou appeler un outil de lecture autorisé, sans inventer l’information manquante. --- Canonical: https://scoperail.fokalabs.io/fr/guides/assistant-ia-comprendre-situation Author: Ramzi Laieb, FokaLabs