Google ADK : faut-il rejouer la carte Google sur les agents ?

Google a un avantage stratégique sur OpenAI dans la guerre des frameworks d’agents : son SDK est multi-langages, son écosystème de modèles est multi-providers via Model Garden (200+ modèles dont Claude, Llama, Mistral), et son protocole A2A est devenu un standard ouvert avec 50+ partenaires industriels. Sur le papier, l’Agent Development Kit (ADK) est plus ouvert que l’OpenAI Agents SDK. Mais cette ouverture s’arrête à la couche infrastructure : Agent Engine, Vertex AI, Google Cloud. La même question stratégique se pose donc qu’avec OpenAI : acceptez-vous le lock-in Google Cloud à 24 mois ? Voici la grille honnête pour décider.

Cet article complète notre analyse de l’OpenAI Agents SDK, notre comparatif CrewAI, AutoGen et LangGraph, et notre guide de décision sur les frameworks d’agents IA pour DSI.

En bref

• Google ADK fait partie d’une plateforme renommée Gemini Enterprise Agent Platform (anciennement Vertex AI Agent Builder) annoncée à Cloud Next 2026.
• 7 millions de téléchargements Python depuis le lancement, selon les chiffres officiels Google Cloud.
• L’ADK est multi-langages (Python, Go, Java, TypeScript) et multi-modèles (Model Garden 200+, Claude est first-class citizen).
• Le lock-in n’est pas dans le code mais dans l’infrastructure : Agent Engine + Vertex AI + Google Cloud.
• C’est le bon choix pour les organisations engagées sur Google Cloud, surdimensionné pour les autres.
• Pour cadrer ce choix dans votre organisation, Proactive Academy propose une formation aux frameworks d’agents IA pour DSI et chefs de projet.

Le rebranding qu’il faut avoir en tête avant de chercher

Première chose à savoir avant même d’aborder la technique : le nom a changé en 2026. Ce qu’on appelait Vertex AI Agent Builder depuis avril 2024 s’appelle désormais Gemini Enterprise Agent Platform depuis Cloud Next 2026. La plateforme est la même, le nom évolue pour aligner Google sur sa stratégie de marque autour de Gemini.

Dans la pratique, vous trouverez les deux appellations dans la documentation et les articles, parfois mélangées. Pour cet article, nous utilisons Google ADK pour parler du framework de développement, et Gemini Enterprise Agent Platform pour parler de la plateforme complète qui l’héberge. Le SDK lui-même reste Agent Development Kit (ADK), son nom n’a pas bougé.

Ce détail compte parce qu’un DSI qui cherche « Vertex AI Agent Builder pricing » aujourd’hui peut tomber sur des contenus qui ne reflètent plus la dernière organisation produit de Google.

Ce que l’ADK est vraiment

L’Agent Development Kit est un framework open source pour construire, déboguer et déployer des agents IA à l’échelle entreprise. C’est l’équivalent fonctionnel de l’OpenAI Agents SDK, mais avec une philosophie d’ouverture plus marquée sur trois dimensions structurantes.

Multi-langages dès le départ. Disponible en Python, Go, Java et TypeScript. C’est une différence majeure avec l’OpenAI Agents SDK dont les fonctions récentes (sandbox, harness, code mode, subagents) sont Python uniquement. Pour une équipe enterprise hétérogène avec du Java legacy ou du Go en backend, l’ADK est plus naturel.

Multi-modèles via Model Garden. Selon UI Bakery (avril 2026), la plateforme donne accès à plus de 200 modèles fondamentaux dont Gemini, Anthropic Claude (Opus, Sonnet, Haiku en first-class citizens depuis Cloud Next 2026), Meta Llama et les modèles ouverts Gemma. L’ADK est nativement model-agnostic. Vous pouvez basculer de Gemini à Claude sans réécrire votre agent.

Multi-architectures de déploiement. L’ADK peut tourner localement pour le debug, dans n’importe quel container, sur Cloud Run, sur GKE Kubernetes, ou sur Agent Engine, le runtime managé de Vertex AI. Le code de l’agent reste identique quel que soit le target.

