Agent Cards : comment les agents se trouvent entre eux (A2A Discovery)

Une Agent Card est un document JSON lisible par machine du protocole A2A, avec lequel un agent IA publie son identité, son endpoint, ses compétences, ses capacités, ses modalités et ses schémas d'authentification. Les autres agents lisent cette carte pour décider s'ils confient une tâche à l'agent et de quelle manière. L'Agent Card est ainsi le mécanisme central qui permet aux agents de se trouver sans que personne ait dû les câbler en dur au préalable.

• Ce que c'est : le profil public d'un agent, à la fois carte de visite et description d'interface.
• À quoi elle sert : la découverte d'agents. Un agent client vérifie les compétences, les modalités et l'authentification avant de confier une mission (task).
• Pourquoi elle compte : sans Agent Card, un agent est invisible pour les autres systèmes et n'est accessible que par une intégration sur mesure.

A2A, MCP et le rôle de l'Agent Card

Dans la pile de protocoles de 2026, deux standards ouverts se sont imposés. Le Model Context Protocol (MCP), développé par Anthropic, régit l'accès des agents aux outils et aux données, autrement dit d'agent à outil. Depuis décembre 2025, MCP relève de l'Agentic AI Foundation, sous l'égide de la Linux Foundation. Le protocole Agent2Agent (A2A) régit la collaboration entre agents, autrement dit d'agent à agent. La documentation A2A distingue les deux ainsi : via MCP, un agent utilise des fonctionnalités comme des outils et des ressources ; via A2A, des agents travaillent en partenaires sur une tâche. Les deux protocoles se complètent.

L'Agent Card est la brique de découverte des capacités d'A2A. Là où un serveur MCP décrit des outils individuels, une Agent Card décrit un agent entier comme partenaire de collaboration potentiel. A2A a été présenté en avril 2025 lors de Google Cloud Next et confié le 23 juin 2025 à la Linux Foundation, avec AWS, Cisco, Google, Microsoft, Salesforce, SAP et ServiceNow comme membres fondateurs. Plus de 100 entreprises soutiennent désormais le protocole (chiffres 2026).

Structure d'une Agent Card

Une Agent Card est un document JSON qu'un agent publie sous un chemin connu de son hôte. Elle contient les éléments essentiels suivants :

Le principe de conception sous-jacent est décisif : A2A définit comment les agents se parlent, pas comment ils pensent. La structure interne d'un agent distant, c'est-à-dire ses prompts, son modèle et sa mémoire, reste volontairement opaque. C'est précisément ce qui permet à un agent Salesforce d'appeler un agent SAP sans qu'aucune des deux parties ne dévoile ses prompts, son modèle ou ses données. La Card est le seul contrat que les deux parties partagent.

Le mécanisme de découverte

La découverte via les Agent Cards se présente sous deux formes typiques.

Découverte directe (point à point). Un agent client connaît l'URL de base d'un agent distant et récupère son Agent Card. Il vérifie si les compétences annoncées correspondent à la tâche, si la modalité nécessaire est prise en charge et s'il peut satisfaire le schéma d'authentification. Ce n'est qu'ensuite qu'il ouvre une tâche.

Découverte par annuaire (registry). Dans les parcs plus importants, les Agent Cards sont enregistrées de manière centralisée. Lancé par Cisco, le projet open source AGNTCY fournit à cet effet un Agent Directory : un registre fédéré dans lequel les agents A2A et les serveurs MCP peuvent être publiés, vérifiés et trouvés. Il décrit les compétences et les attributs avec l'Open Agentic Schema Framework (OASF). Un agent trouve ainsi des partenaires adaptés via un annuaire plutôt que via des adresses codées en dur. SAP regroupe une fonction comparable dans le SAP AI Agent Hub dans SAP LeanIX. Le hub est conçu comme un centre de pilotage indépendant des éditeurs, grâce auquel les entreprises trouvent, inventorient et pilotent des agents SAP et tiers ainsi que des serveurs MCP. En octobre 2026, SAP indique que le hub est en disponibilité générale.

Une fois un partenaire trouvé, le cycle de vie des tâches A2A prend le relais. Selon la spécification A2A, une tâche passe par les états submitted et working, se met en pause en input-required en cas de questions ou en auth-required lorsqu'une authentification supplémentaire est nécessaire, et se termine en completed, failed, canceled ou rejected. Dans le JSON de la spécification 1.0, ces états s'appellent TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_INPUT_REQUIRED, et ainsi de suite. Le transport passe par JSON-RPC 2.0 et HTTPS, et la spécification définit en outre des bindings pour gRPC et HTTP+JSON. Les états intermédiaires sont diffusés en streaming via Server-Sent Events et, pour les exécutions longues, des notifications push optionnelles sont prévues. Le résultat d'une tâche revient sous la forme d'un ou plusieurs Artifacts ; les messages peuvent être composés de plusieurs parties et multimodaux.

