Guide du développeur des protocoles d’agents IA

• Guide expliquant pas à pas, avec du code concret, 6 protocoles d’agents IA — MCP, A2A, UCP, AP2, A2UI, AG-UI — réunis dans un scénario unique d’agent de chaîne d’approvisionnement pour un restaurant, afin de montrer le problème résolu par chacun
• Structure qui part d’un LLM vide avec le Agent Development Kit (ADK) de Google, puis ajoute les protocoles un à un jusqu’à couvrir la vérification des stocks, les devis, les commandes, le paiement et le rendu d’un tableau de bord
• MCP gère la connexion aux outils et aux données, A2A la communication entre agents, UCP la standardisation du commerce, AP2 l’autorisation de paiement, A2UI la composition de l’interface, et AG-UI la diffusion en streaming
• Chaque protocole partage des motifs communs comme la découverte via des URL bien connues, des schémas typés et des flux d’événements standardisés, afin d’assurer la compatibilité de l’écosystème
• Recommande de ne pas adopter les six dès le premier jour, mais de les ajouter progressivement selon les besoins

---

MCP(Model Context Protocol) — connexion aux outils et aux données

• Protocole qui résout le premier obstacle rencontré lorsqu’on connecte un agent à des systèmes et à des données, en éliminant le travail manuel consistant à écrire du code d’intégration personnalisé pour chaque API
• Structure dans laquelle un serveur MCP annonce (advertise) ses propres outils et l’agent les découvre automatiquement, fournissant un modèle de connexion standard unique pour des centaines de serveurs
• Comme les serveurs MCP sont maintenus par les équipes qui ont créé les systèmes concernés, l’agent dispose toujours des définitions d’outils à jour sans avoir à écrire ni mettre à jour le code d’intégration
• Pris en charge nativement dans l’ADK via McpToolset ; l’exemple met en œuvre une interrogation de base PostgreSQL (MCP Toolbox for Databases), la consultation de recettes via Notion MCP et l’envoi d’e-mails fournisseurs via Mailgun MCP
  • Connexion à la base de stocks avec ToolboxToolset
  • Connexion à des services externes comme Notion et Mailgun avec McpToolset
• Modèle simple permettant de lancer un serveur MCP avec une commande npx et de le connecter directement à l’agent, sans code supplémentaire

A2A(Agent2Agent Protocol) — communication entre agents

• Protocole qui traite le problème d’expertise restant une fois l’accès aux données résolu par MCP, en fournissant une méthode standard de découverte et de communication entre agents distants exploités par des équipes, frameworks et serveurs différents
• Chaque agent A2A publie une Agent Card à l’adresse /.well-known/agent-card.json pour exposer son nom, ses capacités et son endpoint ; l’agent gestionnaire de cuisine la récupère puis route les requêtes à l’exécution vers l’agent approprié
• Lorsqu’on ajoute un nouvel agent distant, il suffit d’ajouter son URL, sans modification manuelle du code ni redéploiement
• Le RemoteA2aAgent de l’ADK route vers un seul agent distant par tour ; si l’on doit interroger plusieurs agents distants en parallèle, il faut utiliser directement a2a-sdk
• La fonction to_a2a() permet de transformer n’importe quel agent ADK en service A2A
• Même si des données brutes comme les prix, les niveaux de qualité ou les fenêtres de livraison ne sont pas exposées via une API, elles restent accessibles via une interface agentique

UCP(Universal Commerce Protocol) — standardisation du commerce

• Protocole qui unifie les processus de commande alors que chaque fournisseur dispose d’une API différente, en standardisant le cycle de vie des achats sous forme de fonctionnalités modulaires
• Des schémas de requête/réponse fortement typés assurent la cohérence, et le même modèle fonctionne quelle que soit la couche de transport sous-jacente : REST, MCP, A2A ou EP (protocole embarqué basé navigateur)
• Comme pour A2A, la découverte du catalogue fournisseur se fait via le motif d’URL /.well-known/ucp
• Aucun SDK propriétaire nécessaire : intégration directe avec une API REST standard via un client HTTP existant
• Dans l’exemple, CheckoutCreateRequest sert à commander 10 livres de saumon et 3 bouteilles d’huile d’olive, puis PaymentCreateRequest à construire la demande de paiement
• Le dépôt d’exemples UCP comprend un exemple d’assistant d’achat IA combinant ADK et A2A

AP2(Agent Payments Protocol) — autorisation de paiement et piste d’audit

