google/adk-go : construire des agents en Go, sans quitter le code

Un SDK Go pour des agents qui restent du code

Le problème visé est celui du développeur qui veut décrire un agent dans un langage compilé, versionné et testable, plutôt que dans une interface graphique ou un fichier de configuration propriétaire. Le README présente ADK comme un framework qui applique les principes du génie logiciel à la création d'agents, avec une définition des agents, des outils et de l'orchestration directement en Go. Le public annoncé est explicite : les développeurs qui construisent des applications d'agents cloud-native et veulent s'appuyer sur la concurrence et la performance de Go. Le dépôt appartient à une famille plus large, avec des variantes Python, Java, Kotlin et TypeScript, ainsi qu'une interface ADK Web. Ce détail compte : le Go n'est pas un portage isolé, c'est une déclinaison d'un ensemble dont la documentation est commune. Un lecteur qui hésite entre plusieurs langages trouvera donc des concepts et des noms d'API qui se ressemblent d'une implémentation à l'autre, ce qui facilite la relecture croisée mais rend aussi la documentation moins spécifique au Go qu'on pourrait l'espérer.

Ce que le module expose et comment on l'installe

L'installation tient en une commande, reprise telle quelle du README : go get google.golang.org/adk/v2. Le chemin du module porte donc le suffixe de version majeure, ce qui signifie que l'API v2 est une rupture assumée par rapport à une v1 encore présente dans les notes de version. Les publications récentes montrent cette coexistence : v1.6.1 datée du 7 septembre 2026, v2.3.0 du 31 août 2026, v1.6.0 du 12 août 2026. Autrement dit, les deux lignées reçoivent encore des correctifs au même moment. Pour un nouveau projet, cela veut dire choisir explicitement sa branche et vérifier que les exemples consultés correspondent à la bonne. Le README indique par ailleurs que le dépôt contient un répertoire examples, et que la documentation en ligne couvre la référence d'API Go ainsi que des échantillons. Rien dans le matériel fourni ne décrit la structure interne des packages au-delà de ces éléments, et je ne peux donc pas affirmer comment les agents sont enregistrés ou exécutés au niveau du code.

Outils, orchestration et composition multi-agents

Trois capacités sont mises en avant. La première est un écosystème d'outils : des outils préconstruits, des fonctions personnalisées, ou l'intégration d'outils existants, sans que le README détaille lesquels ni sous quelle forme ils sont exposés. La deuxième est la composition de plusieurs agents spécialisés pour former des systèmes multi-agents. La troisième est le déploiement, présenté comme indépendant de la plateforme, avec un appui revendiqué sur les environnements cloud-native et une mention explicite de Google Cloud Run. Les sujets du dépôt confirment les domaines visés : a2a, mcp, gemini, vertex-ai, multi-agent-collaboration. La présence de mcp et a2a indique que l'interopérabilité avec des serveurs d'outils et avec d'autres agents est un axe du projet, mais le README ne montre aucun exemple de configuration pour ces protocoles. Un lecteur qui a besoin de chaîner un agent avec un serveur MCP devra donc se tourner vers la documentation externe, pas vers le dépôt lui-même.

La documentation pensée pour les agents de codage

Le point le plus singulier du dépôt est peut-être là. Le README recommande adk.dev/llms.txt comme index lisible par machine de la documentation, et adk.dev/llms-full.txt comme version en un seul fichier. Les deux sont générés depuis le dépôt adk-docs et incluent la référence d'API Go ainsi que des exemples. Le README fournit même une invite type à donner à un agent de codage, qui demande de planifier et d'implémenter un agent de revue de tickets clients en s'appuyant sur ADK Go et sur llms-full.txt comme source d'exemples. C'est une position assumée : le projet admet que le premier lecteur de sa documentation sera souvent un modèle, pas un humain. Cela a une conséquence pratique pour une équipe : la qualité de la documentation compte moins que sa densité et sa cohérence, puisque c'est un agent qui va l'assembler. Pour un développeur humain, en revanche, cela déplace le travail de lecture vers la vérification du code généré, ce qui n'est pas gratuit.

