MCP : le problème que le protocole résout

Bienvenue

Depuis 2023, la plupart des entreprises ont franchi une première étape avec l'IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire générative : un assistant conversationnel, un promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire bien tourné, une réponse utile. Cette étape a une limite structurelle qu'on découvre vite en production : un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire, aussi performant soit-il, ne connaît que ce qu'on lui a écrit dans sa fenêtre de contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire. Il ne peut pas, par lui-même, consulter votre CRM, lire un ticket Jira, interroger une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire ou déclencher un déploiement. Pour qu'il agisse réellement dans votre système d'information, il faut lui donner des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire — et un moyen standard de les décrire, de les découvrir et de les invoquer.

C'est exactement le problème que le Model Context ProtocolMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire (MCP) a été conçu pour résoudre. Ce premier chapitre ne présente pas encore la mécanique fine du protocole — cela viendra dans les chapitres suivants — mais pose le problème qu'il règle, montre pourquoi les approches précédentes ne suffisaient pas, et situe MCP par rapport aux alternatives que vous avez peut-être déjà rencontrées : plugins ChatGPT, function callingappel d'outilsIAMécanisme par lequel un modèle produit un appel de fonction structuré que le code environnant décide d'exécuter. Le modèle n'a jamais d'accès direct : il propose, le code dispose.Voir dans le glossaire OpenAI, outils LangChain.

À l'issue de ce chapitre, vous saurez expliquer à un collègue technique pourquoi MCP existe, ce qu'il standardise exactement, et dans quels cas il change réellement la donne pour une architecture d'entreprise.

Du prompt seul à l'agent outillé

Un modèle de langage seul est une fonction : du texte entre, du texte sort. Utile pour rédiger, résumer, traduire, expliquer. Insuffisant dès qu'on veut qu'il agisse — récupérer une donnée fraîche, modifier un enregistrement, appeler une API interne.

La réponse technique à ce manque s'appelle le tool use ou function calling : on décrit au modèle un ensemble de fonctions disponibles (nom, paramètres, description), le modèle décide s'il doit en appeler une, et l'application qui l'héberge exécute réellement l'appel puis renvoie le résultat au modèle. Ce mécanisme existe depuis plusieurs générations de modèles et fonctionne bien à petite échelle.

Le problème apparaît au moment de l'industrialisation. Une entreprise qui veut connecter un assistant IA à dix systèmes internes (ERP, CRM, ticketing, base documentaire, outil de déploiement, annuaire RH...) se retrouve à écrire dix intégrations différentes, chacune avec :

• sa propre description d'outils dans le format attendu par le fournisseur de modèle utilisé ;
• sa propre gestion d'authentification et de permissions ;
• sa propre logique de sérialisation des résultats ;
• sa propre maintenance quand l'API du système interne change.

Si l'entreprise utilise plusieurs fournisseurs de modèles (OpenAI pour un cas d'usage, un modèle open-weight pour un autre, Claude pour un troisième), ce travail se multiplie car les formats de description d'outils diffèrent d'un fournisseur à l'autre. On rejoue, pour l'IA, un problème que l'informatique d'entreprise a déjà connu plusieurs fois : celui de l'intégration point à point.

Le function calling résout déjà la question « comment un modèle appelle-t-il une fonction ». Le problème que MCP adresse est différent : « comment décrire, exposer et découvrir un ensemble d'outils et de ressources de façon indépendante du modèle et de l'application qui l'héberge, pour ne pas réécrire l'intégration à chaque nouvelle combinaison client/serveur ». C'est un problème d'interopérabilité, pas de capacité du modèle.

La fragmentation des connecteurs propriétaires

Avant MCP, chaque écosystème a construit sa propre solution à ce problème d'intégration, avec des périmètres et des garanties différents.

Les plugins ChatGPT (lancés en 2023, puis remplacés par les GPTs et les Actions) permettaient de décrire un service tiers via un fichier de manifeste et une spécification OpenAPI. L'approche fonctionnait, mais restait propriétaire à l'écosystème OpenAI : un plugin ChatGPT ne se réutilise pas tel quel dans un autre produit. De plus, le modèle de découverte reposait sur un magasin de plugins centralisé, peu adapté à un usage interne d'entreprise où l'on veut exposer un outil à un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire maison sans dépendre d'un magasin public.

