Le Model Context Protocol (MCP) : un modèle pour exposer données et fonctions métiers à des agents IA externes tiers

La vague des agents IA transforme déjà la manière dont les entreprises travaillent. Qu’il s’agisse d’assistants internes, d’agents connectés aux systèmes métiers, ou d’IA capables d’automatiser des workflows complexes, un point revient systématiquement : comment donner à l’IA accès aux données et outils de l’entreprise… sans reconstruire une intégration sur mesure à chaque fois ?

C’est exactement le rôle du Model Context Protocol (MCP), un protocole ouvert développé à l’origine par Anthropic, rapidement adopté par OpenAI, Microsoft, Google DeepMind, Cloudflare et de nombreux acteurs technologiques.

Son ambition tient en une phrase :

“Standardiser la connexion entre vos systèmes internes et n’importe quel agent IA.”

Dans cet article, on va voir ce que fait réellement MCP, comment il fonctionne, et pourquoi il devient une brique essentielle dans une architecture agentique moderne.

Comprendre MCP : un standard unique pour relier IA et systèmes métiers

Un protocole pour exposer vos outils, données et fichiers

Le Model Context Protocol est un protocole d’échange basé sur JSON-RPC*.

Son rôle : créer une interface unique permettant à un agent IA (Claude, ChatGPT, un agent interne, une application métier…) d’interagir avec des serveurs MCP installés dans votre organisation.

Ces serveurs MCP exposent :

• des tools → fonctions métiers (créer une facture, retrouver un client, mettre à jour un ticket…)
• des ressources → données, fichiers, documents, extraits de base de données
• des prompts → instructions prêtes à l’emploi pour vos équipes

Ce découpage est standardisé. Autrement dit, le même serveur MCP peut être utilisé par plusieurs agents IA, sans adapter votre code pour chaque fournisseur.

C’est ce qui vaut à MCP son surnom de “USB-C de l’IA” : une interface unique, des usages différents, zéro intégration redondante.

Pourquoi MCP arrive maintenant ?

Trois phénomènes convergent :

1. Explosion des agents IA autonomes

Ces agents ne se contentent plus de générer du texte : ils agissent. Pour agir, ils doivent accéder à de vrais systèmes métiers.

2. Intégrations coûteuses et non standardisées

Avant MCP, intégrer un agent avec un CRM ou un ERP impliquait un développement propriétaire, difficile à maintenir.

3. Besoin d’un standard cross-plateforme

Anthropic a ouvert la voie, OpenAI a suivi, puis Microsoft, Cloudflare, Replit, et d’autres ont rejoint l’écosystème. L’adoption est rapide, et l’effet réseau commence déjà à jouer.

Comment MCP expose vos données et fonctions métiers

L’un des points les plus difficiles à comprendre avec MCP, surtout lorsqu’on n’est pas technique, est le suivant :

“Comment une IA peut-elle “agir” dans un système métier, sans avoir un accès direct et dangereux à toute l’entreprise ?”

La réponse se trouve dans la manière dont MCP structure et contrôle l’accès aux données et aux actions.

Voyons cela pas à pas.

1. L’architecture MCP expliquée simplement

Imaginez trois couches distinctes, qui jouent chacune un rôle précis :

1) L’agent IA (le “cerveau”)

Ce peut être :

• ChatGPT Desktop
• Claude Desktop
• un agent IA interne
• un assistant dans votre CRM
• un outil dans votre IDE (Zed, VS Code, Replit…)

Cet agent réfléchit, analyse, décide, mais ne touche jamais directement à vos systèmes internes.

2) Le “client MCP”

C’est la passerelle entre l’agent IA et le reste de votre environnement.

Il assure trois fonctions :

• Il annonce à l’IA quels serveurs MCP sont disponibles.
• Il filtre et contrôle ce que l’agent est autorisé à utiliser.
• Il transmet les requêtes de manière standardisée et sécurisée.

Pensez-y comme un interprète qui relie l’IA aux outils autorisés.