À cela s’ajoutent des fonctions production qui ont rattrapé celles de LangGraph 1.0 :

• Recovery from failure : si une conversation crashe, l’ADK restaure l’état nativement
• Human-in-the-loop natif : pause à n’importe quel point d’un workflow complexe, reprise après validation
• Rewind state and context : possibilité de revenir à un point antérieur de la conversation et d’invalider les interactions suivantes
• Memory Bank : mémoire long terme persistante avec gestion des accès via IAM

C’est cette dernière fonction, le Memory Bank, qui est devenue selon les communications Google un argument de vente majeur pour les déploiements production.

Là où Google a un vrai différenciateur stratégique : A2A

Un point que la plupart des comparatifs francophones sous-estiment : Google a initié le protocole Agent-to-Agent (A2A), un standard ouvert pour faire communiquer des agents construits sur n’importe quel framework ou avec n’importe quel modèle.

Selon Google Cloud Blog, A2A permet aux agents construits sur ADK, LangGraph, CrewAI ou autres de coopérer entre eux via un langage commun. Plus de 50 partenaires industriels participent à l’initiative, dont Box, Deloitte, Elastic, PayPal, Salesforce, ServiceNow, UiPath, UKG, Weights & Biases.

Pour un DSI qui anticipe une architecture multi-agents complexe avec des composants venant de plusieurs vendors, A2A est un atout réel. C’est précisément le type de problème que l’OpenAI Agents SDK ne résout pas : OpenAI n’a pas initié de protocole interopérable similaire.

Un sujet que nous traiterons en profondeur dans le cluster C12 du blog dédié aux protocoles agents (MCP, A2A, ACP), mais qu’il faut avoir en tête dès maintenant pour évaluer correctement l’ADK.

Cas concrets documentés en 2026

Deux cas publics récents méritent d’être connus pour comprendre où l’ADK prend son sens.

Burns & McDonnell, ingénierie, utilise la plateforme pour transformer des décennies de données projet et d’expérience employés en intelligence opérationnelle temps réel. Selon la communication officielle Google Cloud, leur produit Experience IQ est un agent ADK qui combine règles métier déterministes et raisonnement probabiliste. Leur dirigeant cité dans la communication : « Vertex AI permet à cette innovation de scaler de manière responsable en combinant des règles métier déterministes avec du raisonnement probabiliste, faisant de l’IA une capacité opérationnelle de confiance, et pas seulement un outil de productivité ».

Payhawk, fintech, utilise Vertex AI Agent Builder pour transformer ses agents en assistants financiers qui intègrent réellement les données entreprise. Cas représentatif des fintechs qui ont besoin de combiner LLM + données structurées propriétaires (transactions, factures, paiements) avec des garanties de gouvernance et d’audit.

Ces cas illustrent la zone où l’ADK gagne face aux alternatives : organisations enterprise déjà engagées sur Google Cloud, qui ont besoin de combiner agents IA et données opérationnelles internes, avec des contraintes fortes de gouvernance.

Le lock-in est ailleurs que dans l’OpenAI SDK

Voici la nuance critique pour un DSI. L’ADK est plus ouvert que l’OpenAI Agents SDK sur trois dimensions (langages, modèles, déploiement). Mais le lock-in se situe à un autre niveau : l’infrastructure managée.

Comme l’analyse UI Bakery, « avez-vous besoin d’être sur Google Cloud pour utiliser Vertex AI Agent Builder ? Effectivement, oui ». Vous pouvez techniquement faire tourner l’ADK ailleurs, mais perdre :

• Agent Engine : le runtime managé avec autoscaling, sub-second cold starts, gestion de session, exécution longue
• Memory Bank : la mémoire long terme persistante avec gouvernance IAM
• Cloud Trace : l’observabilité native intégrée
• Cloud API Registry : la gouvernance centralisée des outils
• L’intégration native Workspace : Gmail, Calendar, Drive, Docs, Chat

Sans ces composants, l’ADK redevient un framework « comme les autres » qu’on aurait pu choisir LangGraph ou CrewAI à la place. La valeur de l’ADK pour une entreprise réside précisément dans l’écosystème managé qui l’entoure, et donc dans la dépendance à Google Cloud qui en découle.

