Les cinq modèles d’intégration des systèmes multi-agents selon Google Cloud : A2A et MCP

Google Cloud a dévoilé à Cloud Next 26 une infrastructure destinée à construire des systèmes multi-agents à l’échelle de l’entreprise. Au cœur de cette approche se trouvent deux protocoles : A2A (Agent-to-Agent), chargé de la communication entre agents, et MCP (Model Context Protocol), utilisé lorsque les agents accèdent à des outils et à des données externes. Cet article présente cinq modèles d’intégration combinant ces deux protocoles.

Modèle 1 : découverte et enregistrement des agents

• Agent Card — Tous les agents prenant en charge A2A publient un document JSON décrivant leurs capacités, leurs exigences d’authentification, leurs limites d’appel, etc. Comparable à une spécification OpenAPI, il s’agit en quelque sorte d’une « carte de visite » conçue pour les interactions entre agents.
• Agent Registry — En enregistrant les agents de l’organisation dans un registre central, d’autres agents peuvent rechercher leurs capacités et y accéder sans connaître leur URL. Cela joue un rôle similaire à celui d’un service mesh dans une architecture de microservices, c’est-à-dire une couche intermédiaire qui gère les communications entre services.

Modèle 2 : délégation entre équipes

• Collaboration multilingue et multi-équipes — Un agent d’orchestration unique délègue des tâches à l’agent Go de l’équipe sécurité, à l’agent Java de l’équipe risques, à l’agent TypeScript de l’équipe marketing, etc. Même si chaque équipe utilise des langages et frameworks différents, l’intégration fonctionne dès lors que le protocole A2A est implémenté.
• Déploiement et évolution indépendants — Selon le même principe qui a fait le succès des microservices, chaque agent est déployé et mis à jour indépendamment, sans nécessiter de modifications du côté de l’agent d’orchestration.

Modèle 3 : connexion aux outils via MCP (Tool Bridge)

• Connexion à diverses sources de données via un protocole unique — Sans MCP, il fallait créer un connecteur distinct pour chaque REST API, base de données ou système legacy. MCP unifie cela sous une interface standard unique.
• Réutilisation de la gouvernance API existante — Via Apigee API Hub, les REST API existantes peuvent être automatiquement converties en outils pour agents, tout en conservant les mécanismes de gestion déjà en place, comme l’authentification, la journalisation et le contrôle d’accès.
• Plus de 60 outils préintégrés — Des intégrations MCP prêtes à l’emploi sont proposées pour GitHub, Notion, Stripe et bien d’autres.

Modèle 4 : collaboration inter-organisationnelle

• Agent Gallery — Dans Gemini Enterprise, il est possible d’utiliser immédiatement plus de 100 agents partenaires validés, issus notamment d’Adobe, ServiceNow et Salesforce.
• Maintien d’une gouvernance indépendante — Chaque organisation peut conserver son propre modèle de sécurité tout en collaborant via A2A. Les politiques d’Agent Gateway permettent de contrôler finement quelles données sont partagées et quelles actions sont autorisées.

Modèle 5 : mesh d’agents piloté par les événements

• Réseau d’agents en fonctionnement continu — Des agents connectés à des tables BigQuery ou à des flux Pub/Sub (service de streaming de messages en temps réel) détectent des événements et, selon les besoins, délèguent via A2A à des agents spécialisés ou escaladent vers un humain.
• Auto-organisation — Lorsqu’un nouvel agent spécialisé est ajouté, il suffit de l’enregistrer dans le Registry et d’ajuster la logique de routage, sans avoir à repenser tout le mesh.
• Observabilité — Agent Identity, Agent Gateway et Agent Observability permettent de suivre l’ensemble des activités des agents dans le mesh.

Points différenciants

• L’ouverture d’A2A — Le protocole se présente comme ouvert, sans dépendance à un framework, un langage ou un cloud spécifique, avec l’ambition de devenir un standard pour l’interconnexion d’agents dans des environnements hétérogènes.
• Séparation des rôles entre A2A et MCP — En dissociant la communication entre agents de l’accès aux outils, l’architecture permet à chaque couche d’évoluer indépendamment.
• Exploitation de l’infrastructure existante — L’idée est de superposer une couche d’agents à une infrastructure Google Cloud déjà en production, comme Apigee ou BigQuery, afin de réduire la charge liée à l’adoption d’une pile entièrement nouvelle.

Points de vigilance

• Un écosystème centré sur Google Cloud — Des fonctionnalités clés comme Agent Gallery ou Gemini Enterprise Agent Platform sont étroitement liées à la plateforme Google Cloud, ce qui laisse à vérifier le degré d’ouverture réel dans des environnements multicloud.
• Complexité d’entreprise — Si ces cinq modèles sont combinés en production, ils peuvent entraîner la complexité propre aux systèmes distribués, notamment en matière de gestion des dépendances entre agents et de propagation des pannes.

Le cadre présenté cette fois par Google Cloud vise à faire passer les agents IA du statut d’outils isolés à celui d’infrastructure de collaboration à l’échelle de toute l’organisation. De la même manière que l’architecture microservices a permis de dépasser les limites des applications monolithiques, A2A et MCP cherchent à résoudre l’isolement des agents individuels. Reste à voir à quel point cette vision fonctionnera de manière fluide sur le terrain dans les entreprises, à mesure que les cas d’usage se multiplieront. La maturité des protocoles, la qualité des agents partenaires et la coordination de la gouvernance entre organisations seront probablement les trois facteurs qui détermineront la valeur réelle de cet écosystème.

[bluenyx]

Même avec seulement 3 ou 4 profils senior, on a l’impression qu’on arrive à une structure capable d’absorber la charge de 30 à 40 personnes. (Encore plus clairement qu’aujourd’hui.. )