Introduction à MCP : de la fragmentation aux serveurs d’outils partagés
Pourquoi le collage de contexte échoue, comment les appels de fonction ont aidé, pourquoi les intégrations N×M sont problématiques, et comment MCP fait évoluer une pile LLM vers des serveurs d’outils partagés réutilisables N+M.
Sources: Introduction To MCP: Connecting LLMs to the Real World
Que se passerait-il si un modèle de langage pouvait se connecter au monde réel, communiquer avec lui et y agir ? MCP est le lien entre l’intelligence et l’action.
ChatGPT a été lancé le 30 novembre 2022, à la fin de l’année 2022, et a accéléré l’utilisation généralisée de l’IA dans des domaines tels que la productivité, les tâches quotidiennes et la résolution de problèmes. Les fournisseurs ont ensuite intégré l’IA dans des produits déjà utilisés par les gens : suites de productivité, applications de messagerie, outils de recherche, environnements de développement intégrés et logiciels d’entreprise. Les assistants n’étaient plus uniquement des chatbots indépendants.
Un problème plus difficile est apparu par la suite. Les modèles peuvent raisonner et écrire, mais pour effectuer un travail significatif, il faut le bon contexte, des données, des outils et des systèmes adaptés. Associer ces éléments nécessitait généralement des intégrations sur mesure, des API, des mécanismes d’authentification et du code spécifique à chaque outil. Ce phénomène a un nom : la fragmentation.
Le problème de la fragmentation
La fragmentation se manifeste lorsque les équipes adoptent de nombreux assistants IA, chacun enfermé dans son propre écosystème.
Imaginez un développeur dans VS Code. L’assistant intégré à l’éditeur comprend le répertoire de travail en son sein. Dès qu’il a besoin d’issues GitHub ou de pages Confluence en dehors de l’IDE, il quitte l’assistant, copie le texte, le colle à nouveau et espère que le modèle dispose de suffisamment de contexte.
Ces changements constants d’outil et ce transfert manuel de contexte constituent une fragmentation : le modèle est intelligent, mais il ne perçoit pas automatiquement tous les systèmes nécessaires à la tâche.
Que signifie « contexte »
Le contexte, c’est tout ce que le modèle peut voir lorsqu’il répond. En pratique : tout ce que le LLM utilise pour structurer une réponse — souvent l’historique de conversation ainsi que tout ce que l’utilisateur a collé.
Exemple : création d’une fonctionnalité de sécurité avec ChatGPT. Un développeur pourrait :
- JIRA — copier les exigences et les critères d’acceptation dans la conversation.
- GitHub — coller les implémentations et les répertoires associés.
C’est seulement alors qu’ils posent la vraie question. Le modèle répond mieux — mais le processus est coûteux :
- La copie-collage manuelle entre systèmes est lente.
- Le contexte se disperse ; les développeurs deviennent des API humaines.
- Le temps de mise en place peut dépasser le temps de développement.
- Plus il y a de sources, moins le processus est scalable ; les systèmes réels sont plus vastes qu’un buffer de collage.
Ces difficultés ont contribué à l’émergence des appels de fonctions/outils au milieu de 2023 (le travail d’OpenAI).
Appel de fonctions
L’appel de fonctions permet à un modèle d’accéder à des ressources externes via des fonctions et d’utiliser les résultats comme contexte. Le simple chat a laissé place à l’automatisation de tâches : le modèle choisit un outil, l’application le lance, puis le modèle continue.
Avec des outils définis pour JIRA, GitHub, MySQL, Drive, Slack, etc., le modèle peut choisir ce qu’il faut invoquer à partir d’une demande de l’utilisateur, récupérer le contexte et répondre — sans avoir à recopier manuellement les informations.
Limites de l’appel de fonctions par application
Imaginez trois assistants IA au sein d’une même entreprise. Chacun a encore besoin de ses propres fonctions/intégrations pour les bases de données, GitHub, JIRA, Slack et autres outils similaires.
Si vous disposez de N assistants et M ressources externes, vous risquez N × M intégrations. Dix assistants × vingt ressources ≈ deux cents liens personnalisés. La croissance rend la création et le maintien de ce réseau coûteux.
Si chaque application reste propriétaire de chacune de ses intégrations, la fragmentation ne fait que se déplacer : les difficultés liées à l’assemblage contextuel deviennent alors des problèmes d’intégration.
Pourrait-on passer de N × M à N + M ? C’est là que le MCP entre en jeu.
Model Context Protocol (MCP)
MCP est un protocole ouvert qui standardise la manière dont les applications d’IA se connectent à des outils, des données et des services externes.
Deux rôles principaux :
- Client MCP — présent dans l’application/agent d’IA, il se connecte à un serveur et découvre serta utilise les outils/ressources mis à disposition.
- Serveur MCP — il fait le lien entre l’application d’IA et GitHub, JIRA, une base de données, Drive, Slack ou tout autre service.
Le client et le serveur communiquent via MCP. Au lieu que chaque assistant invente son propre adaptateur de fournisseur, les applications découvrent et appellent des fonctionnalités à travers un format unique.
Appel de fonction vs MCP — exemple météo
1. Appel de fonction
Vous définez une fonction locale à l’application qui communique avec l’API météo :
import requests
def get_weather(city):
response = requests.get(
"https://api.weather.com/current",
params={"city": city}
)
return response.json()
Vous enregistrez cette fonction en tant qu’outil. L’utilisateur demande : « Quel temps fait-il à Bengaluru ? » Le modèle peut alors appeler get_weather("Bengaluru"). L’application exécute cette fonction, renvoie les données, et le modèle complète la réponse.
L’équipe de l’application est responsable de la définition et de la maintenance de cette fonction ainsi que des éléments d’interface avec l’API.
2. MCP
Les informations météo se trouvent sur un serveur MCP qui communique avec l’API et expose un outil standard :
@mcp.tool()
def get_weather(city: str):
"""Get the current weather for a city."""
return weather_api.get_current_weather(city)
L’application IA est un client MCP qui découvre la fonction get_weather. Même question de l’utilisateur → découverte/invoquée via MCP → utilisation du résultat dans la réponse.
La différence : le standard MCP normalise l’échange entre l’application IA et les capacités disponibles, permettant ainsi à un seul serveur de servir de nombreux clients compatibles.
Avantages du MCP
- Maintenance moins répétitive que les catalogues de fonctions par application
- Costs et temps consacrés à l’intégration réduits
- Bordures de sécurité plus claires au niveau du serveur
- L’échelle des intégrations est proche de N + M plutôt que de N × M
C’est là la raison. Les sections suivantes abordent l’architecture, les aspects internes et la mise en œuvre pratique.
Repassage en revue du fonctionnement des fonctionnalités de sécurité
Revenons au développeur qui crée une fonctionnalité de sécurité. Sans MCP ou d’outils adaptés, sa journée se transforme en quête effrénée à travers JIRA, GitHub, MySQL, Drive et Slack. Chaque étape nécessite de copier du contexte. Avec les appels de fonctions, ces étapes deviennent des fonctions nommées que le modèle peut invoquer — mais chaque assistant au sein de l’entreprise doit néanmoins disposer de sa propre copie des intégrations.
MCP élimine cette duplication. Un seul serveur météo, un seul serveur JIRA et un seul serveur GitHub peuvent servir de nombreux clients compatibles avec MCP. Le réseau N×M ressemble alors davantage à N clients plus M serveurs.
Notes de conception que les équipes négligent
Considérez les descriptions des outils comme du texte publicitaire : des noms clairs et des documents de paramètres permettent de choisir le bon modèle. Placez les outils d’écriture derrière une étape de confirmation et séparez les serveurs des outils de catalogue en lecture seule. Enregistrez les appels aux outils avec des IDs de corrélation afin que toute réponse incorrecte puisse être attribuée à une récupération défaillante, et non au « modèle » de manière abstraite.
Lorsque vous comparez les appels de fonctions et MCP pour un nouveau système, demandez qui est responsable du cycle de vie de l’intégration. Si la réponse est « chaque équipe produit, à jamais », les serveurs partagés de MCP se rentabilisent d’eux-mêmes. Si la réponse est « une démo temporaire », une fonction locale suffit.
Que vient ensuite
Lorsque la motivation est claire — fragmentation, assemblage de contextes et problèmes d’intégration — le travail suivant concerne l’architecture : comment les clients découvrent les outils, comment les serveurs s’authentifient, comment les sessions transmettent les résultats, et comment déployer un premier serveur en production. Ces sujets méritent des analyses approfondies dédiées ; le but de cet article était de rendre l’« pourquoi » indéniable et de montrer l’exemple météorologique sous les deux angles.
La fragmentation en tant que problème budgétaire
Comptez les heures que votre équipe passe à copier du contenu de JIRA et GitHub dans des chats. Ce travail représente une charge supplémentaire pour chaque assistant IA que vous adoptez. Les appels de fonctions réduisent le temps de copie, mais augmentent la quantité de code d’adaptation nécessaire. MCP vise à orienter ces dépenses vers des serveurs partagés plutôt que vers des versions distinctes pour chaque assistant.
Rédigez l’argumentaire économique en ces termes : moins d’heures humaines consacrées aux API, moins d’intégrations redondantes, des points d’audit plus clairs. Pour les services financiers, les diagrammes architecturaux ont moins d’importance que le tableau de calcul N×M.
Points clés concernant les exemples météorologiques pour les évaluateurs
Dans le parcours de appel de fonction, le client HTTP météorologique se trouve dans l’application. Dans le parcours MCP, il se trouve sur un serveur que d’autres applications peuvent réutiliser. Même phrase de l’utilisateur, mais propriété différente de l’intégration. Privilégiez le serveur lorsque un deuxième client est déjà prévu ; privilégiez la fonction locale si l’expérience est abandonnée au prochain sprint.