Ouvrez n'importe quelle app bancaire et comptez les écrans que vous n'utilisez jamais. Le partage d'addition, l'onglet investissement, le carrousel de récompenses, le truc qui vous propose un crédit. Quelqu'un a livré tout ça — et pour chaque utilisateur pris individuellement, l'essentiel n'est que du mobilier.
La generative UI est l'argument selon lequel ce problème est soluble — que l'écran devrait être assemblé pour la personne qui l'ouvre, plutôt que dessiné une fois pour tout le monde.
Ce que ce n'est pas
Le terme sert à désigner deux choses complètement différentes, et la confusion gâche beaucoup de réunions.
La première est l'outillage de design : décrire un écran, obtenir une maquette ou du code. C'est du design génératif. Ça se passe avant la livraison, un humain relit le résultat, et l'app elle-même reste aussi statique qu'avant. Réellement utile — pas le sujet de cet article.
La generative UI signifie que l'interface est assemblée à l'exécution. L'app décide, pendant que l'utilisateur la tient en main, quels composants montrer, dans quel ordre, avec quel contenu — selon qui il est et ce qu'il semble vouloir faire. Aucun designer n'a validé cet agencement précis, parce que cet agencement précis n'existait pas il y a trois secondes.
Cette distinction est toute la raison pour laquelle le sujet est controversé.
Pourquoi c'est soudain plausible
L'UI pilotée par le serveur est ancienne. Airbnb, Spotify et la plupart des grandes apps e-commerce la livrent depuis des années : le serveur envoie une liste de types de composants avec des données, le client les rend, et la mise en page peut changer sans passage par l'App Store. Cela a résolu le problème du déploiement — on pouvait réordonner un écran d'accueil sans attendre une semaine de revue.
Ce que ça n'a jamais résolu, c'est le problème de la décision. Quelqu'un devait encore écrire les règles. Montrer la bannière promo au segment B en décembre. Remonter le bouton de recommande pour les clients à plus de trois commandes. Chaque règle était écrite à la main — et la combinatoire a fini par vaincre tout le monde.
Les modèles de langage changent cette moitié-là. Avec une description des composants existants, de ce que l'utilisateur a fait et de ce qu'il semble vouloir, un modèle peut composer une mise en page sans que personne n'écrive la règle. La moitié rendu — un client qui dessine n'importe quelle liste de composants reçue — est un problème résolu que votre équipe possède peut-être déjà.
Fig. — Le modèle choisit dans un registre qu'il ne peut pas dépasser. Rien n'est inventé au rendu.
Où ça gagne vraiment sa place
Commencez par la recherche et la découverte, parce que le gain y est évident. Une requête « veste imperméable à moins de 200 francs » retourne aujourd'hui une grille — parce que l'écran est une grille. Une réponse générée pourrait retourner un tableau comparatif des trois meilleures correspondances, une note sur les tailles, et une puce de filtre pour la contrainte exprimée. Les mêmes données, agencées pour la question réellement posée.
Les parcours de support sont le deuxième cas. La plupart de l'aide intégrée est un arbre de décision dessiné en 2021. Une interface qui assemble les étapes précises du problème précis — avec les détails de commande de l'utilisateur déjà remplis — supprime la navigation entièrement.
L'onboarding est le troisième, et le plus mesurable. Un nouvel utilisateur arrivé par une pub sur le suivi des notes de frais ne devrait pas voir la même visite en six cartes que celui venu pour la facturation. Adapter la première session à l'intention qui les a amenés, c'est là que la rétention bouge — et la rétention, c'est là qu'est l'argent.
Ce que ces cas partagent : un espace d'intentions réellement large, et un contenu qui existe déjà sous forme structurée. La generative UI ne crée pas de capacité nouvelle. Elle réagence ce que vous avez.
Les problèmes que les démos sautent
Voici la liste honnête — et la raison pour laquelle l'adoption est plus lente que l'enthousiasme.
Le test devient probabiliste. Votre processus de QA suppose un ensemble fini d'écrans. Quand l'écran se compose à l'exécution, on ne peut plus les énumérer. Les équipes finissent par tester le registre de composants exhaustivement et la composition statistiquement — un vrai changement dans la façon de penser la justesse, et qui met certaines organisations profondément mal à l'aise.
L'accessibilité casse facilement. Un lecteur d'écran dépend d'un ordre de parcours sensé et d'étiquettes parlantes. Si un modèle réordonne les composants, l'ordre de lecture change avec. Chaque composant doit embarquer son contrat d'accessibilité plutôt que de le recevoir écran par écran — bonne pratique de toute façon, désormais non négociable.
La latence ne pardonne pas. Les utilisateurs tolèrent un spinner sur un chargement réseau. Ils n'en tolèrent pas un avant que l'interface existe. Les déploiements sérieux rendent immédiatement une mise en page par défaut rapide et laissent la version générée la remplacer ou l'affiner — ce qui veut dire construire les deux chemins.
La cohérence s'érode en silence. Votre design system existe pour que l'app ressemble à un seul produit. Un moteur de composition qui optimise chaque écran localement produira volontiers un écran cohérent qui ne ressemble en rien au précédent. Les contraintes doivent être encodées — ce composant jamais au-dessus de celui-là, jamais plus de deux appels à l'action — et cette couche de contraintes est l'essentiel du travail d'ingénierie.
Le débogage change de forme. Quand un utilisateur signale que quelque chose avait l'air faux, il faut reconstituer ce qu'il a vu. Ce qui signifie journaliser la décision de composition, ses entrées et le résultat rendu pour chaque session que vous pourriez devoir expliquer. Les questions de stockage et de vie privée suivent immédiatement.
Qui décide de ce qui est bien
Sous le problème technique, il y a un problème d'organisation — et il émerge environ trois semaines après toute tentative sérieuse.
Les designers ont l'habitude de posséder des écrans. Dans un système génératif, ils possèdent des composants, des contraintes et la définition d'une bonne composition — un métier réellement différent, plus proche de l'écriture d'une grammaire que du dessin d'une maquette. Certains trouvent ça libérateur. D'autres font remarquer, à juste titre, qu'ils ne peuvent plus regarder le produit et savoir ce que voient les utilisateurs — ce qui était jusqu'ici la base entière de leur métier.
Les product managers heurtent le même mur par un autre côté. Valider voulait dire relire un fichier Figma. Maintenant, cela veut dire relire un espace de sorties possibles — ce qui ne se fait pas en regardant. Les équipes qui s'en sortent construisent une vue galerie : un outil qui rend une centaine de compositions échantillonnées depuis de vrais contextes utilisateurs, pour qu'un humain repère l'embarrassant avant la mise en ligne.
Construisez cet outil tôt. Toutes les équipes qui l'ont sauté l'ont construit plus tard — après qu'est sorti quelque chose que personne n'avait jamais vu.
Ce que ça coûte vraiment
Le registre de composants est le vrai projet. Chaque élément que le modèle peut placer doit être réellement autonome — aucune hypothèse sur ce qui le surplombe, aucune mise en page qui casse à une largeur imprévue, des métadonnées d'accessibilité complètes, un comportement sensé quand des données manquent. La plupart des bibliothèques existantes ne sont pas cela. Ce sont des composants qui fonctionnent aux endroits où ils sont actuellement utilisés.
Budgétez aussi le système de contraintes, car c'est là que vit la qualité. Et budgétez l'inférence : un appel de modèle à chaque composition d'écran est un coût par session qui grandit avec l'engagement — une forme inhabituelle et un peu inconfortable pour l'économie d'une app mobile.
Les équipes qui réussissent génèrent des mises en page pour une poignée de surfaces à forte valeur — pas pour toute l'app. Les écrans de réglages n'en ont pas besoin. Le paiement non plus : la prévisibilité y vaut plus que la pertinence.
Commencer sans parier l'app
Choisissez une surface où l'intention varie réellement — les résultats de recherche, le fil d'accueil, le parcours d'aide. Construisez proprement le registre de composants de cette surface, avec l'accessibilité et l'indépendance de mise en page prises au sérieux. Livrez derrière un drapeau, avec un repli statique qui se rend quand le modèle est lent, indisponible ou invalide.
Puis mesurez ce qui compte — et ce n'est pas l'engagement. L'engagement monte dès qu'on réarrange n'importe quoi. Mesurez l'accomplissement de la tâche — la personne a-t-elle trouvé la veste, résolu le problème, terminé la configuration — et comparez honnêtement à la mise en page statique.
Un mot sur le repli, car il décide si tout cela survit à la production. La mise en page statique rendue en premier n'est pas une expérience dégradée — c'est l'expérience de chaque utilisateur dont l'appel de composition expire, de chaque utilisateur en mauvaise connexion, et de chaque utilisateur pendant l'inévitable panne du modèle. Si le repli est mauvais, vous avez construit une app occasionnellement mauvaise pour des raisons que les utilisateurs ne peuvent pas comprendre. Concevez la version statique comme si elle était la seule, puis laissez la version générée l'améliorer.
La plupart des apps n'en ont pas encore besoin. Celles qui en ont besoin sont celles où les utilisateurs arrivent avec des objectifs radicalement différents et naviguent aujourd'hui devant l'essentiel de ce que vous avez construit pour atteindre la seule chose qu'ils venaient chercher. Si cela décrit votre app, le problème du mobilier vous coûte déjà quelque chose. Il n'apparaît simplement dans aucun tableau de bord — personne ne se plaint d'un écran qu'il a fait défiler.
