Le problème n’est pas MCP. C’est le MCP naïf.

On vient de terminer un webinar sur MCP avec des membres de la communauté Free-Work. Et le sujet a clairement généré beaucoup de conversations.

Le générique venait à peine de se terminer que le chat était déjà actif. Les experts étaient sur scène, et il y avait déjà une centaine de commentaires.

Le menu était complet.
En entrée, la question du standard : est-ce que le Model Context Protocol est en train de s’imposer ?
Le plat de résistance, ce sont les cas d’usage. Quand utiliser MCP, et quand une alternative suffit. Spoiler : un skill ne va pas remplacer un serveur MCP.
Le fromage, c’est la consommation de tokens. Voir son quota fondre à cause d’un MCP trop verbeux, c’est une réalité.
Et en dessert, la sécurité. Celle du protocole, mais surtout celle des données.

Au fond, tout ramène à une seule question : est-ce que MCP est en train de devenir un standard ?

Dans cet article, vous retrouverez en quelques minutes de lecture les points clés du webinar.

Le replay complet est disponible ci-dessous. Pensez à vous abonner à la page LinkedIn pour être notifié des prochains événements.

Oui, MCP est en train de devenir un standard.

C’est Julien Casanova qui apporte le point lors du direct. MCP n’est plus le pré carré d’Anthropic. Il a été donné à la Linux Foundation. Elle a annoncé l’AAIF : Agentic AI Foundation, qui comprend MCP mais aussi AGENTS.md.

L’adoption du protocole était déjà bien plus large. Les utilisateurs, qu’ils utilisent les modèles d’Anthropic, de Google ou d’OpenAI n’ont pas attendu que les éditeurs adoubent le protocole pour l’adopter. Lors du Webinar, c’est Context7 par exemple, dont le MCP a été plébiscité.

Est-il déjà arrivé que votre agent « hallucine » sur une feature parce qu’il a imaginé à partir de la mauvaise version de la documentation ? Context7 propose un MCP qui évite ça. Et peu importe votre modèle, ou votre interface.

Et ce n’est qu’un exemple, des centaines d’applications proposent maintenant un serveur MCP pour que les agents puissent interagir avec votre SaaS à votre place. On parle d’outils comme Figma ou de services du réel comme l'État français qui expose un MCP pour les données des entreprises ou de l’éducation nationale. 

L’adoption a été plus que fulgurante et a dépassé largement le domaine d’Anthropic.

Pour autant, il aurait été compliqué pour les éditeurs de contribuer à un protocole qui appartient à un de leurs concurrents. La Linux Foundation est le bon casque bleu pour garder ce bien commun numérique.

Non, il ne remplace pas tout.

MCP a pour but d’étendre les capacités d’un LLM ou d’un agent. Alors forcément les participants avaient de nombreuses idées d’alternatives. On prend le temps de faire le tri.

Les SKILL cachent souvent une CLI sous le capot.

Le premier qui est mentionné, c’est le SKILL. 

C’est encore un format d’Anthropic, qui est également ouvert. On l’a d’abord découvert dans Claude Code, et il a été largement popularisé par OpenClaw.

Il contient principalement un fichier SKILL.md qui explique à l’agent comment utiliser le reste du paquet. On décrit la capacité. Pour la suite, c’est souvent implémenté avec une application en CLI pour être facile à packager.

Donc dans l’absolu, un SKILL.md peut expliquer à votre agent comment utiliser un serveur MCP. Ce n’est pas une alternative, mais bien une brique supplémentaire.

Les alternatives réellement mentionnées sont les APIs ou les applications CLIs. Votre agent accède à un terminal et tape les commandes pour vous. Ou alors il va appeler via HTTP l’API Web d’un service distant.

Et oui, il y a beaucoup de choses qu'on a fait avec un MCP où une API aurait pu suffire. Et ça sera la 3e partie de cet article. Mais avant d’y passer, on doit parler de RAG.

MCP n’est pas là pour remplacer RAG.

Alors c’est quoi un RAG ?

Un RAG est une architecture qui repose sur une base de données vectorielle. C’est le R de RAG, pour Retrieval. On va chercher un vecteur proche. Par exemple, si vous avez une FAQ de service client, chaque question-réponse est transformée en vecteur. Le RAG va alors retrouver celui qui est le plus proche de la question posée.

Une fois ce vecteur retrouvé, on l’utilise pour enrichir la réponse de l’agent. C’est le AG de RAG : Augmented Generation.

