Google, l'IETF et les nouveaux protocoles pour les agents AI : pourquoi A2A, Pilot et OpAMP sont nécessaires

Les systèmes d'IA fonctionnent de plus en plus non seulement comme des chatbots autonomes, mais aussi comme des participants à l'infrastructure réseau. Sur cette base, émerge une nouvelle classe de protocoles qui aide les agents à se découvrir mutuellement, à échanger des tâches, à économiser des tokens et à transmettre la télémétrie sans intégrations chaotiques.

Pourquoi les protocoles sont nécessaires

Les scénarios où l'IA contrôle déjà les processus du monde réel ne sont plus une théorie. Dans l'infrastructure réseau, les modèles d'apprentissage automatique aident déjà à détecter les anomalies, isoler les appareils IoT suspects et définir les règles QoS. Parallèlement, l'IETF publie des documents sur la structure des contrôleurs de réseau intelligents et des réseaux orientés par intention. C'est un changement important : l'IA ne devient plus une couche au-dessus de l'interface, mais fait partie de la boucle opérationnelle qui influence le comportement du système en temps réel.

Le problème est que de tels agents parlent rarement la même langue. La plupart du temps, ils sont connectés via des API séparées, des connecteurs personnalisés et une logique d'échange de messages manuelle. Tant que le système est petit, c'est tolérable. Mais quand il y a de nombreux agents, les coûts d'intégration, d'acheminement des tâches, de gestion d'état et de sécurité de la transmission des données augmentent fortement. Par conséquent, le marché cherche non pas un autre framework, mais des moyens normalisés pour que les agents communiquent.

Quatre approches remarquables

Quatre solutions sont particulièrement intéressantes maintenant car elles abordent non pas le même problème, mais différentes couches de l'infrastructure d'agents. Certaines gèrent la connectivité réseau directe, d'autres le format des messages, d'autres la sélection de l'exécuteur, et d'autres encore l'exploitation et l'observabilité. Au lieu de tenter d'inventer un super-protocole universel, le marché semble prendre un chemin plus pragmatique : diviser la tâche en couches séparées et normaliser chacune à sa manière.

• Pilot de Vulture Labs offre aux agents autonomes une pile réseau complète. Les agents se voient attribuer des adresses virtuelles de 48 bits, et la communication se fait via UDP en utilisant Ed25519 et X25519. L'approche est conçue pour une communication directe même derrière NAT, pare-feu et dans le cloud.

• PAIRL de Dennis Verman traduit le langage naturel en un format plus compact et lisible par machine. Au lieu d'explications longues, le protocole utilise des références et des hashes de données, et l'auteur estime les économies de tokens à 70–90%. De plus, vous pouvez fixer des limites pour des tâches spécifiques.

• A2A est construit autour des "cartes de capacité" JSON des agents. Un agent décrit ce qu'il peut faire, et un autre basé sur ces informations sélectionne un exécuteur et un format d'interaction. Le protocole a été initialement développé chez Google, puis transféré à la Linux Foundation pour un développement ultérieur.

• OpAMP de l'écosystème OpenTelemetry résout un problème plus pratique : gestion à distance d'un grand nombre d'agents et collecte de leur télémétrie. Grâce à lui, vous pouvez obtenir le statut, les données du système, les métriques de charge et renvoyer la configuration aux agents.

"ref:doc:sha256:..." — un exemple de la façon dont PAIRL remplace une

longue phrase par une courte référence lisible par machine à un document.

En général, ces protocoles ne sont pas en concurrence directe les uns avec les autres. Pilot gère la connectivité réseau, PAIRL la compacité et la structure des messages, A2A la description des rôles et la coordination dans un système multi-agent, et OpAMP l'exploitation, l'observabilité et la configuration à distance. C'est le signal clé du marché : l'écosystème des systèmes d'agents se décompose rapidement en couches techniques séparées, chacune développant ses propres normes.

Qui établit la norme

A2A reçoit actuellement le plus d'attention, et la raison est claire : l'initiative venait de Google, et l'idée s'inscrit bien dans la croissance des produits multi-agents. L'article présente un exemple simple : la planification d'un voyage international où un agent réserve des vols, un autre sélectionne un hôtel et un troisième trouve des visites. Cette approche nécessite un format commun pour décrire les capacités, sinon chaque combinaison devient un projet séparé.

Curieusement, la communauté compare déjà A2A avec MCP d'Anthropic : les deux solutions utilisent JSON-RPC mais résolvent des problèmes différents.

Notablement, chacun des protocoles mentionnés a déjà non seulement une idée, mais une infrastructure de travail autour de lui. Pour Pilot, un whitepaper et une démo ont été publiés; pour PAIRL—documentation et un exemple public de transformation de requête; pour A2A—des spécifications détaillées et même un cours de formation préparé avec des spécialistes de Google Cloud et IBM Research. OpAMP dispose d'une documentation pour HTTP et WebSocket, de structures de message et d'implémentations prêtes à l'emploi, y compris une version Go. Ce n'est plus un concept sur une diapositive, mais un ensemble d'outils qui peut être essayé dans les systèmes réels.

Ce que cela signifie

Le marché des systèmes d'agents commence à répéter la première histoire d'Internet : d'abord vient un zoo de solutions incompatibles, puis un ensemble commun de protocoles. Pour les équipes construisant des produits multi-agents, c'est maintenant un bon moment pour examiner les normes : elles aident à réduire le volume des intégrations personnalisées, à simplifier la mise à l'échelle et à faire des agents une partie de l'infrastructure d'ingénierie normale plutôt qu'une collection de scripts disparates.