Qu’est-ce que le MCP et pourquoi tout le monde en parle ?

Le sigle MCP revient régulièrement dans les discussions autour des assistants d’intelligence artificielle. Il désigne le Model Context Protocol, un protocole ouvert destiné à relier une application d’IA aux données et aux outils qui l’entourent. Ni un modèle, ni un produit, ni une promesse d’autonomie : une convention technique. Voici ce qu’elle décrit, ce qu’elle permet, et ce qu’elle ne règle pas.

MCP : de quoi parle-t-on exactement ?

MCP signifie *Model Context Protocol*. C’est un protocole, c’est-à-dire un ensemble de règles décrivant comment deux programmes échangent des messages. Il est dit ouvert parce que sa spécification est publique, documentée et modifiable par une communauté, et non contrôlée par un produit unique.

Son objet est précis : décrire une manière standardisée, pour une application d’IA, de se connecter à des systèmes externes — fichiers, bases de données, services métier, outils de développement — afin de récupérer du contexte utile ou de déclencher des actions. La documentation officielle le présente comme une couche de connexion normalisée.

Un point mérite d’être posé d’emblée : un modèle de langage n’accède pas « magiquement » à vos documents, logiciels ou comptes. Sans intégration explicite, serveur adapté et permission accordée, il ne voit que la conversation. MCP ne change pas cette règle ; il normalise la façon de construire cette intégration.

Quel problème le MCP cherche-t-il à résoudre ?

Avant un standard partagé, chaque connexion se construisait à part. Un assistant devant lire un espace documentaire, un outil de suivi de projet et une base de données nécessitait trois développements distincts — et changer d’assistant imposait souvent de refaire ce travail, chaque application exposant sa propre manière de déclarer des outils. Cette multiplication des intégrations propriétaires coûte cher à écrire, et surtout à maintenir.

L’annonce initiale du protocole, publiée par Anthropic le 25 novembre 2024, décrit exactement ce point de départ : des modèles performants mais isolés derrière des silos d’information, avec une implémentation spécifique à écrire pour chaque nouvelle source de données.

L’idée d’un langage d’intégration commun est donc économique autant que technique : un serveur écrit une fois peut, en principe, servir à plusieurs applications compatibles. On peut y voir une prise universelle — l’analogie est parlante, mais c’est une simplification. Une prise commune garantit le branchement, pas la pertinence : MCP ne garantit à lui seul ni la compatibilité avec vos process, ni la qualité d’un outil, ni sa sécurité, et toutes les intégrations ne deviennent pas interchangeables.

Comment fonctionne le MCP ?

L’architecture officielle distingue trois rôles.

L’hôte est l’application utilisée par la personne : un assistant conversationnel, un environnement de développement, un logiciel métier compatible. C’est lui qui parle au modèle, affiche l’interface et arbitre ce qui est autorisé.

Le client MCP est le composant, situé dans l’hôte, chargé d’ouvrir et de maintenir la communication avec un serveur. Un hôte peut gérer plusieurs clients, donc plusieurs connexions en parallèle, chacune vers un serveur différent.

Le serveur MCP est un programme distinct qui expose des capacités ou des informations à l’application d’IA. Il peut tourner sur votre machine ou à distance, et décide ce qu’il rend visible : tel dossier, telle requête, telle action — rien d’autre.

Un exemple fixe les idées. Un assistant doit préparer une réunion client : consulter quelques documents, retrouver un historique dans une base de données, puis créer une tâche dans un outil professionnel. Avec MCP, l’hôte ouvre trois connexions — un serveur « documents » limité à un dossier autorisé, un serveur « base de données » en lecture, un serveur « gestion de tâches » proposant une action de création. Le modèle ne devine rien : il découvre ce que chaque serveur déclare, et l’hôte contrôle ce qui est réellement exécuté.

Ressources, outils et prompts : quelles différences ?

Un serveur MCP peut exposer trois types de capacités. Les distinguer évite beaucoup de confusions.

Les ressources sont des données lisibles. Les outils sont des fonctions exécutables : c’est la catégorie sensible, puisqu’une action peut écrire, modifier ou envoyer quelque chose — voir l’utilisation d’outils. Les prompts sont des modèles d’instructions réutilisables proposés par le serveur.

