MCP, A2A, tool calling : les protocoles des agents expliqués

Le protocole A2A organise les échanges entre agents indépendants ; MCP fournit une interface commune pour connecter une application IA à des outils et à des données. Le tool calling, ou appel d’outils, permet au modèle de demander une opération structurée que l’application ou un service exécutera. Ces mécanismes peuvent intervenir dans une même tâche, chacun à un endroit différent du parcours.

Des connexions qui répondent à des besoins distincts

Un agent ne consulte pas spontanément vos fichiers ou votre logiciel de facturation. Son application doit lui présenter des capacités disponibles, transmettre ses demandes et récupérer les résultats. Lorsqu’elle sollicite un autre agent, elle doit aussi gérer une relation avec un système qui possède son propre fonctionnement.

Les termes se ressemblent parce qu’ils concernent tous des échanges. Pourtant, le tool calling est un mécanisme proposé par des interfaces de modèles, avec des formats propres aux fournisseurs. MCP et A2A définissent des échanges standardisés entre logiciels. Le tableau situe leurs responsabilités, sans en faire des solutions concurrentes.

Repère	Tool calling	MCP	A2A
Relation organisée	Modèle et environnement d’exécution	Application cliente et serveur de capacités	Client et agent distant
Objet de l’échange	Demande d’opération et arguments	Outils, données et modèles d’instructions	Messages, tâches et résultats
Découverte	Fonctions présentées au modèle	Capacités exposées par le serveur	Capacités décrites par une Agent Card
Responsabilité principale	Formuler un appel exploitable	Rendre une intégration réutilisable	Organiser une collaboration entre systèmes

La documentation officielle décrit A2A et MCP comme complémentaires. Cette distinction concerne l’interface exposée : un service complexe peut être présenté comme un outil, et un agent distant peut lui-même utiliser des outils.

Pour les bases de la boucle qui choisit et enchaîne ces opérations, l’article Agent IA ou chatbot : quelle différence ? explique le rôle de l’application autour du modèle.

Le tool calling : demander une opération précise

L’appel d’outils commence par une description : nom de la fonction, usage prévu et paramètres acceptés. Le modèle reçoit cette description avec la demande de l’utilisateur. Il peut alors produire un appel structuré plutôt qu’une réponse destinée à être lue.

Dans une application de facturation fictive, il pourrait demander une recherche de factures pour un client donné. Le logiciel vérifie les paramètres, applique les autorisations, interroge le système métier et retourne le résultat. Le modèle peut ensuite expliquer ce résultat ou proposer une nouvelle action.

Cette séparation est essentielle : produire un appel ne signifie pas l’avoir exécuté. La documentation d’Anthropic sur l’utilisation des outils distingue les outils exécutés par l’application et ceux exécutés sur l’infrastructure du fournisseur. Il faut donc identifier où chaque opération se déroule.

Un schéma de paramètres aide à obtenir une demande exploitable. Il ne garantit pas que le client choisi soit le bon, que le montant soit justifié ou que l’utilisateur ait demandé cette action. Ces vérifications relèvent aussi du logiciel et des règles métier.

Pour une application limitée à quelques fonctions internes, déclarer directement ces fonctions peut suffire. Ajouter un protocole de connexion devient utile lorsqu’il faut partager les mêmes capacités avec plusieurs applications, maintenir leur découverte ou séparer leur exploitation du code de l’assistant.

MCP : une interface commune vers les capacités externes

Le Model Context Protocol sépare l’application hôte, le client qui communique et le serveur qui expose des capacités. Ce dernier peut fonctionner sur votre machine ou à distance. Le mot « serveur » désigne ici un programme, sans imposer l’achat d’une machine dédiée.

Selon l’architecture officielle de MCP, l’application hôte coordonne ses clients, chacun associé à un serveur. Les échanges locaux peuvent passer par l’entrée et la sortie standard du processus ; les connexions distantes peuvent utiliser Streamable HTTP.