C’est exactement le miroir d’OpenAI : ouverture sur la surface, lock-in sur la profondeur. La nature du lock-in diffère seulement (chez OpenAI ce sont les hosted tools, chez Google c’est l’infrastructure cloud), mais le résultat est équivalent.

Le coût réel d’un projet ADK en 2026

Selon la documentation pricing officielle Google Cloud, Google a baissé le pricing du runtime Agent Engine et a commencé à facturer des services additionnels d’Agent Engine à partir du 28 janvier 2026. Trois postes structurent le TCO d’un projet :

Les tokens des modèles. Pricing classique Vertex AI à l’usage. Gemini 3 Pro et Gemini 3 Flash sont les modèles phares de 2026. Pour les organisations qui veulent diversifier, Claude Sonnet et Opus accessibles via Model Garden ont leur propre pricing aligné sur celui d’Anthropic.

Le runtime Agent Engine. Tarifé à l’usage en compute. La tarification a été revue à la baisse en janvier 2026 mais avec extension du périmètre facturé. À budgéter avec attention en phase de scaling.

Memory Bank et services Vertex AI. Stockage des mémoires long terme, requêtes de récupération, IAM. Postes facturés à part qui peuvent monter avec un usage intensif.

L’observabilité Cloud Trace. Incluse dans le périmètre Google Cloud standard, pas de surcoût dédié. Avantage par rapport à LangGraph qui exige LangSmith en plus.

Pour un agent moyennement utilisé en production sur Gemini 3 Flash (1 000 à 5 000 requêtes par jour avec mémoire long terme activée), comptez entre 2 000 et 6 000 euros par mois en frais Google Cloud, hors développement. Pour un agent intensif sur Gemini 3 Pro avec Memory Bank actif sur de gros volumes de contexte, le chiffre peut être multiplié par 2 à 3.

La grille de décision honnête pour un DSI

Comme pour l’OpenAI Agents SDK, ne posez pas la question « ADK ou LangGraph ? ». Posez celle qui compte vraiment : quelle exposition acceptez-vous à Google Cloud à 24 mois ?

Trois positions stratégiques possibles, miroirs de celles que nous avons posées pour OpenAI :

Position 1, vous êtes déjà tout-Google Cloud. Workspace, BigQuery, GKE, Vertex AI font partie de votre stack. Dans ce cas, l’ADK est cohérent. Le lock-in est déjà là, l’ADK ne l’aggrave pas. Vous bénéficierez de l’intégration native avec Workspace, de la gouvernance unifiée IAM, et de l’expérience opérationnelle de vos équipes Google Cloud.

Position 2, vous voulez préserver votre liberté de mouvement. Vous anticipez de pouvoir basculer sur AWS, Azure, ou un cloud souverain européen dans 12-24 mois. Dans ce cas, partez sur LangGraph ou CrewAI, qui sont nativement cloud-agnostic. Vous pourrez utiliser Gemini ou Claude via leurs API standards sans dépendre de Vertex AI.

Position 3, vous êtes engagé sur Microsoft Azure. Le Microsoft Agent Framework reste plus naturel pour votre stack que l’ADK Google, malgré la qualité du SDK Google. La cohérence vendor compte plus que la richesse fonctionnelle dans ce cas précis.

La distinction commerciale entre OpenAI Agents SDK et Google ADK est ailleurs que dans la technique. Choisir l’ADK, c’est choisir le partenariat stratégique avec Google sur 5 à 10 ans, avec tout ce que ça implique en pricing, en feuille de route produit, et en exposition aux décisions stratégiques d’Alphabet.

Quand l’ADK gagne face à l’OpenAI Agents SDK

Quatre cas concrets où l’ADK est objectivement le meilleur choix face au SDK d’OpenAI.

Vous êtes sur Google Workspace. L’intégration native ADK + Workspace (Gmail, Calendar, Drive, Docs, Chat, Sheets, Slides) via les Vertex AI Search MCP servers est sans équivalent. Si vos cas d’usage tournent autour de la productivité interne avec ces outils, l’ADK est presque obligatoire.

