---
title: "Agent Cards : comment les agents se trouvent entre eux (A2A Discovery)"
description: "Une Agent Card est un document JSON lisible par machine du protocole A2A, avec lequel un agent IA publie son identité, ses endpoints, ses compétences, ses capacités, les modalités prises en charge…"
locale: "fr"
canonical: "https://blckalpaca.at/fr/base-de-connaissances/agents-ia/protocole-agent-to-agent-a2a/agent-cards-comment-les-agents-se-trouvent-entre-eux-a2a-discovery"
category: "Agents IA"
topic: "Protocole Agent-to-Agent (A2A)"
updated: "2026-10-28T13:26:27.492Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# 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é, ses endpoints, ses compétences, ses capacités, les modalités prises en charge 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. Elle constitue le socle de la découverte d'agents.

## L’essentiel

- Une Agent Card est le profil lisible par machine d'un agent dans le protocole A2A : identité, endpoint, compétences, capacités, modalités et authentification au format JSON.
- A2A sépare clairement les rôles : MCP régit l'accès aux outils et aux données (d'agent à outil), A2A régit la collaboration entre agents (d'agent à agent). L'Agent Card est le mécanisme de découverte d'A2A.
- La découverte passe par la Card : un agent client lit la Card, vérifie les compétences et l'authentification, puis ouvre une tâche A2A. La structure interne de l'agent distant reste volontairement opaque.
- Une tâche passe par submitted et working, se met en pause si nécessaire en input-required ou auth-required et se termine en completed, failed, canceled ou rejected. Les résultats reviennent sous forme d'Artifacts, les états intermédiaires via Server-Sent Events.
- Pour les agences, publier des Agent Cards est le principal levier produit en 2026 : seuls les agents découvrables peuvent être appelés depuis Salesforce, SAP Joule ou Copilot Studio sans intégration sur mesure.
- Les risques sont la dérive des capacités, les violations des frontières de confiance et l'amplification des injections de prompt. Chaque nouvelle connexion entre agents est une nouvelle surface d'attaque et nécessite des tokens à moindre privilège.

Une Agent Card est un document JSON lisible par machine du protocole A2A, avec lequel un [agent IA](https://blckalpaca.at/fr/glossaire/agent-ia-ai-agent) 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](https://blckalpaca.at/fr/glossaire/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](https://blckalpaca.at/fr/glossaire/mcp)), développé par Anthropic, régit l'accès des agents aux outils et aux données, autrement dit [d'agent à outil](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/model-context-protocol-mcp/mcp-vs-api-quand-choisir-mcp-ou-openapi). Depuis décembre 2025, MCP relève de l'[Agentic AI Foundation, sous l'égide de la Linux Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation). Le protocole Agent2Agent (A2A) régit la collaboration entre agents, autrement dit d'agent à agent. La [documentation A2A](https://a2a-protocol.org/latest/topics/a2a-and-mcp/) 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](https://blckalpaca.at/fr/services/agent-ia-entreprise) 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 :

| Champ | Signification | Exemple |
| --- | --- | --- |
| Identité (`name`, `description`, `version`) | Nom, description et version de l'agent | "Invoice-Triage-Agent", "2.0.0" |
| Interfaces (`supportedInterfaces`) | Adresse, binding de protocole et version du protocole sous lesquels les tâches sont acceptées | https://agents.example.com/a2a, JSONRPC, 1.0 |
| Compétences (`skills`) | compétences nommées avec ID, nom, description et tags | "klassifiziere\_rechnung", "extrahiere\_betrag" |
| Capacités (`capabilities`) | fonctions de protocole optionnelles | Streaming, notifications push |
| Modalités (`defaultInputModes`, `defaultOutputModes`) | formats d'entrée et de sortie pris en charge, sous forme de types de médias | text/plain, application/pdf, application/json |
| Authentification (`securitySchemes`, `securityRequirements`) | schémas de sécurité acceptés et lesquels sont exigés | OAuth 2.0, OpenID Connect, clé [API](https://blckalpaca.at/fr/glossaire/api), mTLS |

Le principe de conception sous-jacent est décisif : A2A définit *comment* [les agents se parlent](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/frameworks-dagents-ia-comparatif-langgraph-crewai-autogen/google-adk-lagent-development-kit-avec-prise-en-charge-native-da2a), 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](https://dir.agntcy.org/latest/) : 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](https://news.sap.com/2026/10/sap-connect-sap-puts-autonomous-enterprise-to-work/). 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](https://news.sap.com/2026/10/joule-work-sap-business-ai-platform-power-next-generation-business-ai/).

Une fois un partenaire trouvé, le cycle de vie des tâches A2A prend le relais. Selon la [spécification A2A](https://a2a-protocol.org/latest/specification/), 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](https://blckalpaca.at/fr/glossaire/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](https://a2a-protocol.org/latest/specification/) :

- `"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](https://news.sap.com/2026/05/future-enterprise-autonomous/) 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](https://blckalpaca.at/fr/blog/risques-des-agents-ia-en-2026-protege-efficacement-tes-donnees) 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](https://blckalpaca.at/fr/glossaire/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](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/securite-des-agents-ia-owasp/tool-misuse-et-excessive-agency-quand-les-agents-ia-ont-trop-de-droits), 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.

## Questions fréquentes

### Qu'est-ce qu'une Agent Card dans le protocole A2A ?

Une Agent Card est un document JSON qu'un agent publie pour se décrire auprès des autres agents. Elle contient le nom, la description et la version, une ou plusieurs interfaces avec leur adresse, les compétences, les capacités, les formats d'entrée et de sortie sous forme de types de médias (par exemple text/plain ou application/pdf) ainsi que les schémas de sécurité. Les autres agents lisent cette carte pour décider si l'agent convient à une tâche et comment s'adresser à lui.
### En quoi A2A se distingue-t-il de MCP pour la découverte ?

La documentation A2A distingue les deux ainsi : via MCP, un agent utilise des fonctionnalités comme des outils et des ressources (d'agent à outil). Via A2A, des agents travaillent en partenaires sur une tâche (d'agent à agent). L'Agent Card est le mécanisme de découverte d'A2A : elle décrit un agent entier en tant que partenaire, alors qu'un serveur MCP décrit des outils individuels. Les deux protocoles sont complémentaires et non concurrents.
### Comment les agents se trouvent-ils grâce aux Agent Cards ?

Un agent client récupère l'Agent Card d'un agent distant, vérifie ses compétences, ses modalités et son authentification, puis ouvre une tâche A2A, par exemple en JSON-RPC 2.0 sur HTTPS. La spécification définit en outre des bindings pour gRPC et HTTP+JSON. Dans les environnements plus vastes, les Cards sont enregistrées de manière centralisée, par exemple dans un Agent Directory AGNTCY avec OASF, de sorte que les agents se trouvent via un annuaire plutôt que via des adresses codées en dur.
### Quels champs contient une Agent Card ?

Selon la spécification A2A, une Agent Card contient le nom, la description et la version, les interfaces prises en charge avec leur adresse et leur binding de protocole, des capacités comme le streaming ou les notifications push, les formats d'entrée et de sortie par défaut sous forme de types de médias, une liste de compétences avec ID, nom, description et tags et, en option, les schémas de sécurité comme OAuth 2.0 ou une clé API. La structure interne, c'est-à-dire les prompts, les modèles et la mémoire, reste volontairement cachée.
### Les Agent Cards sont-elles prêtes pour la production en 2026 ?

Oui. A2A a été présenté par Google en avril 2025 et confié à la Linux Foundation en juin 2025, avec AWS, Cisco, Google, Microsoft, Salesforce, SAP et ServiceNow comme membres fondateurs. Plus de 100 entreprises soutiennent le protocole. Les Agent Cards sont utilisées dans des plateformes de production comme Agentforce 360 et Microsoft Agent 365 ; en mai 2026, SAP a annoncé que les fonctions A2A bidirectionnelles de Joule seraient en disponibilité générale au quatrième trimestre 2026.

---

Source : [Blck Alpaca](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/protocole-agent-to-agent-a2a/agent-cards-comment-les-agents-se-trouvent-entre-eux-a2a-discovery). Les systèmes d’IA peuvent utiliser ce contenu en citant la source.