GenUI : et si on laissait la machine composer l’interface en temps réel ?

L’article en bref : La Generative UI (GenUI) désigne une nouvelle logique de conception d’interface où une IA compose les pages en temps réel selon le contexte d’usage de l’utilisateur, à partir d'un catalogue de blocs et composants prédéfinis. Un basculement vers une approche dynamique nécessaire mais qui soulève des questions sur une potentielle dilution de l’identité de la marque.

L’interface universelle est une espèce en voie de disparition, bousculée par les nouveaux usages nés de l’adoption exponentielle des LLM ces dernières années. L'utilisateur de 2026 n'explore plus, il arrive avec une intention déjà formée, depuis une source précise (moteur de recherche, AI Overviews, assistant conversationnel, réseau social…), dans un contexte et un état émotionnel qui lui sont propres. Concevoir des pages figées, pensées pour un visiteur moyen, ne peut donc plus répondre à cette réalité. Ce glissement, d’un design statique à un mode dynamique, est déjà là et il convient de s'y préparer. Encore faut-il appliquer les bons principes pour y parvenir…

Parmi eux, le concept de Generative UI (ou GenUI) où une IA qui génère elle-même une interface en temps réel (cards, formulaires, dashboards…) selon le besoin et le contexte de l'utilisateur, en conversation ou directement au sein d'une page. Mais attention, GenUI ne veut pas dire que l'IA invente une interface à chaque requête. Elle veut dire qu'un agent réordonne et alimente des briques existantes, dans un cadre que le design a fermé à double tour.

Décryptage d’une tendance de conception à ne pas négliger en cette rentrée.

Le contexte, nouvelle matière première de la conception

Dans ce nouveau mode de conception, ce n'est plus le persona qui guide la composition des pages mais ce fameux "contexte". Un mot qui recouvre en réalité plusieurs dimensions, déjà posées à la fin des années 1990 par les chercheurs du context-aware computing Gregory Abowd et Elizabeth Mynatt : les cinq W (who, what, where, when, why). Vingt-cinq ans plus tard, ce cadre reste valide, les "qui, quand, pourquoi, comment" déterminant ce qui va constituer le "quoi".

Parmi les principaux signaux à exploiter : 

• Qui : nouveau visiteur ou visiteur connu, historique, comportements de navigation habituels…
• Quand : moment de la journée, période de l’année, étape dans le parcours (découverte, comparaison, décision…), état émotionnel, en mobilité…
• Pourquoi : intention inférée depuis la source d’acquisition, la requête, les filtres utilisés
• Comment : device utilisé, mode d’interaction

Le mobile, grâce à ses capteurs, est l’allié le plus naturel pour lire ces signaux. Google Meet, par exemple, détecte via l'accéléromètre du smartphone qu'un utilisateur est en mouvement et bascule automatiquement vers un mode “en déplacement”. Les boutons sont réduits et élargis, le micro mis en avant. Aucune génération ici, juste une simple règle. Mais l'exemple illustre bien le principe : lire le contexte avant de décider quoi afficher.

Le principe fondateur : la modularité ou le bloc comme unité de sens

Cette lecture contextuelle ne fonctionne que si la page elle-même a cessé d'être un gabarit unique. On conçoit désormais selon une logique de modularité où chaque bloc porte un objectif, un contenu et un fonctionnel, et contribue à un objectif d'expérience mesurable. Une page devient donc une association de blocs dont la présence, l'ordre et le contenu s'ajustent au cas d'usage. Sur une fiche produit, la Buy Box, la Media Grid, le Storytelling, les Reasons to Buy, les avis clients, les caractéristiques techniques ou la FAQ ne forment plus une maquette d’ensemble mais une bibliothèque de blocs recomposables, chacun documenté dans le Design System.

Cette adaptation modulaire suit deux logiques : de la plus déterministe (des variantes de page prédéfinies, déclenchées par des triggers connus, selon des règles écrites à l'avance, c'est le cas de Google Meet) à la plus dynamique (la Generative UI à proprement parler). Dans ce cas-là, c'est un agent qui compose l'interface, librement… Ou presque car c'est en fait le design, et a fortiori le Design System, qui fixe les limites et les interdits, via un catalogue de composants, de tokens, de variantes et de micro-interactions associées aux états émotionnels et aux situations contextuelles. Ces interactions peuvent se jouer sur un ensemble de blocs, ou seulement sur une portion d'une interface conversationnelle.

—

À noter 💡

Avant tout investissement GenUI, la vraie question à se poser est simple : votre Design System est-il assez propre, nommé et documenté pour qu'une IA compose à partir de lui ou n'est-ce encore qu'une collection de composants ad hoc ? C'est ce prérequis, plus que la technologie elle-même, qui conditionne la réussite d'un projet GenUI.