Le function calling (OpenAI, puis généralisé chez la plupart des fournisseurs, y compris Anthropic) standardise la façon dont un modèle décrit qu'il veut appeler une fonction : un schéma JSON, un nom, des arguments. C'est un progrès réel et un composant que MCP réutilise d'ailleurs en interne. Mais le function calling ne dit rien sur où vivent les outils, comment on les découvre dynamiquement, ni comment on partage l'implémentation d'un connecteur entre plusieurs applications. Chaque application hôte doit coder elle-même le pont entre la sortie du modèle et l'exécution réelle de la fonction.

Les frameworks d'orchestration comme LangChain ont apporté une couche d'abstraction utile côté développeur : une classe Tool, des intégrations prêtes à l'emploi pour des dizaines de services. Mais cette couche reste liée au framework et au langage choisis. Un outil LangChain écrit en Python n'est pas directement utilisable depuis une application Node.js, ni depuis un autre framework d'orchestration. L'abstraction facilite l'écriture côté développeur, elle ne crée pas d'interopérabilité entre systèmes.

L'informatique a déjà vu ce scénario : avant les protocoles standardisés, chaque éditeur de base de données proposait son propre driver propriétaire, jusqu'à l'arrivée d'ODBC et JDBC. Chaque environnement de développement a connu la même fragmentation avant le Language Server Protocol (LSP), qui a permis à un seul serveur de langage de servir plusieurs éditeurs de code. MCP applique la même logique à la connexion entre modèles de langage et systèmes d'information : un contrat unique, plusieurs implémentations interchangeables.

MCP comme contrat d'interface

MCP, porté initialement par Anthropic puis ouvert comme standard communautaire, définit un protocole client-serveur inspiré du Language Server Protocol. Il sépare clairement trois rôles :

• L'hôte (host) : l'application avec laquelle l'utilisateur interagit — un assistant de bureau, un IDE, une application métier interne. C'est l'hôte qui embarque le modèle de langage.
• Le client MCP : le composant, intégré à l'hôte, qui maintient une connexion avec un serveur MCP et traduit les échanges dans les deux sens.
• Le serveur MCP : un programme indépendant qui expose des capacités — outils, ressources, prompts — selon le contrat MCP, sans rien savoir du modèle qui les utilisera.

Le protocole standardise trois types de capacités exposées par un serveur :

1. Tools (outils) : des fonctions que le modèle peut invoquer pour produire un effet ou obtenir une donnée calculée — créer un ticket, lancer une recherche, déclencher un pipeline.
2. Resources (ressources) : des données que l'hôte peut lire et injecter dans le contexte — un fichier, un enregistrement de base de données, le contenu d'une page interne.
3. Prompts : des gabarits de requêtes réutilisables, définis côté serveur, que l'utilisateur ou l'hôte peut invoquer pour lancer un flux de travail standardisé.

Cette séparation est ce qui manquait aux approches précédentes. Un outil de function calling mélange souvent, dans la pratique, l'action et la donnée. MCP distingue explicitement « ce que le modèle peut faire » de « ce que l'hôte peut lire », ce qui permet des politiques de sécurité différenciées : on peut autoriser la lecture d'une ressource sans autoriser l'exécution d'un outil, ou l'inverse.

Ce qui rend le schéma intéressant du point de vue entreprise, c'est le sens de la dépendance : un serveur MCP écrit pour exposer le CRM ne dépend d'aucun hôte particulier. Il peut être branché indifféremment à un assistant de bureau, à un agent de service client ou à un outil interne de reporting, du moment que ces hôtes embarquent un client MCP.

Le gain économique de MCP n'est pas dans la sophistication du protocole, mais dans l'effet de mutualisation : un connecteur écrit une fois pour un système interne (par exemple votre ERP) devient utilisable par tous les agents et applications de l'entreprise qui parlent MCP, sans réécriture. C'est le même raisonnement qui justifie un driver de base de données standardisé plutôt qu'un accès propriétaire par application.

MCP face aux alternatives

Le tableau suivant résume les différences pratiques entre les approches évoquées plus haut.

Il faut néanmoins nuancer : MCP ne remplace pas le function calling, il s'appuie dessus. Concrètement, quand un hôte compatible MCP présente les outils d'un serveur à un modèle, il les traduit dans le format de function calling propre à ce modèle. MCP standardise la couche de transport et de description côté serveur ; le function calling reste le mécanisme par lequel le modèle exprime son intention d'appel. Les deux coexistent, à des niveaux différents de la pile.

