A2A Protocol : quand l’utiliser, avec ou sans MCP

A2A Protocol, ou protocole A2A, sert à déléguer une mission à un agent exploité de manière indépendante. Model Context Protocol (MCP) sert à donner à votre agent accès à des outils ou à des données. A2A v1.0 modifie le contrat d’intégration : le choix dépend donc à la fois de ce que vous reliez et des versions prises en charge par vos points de terminaison.

MCP vs A2A : accéder à des outils ou déléguer une mission ?

MCP donne à un agent accès à des capacités. A2A lui permet de confier une partie du travail à un autre agent. Les deux peuvent coexister dans un même système.

Model Context Protocol (MCP) standardise la connexion d’une application d’IA à des systèmes externes, notamment des outils et des sources de données. Agent2Agent (A2A) standardise la communication entre agents indépendants. La documentation officielle les présente comme complémentaires. Présentation de MCP, A2A et MCP.

Exemple avec MCP : retrouver une commande

Un agent de support client doit répondre à une question sur une livraison. Un serveur MCP expose un outil de recherche de commandes. L’agent lui transmet un identifiant de commande, récupère les données et rédige la réponse au client.

L’intérêt métier tient à la connexion réutilisable avec le système de gestion des commandes. Il n’est pas nécessaire d’ajouter un agent pour consulter un enregistrement. Le guide des serveurs MCP détaille ce volet du choix : la connexion aux outils.

Exemple avec A2A : déléguer une présélection de fournisseurs

Un assistant achats doit établir une présélection de fournisseurs adaptés. Un agent de sourcing distinct, exploité par un autre prestataire, prend en charge le workflow de recherche. L’assistant achats transmet les critères, répond à une demande de précision sur les besoins de livraison, puis reçoit une présélection structurée.

L’assistant achats n’a pas besoin de connaître la méthode de recherche de l’agent de sourcing, le modèle qu’il utilise ou l’organisation de ses étapes internes. Il lui faut une demande convenue et un résultat exploitable. C’est cette relation entre deux systèmes qu’A2A vise à prendre en charge.

L’agent de sourcing pourrait utiliser MCP en interne pour récupérer les données d’un catalogue. Dans cette architecture, A2A porte la délégation ; MCP fournit l’accès aux données.

La distinction porte sur l’interface dont vous avez besoin. Un outil MCP peut masquer une logique d’implémentation sophistiquée. Choisissez A2A si vous souhaitez exposer l’autre système comme un agent dont on peut découvrir les compétences et suivre le travail tout au long de son cycle de vie. L’intelligence apparente de son fonctionnement interne n’est pas le critère de choix.

A2A Protocol : à quoi sert ce protocole ?

A2A définit un contrat de communication commun pour des agents conçus par des fournisseurs différents ou avec des frameworks différents. L’appelant peut interagir avec un agent sans accéder à sa mémoire interne, à ses outils ni à sa logique de décision. Le site du protocole qualifie ces éléments internes d’opaques. Présentation d’A2A.

L’appelant est le client A2A ; le système qui accepte la demande est le serveur A2A, aussi appelé agent distant. Pour un fondateur qui achète une capacité spécialisée, l’intégration peut ainsi se concentrer sur l’interface du service, sans avoir à reconstruire son implémentation.

Qui a créé A2A et qui le gouverne ?

La formulation du site officiel est précise : « A2A a été initialement développé par Google, qui en a fait don à la Linux Foundation. » Le site indique qu’un comité de pilotage technique assure la maintenance du projet. Sa gouvernance dépasse donc le cadre de son créateur initial. Gouvernance et open source.

Le dépôt a2aproject/A2A est le point d’entrée du projet pour accéder à la spécification, aux liens vers les SDK et aux exemples. A2A est un protocole : il reste à choisir les logiciels avec lesquels construire et exploiter vos agents.

Spécification A2A : les notions à maîtriser

Il faut distinguer la conversation, le travail dont on suit l’avancement et le livrable. Cette séparation facilite la conception d’un système fondé sur le protocole.

Agent Card : comment connaître les capacités d’un agent ?

Une Agent Card est un document de métadonnées JSON qui décrit l’identité, les compétences, les capacités, les informations de connexion et les exigences d’authentification d’un agent. Elle aide le client à décider s’il doit contacter cet agent, et comment. Concepts fondamentaux.

Dans notre exemple, cette fiche pourrait annoncer des compétences de recherche de fournisseurs. C’est le point de départ de l’intégration, sans pour autant prouver que la présélection obtenue répondra à vos critères d’achat.

Le chemin de découverte standard documenté est /.well-known/agent-card.json. Les fiches peuvent aussi être obtenues par configuration directe ou via un registre organisé. A2A ne prescrit pas d’API standard pour ces registres. Découverte des agents.

