ADK Kotlin 1.0 : des agents mobiles sous contrôle

ADK for Kotlin 1.0, publié par Google, apporte aux équipes Kotlin et Android un socle pour créer des agents avec outils typés, mémoire de session et étapes de confirmation. Pour un produit mobile, la vraie question n’est pas « peut-on ajouter un agent ? » : c’est quelles données il peut utiliser, quelles actions il peut proposer et quand une personne doit garder la main.

Ce que met à disposition ADK for Kotlin 1.0

Google annonce la disponibilité générale de la version 1.0, alignée sur le cœur ADK et conçue pour Kotlin Multiplatform. Le kit propose notamment la coordination de plusieurs agents, la reprise de session, la gestion du contexte et des flux de confirmation humaine. Côté Android, il peut s’appuyer sur Room et AppSearch pour conserver le contexte de l’application, ainsi que sur des options locales ou cloud selon le cas d’usage.

Ces briques ne constituent pas une architecture prête à livrer. Elles permettent de construire une expérience plus explicite : l’application peut répondre, préparer une action ou retrouver un contexte, sans confondre une suggestion du modèle avec une opération autorisée.

Commencer par la frontière des actions sensibles

L’exemple de Google marque certaines fonctions comme nécessitant une confirmation. C’est un principe très utile au-delà du paiement : modifier une donnée, envoyer un message, déclencher une commande ou partager un document mérite une étape visible dans l’interface, avec un libellé compréhensible et la possibilité de renoncer.

Un cadrage concret avant le premier pilote

1. Lister les outils : décrire chaque accès réel de l’agent — lecture, écriture, recherche ou action externe — et ne pas lui donner d’autorisation implicite.
2. Choisir le lieu des données : distinguer le contexte qui peut rester sur l’appareil, celui qui doit être synchronisé et celui qui ne doit pas être envoyé à un modèle.
3. Dessiner la confirmation : montrer l’action proposée, son effet et les informations impliquées avant toute exécution irréversible.
4. Tester les refus : vérifier qu’un refus, une perte de réseau ou une reprise après fermeture de l’application produisent un état clair et sûr.

Local, cloud ou hybride : une décision produit

Un modèle local peut aider à préserver la réactivité ou limiter des transferts, tandis qu’un service cloud peut apporter des capacités différentes. Le bon découpage dépend de la valeur attendue, de la sensibilité des données, du coût d’exploitation et du comportement attendu sans connexion. Il vaut mieux démarrer avec un parcours précis — par exemple préparer une demande de support — que promettre un assistant généraliste sans périmètre vérifiable.

La persistance n’est pas non plus un détail technique : si l’application mémorise une conversation, l’utilisateur doit comprendre ce qui est conservé, pouvoir reprendre son parcours sans surprise et trouver les contrôles adaptés à son contexte.

Transformer une capacité IA en expérience fiable

L’annonce officielle de Google du 9 septembre 2026 détaille les modules et exemples. Avant l’intégration, choisissez un parcours mobile mesurable, écrivez les règles d’autorisation et observez les échecs réels. L’agent devient alors une fonctionnalité du produit, pas une boîte noire posée au-dessus de lui.