IAAgents IA

Le Model Context Protocol : comment les LLM se connectent vraiment aux outils externes

Le Model Context Protocol définit la façon dont un modèle de langage communique avec des outils et des sources de données extérieures à son contexte natif. Comprendre sa mécanique concrète permet de distinguer les intégrations solides des bricolages fragiles, et d'évaluer sérieusement les projets d'automatisation que l'on vous soumet.

Le Model Context Protocol, souvent abrégé MCP, est un standard ouvert proposé par Anthropic (éditeur de Claude) en fin 2024 pour formaliser la communication entre un modèle de langage et les systèmes externes qu'il est censé utiliser : bases de données, APIs, fichiers, applications métier. La confusion autour de ce sujet est réelle. Beaucoup de professionnels ont entendu parler d'"agents IA" capables de "se connecter à tout", sans jamais comprendre ce que cela implique techniquement ni pourquoi cela échoue aussi souvent en production. MCP est précisément la réponse à cette question.

Pourquoi cela change quelque chose pour les professionnels non techniques

Avant MCP, chaque équipe qui voulait connecter un LLM à un outil externe fabriquait son propre pont. Une entreprise qui reliait GPT-4 à Salesforce écrivait du code spécifique à cette paire. Si elle voulait ensuite connecter le même modèle à son ERP ou à un entrepôt de données, elle recommençait depuis zéro. Le résultat : des intégrations fragiles, difficiles à maintenir, impossibles à transférer d'un modèle à l'autre.

MCP propose une interface standardisée. Un outil qui expose ses fonctionnalités via MCP peut être utilisé par n'importe quel modèle compatible, sans réécriture. C'est la différence entre un câble USB-C universel et une collection de connecteurs propriétaires.

Pour un responsable métier ou un chef de projet, cette distinction a des conséquences directes. Si votre prestataire construit une intégration IA sur une architecture ad hoc, vous dépendez de lui pour toute évolution. Si l'intégration respecte MCP, vous conservez la possibilité de changer de modèle, d'ajouter des outils ou de faire auditer le système par une équipe externe. La question à poser lors d'un comité de pilotage est donc simple : cette architecture respecte-t-elle un standard ouvert, ou sommes-nous en train de construire un silo de plus ?

Comment cela fonctionne concrètement

MCP repose sur une architecture client-serveur. Le modèle (ou l'application qui l'orchestre) joue le rôle de client MCP. Les outils externes sont exposés via des serveurs MCP. La communication entre les deux suit un protocole défini : le client découvre les outils disponibles, envoie des requêtes structurées, reçoit des résultats typés.

Prenons un exemple précis. Une entreprise déploie un assistant IA pour ses équipes commerciales. L'assistant doit pouvoir consulter les opportunités ouvertes dans Salesforce, vérifier des délais de livraison dans l'ERP et créer des tâches dans Notion. Sans MCP, trois connecteurs sur mesure. Avec MCP, trois serveurs MCP distincts, chacun exposant ses fonctions selon le même format. L'assistant envoie une requête du type "liste les opportunités en phase de négociation depuis plus de 30 jours" au serveur MCP Salesforce. Ce serveur traduit la requête en appel API Salesforce, récupère les données et les renvoie au modèle dans un format structuré que celui-ci peut exploiter directement dans sa réponse.

Ce qui distingue MCP d'une simple intégration API classique, c'est la couche de description des capacités. Chaque serveur MCP déclare ce qu'il sait faire, quels paramètres il accepte, quels types de résultats il retourne. Le modèle lit cette description et sait quand et comment appeler l'outil, sans que cela soit codé en dur dans le prompt. C'est ce qui rend les agents IA véritablement composables : ils découvrent les outils disponibles à l'exécution plutôt que de les connaître par cœur à l'entraînement.

En juillet 2026, les principaux éditeurs d'outils d'entreprise, dont Atlassian, Block et plusieurs fournisseurs de bases de données vectorielles, ont publié des serveurs MCP officiels. Microsoft a intégré le support MCP dans Copilot Studio. La dynamique d'adoption est réelle, même si l'écosystème reste jeune.

La question des permissions et de la sécurité

Un point souvent négligé : MCP inclut un modèle de permissions. Le serveur MCP contrôle ce que le modèle est autorisé à faire. Lire des données, oui. Modifier des enregistrements, seulement si la permission est explicitement accordée. Supprimer, peut-être jamais. Cette granularité est indispensable dès qu'un agent opère sur des systèmes de production. Un assistant qui peut à la fois lire et écrire dans un CRM sans contrôle humain intermédiaire est un risque opérationnel, pas un gain de productivité.

Quand utiliser MCP, et quand s'en méfier

MCP a du sens dans trois situations. La première : vous construisez un agent ou un assistant qui doit interagir avec plusieurs systèmes hétérogènes, et vous voulez que cette architecture soit maintenable sur deux ou trois ans. La seconde : vous avez plusieurs équipes qui développent des intégrations IA sur des outils différents et vous voulez éviter la duplication de travail. La troisième : vous voulez pouvoir changer de modèle de langage (passer de Claude à GPT-5 ou à un modèle open source) sans tout réécrire.

En revanche, MCP n'est pas la réponse à tout. Pour une intégration simple, ponctuelle, entre un seul LLM et un seul outil, l'overhead de mettre en place un serveur MCP peut ne pas valoir l'effort. Une requête directe à une API avec un prompt bien conçu peut suffire. MCP prend tout son sens à l'échelle, pas pour un prototype de deux semaines.

Il faut aussi garder à l'esprit qu'Anthropic reste l'initiateur du standard. Le protocole est open source et d'autres acteurs contribuent, mais il serait inexact de le présenter comme un standard de l'industrie entériné par un organisme de normalisation indépendant. Son adoption large en 2025 et 2026 lui confère une légitimité de facto, mais la convergence autour d'un standard unique n'est pas encore totalement stabilisée. OpenAI, par exemple, a développé des mécanismes de "function calling" et de "tool use" qui coexistent avec MCP sans en adopter formellement toute l'architecture.

Pour un professionnel qui évalue un projet d'automatisation IA, la bonne posture est de demander comment les outils sont exposés au modèle, qui contrôle les permissions, et quelle est la stratégie si le modèle change dans dix-huit mois. MCP est aujourd'hui la réponse la plus sérieuse à ces trois questions. Ce n'est pas une garantie de succès, mais c'est un signe que l'équipe technique a réfléchi à la durabilité de ce qu'elle construit.

Vous avez lu cet article ?

Validez votre lecture pour gagner de l’XP et alimenter votre radar.