MCP (Model Context Protocol)

Le MCP (Model Context Protocol) est un protocole ouvert créé par Anthropic qui définit une manière standard pour les grands modèles de langage d’accéder à des outils et des données externes. En termes simples, le MCP est au LLM ce que l’USB est à un ordinateur : une interface universelle qui permet de connecter n’importe quel outil sans avoir à développer un branchement spécifique pour chacun.

Avant le MCP, chaque application qui voulait connecter un LLM à ses données ou à des outils externes devait développer ses propres intégrations sur mesure. Le résultat était un enchevêtrement de code difficile à maintenir, à sécuriser et à faire évoluer. Le MCP remplace cette approche par un standard partagé : les outils s’exposent via des “serveurs MCP”, les applications consomment ces outils via des “clients MCP”, et le protocole gère la communication entre les deux.

Pourquoi le MCP existe : le problème de l’IA isolée

Un LLM seul est puissant mais isolé. Il peut raisonner sur du texte, répondre à des questions et produire du contenu, mais il n’a pas accès au monde réel — il ne peut pas lire vos fichiers, interroger votre base de données, envoyer un email ou créer un ticket dans votre outil de gestion de projet. Pour qu’un LLM devienne réellement utile dans un contexte professionnel, il doit pouvoir interagir avec les systèmes que l’entreprise utilise au quotidien.

Sans standard, chaque intégration est un développement spécifique. Connecter un LLM à Slack nécessite un code. Le connecter à une base de données en nécessite un autre. Le connecter à un outil de facturation, encore un autre. Et si vous changez de LLM — de GPT à Claude, par exemple — il faut potentiellement réécrire toutes ces intégrations.

Le MCP résout ce problème en définissant un langage commun. Un serveur MCP expose des capacités — lire des documents, créer des tâches, envoyer des messages — de manière standardisée. N’importe quel LLM compatible MCP peut utiliser ces capacités sans code spécifique. Le résultat est un écosystème où les outils sont interchangeables et où les intégrations sont réutilisables.

Architecture du MCP : client, serveur et protocole

L’architecture MCP repose sur trois composants :

• Le client MCP est intégré dans l’application qui utilise le LLM — c’est lui qui formule les demandes d’accès aux outils.
• Le serveur MCP est un programme qui expose les capacités d’un outil ou d’un système — il sait comment interroger une base de données, envoyer un message sur Slack ou lire un fichier.
• Le protocole définit le format des échanges entre le client et le serveur, en s’appuyant sur JSON-RPC pour la communication.

Un serveur MCP peut exposer trois types de capacités :

• Les ressources sont des données que le LLM peut consulter — des articles de documentation, des fiches client, des rapports.
• Les outils (tools) sont des actions que le LLM peut exécuter — créer un ticket, envoyer un email, mettre à jour un enregistrement.
• Les prompts sont des instructions prédéfinies qui guident le LLM sur la manière d’utiliser les ressources et les outils dans un contexte donné.

En pratique, une application peut connecter plusieurs serveurs MCP simultanément, ce qui rappelle l’approche des microservices. Un agent IA de support client pourrait utiliser un serveur MCP pour accéder à la base de connaissances, un autre pour créer des tickets dans l’outil de suivi, et un troisième pour notifier l’équipe sur la messagerie interne. Le tout sans que le LLM ait besoin de connaître les détails techniques de chaque système.

MCP vs function calling : quelle différence ?

Le function calling (appel de fonctions) est une capacité native des LLM qui leur permet d’exprimer l’intention d’appeler une fonction avec des paramètres structurés. Le MCP va plus loin : il standardise la découverte, l’exécution et la sécurisation de ces fonctions à travers un protocole unifié.

Avec le function calling seul, c’est au développeur de câbler chaque fonction, de gérer l’authentification et de définir le format d’échange. Avec le MCP, tout cela est encadré par le protocole. Un serveur MCP peut être développé une fois et réutilisé par n’importe quelle application compatible, quel que soit le LLM utilisé.

