Comprendre MCP.

Avant 2024, connecter une IA à tes apps demandait du code custom à chaque intégration. Avant 2026, chaque assistant IA avait sa propre logique de connecteur (plugins ChatGPT, Custom GPT Actions, MCP côté Claude…). En 2026, un seul protocole gagne : MCP. Et il change la donne d'une manière que peu d'utilisateurs perçoivent encore.

MCP signifie Model Context Protocol. C'est un standard ouvert lancé par Anthropic en novembre 2024 qui définit comment un assistant IA (Claude, ChatGPT, Cursor, n'importe lequel) peut accéder à des outils, des données, des services externes. L'analogie qui fait consensus : USB-C de l'IA. Avant USB-C, chaque appareil avait son port propriétaire. Avant MCP, chaque IA avait sa propre logique de connecteur. MCP unifie tout — un serveur MCP construit une fois fonctionne avec tous les assistants compatibles.

L'adoption depuis le lancement est massive et inhabituelle dans le monde de la tech. 2 millions de téléchargements SDK à la sortie en novembre 2024. 97 millions par mars 2026. OpenAI a adopté MCP en avril 2025. Microsoft Copilot Studio en juillet 2025. AWS en novembre 2025. Anthropic a cédé le standard à l'Agentic AI Foundation (Linux Foundation) en décembre 2025 avec OpenAI, Block, Bloomberg, Google, AWS, Cloudflare comme membres fondateurs. Ce n'est plus le standard d'un vendeur — c'est l'infrastructure neutre de l'écosystème IA en 2026.

Cet article est le point d'entrée fondation de la rubrique R2 (Connecter outils). À lire avant les articles suivants (Gmail, Calendar, Drive, Notion, Workspace AI). Il te donne : (1) pourquoi MCP existe et le problème qu'il résout, (2) l'anatomie en host/client/server (en simple, sans jargon dev), (3) l'écosystème 2026 avec qui supporte quoi et les serveurs disponibles, (4) les limites et la roadmap. Plus 5 pièges d'usage. Pas de tutoriel d'installation ici — c'est l'objet des articles 2.2 à 2.7.

Pour comprendre pourquoi MCP a explosé, il faut comprendre le problème qu'il résout. C'est ce qu'on appelle dans la littérature tech le problème N×M : N applications IA × M services externes = N×M intégrations à construire et maintenir.

Concrètement, avant MCP : si tu voulais que 4 assistants IA (ChatGPT, Claude, Cursor, ton agent perso) puissent accéder à 10 services (Gmail, Calendar, Drive, Notion, GitHub, Slack, Stripe, HubSpot, Postgres, Linear), il fallait construire et maintenir 40 intégrations. Chacune avec sa propre logique d'authentification, son propre format de réponse, ses propres erreurs. Et si demain un 5e assistant arrivait, il fallait refaire les 10 intégrations pour lui. Insoutenable à grande échelle.

MCP transforme N×M en N+M. Tu construis une fois un serveur MCP pour ton service (par exemple un serveur MCP pour Gmail). Cet unique serveur est utilisable par tous les assistants compatibles MCP. Réciproquement, un assistant qui parle MCP peut consommer tous les serveurs MCP existants. L'effort de construction et de maintenance s'effondre.

L'analogie technique exacte : MCP est à l'écosystème IA ce que REST a été aux APIs web dans les années 2000. Avant REST, chaque API avait son propre style (SOAP, RPC, formats propriétaires). REST a unifié, et l'écosystème API a explosé. MCP fait pareil pour les connecteurs IA — et l'effet est probablement déjà plus rapide que REST, vu l'adoption en 18 mois.

Pour toi en pratique : la vague des « connecteurs IA partout » qu'on voit en 2026 n'est pas un effet de mode. C'est la conséquence directe de cette unification protocolaire. Avant, brancher Claude sur ton CRM était un projet dev d'une semaine. Aujourd'hui, c'est cliquer sur un connecteur MCP existant ou en lancer un en 5 minutes. La barrière s'est effondrée.

MCP repose sur 3 acteurs en architecture client-serveur. Si tu n'as jamais vu d'architecture distribuée, voici l'image mentale qui suffit : un restaurant (host) avec un serveur de salle (client) qui va chercher en cuisine (server) ce que demande le client. Pas plus complexe.

Un serveur MCP peut exposer 3 types de choses au host. C'est utile à savoir parce que ça structure ce qu'un connecteur peut ou ne peut pas faire :

Tools (outils, fonctions). Des opérations que l'assistant peut déclencher. « Crée un événement Calendar », « Envoie un message Slack », « Exécute cette requête SQL ». C'est l'usage le plus visible. Les tools peuvent être en lecture seule (get-account-history) ou en écriture (create-task) — la distinction compte pour la sécurité (voir Phase 4).

Resources (ressources, données). Des données que l'assistant peut consulter sans déclencher d'action — fichiers, contenu de pages, lignes de base de données, transcriptions. Le client peut récupérer une ressource pour la nourrir au modèle, comme un knowledge file dynamique.

Prompts (modèles de prompts). Des templates de requêtes prédéfinies que le serveur expose pour des cas d'usage récurrents. Moins utilisés que tools et resources en pratique, mais structurants pour des serveurs métier complexes.

L'écosystème host (les assistants qui parlent MCP) est massif et continue de s'étendre. Les acteurs majeurs en 2026 :

