A2UI 1.0 : ce que les interfaces génératives changent pour les équipes produit

Google a publié le 11 novembre 2026 la version 1.0 d’A2UI, un protocole ouvert conçu pour permettre aux agents d’intelligence artificielle de répondre avec des interfaces interactives plutôt qu’avec de simples blocs de texte. Pour les équipes produit, design et développement, l’enjeu ne consiste pas à laisser un modèle inventer librement l’interface : l’application garde la maîtrise de ses composants, de son identité visuelle et des actions autorisées.

En bref

• Annonce : 11 novembre 2026.
• Source principale : Google Developers Blog et documentation officielle A2UI.
• Statut : protocole A2UI 1.0 stable et projet open source sous licence Apache 2.0.
• Disponibilité : SDK et renderers disponibles pour plusieurs environnements web et mobiles ; certaines intégrations restent en version antérieure ou en cours d’adaptation.
• Publics concernés : product designers, UX/UI designers, product managers, développeurs, équipes design system, responsables d’agents et de produits numériques.
• Impact professionnel : potentiellement fort pour les produits qui veulent transformer une conversation avec un agent en parcours interactif contrôlé.
• Dernière vérification des références : 13 novembre 2026.

Ce que Google vient d’annoncer

A2UI signifie « Agent-to-User Interface ». Le principe est de séparer trois responsabilités. L’agent détermine, dans un cadre prévu, quelle information ou quelle interaction est utile. Le protocole transporte une description structurée de l’interface et de ses données. Enfin, l’application cliente rend cette description avec ses propres composants.

La version 1.0 introduit notamment des appels de fonctions bidirectionnels. Une interface générée peut donc demander une information actualisée ou déclencher une fonction autorisée, par exemple vérifier une disponibilité avant d’afficher un choix. Le protocole ajoute également une prise en charge de l’accessibilité et un mécanisme d’extensions pour transporter des métadonnées supplémentaires.

Google annonce des bibliothèques de rendu open source pour React, Angular et Lit sur le web, Flutter sur plusieurs plateformes, SwiftUI sur iOS et Jetpack Compose sur Android. La documentation précise toutefois que Jetpack Compose prend actuellement en charge A2UI 0.9.1, avec la version 1.0 annoncée comme prochaine étape. Des SDK d’agents sont proposés pour Python, TypeScript et Dart.

Les renderers web et Flutter peuvent aussi fonctionner dans des MCP Apps. Selon Google, cela permet à une même surface A2UI d’apparaître dans une application propre ou dans un assistant compatible, notamment Claude ou Gemini. Cette portabilité est l’une des promesses centrales du protocole, mais elle dépend toujours du catalogue de composants et des fonctions réellement acceptés par l’hôte.

Pourquoi une interface vaut parfois mieux qu’une réponse textuelle

Une conversation reste efficace pour demander une explication ou produire un brouillon. Elle devient moins pratique lorsqu’un utilisateur doit comparer plusieurs options, modifier des paramètres, sélectionner une date, valider un plan détaillé ou comprendre un ensemble de données. Une réponse textuelle oblige souvent à multiplier les tours de conversation : l’agent pose une question, l’utilisateur répond, puis une nouvelle ambiguïté apparaît.

Une interface interactive peut condenser ces choix dans un écran. Un sélecteur de date expose les contraintes disponibles. Une carte de validation récapitule ce qui sera envoyé. Un graphique rend une évolution plus lisible qu’une suite de chiffres. L’utilisateur ne renonce pas à la conversation ; il dispose d’un support visuel et actionnable au moment où celui-ci est utile.

Ce que cela change pour les product designers

Concevoir des règles de composition, pas chaque écran isolément

Dans un produit classique, le designer décrit des écrans et des états prévisibles. Avec une interface générative, toutes les combinaisons ne peuvent pas être dessinées à l’avance. Le travail se déplace vers la définition d’un vocabulaire : composants autorisés, propriétés, hiérarchie, variantes, comportements, messages d’erreur et relations entre données.

Ce vocabulaire prend la forme d’un catalogue A2UI. Le modèle peut choisir et configurer les éléments inscrits dans ce catalogue, mais il ne reçoit pas le droit d’exécuter du code arbitraire ou d’introduire un composant inconnu. Le catalogue devient donc à la fois une extension du design system et une frontière fonctionnelle.

