Imaginez ceci.
Vous donnez à un agent cinq outils et une seule instruction.
Votre processus de remboursement pourrait fonctionner parfaitement.
Puis, l'e-mail de confirmation échoue.
L'agent recommence toute la séquence, répète une action qui a déjà réussi.
Le résultat ? Un double remboursement.
Le prototype fonctionnait à merveille. Le système de production, non.
Le problème n'est pas le prompt.
Le problème, c'est de demander au modèle d'exécuter un processus qu'il ne devrait tout simplement jamais exécuter !
Les LLM sont constamment contraints de faire du routage, de la planification et de la gestion des erreurs.
Ce sont des tâches que les logiciels standard gèrent déjà avec une parfaite prévisibilité.
Pourtant, nous demandons à l'IA d'accomplir deux tâches contradictoires :
- Lire le monde : donner du sens à des données imprévisibles et non structurées
- Exécuter le processus : orchestrer une séquence d'événements rigide et prédéfinie
C'est dans le premier cas que l'IA brille. C'est dans le second que le code traditionnel a sa place.
Quand l'étape suivante est connue, un modèle ne devrait pas avoir à la deviner.
Imaginez un agent autonome à qui l'on donne cinq outils et une seule grande instruction :
→ récupérer l'historique des achats
→ vérifier la politique de remboursement
→ procéder au remboursement si éligible
→ envoyer un e-mail
→ puis clôturer le ticket
Pour y parvenir, l'agent doit mémoriser la séquence, inspecter chaque résultat d'outil et déduire ce qui vient ensuite.
Si l'e-mail de confirmation échoue après l'envoi de l'argent, le modèle tente de reconstruire le workflow à partir de sa fenêtre de contexte au lieu de reprendre depuis un état d'exécution sécurisé.
Le résultat est ce double remboursement mentionné plus haut.
Comment ADK 2.0 met de l'ordre dans le chaos
L'ADK 2.0 de Google corrige ce problème en adoptant une toute nouvelle approche.
Il ramène les actions prévisibles à des étapes de workflow concrètes, en n'utilisant l'IA que là où une interprétation est réellement nécessaire :
[Graphique du workflow de remboursement — source : « Pourquoi nous avons créé ADK 2.0 »]
Dans l'exemple ci-dessus, récupérer l'historique des achats, procéder au remboursement et clôturer le ticket sont des actions logicielles ordinaires.
L'analyse de la réclamation et la rédaction d'un message de confirmation personnalisé sont confiées à l'IA.
Le résultat est un bel hybride : une exécution fixe combinée à un raisonnement ciblé.
Mais vous vous demandez peut-être : n'est-ce pas simplement un retour à l'automatisation rigide ?
Sommes-nous en train de coder en dur les workflows mêmes que les agents étaient censés remplacer ?
Eh bien, pas tout à fait.
Le workflow définit les limites qui sont déjà connues.
Les agents continuent de gérer les parties qui nécessitent de l'interprétation, du langage ou du jugement.
L'objectif n'est pas de supprimer la flexibilité, mais de cesser de forcer le modèle à redécouvrir le même chemin d'exécution à chaque passage.
En éliminant ces décisions inutiles du modèle, cette architecture change complètement la donne.
Même workflow de remboursement. Même modèle.
Mais avec ADK 2.0, les tokens sont passés de 5 152 à 2 265, et la latence a chuté de 7,2 s à 5,7 s 🔥
[source : « Pourquoi nous avons créé ADK 2.0 »]
Cette structure agit comme un filtre naturel qui réduit l'utilisation des tokens de moitié.
Au lieu de transmettre tout l'historique, les agents ne voient que ce dont ils ont besoin (par exemple, l'agent chargé de la politique de remboursement ne voit que la réclamation).
Les avantages sont immédiats :
- Moins de bruit dans le prompt et une confidentialité accrue
- Une exécution étroitement encadrée
- Des garde-fous : un modèle peut se tromper, mais il ne peut jamais inventer son propre chemin
Le frontend a lui aussi besoin de limites : comment A2UI garde le contrôle de vos UI
Très bien. Le workflow de remboursement est maintenant sous contrôle.
ADK 2.0 a défini le chemin et empêché l'agent d'inventer sa propre séquence.
Mais l'utilisateur a toujours besoin d'un moyen sûr de voir et d'agir sur ce que l'agent produit.
En d'autres termes, le frontend a lui aussi besoin de limites !
Imaginez que chaque remboursement approuvé exige désormais la validation d'un superviseur.
L'agent ne doit pas simplement générer un texte disant :
« Ce remboursement est approuvé. »
Il doit afficher une carte structurée contenant :
- le montant
- la transaction
- le motif de la politique
- des boutons clairs « Approuver/Rejeter »
C'est exactement là qu'intervient l'A2UI de Google !
Avec A2UI, l'agent renvoie un payload JSON déclaratif plutôt qu'un code frontend exécutable.
L'hôte valide ce payload et n'affiche que les composants pris en charge par son catalogue.
L'agent décide des informations à afficher, et l'application contrôle leur rendu.
👇 Voici des exemples de cartes générées par A2UI, qui vous montrent la grande variété de compositions d'interface qu'A2UI peut réaliser :
La démo A2UI-over-MCP Recipe Studio de Google montre cette architecture en pratique :
Source : Google Developers Blog.
👆 Vous pouvez voir qu'un formulaire de sélection statique est fourni via une ressource MCP, tandis qu'une carte de recette générée dynamiquement est renvoyée via un outil MCP.
A2UI affiche les deux nativement dans l'application hôte.
Remarquez-vous la symétrie ?
- ADK 2.0 limite ce que l'agent peut faire côté backend
- A2UI limite ce qu'il peut créer côté frontend
Dans les deux cas, le modèle a une marge de manœuvre pour raisonner, mais uniquement dans les limites définies par l'application.
Pour revenir à l'exemple de remboursement évoqué plus haut, un remboursement standard peut n'avoir besoin que d'une simple carte d'approbation.
Mais un cas litigieux impliquant des exceptions, des pièces jointes ou des remboursements partiels pourrait nécessiter une expérience plus riche.
C'est là qu'une application MCP peut intervenir pour fournir un espace de travail dédié aux interactions complexes :
→ ADK contrôle ce qui peut se produire
→ A2UI rend le résultat visible et exploitable
→ Les applications MCP gèrent les espaces de travail complexes
Curieux d'en savoir plus ?
Voici tout ce dont vous avez besoin pour explorer ADK 2.0, A2UI et la plateforme d'agents plus large de Google Cloud :
- ADK 2.0 : https://fandf.co/4yJhcyh
- A2UI : https://fandf.co/3S1O9pe
- A2UI over MCP : https://fandf.co/45vomJ3
- Gemini Enterprise Agent Platform : https://fandf.co/4x59VY7
Ce fut un privilège de collaborer avec @googlecloud sur ce projet ! 🤝
Si vous souhaitez rester à jour sur les dernières nouveautés en matière de LLM, d'agents IA et de workflows, vous pouvez me suivre @datachaz pour des analyses quotidiennes.