Côté recherche, le projet NANDA du MIT Media Lab montre où la découverte pourrait aller à long terme : un index d'agents décentralisé avec des AgentFacts vérifiables cryptographiquement et un Zero Trust Agentic Access. En 2026, cela reste toutefois du niveau de la recherche et ne constitue pas une base pour des décisions de production.

Exemple : découverte entre deux agents

Supposons qu'un agent CRM dans Salesforce doive faire pré-contrôler les factures fournisseurs entrantes et, pour cela, confier la tâche à un agent de facturation spécialisé d'une agence.

L'Agent Card de l'agent de facturation, abrégée et avec les noms de champs de la spécification A2A 1.0 :

• "name": "Invoice-Triage-Agent", "version": "2.0.0"
• "supportedInterfaces": [{ "url": "https://agents.example.com/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }]
• "capabilities": { "streaming": true, "pushNotifications": true }
• "defaultInputModes": ["text/plain", "application/pdf"], "defaultOutputModes": ["application/json"]
• "securitySchemes": { "oauth": { "oauth2SecurityScheme": { "flows": { … } } } }
• "skills": [{ "id": "klassifiziere_rechnung", "name": "Rechnung klassifizieren", "description": "Liefert Kategorie und Konfidenz (0 bis 1)", "tags": ["rechnung"] }]

Le déroulement :

1. L'agent CRM récupère la Card : GET https://agents.example.com/.well-known/agent-card.json
2. Il vérifie : la compétence correspond, le format d'entrée et OAuth 2.0 sont pris en charge.
3. Il ouvre une tâche via POST https://agents.example.com/a2a ; la tâche démarre à l'état TASK_STATE_SUBMITTED.
4. La tâche passe par TASK_STATE_WORKING et se termine en TASK_STATE_COMPLETED. L'Artifact renvoyé est le suivant : { "kategorie": "Wareneingang", "konfidenz": 0.94 }

L'agent CRM n'a eu besoin de rien savoir du modèle interne ou des prompts de l'agent de facturation. Il a décidé uniquement sur la base de la Card que cet agent pouvait accomplir la tâche, puis la lui a confiée via le contrat de tâche standardisé. C'est précisément ce découplage qui rend possibles des workflows multi-éditeurs entre Agentforce, Joule et Copilot Studio. Pour Joule, SAP a annoncé en mai 2026 que les fonctions A2A bidirectionnelles seraient en disponibilité générale au quatrième trimestre 2026.

Sécurité et gouvernance

Chaque nouvelle connexion entre agents est une nouvelle frontière de confiance et donc une nouvelle surface d'attaque. Quatre risques sont particulièrement pertinents : les violations des frontières de confiance, car chaque pair A2A est opaque pour les autres ; la dérive des capacités, lorsqu'une Card promet plus que ce que l'agent peut réellement fournir de manière sûre ; les lacunes dans la piste d'audit, dès que les messages franchissent les frontières entre processus ; et l'amplification des injections de prompt, car chaque contexte d'agent supplémentaire est une occasion de contournement de plus. Le risque d'injection de prompt indirecte (XPIA) augmente avec chaque agent qui traite des contenus non fiables.

Conséquences pratiques pour les déploiements en Europe : des tokens à portée limitée et de courte durée par tâche, le moindre privilège pour les compétences annoncées dans la Card, des Correlation IDs de bout en bout pour chaque tâche A2A, et aucune extension propriétaire de la sémantique des Cards ou des tâches qui saperait précisément la portabilité pour laquelle on choisit A2A. Pour les workflows réglementés, la reproductibilité impose de journaliser les Agent Cards utilisées à chaque exécution et de figer les versions des modèles.

Pour les agences et le B2B

Pour les agences marketing et digitales en Europe, publier des Agent Cards est le principal levier produit en 2026. Seul un agent découvrable via A2A peut être appelé directement depuis les environnements Salesforce, SAP Joule ou Copilot Studio de tes clients, sans qu'une intégration spécifique soit nécessaire pour chaque client. Qui fait l'impasse sur les Agent Cards reste durablement cantonné à une intégration manuelle. Notre recommandation : de la discipline sur les Cards dès le premier jour, imposer des contrats de sortie typés (par exemple via Pydantic ou JSON Schema) et exiger une Card pour chaque agent proposé comme produit avant sa mise en production.

Pour les décideurs B2B, la question des achats est décisive : ton contrat Agentforce, Joule ou Copilot Studio garantit-il l'interopérabilité A2A et la conformité au standard MCP ? Et contient-il des clauses sur la publication des Agent Cards ainsi que des clauses de sortie ? Blck Alpaca t'aide à concevoir des agents conformes à A2A, à modéliser proprement les Agent Cards et à les intégrer dans une architecture de découverte compatible avec la gouvernance.