• Si UCP gère ce qui est commandé et auprès de quel fournisseur, AP2 s’occupe de qui a approuvé l’achat et de la piste d’audit
• Des mandates typés fournissent une preuve d’intention non répudiable (non-repudiatable proof of intent) et appliquent à chaque transaction des garde-fous configurables
• Flux complet : IntentMandate → PaymentMandate (signé) → PaymentReceipt
  • IntentMandate : définit les garde-fous comme les commerçants autorisés, les plafonds de dépense, l’approbation automatique, l’exigence de remboursement possible ou la date d’expiration
  • PaymentMandate : délégation de paiement liée à un panier et à un montant précis, qui reste non signée tant qu’une approbation explicite du responsable n’a pas été donnée en cas de dépassement de plafond
  • PaymentReceipt : reçu qui complète la piste d’audit
• Fonctionne comme une extension (extension) d’UCP en ajoutant au flux de checkout une preuve d’autorisation chiffrée
• Le protocole en est actuellement au stade v0.1 et n’est pas intégré au cœur de l’ADK ; les types sont fournis dans un package séparé

A2UI(Agent-to-User Interface Protocol) — composition dynamique de l’interface

• Protocole qui permet à un agent de construire dynamiquement, au lieu de simple texte, des tableaux de bord, formulaires de commande, tableaux comparatifs de fournisseurs, etc.
• Les nouvelles mises en page sont décrites en JSON déclaratif à partir d’un catalogue fixe de 18 primitives de composants sûres (lignes, colonnes, champs de texte, etc.)
• La structure de l’interface et les données sont séparées, ce qui permet de mettre à jour uniquement les données sans renvoyer les composants
  • Les composants sont transmis sous forme de liste plate se référant mutuellement par ID
  • Les données sont envoyées séparément via dataModelUpdate
• Un moteur de rendu côté client convertit le JSON en interface native pour Lit, Flutter, Angular ou d’autres environnements
• Avec les mêmes 18 primitives, un seul agent peut générer des interfaces totalement différentes : checklist de stock, formulaire de commande, comparaison de fournisseurs, etc.
• L’interface web de l’ADK (adk web) peut rendre nativement les composants A2UI, sans qu’il soit nécessaire de construire un renderer séparé pendant le développement
• A2UI Widget Builder permet de composer les mises en page de façon interactive

AG-UI(Agent-User Interaction Protocol) — diffusion en streaming

• Contrairement aux API REST classiques, les agents suivent des schémas d’interaction complexes : diffusion progressive de texte, appel d’outils en cours de réponse, pause dans l’attente d’une saisie humaine, etc.
• AG-UI agit comme un middleware qui convertit les événements bruts propres à chaque framework en flux SSE standardisés
• Le front-end n’a qu’à recevoir des événements typés comme TEXT_MESSAGE_CONTENT ou TOOL_CALL_START, sans avoir besoin de savoir quel framework d’agent les a produits
• L’ADK fournit nativement un endpoint /run_sse, mais AG-UI résout les problèmes de code de parsing répétitif et de fragilité lors des changements de format d’événements
• Il suffit d’un encapsulage avec le package ag_ui_adk puis d’un montage dans une application FastAPI pour créer un endpoint de streaming AG-UI

Flux global d’intégration

• Quand l’utilisateur demande de vérifier le stock de saumon, consulter le prix de gros et le niveau de qualité du jour, puis commander 10 livres chez Example Wholesale et autoriser le paiement en cas de stock insuffisant, les 6 protocoles interviennent étape par étape
• Étape 1 — collecte d’informations : requête de la base de stock via MCP (check_inventory) → interrogation d’un agent distant de prix/qualité via A2A (ask_agent)
• Étape 2 — finalisation de la transaction : demande de checkout via UCP (place_order) → obtention d’un mandate de paiement dans les garde-fous définis via AP2 (authorize_payment)
• Étape 3 — affichage du résultat : composition d’un widget interactif avec A2UI → streaming en temps réel des appels d’outils et des réponses textuelles via AG-UI

Conseils d’usage des protocoles

• L’architecture reste propre seulement si l’on identifie précisément le problème que résout chaque protocole
• Il n’est pas nécessaire d’utiliser les six dès le premier jour ; dans la plupart des cas, on commence par MCP, puis on ajoute progressivement la communication multi-agents, le commerce, le paiement, une UI riche et le streaming à mesure que les besoins augmentent
• Avant de construire sur ces protocoles, il faut d’abord vérifier l’intégration ADK, les SDK officiels et les exemples de code, afin d’éviter de les réimplémenter soi-même
• Les protocoles sont encore en phase de maturation, mais adopter tôt des modèles comme la découverte via URL bien connues, les schémas typés et les flux d’événements standardisés aide à garantir la compatibilité avec l’écosystème d’outils, de services et d’agents