L'ère MCP : comment le Model Context Protocol a discrètement remodelé les applis IA en 2026

Anthropic a publié le Model Context Protocol fin 2024. La plupart des gens l'ont rangé sous « encore un standard » et sont passés à autre chose. Dix-huit mois plus tard, MCP est la plomberie de facto de la stack des applis IA. Claude Code est MCP-first. Cursor fait tourner plusieurs serveurs dans une même session. Linear, Figma, Notion, GitHub, Slack et Stripe livrent tous des serveurs officiels. Le protocole a gagné.

Voici un guide pratique doublé d'un état des lieux du protocole. Ce qu'est MCP sur le fil, pourquoi il a battu les standards précédents, les serveurs canoniques en production, ce qu'il faut en faire, et où il flanche encore.

MCP, c'est le câble qui allait enfin à toutes les prises

Le Model Context Protocol permet à n'importe quel client IA de parler à n'importe quel outil ou source de données via un serveur standard. Avant MCP, chaque intégration était sur mesure. Chaque client inventait son propre format d'outil. Chaque outil écrivait un adaptateur maison pour chaque client. Le coût combinatoire était écrasant, et la plupart des builders ont fini par abandonner et coder en dur quelques intégrations.

MCP a fait s'effondrer tout ça. Construisez le serveur une fois, n'importe quel client MCP peut l'utiliser. Construisez le client une fois, n'importe quel serveur MCP devient accessible. La bonne primitive au bon moment, gouvernée au grand jour, avec Anthropic qui fait le travail sur le protocole sans posséder le standard.

Ce qu'est vraiment MCP sur le fil

