Ressources, prompts ou outils MCP — quand chaque surface gagne
À jour au 2026-07-24T14:00:00Z
Qu'est-ce que Ressources, prompts ou outils MCP — quand chaque surface gagne ?
L'erreur de conception MCP la plus fréquente est de tout forcer dans les outils — la bonne surface dépend de qui décide quand : le modèle choisit les outils, l'application hôte attache les ressources, l'humain déclenche les prompts.
L'erreur de conception la plus fréquente lorsqu'on construit un serveur Model Context Protocol consiste à forcer chaque capacité à devenir un outil. La spécification expose délibérément trois surfaces distinctes — outils, ressources et prompts — précisément pour que trois parties différentes, le modèle de langage, l'application hôte et l'utilisateur humain, contrôlent chacune ce qu'elle est le mieux placée pour contrôler. Réduire les trois à « il suffit d'en faire un outil » est pratique au départ, mais cela consomme des jetons, ralentit le temps de réponse et, surtout, dégrade la capacité du modèle à choisir le bon outil tout court, parce que chaque ressource ou prompt mal placé dans la liste des outils est une option de plus que le modèle doit lire et écarter à chaque appel.
À quoi sert chaque surface
Pourquoi c'est important
- La mauvaise surface brûle des tokens, ralentit les réponses et dégrade la précision de sélection, même avec des handlers corrects.
- Les ressources (config, manifestes, glossaires) sont attachées par l'hôte au démarrage de session, peu coûteuses à lire, sans appel LLM nécessaire.
- Les prompts sont des templates déterministes déclenchés par l'utilisateur (ex. « analyze market position ») — pas des fonctions décidées par le modèle.
Points clés
- Outil — action pilotée modèle (search, fetch, write) ; le LLM décide du moment et des arguments.
- Ressource — contexte piloté application (config, manifeste, glossaire) ; l'hôte attache à la session, le LLM lit passivement.
- Prompt — template piloté utilisateur (slash command) ; l'humain déclenche, le serveur renvoie une instruction multi-tour.
- Règle de décision — qui décide quand ? Modèle → outil. Application → ressource. Humain → prompt.
- Coût de mauvaise classification — tokens brûlés, latence en hausse, précision en baisse ; l'erreur n°1 en production.
Termes employés sur cette page
- Model-controlled surface
- Une surface de serveur MCP (les tools) où le LLM décide, au moment du raisonnement, s'il faut invoquer l'appel et comment, sur la base de la description et de la spécification d'entrée en JSON Schema.
- Application-controlled surface
- Une surface de serveur MCP (les resources) où l'application hôte (Claude Desktop, Cursor, Claude Code) décide quels documents adressables par URI attacher à la fenêtre de contexte du LLM.
- User-controlled surface
- Une surface de serveur MCP (les prompts) où l'utilisateur humain déclenche explicitement un modèle nommé — généralement via un menu de commandes slash — et le serveur renvoie une séquence de messages multi-tours structurée.
- Everything-as-tool anti-pattern
- L'échec de conception le plus courant des serveurs MCP : regrouper documents de configuration, notes de méthodologie et workflows modélisés dans des tools, ce qui gonfle l'espace de sélection d'outils et dégrade la précision du LLM.
- Decision owner
- La personne responsable qui assume l'arbitrage et finance l'action suivante.
- Semantic contract
- La définition partagée des termes métier, métriques, entités et règles d'accès utilisée par les outils et les équipes.
- Control plane
- La couche qui applique la politique, l'accès, la traçabilité, la supervision et l'escalade à travers le modèle opérationnel.
- Evidence grade
- Une étiquette qui distingue le fait vérifié, le signal directionnel, l'hypothèse modélisée et l'observation de terrain.
Sources
- MCP specification — Architecture overview
- Anthropic MCP examples repository
- SAP News Center — Accelerate the Autonomous Enterprise with SAP Business Data Cloud
- SAP News Center — SAP Unveils the Autonomous Enterprise
- SAP News Center — The Future of the Enterprise Is Autonomous
- SAP News Center — 2026 SAP Sapphire Keynote: Powering the Autonomous Enterprise
- SAP Help Portal — Administering SAP Datasphere: Enable Joule for SAP Datasphere
- SAP Datasphere — Help Portal
- SAP Datasphere — official product page
- SAP Analytics Cloud — Help Portal
- SAP Analytics Cloud — official product page
- SAP BW/4HANA — Help Portal
- SAP S/4HANA — Help Portal
- SAP News Center
- SAP Community
- SAP — industries overview
- SAP Business AI — official product page
- SAP Joule (work companion) — official product page
- SAP Generative AI — official product page
- Stanford HAI — AI Index Report
- Meta AI — Llama model research
- arXiv — preprint archive (cs.CL/cs.AI)
- HuggingFace — model hub
- Gartner — research & analyst site
- BARC — BI & Analytics research
- TDWI — data & analytics research
- DSAG — German-speaking SAP user group
- ASUG — Americas' SAP User Group
- Databricks — official site
Fiche complète réservée aux abonnés. Ce que la fiche complète ajoute : le cadre de décision complet · la comparaison SAP · Snowflake · Databricks · Fabric · les pièges courants et leur correctif · l'aide-mémoire · les schémas d'architecture · les blocs de code · les chiffres à citer.