Glossaire

Ce glossaire explique les concepts clés de l’approche MCP-first tels qu’ils sont utilisés dans l’architecture, le modèle de sécurité et la conception des capacités.

Termes fondamentaux

• MCP, Le Model Context Protocol ; un protocole ouvert permettant aux agents IA d’appeler de manière structurée et vérifiée les capacités typées d’un système (outils, ressources, workflows).

• MCP-first, Principe d’architecture selon lequel un logiciel est d’abord décrit comme un système de capacités entièrement contrôlable et lisible par les machines ; la webapp, l’application mobile et l’interface d’administration sont ensuite créées comme clients secondaires de cette couche de capacités.

• Capability, Une capacité métier du système, décrite de manière structurée, typée, vérifiée par les droits et auditable ; le cœur réel du produit, indépendant d’une interface concrète.

• Action / Action Layer, Une capacité exécutable individuelle (ex. : create_project, send_external_email) comme première couche sous toutes les interfaces ; la webapp, l’agent, la CLI et le worker appellent la même action.

• Adapter, Une couche (ex. : serveur MCP, backend de webapp, API d’application mobile) qui reçoit les requêtes, mappe le contexte d’authentification, vérifie les politiques et transmet les appels à la couche d’action, sans contenir de logique métier.

Composants

• Tool, Une action appelable dans le système MCP avec un schéma d’entrée typé, un schéma de sortie, un niveau de risque et une politique de confirmation ; correspond à une capacité du point de vue de l’agent (exemple : contacts.create).

• Resource, Un point de données ou un contexte lisible qu’un agent peut récupérer (exemple : projects.list, contacts.get) ; fournit un contexte structuré plutôt que des requêtes de base de données brutes.

• Workflow / Prompt, Un processus prédéfini en plusieurs étapes guidant un agent à travers un processus complexe ; dans le contexte MCP, souvent modélisé comme un template de prompt qui coordonne ressources et outils.

• Policy, Règle lisible par les machines déterminant qui peut appeler quel outil dans quelles conditions, quelle confirmation est nécessaire et si l’exécution autonome est autorisée.

• Audit Event, Une entrée de journal structurée et immuable pour chaque action MCP exécutée ; contient les identités, le niveau de risque, l’ID de confirmation et l’horodatage pour assurer une traçabilité complète.

• Risk Metadata, Marquage lisible par les machines d’un outil ou d’une ressource avec le niveau de risque (low / medium / high / critical / restricted) et d’autres métadonnées comme la réversibilité et les effets secondaires externes.

• Human Confirmation Gate, Mécanisme par lequel un agent doit obtenir explicitement le consentement de l’utilisateur avant d’exécuter un outil risqué ; bloque l’exécution autonome jusqu’à la confirmation.

Identité & Accès

• Human User, Un utilisateur réel et connecté du système (ex. : admin, employé, chef de projet) ; point de départ pour les vérifications de droits et les chaînes de délégation.

• MCP Client, L’application connectée au serveur MCP qui envoie des requêtes au nom d’un utilisateur ou d’un agent (ex. : Claude Desktop, une application IA interne ou un processus worker).

• Agent Identity, L’identité concrète d’un agent ou d’un workflow automatisé (ex. : sales-assistant, payroll-agent) ; gérée séparément de l’identité utilisateur et disposant de ses propres scopes et restrictions.

• Delegated User Context, Le mécanisme par lequel un agent n’agit pas avec des droits système globaux, mais exclusivement dans le cadre des droits et du contexte d’un utilisateur spécifique ou d’un rôle de service configuré.

• Service Identity, Identité pour les processus backend à backend sans donneur d’ordre humain (ex. : import worker, tâche planifiée, sync worker) ; s’authentifie via mTLS ou des service tokens signés.

• Scope, Unité de permission granulaire décrivant précisément quelle action est autorisée sur quelle ressource (exemple : contacts:read, emails:send, billing:write) ; les outils et ressources vérifient les scopes avant l’exécution.

• Tenant, Mandataire dans un système multi-tenant ; chaque accès aux données est lié au tenant (tenant:abc), de sorte que les agents ne peuvent jamais agir de manière inter-tenant, même si leurs autres scopes le permettraient techniquement.

• Role, Ensemble de scopes attribué à un utilisateur ou à une agent identity (exemple : admin, manager, viewer) ; forme le premier niveau d’autorisation avant les vérifications de scope spécifiques au tenant et à l’outil.

Sécurité & Contrôle

• Risk Level, Classification d’un outil en low, medium, high, critical ou restricted ; détermine si l’exécution autonome est autorisée, si une confirmation est requise et si une step-up authentication est exigée.

• Classe de protection, Catégorisation de chaque ressource et outil selon la sensibilité des données : Public (lisible librement), Internal (utilisateurs connectés uniquement), Confidential (rôle explicite requis), Sensitive (transmission de contexte restreinte), Critical (aucune action autonome de l’IA), Forbidden for AI (ne peut être ni lu ni appelé par des agents IA).

• Confirmation Policy, Règle par outil déterminant quel type de consentement est nécessaire avant l’exécution : no_confirmation_required, confirmation_required, step_up_auth_required, admin_approval_required, four_eyes_required ou not_allowed_for_ai.

• Step-up Authentication, Exigence d’authentification supplémentaire pour les actions particulièrement sensibles (ex. : saisie du mot de passe, TOTP, passkey), allant au-delà de la session en cours ; déclenchée pour les outils critical ou les actions admin privilégiées.

• Consent Ledger, Registre persistant de toutes les approbations utilisateur accordées pour des actions d’agents ; enregistre qui, quand, pour quel outil, dans quelle portée et avec quelle méthode a consenti, base pour l’audit et la responsabilité.

• Human-in-the-loop, Principe selon lequel un agent doit activement obtenir la décision de l’utilisateur pour les actions sensibles ou risquées avant d’agir ; MCP-first signifie entièrement contrôlable, pas entièrement automatique.

• Redaction / Context Filtering, Nettoyage ou résumé ciblé des données avant qu’elles n’atteignent le contexte IA ; empêche les agents de voir inutilement des champs sensibles (ex. : bankAccount, privateNotes), même si l’utilisateur aurait fondamentalement accès.

• Dry Run, Mode d’exécution d’un outil dans lequel toutes les entrées sont validées et les effets secondaires prédits, sans que l’action soit réellement effectuée (exemple : emails.bulk_send(dryRun: true)) ; permet une vérification préalable avant les opérations risquées.

• Idempotence, Propriété d’un outil consistant à ne pas générer de doublon inutile lors d’appels répétés avec les mêmes paramètres ; important pour la logique de retry et les workflows agentiques dans lesquels une action peut être déclenchée accidentellement plusieurs fois.

• Tool Discovery / Visibilité des outils, Le processus par lequel un client MCP interroge les outils disponibles d’un serveur ; dans un système MCP-first, les outils sont déjà filtrés lors de la discovery selon l’utilisateur, le client, le tenant, le rôle et les scopes, pas seulement rejetés lors de l’appel.