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, brancher un modèle d'IA sur les outils d'une entreprise voulait dire une intégration sur mesure pour chaque paire. 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 vérification 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 tout simplement le faire. Pas parce qu'Anthropic a intégré GitHub dans Claude. Parce que quelque part — votre équipe des TI, 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 maintenant vrai aussi de ChatGPT, de Gemini de Google et de Microsoft Copilot. Cette convergence, plus que n'importe quelle mise en ligne d'une fonction isolée, explique pourquoi MCP est devenu ce pour quoi presque tous les fournisseurs d'IA ont passé la dernière année à construire une prise en charge.
Ce qu'est vraiment MCP
MCP veut dire Model Context Protocol. Anthropic l'a conçu, puis a publié la spécification en code source ouvert, avec les premiers SDK, le 25 novembre 2024. Son propre matériel de lancement a décrit l'idée avec une analogie qui est restée : pensez à MCP comme à un port USB-C pour les applications d'IA — un standard de connecteur physique plutôt qu'un câble différent pour chaque accessoire. Au lancement, Anthropic a nommé les premiers adoptants qui intégraient déjà la prise en charge de MCP dans leurs propres produits, dont les entreprises de logiciels d'entreprise Block et Apollo, ainsi que les fabricants 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 l'ordinateur 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 porte un nom que les ingénieurs utilisent sans façon : le problème d'intégration N par M. Disons 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 robot d'assistance interne — et que ces données se trouvent à huit endroits : Slack, GitHub, une base de données Postgres, Salesforce, Notion, Google Drive, Jira et une API interne. Sans protocole partagé, brancher chaque outil sur chaque source de façon utile exige jusqu'à quarante intégrations distinctes — cinq fois huit — chacune avec son propre schéma d'authentification, sa propre gestion des erreurs et son propre fardeau d'entretien chaque fois que l'une de ces API change de forme. Ajoutez un sixième outil d'IA et le nombre passe à quarante-huit. Dans la 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 dans sa base de données Postgres ne construit pas un connecteur Postgres propre à 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 n'importe quel autre agent compatible MCP, sans code supplémentaire. La propre liste d'Anthropic, au lancement, nommait des serveurs déjà prêts pour Google Drive, Slack, GitHub, Git, Postgres et un outil d'automatisation de navigateur appelé Puppeteer. L'idée n'a jamais été qu'Anthropic les construirait tous. C'est que n'importe qui le pouvait, et le catalogue de serveurs disponibles a largement dépassé ce qu'une seule entreprise pourrait assumer en personnel.
Comment le protocole fonctionne vraiment
Une fois le cadrage retiré, MCP est un protocole client-serveur assez simple, volontairement sans éclat. 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 intègre un MCP Client, qui ouvre une connexion directe et avec état vers un MCP Server — un petit programme qui expose un système précis : une base de données, un outil de billets, un système de fichiers, une API interne. Le client et le serveur échangent des messages au format JSON-RPC 2.0, un format léger d'appel de procédure à distance déjà courant dans l'infrastructure existante, sur l'un de deux transports : stdio, quand le serveur est un programme qui tourne localement sur le même ordinateur, ou Streamable HTTP, quand il s'agit d'un service hébergé qui tourne ailleurs.
Ce qu'un serveur peut exposer se résume à trois primitives. Les Tools sont des fonctions que le modèle peut appeler pour poser une action — 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 aller chercher et remettre au modèle sans que celui-ci ait à le demander — le contenu d'un fichier, le schéma d'une base de données, un billet d'assistance. Les Prompts sont des modèles réutilisables déclenchés par la personne — 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 de lui-même. Un serveur bien construit indique clairement lequel des trois il offre pour une capacité donnée, parce que cette distinction est exactement ce qui détermine 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 d'Anthropic seulement. Cela a changé vite, et d'une façon vraiment inhabituelle en IA : des concurrents directs ont convergé vers le protocole d'une seule entreprise plutôt que de publier le leur. OpenAI a ajouté la prise en charge de MCP à son Agents SDK en mars 2025, pour permettre aux développeurs de brancher des flux d'agents sur n'importe quel serveur MCP au lieu de construire des intégrations d'outils sur mesure, propres à OpenAI. Le mois suivant, Google DeepMind a confirmé que Gemini et sa propre trousse de développement d'agents prendraient aussi MCP en charge — un geste que Google a jumelé à son propre protocole complémentaire, Agent2Agent, visant à 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 par ce qu'il appelle Windows AI Foundry, la prise en charge arrivant aussi dans GitHub Copilot et Copilot Studio.
Aucune de ces quatre entreprises ne s'entend sur grand-chose en matière d'architecture de modèles, de prix ou de stratégie de plateforme. Les quatre livrent maintenant des produits qui parlent le même protocole pour brancher un agent sur un outil. C'est assez rare dans cette industrie pour être la vraie histoire — plus que n'importe quelle fonction individuelle 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 trivial le fait qu'un agent se branche sur les systèmes de votre entreprise est un protocole qui rend trivial le fait qu'une connexion mal construite ou mal configurée atteigne ces mêmes systèmes. MCP lui-même ne l'empêche pas. 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 va s'en apercevoir si quelque chose tourne mal. Ces choix appartiennent entièrement à qui a construit ou configuré le serveur ou le client que vous avez devant vous. Certains fournisseurs construisent tout cela avec soin. D'autres ne le construisent pas du tout, et le protocole ne les arrêtera pas.
MCP est un protocole de transmission, pas un système de contrôle d'accès. Il normalise la façon dont un agent demande à un outil de faire quelque chose. Que cette demande soit délimitée, journalisée et révocable est une décision que quelqu'un a prise — ou n'a pas prise — par-dessus.
Une liste de vérification avant d'en connecter un
Avant que votre équipe connecte un serveur MCP — que ce soit le produit d'un fournisseur, un outil à code source ouvert que quelqu'un a trouvé sur GitHub, ou quelque chose construit à l'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 pose la question avant de cliquer sur approuver, et qu'il lise vraiment la réponse que renvoie l'écran de connexion.
| Posez cette question | À quoi ressemble le bon | Surveillez ceci |
|---|---|---|
| Quelles portées ou quels outils 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 vraiment faire. |
| Est-il en lecture seule, ou peut-il écrire et agir ? | Séparé Lecture par défaut; toute action qui modifie des données a besoin de sa propre autorisation visible. | Groupé L'accès en écriture est inclus automatiquement, sans moyen de savoir quelle capacité fait quoi. |
| Est-il par personne ou partagé à toute l'équipe ? | Par personne Chaque personne ouvre une session avec son propre identifiant; l'agent ne peut voir 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 consigné — qui l'a connecté, ce qu'il a touché, et quand. | Non journalisé Aucune trace au-delà de ce que l'outil d'IA lui-même choisit de vous dire qu'il s'est passé. |
| Peut-il être révoqué sur-le-champ ? | Immédiat Un interrupteur, effectif tout de suite, depuis une page de paramètres que vous contrôlez. | Retardé Révoquer exige un billet d'assistance, un appel au fournisseur, ou n'est pas possible du tout. |
| Le révoquer brise-t-il autre chose ? | Isolé Limité à cette seule connexion; la désactiver n'affecte que celle-là. | Enchevêtré Partage un identifiant avec d'autres outils, de sorte que révoquer l'un en brise 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 — pas 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 joue les deux rôles à la fois : c'est un serveur MCP auquel des outils externes se branchent, de sorte que Cursor, Claude ou ChatGPT peuvent créer une tâche, ajouter un commentaire ou lire une note en utilisant les permissions FabricLoop d'une personne précise — et c'est un client MCP qui se connecte vers l'extérieur, de sorte qu'un canal peut faire entrer l'application MCP d'un fournisseur, comme GitHub ou Linear, et la mentionner avec @ 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 outils précis que le client demande — le client ne peut ensuite agir qu'avec les portées accordées sur cet écran, sous les permissions de cette seule personne, jamais avec un compte de service partagé. L'autre direction fonctionne de la même façon : un administrateur peut activer l'application MCP d'un fournisseur pour toute l'équipe, mais chaque personne complète quand même sa propre ouverture de session avant que cela fonctionne pour elle, et un administrateur peut régler cette application en mode lecture seule ou la limiter à une liste d'outils autorisés, au lieu de tout ce que le fournisseur expose.
Chaque client connecté apparaît sur un écran de paramètres à côté d'une commande Révoquer qui le déconnecte immédiatement — sur la propre page de la personne, pas dans un billet d'assistance. Sur les forfaits Entreprise, cette activité — y compris les autorisations MCP et ce qu'un agent connecté a vraiment fait — aboutit dans un journal d'audit qu'une équipe de sécurité peut consulter sur demande, plutôt que dans des captures d'écran tirées d'un fil de clavardage après coup.
Rien de tout cela n'est de l'ingénierie exotique. C'est un petit ensemble de décisions, volontairement sans éclat, répétées de façon constante : en délimiter la portée, l'attacher à une personne, le journaliser, le rendre révocable sans dommages collatéraux. C'est le même argument que ce site avance au sujet de la Legibility plus largement — un accès que l'on peut nommer, journaliser et révoquer bat un accès auquel personne n'a à penser — et MCP ne livre cela que lorsque quelqu'un le construit de cette façon. Le protocole normalise la plomberie. 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. Tous les grands fournisseurs de modèles le livrent maintenant, la liste des serveurs disponibles continue de s'allonger, et un agent qui ne peut pas atteindre vos outils est, pour la plupart du vrai travail, 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 brancher sur vos systèmes — de plus en plus, une version de cette décision est déjà prise pour vous, une intégration à la fois, pendant que les outils que votre équipe utilise déjà ajoutent discrètement la prise en charge de MCP sous une fonction sur laquelle vous avez cliqué sans lire les petits caractères. La décision qui vous appartient encore vraiment, c'est ce que vous vérifiez avant de cliquer sur approuver.
MCP a normalisé la façon dont un agent d'IA demande à un outil de faire quelque chose. Il n'a rien fait pour normaliser si cette demande est sûre à accorder — cette partie reste, et restera, une décision de la personne qui clique sur « approuver ».