Qu'est-ce que Google ADK (Agent Development Kit) ? Un guide pratique

Google ADK est un framework open source pour créer, évaluer et déployer des agents IA. Il alimente déjà des agents dans des produits Google comme Agentspace. Si vous avez déjà exploré d’autres piles d’agents, comme le SDK OpenAI Agents, ADK couvre un périmètre similaire tout en restant proche de Gemini et Vertex AI. Dans ce guide, vous verrez comment structurer un agent ADK, connecter des outils, composer plusieurs agents et tester les API appelées par vos outils avec Apidog.

Essayez Apidog aujourd’hui

Qu’est-ce que Google ADK ?

ADK signifie Agent Development Kit. Google l’a présenté lors de Google Cloud Next en avril 2025 comme une boîte à outils open source pour le cycle de vie complet des agents :

1. définir un agent ;
2. lui fournir des outils ;
3. composer plusieurs agents ;
4. évaluer son comportement ;
5. le déployer en production.

ADK a commencé avec Python. Google a ensuite ajouté Java, avec le support de Go et TypeScript à suivre. Le framework est le même que celui utilisé en interne par Google pour les agents d’Agentspace et de sa Customer Engagement Suite. Ce n’est donc pas un SDK expérimental : il cible des charges de travail de production.

ADK est agnostique au modèle, mais optimisé pour l’écosystème Google. Il fonctionne particulièrement bien avec Gemini et les modèles disponibles via Vertex AI Model Garden. Il s’intègre aussi à LiteLLM, ce qui permet d’orienter un agent vers Anthropic, Meta, Mistral ou d’autres fournisseurs.

Où ADK se situe dans l’écosystème Gemini et Vertex AI

Pensez à ADK comme à la couche d’orchestration entre le modèle et l’environnement d’exécution.

• Le modèle : Gemini, ou un autre fournisseur via Vertex AI Model Garden ou LiteLLM, effectue le raisonnement.
• Le framework : ADK définit les agents, les outils et les flux multi-agents.
• L’environnement d’exécution : Vertex AI Agent Engine héberge et scale l’agent en production. Vous pouvez aussi déployer sur Cloud Run ou tout autre runtime de conteneurs.

Vous pouvez donc utiliser Gemini, ADK et Vertex AI Agent Engine ensemble, ou exécuter ADK localement puis le déployer ailleurs. ADK ne vous force pas à une seule architecture.

Concepts fondamentaux d’ADK

1. Agents

L’unité de base est un agent basé sur un LLM. En Python, vous l’importez depuis google.adk.agents.

La classe principale est LlmAgent, et Agent est un alias pratique. Vous lui fournissez :

• un nom ;
• un modèle ;
• une instruction système ;
• une liste d’outils ;
• éventuellement des sous-agents.

Exemple minimal :

from google.adk.agents import Agent

def get_exchange_rate(base: str, target: str) -> dict:
    """Return the exchange rate between two currencies."""
    # Ici, appelez votre vraie API de change.
    return {
        "base": base,
        "target": target,
        "rate": 1.08
    }

currency_agent = Agent(
    name="currency_exchange_agent",
    model="gemini-2.0-flash",
    instruction="You help users convert between currencies. Stick to the facts.",
    tools=[get_exchange_rate],
)

Cet agent peut répondre à une demande utilisateur et appeler get_exchange_rate lorsque le modèle estime qu’il a besoin d’un taux de change.

2. Outils

Les outils permettent à un agent de faire autre chose que générer du texte.

Dans ADK, une simple fonction Python peut devenir un outil. Le modèle s’appuie sur trois éléments pour comprendre comment l’utiliser :

• le nom de la fonction ;
• les annotations de type ;
• la docstring.

Exemple :

def search_order(order_id: str) -> dict:
    """Return the order status, delivery date, and tracking URL for a given order ID."""
    return {
        "order_id": order_id,
        "status": "shipped",
        "delivery_date": "2026-06-28",
        "tracking_url": "https://example.com/track/123"
    }

Une docstring précise améliore la capacité du modèle à choisir le bon outil au bon moment.

ADK fournit aussi des outils intégrés comme google_search et l’exécution de code. Il prend également en charge le Model Context Protocol MCP pour connecter des serveurs d’outils externes.

Dans une application réelle, beaucoup d’outils appellent des API REST : paiement, CRM, inventaire, moteur de recherche interne, API de données, etc. Ces appels doivent être testés séparément de l’agent.

3. Systèmes multi-agents

Un agent unique suffit pour des cas simples. Pour des workflows plus riches, ADK permet de composer plusieurs agents spécialisés.

ADK fournit plusieurs agents de workflow :

• SequentialAgent : exécute les sous-agents dans l’ordre ;
• ParallelAgent : exécute plusieurs sous-agents simultanément ;
• LoopAgent : répète une étape jusqu’à ce qu’une condition soit remplie.

