Faire dialoguer deux agents IA avec un protocole a2a, pas à pas

Un chef de produit d’une marketplace veut automatiser la prise de commande. Un agent concierge négocie les prix et confie l’émission du bon de commande à un agent fournisseur. Sans standard commun, chaque intégration casse au premier changement. Avec le protocole agent à agent (A2A, a2a), la conversation devient prévisible, sécurisée et observable.

Pourquoi cet article: vous montrer, pas à pas, comment faire dialoguer deux agents via a2a pour une preuve de concept (POC) robuste en environnement entreprise. À qui s’adresse-t-il: product managers (PM), tech leads et équipes plateforme/data.

A2A en deux minutes: pourquoi et quand l’utiliser

Dans les faits, l’essor de l’intelligence artificielle (IA) amène des agents spécialisés à collaborer. Le protocole agent à agent (A2A) répond au besoin d’orchestrer ces agents hétérogènes, sans enfermement chez un fournisseur.

A2A est un standard ouvert et asynchrone par conception. Il réutilise le protocole de transfert hypertexte (HTTP) et l’appel de procédure à distance JSON (JSON-RPC 2.0) pour les méthodes, ainsi que les événements envoyés par le serveur (SSE) pour le streaming. Références utiles: la spécification JSON-RPC 2.0 et la définition SSE par le WHATWG Server-Sent Events .

A2A se complète avec le protocole de contexte de modèle (MCP), proposé par Anthropic, qui standardise l’accès d’un agent à ses outils et données. MCP gère donc le lien agent-outils, tandis qu’A2A coordonne la collaboration entre agents. Pour une introduction MCP, voir l’annonce d’Anthropic: Model Context Protocol .

En pratique, A2A est pertinent pour des workflows multi-étapes et de longue durée. On l’emploie quand il faut des retours intermédiaires, des tâches à reprendre après incident, et une gouvernance fine des accès.

Les briques à connaître avant de commencer

La carte d’agent (Agent Card) est la carte d’identité publiée en JSON. Elle décrit le nom, la version, les points d’accès, les compétences, les schémas d’authentification pris en charge, les formats de contenus et des exemples d’appels.

La découverte d’un agent s’effectue via une URL normalisée (well-known) suivant l’identifiant de ressource uniforme (URI) défini par l’IETF. La ressource est accessible de type /.well-known/agent-card.json. Pour les détails, voir RFC 8615 sur les ressources well-known . En entreprise, on privilégie aussi un registre interne ou une configuration directe quand la gouvernance l’exige.

Côté échanges, A2A utilise JSON-RPC 2.0 pour les méthodes, avec identifiants de tâche et états associés. Les messages sont composés de parties, multimodales, qui peuvent transporter texte, données structurées ou fichiers. Les modes d’exécution couvrent l’appel rapide (send), le flux incrémental via SSE (stream) et les notifications par webhook pour le très long-cours.

Tutoriel: faire communiquer deux agents en 7 étapes

Avant de coder, choisissez un cas simple et mesurable. L’exemple de concierge d’achat qui délègue à un agent fournisseur est idéal pour comprendre les mécanismes A2A et les métriques de bout en bout.

1. Choisir le scénario: un agent concierge collecte la demande et délègue la création de commande à un agent fournisseur.
2. Définir l’Agent Card de chaque agent: identité, compétences, schémas d’authentification, exemples d’invocation et formats supportés.
3. Exposer l’endpoint serveur A2A de l’agent fournisseur (JSON-RPC) et publier sa carte via /.well-known/agent-card.json ou un registre interne.
4. Côté agent client: découvrir l’agent fournisseur, récupérer et parser l’Agent Card, vérifier la compatibilité des formats et des modes (stream ou webhook).
5. Mettre en place l’authentification: clé API, autorisation ouverte 2.0 (OAuth 2.0) en client credentials, ou TLS mutuel (mTLS) selon la carte. Tester l’échange et la portée des jetons.
6. Envoyer le premier message: choisir send ou stream, inclure un identifiant de tâche, fournir le contexte minimal et gérer les mises à jour.
7. Gérer la complétion: consommer les updates, traiter les erreurs et les délais, fermer proprement la tâche et stocker le résultat pour audit.

Encadré pratique: un message peut contenir une partie texte pour l’instruction, une partie application/json pour les paramètres structurés, et une partie binaire si un fichier est nécessaire. La négociation de formats s’appuie sur la déclaration des content-types dans les cartes d’agent et les en-têtes HTTP.

Sécurité et conformité dès le jour 1

Le chiffrement par sécurité de la couche de transport (TLS) est non négociable en production. Validez les certificats, refusez le clair, et durcissez les suites cryptographiques. L’authentification machine à machine s’appuie idéalement sur OAuth 2.0 en flux client credentials ou sur mTLS lorsque c’est requis par la politique interne.

