Il y a encore un an, connecter un LLM à vos outils internes relevait du bricolage artisanal. Chaque intégration était un cas particulier : un bout de code sur mesure pour interroger une base de données, un autre pour appeler une API, un autre pour lire des fichiers. Ça fonctionnait, plus ou moins, mais ça ne scalait pas.

Le Model Context Protocol change ça. Pas de façon révolutionnaire, pas du jour au lendemain mais il pose enfin une base commune que tout le monde peut adopter.

Le problème qu'il résout

Un LLM, seul, ne sait rien de votre système. Il ne connaît pas votre base de code, votre CRM, votre Confluence, vos tickets Jira, vos logs de production. Pour qu'il soit vraiment utile dans un contexte professionnel, il faut lui donner accès à tout ça, en temps réel, de façon fiable, sans que chaque équipe réinvente la roue de son côté.

Avant MCP, la solution dominante était le function calling : on exposait des fonctions au modèle, il décidait lesquelles appeler, on gérait les résultats. Ça marche, mais chaque implémentation est propriétaire. Vous construisez une intégration pour Claude, vous recommencez pour GPT-4, vous recommencez encore pour le prochain modèle que vous voulez tester. Et côté outils, chaque fournisseur doit implémenter ses connecteurs pour chaque modèle.

MCP propose une autre approche : un protocole standardisé, côté client et côté serveur, qui découple le modèle de ses sources de données.

Comment ça fonctionne

L'architecture repose sur trois composants.

Le MCP client est intégré dans l'application qui utilise le LLM, un assistant de code, un agent, un chatbot interne. C'est lui qui initie les connexions et transmet les requêtes.

Le MCP server est un processus léger qui expose des ressources ou des capacités : lire des fichiers, interroger une base de données, appeler une API externe, exécuter une commande. Chaque outil ou source de données peut avoir son propre serveur MCP.

Entre les deux, le protocole définit un format d'échange standardisé basé sur JSON-RPC. Le client annonce ce dont il a besoin, le serveur répond dans un format que le client sait interpréter, quel que soit le modèle utilisé derrière.

Ce qui change vraiment, c'est que le serveur MCP peut être développé une seule fois et réutilisé avec n'importe quel client compatible. Vous écrivez un connecteur pour votre base de données interne il fonctionne avec Claude, Cursor, par exemple ou avec n'importe quel agent qui implémente MCP.

Ce que ça donne en pratique

Quelques exemples concrets pour ancrer la chose :

Un développeur travaille dans Cursor. Grâce à un serveur MCP connecté à GitHub, l'assistant peut lire l'historique des commits, comprendre le contexte d'une PR, suggérer des corrections cohérentes avec les conventions du repo. Sans MCP, il faudrait copier-coller le contexte à la main.

Une équipe data configure un serveur MCP devant leur entrepôt de données. Un analyste peut poser des questions en langage naturel, le modèle génère la requête SQL, l'exécute via le serveur MCP, et retourne le résultat sans que l'analyste ait besoin de toucher à du SQL ou de passer par une interface dédiée.

Une équipe ops connecte leur outil de monitoring via MCP. L'agent peut interroger les métriques, lire les logs récents, et proposer un diagnostic directement dans le fil de conversation, avec accès aux données réelles au moment où il répond.

Dans les trois cas, la valeur ne vient pas du modèle seul. Elle vient de sa capacité à agir dans un contexte réel, avec des données fraîches, sans friction d'intégration.

Les limites à ne pas ignorer

MCP n'est pas magique, et certains points méritent d'être abordés honnêtement avant de se lancer.

La sécurité est le sujet le plus sensible. Un serveur MCP expose des capacités à un modèle, ce qui signifie qu'un prompt injection mal géré peut potentiellement déclencher des actions non souhaitées. La gestion des permissions, l'authentification entre client et serveur, et le principe du moindre privilège ne sont pas optionnels.

La standardisation est encore jeune. Le protocole a été ouvert par Anthropic fin 2024, l'adoption s'accélère, mais l'écosystème n'est pas encore aussi mature que celui d'OpenAPI ou REST. Des conventions émergent, certaines casse-compatibilité sont encore possibles. C'est un protocole à adopter en ayant conscience qu'on est encore dans une phase de consolidation.

La complexité opérationnelle, enfin. Multiplier les serveurs MCP, c'est multiplier les processus à maintenir, à monitorer, à sécuriser. Pour des cas d'usage simples, un function calling classique peut suffire. MCP apporte sa valeur quand on commence à avoir plusieurs sources de données, plusieurs modèles, et un besoin de réutilisabilité sérieux.

Pourquoi ça compte maintenant

L'adoption de MCP dans les outils de développement s'est faite plus vite que prévu. Cursor, Claude Desktop, Zed, Sourcegraph, plusieurs environnements majeurs le supportent déjà. Du côté des serveurs, des connecteurs officiels existent pour GitHub, Slack, PostgreSQL, Google Drive, et des dizaines d'autres.

Ce n'est pas encore le standard universel qu'il ambitionne d'être, mais la trajectoire est là. Pour une équipe tech qui construit des agents ou des assistants IA aujourd'hui, ignorer MCP, c'est risquer de construire des intégrations qui devront être refaites dans dix-huit mois.

La vraie question n'est plus "faut-il regarder MCP ?" mais "par où on commence ?"