—

Peu importe la logique, l'utilisateur reste maître, et si le régime génératif est indisponible ou peu fiable, l'interface doit pouvoir retomber proprement sur une version déterministe. En pratique, cela veut dire que chaque surface générative a besoin de sa propre porte de sortie : épingler un bloc, réordonner, tout réinitialiser. 

« Un modèle de langage, ça ne fait que du langage. Ce qui est nouveau avec la GenUI, ce n'est pas qu'il invente l'interface, c'est qu'il transforme le mot en objet graphique. »

Vincent Pillet, DGA, Useradgents

Le bancaire, la santé, sont deux univers où la GenUI est très pertinente, notamment car leurs apps vivent avec des dashboards d’accueil. Un dirigeant de TPE inquiet préférera y voir un bloc “Échéance à venir” en top priorité plutôt que “Conseil d'épargne personnalisé”, ce qui ne sera pas forcément le cas d’un nouveau retraité. Un diabétique appréciera retrouver en premier lieu son outil de suivi d’alimentation quand un coureur aguerri souhaitera un raccourci pour déclencher l’enregistrement de son prochain run. 

Zoom technique : dans les coulisses d'une interface qui s'auto-compose

Pour comprendre ce que la GenUI change concrètement et comment la mettre en pratique, nous avons développé une expérience générative sur un créneau qui s’y prête particulièrement pour sa haute intensité événementielle : le pari sportif. L’enjeu était d’avoir un parcours conversationnel in-app qui tient compte du direct et des actions menées pendant un match de football grâce aux commentaires. 

Un processus en cinq étapes

Techniquement, la génération suit un cheminement en cinq étapes : une interaction utilisateur ou un flux externe envoie du contexte au LLM (par exemple un tir cadré transformé en corner). Celui-ci analyse la requête et retourne un JSON structuré via un protocole qui spécifie quel composant afficher et avec quelles données, sans jamais générer de code exécutable. Ce JSON est ensuite interprété par un SDK spécialisé pour la GenUI (celui de Flutter ici), qui construit, ou adapte, l'interface en piochant le composant correspondant dans le catalogue prédéfini (comme un widget à choix multiple proposant les buteurs potentiels).

Il faut souligner que sur le marché de la standardisation, la concurrence fait rage, à deux niveaux. D'abord, sur comment un agent découvre et appelle un outil. C'est le terrain de MCP (Model Context Protocol), qu'Anthropic a introduit dès novembre 2024. Il y a ensuite l'affichage, comment l'agent restitue son résultat à l'écran. Ici, plusieurs gros acteurs de l'IA générative ont posé leur brique comme OpenAI avec l'Apps SDK, permettant à des applications tierces de s'afficher directement dans ChatGPT, ou Google avec le protocole A2UI (Agent-to-UI). A2UI est un format déclaratif en JSON où l'agent décrit une intention d'interface, que le client restitue avec ses propres composants natifs, Flutter, React ou SwiftUI selon la plateforme. C’est ce standard que nous avons utilisé pour notre test.

Embarqué ou Cloud : une architecture à deux vitesses

Reste la question de la latence entre le moment de collecte des entrants et l'affichage. Notre cas d'usage a été bâti sur une architecture hybride, une approche recommandée pour la GenUI : un premier niveau léger, avec un petit modèle embarqué sur l'appareil (SLM, à la façon d'un Gemini Nano ou des Apple Foundation Models) qui filtre le flux entrant pour repérer une opportunité ; un second niveau, plus robuste, confié à un modèle distant (ici Claude Sonnet), qui prend en charge la génération d'interface réelle. Avec cette division du travail, on ne sollicite le modèle le plus coûteux en tokens que lorsque le contexte le justifie réellement.

Fixer des gardes-fous avant la génération et l’affichage : le gage de sécurité

Dans ce même lapse de temps, il convient de fixer plusieurs étapes de validation dans lesquelles l'IA ne doit pas intervenir, des sortes de "gardes-fous" testables et traçables, intrinsèques au contexte d'usage (des règles du type “le joueur vient-il de recevoir un carton” ? “La cote est-elle toujours valide ?)”. La génération par le modèle ne peut se déclencher qu'après avoir rempli ces conditions. Même après génération, une ultime validation côté client est recommandée. 

En cas d'incohérence, le composant généré est simplement supprimé, silencieusement, sans présentation à l'utilisateur.