De même, MCP n'est pas un concurrent direct de LangChain ou d'autres frameworks d'orchestration d'agents. Un framework d'orchestration peut très bien inclure un client MCP parmi ses moyens de connecter des outils, au même titre qu'il proposait déjà des intégrations propriétaires. Le protocole et le framework opèrent à des niveaux différents : l'un standardise l'interface, l'autre orchestre la logique de l'agent.

Adopter MCP ne dispense pas de concevoir la sécurité, la journalisation et la gestion des permissions de chaque serveur exposé. Le protocole standardise l'interface, pas la politique d'accès. Un serveur MCP mal sécurisé donne à un agent la même capacité de nuisance qu'une API mal sécurisée exposée sans protocole particulier — la standardisation du contrat ne remplace pas une revue de sécurité.

Cas d'usage en entreprise

Quelques scénarios concrets où la logique de MCP change réellement l'équation, comparée à des intégrations point à point :

• Support client outillé : un serveur MCP expose l'outil de ticketing (créer, consulter, mettre à jour un ticket) et une ressource d'historique client. Le même serveur sert l'assistant utilisé par les agents humains en interne et un futur agent autonome de premier niveau, sans double implémentation.
• Ingénierie et DevOps : un serveur MCP encapsule les commandes de déploiement, de consultation de logs et de statut d'incident. Il peut être branché à un assistant dans l'IDE et, plus tard, à un agent de supervision, avec les mêmes garde-fous de permission définis une seule fois côté serveur.
• Connaissance documentaire interne : un serveur MCP expose en lecture seule (ressources, pas d'outils) la base documentaire de l'entreprise, évitant qu'un agent de rédaction obtienne accidentellement des droits d'écriture sur les mêmes systèmes.
• Multi-fournisseur de modèles : une entreprise qui teste plusieurs modèles (pour des raisons de coût, de conformité ou de performance) peut conserver les mêmes serveurs MCP et changer seulement le modèle branché côté hôte, sans retoucher les connecteurs.

Une équipe a d'abord codé un connecteur maison entre son assistant interne et son ERP : appel API, gestion de tokentokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire, parsing de réponse, tout en dur dans le code de l'assistant. Six mois plus tard, une deuxième équipe veut brancher un agent de reporting au même ERP : elle réécrit un connecteur quasi identique, avec ses propres bugs. En migrant vers un serveur MCP unique pour l'ERP, les deux équipes consomment la même implémentation, maintenue à un seul endroit, testée une seule fois.

Ce que ce chapitre ne couvre pas encore

Volontairement, ce chapitre reste au niveau du problème et du positionnement. La mécanique précise du protocole — format des messages JSON-RPC, cycle de vie d'une connexion, modes de transport (entrée standard, HTTP en streaming), gestion fine des permissions et du consentement utilisateur — sera détaillée dans les chapitres suivants, une fois ce cadre de compréhension posé.

Checklist de fin de chapitre

Avant de passer au chapitre suivant, vous devriez pouvoir répondre sans hésiter aux questions suivantes :

• Pourquoi le function calling seul ne suffit pas à standardiser l'intégration d'un agent avec un système d'information d'entreprise ?
• Quelle différence MCP établit-il entre un outil, une ressource et un prompt, et pourquoi cette distinction a une valeur en matière de sécurité ?
• En quoi un serveur MCP diffère-t-il d'un plugin ChatGPT ou d'un outil LangChain en termes de réutilisabilité ?
• Pourquoi MCP ne remplace-t-il ni le function calling ni les frameworks d'orchestration, mais s'articule-t-il avec eux ?

En résumé

MCP ne rend pas un modèle plus intelligent : il standardise la façon dont un modèle, quel qu'il soit, se connecte aux outils et aux données d'une entreprise, quel que soit l'hôte qui l'embarque. Le problème qu'il résout — la fragmentation des connecteurs propriétaires, réécrits à chaque nouvelle combinaison modèle/application — est un problème d'ingénierie logicielle classique, déjà résolu ailleurs par des protocoles comme ODBC ou LSP. La valeur de MCP se mesure à la mutualisation qu'il permet : un connecteur, écrit une fois, servant plusieurs agents et plusieurs générations de modèles. Les chapitres suivants entrent dans la mécanique du protocole lui-même.