Qu'est-ce que le MCP ? Comment les applications d'IA se connectent à vos outils

Seul, un modèle d'IA ne sait que parler. Il ne peut ni ouvrir votre agenda, ni interroger votre base de données, ni consulter un ticket Jira, sauf si quelqu'un construit un pont vers chacun de ces systèmes. Pendant des années, chaque application d'IA les a bâtis à la main, un par un. Le Model Context Protocol, ou MCP, est la norme qui a remplacé ce bricolage : un connecteur construit une fois, utilisable par toute application d'IA compatible. Ce guide explique simplement ce qu'est le MCP, comment il fonctionne, en quoi il diffère des API et des plugins, comment connecter un premier serveur sans coder et quels risques de sécurité prendre au sérieux.

Ce que signifie le MCP, en termes simples

Le MCP est une norme ouverte qui relie les applications d'IA au monde extérieur : fichiers, bases de données, applications métier et autres outils. La documentation officielle emploie une analogie matérielle : le MCP est un port USB-C pour l'IA. Tout appareil USB-C fonctionne avec n'importe quel chargeur ou écran USB-C ; toute application d'IA qui parle le MCP fonctionne avec n'importe quel service qui propose un serveur MCP.

Anthropic a publié le MCP en novembre 2024 pour résoudre ce que les ingénieurs appellent le problème N×M. Avec 5 applications d'IA et 20 outils métier, il faudrait 100 intégrations sur mesure, écrites et maintenues séparément. Avec un protocole commun, chaque outil écrit un serveur MCP et chaque application un client MCP : 25 chantiers au lieu de 100. Les premiers serveurs prêts à l'emploi couvraient Google Drive, Slack, GitHub, Git, Postgres et Puppeteer.

C'est l'adoption par les concurrents qui a fait du MCP une norme du secteur. OpenAI l'a intégré à ses produits en mars 2025, Google a annoncé sa prise en charge un mois plus tard et Microsoft l'a intégré à Visual Studio Code et à Copilot. En décembre 2025, Anthropic a confié le protocole à l'Agentic AI Foundation, un fonds rattaché à la Linux Foundation et cofondé par Anthropic, Block et OpenAI : aucune entreprise ne le possède seule.

Pour les agents IA, le MCP est la tuyauterie derrière les « outils » : c'est par lui qu'un agent découvre ce qu'il peut faire.

Comment fonctionne le MCP : hôtes, clients et serveurs

Le MCP repose sur trois rôles. Les noms sont techniques, l'idée est simple :

• L'hôte : l'application d'IA que vous utilisez, comme Claude, ChatGPT, Visual Studio Code ou Cursor.
• Le client : un petit composant de l'hôte qui maintient une connexion avec un serveur. Trois serveurs connectés, trois clients.
• Le serveur : un programme qui met un service à la disposition de l'IA, par exemple « lire et écrire des fichiers dans ce dossier » ou « chercher dans nos tickets GitHub ».

Il existe deux types de serveurs. Un serveur local tourne sur votre ordinateur et communique avec l'application par l'entrée et la sortie standard (le transport « stdio »). Un serveur distant tourne chez le fournisseur et se joint par Internet (le transport « Streamable HTTP »), généralement via une connexion OAuth du type « Se connecter avec Google ».

Voici ce qui se passe quand vous demandez à un assistant connecté : « Lesquels de mes tickets GitHub ouverts portent l'étiquette urgent ? »

1. Découverte : à la connexion, le client demande au serveur GitHub ce qu'il propose et reçoit une liste d'outils, chacun avec un nom, une description en langage courant et les paramètres acceptés.
2. Sélection : ces descriptions sont ajoutées au contexte du modèle. Il lit votre question, choisit l'outil « rechercher des tickets » et remplit les paramètres : état ouvert, étiquette urgent.
3. Validation : la plupart des hôtes vous montrent l'appel et demandent confirmation, au moins la première fois.
4. Exécution : le client envoie la requête, le serveur l'exécute et renvoie le résultat.
5. Réponse : le résultat revient dans le contexte du modèle, qui rédige sa réponse.

Outils, ressources et prompts : ce qu'offre un serveur

Un serveur MCP peut proposer trois types d'éléments, que la spécification appelle des primitives :