Les équipes design doivent prévoir les assemblages robustes plutôt que les seuls cas idéaux. Que se passe-t-il si un titre est très long, si une donnée manque, si trois actions sont proposées au lieu d’une, si un graphique n’a qu’un point ou si le texte est affiché dans une autre langue ? Les composants doivent rester compréhensibles lorsque leur contenu est décidé dynamiquement.

Traiter la confirmation comme un élément de confiance

Google illustre A2UI avec des cartes qui permettent de revoir puis de confirmer une action. Ce principe mérite d’être généralisé. Plus une action a des conséquences importantes, plus l’interface doit montrer clairement les données utilisées, la destination, les paramètres et le moment où l’exécution devient effective.

Un bon parcours agentique ne cherche pas à supprimer toutes les étapes. Il réduit les étapes inutiles tout en renforçant celles qui protègent l’utilisateur. Pour une réservation, une modification de calendrier, un envoi ou une mise à jour d’un dossier, une vue récapitulative peut être plus sûre qu’une confirmation implicite dans le fil de discussion.

Évaluer l’expérience générée, pas seulement le composant

Un composant peut être conforme au design system et produire malgré tout une expérience confuse lorsqu’il est mal choisi ou mal ordonné. Les tests doivent donc porter sur les séquences complètes : compréhension de la demande, choix des composants, qualité des libellés, gestion des erreurs, retour arrière et comportement après l’action.

Il faut aussi tester la variabilité. Une même demande formulée de plusieurs façons doit conduire à des parcours cohérents. À l’inverse, deux besoins différents ne doivent pas être écrasés dans une interface générique. Les équipes produit peuvent constituer un jeu de scénarios représentatifs et observer les écarts avant d’élargir le périmètre.

Ce que cela change pour les développeurs et les équipes produit

A2UI ne fournit pas un agent complet. La documentation sépare l’inférence, le transport et le rendu. L’équipe reste responsable du modèle ou du moteur de décision, des outils auxquels l’agent accède, des données, de l’authentification, des autorisations et de la logique métier.

Le SDK d’agent aide à produire et valider les messages A2UI, tandis que le renderer transforme ces messages en composants du framework choisi. Les valeurs liées peuvent évoluer localement et les actions de l’utilisateur remontent vers le serveur. Cette architecture permet d’afficher progressivement une surface pendant que l’agent travaille, mais elle introduit aussi de nouveaux points à observer : temps de génération, erreurs de validation, version du catalogue, compatibilité du renderer et disponibilité des fonctions appelées.

Pour le product manager, la priorité est de choisir un cas d’usage où l’interface dynamique apporte un avantage mesurable. Le protocole ne justifie pas de rendre tout l’écran génératif. Une zone ciblée peut suffire : compléter les informations manquantes d’une demande, comparer des options, explorer un jeu de données ou confirmer un plan produit par l’agent.

Design system : le catalogue devient une frontière opérationnelle

Dans A2UI, l’application enregistre les composants accessibles à l’agent. Cette approche protège l’identité de marque : typographie, couleurs, espacement et comportements restent implémentés côté produit. L’agent demande par exemple une carte, un formulaire ou un graphique ; il ne définit pas librement toute la feuille de style.

Pour une équipe design system, cela suppose de documenter les composants d’une manière exploitable par une machine. Le nom, la fonction, les propriétés attendues, les contraintes, les événements et les usages interdits doivent être suffisamment explicites pour guider l’agent et le validateur. Les descriptions deviennent une partie du produit, pas un simple commentaire technique.

Sécurité et données : ce que le protocole encadre, et ce qu’il ne règle pas

Le dépôt officiel présente A2UI comme un format de données validées plutôt qu’un mécanisme d’exécution de code arbitraire. Le développeur contrôle les composants et les capacités accordés à l’agent. Google indique aussi que certaines liaisons de données peuvent être réalisées côté serveur afin que des valeurs sensibles ne soient pas envoyées au modèle.

Ces propriétés réduisent certains risques, mais elles ne sécurisent pas automatiquement le produit. Une fonction autorisée peut rester trop puissante. Un catalogue peut révéler une donnée qu’un utilisateur ne devrait pas voir. Un agent peut choisir un composant valide mais proposer une action inadaptée au contexte. L’authentification, les contrôles d’accès, la journalisation et les validations métier restent indispensables.

Chaque fonction bidirectionnelle doit donc être analysée comme une capacité réelle. Il faut préciser qui peut l’appeler, sur quelles données, avec quelles limites, et si une confirmation est requise. Les événements doivent être journalisés de façon compréhensible pour permettre l’analyse d’un incident ou d’un comportement inattendu.

Disponibilité et maturité : ne pas confondre version stable et produit fini