Ces trois capacités ne sont pas obligatoires : un serveur peut n’exposer que des ressources, uniquement des outils, ou une combinaison partielle. Mieux vaut regarder ce qu’il déclare que supposer qu’il fait tout.

Des usages concrets

Voici des exemples cohérents avec ce que le protocole permet techniquement.

• Consulter des fichiers dans un dossier explicitement autorisé.
• Rechercher une information dans une documentation interne.
• Interroger une base de données en lecture pour retrouver un historique.
• Travailler avec un dépôt de code : lire des fichiers, préparer une modification.
• Consulter un calendrier pour situer des disponibilités.
• Préparer une action dans un outil professionnel : brouillon, ticket, fiche.
• Connecter un assistant à une API métier interne.

Pour les actions sensibles — écriture, envoi, suppression, paiement —, une précision s’impose : la possibilité technique d’exécuter une action ne signifie pas qu’elle doive être autorisée automatiquement.

Pourquoi le MCP attire-t-il autant l’attention ?

Plusieurs raisons vérifiables se cumulent.

D’abord, les assistants capables d’utiliser des outils se sont généralisés : dès lors qu’un modèle peut invoquer des fonctions, savoir *comment* les déclarer devient central. Ensuite, réécrire les mêmes connecteurs pour chaque application coûte cher. Le protocole est par ailleurs pris en charge par plusieurs acteurs : la documentation d’OpenAI décrit l’utilisation de serveurs MCP dans ses propres outils, aux côtés des SDK et de la documentation publiés par le projet.

Enfin, la gouvernance a évolué vers un cadre ouvert : la documentation officielle indique que le Model Context Protocol est établi comme un projet de LF Projects, LLC, avec des rôles de mainteneurs, un processus de décision et des propositions d’évolution publiques.

Cela ne fait pas du MCP le vainqueur définitif d’une « guerre des standards » : un protocole documenté et adopté par plusieurs acteurs reste un protocole en évolution, et tous les outils d’IA ne l’utilisent pas.

MCP, agent IA et chatbot : ne pas tout confondre

Trois notions sont régulièrement mélangées.

MCP est un protocole de connexion : il décrit des échanges, pas un comportement. Un chatbot est une interface conversationnelle : il reçoit une question, produit une réponse. Un agent IA est un système capable d’organiser ou d’exécuter plusieurs étapes selon des règles déterminées, en utilisant des outils.

Brancher un serveur MCP ne transforme donc pas automatiquement une application en agent autonome. Les capacités finales dépendent du modèle, de l’application hôte, des outils réellement disponibles, des autorisations accordées et des garde-fous mis en place. Sans logique d’orchestration ni permissions d’écriture, un assistant connecté reste un assistant qui lit mieux son contexte.

Les risques et limites à connaître

C’est le point le plus important en usage professionnel. MCP n’est pas dangereux par nature : il fournit un cadre technique, et la documentation officielle consacre une page aux bonnes pratiques de sécurité. Mais le niveau réel de sécurité dépend de l’implémentation du serveur, de l’hôte, des permissions accordées et du comportement de l’utilisateur.

Les points de vigilance à examiner :

• Permissions excessives : un serveur configuré avec un accès large voit plus que nécessaire. Le principe du moindre privilège s’applique ici comme ailleurs.
• Serveurs non fiables : installer un serveur revient à exécuter un programme tiers. Sa provenance, son code et son mainteneur comptent.
• Actions déclenchées sans validation : autoriser une écriture automatique supprime le dernier filet de sécurité humain.
• Fuite de données : ce qu’un serveur peut lire peut être transmis à l’application, donc potentiellement au modèle et à son hébergeur.
• [Injection de prompt](/lexique-ia/injection-prompt) : un contenu récupéré depuis une source externe peut contenir des instructions déguisées visant à détourner l’assistant.
• Détournement d’autorisations : un jeton d’accès mal cloisonné peut servir à autre chose que l’usage prévu.
• Journaux : ce qui est enregistré, où, et pour combien de temps, doit être décidé explicitement.
• Séparation lecture / écriture : commencer en lecture seule, n’ouvrir l’écriture que sur un périmètre précis.
• Révocation : savoir couper un accès rapidement, et vérifier qu’il est effectivement coupé.
• Validation humaine : maintenir une confirmation explicite pour toute opération sensible.