En délégation au nom d’un utilisateur, évitez les redirections navigateur pour les agents sans interface. Le flux d’authentification par canal secondaire initiée par le client (CIBA) d’OpenID est adapté, car il notifie l’utilisateur via un canal séparé. Spécification: OpenID CIBA Core .

Appliquez une autorisation par compétence avec le principe du moindre privilège. Séparez les secrets, activez la rotation régulière des clés et surveillez les accès. Pour les données sensibles, combinez minimisation des champs, chiffrement au repos côté systèmes d’agent, et cartographie des flux pour respecter le Règlement général sur la protection des données (RGPD) et autres réglementations.

Orchestration: choisir les bons modes et rythmer le cycle de vie

Pour les équipes, le mode send convient aux opérations instantanées. Le mode stream fournit des retours en temps réel lors d’analyses plus longues. Les webhooks s’imposent pour les tâches très longues ou les clients intermittents, par exemple une fonction serverless.

Définissez clairement les états de tâche. Rendez les opérations idempotentes pour pouvoir relancer sans doublons. Encadrez les erreurs par des codes explicites, des temporisations avec reprise exponentielle et des coupe-circuits pour isoler les défaillances.

Le humain dans la boucle (HIL) doit être un citoyen de première classe. Préparez des points d’arrêt, des instructions d’escalade, et la reprise du contexte une fois la décision prise.

Outils et SDKs pour aller vite

Le kit de développement logiciel (SDK) Agent Development Kit de Google facilite la mise en place côté serveur et côté client, en Python et TypeScript. Il gère une partie de la conformité protocolaire et des états.

Des alternatives existent. Le framework d’agents de Microsoft en .NET permet d’exposer rapidement des capacités et de déployer sur des environnements managés. LangChain offre une intégration d’agents distants via A2A à l’intérieur de chaînes Python.

En déploiement, conteneurisez les agents, externalisez les secrets, et paramétrez les webhooks sur une passerelle sécurisée. Pour le streaming, vérifiez que votre proxy supporte correctement SSE sur des connexions longues.

Tests, observabilité et fiabilité des opérations

Testez la carte d’agent comme un contrat stable. Créez des stubs d’agents distants pour valider les chemins d’erreurs et les délais. Activez le traçage distribué avec l’en-tête standard W3C, décrit dans W3C Trace Context , et corrélez identifiant de tâche et identifiant de trace.

Préférez des logs structurés pour agréger facilement les événements. Suivez la latence, le taux de succès et les budgets d’erreurs. En charge, éprouvez les flux SSE et webhooks, et pratiquez un chaos engineering limité pour vérifier la résilience.

La fiabilité des sites (SRE) doit disposer de runbooks pour le redémarrage d’agents, la rotation de certificats et le rollback de cartes d’agent.

Exemples express d’usage en entreprise

Le concierge d’achat multi-fournisseurs démontre la délégation et l’agrégation des résultats, utile pour une démonstration rapide.

La détection de fraude multi-agents combine un agent de patterns transactionnels, un agent de contrepartie et un agent conformité. Ce montage réduit les faux positifs face à des scénarios sophistiqués.

En assurance, le parcours quote-to-bind profite d’agents spécialisés en souscription, tarification et conformité. La synchronisation par A2A accélère la réponse et stabilise les règles métiers.

Limites et contournements à prévoir

Le modèle point à point peut entraîner une explosion des connexions quand le nombre d’agents augmente. Insérer une couche événementielle, par exemple un bus type Kafka ou MQTT, aide à limiter le couplage et à lisser les charges.

Le couplage fort complique les changements. Versionnez les cartes d’agent, maintenez une compatibilité descendante et pilotez l’activation de nouvelles capacités par indicateurs de fonctionnalité.

La gouvernance multi-équipes impose un registre d’agents géré, des contrôles d’accès et des revues régulières de sécurité. Définissez qui peut publier, modifier et déréférencer une carte.

Feuille de route d’adoption (0–90 jours)

Semaines 0 à 2: construisez un POC minimal avec un agent client et un agent fournisseur. Utilisez le mode send pour valider le chemin critique de bout en bout, de la découverte à la complétion.

Semaines 3 à 6: activez le stream pour des retours incrémentaux et les webhooks pour les tâches longues. Passez à OAuth 2.0 en client credentials et ajoutez une observabilité de base avec traçage et logs structurés.

Semaines 7 à 12: durcissez la sécurité (mTLS si nécessaire), intégrez le HIL, déployez en production limitée avec objectifs de niveau de service (SLO) et un plan de rollback prêt.

Conclusion: passer du pilote à la valeur métier

A2A devient la colonne vertébrale des workflows multi-agents en entreprise, tandis que MCP fournit l’accès fiable aux outils. À court terme, lancez un POC ciblé en deux semaines avec un cas métier précis, appliquez la check-list sécurité et observabilité, et tenez un registre interne d’agents pour cadrer la gouvernance.