MCP, c'est du JSON-RPC sur un transport, avec un petit ensemble de primitives standard. Le serveur expose des ressources (les données que le modèle peut lire), des outils (les actions qu'il peut appeler) et des prompts (des modèles que l'utilisateur peut invoquer). Le client parle les mêmes méthodes à chaque serveur : list, read, call. C'est toute l'abstraction.

JSON-RPC est ennuyeux, bien compris, débogable avec curl, et passe à travers tous les pare-feu jamais construits. La séparation des primitives donne au modèle assez de structure pour raisonner sur ce qu'un serveur sait faire, sans forcer le serveur à entrer dans un schéma unique.

Les trois transports et pourquoi ils comptent

MCP circule sur trois transports : stdio, HTTP plus SSE, et WebSockets. Stdio fait tourner le serveur comme processus enfant du client, le choix par défaut des clients desktop comme Claude Desktop. HTTP plus SSE fait tourner le serveur comme un service distant que le client interroge et dont il reçoit les flux, la bonne forme pour les serveurs MCP cloud. WebSockets couvre le cas rare où il faut du full-duplex depuis un serveur distant.

Le transport est surtout un choix de déploiement, pas de capacités. La même logique serveur fonctionne sur les trois. Une équipe peut prototyper en local sur stdio et livrer sur HTTP plus SSE derrière sa passerelle d'authentification sans réécrire la couche protocole.

Pourquoi MCP a gagné là où les standards précédents ont perdu

Les plugins ChatGPT, les specs de function calling et OpenAPI-pour-LLM ont tous tenté de devenir le standard outil-agent. Les trois ont calé. MCP a gagné parce qu'il a choisi la bonne primitive, au bon moment, avec la bonne gouvernance.

Les plugins ChatGPT étaient liés à un seul client et un seul modèle de facturation, et le manifeste supposait des endpoints HTTP sans état avec des specs OpenAPI que presque aucun vrai produit n'expose proprement. Les specs de function calling de chaque labo étaient des formats mono-fournisseur déguisés en standards. OpenAPI-pour-LLM a tenté de transformer après coup un format de documentation en contrat d'exécution, et le décalage d'impédance l'a écrasé.

La bonne primitive : le serveur, pas le plugin

Le choix de MCP de faire de l'intégration un serveur longue durée exposant un contrat typé, plutôt qu'un manifeste de plugin sans état, est la décision d'architecture dont tout le reste découle. Un serveur peut garder des connexions à une base de données, mettre des ressources en cache, gérer des jetons d'authentification, streamer des réponses et livrer des mises à jour sans casser le client. Un plugin sans état ne sait presque rien faire de tout ça. Les vraies intégrations ont besoin d'état, de retries, d'observabilité et de gestion des limites de débit. Les serveurs portent tout ça. Les plugins se battent contre.

Le bon timing : après le tool use, avant la stack d'agents

MCP est sorti pile quand les builders avaient cessé de se demander si le tool use comptait et s'étaient mis à se demander comment brancher dix outils sur un agent sans tout réécrire à chaque release. Le tool use était acté. Le problème suivant était l'orchestration. MCP a donné à la couche d'orchestration une abstraction propre.

La gouvernance a aidé. Anthropic a ouvert la spec, ouvert l'organisation GitHub, accepté les contributions externes dès le premier jour, et laissé d'autres labos implémenter des clients sans demander la permission. À la mi-2026, OpenAI a livré le support MCP dans sa stack Assistants. Gemini le supporte via l'API Gemini. C'est ce grand chapiteau qui a transformé un side project en standard.

Les serveurs MCP canoniques en production

Une courte liste fait le gros du travail. La plupart des stacks d'agents en 2026 sont une combinaison de ces neuf-là.

Figma expose les frames, composants, variables et arbres de calques, si bien que le modèle lit une frame comme un développeur lit une spec. Linear expose les tickets, projets et cycles, et transforme Claude Code en codeur conscient du projet. Notion expose les pages, bases de données et blocs, ce qui en fait le magasin de contexte universel. GitHub expose les dépôts, tickets, pull requests et actions, la surface de contexte de code canonique. Slack expose les canaux, fils et la recherche. Stripe expose les clients, abonnements, paiements et métriques, la façon dont les agents finance et ops lisent les comptes.

Postgres expose les schémas, tables et requêtes avec des périmètres en lecture seule ou en lecture-écriture. Filesystem expose un répertoire en bac à sable, la façon dont Claude Code lit et écrit un dépôt. Browserbase expose une flotte hébergée de Chromium via MCP, la façon dont les agents pilotent un navigateur sans gérer d'infrastructure. Neuf serveurs, quatre-vingt-dix pour cent du travail des agents.

Les clients MCP-first qui font tourner la boutique

Claude Code est le client MCP canonique. Chaque intégration est un serveur MCP. Ajouter un outil, c'est éditer un fichier de config et le pointer vers un binaire de serveur ou une URL. Claude Desktop livre le même modèle avec une interface pour configurer les serveurs par espace de travail. Cursor a ajouté le support MCP début 2026 et fait désormais tourner plusieurs serveurs dans une session, ce qui explique pourquoi le même panneau Cursor qui édite du code peut aussi tirer une frame Figma, créer un ticket Linear et interroger Postgres.

Continue.dev est MCP-first. JetBrains AI a ajouté le support MCP. Zed a livré MCP. Chaque IDE et client IA qui veut être pris au sérieux livre maintenant le support MCP, et les produits sans histoire MCP commencent à faire vieux.

Ce que les designers devraient vraiment faire avec MCP

Arrêtez de faire des captures d'écran de Figma. Exposez vos outils comme un espace de travail MCP. Le serveur Figma MCP donne au modèle de vraies coordonnées de frame, de vraies variables et de vraies instances de composants, au lieu de valeurs de pixels devinées à partir d'une image.

Le geste plus ambitieux, c'est de construire un seul espace de travail MCP. Branchez Figma, Notion et votre dépôt de design tokens dans Claude Code comme trois serveurs. Le même prompt qui demande « construis ce composant selon la spec » lit la frame Figma, récupère le raisonnement dans Notion, consulte le fichier de tokens et écrit le code. C'est la première fois qu'un design system se comporte vraiment comme un artefact continu dans un workflow IA. Le même schéma s'applique aux Claude Skills, où le Skill est la persona et MCP est l'espace de travail.

Ce que les builders devraient vraiment faire avec MCP

Livrez un serveur MCP interne pour chaque outil interne que possède votre équipe. Pointez Claude Code dessus. Regardez le même agent qui écrit du code se mettre à lancer des opérations. Le schéma gagnant en 2026 n'est pas « assistant IA pour X ». C'est « chaque outil que votre équipe utilise, exposé comme serveur MCP, avec un seul client qui orchestre ».

Vous voulez de l'aide pour brancher MCP sur les outils de votre équipe sans perdre un trimestre sur le modèle d'authentification, ou pour livrer une stack de serveurs MCP internes qui tient en production ? Engagez Brainy. ClaudeBrainy livre un template de serveur MCP plus des bibliothèques de prompts, et AppBrainy livre des builds produit complets pour les équipes qui veulent que leurs agents partagent un vrai espace de travail, pas des captures d'écran.

Le build n'a rien de glamour. La plupart des serveurs MCP internes sont une fine couche autour d'une API existante, plus l'authentification, plus une liste de ressources et d'outils. Quelques centaines de lignes de code, et le dashboard de déploiement, le suivi d'erreurs, la console de facturation ou le panneau d'admin de l'équipe devient un outil de plus que l'agent peut utiliser. Dix serveurs plus tard, l'agent est un coéquipier, pas un chatbot.

Là où MCP perd encore

La latence de l'orchestration multi-serveurs, la complexité de l'authentification et l'absence d'une histoire mobile sont les trois endroits où MCP flanche encore, et les démos qui les cachent sont les démos à ignorer.

La latence en orchestration multi-serveurs est réelle. Un prompt qui touche Figma, Notion et Postgres en un seul tour peut payer trois allers-retours avant que le modèle ait assez de contexte pour répondre, et sur des transports plus lents l'attente cumulée dépasse cinq secondes. Le cache aide. Le pooling de connexions aide. Rien de tout ça ne fait disparaître la latence.

La complexité de l'authentification est le deuxième trou. MCP ne standardise pas l'auth. Chaque serveur choisit son propre modèle : OAuth, clés d'API, jetons à portée limitée, parfois rien du tout. Brancher quinze serveurs sur un seul client, c'est quinze magasins d'identifiants, quinze politiques de rafraîchissement et quinze pistes d'audit. La plupart des équipes sous-estiment ça jusqu'à la première fois qu'un serveur de données clients fuit dans un contexte non client.

L'histoire mobile est absente. MCP suppose un client longue durée capable de lancer des processus locaux, de garder des connexions réseau et de gérer le cycle de vie des serveurs. Rien de tout ça ne correspond au modèle d'exécution mobile. Il n'existe pas de MCP-sur-iOS utile à la mi-2026. Une poignée d'équipes travaillent sur des profils 100 % distants, mais le protocole n'en est pas là.

Trois modes d'échec que les démos MCP survendues cachent

La plupart des regrets MCP en 2026 remontent aux trois mêmes trous.

Premièrement. La démo qui balaie l'auth sous le tapis. Le présentateur montre un serveur connecté au CRM d'un client, l'agent répond, applaudissements. L'auth, c'était un jeton personnel du compte de démo. Pointer la même configuration sur un système de production multi-tenant impose de reconstruire l'auth avec des identifiants à portée limitée, des flux OAuth et de l'isolation par tenant. Solution : choisissez le modèle d'auth avant de livrer le serveur, pas après.

Deuxièmement. La démo 100 % locale. Tout marche sur le laptop du présentateur parce que le serveur tourne en stdio avec le système de fichiers local et une base de données personnelle. Rien de tout ça ne se livre à une équipe qui a besoin d'HTTP plus SSE et d'identifiants partagés. Solution : prototypez sur stdio, livrez sur HTTP plus SSE derrière votre passerelle d'auth, et testez l'histoire du déploiement avant que l'équipe ne lui fasse confiance.

Troisièmement. La démo mono-serveur. L'agent utilise un serveur à merveille, le présentateur fait comme si l'orchestration multi-serveurs n'était qu'une ligne de config de plus. En production, le deuxième et le troisième serveur introduisent de la latence, des conflits d'auth et de la confusion dans les prompts. Solution : concevez l'ensemble des serveurs comme un système, pas comme une liste. Documentez les frontières.

Le premier geste selon le rôle

Chaque rôle dans l'équipe a un premier geste différent avec MCP. Le travail n'est pas réparti également.

Le schéma. Les designers et les développeurs frontend portent l'assemblage de l'espace de travail. Les développeurs backend portent le contrat du serveur et le modèle d'auth. Les fondateurs choisissent la voie.

FAQ

Qu'est-ce que le Model Context Protocol ?

MCP est un protocole ouvert qui permet à n'importe quel client IA de parler à n'importe quel outil ou source de données via un serveur standard. Le serveur expose des ressources, des outils et des prompts. Le client parle JSON-RPC sur stdio, HTTP plus SSE ou WebSockets. Anthropic a publié la spec fin 2024, et à la mi-2026 c'est le standard d'intégration outil-agent de facto.

MCP, c'est seulement pour Claude ?

Non. Cursor, Continue.dev, JetBrains AI, Zed et la stack Assistants d'OpenAI supportent tous MCP. Gemini le supporte via l'API Gemini. Anthropic a publié le protocole mais n'en est pas propriétaire.

Dois-je écrire mon propre serveur MCP ?

Probablement pas pour les outils canoniques. Figma, Linear, Notion, GitHub, Slack, Stripe, Postgres, Filesystem et Browserbase livrent tous des serveurs officiels ou canoniques. Vous écrirez le vôtre pour les outils internes, les bases de données maison et les API propriétaires. La plupart des serveurs MCP internes font quelques centaines de lignes de code plus un modèle d'auth.

En quoi MCP diffère-t-il du tool use ?

Le tool use est la capacité côté modèle d'appeler des fonctions avec des entrées et sorties structurées. MCP est le protocole qui définit comment les outils sont découverts, décrits et invoqués depuis n'importe quel client. Le tool use, c'est le moteur. MCP, c'est le câblage. Le guide sur les agents computer use couvre la troisième jambe, quand il n'y a pas d'API propre à appeler.

Quand MCP n'a-t-il pas de sens ?

Quand vous avez un outil, un client et une intégration codée en dur qui marche déjà. Le gain se trouve dans le monde multi-outils, multi-clients. Pour un agent et une API, le tool use classique suffit.

Le basculement que MCP débloque vraiment

MCP n'est pas un agent plus intelligent. C'est le protocole qui a enfin permis aux agents de partager un espace de travail, et les produits qui traitent cet espace de travail comme leur surface centrale gagneront le prochain round.

La plupart des équipes traitent encore les intégrations IA comme une fonctionnalité vissée sur un produit. Les équipes qui prennent de l'avance traitent le client IA plus un ensemble de serveurs MCP comme l'espace de travail, et le produit, c'est ce qui apparaît aux bords. Les premières livrent un onglet de chat de plus. Les secondes livrent un outil que l'équipe utilise vraiment. Le même basculement apparaît dans la comparaison des éditeurs de code IA et dans le décryptage Claude 4.7 pour les builders.

Si votre stack n'a pas d'histoire MCP ce trimestre, les agents que vos clients utilisent vous contourneront. Si elle en a une, ces agents se mettront à traiter votre produit comme un coéquipier. Choisissez le workflow. Livrez le serveur. Branchez l'espace de travail.

Si vous voulez de l'aide pour brancher MCP sur les outils de votre équipe sans perdre un trimestre sur le modèle d'auth, ou pour livrer une stack de serveurs MCP internes qui tient en production, engagez Brainy. ClaudeBrainy livre des packs de Skills et des templates de serveurs MCP. AppBrainy livre des builds produit complets pour les équipes qui veulent que leurs agents partagent un vrai espace de travail, pas des captures d'écran.