--- title: "Model Context Protocol : outils, ressources et limites" description: "Comprendre clients, serveurs, outils, ressources et prompts MCP, ainsi que les contrôles de sécurité et de fiabilité encore nécessaires." canonical: "https://zephior.com/fr/glossary/model-context-protocol" last-updated: 2026-07-28 --- # Model Context Protocol : outils, ressources et limites > Comprendre clients, serveurs, outils, ressources et prompts MCP, ainsi que les contrôles de sécurité et de fiabilité encore nécessaires. Par [Tony Kim](https://zephior.com/fr/authors/tony-kim). Published 2026-07-28; updated 2026-07-28. 6 minute read. ## Définition Le Model Context Protocol, ou MCP, est un protocole ouvert qui permet à une application IA de se connecter à des serveurs exposant outils, ressources et prompts réutilisables par une interface client-serveur standardisée. ## Problème Une équipe peut confondre protocole de connexion commun, plateforme d’agents complète et frontière de sécurité. MCP standardise la découverte et l’appel, mais identité, autorisation, sûreté des outils, politique métier, vérification, observabilité et récupération restent à la charge de l’application. ## Point de vue MCP est surtout utile comme contrat d’intégration. Il réduit les connecteurs spécifiques et permet aux clients et serveurs d’évoluer séparément. La qualité de production dépend toujours des contrats étroits, droits et contrôles opératoires autour de chaque capacité. ## MCP standardise la connexion, pas toute l’application Un hôte MCP est l’application IA dans laquelle travaille l’utilisateur. Il crée des clients qui se connectent aux serveurs. Un serveur annonce des capacités telles que outils, ressources et prompts. La négociation permet aux participants de convenir d’une version et de fonctions prises en charge avant leur usage. La distinction des fonctions compte. Les ressources fournissent du contexte à lire, les outils permettent au modèle de demander une opération et les prompts fournissent des modèles réutilisables. L’hôte décide comment les présenter au modèle et à la personne. Processus métier, mémoire et autorité finale peuvent rester hors du protocole. | Composant | Mission principale | Question de contrôle | | --- | --- | --- | | Hôte | Exécute l’expérience IA et coordonne les clients | Quel utilisateur et quelle politique gouvernent? | | Client | Maintient une connexion vers un serveur | Quelles capacités sont acceptées et exposées? | | Serveur | Adapte données ou actions comme capacités | Quel système et quelle autorité se trouvent derrière? | | Ressource | Fournit un contexte à lire | Comment le contenu sensible est-il limité? | | Outil | Offre une opération que le modèle peut demander | Qui valide et approuve son effet? | ## L’entreprise a besoin de contrôles au-dessus et sous MCP Au-dessus du protocole, l’hôte a besoin de consentement, politique, approbation, évaluation et affichage clair des actions. En dessous, serveur et système cible ont besoin d’authentification, autorisation limitée, validation, transactions sûres, journalisation et réconciliation. Un message bien formé n’est pas automatiquement une instruction métier autorisée. Traitez les serveurs tiers comme des dépendances logicielles avec accès. Examinez éditeur, code ou contrôles du service, traitement des données, mises à jour et réponse aux incidents. Maintenez l’inventaire des serveurs et capacités. La portabilité de l’intégration rend l’ajout et le retrait contrôlés encore plus importants. - Lier les jetons à leur audience et ne jamais les transférer sans contrôle. - N’exposer que les capacités minimales nécessaires à la personne et au processus. - Confirmer les appels importants avant leur exécution. - Nettoyer les journaux tout en gardant audit et récupération possibles. - Réévaluer lorsque outils, schémas, serveurs ou modèles changent. ## Déroulement 1. **Définir la capacité métier.** Commencez par l’information ou l’action exacte dont l’application a besoin. Décrivez utilisateur, système de référence, périmètre permis et résultat observable. Décidez si la capacité doit être une ressource à lire, un outil à appeler ou un prompt réutilisable. 2. **Choisir les frontières client et serveur.** Identifiez quel hôte contrôle conversation et permissions, quel client maintient la connexion et quel serveur adapte le système sous-jacent. Gardez visibles frontières de confiance et responsabilité de déploiement au lieu de traiter tout serveur comme plugin interchangeable. 3. **Limiter et valider l’interface.** Employez opérations étroites, arguments typés, droits minimaux et états d’erreur explicites. Validez les entrées générées contre les règles métier. Séparez lecture et mutation puis exigez une approbation avant un effet coûteux, externe ou difficile à inverser. 4. **Tester protocole et comportement métier.** Testez découverte, compatibilité de version, autorisation, requêtes mal formées, délais et échecs partiels. Évaluez ensuite si l’agent choisit la bonne capacité, fournit les bons arguments et vérifie le résultat dans des cas réalistes et hostiles. ## Décisions clés - La capacité doit-elle être un outil, une ressource ou une étape contrôlée par l’application? - Où identité et autorisation sont-elles imposées pour chaque serveur et système en aval? - Une écriture peut-elle être idempotente et réconciliée après une réponse ambiguë? - Quelles métadonnées et descriptions de serveur sont considérées comme instructions par l’application? - Qui revoit mises à jour, versions du protocole et nouvelles capacités exposées? ## Risques - Un outil décrit trop largement donne au modèle plus d’autorité que la tâche de l’utilisateur. - Une ressource ou sortie non fiable peut contenir des instructions qui cherchent à détourner le modèle. - Le transfert de jetons ou une faible validation d’audience peut exposer des droits au mauvais serveur. - Un serveur compatible peut toujours avoir des écritures dangereuses, une faible isolation ou un audit insuffisant. - Le succès du protocole peut être confondu avec celui du métier sans réconciliation de l’effet final. ## Indicateurs - découverte et négociation de version réussies par client pris en charge - appels refusés pour arguments, permissions ou politique métier - succès de l’action après réconciliation avec le système de référence - effets doublés évités après reprise ou délai - cas de sécurité et régression réussis par version de serveur ## Questions fréquentes ### MCP est-il une API? MCP est un protocole qui permet aux applications IA et serveurs de découvrir et échanger outils, ressources, prompts et messages. Un serveur peut adapter des API, bases ou fonctions locales existantes. MCP ne remplace pas toutes les API métier sous-jacentes. ### Qu’est-ce qu’un serveur MCP? C’est un programme ou service distant qui expose des capacités par MCP. Une capacité peut lire des données, fournir une ressource ou accomplir une action. Sa sûreté dépend de l’implémentation, des identifiants et des systèmes cibles autant que du protocole. ### MCP sécurise-t-il les agents IA? Non. MCP définit une connexion interopérable et comprend des mécanismes d’autorisation pour certains transports. L’hôte, le serveur et l’organisation doivent encore imposer identité, moindre privilège, approbation, validation, isolation, audit et récupération. ## Sources primaires - [Présentation de l’architecture MCP](https://modelcontextprotocol.io/docs/learn/architecture), Model Context Protocol - [Bonnes pratiques de sécurité MCP](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices), Model Context Protocol