Le bénéfice attendu est la réutilisation de l’interface. Un service peut exposer ses capacités selon MCP plutôt que maintenir une intégration particulière pour chaque application. Cela ne supprime ni la configuration, ni les différences de prise en charge entre clients.

La documentation distingue les capacités proposées par les serveurs MCP :

• les outils, qui réalisent une opération ou récupèrent une information ;
• les ressources, qui fournissent du contenu à utiliser comme contexte ;
• les prompts, qui proposent des modèles d’instructions réutilisables.

L’application peut présenter au modèle les outils découverts, recevoir sa demande par tool calling, puis transmettre l’opération au serveur MCP. Le protocole de connexion et le mécanisme de décision travaillent alors ensemble.

Un serveur MCP ne choisit donc pas nécessairement un objectif et ne conduit pas automatiquement une mission. Pour examiner les intégrations disponibles, consultez les fiches des serveurs MCP ; le guide Choisir un serveur MCP détaille les critères de confiance et de permissions.

Le protocole A2A : dialoguer avec un autre agent

A2A, pour Agent2Agent, s’adresse aux systèmes qui souhaitent communiquer avec un agent indépendant. Le client lui adresse une demande sans devoir connaître son modèle, sa mémoire ou ses outils internes. Cette séparation permet notamment de conserver des architectures différentes de chaque côté.

Les concepts fondamentaux d’A2A distinguent le client qui initie l’échange et l’agent distant qui traite la demande. Ce dernier expose une Agent Card : une description de son identité, de ses compétences et de ses capacités d’interaction.

Cette carte aide à déterminer si le service semble adapté à une mission. Elle ne constitue pas une certification de qualité. Une compétence déclarée doit encore être évaluée sur des demandes représentatives, avec des critères de résultat explicites.

A2A peut servir à demander une analyse à un système spécialisé, puis à poursuivre l’échange lorsqu’il manque une information. Le demandeur n’a pas besoin de dicter chaque appel technique. Il doit en revanche préciser le résultat attendu et les contraintes à respecter.

Le terme protocole A2A ne désigne pas toute conversation entre agents. Des sous-agents appartenant à une même application peuvent communiquer par des mécanismes internes. A2A apporte un contrat d’échange lorsque cette interaction traverse une frontière entre systèmes.

De même, rendre un agent accessible par A2A ne prouve pas qu’il sache collaborer utilement. La pertinence dépend du découpage du travail : une responsabilité claire et un livrable vérifiable sont plus faciles à exploiter qu’une délégation vague.

Des tâches suivies et des livrables identifiables

Une demande adressée à un agent distant peut nécessiter plusieurs échanges. Le cycle de vie des tâches A2A prévoit une réponse immédiate par message ou une tâche avec état. Celle-ci peut progresser, demander une information supplémentaire, échouer ou se terminer.

L’application cliente doit interpréter cet état. Une tâche qui attend une précision ne doit pas être présentée comme achevée ; une tâche échouée ne doit pas produire silencieusement une réponse de remplacement. L’interface utilisateur fait donc partie de la fiabilité de l’ensemble.

La spécification A2A sépare les messages de communication et les artifacts, c’est-à-dire les livrables associés à une tâche. Elle prévoit aussi différents moyens de recevoir des mises à jour, dont l’interrogation périodique, le flux d’événements et les notifications, selon les capacités annoncées.

Pour votre application, cette distinction permet de séparer un commentaire d’avancement du document final à exploiter. Il reste à définir ce qui rend ce document acceptable : format attendu, provenance des données, informations manquantes et contrôles nécessaires.

Un état technique terminé signifie que le traitement annoncé est fini. Il ne garantit pas l’exactitude du contenu produit. Le guide sur les systèmes multi-agents aide à évaluer l’intérêt de cette délégation et la charge de coordination qu’elle ajoute.