Cas d’usage concrets du MCP

Le MCP trouve sa place dans de nombreux scénarios :

• Agents IA métier : un agent IA qui accède au CRM, consulte l’historique client et rédige des réponses personnalisées via des serveurs MCP connectés à chaque système.
• Assistants de développement : des outils comme Claude Code, Cursor ou Windsurf utilisent le MCP pour interagir avec le système de fichiers, les bases de données ou les API tierces directement depuis l’IDE.
• Automatisation de workflows : connecter un LLM à des outils de gestion de projet, de facturation ou de communication pour automatiser des tâches répétitives.
• RAG enrichi : combiner le MCP avec une approche RAG pour donner au LLM un accès dynamique à des sources de données multiples, au-delà d’une simple base vectorielle.
• Chatbots IA connectés : des chatbots capables d’agir — réserver un créneau, modifier une commande, consulter un statut — et pas seulement de répondre à des questions.

Ce que le MCP change pour les produits SaaS

Pour les développeurs de SaaS, le MCP réduit considérablement le temps nécessaire pour intégrer des fonctionnalités intelligentes dans un produit. Au lieu de développer une intégration complète pour chaque source de données ou chaque outil, ils peuvent s’appuyer sur des serveurs MCP existants — développés par la communauté open source ou par les éditeurs eux-mêmes.

La modularité est un avantage majeur. Chaque serveur MCP est indépendant : corriger un problème dans le serveur qui gère les tickets n’affecte pas celui qui gère les emails. Ajouter un nouvel outil — un système de facturation, un outil d’analytics — revient à connecter un nouveau serveur, sans modifier le reste de l’architecture.

La sécurité est intégrée dans le protocole. Chaque serveur MCP définit précisément ce que le LLM peut faire et ne peut pas faire. On peut autoriser la lecture de documents publics tout en interdisant l’accès aux données clients sensibles. Ce contrôle granulaire est essentiel pour les applications professionnelles où la confidentialité des données est critique.

Enfin, le MCP réduit la dépendance à un fournisseur de LLM spécifique. Puisque le protocole est standard, changer de modèle — passer de Claude à GPT ou à Mistral — ne nécessite pas de réécrire les intégrations avec les outils. Les serveurs MCP restent les mêmes.

Limites et défis du Model Context Protocol

Le MCP est une technologie récente dont l’écosystème est encore en construction. Le nombre de serveurs MCP disponibles grandit rapidement, mais certains outils spécialisés n’ont pas encore de serveur compatible. Dans ces cas, il faut développer son propre serveur — ce qui, bien que plus simple que de développer une intégration complète, demande tout de même un investissement technique.

La performance peut être un sujet d’attention. Chaque appel à un serveur MCP ajoute une étape dans le traitement d’une requête, ce qui peut augmenter la latence. Pour les applications où la réactivité est critique, l’architecture doit être pensée pour minimiser ces allers-retours — par exemple via la mise en cache des ressources ou le regroupement des appels.

La standardisation est encore en cours. Le protocole évolue rapidement, et les bonnes pratiques se consolident au fil du temps. Il est important de suivre les mises à jour de la spécification pour bénéficier des dernières améliorations en matière de sécurité et de fonctionnalités.

Comment Polara Studio utilise le MCP

Chez Polara Studio, le MCP est devenu un composant central de l’architecture des SaaS que nous construisons avec des fonctionnalités d’intelligence artificielle. Plutôt que de développer des intégrations sur mesure entre le LLM et chaque système, nous concevons une architecture où des serveurs MCP exposent les capacités métier de l’application — accès aux données, actions sur le produit, interactions avec les services tiers.

Cette approche nous permet de livrer des agents IA capables d’interagir avec l’écosystème de nos clients de manière fiable et sécurisée. Et quand les besoins évoluent — un nouveau système à connecter, un nouveau type d’action à automatiser — il suffit d’ajouter un serveur MCP sans repenser l’ensemble de l’architecture.