Aller au contenu
SCOPERAILUN PRODUIT FOKALABS
SCOPE / FIELD GUIDERamzi Laieb · FokaLabsMis à jour 29 juillet 20268 min de lectureVersion Markdown

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.

contexteidentitédroits d’accèsRAG

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

  1. 01

    Considérer les informations du navigateur comme des indices tant que le serveur ne les a pas validées.

  2. 02

    Séparer les règles stables de l’état actuel du produit.

  3. 03

    Construire le plus petit contexte utile au lieu d’envoyer tout ce qui existe.

01 / SITUATION

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

02 / MECHANISM

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. 01Identifier

    Retrouver l’utilisateur connecté, son organisation, son site et son rôle effectif depuis l’application.

  2. 02Valider 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. 03Chercher 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. 04Lire l’état actuel

    Utiliser des outils de lecture limités pour les faits qui peuvent changer : statut, historique, options encore disponibles.

  5. 05Ré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. 06Pré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.

03 / Dans le travail réel

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 d’implémentation

  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.

Ce que cette approche ne promet pas

  • 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 et nature des références

  1. 01Guidelines for Human-AI InteractionAmershi et al., Microsoft Research · 2019Recherche
  2. 02Retrieval-Augmented Generation for Knowledge-Intensive NLP TasksLewis et al. · 2020Recherche
  3. 03ReAct: Synergizing Reasoning and Acting in Language ModelsYao et al. · 2023Recherche
  4. 04AgentDojo: A Dynamic Environment to Evaluate Prompt Injection AttacksDebenedetti et al. · 2025Recherche
Voir les artefacts de méthode

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.