MCP, le HTTP des agents IA, expliqué pour les CTO en 2026

MCP, pour Model Context Protocol, est un protocole ouvert publié par Anthropic en novembre 2024 puis transféré à une fondation open source en décembre 2025. Son adoption par les principaux fournisseurs de LLM en 2025 en a fait le standard de fait pour connecter les agents IA à des outils, des sources de données et des fonctions métier.

Pour un CTO, MCP n'est pas un détail technique, c'est une décision d'architecture. Cet article explique pourquoi.

Le problème que MCP résout

Avant MCP, chaque éditeur de LLM exposait sa propre API d'outils. Anthropic avait son tool use, OpenAI son function calling, Google son ADK, etc. Ces formats étaient incompatibles entre eux. Pour qu'un agent puisse changer de modèle, il fallait réécrire tous ses connecteurs, parfois changer la logique d'orchestration. Le coût de migration entre fournisseurs était énorme.

MCP unifie. Un serveur MCP expose ses capacités selon une spécification commune. N'importe quel client (Claude, GPT, Gemini, agent custom) peut s'y connecter sans adaptation. C'est exactement ce que HTTP a fait pour le web : un protocole d'interopérabilité qui survit aux changements d'implémentation.

Quatre raisons pour lesquelles ça compte en 2026

• Adoption massive : les principaux fournisseurs ont adopté MCP entre fin 2024 et mi-2025. Refuser MCP, c'est se couper de l'écosystème.
• Découplage du modèle : un agent qui parle MCP peut basculer de Claude à GPT à Mistral sans réécriture des connecteurs.
• Sécurité par construction : les capacités exposées sont déclarées, scopées, authentifiables via OAuth 2.1. Plus de plomberie ad hoc.
• Découvrabilité : un agent découvre dynamiquement les outils disponibles dans un serveur MCP, sans documentation manuelle.

Ce que MCP n'est pas

MCP est un protocole, pas un framework d'agents. Il décrit comment un agent parle à des outils, pas comment il décide ni comment il mémorise. Confondre MCP avec un framework comme LangChain ou CrewAI est une erreur courante. MCP est une brique d'interopérabilité, complémentaire d'un framework, pas substituable à lui.

MCP ne remplace pas non plus REST. REST reste le protocole de référence pour les humains et les frontends classiques. MCP est optimisé pour les agents IA : descriptions en langage naturel, métadonnées de guidage, schémas JSON enrichis. Une bonne architecture expose les deux en parallèle, depuis la même source de vérité.

Comment commencer

Anthropic publie une spécification de référence et des SDK officiels en TypeScript et Python. Pour un éditeur SaaS, le chemin le plus court est d'exposer les opérations métier les plus utilisées via un serveur MCP minimal, de tester avec Claude Desktop ou un agent custom, puis d'itérer. Compter une à deux semaines pour un MVP fonctionnel.

Pour une organisation qui développe ses propres agents, l'enjeu est différent : il faut décider quelle stratégie adopter pour exposer les capacités internes. Soit MCP, soit REST, soit les deux. Notre recommandation : exposer en MCP toutes les opérations susceptibles d'être pilotées par des agents, et garder REST pour les frontends humains. Les deux peuvent partager la même logique métier sous-jacente.

Sécurité et gouvernance

Comme tout protocole d'exposition de capacités, MCP nécessite une politique d'authentification et d'autorisation rigoureuse. La spécification supporte OAuth 2.1. Les bonnes pratiques sont les mêmes que pour une API REST exposée à des tiers : scopes, audit, rate limiting, segmentation par domaine.

Une bonne pratique trop peu adoptée : organiser les serveurs MCP selon la loi de Conway, c'est-à-dire selon la structure de l'organisation, pas selon l'arborescence technique. Un serveur MCP pour la conformité, un pour la finance, un pour les opérations. Cela facilite la gouvernance des accès et le contrôle des actions par domaine.