Google a publié A2UI 1.0 le 11 novembre 2026, en le présentant comme la première version stable de son protocole ouvert pour les interfaces génératives. Dans un article du blog Google Developers, l'équipe A2UI, avec le chef de produit Vishal Motwani, expose son idée sans détour : les agents actuels répondent surtout par du texte, ce qui se prête mal à la comparaison de trois produits ou à la validation d'un plan détaillé. L'agent devrait donc décrire un écran interactif et laisser chaque application le dessiner.
Le protocole repose sur une répartition des rôles. L'agent envoie des messages A2UI structurés qui indiquent quoi afficher, par exemple un formulaire à confirmer ou un graphique, et l'application hôte les restitue avec ses propres composants natifs. Selon Google, les agents ne peuvent placer que des composants que l'entreprise a enregistrés depuis son système de design, et la liaison aux données se fait côté serveur, si bien que les valeurs sensibles n'atteignent jamais le modèle. Ces garanties de sécurité sont la description de Google et n'ont pas fait l'objet d'un test indépendant ici.
La version 1.0 apporte trois nouveautés. Le protocole devient stable et gagne des appels de fonction dans les deux sens, de sorte qu'un sélecteur de vol ou de réservation puisse vérifier la disponibilité sur le champ, ainsi qu'une prise en charge de l'accessibilité et des extensions pour des métadonnées supplémentaires. Les moteurs de rendu open source couvrent React, Angular et Lit sur le web, Flutter sur mobile, web et ordinateur, et SwiftUI sur iOS, tandis que celui de Jetpack Compose pour Android reste à la version 0.9.1, la 1.0 étant annoncée prochainement. De nouveaux SDK d'agent en TypeScript et Dart rejoignent celui de Python et gèrent la génération de compétences, la traduction des messages et la correction d'erreurs, avec des formats d'inférence interchangeables pour réduire la latence et, en Python, des macros pour l'expansion de composants et la liaison de données. Les moteurs web et Flutter fonctionnent aussi à l'intérieur de MCP Apps ; les écrans A2UI peuvent donc apparaître dans les assistants compatibles, que Google cite sous les noms de Claude et de Gemini.
Google énumère ses premiers utilisateurs. Atlassian s'en sert dans Jira pour qu'un agent à qui il manque une information puisse la demander à l'équipe au moyen d'une carte interactive placée dans le ticket. Alation génère des fils de cartes de métriques et de graphiques qui s'affichent aussi bien dans Claude que dans sa propre application. ByteDance a publié en juin 2026 un moteur de rendu A2UI pour son framework Lynx et prépare le passage à la 1.0, et Bloomberg figure parmi les entreprises qui développent avec le protocole. Chez Google même, Gemini Notebook affiche des cartes d'options et de relecture quand un utilisateur réclame une présentation. Gemini prend en charge A2UI 0.9.1 aujourd'hui et permet aux organisations d'enregistrer des agents qui répondent avec ce format ; Google affirme préparer la migration de Gemini Enterprise vers la 1.0, d'autres équipes développant des fonctions pas encore lancées.
La couverture extérieure reste pour l'instant surtout descriptive. SD Times et Digital Influence ont rapporté la sortie le jour même en reprenant la présentation de Google. CopilotKit, entreprise qui a travaillé avec l'équipe de Google, a publié son propre guide : selon elle, A2UI circule sur son protocole AG-UI, et elle propose un produit d'interface générative doté d'un catalogue de 70 composants bâti sur cette version. C'est un signal d'écosystème, pas une évaluation indépendante.
Les développeurs d'agents doivent lire ces affirmations avec prudence. Les descriptions des adoptants proviennent de l'article de Google, le moteur Android et Gemini lui-même restent en retrait de la version 1.0, et aucune mesure indépendante de latence, de sécurité ou d'effort de développement n'a été trouvée. L'intérêt concret tient à une cible stable, soutenue par un grand éditeur, pour les interfaces d'agents, qui cohabite avec MCP Apps et peut limiter la tentation de construire une couche d'écrans distincte pour chaque assistant.