Depuis plusieurs mois chez Talisker, nous observons une recrudescence des discussions autour du passage à l’échelle des systèmes IA chez nos clients. Que ce soit au sein des opérations, des métiers ou de la DSI, les « POC IA » se multiplient sans réussir à passer à l’échelle (et ainsi trouver leur valeur). C’est le cas pour les agents IA connectés au système d’information : complexités de développements liés à l’utilisation d’APIs spécifiques, supports techniques à mettre en place, garde-fous encore incertains et mal maitrisés… Le passage à l’échelle est souvent freiné par de nombreuses contraintes.
Cependant, la valeur de ces agents IA est réelle, car ils ne se contentent pas de produire une réponse : ils peuvent désormais décomposer un objectif, mobiliser plusieurs outils et enchaîner des actions sans intervention d’un utilisateur.On l’appelle l’IA agentique.
Cette évolution soulève cependant des questions d’intégration : comment permettre à ces agents d’interagir efficacement avec les données et les applications de l’entreprise, en évitant notamment la multiplication du nombre de développement ? C’est précisément la promesse du Model Context Protocol, plus connu sous le nom de MCP.
Les limites des approches classiques : API et LLM
Aujourd’hui les APIs permettent déjà aux systèmes d’interagir avec des données structurées, en lecture comme en écriture. Elles présentent néanmoins plusieurs limites dans un contexte agentique : elles sont souvent spécifiques à un usage, ne proposent pas nécessairement de mécanisme de découverte dynamique et n’intègrent pas directement la contextualisation attendue par un LLM (Large Language Model).
À l’inverse, les approches fondées sur les LLM et les technologies RAG (Retrieval Augmented Generation) facilitent l’accès à des contenus structurés ou non structurés afin de contextualiser une réponse. Elles restent toutefois principalement orientées vers la lecture et ne permettent pas, seules, de déclencher des actions dans d’autres systèmes.
Ce que change le MCP
Le MCP introduit une couche standardisée entre l’agent IA et les différentes ressources de l’entreprise. Son architecture repose notamment sur trois composants :
- L’hôte MCP, ou plus simplement l’agent IA doté d’un LLM;
- Le client MCP, qui joue le rôle de traducteur entre le LLM et les outils ;
- Les serveurs MCP, qui exposent de manière standardisée les données, les fonctions ou les API disponibles. Il décrit ce que permettent les bases de données ou les API associées. Il précise également les informations nécessaires en entrée et les données renvoyées en sortie.
Avec ce protocole, l’agent peut alors comprendre les outils disponibles avant de les appeler.
En d’autres termes, le MCP ne remplace pas obligatoirement les API. Il les rend plus facilement compréhensibles et mobilisables par les agents IA.
Un exemple concret
Imaginons la demande suivante : « Prépare un compte-rendu, identifie les actions et crée les tâches dans l’outil de suivi. »
Pour atteindre cet objectif, l’agent doit :
- identifier la réunion concernée ;
- retrouver son contenu ou sa transcription ;
- rédiger le compte-rendu ;
- identifier les actions ;
- interroger les outils disponibles ;
- créer les tâches avec les informations requises.
Si certaines données sont manquantes, l’agent peut revenir vers l’utilisateur. Il peut par exemple demander à quelle réunion celui-ci fait référence ou solliciter un groupe d’affectation nécessaire à la création d’un ticket (pour un exemple plus illustré, voir mon autre article : Comprendre le MCP avec une métaphore simple)
Le MCP en facilitateur du passage à l’échelle
L’un des principaux freins au passage à l’échelle des agents IA réside dans le coût de développement et de maintenance des intégrations. Le MCP répond en partie à cette problématique en favorisant leur mutualisation. En effet, chaque agent nécessite généralement le développement de connecteurs ou d’interfaces spécifiques pour accéder aux systèmes de l’entreprise. Avec le modèle MCP, l’approche est différente : un serveur MCP n’est développé qu’une seule fois et peut ensuite être consommé par l’ensemble des agents qui y sont connectés. Les coûts d’intégration sont ainsi mutualisés, ce qui permet d’améliorer le retour sur investissement en multipliant les cas d’usage couverts, sans avoir besoin de répliquer les mêmes développements.
Par ailleurs, le MCP contribue à pérenniser l’écosystème d’agents dans le temps. Lorsqu’une API évolue ou est remplacée, il n’est plus nécessaire de modifier chaque agent qui l’utilise. Seul le serveur MCP assurant l’interface avec cette API doit être adapté. Cette couche d’abstraction réduit fortement les efforts de maintenance, limite les risques de régression et facilite l’évolution du système d’information tout en préservant les agents existants.
Vers des applications pensées pour les agents ?
Le MCP invite finalement les entreprises à revoir leur manière de concevoir l’intégration. Les logiciels actuels sont principalement construits pour être utilisés par des humains. Demain, une partie d’entre eux pourrait également être conçue pour être interprétée et actionnée par des intelligences capables de raisonner sur un objectif.
Le véritable enjeu n’est donc pas seulement technique : il consiste à préparer un système d’information dans lequel humains, agents IA, API et applications pourront coopérer sans multiplier les intégrations spécifiques
