a2ui : Google laisse les agents IA composer l’interface

Une équipe produit veut passer d’un agent en discussion à un vrai parcours, avec formulaires et actions. Google pousse A2UI pour y arriver, sans demander à l’agent d’envoyer du code exécutable.

Dans les faits, A2UI est un protocole Agent-to-UI (A2UI) open source qui permet à un agent d’intelligence artificielle (agent IA) de « composer » une interface utilisateur (UI) en décrivant des composants, plutôt qu’en renvoyant du langage de balisage hypertexte (HTML) et du JavaScript (JS).

Table des matières

Le problème concret que ça résout

Les agents IA en mode discussion restent efficaces pour expliquer, pas toujours pour faire. Dès qu’il faut collecter des informations structurées, la conversation devient lente et fragile.

On connaît la séquence classique : “quelle date ?”, puis “combien de personnes ?”, puis “à quelle heure ?”. À chaque étape, on perd du contexte, on multiplie les erreurs et l’utilisateur ne voit jamais l’ensemble.

Dans ce contexte, un autre sujet devient critique : la frontière de confiance (trust boundary). Beaucoup d’agents sont distants, parfois opérés par un tiers, et doivent pourtant afficher une UI dans l’application hôte, sans accès direct à ses composants.

Jusqu’ici, une solution fréquente consistait à renvoyer de l’HTML/JS rendu dans un cadre intégré (iframe). Cela marche vite en démonstration, mais la facture arrive en production.

Avec un iframe, l’UI a tendance à “faire pièce rapportée” : style différent, comportements incohérents, et accessibilité incertaine. La maintenance se complique, car l’agent “définit” la présentation au lieu de s’appuyer sur le système de design (design system) existant.

A2UI prend l’approche inverse : l’agent n’envoie que des données, sous forme de JavaScript Object Notation (JSON). Le client rend l’UI avec ses propres composants natifs, via un moteur de rendu (renderer) compatible.

À la clé, trois effets attendus : une cohérence visuelle avec l’application, une meilleure compatibilité accessibilité, et une surface d’attaque réduite puisque l’agent ne peut pas exécuter de code arbitraire. Pour creuser, la documentation et les exemples de référence sont centralisés sur le site du projet A2UI .

A2UI en clair : le modèle mental à retenir

Le principe est simple : l’agent IA propose une « maquette décrite », et l’application hôte la matérialise. Autrement dit, l’agent décrit quoi afficher, et le client décide comment l’afficher.

A2UI s’appuie sur un flux, souvent en JSON Lines (JSONL), ce qui autorise un rendu progressif (progressive rendering). L’utilisateur voit l’interface se construire au fil des messages, au lieu d’attendre une réponse complète.

Pour les équipes, trois types de messages suffisent à comprendre l’essentiel, sans entrer dans le détail du schéma :

surfaceUpdate décrit la structure : quels composants, quels identifiants, quelles relations. dataModelUpdate envoie les données et la liaison de données (binding) entre champs et modèle. beginRendering déclenche l’affichage quand le client est prêt.

Un choix de conception explique la robustesse côté génération : A2UI utilise une liste d’adjacence (adjacency list). Au lieu d’un arbre JSON imbriqué, les composants sont listés “à plat” et reliés par des identifiants.

Pourquoi c’est important ? Un modèle de langage se trompe facilement dans les imbrications longues, et produit du JSON cassé. Avec une structure plate, il peut ajouter un composant après l’autre, puis les relier, ce qui colle bien au streaming.

Les liaisons de données reposent sur un pointeur JSON (JSON Pointer), un format standardisé pour viser un chemin dans un document JSON. Si vos équipes veulent un repère neutre et durable, la référence est la RFC 6901 du RFC Editor .

Checklist d’intégration : un MVP en 1 à 2 jours

L’objectif réaliste n’est pas de “tout rendre génératif” dès le départ. Un MVP consiste à rendre un seul parcours, de bout en bout, avec validation et retour d’état.

Étape 1 : choisir le moteur de rendu côté client. Aujourd’hui, les implémentations citées dans l’écosystème couvrent notamment Web Components (avec Lit), Angular et Flutter. La feuille de route mentionne React puis des solutions natives comme SwiftUI (bibliothèque d’interface Apple) et Jetpack Compose.

Étape 2 : cadrer un catalogue approuvé (trusted catalog). C’est votre liste blanche de composants autorisés, avec leurs propriétés permises. En pratique, on démarre petit : champs texte, sélecteurs, boutons, cartes, tableaux simples.

Étape 3 : choisir le transport selon l’interactivité. Pour du streaming unidirectionnel, les événements envoyés par le serveur (SSE) suffisent souvent. Pour des interactions serrées, un canal WebSocket devient plus confortable.

Si vous avez déjà plusieurs agents et de l’orchestration, l’empilement peut inclure Agent-to-Agent (A2A) et Agent-User Interaction (AG-UI). A2A vise surtout la coordination entre agents, et Google indique l’avoir donné à la Linux Foundation ; cela aide à situer l’initiative dans une logique d’écosystème plutôt que de produit fermé.