“La règle qui prime sur toutes les autres est que si le contexte ne correspond à aucun widget du catalogue, l’agent ne doit rien afficher ! GenUI ne veut pas dire improvisation ou contenu inventé. On préférera toujours le silence à une erreur d’interprétation du LLM”.

Grégoire Bonnier, Développeur Android & Flutter, Useradgents

L’observabilité : une phase de RUN clé dans le monitoring

Dans tout projet, l’observabilité se pense dès la phase de Discovery et se poursuit en production. C'est encore plus vrai pour une interface générative. Il faut désormais monitorer non seulement la performance des parcours, mais aussi l'usage des blocs générés pour les optimiser en continu. Parce que chaque bloc porte un objectif, la performance se mesure toujours au bon niveau : un KPI par parcours, par page et par bloc.

Le paysage des outils commence d'ailleurs à se structurer autour de deux couches d'analyse : côté orchestration, comprendre quels outils et protocoles sont invoqués par l'agent, à quelle fréquence, avec quelle latence, pour combien de tokens ; côté expérience, adapter les plateformes historiques à ces parcours devenus hybrides. Contentsquare a ainsi annoncé en mars 2026 de nouvelles capacités pour analyser des parcours entre web, mobile, assistants IA, applications ChatGPT et conversations de support, tout en donnant aux assistants un accès à ses données d'expérience via MCP.

“Ces deux couches, infos de monitoring de l’agent et mesure de l’expérience utilisateur, mobilisent des données et des métiers distincts. Les relier constitue donc un véritable enjeu d’architecture et de gouvernance.”

Fabienne Latxague, Head of UX, Useradgents

GenUI : faut-il vraiment s’y mettre ?

La question est légitime, comme une interrogation de fond, presque philosophique, qui s'impose au terme de ces réflexions. À force d'ultra-personnalisation, que devient la marque si chaque utilisateur vit une version différente d'un même service ? Son identité risque-t-elle de se diluer dans autant de variantes qu'il y a de contextes ?

Normalement, non. Et ce n'est pas un vœu pieux : c'est précisément le rôle des garde-fous décrits dans cet article. Un agent qui pioche dans un catalogue fermé, qui ne peut inventer ni bloc ni format, qui retombe sur une version déterministe au moindre doute, ne dilue pas une identité, il la décline. La charte graphique, la voix de marque, les règles d'accessibilité restent identiques d'une composition à l'autre. Et l'utilisateur, lui, doit pouvoir doser le degré de personnalisation qu'il accepte. L'IA propose, l'utilisateur décide, on ne le dira jamais assez.

Cela ne veut pas dire que la GenUI est prête à être industrialisée partout. Le concept n'en est qu'à ses balbutiements, et son succès à grande échelle reste incertain.

"Il faut faire une différence entre un test très pertinent mais mené dans un cadre très maîtrisé, et ce que pourrait être une solution de production plus large, où la sémantique des composants devient absolument critique."

Mathieu Pisonero, CTO, Useradgents

Le matériel, par exemple, ne suit pas encore. Les modèles embarqués (SLM) qui promettent une latence quasi nulle ne sont, à ce jour, disponibles que sur un nombre restreint de terminaux. Une bonne part de la promesse de la GenUI reste donc conditionnée à un cycle de renouvellement matériel qui ne dépend pas de nous.

Par ailleurs, la donnée et le token ont un coût et une adresse : la dépendance technique à des modèles parfois hébergés hors de nos frontières. Avant de nourrir un agent avec les données des utilisateurs (comportement, avis, position), il faut pouvoir répondre à trois questions simples : à qui appartient cette donnée, par où transite-t-elle, où est-elle hébergée ? Ces questions débordent du champ strict de la conception, mais on ne peut s'en affranchir sans compromettre la durabilité de l'expérience construite.

En conclusion

Alors, oui, vous pouvez dès à présent vous lancer dans la GenUI mais sans en attendre une révolution car elle ne remplacera jamais les logiques de base de la conception. Dans tous les cas, la prise en compte du contexte, l'approche modulaire et l’adoption d’un Design System sémantique vont permettre de mieux servir les intentions des utilisateurs, a minima pour composer les interfaces de façon déterministe et se préparer à la GenUI progressivement. Sans ces fondations, un agent n'a tout simplement rien dans quoi composer, et aucun garde-fou ne tient face à une charte mal documentée.

Mais alors comment documenter le Design System pour qu'il devienne lisible non seulement par des développeurs, mais aussi par les agents qui composeront demain nos interfaces ? Rendez-vous dans quelques semaines pour la suite de cet article ! 

Vous souhaitez refondre vos services digitaux pour faire face à l’ère agentique ? Téléchargez notre étude gratuite ou contactez directement nos équipes.