Votre équipe est polyglotte. Si vous avez du Java enterprise legacy, du Go en backend, ou si vos équipes refusent le tout-Python, le support multi-langages de l’ADK (Python, Go, Java, TypeScript) est un argument décisif. L’OpenAI Agents SDK est essentiellement Python en 2026.

Vous voulez utiliser Claude. Anthropic Claude est first-class citizen de Model Garden depuis Cloud Next 2026. Vous pouvez utiliser Claude Opus ou Sonnet directement dans l’ADK avec une intégration meilleure que celle d’OpenAI Agents SDK avec Claude (ce dernier accepte Claude techniquement mais les optimisations sont calibrées pour GPT).

Vous architecturez du multi-vendor. Si votre stratégie consiste à faire coopérer des agents construits sur plusieurs frameworks et vendors, le protocole A2A initié par Google et soutenu par 50+ partenaires est un atout que l’OpenAI Agents SDK ne propose pas.

Quand l’ADK perd face à l’OpenAI Agents SDK

À l’inverse, trois cas où le SDK d’OpenAI reste plus pertinent.

Vous êtes déjà tout-OpenAI. Modèles GPT, ChatGPT Enterprise, API Assistants en migration. Aucun bénéfice à diversifier juste pour ajouter Google.

Vous voulez la richesse maximale des hosted tools OpenAI. Web search, code interpreter, file storage hosted OpenAI ont une maturité que les équivalents Google n’ont pas systématiquement. Pour les cas qui en dépendent intensivement, OpenAI reste plus complet.

Vous voulez les derniers modèles OpenAI sans délai. Les nouveaux modèles GPT arrivent typiquement dans Vertex AI Model Garden avec quelques mois de retard. Si vous voulez l’avantage du modèle le plus récent immédiatement, OpenAI direct est plus rapide.

Comment former vos équipes à l’ADK

L’investissement formation suit la même logique que pour les autres frameworks, avec quelques spécificités liées à l’écosystème Google.

Le développeur qui implémente doit maîtriser : l’ADK selon le langage retenu (Python, Go, Java ou TypeScript), l’écosystème Vertex AI, Agent Engine, Memory Bank, l’intégration MCP servers, et les subtilités IAM Google Cloud. Comptez 3 à 5 semaines pour un développeur expérimenté qui connaît déjà Google Cloud, 2 mois s’il découvre l’écosystème.

Le tech lead doit comprendre l’architecture Agent Engine, savoir arbitrer entre déploiement managé et self-hosted, anticiper les coûts à l’échelle, et maîtriser le protocole A2A pour les architectures multi-agents.

Le DSI et le chef de projet ont besoin d’une lecture stratégique : exposition Google Cloud, alignement avec la stratégie cloud de l’organisation, alternatives, gouvernance IAM. C’est le périmètre que couvre notre parcours formation Agents IA pour DSI, qui adresse spécifiquement l’arbitrage stratégique entre frameworks propriétaires et neutres.

FAQ : Google ADK en entreprise

Le Google ADK n’est pas un mauvais produit, loin de là. Sa philosophie multi-langages, multi-modèles, multi-architectures de déploiement le rend objectivement plus ouvert que l’OpenAI Agents SDK sur la surface technique. Mais cette ouverture cohabite avec un lock-in tout aussi fort, simplement déplacé d’un niveau : là où OpenAI vous attache à ses hosted tools, Google vous attache à son cloud. Pour un DSI, le bon réflexe en 2026 n’est pas de choisir le framework le plus ouvert dans l’absolu, mais de choisir le vendor avec qui vous voulez bâtir un partenariat stratégique sur 5 à 10 ans. Si Google Cloud fait déjà partie de votre stack, l’ADK est une suite logique naturelle. Sinon, LangGraph ou CrewAI restent les options qui préservent votre liberté de mouvement. Pour structurer cet arbitrage avant d’engager les équipes techniques, un accompagnement formation aux frameworks d’agents IA avec Proactive Academy reste le moyen le plus direct de prendre cette décision en connaissance de cause.