Skip to main content

Protocole Agent-à-Agent (A2A)

POUR AGENT IAChatGPTClaude

Standard ouvert d'interopérabilité réseau permettant la découverte décentralisée et l'échange sécurisé de contexte entre agents IA indépendants issus de différents fournisseurs et plateformes.

1. Vue d'ensemble du concept et problème systémique

Jusqu'en 2025–2026, la plupart des systèmes multi-agents étaient construits sous forme de monolithes propriétaires rigides (au sein d'une seule bibliothèque comme LangGraph ou CrewAI). Cependant, avec l'émergence de dizaines d'agents commerciaux spécialisés (agent d'audit de sécurité, agent comptable, agent DevOps fourni par un cloud provider), un problème systémique est apparu :

  • Isolation des écosystèmes : Un agent déployé sur un réseau interne basé sur PydanticAI ne peut pas déléguer en toute sécurité une partie de sa tâche à un agent opérant dans l'écosystème LangGraph d'une autre entreprise.
  • Absence de contrat de compétences unifié : Il n'existe aucun moyen universel de connaître les tâches qu'un agent tiers sait résoudre, le coût de ses requêtes ou les garanties SLA qu'il offre.
  • Perte de contexte lors du handoff : Le transfert de prompt entre systèmes tronque souvent la chaîne de raisonnement et les contraintes système.

Le protocole A2A (Agent-to-Agent) supprime ces barrières. Il s'agit d'un protocole applicatif standardisé qui transforme les agents autonomes en participants à part entière d'un réseau ouvert, capables de découvrir les capacités des uns et des autres (Discovery), de négocier les conditions d'exécution (Negotiation) et de déléguer des tâches en toute sécurité.

2. Taxonomie architecturale et modèle mental

L'architecture du protocole A2A repose sur quatre niveaux fonctionnels :

┌─────────────────────────────────────────────────────────────┐
│                 A2A PROTOCOL STACK ARCHITECTURE             │
├─────────────────────────────────────────────────────────────┤
│ 1. Semantic Discovery Layer                                 │
│    • Capability Manifests (Agent.json / JSON-LD)            │
│    • Skill Taxonomy & SLA Declarations                      │
├─────────────────────────────────────────────────────────────┤
│ 2. Negotiation & Contract Layer                             │
│    • Task Scoping & Constraint Bidding                      │
│    • Cost / Token Budget Allocation                         │
├─────────────────────────────────────────────────────────────┤
│ 3. Session & Handoff State Layer                            │
│    • Structured State Vectors & Memory Snapshots            │
│    • Execution Tracing & Callback Channels                  │
├─────────────────────────────────────────────────────────────┤
│ 4. Transport & Cryptographic Trust Layer                    │
│    • mTLS, Ed25519 Signatures, DID (Decentralized IDs)      │
│    • HTTP/3 Streams & Ephemeral WebSocket Tunnels           │
└─────────────────────────────────────────────────────────────┘
  1. Discovery (Découverte) : L'agent publie un manifeste de ses capacités (/.well-known/agent.json), contenant les types de tâches, les schémas attendus pour les données d'entrée et les limites de sécurité.
  2. Negotiation (Négociation) : L'agent initiateur demande l'exécution d'une sous-tâche en spécifiant le budget maximal de tokens, la deadline et les restrictions de droits.
  3. Execution & Handoff (Exécution) : Transmission du contexte minimal nécessaire à la tâche sous une forme structurée.
  4. Verification (Vérification) : Validation du résultat cryptographiquement signé et des métriques de consommation.

3. Pipeline technique et mécanique interne

Le cycle de vie typique d'une transaction A2A se déroule comme suit :

[ Primary Agent ]               [ Directory / DNS ]             [ Specialist Agent ]
       │                                 │                                │
       ├────── Query capabilities ───────►                                │
       │◄───── Endpoint & Public Key ────┤                                │
       │                                                                  │
       ├────── Send Task Contract (Schema, Tokens, Scope) ───────────────►│
       │                                                                  │ (Validate Auth &
       │                                                                  │  Resource Budget)
       │◄───── Accept / Propose Counter-Terms (Ack) ──────────────────────┤
       │                                                                  │
       ├────── Stream Context & Constraints ─────────────────────────────►│
       │                                                                  │ (Execute in Sandbox)
       │◄───── Stream Progress Events & Sub-Task Artifacts ───────────────┤
       │                                                                  │
       │◄───── Final Signed Result (Proof of Execution) ──────────────────┤
  • Contract Validation : Les parties vérifient les signatures numériques de la requête pour prévenir les attaques Man-in-the-Middle ou la substitution de prompts système.
  • Context Encapsulation : Seule une tranche pertinente de la mémoire (Task-Specific Slice) est transmise, et non l'historique complet de la conversation entre l'agent principal et l'utilisateur, garantissant ainsi la confidentialité.

4. Scénarios d'ingénierie pratiques en production

01. Orchestrateur DevOps multicloud

Un agent local de développeur coordonne une release. Il contacte via A2A un agent d'infrastructure externe chez Hetzner pour créer un VPS, puis transmet les accès obtenus à un agent de sécurité pour auditer les ports ouverts et générer la configuration UFW.

02. Déléguage de calculs mathématiques complexes

Un agent coordinateur léger basé sur le modèle Gemini Flash rencontre un problème d'optimisation complexe. Via A2A, il délègue la tâche à un agent spécialisé basé sur DeepSeek-R1 disposant d'un runtime Python/NumPy dédié, recevant une réponse numérique signée.

03. Flotte de Code Review cross-platform

Un agent dans l'environnement Cursor appelle un agent corporate de compliance, déployé dans le périmètre privé d'une banque, pour obtenir un verdict sur l'absence de données PII et la conformité des licences avant la création du commit.

5. Pièges courants, erreurs typiques et sécurité

  • Cascade Failure (Pannes en cascade) : Si un agent dans la chaîne A2A reste bloqué dans une boucle infinie, l'opération entière est gelée. Il est impératif d'implémenter des timeouts stricts (Time-to-Live) pour chaque appel.
  • Indirect Prompt Injection via A2A : Un agent spécialisé compromis peut retourner un résultat contenant une instruction malveillante destinée à l'agent principal. Tout résultat entrant A2A doit subir une validation de schéma et une sanitisation comme s'il s'agissait de données externes dangereuses.
  • Fuite budgétaire incontrôlée : Les appels mutuels entre agents sans limite globale de tokens peuvent déclencher un dialogue circulaire (« merci — à vous aussi ») qui épuise le solde en quelques minutes.

6. Conclusion stratégique pour l'ingénieur 2026

Le protocole A2A fait sortir l'ingénierie de l'intelligence artificielle de l'ère des scripts fermés pour entrer dans celle de l'internet ouvert des agents. En concevant des services agentiques aujourd'hui, isolez leur logique interne de l'interface de communication et intégrez des spécifications d'interaction ouvertes afin que vos agents puissent devenir des composants de systèmes distribués globaux.

/ Questions fréquentesSchema.org FAQPage

FAQ: Protocole Agent-à-Agent (A2A)

Le protocole MCP est optimisé pour la communication « Modèle ➔ Outil/Données » (appels client-serveur vers des utilitaires locaux, des bases de données ou des fichiers). Le protocole A2A est conçu pour l'interaction « Agent ➔ Agent » (peer-to-peer), où les entités possèdent leur propre autonomie, mémoire, état et objectifs, et négocient l'exécution des tâches.
/ Liens internes
Tous les termes