La publication de la version 1.0 stabilise le protocole, mais l’écosystème continue d’évoluer. Le dépôt officiel mentionne déjà une réflexion sur la version 1.1, des travaux sur les modèles de décision, des primitives réutilisables, de la logique isolée, des évaluations et des intégrations MCP Apps plus poussées.

Tous les renderers ne sont pas au même niveau. Google précise par exemple que Jetpack Compose est encore en 0.9.1 et doit passer à la version 1.0. Gemini prend également en charge A2UI 0.9.1 au moment de l’annonce, tandis qu’une mise à niveau vers 1.0 est en cours. Une équipe doit donc vérifier la version exacte de chaque brique avant de planifier une mise en production.

Les exemples et le quickstart facilitent l’exploration, mais la documentation indique que l’application de démonstration Travel A2UI est destinée à l’apprentissage et non à un usage de production. Cette distinction est importante : un prototype fonctionnel ne prouve ni la robustesse, ni l’accessibilité complète, ni la conformité d’un parcours réel.

Une méthode de test en six étapes

La présentation Google d’A2UI 1.0 décrit les capacités du protocole. Unexia n’a pas exécuté de prototype dans le cadre de cet article. Le Quickstart officiel propose un exemple d’apprentissage ; il ne constitue pas une application de production validée.

Exemple illustratif à tester : demande « Propose deux créneaux pour mon rendez-vous ». Le catalogue n’autorise que deux composants : une liste de créneaux et un bouton de confirmation. L’action consiste à sélectionner un créneau, puis à envoyer une demande de réservation après confirmation. Le serveur recontrôle les droits et la disponibilité avant l’envoi. Le test doit aussi vérifier un créneau devenu indisponible et l’absence de confirmation ; aucune réservation ne doit alors partir. Ce scénario est proposé par Unexia, sans résultat de test revendiqué.

1. Choisir une interaction étroite. Partir d’une tâche où un formulaire, une comparaison ou une confirmation améliore clairement le texte seul.
2. Définir le catalogue minimal. Exposer uniquement les composants et fonctions nécessaires au scénario.
3. Fixer les responsabilités. Séparer ce que décide l’agent, ce que valide le serveur et ce que confirme l’utilisateur.
4. Préparer les cas limites. Tester les données absentes, les libellés longs, les erreurs réseau, les refus et les demandes hors périmètre.
5. Mesurer l’expérience. Comparer le nombre d’étapes, les erreurs, le taux d’abandon, le temps de réalisation et la compréhension avec le parcours actuel.
6. Élargir seulement après observation. Ajouter des composants ou des actions lorsque l’équipe sait expliquer les bénéfices et maîtriser les risques.

L’analyse Unexia

A2UI 1.0 mérite un test ciblé pour les organisations qui construisent déjà un agent ou un produit conversationnel. Il n’est pas nécessaire de revoir immédiatement toute l’interface. La bonne question est plus simple : à quel moment une conversation oblige-t-elle l’utilisateur à comparer, corriger ou confirmer trop d’informations ? C’est là qu’une surface interactive peut créer une valeur réelle.

Pour les designers, la compétence clé devient la conception de systèmes capables d’accueillir de la variabilité sans perdre en clarté. Pour les développeurs, le protocole apporte une structure, mais pas une délégation de responsabilité. Pour les responsables produit, l’enjeu est de fixer un niveau d’autonomie cohérent avec le risque de la tâche.

La recommandation est donc de tester, pas de généraliser. Un prototype relié à un petit catalogue, à des données non sensibles et à des actions réversibles permet d’évaluer la qualité des compositions. Une mise en production doit attendre des preuves sur l’accessibilité, la cohérence, la sécurité et le comportement en erreur.

Pour aller plus loin

Avant de concevoir l’interface d’un agent, il faut comprendre ce qu’il peut réellement faire, quelles ressources il utilise et quand il doit demander une validation. Le guide Agent IA : définition, fonctionnement, cas d’usage et outils d’Unexia Lab fournit ce cadre durable pour relier capacité, permissions et supervision humaine.

Sources

• Google Developers Blog — A2UI 1.0: Build delightful, fast, reliable, agentic experiences, 11 novembre 2026.
• Documentation A2UI — Quickstart, consultée le 12 novembre 2026.
• Dépôt officiel A2UI sur GitHub, licence Apache 2.0, consulté le 12 novembre 2026.
• Photo de Pavel Danilyuk sur Pexels, utilisée sous licence Pexels.

‍