Aller au contenu

Les protocoles d'agents passent sous gouvernance neutre

Le standard de Google rejoint celui d'Anthropic dans une fondation indépendante. Deux cent cinquante membres, dont tous les concurrents. Ce genre d'accord est plus rare qu'il n'y paraît.

Espace publicitaire
L'essentiel en 30 secondes ⚡
Le protocole A2A, conçu par Google pour faire communiquer des agents entre eux, a rejoint le 20 août une fondation adossée à la Linux Foundation qui gouverne déjà le MCP d'Anthropic. Cette structure compte désormais plus de 250 membres, dont AWS, Anthropic, Cloudflare, Google, Microsoft et OpenAI. Des concurrents directs placent leurs standards sous une gouvernance commune.

Nous avons expliqué ce qu'est le MCP : un protocole qui permet à un modèle de se brancher sur des outils extérieurs sans intégration sur mesure. Voici la suite, et elle est plus importante qu'elle n'en a l'air.

Deux protocoles complémentaires

Il faut distinguer ce que chacun résout, parce qu'ils ne se concurrencent pas.

Le MCP relie un modèle à des outils : une base de données, un service, un système de fichiers. C'est la prise de courant entre l'IA et le reste du logiciel.

Le A2A relie des agents entre eux. Il permet à un agent construit par une entreprise de déléguer une tâche à un agent construit par une autre, avec un vocabulaire commun pour se présenter, négocier et rendre compte.

Réunir les deux sous une même gouvernance produit une pile cohérente : comment une IA parle aux outils, et comment les IA se parlent entre elles.

Pourquoi c'est inhabituel

Des concurrents qui placent leurs standards sous une autorité neutre, c'est rare. La tentation naturelle est l'inverse : imposer son protocole pour que l'écosystème dépende de soi.

Si tout le monde accepte ici, c'est qu'un calcul l'emporte. L'adoption des agents en entreprise est freinée par le coût d'intégration bien plus que par les capacités des modèles. Chaque entreprise redoute de s'enfermer chez un fournisseur unique et attend donc.

Un standard neutre lève ce blocage. Le gâteau grossit pour tout le monde, et personne ne prend le risque de rater le marché en défendant un protocole isolé.

Le lien avec la sécurité 🔐
Un standard partagé n'apporte pas que de l'interopérabilité. Il permet aux correctifs de se propager, aux vérifications de flux de données d'être normalisées, et aux bonnes pratiques d'être communes. Nous avons documenté cette semaine une attaque par texte invisible et une faille exploitant la mémoire persistante. Dans un paysage fragmenté, chaque intégration réinvente ses protections et répète les mêmes erreurs. Un standard commun ne supprime pas les failles, il évite au moins de les découvrir dix fois.

Ce que ça ne résout pas

Un protocole définit comment des systèmes échangent, pas ce qu'ils ont le droit de faire. Le problème central des agents reste entier : quand un agent en mandate un autre, qui répond du résultat ?

C'est exactement le chantier que nous décrivions à propos des agents qui paient : établir une trace vérifiable de qui a autorisé quoi, dans quelles limites. Les protocoles peuvent transporter cette information, ils ne décident pas de sa valeur juridique.

Et un standard largement adopté crée une surface commune : une faiblesse dans le protocole affecte tout le monde à la fois. C'est le revers habituel de la normalisation.

Ce qu'il faut retenir

Cette consolidation est le genre d'actualité qu'on saute et qui compte davantage que la sortie d'un modèle.

Elle signale que le secteur est passé de la démonstration à l'industrialisation. On ne normalise pas un domaine expérimental : on normalise ce qu'on prévoit de déployer massivement et longtemps.

Pour une entreprise qui construit avec des agents, la conséquence pratique est directe et vaut dès maintenant : privilégiez les outils qui parlent ces protocoles. C'est la meilleure protection contre l'enfermement, et c'est le conseil que nous répétons sous toutes ses formes — ne choisissez pas un fournisseur, choisissez une architecture qui permet d'en changer.

Espace publicitaire