12 mars 2026
– 7 minutes de lecture
Hugues des Dorides
Consultant Architecture
MCP
Le MCP visant à faciliter l’accès d’un client via ses LLM à des ressources distantes, il se base sur une architecture client – serveur classique.
Du côté client, deux briques : l’hôte (application ou utilisateur via son application IA de chat, IDE, etc.) et le client (instance spécifique créée par l’hôte en vue de la communication avec le serveur MCP visé). Si l’hôte doit requêter plusieurs serveurs MCP différents, il instancier autant de clients MCP, afin de garder cette relation un-pour-un.
Concepts
Afin d’établir une communication entre client et serveur, il est nécessaire de connaître les capacités offertes par chacun. Dans MCP cela se fait via une notion appelée primitive. Client et serveur s’exposent des primitives l’un à l’autre.
Primitives exposées par le serveur :
- Prompt : template à réutiliser par les LLM comme guide de requête pour bien utiliser les capacités du serveur (par exemple donnant des paramètres à inclure dans une future requête) ;
- Ressource : données statiques (ou quasi) du serveur exposées, typiquement pour du cache : fichiers, réponses API ;
- Tool : fonctions (écrire dans BDD, appel API, écriture fichier) appelées par le LLM.
Ressource et tool semblent assez proches, l’un comme l’autre pouvant retourner de la donnée. La principale différence réside dans la manière de les contrôler : par l’application pour les ressources et par le modèle pour les tools. Autrement dit, les tools peuvent être appelés de manière autonome par le LLM, tandis que les ressources ne sont appelées que via un choix de l’utilisateur/application.
Primitives exposées par le client :
- Sampling (échantillonnage) : permet au serveur de demander au client d’utiliser son LLM pour une tâche, avec potentielle intégration d’une validation utilisateur. Le serveur MCP n’a ainsi pas besoin d’avoir un SDK de langage, ni de payer un abonnement à un LLM ;
- Elicitation : permet au serveur de demander de façon structurée des informations supplémentaires à l’utilisateur ;
- Roots (racines) : permet de préciser au serveur une organisation des dossiers & fichiers du client, une segmentation/structuration par domaine, ou par privilège. Le client précise ce périmètre d’accès afin que le serveur “comprenne” mieux où rechercher des informations du client. Attention, cela n’applique aucun contrôle d’accès, aucune sécurité. Tout cela doit être fait par ailleurs, hors du cadre du MCP ;
- Logging : envoi de messages log au client pour déboguer et monitorer.
Protocole
Le MCP utilisé du JSON-RPC 2.0. Sans rentrer trop dans le détail de chaque étape du protocole, la connexion commence par un handshake puis une découverte. Y sont échangés la version de protocole, les capacités supportées par le client et le serveur, notamment au travers de l’échange des primitives. Une fois ces primitives supportées connues, on peut les lister.
Par exemple, le serveur dit au client qu’il supporte les primitives type tools. Le client demande alors une liste de ces tools puis il peut faire les appels souhaités. Enfin, le serveur peut aussi envoyer des notifications pour prévenir le client de changements.
Intégration au SI
Le MCP ayant pour but de faciliter un accès à des ressources, il est essentiel de les protéger. Imaginons que notre serveur MCP ait comme outil des appels API sur une base de données. Il convient de gérer ces API de la même manière qu’on le ferait habituellement : plateforme d’API management, application de policies de rate limiting, gestion de l’authentification et de l’autorisation, etc.
Le MCP ne remplace en rien ces sécurités. Le besoin est au contraire accru car les appels issus d’IA sont potentiellement moins contrôlés qu’avec des applications/utilisateurs classiques où l’on choisit normalement mieux les appels générés. C’est pour cela que certains APIs Gateway gèrent aussi le filtrage et le routing de LLM, afin entre autres d’éviter d’envoyer des données critiques à des LLMs publiques.
A2A
Le protocole A2A se base lui aussi sur une notion de client-serveur. Un utilisateur final, qu’il soit humain ou non, fait une requête nécessitant des agents. L’agent client (application, service ou agent IA) vient initier une communication comme client vers un agent distant agissant comme serveur. Ce dernier a une bonne couche d’abstraction, du point de vue de l’agent client, l’agent distant est une boîte noire ayant des capacités d’intérêt.
Concepts
Afin de connaître ces capacités, l’agent expose son Agent Card (fichier JSON), qui va permettre la découverte. Elle contient une description, l’URL de l’endpoint du service, les options supportées, l’authentification nécessaire, …
Les deux agents communiqueront au moyen de Messages, représentant un tour de communication. Ce Message a un rôle : utilisateur ou agent. Surtout il contient une ou plusieurs parts.Une Part est la donnée utile transmise, que ce soit du texte, un fichier, une image, etc.
L’agent client fera une requête qui débouchera sur une Task (tâche) du côté agent distant. Cette tâche débouchera sur un Artefact, le résultat généré par l’agent distant, constitué de une ou plusieurs Parts.
Protocole
A2A utilise HTTPS pour le transport et JSON-RPC2.0 pour le format de payload.
Plusieurs mécanismes de découverte sont envisageables, selon les cas d’usages : exposer l’agent card serveur sur une URI standardisée, la référencer dans un catalogue d’entreprise, ou encore l’inscrire en dur dans le client. Selon le niveau de sensibilité pour l’entreprise des informations présentes sur la carte, il conviendra d’ajuster le niveau de protection nécessaire.
A2A peut donc utiliser des protocoles type OAuth2, OIDC. L’autorisation est gérée par le serveur, l’agent A2A distant, alors que l’authentification est typiquement déléguée à l’IAM de l’entreprise. Pour gérer au mieux la couche de sécurité, la performance et la cohérence entre les agents de l’entreprise, bref pour une meilleure gouvernance, il est conseillé d’intégrer ces serveurs A2A avec les solutions d’intégration type API management.
Si certaines requêtes sont simples, on peut s’attendre à une réponse immédiate, via un objet message. Inversement, si la requête est complexe, le traitement peut être long et donc nécessiter un objet tâche (ou plusieurs en parallèle). Il faut alors éviter de bloquer l’agent client. Donc trouver divers modes permettant d’avoir l’information d’avancement de la tâche et de son résultat. Notamment utiliser de l’asynchrone.
- En mode pooling (requête/réponse), le fonctionnement basique, une fois la tâche créée côté agent distant, le client demande régulièrement l’état de la tâche ;
- En mode streaming Server Sent Events (SSE), le serveur envoie l’état en temps réel, voire des résultats de manière incrémentale (à la manière d’un texte qui se complète peu à peu) ;
- En mode notification push, grâce à une webhook, le serveur communique sur des avancées significatives sur la tâche.
Grâce à ces divers modes, on peut ainsi être au courant qu’une tâche a été créée, de son avancement, qu’un artefact a été généré et enfin que la tâche est terminée.
A noter que même terminée ou rejetée, si besoin de raffiner une réponse, on pourra se référer au contexte d’une tâche précédente, mais toujours via une nouvelle. Pas de redémarrage d’une tâche passée.
MCP & A2A
A première vue, MCP & A2A pourraient se recouper.
En réalité, le MCP s’intéresse à faciliter et standardiser l’accès à des ressources par un agent. Le A2A s’intéresse à faciliter la communication entre agents en vue d’une tâche, la décomposer en sous-tâches mieux réparties.
Dès lors MCP et A2A se complètent. Pour résoudre une tâche complexe faisant appel à des données dispersées, on utilisera du A2A pour orchestrer la communication avec des agents spécialisés. Ces agents spécialisés utiliseront du MCP pour requêter les données nécessaires à la résolution du problème.
Un serveur A2A pourrait exposer des capacités en tant que ressources MCP si elles sont bien définies, accessibles avec du stateless, etc.
Parlons de votre projet !
11 février 2026
Architecture