Anthropic (côté Claude) : Claude Desktop est le client MCP de référence — c'est sur Claude Desktop qu'a été lancé le protocole en 2024. Claude Code (l'agent CLI) utilise MCP intensivement. Connectors MCP grand public lancés le 13 mars 2026 sur Pro/Max/Enterprise — auparavant réservés aux dev, désormais grand public en quelques clics.

OpenAI (côté ChatGPT) : support MCP intégré dans l'Agents SDK depuis avril 2025. ChatGPT (app grand public) supporte MCP via les Apps et les Custom GPT Actions configurables avec un serveur MCP. Note importante : sur ChatGPT Business/Enterprise, les admins peuvent déployer des connecteurs custom MCP pour des systèmes propriétaires de l'entreprise.

Microsoft (côté Copilot) : Copilot Studio supporte MCP depuis juillet 2025 — permet de construire des agents qui utilisent des serveurs MCP comme sources de connaissances et tools.

Google (côté Gemini) : support MCP dans le Gemini SDK et Gemini CLI. Adoption progressive.

Outils dev : Cursor (MCP natif depuis 2025), Windsurf (Codeium), VS Code via extensions, Sourcegraph Cody, Continue.dev, Goose (Block). C'est dans le monde dev que MCP a été adopté en premier — usage le plus mature.

L'autre côté de l'écosystème : les services accessibles. Plus de 10 000 serveurs MCP publics actifs en 2026, avec 3 catégories utiles à distinguer.

Côté utilisateur, tu n'écris jamais de code MCP. Tu installes des serveurs MCP préconstruits. Sur Claude Desktop, le flow typique en 2026 ressemble à ceci :

Tu colles ce JSON dans le fichier de config, tu redémarres Claude Desktop, et les 3 serveurs sont accessibles. Quand tu demandes « Lis le README de mon repo X et résume-moi les changements de la semaine dernière », Claude utilise le serveur GitHub. Quand tu dis « Combien de clients ont signé en mars dans la base ? », il utilise le serveur Postgres. Tu n'écris pas de code, pas de SQL, pas d'appel API — juste du langage naturel.

Variante simplifiée 2026 : les Connectors MCP de Claude Desktop (mars 2026) ajoutent une UI graphique pour configurer les serveurs MCP sans toucher au JSON. Pour ChatGPT Enterprise, les admins déploient des connecteurs MCP centralisés que les utilisateurs sélectionnent dans une liste. La friction d'usage continue de baisser.

MCP n'est pas magique. Il a des limites réelles à connaître pour ne pas être déçu. Et une roadmap 2026 qui clarifie où ça va.

Limite 1 — La sécurité reste à ta charge. Une étude académique d'avril 2025 a documenté plusieurs risques de sécurité (injection de code malveillant via connecteurs MCP, exfiltration de données via serveurs malicieux). MCP est un protocole, pas un firewall. Installer un serveur MCP = donner à l'assistant l'accès au service correspondant. Si le serveur est mal configuré ou malveillant, l'assistant peut faire des dégâts. Article 2.8 traite cette sécurité en profondeur.

Limite 2 — Qualité variable des serveurs communautaires. Sur 10 000+ serveurs MCP publics, la majorité sont expérimentaux. Certains sont production-ready (officiels Anthropic, ceux des grands éditeurs SaaS), d'autres ont des bugs, des fuites, ou ne sont plus maintenus. Discipline : audit avant installation.

Limite 3 — Configuration toujours technique pour serveurs custom. Pour des serveurs préconstruits, la config est simple (UI ou JSON minimal). Mais construire ton propre serveur MCP pour ton service interne demande des compétences dev (TypeScript, Python, ou autres SDK officiels). Pour un solo non-dev, c'est encore une barrière — bien que des plateformes managées (Truto, mcp.run, mcp.natoma.ai) émergent pour exposer une API existante en MCP sans coder.

Limite 4 — Synchrone uniquement (pour l'instant). En 2026, toutes les interactions MCP sont synchrones (request/response immédiat). Pas d'opérations longues asynchrones. Si tu veux qu'un assistant lance une analyse de 20 minutes et continue à travailler en attendant, ce n'est pas possible nativement (la primitive Tasks est sur la roadmap 2026 mais pas livrée).

Limite 5 — Pas adapté pour des workflows multi-étapes complexes. MCP est excellent pour des opérations atomiques (lire X, créer Y). Pour des workflows orchestrés multi-services avec logique conditionnelle, retry, et états intermédiaires, les outils no-code dédiés (Zapier, Make, n8n) restent plus adaptés. MCP ne remplace pas ces outils — il les complète. Voir la rubrique R4 sur les automatisations durables.

Le steering committee MCP a publié sa roadmap 2026 en mars. Trois évolutions importantes annoncées :

(1) Transport stateless HTTP en review — permettra aux serveurs MCP de scaler horizontalement derrière des load balancers standards. Critique pour des déploiements entreprise à grande échelle.

(2) Primitive Tasks pour les opérations asynchrones longues. Un assistant pourra dispatcher un job de 20 minutes et poller pour la complétion. Essentiel pour les agents persistants always-on (sujet R3).

(3) Open governance renforcée sous l'Agentic AI Foundation. Standards transparents, processus de décision communautaire, contributions externes facilitées. Renforce le statut de standard ouvert vs propriétaire.

Ce qui n'est pas (encore) sur la roadmap visible : un protocole agent-to-agent (A2A) complémentaire est en préparation séparée — il connecterait les agents entre eux, MCP les connectant aux outils. À surveiller en 2026-2027.