Tâches, messages, Parts et artefacts

Une tâche est une unité de travail avec état, dotée d’un identifiant et d’un cycle de vie. Un message correspond à un tour d’échange. Une Part contient le texte, le contenu d’un fichier ou sa référence, ou encore des données structurées. Un artefact est un résultat concret produit au cours d’une tâche. Concepts fondamentaux.

Dans l’exemple des fournisseurs, « Dans quelle zone faut-il livrer ? » relève de la communication. La mission de sourcing dont on suit l’avancement constitue la tâche. La présélection terminée est un artefact. Votre workflow achats doit exploiter cette présélection comme un livrable, sans devoir fouiller dans une conversation pour trouver ce qui ressemble à un résultat final.

Un agent peut renvoyer un message autonome ou créer une tâche. Les interactions liées sont regroupées par contextId. Une fois qu’une tâche atteint un état terminal, une demande d’ajustement ouvre une nouvelle tâche au lieu de relancer l’ancienne. Cycle de vie d’une tâche.

Cette distinction compte lorsque l’acheteur modifie ses critères après la livraison. La présélection initiale doit rester identifiable et sa révision constituer un nouveau travail. Les utilisateurs en aval peuvent ainsi savoir quel résultat ils ont approuvé.

Transports : comment le contrat se traduit-il sur la connexion ?

Un transport, ou binding de protocole, définit la manière dont les opérations sont transmises sur la connexion. La spécification définit des bindings JSON-RPC, gRPC et HTTP+JSON/REST. Les interfaces de l’Agent Card indiquent le point de terminaison, le binding et la version du protocole. Spécification A2A.

L’interrogation périodique, le streaming et les notifications push déterminent la manière dont arrivent les mises à jour d’une tâche. Ce choix est distinct de celui du binding. Pour un tableau de bord achats, une interrogation périodique peut suffire ; pour une expérience interactive, des mises à jour progressives peuvent être nécessaires. Vérifiez les fonctionnalités réellement prises en charge par le point de terminaison avant de concevoir l’interface autour d’elles.

Qu’est-ce qui change avec A2A v1.0 ?

Les intégrations existantes doivent faire l’objet d’une revue de compatibilité : changer une chaîne de version ne suffit pas. Les changements ci-dessous sont ceux que décrit la page officielle des nouveautés, qui compare v0.3.0 à v1.0 :

• Une définition commune : a2a.proto devient la définition de référence du protocole, avec des spécifications formelles pour les bindings.
• De nouveaux formats d’échange : une Part unifiée remplace les types de contenu distincts ; les noms des membres remplacent les discriminateurs kind, et les valeurs d’énumération utilisent SCREAMING_SNAKE_CASE.
• Des Agent Cards réorganisées : supportedInterfaces regroupe les détails de connexion, avec une version du protocole déclarée pour chaque interface.
• Des opérations modifiées : message/send devient SendMessage ; ListTasks ajoute une liste filtrable avec pagination par curseur.
• Des évolutions pour l’entreprise : les champs de tenant, les règles de vérification des signatures des Agent Cards et les changements des flux OAuth ont des conséquences sur la conception des intégrations.

Ces changements ont été vérifiés dans la page des nouveautés de la v1.0 du projet le 12 octobre 2026.

Pour un connecteur existant, examinez ensemble les requêtes sérialisées, le traitement des réponses, la découverte des fiches et les opérations utilisées. Une connexion qui fonctionne ne prouve pas que toutes les interactions se comportent encore correctement.

Quels frameworks et plateformes prennent en charge A2A ?

Des implémentations sont documentées, mais les versions et les fonctionnalités couvertes varient. Choisissez en fonction du comportement requis par votre workflow. Les capacités et les limites ci-dessous ont été vérifiées dans la documentation publique de chaque éditeur le 12 octobre 2026 ; aucun test n’a été réalisé dans les produits avec un compte connecté.

Google Agent Development Kit

Google Agent Development Kit (ADK), un framework de développement d’agents, documente to_a2a pour exposer un agent et générer son Agent Card. Son intégration A2A en Python est marquée expérimentale. La documentation indique la prise en charge d’a2a-sdk 0.3.x et 1.x.x, et oriente les nouvelles intégrations vers 1.x.x. Guide ADK pour exposer un agent.

ADK documente aussi RemoteA2aAgent pour appeler un agent distant. Un développeur qui utilise ADK dispose donc de points d’entrée documentés des deux côtés de la délégation. Le statut expérimental doit peser dans la décision de déploiement, même si cette couche d’intégration est pratique. Guide ADK pour appeler un agent distant.

LangGraph via LangSmith Agent Server