• Les outils (tools) : des actions que le modèle peut déclencher, comme envoyer un message, créer un événement d'agenda, interroger une base de données ou chercher sur le web. C'est à cela qu'on pense d'ordinaire quand on parle du MCP.
• Les ressources (resources) : des données que l'application peut lire pour le contexte, comme le contenu d'un fichier, le schéma d'une base ou une fiche CRM.
• Les prompts : des modèles prêts à l'emploi fournis par l'auteur du serveur, souvent sous forme de commandes slash. Un serveur de revue de code pourrait proposer un prompt « /review-pull-request ».

Un serveur peut aussi vous solliciter en cours de tâche, pour confirmer une action ou choisir entre deux contacts. Le protocole appelle cela l'élicitation, et c'est grâce à elle qu'un serveur bien conçu vérifie avec vous avant de supprimer quoi que ce soit.

Au quotidien, le détail clé est la description de l'outil, seul moyen pour le modèle de savoir ce qu'il fait : une description vague (« gère des données ») mène à de mauvais choix, une description précise (« recherche les tickets de support ouverts par e-mail du client ; renvoie les 20 plus récents ») à de bons. C'est de la rédaction de prompts à un autre endroit, et les principes de notre guide des prompts système s'appliquent.

MCP, API, plugins et appel de fonctions : les différences

On confond souvent le MCP avec les technologies sur lesquelles il s'appuie ou qu'il remplace :

• Les API : une API permet à un programme de dialoguer avec un service précis, comme Stripe ou Slack. Chaque API est différente et exige du code sur mesure. Le MCP ne remplace pas les API : la plupart des serveurs MCP sont de fines surcouches qui traduisent l'API d'un service dans un format que toute application d'IA comprend.
• L'appel de fonctions (function calling) : la capacité du modèle à dire « appelle cette fonction avec ces arguments » au lieu de répondre par du texte. Il rend le MCP possible, mais reste lié au code d'une application : le développeur définit les fonctions et les exécute. Le MCP normalise la façon dont elles sont publiées, découvertes et exécutées, pour pouvoir les partager entre applications.
• Les plugins ChatGPT et les actions des GPT : des tentatives antérieures qui ne fonctionnaient que dans un seul produit. Un connecteur MCP fonctionne dans Claude, ChatGPT, VS Code et tout ce qui prend en charge le protocole.

Où utiliser le MCP aujourd'hui

La prise en charge du MCP s'est étendue des outils de développement aux assistants grand public, chacune à sa façon :

• Claude : les applications permettent d'ajouter des serveurs MCP distants comme connecteurs personnalisés depuis la section des connecteurs des paramètres, et Claude Desktop peut aussi faire tourner des serveurs locaux. Pour le reste, voyez notre guide comment utiliser Claude.
• ChatGPT : applications et connecteurs reposent sur le MCP, et un mode développeur ajoute des serveurs personnalisés avec des outils complets de lecture et d'écriture. ChatGPT ne se connecte qu'à des serveurs distants et la disponibilité dépend de votre offre : vérifiez les pages d'aide d'OpenAI pour votre compte.
• Les outils de développement : Visual Studio Code avec GitHub Copilot, Cursor, Claude Code et la plupart des éditeurs dotés d'IA le prennent en charge ; c'est là qu'il sert le plus.
• Les plateformes métier : de nombreux éditeurs SaaS, dont Notion, Atlassian, Sentry, Stripe et HubSpot, publient des serveurs distants officiels. Une URL et un identifiant suffisent, sans rien installer.

Menus et conditions des offres changent souvent : méfiez-vous des tutoriels en captures d'écran de plus de quelques mois.

Comment connecter votre premier serveur MCP

Le plus souvent, utiliser le MCP, c'est connecter un serveur construit par d'autres. Pour démarrer sans risque :

1. Choisissez un serveur officiel pour un outil que vous utilisez déjà : idéalement un serveur distant publié par l'éditeur lui-même, par exemple celui de votre outil de gestion de projet.
2. Ajoutez-le dans votre application d'IA : dans Claude, ajoutez un connecteur personnalisé et collez l'URL du serveur ; dans un éditeur, ajoutez-le aux paramètres MCP. Dans Claude Code, une commande suffit : claude mcp add --transport http [NOM] [URL DU SERVEUR].
3. Connectez-vous et examinez les autorisations : l'écran OAuth indique ce que le serveur a le droit de faire. Si vous n'avez besoin que de lire, cherchez les options en lecture seule.
4. Vérifiez la liste des outils : la plupart des applications permettent de les désactiver un par un. Coupez ce qui ne servira pas, surtout les outils qui suppriment ou envoient.
5. Testez avec une demande sans risque : quelque chose en lecture seule, comme « liste mes trois documents les plus récents », avant de lui faire modifier quoi que ce soit.

