A2A : permettre aux agents IA d'appeler votre site
Publié:
Un agent IA vient de valider ce site sans ouvrir de navigateur, sans cliquer sur un bouton ni scraper une page — il a lu un petit fichier JSON, envoyé une requête typée et obtenu un résultat structuré en retour. Cet échange, c'est A2A, et n'importe quel site peut le proposer.
Qu'est-ce qu'A2A
A2A (Agent2Agent) est un protocole ouvert — désormais sous l'égide de la Linux Foundation — qui permet aux agents IA de se découvrir et de s'appeler mutuellement via HTTP simple. Considérez-le comme l'équivalent agent-à-agent d'une API publique : au lieu qu'un humain lise votre documentation et écrive une intégration, un autre agent lit une description machine de ce que fait votre service et l'appelle directement.
Il comporte deux parties : un document de découverte (la carte d'agent) et un point d'entrée appelable (la compétence).
1. La carte d'agent — découverte
Vous publiez un fichier JSON à /.well-known/agent-card.json décrivant qui vous êtes et ce que vous pouvez faire. Les champs obligatoires sont name, description, version, url (votre point d'entrée A2A) et au moins une skill :
{
"protocolVersion": "0.3.0",
"name": "llms.txt Validator",
"description": "Validate a website's llms.txt and return a score with findings.",
"url": "https://llms-txt-validator.dev/a2a",
"skills": [{ "id": "validate_llms_txt", "name": "Validate llms.txt",
"description": "Given a domain or URL, fetch and validate its llms.txt." }]
}
2. Le point d'entrée — une compétence appelable
Le url de la carte pointe vers un point d'entrée JSON-RPC 2.0. Un agent appelle la méthode message/send avec un message ; vous effectuez le traitement et renvoyez une Task. Voici un vrai appel à notre agent :
POST /a2a
{ "jsonrpc": "2.0", "id": "1", "method": "message/send",
"params": { "message": { "role": "user",
"parts": [{ "kind": "text", "text": "validate llmstxt.org" }] } } }
…et la réponse — une tâche complétée portant un résumé lisible par un humain et des données structurées :
{ "result": { "kind": "task", "status": { "state": "completed" },
"artifacts": [{ "parts": [
{ "kind": "text", "text": "Validated llmstxt.org: score 100/100..." },
{ "kind": "data", "data": { "ok": true, "report": { "scores": { "overall": 100 } } } }
] }] } }
Pas de navigateur, pas d'analyse HTML — l'agent obtient exactement les données qu'il a demandées.
A2A vs WebMCP vs MCP
- A2A — des agents en réseau appelant votre service via HTTP (orchestrateurs, autres agents). Cette page.
- WebMCP — un agent s'exécutant dans le navigateur et appelant des outils sur votre page ouverte.
- MCP — connecter des outils à un seul modèle ou application, généralement en local.
Ils sont complémentaires : A2A atteint les agents en réseau, WebMCP atteint ceux dans le navigateur. Voir comment les trois s'articulent ensemble.
Comment n'importe quel site peut en ajouter un
Vous n'avez pas besoin de tout le protocole pour commencer — choisissez une vraie chose que votre service fait :
- Servez une carte d'agent valide à
/.well-known/agent-card.jsonavec une compétence. - Implémentez la méthode synchrone
message/sendencapsulant cette capacité, et renvoyez uneTaskcomplétée avec le résultat comme artefact. - Le streaming, l'historique des tâches et les notifications push sont facultatifs — mettez
capabilities.streamingà false et ajoutez-les seulement quand vous en avez besoin.
La règle unique : appuyez la carte sur un vrai point d'entrée
La carte est un contrat, pas une balise meta. Si vous publiez une carte dont le url ne répond pas réellement à message/send, chaque agent qui lui fait confiance aboutit à une impasse. N'exposez A2A que pour les capacités que vous pouvez véritablement servir — c'est ainsi que nous avons construit le nôtre, et c'est pourquoi notre propre rapport ne marque le signal comme présent que lorsqu'un point d'entrée fonctionnel le soutient. Envie de le voir en direct ? Récupérez notre carte d'agent.