Vous pouvez combiner ces workflows déterministes avec un routage piloté par LLM.

Exemple de structure :

from google.adk.agents import Agent

def search_flights(origin: str, destination: str, date: str) -> dict:
    """Find flight options for a route and date."""
    return {
        "origin": origin,
        "destination": destination,
        "date": date,
        "flights": []
    }

def search_hotels(destination: str, checkin: str, checkout: str) -> dict:
    """Find hotel options near a destination for given dates."""
    return {
        "destination": destination,
        "checkin": checkin,
        "checkout": checkout,
        "hotels": []
    }

flights = Agent(
    name="flight_agent",
    model="gemini-2.0-flash",
    instruction="Find flight options for the user's route and dates.",
    tools=[search_flights],
)

hotels = Agent(
    name="hotel_agent",
    model="gemini-2.0-flash",
    instruction="Find hotel options near the destination.",
    tools=[search_hotels],
)

trip_planner = Agent(
    name="trip_planner",
    model="gemini-2.0-flash",
    instruction="Planifier un voyage. Déléguer les recherches de vols et d'hôtels aux sous-agents appropriés.",
    sub_agents=[flights, hotels],
)

Le coordinateur reçoit la demande utilisateur, identifie les tâches nécessaires, puis délègue aux sous-agents.

4. Runners

En production, vous n’appelez pas directement un agent comme une simple fonction. ADK utilise un Runner.

Le Runner gère :

• la session ;
• le flux d’événements ;
• l’état ;
• les appels au modèle ;
• les appels d’outils ;
• la coordination entre agents.

Pendant le développement, utilisez la CLI ADK :

adk run

Cette commande lance une session interactive dans le terminal.

Pour inspecter plus facilement les étapes de raisonnement et les appels d’outils, utilisez :

adk web

Cette commande ouvre une interface web locale pour discuter avec l’agent et observer son exécution.

5. Évaluation et déploiement

ADK inclut un harnais d’évaluation. L’objectif est de tester un agent sur des trajectoires et des réponses attendues, plutôt que de valider manuellement une sortie isolée.

C’est utile lorsque vous modifiez :

• les instructions ;
• les outils ;
• les modèles ;
• les sous-agents ;
• les conditions de routage.

Pour le déploiement, vous avez deux chemins principaux :

• chemin géré : Vertex AI Agent Engine ;
• chemin portable : conteneuriser l’agent et le déployer sur Cloud Run ou une autre plateforme de conteneurs.

Exemple : créer un agent ADK autour d’une API REST

Un cas courant consiste à exposer une API existante comme outil d’agent.

Exemple simplifié avec requests :

import requests
from google.adk.agents import Agent

def get_customer_profile(customer_id: str) -> dict:
    """Return the customer profile, plan, and account status for a given customer ID."""
    response = requests.get(
        f"https://api.example.com/customers/{customer_id}",
        timeout=10
    )
    response.raise_for_status()
    return response.json()

support_agent = Agent(
    name="support_agent",
    model="gemini-2.0-flash",
    instruction=(
        "You help support agents answer customer questions. "
        "Use tools when customer account data is required."
    ),
    tools=[get_customer_profile],
)

Dans cet exemple, le point fragile n’est pas seulement le prompt. C’est aussi le contrat de l’API :

{
  "id": "cus_123",
  "plan": "pro",
  "status": "active"
}

Si l’API renvoie soudain account_status au lieu de status, l’agent peut produire une réponse incorrecte ou échouer de manière difficile à diagnostiquer. C’est pour cela que les outils doivent être testés comme des intégrations API classiques.

ADK vs SDK OpenAI Agents

Les deux frameworks sont orientés code et prennent en charge les agents, les outils et les transferts. La différence principale est l’écosystème cible.

	Google ADK	SDK OpenAI Agents
Modèle par défaut	Gemini, Vertex AI	Modèles OpenAI
Autres modèles	Vertex AI Model Garden, LiteLLM	LiteLLM et autres
Langages	Python, Java, Go, TypeScript	Python, JavaScript/TypeScript
Multi-agents	Sous-agents, SequentialAgent, ParallelAgent, LoopAgent	Agents comme outils et transferts
Runtime géré	Vertex AI Agent Engine	À fournir soi-même
Protocole d’outils	MCP, outils intégrés, fonctions	MCP, fonctions

Si votre stack est déjà sur Google Cloud, ADK et Vertex AI sont un choix naturel. Si vous privilégiez OpenAI, le SDK OpenAI Agents reste plus direct. Les deux supportent MCP, ce qui permet de partager certains serveurs d’outils entre écosystèmes.

Quand utiliser ADK ?

Utilisez ADK si :

• vous développez déjà sur Google Cloud ;
• vous voulez utiliser Gemini avec un runtime géré dans Vertex AI Agent Engine ;
• vous avez besoin d’orchestration multi-agents ;
• vous voulez contrôler explicitement des étapes séquentielles, parallèles ou en boucle ;
• vous souhaitez intégrer l’évaluation dans le cycle de développement ;
• vous voulez garder une option de changement de modèle via LiteLLM ou Vertex AI Model Garden.