LangSmith Agent Server, la couche d’exécution documentée pour les déploiements LangGraph, expose un point de terminaison A2A à l’adresse /a2a/{assistant_id}. Sa documentation précise qu’il utilise le binding JSON-RPC v1.0 et accepte les noms de méthodes v0.3. L’état du graphe doit contenir un champ messages. Documentation A2A de LangSmith.

La même page en précise les limites : gRPC et HTTP+JSON ne sont pas implémentés, et SubscribeToTask ainsi que la configuration des notifications push ne sont pas encore pris en charge. Le streaming d’un message est disponible, mais cela ne signifie pas que toutes les opérations d’abonnement ou de notification existent. C’est une raison concrète de vérifier les opérations couvertes avant de choisir une architecture de traitement en arrière-plan.

CrewAI et CrewAI AMP

CrewAI, un framework de coordination d’agents, documente A2AClientConfig pour la délégation à distance et A2AServerConfig pour exposer des agents. Un même agent peut être configuré pour les deux rôles. Documentation de la délégation dans CrewAI.

CrewAI AMP, sa plateforme de déploiement, présente les agents serveurs A2A comme une version préliminaire et indique les versions 0.2 et 0.3 du protocole. La plateforme décrit aussi un stockage distribué persistant qui remplace l’état conservé en mémoire de l’implémentation open source. La prise en charge d’A2A par CrewAI ne permet donc pas de supposer qu’un point de terminaison AMP accepte la v1.0. A2A sur AMP.

Microsoft Foundry Agent Service

Microsoft Foundry Agent Service, une plateforme managée d’agents, documente un type d’outil a2a en disponibilité générale pour la version 1.0 du protocole. Son ancien type d’outil a2a_preview prend en charge la version 0.3 et reste en préversion. Microsoft recommande le type en disponibilité générale pour les nouvelles intégrations. Documentation A2A de Foundry.

La page précise également que les agents Foundry ciblés ne prennent en charge que le texte et ne proposent pas de réponses en streaming. Un workflow qui exige un livrable multimédia transmis en streaming doit tenir compte de cette limite. Les types de contenu prévus par un protocole ne garantissent pas que toutes les plateformes d’hébergement les implémentent.

Le comparatif des frameworks d’agents IA vous aidera à choisir un framework dans son ensemble. Ces indications d’intégration répondent à une question plus précise : quelle interface A2A le système qui expose les agents documente-t-il ?

Ce que cela change pour les développeurs, les exploitants et les acheteurs

Le bénéfice est une interface d’intégration plus réutilisable, à condition que le service ajouté justifie son exploitation. Les conséquences varient selon la personne qui porte la décision.

Développeurs : définissez ce que vous déléguez avant d’ajouter un transport. « Produire une présélection avec des sources et des justifications » relève d’un service. « Exécuter cette recherche en base de données » relève d’un outil. Gardez cette distinction, même si les deux finissent par déclencher des appels à des modèles.

Exploitants : désignez un responsable de la tâche après sa délégation. Dans l’exemple des achats, quelqu’un doit décider de la suite si l’agent de sourcing demande des précisions, cesse de répondre ou renvoie une présélection qui ne satisfait pas les critères d’acceptation. Un format de message commun ne répartit pas ces responsabilités.

Acheteurs et fondateurs : demandez la version du protocole, le binding, les opérations, les types de contenu et le statut de déploiement pris en charge. Confrontez ces éléments aux exigences de votre workflow. Une simple déclaration de compatibilité, sans ces détails, ne suffit pas pour s’engager dans une intégration.

Comment budgéter un déploiement A2A ?

Il n’existe pas de configuration de déploiement A2A unique à partir de laquelle calculer une facture mensuelle. Un spécialiste hébergé et un service que vous exploitez vous-même n’ont pas les mêmes postes de coût. La documentation du protocole ne fixe pas non plus de tarif universel pour les plateformes.

Pour préparer le budget, appliquez cette équation sur une même période :

Bénéfice net de l’intégration = coûts de connecteurs évités moins coûts de migration, coûts d’infrastructure supplémentaires et coûts d’exploitation récurrents.

Incluez dans l’exploitation l’usage des modèles, l’hébergement, le stockage des tâches, la supervision et la prise en charge des incidents. Utilisez vos propres coûts pour chaque terme. A2A se justifie lorsque la réduction des intégrations répétitives compense la nouvelle interface de service à maintenir.

Quelles promesses autour d’A2A faut-il relativiser ?

Un protocole commun ne rend pas fiables des agents que vous ne connaissez pas et ne garantit pas la fiabilité d’un travail distribué. La standardisation est utile, mais les décisions applicatives restent de votre ressort.

