Aller à la méthode
SCOPERAIL
FR / EN

MÉTHODE PUBLIQUE / VERSION 01

Produit ↗

Avancer vite. Garder les limites explicites.

Le terrain d’abord. L’automatisation ensuite.

ScopeRail part d’un travail qui existe déjà : répondre à un client, retrouver la bonne procédure, préparer une intervention ou transformer une demande en prochaine étape claire. Connaissances, données métier et outils travaillent ensuite ensemble dans les droits déjà en place.

C’est une méthode de travail portable. Ce n’est pas une publication de code client, de configuration privée ni de l’implémentation Sextan.

Suivre le parcours de contrôleUtiliser les artefacts publics ↘

01 / LE PARCOURS DE CONTRÔLE

Le modèle est un composant. Le cadre forme le système.

Chaque étape a une responsabilité précise. Les contrôles déterministes fixent ce qui est possible. Les modèles aident à sélectionner, comprendre et proposer dans ce périmètre.

  1. 01

    Politique ferme

    Établir l’identité, le périmètre, les opérations interdites et les règles de confirmation hors du modèle. Un prompt ne donne jamais un droit.

    Le produit hôte reste l’autorité

  2. 02

    Catalogue éligible

    Composer la liste des outils après les contrôles de droits. Le modèle ne voit que ce que cette personne peut utiliser pour ce parcours.

    Conserver, réduire ou refuser

  3. 03

    Sélection

    Chercher le contexte utile et classer les outils candidats selon la tâche. Le classement améliore la pertinence. Il n’élargit jamais les droits.

    La pertinence ne remplace pas la règle

  4. 04

    Provenance

    Associer la source, sa version, sa fraîcheur et son état d’accès à la réponse. Manquant, indisponible et refusé restent trois résultats distincts.

    La preuve accompagne l’affirmation

  5. 05

    Proposer ou exécuter

    Répondre directement lorsque les éléments suffisent. Pour une écriture, préparer une proposition modifiable puis refaire contrôler les droits par le produit.

    Toute action importante passe un point de contrôle

  6. 06

    Tracer et reprendre

    Conserver le résultat, les références utiles et l’issue de l’outil. Si le contexte manque ou si l’exécution échoue, prévoir une reprise humaine claire.

    L’échec reste visible et récupérable

02 / LA PRATIQUE AVANT L’ÉCHELLE

La vitesse vient d’un périmètre net.

Une équipe rapide ne branche pas toutes ses sources et tous ses outils d’un coup. Elle choisit un point de friction récurrent, le traite de bout en bout, observe les exceptions puis n’étend que ce qui fonctionne.

  1. 01

    Cadrer

    Nommer l’utilisateur, la décision, les éléments utiles et la limite que le système ne doit pas franchir.

  2. 02

    Instrumenter

    Réunir des questions représentatives, des cas de droits, des erreurs d’outil et les résultats réellement attendus.

  3. 03

    Livrer un parcours étroit

    Mettre un flux complet en usage derrière les contrôles existants du produit. Une démonstration large n’est pas l’objectif.

  4. 04

    Opérer

    Examiner les réponses faibles, les sources manquantes, les actions refusées et les reprises humaines. Corriger avant d’ajouter un nouveau parcours.

L’exécution compte. Le contrôle lui permet de rester utile après la première démonstration.

03 / UNE INTELLIGENCE À LA BONNE TAILLE

N’utiliser que l’intelligence nécessaire au parcours.

Une exploitation responsable commence avant le choix du modèle. On retire d’abord les appels, le contexte et les outils inutiles. On compare ensuite les plus petites options capables de réussir les mêmes évaluations.

  1. 01

    Déterministe d’abord

    Utiliser une règle, une lecture directe ou une validation typée lorsque la réponse est déjà explicite. Inutile d’appeler un modèle pour redécouvrir une contrainte connue.

  2. 02

    Chercher avec mesure

    Charger les sources nécessaires à la question en cours. Plus de contexte ne signifie pas automatiquement un meilleur contexte.

  3. 03

    Passer la matrice

    Choisir le plus petit modèle qui réussit les évaluations de qualité, de droits, d’outils et de reprise. La taille n’est pas le critère d’acceptation.

  4. 04

    Renforcer avec raison

    Faire appel à un modèle plus puissant ou à une personne seulement lorsque le cas d’échec observé le justifie. Garder le chemin courant simple.

  5. 05

    Mesurer le travail réel

    Suivre les résultats utiles, les parcours en échec, la latence et les ressources consommées. Optimiser à partir de l’usage, pas d’une mise en scène de benchmark.