Évitez ADK si votre cas d’usage tient dans une seule invite avec un ou deux appels de fonction simples. Un framework d’agents ajoute de la structure, mais cette structure a un coût lorsque la tâche est très limitée.

Où Apidog intervient : tester et mocker les API appelées par l’agent

ADK orchestre l’agent. Il ne remplace pas les tests des API que vos outils appellent.

Chaque outil important dépend souvent d’un service externe :

• endpoint LLM ;
• API de paiement ;
• microservice interne ;
• CRM ;
• API de recherche ;
• base de connaissance ;
• service tiers.

Si l’un de ces services renvoie une réponse inattendue, l’agent raisonne sur une mauvaise entrée. Le problème peut ensuite apparaître comme un “bug d’agent”, alors que la cause réelle est un contrat API cassé.

Apidog ne remplace pas ADK. Il se place une couche plus bas : sur les API appelées par les outils de votre agent.

1. Mocker les endpoints des outils

Pendant le développement, vous pouvez créer une API mock pour éviter d’appeler le service réel à chaque test.

Exemple de workflow :

1. définissez le contrat de l’endpoint dans Apidog ;
2. créez une réponse mock stable ;
3. pointez votre fonction outil vers l’URL mock ;
4. lancez l’agent avec adk web ;
5. observez comment l’agent réagit à la réponse.

Cela permet de tester des cas comme :

• réponse valide ;
• réponse vide ;
• erreur 401 ;
• erreur 429 ;
• timeout ;
• champ manquant ;
• format inattendu.

2. Vérifier la forme des réponses

Utilisez les assertions d’API pour confirmer que chaque endpoint renvoie les champs attendus par l’agent.

Par exemple, si votre outil attend :

{
  "status": "active",
  "plan": "pro"
}

Vous devez détecter rapidement une réponse comme :

{
  "account_status": "active",
  "subscription": "pro"
}

Sans assertion, ce changement peut passer inaperçu jusqu’à ce que l’agent produise une réponse incorrecte.

3. Séparer les environnements

Conservez les variables par environnement :

• développement ;
• staging ;
• production.

Cela évite de mélanger les clés API ou les URLs entre les étapes. Le même outil ADK peut être exécuté contre un mock, un environnement de test ou une API réelle selon la configuration.

4. Tester les appels d’outils avant la production

Avant de connecter un outil à un agent, testez-le comme une API normale :

1. validez les paramètres d’entrée ;
2. vérifiez le schéma de sortie ;
3. testez les erreurs ;
4. testez les limites de débit ;
5. ajoutez des réponses mock pour les scénarios critiques.

Pour un guide plus ciblé sur les agents, consultez comment tester les appels d’outils d’un agent IA avant qu’ils ne cassent en production. Vous pouvez aussi télécharger Apidog et mocker un endpoint en quelques minutes.

Foire aux questions

Google ADK est-il gratuit et open source ?

Oui. ADK est open source dans un dépôt GitHub sous licence Apache. Vous pouvez l’exécuter localement sans frais. Vous payez les modèles appelés et l’infrastructure managée utilisée, par exemple Vertex AI Agent Engine.

ADK fonctionne-t-il uniquement avec Gemini ?

Non. ADK est optimisé pour Gemini et Vertex AI, mais il est agnostique au modèle. Via Vertex AI Model Garden et LiteLLM, vous pouvez utiliser Anthropic, Meta, Mistral et d’autres fournisseurs. Gemini est le choix naturel dans l’écosystème Google, pas une obligation.

Quels langages ADK supporte-t-il ?

Python a été le premier langage et reste le plus complet. Google a ensuite ajouté Java, avec le support de Go et TypeScript à suivre. Pour la couverture fonctionnelle la plus large aujourd’hui, Python reste le choix le plus sûr.

Comment tester les API dont dépend mon agent ADK ?

Testez-les séparément de l’agent. Mocker les endpoints du LLM ou des outils vous permet d’exécuter l’agent sans appels réels. Ajoutez ensuite des assertions pour vérifier que chaque réponse correspond au contrat attendu. Le guide sur la façon de tester l’API ChatGPT montre le même modèle appliqué à un endpoint LLM.

Conclusion

Google ADK fournit une base solide pour construire des agents et des systèmes multi-agents orientés production. Commencez avec un agent simple, ajoutez des outils bien typés, inspectez l’exécution avec adk web, puis introduisez des sous-agents lorsque le workflow devient plus complexe.

La partie à ne pas négliger est le contrat des API appelées par vos outils. Un agent fiable dépend d’entrées fiables. Mockez vos endpoints, ajoutez des assertions et testez les erreurs avant la production. C’est précisément la couche que Apidog vous aide à sécuriser.