Le Model Context Protocol expliqué pour les développeurs
Toute équipe qui construit plus d'un agent écrit deux fois le même adaptateur : se connecter à un système, décrire ce qu'il sait faire et exposer ces capacités au modèle dans la forme attendue par le client du jour. Le Model Context Protocol existe pour arrêter cette duplication en normalisant l'interface entre client d'agent et serveur d'outils.
C'est réellement utile, et plus étroit que l'enthousiasme ne le suggère. MCP décrit comment les capacités sont annoncées et invoquées. Il ne décide pas qui a le droit de les invoquer, et confondre les deux est la source des incidents de sécurité.
Ce que le protocole normalise#
- Découverte : le serveur annonce au client ses outils et ressources, avec schémas.
- Invocation : le client appelle avec des arguments typés et reçoit un résultat structuré.
- Ressources : du contenu en lecture seule que le client tire dans le contexte à la demande.
- Transport : un format commun pour que client et serveur d'auteurs différents s'entendent.
Ce qu'il ne fait volontairement pas#
MCP n'authentifie pas vos utilisateurs, ne décide pas quels enregistrements chacun peut lire, ni si une action exige une validation. Cela reste à vous et doit vivre côté serveur — un client qui demande poliment la permission n'est pas un système de permissions. L'erreur d'architecture la plus fréquente est d'exposer un outil large comme `run_query` via MCP en comptant sur le prompt pour le contenir.
Traitez chaque outil MCP comme si un appelant confus ou manipulé allait l'invoquer avec les pires arguments plausibles ; tôt ou tard, quelqu'un le fera.
Où cela paie aujourd'hui#
| Situation | Valeur de MCP |
|---|---|
| Un système interne, plusieurs clients d'agent | Élevée : le serveur s'écrit une fois |
| Assistants de bureau avec contexte local | Élevée : l'écosystème s'est bâti là |
| Un agent avec trois outils maison | Faible : l'appel direct est plus simple |
| Outils tiers que vous ne contrôlez pas | Moyenne : pratique, mais auditez le serveur |
Une adoption sûre#
- Encapsulez des capacités étroites, pas de la puissance générale : `get_order(id)` plutôt que `sql(query)`.
- Appliquez l'autorisation dans le serveur, à chaque appel, avec l'identité de l'utilisateur final.
- Renvoyez des erreurs courtes et honnêtes — `introuvable`, `non autorisé` — pour que l'agent réagisse bien.
- Journalisez chaque invocation avec arguments et identité : c'est votre piste d'audit.
- Épinglez les serveurs utilisés à des versions relues, comme toute dépendance.
La question de la chaîne d'approvisionnement#
Un serveur MCP tiers est du code qui décrit des outils à votre agent et reçoit les arguments que votre agent décide d'envoyer. Les descriptions font partie du contexte du modèle : une description malveillante ou négligente peut influencer le comportement. Relisez les serveurs avant adoption, préférez ceux que vous pouvez lire, et tenez les serveurs non fiables loin des clients à accès sensible.
Questions fréquentes
MCP est-il nécessaire pour construire un agent ?
Non. Pour un agent avec quelques outils maison, l'appel direct est plus simple. MCP paie quand la même capacité doit être atteinte depuis plusieurs clients ou quand vous consommez des outils d'autres équipes.
MCP est-il sûr par défaut ?
C'est une norme de transport et de découverte, pas un modèle de sécurité. Authentification, autorisation par utilisateur et portes de validation s'implémentent côté serveur et ne se délèguent jamais au prompt.
Peuvent-ils être un vecteur d'injection ?
Oui, via les descriptions qui entrent dans le contexte et via le contenu renvoyé. Traitez la sortie comme non fiable, gardez des périmètres étroits et ne pointez pas un agent en écriture vers des serveurs non relus.
model context protocolmcp expliquéstandard d'outils agentssécurité mcpdécouverte d'outils