04 / LE SEUIL D’ÉVALUATION

Les exceptions disent si le parcours est prêt.

Il n’existe pas un score universel pour un assistant sous contrôle. Chaque intégration définit ses cas représentatifs et les preuves attendues pour les décisions qu’elle doit aider.

01 / Périmètre

Les informations restreintes restent-elles dehors ?

Jeux de droits, cas entre périmètres et rejet des écritures non autorisées par le produit hôte.

02 / Preuves

La réponse remonte-t-elle à des sources actuelles et permises ?

Questions représentatives, jeux de recherche réservés, reformulations et cas de source manquante.

03 / Choix des outils

Le bon outil éligible est-il sélectionné et appelé correctement ?

Cas de routage, arguments invalides, catalogues étendus et tests de chaînes d’outils exécutables.

04 / Intégrité de l’action

Proposé, confirmé et terminé restent-ils bien distincts ?

Confirmation, idempotence, annulation, nouveau contrôle des droits et échecs partiels.

05 / Reprise

L’échec rend-il la main à une personne ?

Résultat vide, accès refusé, délai dépassé, format invalide et injection de pannes.

06 / Juste niveau

Est-ce le système le plus simple qui réussit ?

Comparer sans modèle, avec un petit modèle et avec un modèle plus large sur les mêmes cas et contraintes.

Les seuils, les responsables et les règles de mise en production appartiennent à l’intégration. La matrice publique n’en invente aucun.

05 / ARTEFACTS PUBLICS

Des formats portables pour les points difficiles.

Ces schémas et listes de contrôle rendent les décisions révisables entre produit, technique, sécurité et opérations. Adaptez-les puis versionnez-les avec le système hôte.

01Définition d’outilJSON SCHEMADécrire l’objectif, l’éligibilité, les entrées, les sorties, les effets et la confirmation avant d’ajouter un outil au catalogue.Ouvrir ↗02Action en attenteJSON SCHEMASéparer une écriture proposée de sa confirmation, de son exécution et de son résultat.Ouvrir ↗03Enveloppe de preuvesJSON SCHEMATransporter l’identité de la source, sa fraîcheur, son état d’accès et ses limites avec une réponse.Ouvrir ↗04Proposition de ticketJSON SCHEMATransformer un signal flou en brouillon révisable sans l’envoyer à la place de la personne.Ouvrir ↗05Checklist d’intégrationMARKDOWNCadrer identité, sources, outils, actions, évaluations et exploitation pour un premier parcours.Ouvrir ↗06Matrice d’évaluationMARKDOWNDéfinir les cas, les preuves, les responsables et la décision de sortie avant de choisir un modèle.Ouvrir ↗07Journalisation et masquageMARKDOWNObserver le parcours sans transformer prompts, résultats d’outils ou données personnelles en télémétrie.Ouvrir ↗08Modèle de menacesMARKDOWNExaminer les frontières de confiance, l’injection, le confused deputy, l’autonomie excessive et les chemins de reprise.Ouvrir ↗

Des points de départ, pas des certifications. À revoir selon votre produit, vos contrats et votre modèle de risque.

06 / CARTE DES RÉFÉRENCES

Normes, recherche et pratique de terrain ne jouent pas le même rôle.

La méthode utilise chaque source pour ce qu’elle peut soutenir. Les normes cadrent les risques et les interfaces. La recherche teste des hypothèses précises. La pratique apporte des modes opératoires utiles.

Normes et documentation officielle