3) Les serveurs MCP (vos “adaptateurs métiers”)

C’est la pièce maîtresse du dispositif.

Un serveur MCP est un petit service que votre équipe installe pour exposer, de manière claire et limitée, des éléments de votre système d’information :

• vos fonctions métiers (ex. créer un ticket, générer une facture)
• vos données (ex. récupérer un contrat, lire une fiche client)
• vos fichiers (ex. trouver un PDF précis dans un dossier)

Chaque serveur MCP a une mission précise : exposer seulement ce que vous autorisez.

L’agent ne “voit” que ce que vous exposez via MCP, et rien d’autre.

C’est un point clé : MCP transforme vos systèmes internes en actions ciblées et en données limitées, que l’IA peut utiliser sans jamais disposer d’un accès global ou illimité à votre SI.

2. Exposer des actions métier : les “tools”

Pour permettre à un agent IA d’effectuer une action concrète, vous exposez un tool.

Un tool est, en réalité, un mode d’emploi structuré pour une action précise.

Il contient :

• un nom (create_support_ticket)
• une description claire (“Créer un ticket dans l’outil X”)
• des paramètres obligatoires (ex. titre, description, priorité)
• une structure de réponse (résultat, statut, identifiant créé)

Autrement dit, un tool est une capacité maîtrisée, comparable à un bouton précis dans une application.

Exemple concret

Vous exposez un tool nommé :
create_invoice

Il demande :

• customer_id
• amount
• due_date

Et renvoie :

• invoice_id
• status

Ce que fait l’agent IA

Si un utilisateur dit à l’agent :

« Générer une facture de 850 € pour le client 83945 et l’envoyer au service comptabilité. »

L’agent procède en trois étapes :

1. Comprendre la demande
2. Identifier le tool approprié
3. Appeler ce tool avec les paramètres corrects

L’IA ne cherche pas la facture dans votre ERP en autonomie, elle n’explore pas vos données, elle n’a pas d’accès généralisé. Elle ne peut agir qu’en utilisant les tools définis dans vos serveurs MCP.

C’est un garde-fou extrêmement important.

3. Exposer des données : les “ressources”

Les ressources fonctionnent comme les “documents autorisés” que vous laissez l’agent regarder.

Une ressource peut être :

• un dossier contenant des PDF
• un fichier précis (ex. “Contrat_4587.pdf”)
• une table de base de données filtrée
• un ensemble de rapports
• un document interne, une spécification, une procédure…

Chaque ressource :

• a un nom
• un emplacement
• une description
• des permissions explicites

Ce qu’une ressource n’est pas

Une ressource n’est pas toute votre base de données. Ce n’est pas un accès global à votre système documentaire. C’est un périmètre fermé que vous choisissez délibérément d’exposer.

Exemple concret

Vous exposez ce dossier : /contract_repository/clients/83945/

L’agent pourra :

• ouvrir les fichiers dans ce dossier
• en lire le contenu
• analyser les documents

Mais pas :

• accéder au dossier d’un autre client
• parcourir l’arborescence complète
• lire la base de données complète

En quoi MCP se distingue des intégrations IA classiques ?

Avant MCP, une intégration IA ressemblait à ça :

• On donne à l’agent des tokens API.
• On lui fournit un accès direct à une base ou un SaaS.
• On crée une série de scripts propriétaires.

C’était :

• fragile
• difficile à maintenir
• très risqué en termes de sécurité
• long à implémenter

Avec MCP :

• chaque action est une fonction encapsulée
• chaque donnée est une ressource limitée
• l’agent ne fait rien sans passer par un point de contrôle
• vous conservez une journalisation complète
• vous choisissez ce que l’agent est capable de faire

Le Model Context Protocol n’est pas un gadget : c’est une couche d’infrastructure qui simplifie la manière dont vos données et vos fonctions métiers dialoguent avec les agents IA.

Il réduit les coûts d’intégration, unifie les pratiques, améliore la sécurité, et crée une base durable pour vos projets agentiques.