Une Agent Card annonce ce qu’un service propose. C’est toujours à vous de décider si vous faites confiance à son exploitant et si vous acceptez son résultat. Les recommandations d’A2A pour l’entreprise confient à l’implémentation l’application des règles d’authentification et d’autorisation, y compris les permissions sur les actions sous-jacentes. Recommandations d’implémentation en entreprise.

Dans le workflow de sourcing, autorisez la recherche sans accorder implicitement le droit d’acheter. Renvoyer une recommandation et passer une commande doivent relever de permissions distinctes dans votre application.

Gérez séparément l’artefact reçu, le statut de sa tâche et votre propre trace d’acceptation. Avant d’autoriser un workflow délégué à créer un bon de commande, définissez comment l’application repère les actions métier répétées et résout une situation dont l’issue est incertaine.

Autre excès : ajouter A2A à chaque appel interne à un sous-agent. Le périmètre du projet exclut explicitement de prescrire les appels internes d’un agent à ses sous-agents ou à ses outils. Si les composants relèvent du même contrat applicatif, les mécanismes de composition natifs de votre framework peuvent déjà suffire. Périmètre d’A2A.

Faut-il choisir A2A, MCP ou les deux ?

Partez des systèmes que votre produit doit réellement relier aujourd’hui.

Choisissez MCP lorsqu’un agent a besoin d’accéder à des systèmes métier, à des fichiers ou à des API via des interfaces d’outils réutilisables. Si vous devez vous-même exposer une capacité, suivez le guide de création d’un serveur MCP en Python. Lorsque l’enjeu devient de gouverner les accès à travers ces connexions, le guide des passerelles MCP traite cette couche.

Choisissez A2A lorsqu’un autre agent, exploité de manière indépendante, prend en charge une véritable mission et qu’il vous faut un moyen commun de découvrir son interface, d’échanger des instructions et de suivre le travail qui en découle. Passez à l’action si ce besoin d’intégration existe déjà et si les points de terminaison documentent des fonctionnalités compatibles.

Choisissez les deux lorsque votre agent délègue à un spécialiste qui a lui-même besoin d’outils et de données. L’exemple du sourcing correspond à ce cas : A2A pour la mission de recherche déléguée, MCP pour l’accès au catalogue à l’intérieur d’un agent.

Attendez avant d’adopter A2A si le spécialiste externe est encore hypothétique. L’apparition d’un nouveau protocole entre agents ne change rien pour un agent qui fonctionne correctement avec ses outils actuels. Vous n’avez pas non plus besoin de l’un ou l’autre standard pour chaque appel de fonction interne. Adoptez le contrat de connexion qui résout un véritable problème d’intégration.

Par quoi commencer concrètement ?

Rédigez le contrat de délégation pour un résultat métier bien délimité avant de migrer le reste de votre stack. Pour un assistant achats, commencez par une présélection de fournisseurs et laissez l’exécution des achats hors du périmètre initial.

1. 1

   Définir un artefact acceptable

   Précisez les informations que la présélection doit contenir, ce qui la rendrait inacceptable et l’application qui enregistre le résultat accepté. Confiez à l’agent distant une responsabilité délimitée.

2. 2

   Vérifier la compatibilité des interfaces documentées

   Consignez les versions du protocole côté client et serveur, le binding, les exigences d’authentification et les opérations nécessaires. Vérifiez si le workflow exige du streaming ou des notifications push, et si les deux points de terminaison les prennent en charge.

3. 3

   Prévoir les cas où le travail n’aboutit pas

   Décidez qui gère les demandes de précision, les délais d’attente dépassés, les rejets et les réponses incertaines après une nouvelle tentative. Définissez ce que voit l’utilisateur tant que le travail est en attente, ainsi que la manière dont un artefact révisé remplace le précédent.

Ce contrat donne une base concrète à l’intégration d’A2A. Si sa rédaction révèle que le supposé spécialiste se contente de consulter un enregistrement, commencez par mettre en place la connexion à l’outil.

Les questions à se poser avant d’intégrer A2A

Peut-on utiliser A2A sans MCP ?

Oui. A2A ne prescrit pas la manière dont l’agent distant accède à ses propres outils et données. MCP est utile si vous avez aussi besoin de connexions standardisées aux outils. Comment les deux protocoles se complètent.

Les deux agents doivent-ils utiliser le même framework ?

Non. L’interopérabilité entre frameworks est l’un des objectifs centraux d’A2A. Ce sont l’interface exposée et les fonctionnalités nécessaires à l’interaction qui doivent être compatibles, pas les implémentations internes des agents. Présentation d’A2A.

Pour recevoir des guides pratiques sur la création de systèmes d’agents utiles, abonnez-vous à la newsletter.