Étape 4 : côté agent, outiller la génération. Intégrez le schéma A2UI dans les instructions système. Si votre modèle le supporte, imposez une sortie structurée (structured output) plutôt qu’un texte libre.

Ajoutez deux ou trois exemples proches de vos écrans cibles, sinon l’agent improvisera. Les exemples doivent refléter votre catalogue approuvé et vos libellés métier.

Étape 5 : valider systématiquement avant rendu. Validez au schéma JSON, rejetez les types inconnus, vérifiez les pointeurs JSON, et imposez des limites de taille. C’est le garde-fou qui évite les hallucinations “inoffensives” mais cassantes.

Pour les équipes produit et développement, les livrables minimaux sont clairs : un écran formulaire, un écran résultats, puis un écran confirmation. Avec ça, vous testez la boucle complète, sans vous disperser.

Deux cas d’usage qui parlent

Cas 1 : une réservation en formulaire, au lieu d’un ping-pong en discussion

Imaginez un parcours de réservation : date, nombre d’invités, préférences. L’agent IA génère l’UI, l’utilisateur remplit, puis le client renvoie un dataModelUpdate que l’agent exploite pour proposer l’étape suivante.

Le gain est immédiat : la validation est plus proche de l’action, et l’utilisateur voit ce qui manque. Vous réduisez aussi les incompréhensions, car les champs imposent une structure.

Mini-extrait simplifié, pour rendre l’idée tangible (structure plate, et une liaison via pointeur JSON) :

{"type":"surfaceUpdate","components":[
 {"id":"form","component":"Form","children":["date","guests","submit"]},
 {"id":"date","component":"DateInput","label":"Date","bind":"/reservation/date"},
 {"id":"guests","component":"NumberInput","label":"Invites","bind":"/reservation/guests"},
 {"id":"submit","component":"Button","label":"Verifier","action":"confirm"}
]}
{"type":"dataModelUpdate","data":{"reservation":{"date":"2026-01-12","guests":4}}}
{"type":"beginRendering"}

L’extrait ne montre pas tout, mais on voit l’essentiel : l’agent décrit, le client rend, et la donnée reste inspectable. Pour une équipe produit, cela se traduit par des itérations plus rapides sur le parcours, sans réécrire des écrans complets.

Cas 2 : un workflow d’approbation en entreprise, plus audit-able

Dans les opérations, la finance ou les ressources humaines, l’agent IA doit souvent guider un salarié dans une décision : valider une dépense, approuver un recrutement, traiter une exception.

A2UI est intéressant ici pour trois raisons : la cohérence avec votre système de design, l’auditabilité des actions, et la séparation nette entre l’affichage et les droits. Le client reste maître des composants “sensibles” et des confirmations.

Concrètement, on vise une UI de type tableau d’approbation avec filtres, un panneau de détail, puis deux actions : approuver ou refuser avec justification. Le modèle se prête aussi à des contrôles : un bouton “Approuver” peut exiger une double confirmation côté client, même si l’agent le propose.

Points de vigilance : ce qui peut casser en production

A2UI réduit le risque technique lié au code injecté, mais ne supprime pas les risques produit. L’UI générée reste une surface d’influence, donc une surface d’attaque.

Sécurité d’expérience : pas d’exécution d’HTML/JS, mais une UI trompeuse reste possible (ingénierie sociale). Prévoyez des confirmations natives sur les actions critiques.
Injection d’instructions (prompt injection) : un utilisateur peut pousser l’agent à contourner vos règles d’UI ou de wording. Protégez vos instructions système et journalisez les générations.
Gouvernance : fixez des règles claires sur les libellés, les états de transaction et les retours d’erreur. Sans ça, l’agent variera trop, et le support explosera.
Accessibilité : le “natif” aide, mais seulement si votre catalogue approuvé est lui-même accessible. Testez clavier, lecteurs d’écran et contrastes.
Coûts et performance : le streaming peut multiplier les mises à jour et gonfler les charges. Mesurez la taille des messages, la fréquence, et imposez des plafonds.

Positionnement rapide face aux autres approches

Face à l’HTML en iframe, A2UI privilégie le contrôle et la cohérence plutôt que la flexibilité brute. C’est un choix logique pour des applications métiers, où l’UI doit rester conforme et maintenable.

Face à des gabarits statiques, A2UI apporte de la souplesse quand le cas n’a pas été prévu. En contrepartie, vous devez investir dans le catalogue approuvé et dans la validation, sinon l’agent produira des écrans instables.

Enfin, il faut distinguer le rôle de chaque brique : A2UI décrit l’UI, tandis qu’AG-UI ou A2A transportent les messages et aident à orchestrer des systèmes multi-agents. L’empilement est modulaire, ce qui évite de tout remplacer d’un coup.

Que faire maintenant ?

La bonne stratégie est prudente : démarrez par un seul workflow à forte friction, comme un formulaire ou une approbation. Limitez le catalogue approuvé, forcez la sortie structurée et validez tout avant affichage.

Le critère de décision est assez net. Si vous avez des agents distants ou tiers et besoin d’une UI native cohérente sur plusieurs plateformes, A2UI mérite un projet pilote immédiat ; sinon, des gabarits peuvent suffire, quitte à évoluer ensuite.