Introduction

Le Model Context Protocol, ou MCP, est un protocole ouvert permettant de connecter les applications d’IA à des sources externes de contexte et à des capacités exécutables. Une application peut utiliser MCP pour accéder à des fichiers, interroger un service, appeler une logique métier ou réutiliser un modèle de prompt grâce à un modèle d’interaction cohérent. L’idée essentielle est la séparation des responsabilités : l’application orchestre la conversation, tandis qu’un serveur MCP expose une interface contrôlée vers des données ou des actions.

Cette séparation est importante, car les applications d’IA ont souvent besoin de nombreuses intégrations. Sans protocole commun, chaque application doit définir son propre format de connecteur, son propre mécanisme de découverte, son propre flux d’authentification et son propre schéma d’outil pour chaque service. MCP fournit aux hôtes et aux serveurs un contrat commun, ce qui réduit le code propre à chaque intégration et facilite l’inspection des capacités. Il ne rend pas un modèle de langage précis à lui seul, ne remplace pas un système d’autorisation et ne garantit pas qu’une opération externe est sans danger.

Un modèle mental utile est celui d’un pont contrôlé. Le modèle propose qu’une capacité puisse être utile, l’hôte détermine si la requête est autorisée, un client MCP envoie une requête conforme au protocole, et le serveur exécute ou refuse l’opération. Le résultat revient ensuite par l’intermédiaire du client jusqu’à l’hôte, qui décide comment le présenter au modèle et à l’utilisateur.

Architecture principale

Un hôte MCP est l’application d’IA complète avec laquelle l’utilisateur interagit. Un assistant de bureau, un environnement de développement ou un service d’agent personnalisé peut servir d’hôte. L’hôte gère le flux de la conversation et détermine généralement quels serveurs sont configurés, quelles autorisations s’appliquent, comment les résultats des outils sont insérés dans le contexte du modèle et si l’utilisateur doit approuver une opération.

Un client MCP est le composant du protocole géré par l’hôte. Dans une architecture courante, l’hôte crée une connexion client pour chaque serveur MCP. Le client gère les communications du protocole, l’initialisation, la négociation des capacités, la corrélation des requêtes, les notifications et les détails propres au transport. Le client n’est ni le modèle de langage ni l’implémentation du serveur : il constitue la couche de connexion entre l’hôte et un serveur.

Un serveur MCP est un programme qui expose des capacités via MCP. Il peut s’exécuter localement en tant que sous-processus ou à distance derrière un transport réseau, selon le déploiement et la prise en charge du client. Un serveur peut lire une source de données approuvée, appeler un service externe ou implémenter une logique métier. Il doit exposer une interface claire et limitée, et appliquer ses propres validations au lieu de supposer que l’hôte ou le modèle a vérifié chaque entrée.

Le modèle n’ouvre généralement pas de connexions réseau brutes vers les serveurs. À la place, l’hôte met à disposition les capacités découvertes via MCP et intègre les résultats pertinents dans l’interaction avec le modèle. Cette séparation améliore le contrôle et l’observabilité, car l’hôte peut journaliser les requêtes, exiger une confirmation, appliquer des politiques et gérer les échecs avant qu’une action externe ne soit exécutée.

Flux du protocole

Une session MCP commence par une initialisation. Le client et le serveur identifient les informations de protocole et échangent les capacités décrivant les fonctionnalités prises en charge par chacun. Le client doit terminer cette étape du cycle de vie avant d’utiliser les fonctionnalités normales du serveur. Un client doit également gérer la possibilité qu’un serveur ne prenne pas en charge une capacité optionnelle, plutôt que de supposer que tous les serveurs implémentent toutes les fonctionnalités.

Après l’initialisation, le client peut découvrir les fonctionnalités du serveur. Les outils décrivent des opérations pouvant être invoquées avec des entrées structurées, comme rechercher un ticket dans un outil de suivi ou créer un événement de calendrier. Les ressources représentent des données pouvant être lues comme contexte, par exemple un document ou le résultat d’une requête de base de données. Les prompts représentent des structures de messages ou des workflows réutilisables qu’un serveur peut fournir à l’hôte. Ces catégories ont des finalités différentes et ne doivent pas être considérées comme des libellés interchangeables.

Un flux d’utilisation d’un outil comporte généralement plusieurs étapes. L’hôte met une définition d’outil à la disposition du modèle, le modèle propose un appel avec des arguments, puis l’hôte évalue la politique applicable et le consentement de l’utilisateur. Si la demande est approuvée, le client envoie la requête au serveur. Le serveur valide les arguments, exécute l’opération si elle est autorisée et renvoie un résultat ou une erreur. L’hôte décide ensuite si le résultat doit être affiché à l’utilisateur, renvoyé au modèle, ou les deux.

Les messages MCP utilisent un protocole structuré fondé sur les concepts de JSON-RPC ; les requêtes, les résultats, les erreurs et les notifications y ont donc des rôles définis. Le transport exact est indépendant de la signification des messages. Les intégrations locales utilisent couramment une connexion fondée sur un processus, comme l’entrée et la sortie standard, tandis que les intégrations distantes peuvent utiliser un transport basé sur HTTP et pris en charge par l’implémentation. Un transport achemine les messages ; il ne détermine pas si une action est autorisée.