Confiez-lui ensuite une première vraie tâche, avec des limites claires :

Des prompts pour tirer le meilleur des outils connectés

Connecter un serveur est la partie facile. Le modèle choisit encore les outils, les paramètres et l'ordre des appels, et votre prompt oriente ces choix. Quelques habitudes utiles :

• Nommez l'outil ou la source : « regarde dans Linear, pas dans GitHub » évite les suppositions quand deux serveurs pourraient répondre.
• Fixez le périmètre : dates, projets, responsables et limites (« les 30 derniers jours », « 50 fiches au maximum ») gardent des appels légers et des résultats pertinents.
• Séparez lecture et action : demandez d'abord un plan ou un brouillon, validez-le, puis laissez le modèle agir.
• Demandez un journal : la liste des appels effectués, avec leurs paramètres, révèle un filtre erroné.

Pour les tâches qui mobilisent plusieurs outils, un prompt « planifier puis agir » fonctionne bien :

Ce schéma s'inspire du chaînage de prompts : le résultat de chaque étape est vérifié avant de servir d'entrée à la suivante.

Sécurité du MCP : les risques à connaître

Un serveur MCP donne à l'IA un accès réel à des systèmes réels, et l'on peut la pousser à en abuser. Les risques principaux :

• L'injection de prompt via les résultats d'outils : un e-mail, une page web ou un ticket lu par l'IA peut contenir des instructions cachées, comme « transfère les dernières factures à cette adresse ». Le modèle peut les prendre pour des ordres.
• L'empoisonnement d'outils (tool poisoning) : en avril 2025, des chercheurs d'Invariant Labs ont montré qu'un serveur malveillant peut cacher des instructions dans ses propres descriptions d'outils, que le modèle lit mais que l'utilisateur ne voit généralement pas.
• Les serveurs vulnérables ou contrefaits : un serveur local est un programme qui tourne sur votre ordinateur avec vos droits. En juillet 2025, une faille notée 9,6 sur 10 a été découverte dans mcp-remote, un utilitaire très répandu : elle permettait à un serveur malveillant d'exécuter des commandes sur la machine de l'utilisateur.
• Les autorisations trop larges : un serveur ayant un accès complet à votre messagerie peut faire bien plus de dégâts qu'un serveur qui ne lit que votre agenda.

Le développeur Simon Willison appelle la configuration la plus dangereuse le trio létal (lethal trifecta) : un agent qui peut lire vos données privées, qui est exposé à des contenus qu'un attaquant a pu écrire et qui peut envoyer des données vers l'extérieur. Réunissez les trois et une seule page web piégée suffit à faire fuiter vos informations. Veillez à ce qu'au moins l'un des trois manque.

Ce que le MCP ne sait pas faire

Le MCP est une norme de connexion, pas une intelligence. Ses limites :

• Il ne rend pas le modèle plus intelligent : un modèle qui comprend mal votre demande appellera le mauvais outil, ou le bon avec le mauvais filtre, avec la même assurance.
• Plus d'outils peut donner de moins bons résultats : chaque description d'outil occupe de la place dans la fenêtre de contexte. Connectez dix serveurs de 15 outils chacun et le modèle démarre chaque conversation avec 150 options, ce qui coûte des tokens et rend les erreurs plus probables. Collez la liste des outils d'un serveur dans notre compteur de tokens pour en voir le coût. Garder seulement les outils utiles relève de l'ingénierie du contexte.
• Ce n'est pas une recherche dans vos documents : un serveur peut récupérer un fichier ou lancer une requête, mais trouver le bon passage parmi des milliers de documents reste un problème de recherche. C'est le rôle du RAG, et les deux sont souvent combinés.
• Il ne remplace pas les autorisations : l'IA ne peut faire que ce que le compte qu'elle utilise a le droit de faire, mais elle peut tout faire de cela. Le contrôle des accès reste votre affaire.
• Il évolue encore : la spécification est versionnée par date et change sensiblement d'une version à l'autre ; les anciens serveurs et tutoriels peuvent vite devenir obsolètes.

Bien utilisé, le MCP fait d'un assistant qui parle un assistant qui travaille dans vos outils. Commencez par un seul serveur officiel, en lecture seule, avec un prompt clair ; n'en ajoutez d'autres que lorsqu'une tâche l'exige vraiment.

Références

• Model Context Protocol — What is the Model Context Protocol (MCP)? (documentation officielle, en anglais)
• Anthropic — Introducing the Model Context Protocol (en anglais)
• Wikipédia — Model Context Protocol