Exemple : préparer une relance de facturation

Prenons un scénario fictif : vous demandez de préparer les relances des factures impayées, avec validation avant envoi. L’application principale doit consulter les données comptables, traiter les situations particulières et vous présenter les brouillons.

Les mécanismes peuvent s’enchaîner ainsi :

1. L’application découvre, par MCP, les outils autorisés de consultation des factures.
2. Le modèle demande cette consultation par tool calling ; l’application transmet l’opération et récupère les données.
3. Si un agent spécialisé doit examiner les dossiers litigieux, l’application lui confie cette analyse par A2A.
4. Elle suit la tâche distante, récupère son livrable et prépare les relances à vous soumettre.

Cet exemple illustre une architecture possible, pas une intégration prête à l’emploi. Chaque connexion exige une prise en charge effective, des autorisations adaptées et un accord sur les données échangées.

Il montre aussi où placer les contrôles. Lire une facture, transmettre son contenu à un service distant et envoyer un courrier sont des actions différentes. L’autorisation de consultation ne devrait pas être interprétée comme une autorisation générale de diffusion.

Si les règles de relance sont fixes, une automatisation classique peut suffire. Le choix entre plateformes relève d’un autre examen, traité notamment dans le comparatif n8n vs Make. Le protocole ne remplace pas ce choix d’architecture.

Compatibilité et sécurité : vérifier le parcours complet

La mention compatible MCP ou A2A ne décrit pas toute une intégration. Vérifiez les capacités réellement prises en charge, les modalités d’authentification, le traitement des erreurs et la restitution des résultats. Un échange techniquement accepté peut rester inutilisable pour votre processus.

Les bonnes pratiques de sécurité MCP abordent notamment les risques liés aux serveurs locaux, aux intermédiaires d’autorisation et à la transmission des jetons d’accès. Brancher un serveur local revient à autoriser l’exécution d’un programme : son origine et ses droits méritent un examen.

Pour une délégation distante, précisez quelles données peuvent quitter l’application et sous quelle identité les actions seront réalisées. Le service destinataire doit appliquer ses propres contrôles ; la demande du modèle ne constitue pas une preuve d’autorisation.

Les contenus retournés restent également des données externes. Un document, une description d’outil ou un livrable peut contenir des instructions trompeuses. L’article consacré à la sécurité des intégrations MCP et des skills détaille les vérifications avant installation.

Avant d’élargir les accès, testez un parcours complet comprenant une erreur, un refus et une interruption. Vous devez pouvoir comprendre ce qui a été demandé, exécuté et transmis. Un protocole standardise les échanges ; la maîtrise des actions dépend de l’application qui les autorise et les contrôle.

Questions fréquentes

Que signifie A2A pour les agents IA ?

A2A signifie Agent2Agent. Ce standard décrit les échanges entre systèmes d'agents indépendants, même lorsque leur fonctionnement interne reste privé. Une intégration doit prendre en charge les interfaces et capacités nécessaires à l'échange.

Peut-on utiliser MCP sans protocole A2A ?

Oui : un assistant connecté à des outils n'a pas besoin de déléguer à un autre agent. A2A devient pertinent lorsqu'un système doit échanger avec un service agentique indépendant. Le nombre d'outils disponibles ne suffit donc pas à justifier son ajout.

Le tool calling nécessite-t-il un serveur MCP ?

Non : une application peut déclarer directement ses fonctions au modèle et exécuter les appels reçus. MCP sert à fournir une interface commune pour découvrir et utiliser des capacités externes. Le choix dépend notamment du besoin de réutiliser ces connexions dans plusieurs applications.

Un agent compatible A2A peut-il accéder à tous mes outils ?

La compatibilité ne lui accorde aucun accès général à vos comptes. Les autorisations dépendent du service, de l'identité utilisée et des contrôles appliqués côté serveur. Il faut également examiner les données incluses dans chaque délégation.