Pendant un temps, c’était la principale façon de rendre un agent plus pertinent sur un contexte borné. On met le code du travail dans un RAG, la jurisprudence du droit social dans un RAG, et le LLM devient plus pertinent.

Mais MCP ne remplace pas RAG. C’est le point de Marco Berta, notre ingénieur ML/IA sur le plateau.

Au contraire, les deux peuvent très bien coexister. Vous pouvez continuer d'utiliser votre base de données vectorielle pour apporter du contexte, tout en utilisant MCP pour permettre à l’agent d’agir ou d’interagir avec des outils.

Un serveur MCP peut même exposer cet accès à la base vectorielle. MCP n’est pas une alternative, c’est une interface.

Si le MCP coûte trop cher, c’est probablement que c’est un MCP Naïf

Marco nous a donné le mot : “Naïve MCP”. C’est l’architecture d’un MCP qui est un passe-plat vers une API. 

Alors c’est quoi le problème ?

Quand on laisse un agent se promener sur une API, il va faire des dizaines de requêtes. Parfois en prenant des erreurs 400 parce qu’il a mal formé les requêtes. Il va toujours chercher une page ou deux en trop parce qu’il attend que les données ne soient pas pertinentes pour s’arrêter d’explorer.

Imaginons un agent qui a besoin de trouver le meilleur vélo pour son client. S’il cherche sur une API qui contient tous les modèles de vélos qui existent dans le monde, il va sûrement tout charger dans son contexte pour être sûr d’avoir la bonne réponse.

S’il utilise un MCP, il doit avoir un nombre limité de vélos dans son contexte. Le serveur MCP doit prendre en entrée l’intention de l’utilisateur pour faire le tri à la place de l’agent.

Si votre serveur MCP a renvoyé à l’agent tout le catalogue, il a rempli le contexte et l’agent va certainement halluciner très vite. Et c’est ce que fait un MCP naïf.

Pire, il ne réduit pas la complexité de parcours de l’API. Imaginez que ce catalogue soit paginé avec 20 vélos par page. Si le MCP Naïf fait la même chose, le LLM va parcourir toutes les pages du catalogue avant de s’arrêter, faisant autant de requêtes que sur une API.

Imaginez que votre LLM fasse appel à plusieurs serveurs MCP naïfs pour un seul prompt utilisateur : sa fenêtre de contexte va se remplir très vite, et le nombre de tokens consommés va exploser très vite.

Le vrai sujet, c’est la gouvernance de la donnée et des accès

Quand on a parlé de sécurité, c’est notre Data Analyst, Lamia Salhi, qui a apporté les réponses.

Pourquoi parler de sécurité quand on parle de MCP ?

Parce que les LLMs sont comme des humains : imparfaits. Ils font des erreurs.
Si un humain peut faire un rm -rf et brûler un serveur en production, un agent avec les mêmes permissions pourra en faire autant.

Et comme pour les humains, la solution n’est pas magique. C’est la gouvernance de la donnée et des accès.

Le protocole mentionné par Lamia est le RBAC : Role-Based Access Control. Il s’agit de gérer les accès en fonction des rôles.

Sur le papier, c’est simple. Dans la réalité, beaucoup de systèmes ne fonctionnent pas exactement comme ça.

On utilise souvent des groupes. Par exemple, un groupe “comptabilité” aura accès aux comptes bancaires. Mais aligner ces groupes avec une vraie gestion des rôles, revoir les systèmes d’identification (IAM), et contrôler finement l’accès aux ressources reste un chantier long et complexe.

Et dans beaucoup d’entreprises, ce chantier n’est pas terminé. Parfois, il n’a même pas commencé.

MCP n’a pas rendu votre système dangereux. Il met à nu le fait que celui-ci n’était pas sécurisé avant.

Personne n’est en retard pour adopter MCP

Le protocole a clairement créé une vague de hype. Une forme de fear of missing out. Mais en réalité, ceux qui se sont précipités ont souvent construit des MCP mal conçus, naïfs.

MCP reste un protocole à utiliser avec parcimonie.

Si une CLI ou une API suffit, il n’y a probablement pas besoin d’un serveur MCP. Dans la plupart des cas, un agent sait enchaîner une ou deux opérations simples sans se tromper.

En revanche, si votre modèle se perd sur une API pourtant simple, alors MCP devient intéressant. Il permet de condenser l’accès à l’information et d’obtenir une réponse en une seule interaction. Et là, il économise réellement du contexte.

La conclusion est simple : il n’est pas trop tard.

Au contraire, vous bénéficiez aujourd’hui des apprentissages de tous ceux qui ont construit des serveurs MCP… pour rien.