Anthropic's Model Context Protocol a gagné : comment MCP est devenu le standard universel pour l'intégration d'outils IA

En novembre 2024, Anthropic publiait une spécification baptisée Model Context Protocol — un standard ouvert pour connecter les modèles d’IA à des outils externes, sources de données et services. À l’époque, cela ressemblait à un énième format d’intégration propriétaire. Mi-2026, toutes les grandes plateformes d’IA l’avaient adopté. MCP avait résolu le problème de fragmentation qui bridait silencieusement les agents IA : l’impossibilité de partager des intégrations d’outils entre modèles et environnements d’exécution.

Ce qu’est vraiment MCP

MCP est un protocole client/serveur bâti sur JSON-RPC 2.0. Un MCP server expose des capacités — outils, ressources et prompts — via une couche de transport (stdio pour les processus locaux, HTTP/SSE pour les services réseau). Un MCP client, embarqué dans un hôte IA comme Claude, Copilot ou Cursor, découvre et invoque ces capacités à l’exécution.

Le protocole définit trois types primitifs :

• Tools — des fonctions appelables que le modèle peut invoquer, avec des définitions typées d’entrée/sortie en JSON Schema. Par exemple : github.create_pull_request, postgres.run_query, slack.send_message.
• Resources — des données structurées que le modèle peut lire, identifiées par une URI. Un fichier, une ligne de base de données, un événement de calendrier.
• Prompts — des modèles de prompts réutilisables et paramétrables que le serveur expose pour les tâches courantes.

La conception indépendante du transport est intentionnelle. Un MCP server s’exécutant localement communique via stdin/stdout. Le même serveur déployé en microservice bascule vers HTTP avec Server-Sent Events pour le streaming. Le client ne se soucie pas du transport utilisé.

La chronologie d’adoption qui a tout changé

Anthropic a open-sourcé MCP et publié des SDK en Python et TypeScript en même temps que la spécification. Les premiers adoptants viennent des outils de développement : Cursor, Zed et Continue ont intégré MCP en quelques semaines, donnant à leurs utilisateurs l’accès à un catalogue croissant de serveurs pour GitHub, les systèmes de fichiers, les bases de données et la recherche web.

Le point d’inflexion est arrivé début 2025 quand OpenAI a annoncé le support natif de MCP dans la Responses API et son framework d’agents. Cette décision signalait que MCP n’était pas une fonctionnalité propre à Claude — c’était une infrastructure. Google a suivi avec l’intégration MCP de Gemini dans Google AI Studio et Vertex AI, permettant aux agents Gemini de consommer le même catalogue de serveurs que les utilisateurs de Claude construisaient. Microsoft Copilot Studio a ajouté le support du connecteur MCP, laissant les équipes exposant des API internes comme MCP servers sans écrire de code de plugin personnalisé.

À la mi-2026, le registre des MCP servers comptait plus de 2 000 serveurs maintenus par la communauté et les fournisseurs. AWS, Azure et GCP ont chacun publié des MCP servers propriétaires pour leurs services principaux. Stripe, Linear, Notion et Atlassian ont livré des intégrations officielles. L’écosystème qui avait mis des années à se construire autour des API REST se reconstruisait autour de MCP en quelques mois.

Pourquoi MCP a gagné face aux alternatives

Avant MCP, chaque plateforme d’IA avait son propre format d’appel d’outils. OpenAI avait le function calling avec son propre dialecte JSON Schema. LangChain avait des Tools avec des définitions de classes Python. Semantic Kernel avait des plugins avec des descripteurs OpenAPI. Chaque écosystème obligeait à réécrire les intégrations depuis zéro en changeant de modèle ou d’environnement d’exécution.

MCP a gagné pour trois raisons :

• Il est véritablement ouvert. La spécification est sous licence MIT et gouvernée indépendamment. Aucun fournisseur ne contrôle la feuille de route unilatéralement. Cela a rendu l’adoption politiquement sûre pour OpenAI et Google, qui n’auraient pas livré un protocole enfermant les utilisateurs dans l’écosystème d’Anthropic.
• Il est plus simple que les alternatives. Un MCP server est un processus qui parle JSON-RPC. Pas besoin de framework, de manifeste de plugin ni de spécification OpenAPI. Un serveur fonctionnel en Python représente environ 30 lignes de code avec le SDK officiel.
• L’indépendance vis-à-vis du transport supprime les frictions de déploiement. Le même binaire serveur fonctionne dans un environnement de développement local et dans un cluster Kubernetes. Cette prévisibilité compte pour les équipes d’entreprise avec des exigences strictes de réseau et de sécurité.

