Le Model Context Protocol définit une manière commune de connecter une application d’IA à des outils et à des sources de contexte. Il évite que chaque assistant invente une intégration différente pour chaque système, mais il ne remplace ni l’API métier ni les règles de sécurité.
L’architecture en trois rôles
Un système MCP distingue généralement :
- **l’hôte**, l’application utilisée par la personne, par exemple un assistant ou un environnement de développement ;
- **le client MCP**, créé par l’hôte pour maintenir une connexion avec un serveur ;
- **le serveur MCP**, qui expose des capacités vers un système local ou distant.
Un hôte peut ouvrir plusieurs clients, chacun relié à un serveur. Cette séparation limite ce qu’un serveur peut observer des autres connexions et laisse à l’hôte la maîtrise de l’expérience utilisateur, des autorisations et du contexte envoyé au modèle.
Les trois primitives à connaître
Tools : demander une action
Un outil est une opération invocable avec des arguments structurés. Il peut lire une base, lancer un calcul ou déclencher une action externe. Le modèle peut proposer son appel, mais l’hôte reste responsable de la décision d’exécution.
Un bon outil possède un nom stable, une description non ambiguë et un schéma d’entrée étroit. delete_all_data ne doit jamais être un effet caché d’un outil présenté comme une simple recherche.
Resources : lire un contexte identifié
Une ressource expose un contenu accessible par URI : fichier, configuration, enregistrement ou documentation. Elle convient aux données que le client choisit de consulter. Les modèles de ressources permettent de paramétrer une URI, par exemple customer://42/profile.
Une ressource ne doit pas contourner les droits du système d’origine. L’identité et les autorisations sont vérifiées côté serveur à chaque lecture.
Prompts : proposer un modèle de conversation
Un prompt MCP est un gabarit réutilisable, éventuellement paramétré. Il permet à un serveur de proposer des procédures ou formulations adaptées à son domaine. Le client décide comment les présenter et quand les utiliser.
Les prompts ne constituent pas une barrière de sécurité : une instruction textuelle peut être ignorée ou contredite. Les contrôles importants restent dans le code.
Comment se déroule une connexion ?
Client et serveur négocient d’abord leur version du protocole et leurs capacités. Après cette initialisation, le client peut lister les primitives disponibles et effectuer des appels. Les messages utilisent JSON-RPC ; le transport assure leur acheminement.
Pour un serveur lancé localement, le transport standard repose souvent sur les entrées et sorties du processus. Pour un service distant, le transport HTTP diffusé permet des connexions réseau. Le choix modifie l’authentification, l’exposition réseau et l’exploitation, pas la sémantique des outils.
MCP n’est pas une API universelle
Le serveur reste un adaptateur. Il traduit des capacités métier existantes en primitives compréhensibles par un client MCP. L’API d’origine continue de définir les transactions, les validations, les quotas et les droits.
Évitez de générer automatiquement des centaines d’outils à partir d’une API entière. Trop d’outils dégradent la sélection par le modèle et augmentent la surface de risque. Exposez des opérations orientées tâche avec des schémas simples.
Sécurité : qui fait quoi ?
Le serveur doit authentifier les appels, vérifier les autorisations, valider les arguments, limiter les effets et journaliser les opérations sensibles. Il ne doit jamais supposer qu’un appel est sûr parce qu’il vient d’un modèle.
L’hôte doit montrer clairement les actions importantes, demander une confirmation lorsque nécessaire et éviter de transmettre inutilement des données d’un serveur à un autre. Il doit aussi traiter les descriptions, ressources et résultats comme des contenus potentiellement non fiables.
Pour chaque outil, classez l’effet : lecture, écriture réversible, message externe, paiement, changement de droits ou suppression. Plus l’effet est difficile à annuler, plus l’approbation doit être explicite et proche de l’action.
Exemple de découpage
Pour un outil de support client, préférez :
search_customer(query)pour rechercher ;get_customer(customer_id)pour lire ;draft_reply(ticket_id)pour préparer sans envoyer ;send_reply(ticket_id, body)pour l’effet externe, avec confirmation.
Ce découpage rend l’intention visible et permet d’appliquer des droits différents. Un unique outil handle_ticket serait plus difficile à contrôler et à auditer.
Checklist avant d’exposer un serveur
- Définir l’utilisateur ou le service au nom duquel chaque appel s’exécute.
- Limiter la liste d’outils au besoin réel.
- Valider les arguments indépendamment du modèle.
- Séparer préparation et action irréversible.
- Protéger secrets et données personnelles dans les journaux.
- Tester délais, annulations, doubles appels et erreurs partielles.
- Versionner les schémas et conserver une compatibilité maîtrisée.
À retenir
MCP standardise la conversation entre applications d’IA et systèmes externes. Il facilite la réutilisation des intégrations ; la confiance dépend toujours de l’architecture d’autorisation, de la qualité des outils et de la manière dont l’hôte contrôle leurs effets.