Le (MCP) Model Context Protocol suscite un intérêt grandissant, car il laisse entrevoir des agents IA plus connectés au système d’information. Mais derrière la promesse d’une intégration standardisée se trouvent des coûts de calcul, de développement, de formation et d’exploitation.
Si je peux comprendre la fascination technologique pour ces nouveaux outils, je suis convaincu qu’avant d’investir, les entreprises doivent aborder le MCP avec une logique de cas d’usage et de valeur.
Des opportunités à saisir…
Accélérer l’innovation interne et autonomiser les équipes
En facilitant la connexion des agents IA aux données et aux outils, le MCP peut par la même occasion faciliter la création d’agents par les métiers et les personnes non initiées.
Concrètement, le MCP fait sauter le verrou technique entourant la manipulation des API. Désormais on se connecte à un client MCP qui expose des serveurs MCP adossés à des données ou applications. Le tout sans trop se soucier d’une quelconque intégration spécifique, réduisant par la même le nombre d’intégrations nécessaires à la création d’agents.
Cette approche favorise également l’adoption d’un mode produit à l’échelle de l’entreprise. Les connexions aux données et aux applications deviennent des capacités mutualisées, maintenues et enrichies de manière continue, plutôt que des développements réalisés projet par projet. Les serveurs MCP constituent alors un patrimoine numérique réutilisable sur lequel de nouveaux agents peuvent être construits rapidement, accélérant l’innovation tout en améliorant la maîtrise des coûts et de la gouvernance.
Par exemple prenons les équipes RH et Finance d’une entreprise. Admettons qu’elles aient toutes les deux besoins d’accéder aux systèmes de paie et facturation. Il devient alors possible de mutualiser les développements en délivrant un seul serveur MCP exploitable par les deux équipes, plutôt que de réaliser deux intégrations séparées des APIs dans leurs agents respectifs.
Faciliter une stratégie multi-modèle
La standardisation de la connectivité rend l’architecture moins dépendante d’un fournisseur unique de LLM. Une entreprise peut ainsi faire évoluer les modèles utilisés sans redévelopper systématiquement toute la couche d’intégration.
En effet, les APIs n’étant plus directement intégrées dans les agents, leur déclenchement est beaucoup moins dépendant du LLM qui les orchestre. Changer de fournisseur de LLM pourrait donc impliquer moins de régressions puisque le MCP standardise les communications entre les LLM et les données.
Cette agnosticité technique constitue un levier pour les organisations qui souhaitent garder davantage de flexibilité dans leur stratégie IA.
… et des coûts à bien quantifier
Le MCP est présenté comme un standard open source n’impliquant pas directement de coût de licence. Cela ne signifie pas que son adoption est gratuite. Les dépenses se déplacent vers l’infrastructure, le développement, les compétences et le maintien en conditions opérationnelles.
Les coûts de calcul
Les agents et les serveurs MCP consomment des ressources. L’exécution des LLM, les appels successifs aux outils et le fonctionnement des serveurs génèrent une consommation qui doit être maîtrisée.
Une piste évoquée consiste à répartir les usages entre plusieurs modèles afin de mobiliser le niveau de puissance adapté à chaque tâche. Une bonne pratique est par exemple d’utiliser des modèles très spécialisés et moins consommateurs en tokens pour les serveurs MCP.
Les coûts de développement et de formation
Les serveurs MCP doivent être créés, intégrés au système d’information et raccordés aux ressources existantes. Les équipes SI comme les métiers doivent également être formées au fonctionnement du MCP et à ses bonnes pratiques(voir mes autres articles Avec les agents IA, un nouvel utilisateur entre dans le système d’information et Gouverner les serveurs MCP : Sept règles pour passer du prototype à l’échelle pour creuser les bonnes pratiques).
La réutilisation des API existantes peut réduire une partie de l’effort. Elle ne supprime toutefois ni la conception des serveurs ni leur intégration.
Les coûts opérationnels
Le MCP fait apparaître un nouvel environnement à maintenir que ce soit en termes de supervision, de sécurité, de gestion des mises à jour, de traitement des incidents ou encore de suivi de la consommation.
Ces coûts pourraient être compensés par la rationalisation ou le décommissionnement d’autres solutions, mais cet équilibre doit être démontré au cas par cas.
Le MCP ne remplacera pas l’architecture existante
Dans la réalité, le SI ne composera pas uniquement de serveurs MCP. Ce protocole ne doit donc pas être perçu comme une couche magique. Il n’est pas capable de corriger les faiblesses existantes du système d’information. Une API médiocre reste une API médiocre, même exposée via MCP. Les données sous-jacentes peuvent être de mauvaise qualité ou les performances API insuffisantes. Dans ce cas, les agents reproduiront les mêmes défauts.
Le protocole standardise l’accès aux capacités existantes, il n’en améliore ni la qualité ni la maturité. Autrement dit, « garbage in, garbage out » s’applique également au MCP. Il doit donc être envisagé comme une brique supplémentaire de l’architecture d’entreprise et non comme le remplacement immédiat de tous les flux existants.
Comment construire un business case pertinent ?
Une démarche pragmatique (mais cependant non exhaustive) peut s’appuyer sur quatre questions :
- Les mêmes capacités seront-elles réutilisées par plusieurs agents ?
- Les API sous-jacentes existent-elles déjà ?
- Quel niveau de contrôle humain faut-il conserver ?
- Quels coûts ou développements spécifiques le MCP permet-il effectivement d’éviter ?
Ces questions constituent une proposition méthodologique. Elles doivent bien sûr être adaptées au contexte, aux contraintes et aux indicateurs de chaque organisation. N’hésitez pas à nous contacter pour en discuter !