Scénario d’intégration pratique

Prenons le cas d’un assistant interne de support connecté à deux serveurs. Un serveur de tickets expose un outil de recherche de tickets et un outil permettant d’ajouter une note interne. Un serveur de documentation expose des ressources contenant des pages de dépannage approuvées. L’hôte se connecte aux deux serveurs au moyen de clients MCP distincts et découvre leurs capacités au démarrage.

Lorsqu’un ingénieur support demande la cause probable d’une erreur connue, l’hôte peut permettre au modèle d’utiliser l’outil de recherche de tickets et les ressources documentaires. Le résultat de la recherche peut identifier des incidents associés, tandis que la ressource documentaire fournit un contexte technique approuvé. L’hôte peut présenter les deux résultats au modèle avec leurs informations de source, afin que celui-ci rédige une réponse fondée sur les données disponibles.

Si l’ingénieur demande à l’assistant d’ajouter une note à un ticket, le workflow change, car l’opération entraîne un effet de bord externe. L’hôte doit afficher le ticket cible et la note proposée, vérifier que l’utilisateur dispose des autorisations nécessaires et demander une confirmation lorsque cela est approprié. Le serveur doit malgré tout valider l’identifiant du ticket, la longueur de la note et le contexte d’autorisation. L’approbation accordée par une couche ne dispense pas les autres de leur responsabilité de validation.

Les tests les plus utiles couvrent l’intégralité de la frontière d’intégration, et pas uniquement la réponse finale. Vérifiez que l’initialisation réussit, que les capacités non prises en charge sont correctement gérées, que des arguments mal formés produisent une erreur contrôlée, qu’une opération refusée ne modifie pas l’état externe et qu’un délai d’attente du serveur n’amène pas l’hôte à afficher un message de succès fabriqué. Ces tests rendent le comportement de l’intégration explicite et facilitent le diagnostic.

Modes de défaillance courants

Une erreur fréquente consiste à confondre MCP avec un framework d’agents autonomes. MCP définit la communication et l’exposition des capacités ; il n’impose pas un algorithme de planification, un fournisseur de modèles, un système de mémoire ou une interface utilisateur particuliers. Un agent peut utiliser MCP, mais la boucle de l’agent reste une décision de conception applicative. Une autre erreur consiste à traiter chaque fonctionnalité d’un serveur comme un outil, ce qui peut encourager des actions inutiles alors que des ressources en lecture seule seraient plus appropriées.

Les failles de sécurité proviennent souvent d’un excès de confiance. Les descriptions des outils constituent des métadonnées utiles, mais elles ne forment pas une frontière de sécurité complète. Validez les entrées sur le serveur, restreignez les accès aux fichiers et au réseau, protégez les identifiants et appliquez l’autorisation au niveau de chaque opération. Évitez d’exposer un outil général d’exécution de commandes lorsqu’une petite opération spécifique au domaine peut répondre au besoin.

Les problèmes opérationnels concernent souvent la gestion du cycle de vie et du transport. Un client peut tenter d’envoyer des requêtes avant l’initialisation, supposer qu’une capacité existe, perdre une connexion sans réinitialiser son état ou considérer un délai d’expiration comme un résultat réussi. Consignez l’identité du serveur, le type de requête, les informations de corrélation, la durée et les détails d’erreur assainis. N’enregistrez pas de jetons, de mots de passe ou de contenu utilisateur sensible dans le seul but de simplifier le débogage.

Une autre défaillance consiste à laisser les résultats des outils entrer dans le contexte du modèle sans vérifier leur origine ni leur pertinence. Le contenu externe peut contenir des instructions trompeuses ou des données qu’il serait dangereux de reproduire. L’hôte doit maintenir des frontières claires entre les instructions, les données récupérées et les actions approuvées par l’utilisateur, tandis que l’application définit la manière dont le contenu non fiable est traité.

Résumé

MCP fournit aux applications d’IA un moyen standard de connecter les modèles à un contexte et à des capacités externes. L’hôte gère l’expérience applicative et les décisions de politique, le client gère une connexion au protocole et le serveur expose des données ou des opérations validées. La séparation de ces responsabilités facilite la compréhension et les tests des intégrations.

Le flux de travail principal comprend l’initialisation, la négociation des capacités, la découverte, l’invocation ou la récupération contrôlée, puis le traitement des résultats. Les outils conviennent aux opérations appelables, les ressources aux données contextuelles et les prompts aux modèles d’interaction réutilisables. Le protocole peut transporter des messages via différents transports, mais le choix du transport ne remplace ni l’authentification, ni l’autorisation, ni la validation, ni l’observabilité.

Lors de la conception d’une intégration MCP, commencez par l’interface de serveur la plus petite qui soit utile. Définissez ce que le serveur expose, identifiez les opérations qui ont des effets de bord, déterminez où le consentement est requis et spécifiez le comportement en cas d’échec avant de connecter le modèle. Une application fiable traite la sortie du modèle comme une proposition, applique la politique au niveau de l’hôte et du serveur, et vérifie les résultats externes avant de signaler la réussite.