Ce que ça donne en pratique

Un développeur qui construit un agent de support client aujourd’hui n’écrit pas de code de glue d’appel d’outils personnalisé pour chaque modèle qu’il veut supporter. Au lieu de cela, il exécute un MCP server qui expose son CRM, son système de tickets et sa base de connaissances comme outils et ressources. N’importe quel hôte IA compatible MCP — Claude, GPT-4o, Gemini — peut alors utiliser ces outils sans modification.

Prenons une stack concrète. Une équipe déploie :

• Un MCP server enveloppant leur base PostgreSQL, exposant run_query et list_tables comme outils
• Un MCP server pour leur dépôt GitHub, exposant la gestion des issues et la création de PR
• Un MCP server pour Slack, exposant la messagerie par canal et la lecture de threads

Leur agent IA — tournant sur le modèle qui donne les meilleurs résultats pour leur charge de travail — découvre les trois serveurs au démarrage via un fichier de configuration et peut appeler n’importe quel outil de n’importe quel serveur lors d’une session de raisonnement. Passer de Claude à Gemini ne casse aucune intégration. C’est la valeur pratique que MCP apporte.

Le changement d’expérience développeur

Le modèle mental a changé pour les développeurs qui construisent des produits alimentés par l’IA. Auparavant, les intégrations étaient spécifiques au modèle : vous construisiez pour le function calling d’OpenAI, ou pour l’utilisation d’outils de Claude, et le portage entre les deux signifiait réécrire les schémas et le code de glue. Maintenant, les intégrations sont spécifiques aux capacités : vous construisez un MCP server une fois, et tout runtime IA conforme peut l’utiliser.

Ce changement a des conséquences pratiques sur la façon dont les équipes structurent leur infrastructure IA. Les MCP servers sont désormais une couche distincte dans la stack — séparée de l’application, déployée séparément, versionnée séparément. Les équipes construisent des catalogues internes de MCP servers comme elles construisaient auparavant des catalogues d’API internes. La discipline de conception d’API — contrats clairs, versionnage, documentation — est appliquée aux intégrations d’outils IA pour la première fois.

Sécurité et autorisation

MCP 1.1, publié au T1 2026, a ajouté une couche d’autorisation OAuth 2.1 pour les serveurs HTTP. Un MCP client peut désormais négocier des tokens d’accès avec des scopes avant d’appeler des outils sur un serveur distant. Cela répondait à la principale objection des entreprises aux premiers déploiements MCP : que n’importe quel modèle connecté pouvait appeler n’importe quel outil sans contrôle d’accès granulaire. Avec les flux OAuth 2.1 standardisés dans la spécification, les déploiements MCP en entreprise sont désormais viables sans middleware de sécurité personnalisé.

Pistes d’action

Si vous construisez des produits alimentés par l’IA en 2026, MCP n’est plus une infrastructure optionnelle à évaluer — c’est la couche d’intégration par défaut. Voici ce qu’il faut faire :

• Auditez vos intégrations d’outils existantes. Tout schéma de function calling personnalisé que vous maintenez pour un modèle spécifique est désormais une dette technique. Migrer vers un MCP server vous donne la portabilité sur tous les modèles conformes.
• Vérifiez le registre avant de construire. Le catalogue de MCP servers sur modelcontextprotocol.io contient probablement un serveur maintenu pour l’API dont vous avez besoin. Stripe, GitHub, Postgres, Slack et Google Drive ont tous des serveurs propriétaires.
• Construisez des MCP servers comme des produits internes. Traitez votre MCP server comme vous traitez une API interne : versionnez-le, documentez-le et donnez-lui un modèle de propriété clair. Les équipes qui investissent dans un catalogue MCP interne bien conçu verront cet investissement se multiplier à chaque fonctionnalité IA qu’elles livrent.
• Utilisez le flux OAuth 2.1 pour tout ce qui est en production. Les serveurs locaux en stdio conviennent pour le développement. Tout MCP server exposé à un agent IA en production doit nécessiter un accès authentifié et avec des scopes.

MCP n’a pas gagné parce qu’Anthropic l’a bien marketé. Il a gagné parce que le problème qu’il résout — la fragmentation des outils IA — était réel et coûteux, et que la solution était assez simple pour que les concurrents n’aient aucun intérêt à construire autre chose. Cette combinaison échoue rarement.