MCP (Model Context Protocol)

Ce qu'est vraiment le MCP

Le Model Context Protocol (MCP) est une spécification ouverte publiée par Anthropic fin 2024. Son objectif est simple à énoncer : donner aux modèles d'IA un moyen normalisé d'accéder au contexte et aux outils dont ils ont besoin pour agir. Avant le MCP, chaque connexion entre un assistant et un système externe (un CMS, une base Airtable, un CRM, un stockage de fichiers) exigeait sa propre intégration sur mesure. Dix outils, c'était dix connecteurs spécifiques, chacun maintenu séparément. Le MCP remplace ce fouillis par un langage commun : un outil s'expose une fois, et n'importe quel assistant compatible peut l'utiliser.

Une bonne comparaison est le Language Server Protocol (LSP) dans les éditeurs de code. Avant le LSP, chaque éditeur avait besoin d'un plugin sur mesure pour chaque langage de programmation, un problème en N fois M. Le LSP l'a transformé en N plus M en définissant un protocole unique entre éditeurs et serveurs de langage. Le MCP fait la même chose pour l'IA : au lieu de construire un pont sur mesure pour chaque assistant et chaque outil, on construit un serveur MCP par outil et un client MCP par assistant, et ils parlent le même protocole.

Comment le MCP fonctionne en coulisses

Le MCP suit une architecture client et serveur. L'hôte est l'application d'IA (par exemple un assistant de bureau ou un environnement de développement). À l'intérieur s'exécute un client MCP, qui ouvre une connexion vers un ou plusieurs serveurs MCP. Chaque serveur enveloppe un système précis et annonce ce qu'il sait faire. La communication utilise des messages JSON-RPC, et le transport peut être un processus local via l'entrée et la sortie standard, ou une connexion distante via HTTP.

Un serveur expose trois grandes catégories de capacités :

• Ressources : des données que le modèle peut lire, comme un document, un enregistrement de base ou un fichier.
• Outils : des actions que le modèle peut déclencher, comme créer un élément, envoyer une requête ou exécuter une recherche.
• Prompts : des gabarits réutilisables qui empaquettent une tâche pour que l'assistant la déclenche de façon cohérente.

Le mécanisme clé est la découverte. Le client demande au serveur ce qu'il propose, le serveur décrit chaque capacité de manière structurée et auto-explicative, et le modèle décide quand et comment l'utiliser. Personne ne code chaque appel à la main à l'avance.

MCP face à une API classique

On est tenté de demander en quoi ce n'est pas juste une API, et la réponse honnête est que le MCP se pose au-dessus des API plutôt que de les remplacer. Une API REST expose des endpoints conçus pour des développeurs, qui lisent une documentation et écrivent du code pour appeler chacun de façon déterministe. C'est toujours le bon outil pour un travail de machine à machine où la séquence d'appels est fixe et connue d'avance.

Le MCP est différent parce qu'il décrit ses capacités d'une façon qu'un modèle peut interpréter seul. L'assistant n'a pas besoin d'un développeur pour câbler chaque appel : il lit les descriptions d'outils à l'exécution et raisonne sur l'action qui convient à la demande. La ligne de partage n'est donc pas une supériorité technique mais une question d'adéquation : une API simple pour les intégrations déterministes et codées, le MCP quand un agent doit décider, sur le moment, quoi lire et quoi faire. En pratique, un serveur MCP est souvent une fine couche bien décrite au-dessus des API que vous avez déjà.

Quand utiliser le MCP, et quand l'éviter

Le MCP prend sa place quand vous voulez qu'un assistant généraliste agisse de façon fiable sur vos propres données et systèmes : rédiger du contenu dans votre CMS, consulter une fiche client, vérifier un stock, déclencher un workflow, le tout en langage naturel et de façon traçable. Il est particulièrement utile quand les mêmes données doivent être accessibles depuis plusieurs assistants, car vous construisez le serveur une fois au lieu d'un connecteur par outil.

C'est le mauvais choix pour un pipeline figé et à fort débit où aucun raisonnement n'intervient. Si un système doit simplement recopier des enregistrements de A vers B à intervalle régulier, un appel API direct ou une plateforme d'automatisation est plus simple et moins cher. Le MCP ajoute une couche de raisonnement, et cette couche ne vaut son poids que lorsqu'il faut réellement décider. L'ajouter à une tâche purement mécanique, c'est de la surcharge sans bénéfice.

Sécurité, contrôle et pièges fréquents

Comme un serveur MCP peut exposer de vraies actions sur de vrais systèmes, le contrôle est la question centrale de conception, pas une pensée d'après-coup. Un serveur bien construit n'expose que les ressources et outils qu'il doit, applique des permissions fines et valide chaque entrée, de sorte qu'un agent ne puisse ni lire ni modifier ce qu'il n'aurait jamais dû toucher. L'erreur récurrente est l'inverse : câbler un serveur large et trop permissif en se fiant au modèle pour bien se tenir. Autres pièges : laisser fuiter des identifiants par le serveur, renvoyer bien plus de données qu'une tâche n'en demande, ou négliger la journalisation. Traitez chaque outil que le modèle peut appeler comme une porte vers vos systèmes, et concevez chaque porte avec le moindre privilège qui permet encore de faire le travail.

Le MCP chez BeBranded

Chez BeBranded, on construit des serveurs MCP sur mesure pour rendre l'environnement du client pilotable par IA. Exemple concret : un serveur MCP branché sur le CMS Webflow d'un client permet à un assistant de rédiger un article, de le pousser en brouillon dans la bonne Collection, de vérifier les champs SEO et de repérer un bloc de code vide avant toute publication. On peut aussi exposer une base Airtable ou un outil interne pour qu'une équipe non technique pilote son site et ses données en langage naturel, sans quitter les systèmes en lesquels elle a déjà confiance. On délimite chaque serveur au plus juste, on n'expose que ce dont une tâche donnée a besoin et on garde les actions traçables, car c'est le contrôle qui rend un workflow piloté par IA sûr à déléguer. C'est la brique qui transforme un site Webflow, d'un endroit que l'on édite à la main, en une surface qu'un assistant peut opérer sous des limites claires et auditables.