Des cadres normatifs et des spécifications maintenues. Ils orientent les contrôles sans certifier une implémentation.

  1. Artificial Intelligence Risk Management Framework 1.0NIST · 2023Ouvrir la source: Artificial Intelligence Risk Management Framework 1.0
  2. Model Context Protocol specificationMCP maintainers · 2025-11-25Ouvrir la source: Model Context Protocol specification
  3. MCP Security Best PracticesMCP maintainers · 2026Ouvrir la source: MCP Security Best Practices
  4. Syntax for GitHub Issue FormsGitHub Docs · 2026Ouvrir la source: Syntax for GitHub Issue Forms
  5. Adversarial Machine Learning: A Taxonomy and TerminologyNIST · 2025Ouvrir la source: Adversarial Machine Learning: A Taxonomy and Terminology
  6. OWASP Top 10 for LLM Applications 2025OWASP · 2025Ouvrir la source: OWASP Top 10 for LLM Applications 2025
  7. Energy and AIInternational Energy Agency · 2025Ouvrir la source: Energy and AI

Recherche

Des travaux scientifiques ou de recherche. Leurs résultats restent liés aux données, tâches et conditions expérimentales étudiées.

  1. Guidelines for Human-AI InteractionAmershi et al., Microsoft Research · 2019Ouvrir la source: Guidelines for Human-AI Interaction
  2. Retrieval-Augmented Generation for Knowledge-Intensive NLP TasksLewis et al. · 2020Ouvrir la source: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
  3. ReAct: Synergizing Reasoning and Acting in Language ModelsYao et al. · 2023Ouvrir la source: ReAct: Synergizing Reasoning and Acting in Language Models
  4. τ-bench: Tool-Agent-User Interaction in Real-World DomainsYao et al. · 2025Ouvrir la source: τ-bench: Tool-Agent-User Interaction in Real-World Domains
  5. AgentDojo: A Dynamic Environment to Evaluate Prompt Injection AttacksDebenedetti et al. · 2025Ouvrir la source: AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks
  6. What Makes a Good Bug Report?Bettenburg et al. · 2008Ouvrir la source: What Makes a Good Bug Report?
  7. Information needs in bug reports for web applicationsJournal of Systems and Software · 2025Ouvrir la source: Information needs in bug reports for web applications
  8. The Probabilistic Relevance Framework: BM25 and BeyondRobertson and Zaragoza · 2009Ouvrir la source: The Probabilistic Relevance Framework: BM25 and Beyond
  9. ColBERTv2: Effective and Efficient Retrieval via Lightweight Late InteractionSanthanam et al. · 2022Ouvrir la source: ColBERTv2: Effective and Efficient Retrieval via Lightweight Late Interaction
  10. RAGAS: Automated Evaluation of Retrieval Augmented GenerationEs et al. · 2024Ouvrir la source: RAGAS: Automated Evaluation of Retrieval Augmented Generation
  11. Toolformer: Language Models Can Teach Themselves to Use ToolsSchick et al. · 2023Ouvrir la source: Toolformer: Language Models Can Teach Themselves to Use Tools
  12. ToolLLM: Facilitating Large Language Models to Master 16000+ APIsQin et al. · 2023Ouvrir la source: ToolLLM: Facilitating Large Language Models to Master 16000+ APIs
  13. ToolRet: Tool Retrieval for Large Language ModelsACL Findings · 2025Ouvrir la source: ToolRet: Tool Retrieval for Large Language Models
  14. ToolRerank: Adaptive and Hierarchy-Aware Reranking for Tool RetrievalLREC-COLING · 2024Ouvrir la source: ToolRerank: Adaptive and Hierarchy-Aware Reranking for Tool Retrieval

Pratique de terrain

Des références utiles pour l’ingénierie et le produit. Elles apportent une direction et de l’expérience, pas une preuve scientifique.

  1. Owning the Workflow in B2B AI AppsAndreessen Horowitz · 2025Ouvrir la source: Owning the Workflow in B2B AI Apps
  2. Software Is Changing (Again)Andrej Karpathy · 2025Ouvrir la source: Software Is Changing (Again)
  3. QMD: query Markdown with hybrid searchTobi Lütke · 2026Ouvrir la source: QMD: query Markdown with hybrid search
  4. gstackGarry Tan · 2026Ouvrir la source: gstack

SCOPE / TRANSPARENCE

La méthode est publique. Les systèmes clients ne le sont pas.

Cette publication décrit des interfaces portables, des contrôles et des choix d’exploitation. Elle n’expose ni données client, ni prompts, ni identifiants, ni seuils privés, ni configuration interne, ni code source, ni implémentation Sextan.