Le point faible : une API en deux lignées

La limite la plus concrète ne vient pas d'une fonctionnalité absente mais du calendrier. Des versions v1.6.x et v2.x publiées à quelques jours d'intervalle signifient que le projet n'a pas encore stabilisé une seule surface publique. Un module Go dont le chemin change de /v1 à /v2 oblige à mettre à jour les imports, et l'absence de guide de migration dans le matériel fourni laisse la question ouverte. Pour une équipe qui doit livrer un agent en production et le maintenir pendant des mois, c'est un coût réel : soit vous suivez la v2 et vous acceptez que des correctifs continuent d'arriver sur une branche que vous n'utilisez pas, soit vous restez sur la v1 et vous vous demandez quand elle cessera d'être alimentée. Le README ne donne aucune indication sur la politique de support des versions. C'est le premier point à clarifier avant d'engager du code, et le dépôt seul ne suffit pas à y répondre.

Face à quoi on le compare vraiment

L'alternative la plus immédiate est le reste de la famille ADK, en particulier ADK Python, cité dans le README parmi les liens importants. La différence n'est pas cosmétique : Python dispose d'un écosystème de bibliothèques d'apprentissage automatique et de prototypage rapide que Go ne propose pas au même niveau, tandis que Go apporte la compilation en un binaire unique, la concurrence native et un déploiement conteneurisé simple. Choisir la version Go, c'est choisir de renoncer à la vitesse d'itération du scripting pour gagner en robustesse d'exécution. Cela se défend quand l'agent est un service qui tourne en continu, beaucoup moins quand il s'agit d'explorer une idée pendant une après-midi. Le README affirme que le framework est agnostique vis-à-vis du modèle et compatible avec d'autres frameworks, tout en étant optimisé pour Gemini. Cette double affirmation mérite d'être testée sur votre fournisseur réel avant de bâtir dessus, car le matériel fourni ne documente aucun exemple avec un modèle non-Gemini.

Licence et coût de maintenance

Le projet est publié sous Apache-2.0, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de licence et de copyright et de signaler les fichiers modifiés. Une exception est signalée dans le README : le répertoire internal/httprr possède son propre fichier LICENSE. Comme il s'agit d'un chemin internal, il n'est pas importable depuis l'extérieur du module, mais la mention indique qu'une dépendance interne ne suit pas la même licence que le reste. Je ne peux pas dire quelle licence s'applique à ce répertoire, le matériel ne le précise pas, et ce n'est pas un point à traiter à la légère si vous prévoyez de vendre un produit dérivé. Sur la maintenance, le dépôt n'est pas archivé et reçoit des publications régulières, avec un workflow de vérification nocturne visible dans les badges. Cela ne dit rien de la durée de support des branches, qui reste l'inconnue principale. Notez enfin que le README renvoie à un fichier AGENTS.md pour ceux qui veulent contribuer au dépôt plutôt que l'utiliser, ce qui sépare clairement les deux publics.

Conclusion éditoriale

À adopter si votre agent doit vivre dans un binaire Go et que vous acceptez de suivre une API encore en mouvement : le module est google.golang.org/adk/v2 et la licence Apache-2.0 n'impose pas de contrainte de distribution au-delà de la conservation des mentions. À éviter si vous cherchez un framework figé ou si vous ne pouvez pas consommer un SDK dont les branches v1 et v2 coexistent dans les mêmes notes de version. Avant de vous engager, vérifiez deux points précis : le contenu de internal/httprr/LICENSE, qui déroge à la licence du reste du dépôt, et la compatibilité de votre fournisseur de modèle avec l'approche annoncée comme agnostique.

Sources officielles

1. google/adk-go on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases