Oui, dans le contexte actuel de l’engouement pour l’IA, cette déclaration équivaut presque à un suicide, mais je voudrais expliquer brièvement pourquoi nous, chez HybridAI, avons décidé de ne pas mettre en place ou utiliser de serveur MCP pour le moment.
Les serveurs MCP sont une norme (actuellement encore “souhaitée”) développée et promue par Anthropic, qui suscite beaucoup d’écho dans la communauté IA.
Un serveur MCP vise à standardiser les appels d’outils (ou “function calls”) essentiels aux applications IA “agentiques” actuelles – c’est-à-dire l’interface entre le LLM (appel d’outil) et l’interface du service ou de l’outil externe, généralement une API REST.
Avec le moteur d’image actuel de ChatGPT – j’adore un peu ces images IA “poubelle” et elles vont me manquer…
Chez HybridAI, nous misons depuis longtemps sur une solide implémentation des appels de fonctions. Nous avons plusieurs dizaines de fonctions en production, utilisées par plus de 450 agents IA. Nous avons donc un peu d’expérience dans le domaine. Nous utilisons aussi N8N dans certains cas, ce qui ajoute une couche supplémentaire pertinente dans la pratique. Nos agents exposent également des API externes, donc nous connaissons le problème dans les deux sens (c’est-à-dire que nous pourrions à la fois mettre en place un serveur MCP pour nos agents et interroger d’autres MCP dans nos appels de fonctions).
Alors pourquoi je ne trouve pas les serveurs MCP géniaux ?
Simplement parce qu’ils résolvent un problème qui, à mon avis, existe à peine, et laissent deux problèmes bien plus importants des appels de fonctions et des configurations agentiques non résolus.
Premièrement : pourquoi le problème de la standardisation des API externes est-il relativement marginal ? Deux raisons. (1) Les API existantes sont souvent des API REST ou similaires, donc déjà standardisées. De plus, elles sont généralement très stables (par exemple avec « /v1/… » ou « /v2/… »). Même avec de nouvelles interfaces, les anciens endpoints restent souvent accessibles très longtemps. Et les vieilles API restent intéressantes – celles de l’ISS, de l’Office européen des brevets ou d’une ville. Ces services ne proposeront pas d’interface MCP de sitôt – il faudra donc continuer à gérer ces vieilles API. (2) Et c’est là que je suis surpris par le battage autour de MCP : les LLM sont très bons pour interroger ces vieilles API – bien mieux que d’autres systèmes que j’ai vus. On injecte la réponse brute de l’API dans le LLM, et il s’en sort. Pas de parsing, pas de gestion d’erreurs, pas de décryptage XML. Le LLM fait tout cela de manière fiable. Alors pourquoi ajouter MCP pour abstraire cela ?
MCP ajoute donc une couche technique supplémentaire pour un problème qui, dans la pratique, n’est pas si grave.
Les deux vrais problèmes sont plutôt :
–> La sélection des outils
–> L’exécution des outils et la sécurité du code
Sélection des outils : Les solutions agentiques permettent de combiner plusieurs outils, parfois en chaîne, le LLM décidant de ceux à utiliser et comment les combiner. Ce processus est influencé par les descriptions d’outils – de petits mini-prompts expliquant leur fonction et leurs arguments. Mais cela devient vite le bazar. Par exemple, nous avons un appel de fonction vers Perplexity pour des questions actuelles (“quel temps fait-il aujourd’hui…”), mais le LLM l’appelle aussi quand la question est juste un peu complexe. Ou il déclenche l’appel API de recherche WordPress alors que nous voulions la recherche web avec GPT-4.1. Cette partie est assez chaotique et va devenir plus complexe avec l’autonomie accrue.
Exécution des outils : Le gros problème pour la scalabilité et la sécurité vient de l’exécution locale du code des outils. Cela se passe sur votre propre système. Idéalement, chez HybridAI, nous proposerions à nos clients de nous soumettre leur propre code, qui serait exécuté comme appel de fonction quand le LLM le souhaite. Mais en termes d’intégrité du code, de stabilité et de sécurité de la plateforme, c’est un cauchemar (ceux qui ont déjà soumis un plugin WordPress comprendront). Ce problème deviendra encore plus important avec l’usage accru des outils « operator » ou « computer use » – qui tournent aussi localement.
Pour ces deux problèmes, j’aimerais avoir des idées – peut-être un TOP (Tool Orchestration Protocol) ou un TEE (Tool Execution Environment). Mais bon.
