TL;DR
L’Agent Development Kit de Google dispose d’implémentations en Python, Go, TypeScript, Java et Kotlin. Les clients MCP connectent les agents aux outils à travers ces langages, tandis qu’A2A prend en charge la communication avec des agents distants. Des protocoles communs n’impliquent pas des fonctionnalités identiques : la documentation Kotlin décrit actuellement la consommation d’A2A, et non l’exposition d’un agent Kotlin en tant que serveur A2A.
Un framework pour plusieurs environnements d’exécution
Python reste un choix pratique pour l’expérimentation, mais les systèmes d’entreprise s’exécutent aussi sur des services JVM, des backends Go, des applications navigateur et des appareils mobiles. L’ADK de Google couvre cinq langages : Python, Go, TypeScript, Java et Kotlin. Google indique que chaque implémentation est conçue pour son propre environnement d’exécution et son propre système de types, tout en partageant une architecture et des protocoles ouverts. (Source : Google Cloud — One Agent Development Kit, five languages)
Cela compte lorsqu’un agent doit résider à proximité de services existants. Une équipe disposant d’une plateforme Java ne souhaite pas nécessairement déployer un service Python distinct uniquement pour appeler un modèle. Un produit orienté navigateur peut préférer TypeScript ; une application Android a des contraintes différentes de celles d’un serveur. Le support natif réduit une partie des frictions d’intégration, mais les équipes doivent examiner les capacités de chaque SDK plutôt que de supposer que leurs fonctionnalités sont identiques.
MCP et A2A résolvent des problèmes différents
Google indique que chaque langage de l’ADK inclut un client MCP. Dans ce contexte, le Model Context Protocol connecte un agent à des outils ou à des données exposés par un serveur MCP. A2A, en revanche, sert à communiquer avec un agent distant via HTTP. Un protocole donne accès à des outils ; l’autre offre aux agents un moyen d’échanger des tâches et des réponses. (Source : Google Cloud — Shared foundation; ADK — MCP tools)
Cette distinction influence la conception d’un système. Une recherche d’inventaire peut être exposée comme un outil au périmètre restreint. Un agent d’approvisionnement distant peut prendre plusieurs décisions et appeler plusieurs outils avant de renvoyer un résultat. Traiter ce dernier comme une simple fonction de base de données peut masquer la latence, les frontières de permissions et la possibilité d’un achèvement partiel.
Un protocole de communication partagé crée une opportunité d’interopérabilité, pas une confiance automatique. L’authentification, l’autorisation, la négociation de version, la gestion des erreurs et le schéma d’un résultat doivent encore être testés entre les implémentations réellement utilisées.
Cinq SDK, des compromis d’ingénierie différents
Google décrit Python comme son implémentation de référence, avec de nombreuses intégrations et des outils d’évaluation. Son SDK Go utilise des définitions d’outils typées et inclut un environnement d’exécution de workflows sous forme de graphe. Le SDK TypeScript utilise des définitions de schéma et peut également s’exécuter dans un contexte navigateur. Pour Java, Google met en avant l’intégration à l’écosystème JVM ; Kotlin utilise des outils au moment de la compilation et prend en charge des cas d’usage orientés mobile. Il s’agit de descriptions produit, et non d’une comparaison indépendante du débit ou de la maturité. (Source : Google Cloud — Hands-on view of each ADK)
Un choix doit refléter la charge de travail. Une équipe serveur peut privilégier une infrastructure de déploiement et de traçage existante plutôt qu’un benchmark au niveau du langage. Une équipe mobile doit examiner la disponibilité des modèles, le traitement local des données, les contraintes de batterie et les actions disponibles sur l’appareil. Un agent navigateur hérite également des frontières de sécurité de son environnement d’exécution.
Il existe un compromis organisationnel : la diversité des langages peut réduire le coût d’intégration d’un agent dans une application existante, mais maintenir plusieurs SDK augmente le nombre de versions, de dépendances et de chemins opérationnels à prendre en charge. L’interopérabilité déplace une partie de la complexité des ponts entre langages vers les tests de protocole et de contrat ; elle ne fait pas disparaître la complexité.
La mise en garde concernant A2A et Kotlin
Le guide de démarrage rapide de l’ADK Kotlin indique que Kotlin peut consommer un agent distant via A2A, mais ne peut pas encore exposer son propre agent via A2A. Le client Kotlin lit les fiches d’agent A2A 1.0 et rejette les fiches à l’ancien format 0.3. Le guide précise que son exemple de serveur Python peut convertir une fiche au format 0.3 vers le format 1.0 au démarrage avec a2a-sdk 1.x. (Source : ADK — Kotlin A2A quickstart)
C’est exactement le type de nuance qu’une affirmation telle que « tous les langages parlent A2A » peut occulter. Une implémentation client uniquement peut être utile, mais elle n’est pas interchangeable avec une implémentation serveur. Même deux composants qui prétendent prendre en charge le même protocole peuvent échouer à interopérer s’ils ciblent des versions incompatibles.
Un test en production doit donc consigner les versions des SDK et les formats de fiches d’agent, ainsi que la capacité de chaque composant à initier une requête, exposer un point de terminaison, s’authentifier, diffuser des réponses en streaming et gérer l’échec ou l’interruption d’une tâche.
Une checklist d’adoption pratique
Commencez par un cas d’usage à faible risque et définissez un contrat pour les entrées, les sorties et les erreurs. Testez chaque langage avec le même serveur MCP, en utilisant l’authentification et les permissions d’outils réelles prévues pour le déploiement. Pour A2A, testez chaque direction séparément : un agent capable d’appeler un pair distant ne peut pas nécessairement recevoir lui-même des requêtes A2A.
Suivez la latence de bout en bout et le coût total de la tâche complète, y compris les sauts réseau et les nouvelles tentatives. Inspectez les traces à travers les frontières des services et assurez-vous que les identifiants de tâche survivent à la délégation. Enfin, testez la révocation : lorsqu’un outil ou un agent distant perd l’accès, le système doit échouer de manière sûre plutôt que de continuer silencieusement avec des identifiants obsolètes.
Le résultat est une interprétation plus réaliste de l’annonce. Les équipes disposent de davantage de choix d’implémentation ; la parité et un fonctionnement inter-langages fiable restent un travail d’ingénierie à vérifier.
FAQ
L’ADK est-il disponible uniquement en Python ?
Non. Google liste des implémentations en Python, Go, TypeScript, Java et Kotlin.
MCP et A2A sont-ils interchangeables ?
Non. MCP connecte à des outils et des données ; A2A prend en charge la communication avec des agents distants.
Le SDK Kotlin peut-il exposer un agent A2A ?
Le guide de démarrage rapide Kotlin cité ne documente actuellement que le côté consommateur, sans prise en charge encore de l’exposition d’un agent Kotlin via A2A.
Pour aller plus loin
— The Agent Report