Connecter un LLM à vos outils métier : ce que MCP change vraiment
MCP est devenu la troisième voie d'intégration d'un LLM, à côté du RAG et des appels d'API directs. Voici ce que le protocole règle réellement, ce qu'il ne règle pas, et la grille qui dit s'il vaut le coup chez vous.
title: "Connecter un LLM à vos outils métier : ce que MCP change vraiment" seoTitle: "MCP : connecter un LLM à vos outils métier" description: "MCP est devenu la troisième voie d'intégration d'un LLM, à côté du RAG et des appels d'API directs. Voici ce que le protocole règle réellement, ce qu'il ne règle pas, et la grille qui dit s'il vaut le coup chez vous." seoDescription: "Ce que le Model Context Protocol règle vraiment quand on branche un LLM sur ses outils métier, ce qu'il ne règle pas, et quand il ne vaut pas le coup." date: "2026-09-21" author: "Équipe Raicode" tags: ["IA", "automatisation", "architecture", "développement"] category: "IA & Automatisation" keywords: ["MCP", "Model Context Protocol", "connecter un LLM à ses outils", "intégration LLM production", "serveur MCP", "outils LLM", "agent IA outils métier", "MCP ou API directe", "MCP et RAG"]
L'assistant interne fonctionne depuis quatre mois. Il lit le CRM, crée des tickets, interroge la facturation : onze outils, chacun écrit à la main dans le dépôt de l'application web, chacun avec sa description glissée dans le prompt système. Le problème arrive le jour où l'équipe support veut les mêmes onze outils dans son propre agent, et où l'équipe data veut les brancher sur un assistant de requêtage. Il faut soit recopier la couche d'intégration dans deux dépôts de plus, soit tout exposer derrière une API maison que personne n'a le temps de spécifier. C'est à ce moment qu'un prestataire prononce « MCP », et que la question devient concrète : est-ce que ce protocole règle ce problème-là, ou est-ce qu'il ajoute une couche de plus à maintenir ?
La réponse honnête est : il règle ce problème-là, précisément celui-là, et presque aucun des autres. Ce qui n'est pas rien, mais ce n'est pas ce que laissent entendre les pages d'offre qui le citent désormais au même rang que le RAG et le choix du modèle. Cet article décrit ce que MCP fait réellement dans une intégration LLM en production, ce qu'il laisse entièrement à votre charge, et les critères qui décident s'il vaut son coût d'adoption chez vous.
Ce que MCP est, sans la métaphore
Le Model Context Protocol est un protocole ouvert, publié par Anthropic fin 2024 et adopté depuis par la plupart des éditeurs de clients LLM. Il standardise la conversation entre un client (l'application qui pilote le modèle) et un serveur (le programme qui expose vos outils et vos données). Les messages sont du JSON-RPC 2.0. Le transport est soit stdio pour un serveur local, soit Streamable HTTP pour un serveur distant. La spécification est versionnée par date — 2024-11-05, 2025-03-26, 2025-06-18 — et un serveur sérieux en accepte plusieurs, parce que les clients ne migrent pas tous au même rythme.
Un serveur expose trois types de primitives. Les outils sont des fonctions appelables, décrites par un nom, une description en langage naturel et un schéma JSON d'entrée. Les ressources sont des contenus adressables que le client peut lire et injecter dans le contexte. Les prompts sont des modèles d'invocation réutilisables, proposés à l'utilisateur. Dans la pratique, plus de 90 % des serveurs que nous auditons n'exposent que des outils.
La comparaison avec l'USB-C circule partout et elle induit en erreur sur un point : USB-C garantit qu'un périphérique branché fonctionne. MCP garantit seulement que le client sait quels outils existent et comment les appeler. Que le modèle les appelle au bon moment, avec les bons arguments, et qu'il fasse quelque chose de sensé du résultat, reste entièrement hors du protocole. MCP normalise la prise, pas l'électricité.
Les trois voies d'intégration, et ce qui les départage
Quand une équipe veut qu'un LLM agisse sur ses systèmes, elle a trois options réelles, et le choix ne se fait pas sur l'élégance technique.
L'appel d'API codé en dur. Vous écrivez une fonction outil dans votre application, vous la déclarez au modèle, vous gérez l'appel. C'est ce que fait tout le monde au début, et c'est la bonne réponse plus souvent qu'on ne le dit. Coût d'entrée quasi nul, latence minimale, contrôle total sur ce qui part et ce qui revient.
Le RAG. Vous ne donnez pas d'action au modèle, vous lui donnez de la matière : des documents récupérés au moment de la question. C'est une réponse à un besoin de connaissance, pas à un besoin d'action. Les deux se combinent d'ailleurs souvent, et la qualité de la récupération reste le premier facteur de réponses à côté, que le transport soit MCP ou non.
MCP. Vous sortez vos outils de l'application et vous les exposez derrière un serveur que n'importe quel client compatible peut interroger.
Le critère qui tranche n'est ni la taille du projet ni la maturité de l'équipe : c'est le rapport entre le nombre de clients et le nombre d'outils. Avec un seul assistant et onze outils, écrire ces outils en dur coûte onze fonctions. Avec trois assistants, cela coûte trente-trois fonctions à maintenir en cohérence, ou onze fonctions derrière un serveur MCP plus trois branchements. C'est une arithmétique de M × N contre M + N, et elle ne devient favorable qu'à partir du deuxième consommateur réel. Un deuxième consommateur prévu pour l'an prochain ne compte pas.
Le second critère est la propriété. Si l'équipe facturation possède ses règles métier et ne veut pas que trois applications les réimplémentent, un serveur MCP maintenu par elle est un contrat propre : elle publie, les autres consomment, les changements de schéma se voient. C'est l'argument d'organisation, et il pèse souvent plus lourd que l'argument technique.
Ce que le protocole règle réellement
La découverte. Un client appelle tools/list et reçoit le catalogue à jour. Ajouter un outil ne demande pas de redéployer les clients. Sur une plateforme où les outils bougent toutes les semaines, c'est le gain principal, et il est réel.
La description normalisée. Nom, description, schéma JSON d'entrée, et depuis la révision 2025-06-18 une sortie structurée en plus du texte. Fini les conventions maison qui divergent entre deux équipes.
La réutilisation entre surfaces. Le même serveur sert votre application web, un agent interne, un IDE et, si vous le décidez, un client externe. C'est exactement le problème de l'équipe du début de cet article.
L'écosystème. Les serveurs existants pour GitHub, Postgres, Slack, Sentry et quelques centaines d'autres évitent d'écrire la couche d'accès. À condition de les auditer, ce qui nous amène au reste.
Ce que MCP ne règle pas
C'est la partie que les pages d'offre omettent, et c'est celle qui décide du succès en production.
La fiabilité du modèle. Un outil parfaitement décrit sera appelé au mauvais moment, avec un argument inventé, ou ignoré alors qu'il fallait l'appeler. Nous voyons régulièrement des équipes qui migrent vers MCP en espérant améliorer un taux de réussite de 80 %, et qui retrouvent exactement 80 % après migration — c'est attendu, elles ont changé le transport, pas le raisonnement. Le levier est ailleurs : l'évaluation qui manque à un agent qui marche 8 fois sur 10 se construit indépendamment du protocole.
Le coût. C'est le contresens le plus cher. Chaque définition d'outil est envoyée au modèle, à chaque tour de conversation. Une description sérieuse avec son schéma pèse entre 150 et 400 jetons. Quarante outils, c'est 8 000 à 15 000 jetons consommés avant que l'utilisateur ait posé sa question, sur chaque tour, pour tous les utilisateurs. La facilité de branchement de MCP pousse mécaniquement au catalogue large — on connecte trois serveurs tiers « parce que c'est gratuit » — et la facture suit. Nous avons vu ce seul mécanisme doubler un coût mensuel d'API sans qu'aucune ligne de prompt n'ait changé ; les leviers pour le reprendre en main sont les mêmes que d'habitude, et nous les avons détaillés ailleurs.
Le volume des réponses. MCP transporte, il ne trie pas. Un outil qui renvoie 2 000 lignes de CRM parce que le filtre était vide noie le contexte, coûte cher et dégrade la réponse. Le tri, la pagination et le résumé sont votre travail, dans le serveur, pas celui du protocole.
Les droits réels. La révision 2025-03-26 a introduit un cadre OAuth 2.1 pour le transport HTTP, affiné ensuite. Il authentifie le client auprès du serveur. Il ne dit rien de la question qui compte : est-ce que cet utilisateur-là a le droit de lire cette facture-là. Votre logique d'autorisation métier doit être réimplémentée dans le serveur MCP, sur l'identité propagée, sinon vous venez d'exposer un contournement propre de vos contrôles d'accès applicatifs. Ajoutez-y l'injection de prompt par le contenu retourné — un ticket dont le texte demande au modèle d'appeler un autre outil — et le fait qu'un serveur tiers non audité est du code qui s'exécute avec vos jetons d'accès.
La traçabilité. Rien dans le protocole ne dit quelle version d'un outil a produit quelle réponse. Si vous modifiez la description d'un outil un mardi et que le taux d'erreur monte le jeudi, c'est votre instrumentation qui vous le dira, ou personne. Les traces, les seuils et le retour arrière restent le travail d'exploitation habituel.
Le coût d'adoption, tel qu'il se présente en semaine trois
Trois choses surprennent systématiquement les équipes qui basculent.
La granularité. Le réflexe est de transposer une API REST en un outil par point d'entrée. On se retrouve avec quarante outils atomiques, un contexte saturé et un modèle qui enchaîne six appels pour une tâche. Les serveurs qui marchent exposent moins d'outils, plus larges, alignés sur des intentions métier — « trouver le contrat actif d'un client » plutôt que trois outils de lecture à composer. Compter huit à quinze outils par serveur comme ordre de grandeur sain.
La description est un prompt. Elle n'est pas de la documentation pour un développeur, c'est le seul élément qui décide si le modèle choisit le bon outil. Elle doit dire quand utiliser l'outil et quand ne pas le faire. C'est la partie qu'on réécrit le plus souvent, et celle qui fait le plus bouger le taux de réussite.
Les erreurs sont adressées au modèle. Un 500 Internal Server Error ne lui apprend rien. Un message qui dit que la date doit être au format AAAA-MM-JJ lui permet de réessayer correctement. C'est du travail de rédaction dans le code de gestion d'erreur, et il paie immédiatement.
Si vous héritez d'une intégration déjà bâtie sur MCP — un prestataire parti, un serveur que personne dans l'équipe n'a écrit — ces trois points sont exactement là où nous commençons quand nous prenons en charge une reprise de projet IA : la granularité explique la lenteur, les descriptions expliquent les erreurs de sélection, et le volume des réponses explique la facture.
La grille de décision
MCP ne vaut pas son coût si vous avez un seul client LLM, moins de six outils, un périmètre stable, ou une contrainte de latence forte sur un chemin critique. Dans ces cas, des fonctions outils dans votre code sont plus simples, plus rapides et plus faciles à déboguer. Le protocole ajoute alors un processus, un déploiement et une surface de panne pour un bénéfice nul.
MCP vaut son coût si au moins deux consommateurs existent aujourd'hui, si les outils appartiennent à des équipes différentes de celles qui écrivent les agents, si le catalogue change plus vite que votre cycle de déploiement, ou si vous voulez qu'un client externe — un agent chez votre client, un assistant du marché — puisse s'y connecter.
Ce dernier point est la seule raison stratégique, et elle sort du sujet de l'intégration interne : exposer un serveur MCP public, c'est rendre son produit utilisable par des agents qui ne sont pas les vôtres. Nous l'avons fait sur ce site — un serveur en Streamable HTTP sans état sur /mcp, quatre outils, une carte de serveur sur /.well-known/mcp/server-card.json pour que le client le découvre sans documentation. Le code utile tient en deux fichiers et une après-midi. La décision, elle, n'est pas technique : elle consiste à accepter que des agents lisent et utilisent votre produit sans passer par votre interface.
Par quoi commencer
Si la question « faut-il passer à MCP » est ouverte chez vous, ne commencez pas par le protocole. Comptez d'abord vos consommateurs réels, aujourd'hui, pas ceux du prochain trimestre. S'il y en a un seul, la réponse est non et vous venez d'économiser trois semaines. S'il y en a deux ou plus, prenez les trois outils les plus utilisés, exposez-les derrière un serveur, branchez-y le deuxième consommateur, et mesurez deux chiffres avant et après : les jetons consommés par requête et le taux de sélection correcte de l'outil. Ce sont les deux seuls qui disent si la migration vous a rapporté quelque chose. Tout le reste — le catalogue complet, les serveurs tiers, les ressources et les prompts — attend d'avoir cette preuve.
Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.
Votre projet IA a dérapé ?
POC bloqué, facture LLM qui triple, agent qui se trompe une fois sur cinq : on reprend l’existant, on mesure, on livre. Diagnostic en cinq jours.
Articles similaires
Le POC IA marchait : pourquoi il ne passe pas en production
Votre agent IA est en production : instrumentation, seuils d'alerte et retour arrière