À retenir : un serveur MCP ne reçoit que les accès qui lui sont accordés — mais ces accès peuvent être très puissants. Il faut donc vérifier sa provenance et limiter ses permissions au strict nécessaire.

Ce que cela change pour les utilisateurs et les entreprises

Les bénéfices potentiels sont réels, sans être garantis : des assistants mieux intégrés aux outils déjà utilisés, moins de développements spécifiques dans certains scénarios, un composant compatible plus facile à remplacer, des workflows adaptés à un métier, une centralisation plus lisible des connexions.

Les contraintes sont tout aussi concrètes : installer et configurer, gouverner les accès, maintenir les serveurs, accepter une compatibilité variable, traiter la sécurité sérieusement, former les utilisateurs. Un workflow automatisé mal cadré reproduit les erreurs plus vite, pas moins souvent.

Faut-il utiliser le MCP aujourd’hui ?

La réponse dépend du profil.

Un particulier n’a rien à construire : il en bénéficie indirectement, via des applications compatibles proposant des connexions déjà intégrées. Un utilisateur avancé peut connecter des outils locaux ou distants, en commençant par des accès en lecture sur un périmètre limité. Une entreprise doit d’abord cadrer : quelles données, quels droits, quelles actions autorisées, quelle validation humaine, quelle traçabilité. Et rien n’oblige à s’y mettre : utiliser MCP parce que le sujet est populaire n’est pas un projet ; identifier une tâche répétitive et vérifier qu’une connexion la simplifie réellement, si.

Conclusion

Le Model Context Protocol répond à un problème d’ingénierie ancien : relier un système à d’autres sans réécrire une intégration pour chaque combinaison. Il définit des rôles clairs — hôte, client, serveur —, un vocabulaire de capacités — ressources, outils, prompts — et un cadre de sécurité documenté.

Ce n’est ni une révolution automatique, ni un gadget : c’est une plomberie utile et structurante, neutre quant à l’usage qu’on en fait. Sa valeur dépendra des applications hôtes et de la rigueur des permissions accordées.

Une idée simple pour finir : MCP ne rend pas une intelligence artificielle plus intelligente par lui-même ; il lui fournit une manière standardisée de découvrir et d’utiliser des données ou des capacités externes, dans les limites définies par l’application et ses autorisations.

Questions fréquentes

MCP est-il une intelligence artificielle ?

Non. MCP est un protocole de communication : il ne comprend rien et ne génère rien. Le raisonnement vient du modèle ; MCP décrit seulement comment l’application peut aller chercher des informations ou déclencher des actions.

Faut-il savoir programmer pour utiliser MCP ?

Pas pour en bénéficier. Si l’application que vous utilisez propose des connexions compatibles, l’activation relève de la configuration. En revanche, créer un serveur MCP ou l’exposer à un système interne est un travail technique, qui suppose aussi de gérer les permissions.

Un serveur MCP peut-il accéder à toutes mes données ?

Non, pas par défaut : un serveur voit ce que sa configuration et les autorisations accordées lui permettent de voir. Le risque vient d’un périmètre trop large — un accès à l’ensemble d’un disque ou d’une base est effectivement très étendu.

MCP transforme-t-il un chatbot en agent IA ?

Non. Le protocole donne accès à des ressources et à des outils. Devenir un agent suppose une orchestration en plusieurs étapes, des règles et des garde-fous, qui dépendent de l’application hôte et du modèle — pas du protocole seul.

MCP est-il réservé à Claude ?

Non. Le protocole a été présenté initialement par Anthropic, en novembre 2024, mais il est ouvert : sa spécification est publique et sa gouvernance est portée par un projet communautaire. D’autres acteurs le prennent en charge — la documentation d’OpenAI décrit par exemple l’usage de serveurs MCP dans ses outils. Le niveau de prise en charge varie néanmoins d’une application à l’autre : c’est la documentation de chaque éditeur qui fait référence.

Sources officielles

• Model Context Protocol — Introduction et prise en main
• Model Context Protocol — Architecture du protocole
• Model Context Protocol — Concepts côté serveur : ressources, outils, prompts
• Model Context Protocol — Concepts côté client
• Model Context Protocol — Bonnes pratiques de sécurité
• Model Context Protocol — Gouvernance et stewardship
• Anthropic — Introducing the Model Context Protocol (25 novembre 2024)
• OpenAI — Documentation MCP de la plateforme