Qu'est-ce que MCP, et pourquoi tous les outils d'IA se mettent-ils soudain à le parler ?
Pendant la plus grande partie de la dernière décennie, connecter un modèle d'IA aux outils de votre entreprise signifiait une intégration sur mesure pour chaque paire. Le Model Context Protocol, le standard ouvert qu'Anthropic a présenté en novembre 2024, a remplacé cela par une seule prise qui s'adapte partout — et OpenAI, Google et Microsoft l'ont tous adopté depuis. Voici comment il fonctionne vraiment, et une vraie liste de contrôle avant d'en connecter un aux données de votre équipe.
Ouvrez l'application de bureau de Claude et demandez-lui de vérifier les pull requests ouvertes de votre équipe : elle peut simplement le faire. Pas parce qu'Anthropic a intégré GitHub dans Claude. Parce que quelque part — votre équipe informatique, un fournisseur, un développeur sur GitHub — quelqu'un a écrit un petit programme qui parle un protocole appelé MCP, et Claude sait déjà parler à tout ce qui le parle. C'est désormais vrai aussi de ChatGPT, de Gemini de Google et de Microsoft Copilot. Cette convergence, plus que n'importe quelle sortie de fonctionnalité isolée, explique pourquoi MCP est devenu ce que presque tous les fournisseurs d'IA ont passé l'année dernière à prendre en charge.
Ce que MCP est vraiment
MCP signifie Model Context Protocol. Anthropic l'a conçu, et a publié la spécification en open source avec les premiers SDK le 25 novembre 2024. Ses propres documents de lancement ont décrit l'idée avec une analogie qui est restée : voyez MCP comme un port USB-C pour les applications d'IA — un standard de connecteur physique, au lieu d'un câble différent pour chaque accessoire. Au lancement, Anthropic a nommé les premiers adoptants qui intégraient déjà MCP dans leurs propres produits, notamment les éditeurs de logiciels d'entreprise Block et Apollo, ainsi que les éditeurs d'outils pour développeurs Zed, Replit, Codeium et Sourcegraph. L'application de bureau de Claude est sortie, le même jour, avec la capacité d'exécuter des serveurs MCP localement sur la machine d'une personne.
Le problème qu'il résout : N outils fois M sources de données
Le problème que MCP résout a un nom que les ingénieurs emploient sans cérémonie : le problème d'intégration N par M. Imaginons qu'une entreprise utilise cinq outils d'IA qui doivent agir sur les données de l'entreprise — Claude, ChatGPT, GitHub Copilot, Cursor et un bot de support interne — et que ces données vivent dans huit endroits : Slack, GitHub, une base Postgres, Salesforce, Notion, Google Drive, Jira et une API interne. Sans protocole partagé, relier chaque outil à chaque source de façon utile demande jusqu'à quarante intégrations distinctes — cinq fois huit — chacune avec son propre schéma d'authentification, sa propre gestion des erreurs, et sa propre taxe de maintenance chaque fois que l'une de ces API change de forme. Ajoutez un sixième outil d'IA et le nombre passe à quarante-huit. En pratique, personne n'a construit les quarante. Chaque fournisseur d'IA a construit la poignée qu'il jugeait digne du temps d'ingénierie, et tout le reste est resté manuel : copier, coller, réexpliquer, recommencer.
MCP transforme la multiplication en addition. Une entreprise qui veut que Claude lise sa base Postgres ne construit pas un connecteur Postgres spécifique à Claude. Elle construit — ou réutilise celui que quelqu'un d'autre a déjà publié — un serveur MCP qui expose Postgres, et ce serveur fonctionne avec Claude, ChatGPT, Gemini ou tout autre agent compatible MCP, sans code supplémentaire. La propre liste d'Anthropic, au lancement, nommait des serveurs préconstruits pour Google Drive, Slack, GitHub, Git, Postgres et un outil d'automatisation de navigateur appelé Puppeteer. L'enjeu n'a jamais été qu'Anthropic les construirait tous. C'est que n'importe qui pouvait le faire, et le catalogue de serveurs disponibles a largement dépassé ce qu'une seule entreprise pourrait assurer avec ses équipes.
Comment le protocole fonctionne vraiment
Une fois le cadre retiré, MCP est un protocole client-serveur assez simple, délibérément sans glamour. Il définit trois rôles. Un Host est l'application qu'une personne ouvre vraiment — Claude Desktop, un IDE comme Cursor, l'application ChatGPT. Le Host embarque un MCP Client, qui ouvre une connexion directe et à état vers un MCP Server — un petit programme qui expose un système précis : une base de données, un outil de tickets, un système de fichiers, une API interne. Client et serveur échangent des messages au format JSON-RPC 2.0, un format léger d'appel de procédure distante déjà courant dans l'infrastructure existante, sur l'un de deux transports : stdio, quand le serveur est un programme qui tourne localement sur la même machine, ou Streamable HTTP, quand c'est un service hébergé qui tourne ailleurs.
Ce qu'un serveur peut exposer se ramène à trois primitives. Les Tools sont des fonctions que le modèle peut appeler pour agir — create_task, run_query, send_message — et le modèle décide quand en appeler une selon la conversation. Les Resources sont un contexte en lecture seule que le Host peut récupérer et remettre au modèle sans que celui-ci ait à le demander — le contenu d'un fichier, un schéma de base, un ticket de support. Les Prompts sont des modèles réutilisables, déclenchés par l'utilisateur — un « résume ce fil » ou « rédige une mise à jour de statut » tout prêt, qu'une personne invoque explicitement, plutôt que quelque chose que le modèle décide de faire seul. Un serveur bien construit dit explicitement lequel des trois il offre pour une capacité donnée, parce que cette distinction détermine exactement si un outil d'IA connecté peut regarder quelque chose ou le modifier.
Qui d'autre l'a adopté, et quand
Les premiers mois de MCP ont été un projet uniquement Anthropic. Cela a changé vite, et d'une façon vraiment inhabituelle dans l'IA : des concurrents directs ont convergé vers le protocole d'une seule entreprise plutôt que de livrer le leur. OpenAI a ajouté la prise en charge de MCP à son Agents SDK en mars 2025, permettant aux développeurs de connecter des workflows d'agents à n'importe quel serveur MCP au lieu de construire des intégrations d'outils sur mesure, spécifiques à OpenAI. Le mois suivant, Google DeepMind a confirmé que Gemini et son propre kit de développement d'agents prendraient aussi MCP en charge — un geste que Google a associé à son propre protocole complémentaire, Agent2Agent, destiné à laisser des agents indépendants se coordonner entre eux plutôt qu'avec des outils. En mai 2025, Microsoft avait apporté une prise en charge native de MCP à Windows 11 via ce qu'il appelle Windows AI Foundry, avec un support qui arrivait aussi dans GitHub Copilot et Copilot Studio.
Aucune de ces quatre entreprises n'est d'accord sur grand-chose dès qu'il s'agit d'architecture de modèles, de tarification ou de stratégie de plateforme. Toutes les quatre livrent désormais des produits qui parlent le même protocole pour connecter un agent à un outil. C'est assez rare dans cette industrie pour être la vraie histoire — plus que n'importe quelle fonctionnalité isolée que MCP rend possible.
Pourquoi c'est une question de confiance, pas seulement de plomberie
Cette convergence est vraiment utile, et c'est exactement pourquoi MCP mérite un examen plutôt qu'une confiance aveugle. Un protocole qui rend banale la connexion d'un agent aux systèmes de votre entreprise rend tout aussi banale l'atteinte de ces mêmes systèmes par une connexion mal construite ou mal configurée. MCP lui-même n'empêche pas cela. La spécification définit comment un client et un serveur se parlent — elle ne dit rien sur qui a le droit d'accorder une connexion, ce que cette connexion a le droit de toucher, ou si quelqu'un le remarquera si quelque chose tourne mal. Ces choix appartiennent entièrement à celui qui a construit ou configuré le serveur ou le client précis devant vous. Certains fournisseurs construisent tout cela avec soin. D'autres ne le construisent pas du tout, et le protocole ne les en empêchera pas.
MCP est un protocole de câblage, pas un système de contrôle d'accès. Il standardise la façon dont un agent demande à un outil de faire quelque chose. Que cette demande soit limitée, journalisée et révocable est une décision que quelqu'un a prise — ou pas — par-dessus.
Une liste de contrôle avant d'en connecter un
Avant que votre équipe connecte un serveur MCP — qu'il s'agisse d'un produit de fournisseur, d'un outil open source trouvé sur GitHub, ou de quelque chose construit en interne — six questions séparent une connexion gouvernée d'une porte ouverte. Aucune n'exige de lire la spécification. Elles exigent seulement que quelqu'un demande avant de cliquer sur approuver, et qu'il lise vraiment la réponse que l'écran de connexion renvoie.
| Posez ceci | À quoi ressemble le bon | Surveillez |
|---|---|---|
| Quels périmètres ou tools demande-t-il ? | Détaillé Une liste nommée et précise que vous pouvez lire avant d'approuver — « créer des tâches, lire les messages de ce canal ». | Global « Accès complet au compte » sans liste détaillée de ce qu'il peut réellement faire. |
| Est-il en lecture seule, ou peut-il écrire et agir ? | Séparé Accès en lecture par défaut ; toute action qui modifie des données a besoin de sa propre autorisation visible. | Groupé Accès en écriture inclus automatiquement, sans moyen de dire quelle capacité fait quoi. |
| Est-il par personne ou partagé à toute l'équipe ? | Par personne Chaque personne se connecte avec son propre identifiant ; l'agent ne voit que ce que cette personne peut voir. | Partagé Une clé API ou un compte de service utilisé par toute l'équipe, qui contourne les permissions individuelles. |
| Existe-t-il un journal d'audit de ce qu'il a fait ? | Journalisé Chaque appel d'outil est enregistré — qui l'a connecté, ce qu'il a touché, et quand. | Sans journal Aucune trace au-delà de ce que l'outil d'IA choisit lui-même de vous dire. |
| Peut-il être révoqué instantanément ? | Immédiat Un interrupteur, effectif tout de suite, depuis une page de réglages que vous contrôlez. | Différé La révocation exige un ticket de support, un appel au fournisseur, ou n'est pas possible du tout. |
| La révoquer casse-t-elle autre chose ? | Isolé Limité à cette seule connexion ; la couper n'affecte que celle-ci. | Enchevêtré Partage un identifiant avec d'autres outils, de sorte que révoquer l'un casse discrètement trois autres. |
À quoi ressemble vraiment une connexion bien construite
La propre configuration MCP de FabricLoop est une réponse concrète à cette liste — non parce qu'elle est inhabituelle, mais parce que chaque pièce correspond directement à l'une des six questions ci-dessus, et qu'il vaut la peine de nommer la mécanique réelle plutôt que la version marketing. FabricLoop tient les deux rôles à la fois : c'est un serveur MCP auquel des outils extérieurs se connectent, pour que Cursor, Claude ou ChatGPT puisse créer une tâche, ajouter un commentaire ou lire une note avec les permissions FabricLoop d'une personne précise — et c'est un client MCP qui se connecte vers l'extérieur, pour qu'un canal puisse faire entrer l'application MCP d'un fournisseur, comme GitHub ou Linear, et la @mentionner comme un coéquipier.
Chaque connexion, dans un sens comme dans l'autre, commence par une personne, pas par un espace de travail. Connecter un client externe comme Cursor ouvre un écran de consentement OAuth à app.fabricloop.com/oauth/consent, où cette personne choisit un espace de travail et approuve les tools précis que le client demande — le client ne peut ensuite agir qu'avec les périmètres accordés sur cet écran, sous les permissions de cette seule personne, jamais via un compte de service partagé. Le sens inverse fonctionne de la même façon : un administrateur peut activer l'application MCP d'un fournisseur pour toute l'équipe, mais chaque personne termine quand même sa propre connexion avant que cela fonctionne pour elle, et un administrateur peut mettre cette application en mode lecture seule ou la restreindre à une liste d'autorisation de tools précis, au lieu de tout ce que le fournisseur expose.
Chaque client connecté apparaît sur un écran de réglages à côté d'un contrôle Révoquer qui le déconnecte immédiatement — la page de la personne elle-même, pas un ticket de support. Sur les offres Enterprise, cette activité — y compris les autorisations MCP et ce qu'un agent connecté a réellement fait — arrive dans un journal d'audit qu'une équipe de sécurité peut consulter à la demande, plutôt que dans des captures d'écran tirées d'un fil de discussion après coup.
Rien de tout cela n'est de l'ingénierie exotique. C'est un petit ensemble de décisions, délibérément sans glamour, répété avec constance : limiter le périmètre, l'attacher à une personne, le journaliser, le rendre révocable sans dégâts collatéraux. C'est le même argument que ce site tient plus largement à propos de la Legibility — un accès que l'on peut nommer, journaliser et révoquer vaut mieux qu'un accès auquel personne n'a à penser — et MCP ne livre cela que si quelqu'un le construit ainsi. Le protocole rend la plomberie standard. Il ne rend pas la gouvernance automatique.
La décision qui compte vraiment
MCP ne va pas disparaître, et s'y opposer à ce stade ressemble un peu à s'opposer à l'USB. Chaque grand fournisseur de modèles le livre désormais, la liste des serveurs disponibles continue de grandir, et un agent qui ne peut pas atteindre vos outils est, pour la plupart du travail réel, un agent qui ne peut pas faire grand-chose. La décision intéressante n'est pas de laisser ou non un outil d'IA se connecter à vos systèmes — de plus en plus, une version de cette décision est déjà prise pour vous, une intégration à la fois, tandis que des outils que votre équipe utilise déjà ajoutent discrètement la prise en charge de MCP sous une fonctionnalité sur laquelle vous avez cliqué sans lire les petites lignes. La décision qui vous appartient encore vraiment est ce que vous vérifiez avant de cliquer sur approuver.
MCP a standardisé la façon dont un agent d'IA demande à un outil de faire quelque chose. Il n'a rien fait pour standardiser si cette demande est sûre à accorder — cette part reste, et restera, une décision de la personne qui clique sur « approuver ».