On nous répète depuis dix-huit mois que concevoir des interfaces classiques, c’est produire de la dette. Que l’IA générera bientôt chaque page web, chaque interface à la volée, pour chaque utilisateur, et que les interfaces traditionnelles vont disparaître.
C’est une thèse commode, et elle est contestable pour une raison assez terre à terre : générer une interface reste, pour le moment, extrêmement gourmand en ressources. L’UI traditionnelle, elle, a un coût marginal proche de zéro.
La vraie question n’est donc pas « quelle interface est l’avenir », mais « quelle interface pour quelle fonctionnalité, à quel coût de maintenance et de service et, surtout, pour quelle valeur perçue ». Cet article propose une grille d’arbitrage en décryptant trois types d’interfaces à l’ère de l’IA, neuf critères à prendre en compte pour les évaluer, et notre humble avis sur les cas d’usages qui pourraient mériter de générer des interfaces personnalisées en fonction d’un contexte.
Gen UI : de quoi parle-t-on ?
La nouvelle ère des d’interfaces homme-machine
Depuis 2025, le remplacement de l’UI traditionnelle par la GenUI s’affirme comme une véritable tendance. Les utilisateurs pourront interagir avec des services numériques au travers d’interfaces générées en fonction de leurs requêtes. Concevoir des pages et des parcours précodés reviendrait alors à créer de la dette produit. Ce discours a pourtant un angle mort : il ne prend pas en compte le coût de service de la Gen UI. Le contre-argument le plus net vient de Tobi Jo LeBron (juin 2026) : la GenUI, c’est de l’UI traditionnelle sur un tapis roulant très cher. Au regard du coût de génération des interfaces en 2026 nous nous posons la questions suivantes : la Gen UI est elle économiquement viable ? Et c’est bien la question centrale car aujourd’hui, plus que jamais, le ROI des services numériques et au coeur des enjeux de conception. Quant à la question voisine, celle qui consiste à savoir si les interfaces graphiques vont disparaitre, nous l’avons traitée dans notre analyse de l’avenir des interfaces graphiques ; le présent article se concentre donc sur la viabilité économique et sur la valeur d’usage de la Gen UI.
Design-time et runtime
En mars 2024, le Nielsen Norman Group distingue deux notions liées aux interfaces et à l’IA. D’un côté, le design assisté par l’IA (design-time) : l’IA aide le designer à produire des prototypes plus rapidement. De l’autre, l’interface générative (runtime) : l’IA compose l’interface avant que l’utilisateur final ne s’en serve. Or 90 % des « retours d’expérience GenUI » qui circulent parlent en réalité de design-time. Ce sont des designers qui témoignent du temps gagné en générant des interfaces dans le cadre d’un projet de conception UX/UI. Confondre les deux, ce serait comme comparer un gain de productivité à un coût d’infrastructure. Dans le cas du design-time, on enregistre des économies de coût de conception. Dans le cas du runtime il faut prendre en compte le coût des infrastructures pour générer des milliers d’interfaces en fonction du trafic et de l’usage de vos plateformes numériques.
Un troisième terme mérite d’être séparé : l’interface adaptative, qui bascule entre des écrans pré-construits selon des règles déterministes écrites par un designer. Ce n’est pas de la génération, c’est de la conditionnalité, un mécanisme voisin de ce que nous décrivions à propos des interfaces invisibles, NoUI et NUI.
Les trois types de GenUI
On peut dire que la GenUI se décline en trois niveaux de maîtrise :
La GenUI contrôlée (par appel d’outil) : un outil de génération d’interface génère une mise en page sur la base de données structurées et des instructions fournies par le concepteur.
La GenUI déclarative : l’agent renvoie un schéma de mise en page (le protocole A2UI poussé par Google Cloud en est l’exemple type) que le front interprète pour piocher dans un catalogue fermé de composants.
La GenUI ouverte : l’agent génère du code libre, rendu en bac à sable. Le modèle décide de tout.
Ce que la GenUI génère vraiment en 2026
Le décalage entre la démo et les environnements de production
Les vitrines du moment relèvent du design-time ou de l’expérience isolée. Vercel v0 produit un composant React que le développeur copie dans son projet : rien n’est généré à l’exécution. Les artefacts de Claude sont rendus dans un panneau dédié, pas fondus dans un produit tiers. Aucune de ces démonstrations, aussi impressionnantes soient-elles, n’est une interface générée au runtime pour un utilisateur final.
Le travail le plus sérieux sur le sujet vient de Google Research, dont la publication Generative UI (2026) mesure que les expériences interactives générées sont largement préférées au texte brut dans les tests humains. Mais la méthode repose sur des outils optimisés, des instructions système longuement travaillées et un post-processeur chargé de rattraper les défauts récurrents : le modèle seul n’est pas fiable pour composer du visuel. Et la clause qui accompagne le résultat mérite d’être citée telle quelle : la préférence est mesurée « quand on ignore le temps de génération ». En d’autres termes, cette étude a mesuré la préférence des participants en terme de résultat et de rendu et non en terme d’experience d’usage incluant le temps de génération.
Les middlewares : le catalogue fermé comme modèle dominant
Tambo, CopilotKit et les SDK équivalents suivent tous le même schéma : le développeur enregistre des composants pré-codés avec des schémas de validation, l’agent choisit dans ce catalogue fermé et alimente le composant en données.
Dans un envorionnement de production, la GenUI n’est pas un générateur d’interface, c’est un routeur de composants. Elle ne supprime donc pas le design system, elle en dépend absolument.
Ce que ça implique pour une équipe design
Le catalogue de composants devient l’interface de programmation de l’IA. Plus le design system est atomique, documenté et contraint, plus la GenUI est exploitable. Une entreprise ou une équipe sans design system mature pourra difficilement obtenir des résultats satisfaisant en GenUI de runtime. Elle peut faire des démos. Structurer un design system exploitable par un agent devient ainsi le prérequis concret de tout projet GenUI, bien avant le choix du modèle.
Le travail d’UI ne disparaît pas pour autant, il se déplace en amont : définir les composants, les états, les contraintes et les règles d’assemblage. Nous avons détaillé ailleurs ce que l’IA change au métier d’UX designer ; la GenUI en est une illustration de plus.
Ce que coûte une interface qui se génère
Le coût d’affichage des interface n’est plus marginal
Afficher un tableau de bord traditionnel pour le millième utilisateur coûte une requête en base de données : un coût marginal quasi nul. En GenUI, chaque rendu appelle le modèle et consomme des tokens, et chaque interaction ultérieure (filtrer, trier, cliquer) doit repasser dans la fenêtre de contexte pour que le modèle comprenne le nouvel état et pour le moment les possibilités d’optimisation sont minces.
La latence
Générer une interface complexe via un protocole déclaratif dépasse couramment les 40 secondes, et Google Research reconnaît que la génération de l’interface peut « parfois prendre une minute ou plus ». Si on rapproche ces temps des seuils établis par le Nielsen Norman Group : 0,1 seconde pour la sensation de manipulation directe, 1 seconde pour maintenir le fil de la pensée, 10 secondes avant le décrochage de l’attention : un premier rendu en dizaines de secondes serait de fait hors échelle. Même si le résultat produit un effet « wahou », il aura fallu attendre de longues secondes pour l’obtenir. Nous rappelons que le web traditionnel à fait du temps de réponse la clé d’une bonne experience utilisateur. L’aspect hyper personnalisé de la Gen UI viendrait-il effacer 30 ans de progrès dans la fluidification de nos expériences numériques ?
L’économie du token
Chez Uber, le CTO Praveen Neppalli Naga a reconnu en 2026 que l’entreprise avait consommé son budget IA annuel en quatre mois, certains ingénieurs dépensant 500 à 2 000 dollars de tokens par mois ; il annonce la fin du « tokenmaxxing » et une réorientation vers des équipes restreintes devant prouver une valeur métier sur des cycles courts. Le mouvement dépasse Uber : Duolingo a rétropédalé en 2026 sur sa posture « AI-first » d’avril 2025 après une réaction violente de ses utilisateurs et de ses équipes, tandis qu’Alphabet levait 84,75 milliards de dollars pour financer son infrastructure IA, signe que l’inférence (le calcul par l’IA) restera durablement une ressource premium.
Les projets IA peinent à créer de la valeur par manque de cadrage et de gouverance
L’étude du MIT The GenAI Divide: State of AI in Business 2025 (environ 300 déploiements analysés, plus de 150 entretiens) conclut que 95 % des pilotes GenAI ne produisent aucun retour positif mesurable. Ce chiffre circule partout comme preuve que « l’IA ne marche pas », et c’est un contresens : l’étude documente un échec d’intégration et de gouvernance des données, pas une défaillance des modèles. Les 5 % qui réussissent partagent un profil précis : périmètre métier étroit, intégration profonde dans le flux de travail existant.
Notre position ne change pas : nous refusons aussi bien le « ROI de 9 900 % » que le « 95 % d’échec » brandi hors contexte. Les deux sont des chiffres-slogans.
La gen UI présente un véritable enjeu d’utilisabilité
Mémoire spatiale et loi de Jakob
La loi de Jakob rappelle que les utilisateurs passent l’essentiel de leur temps sur d’autres produits que le vôtre, et qu’ils en importent les conventions. La stabilité de l’emplacement des éléments dans une interface graphique représente un capital d’usage pour l’utilisateur. En B2B, l’enjeu est encore plus net : la mémoire spatiale est ce qui permet à un utilisateur expert de naviguer sans lire l’écran. Une interface qui se recompose entre deux sessions annule cet acquis et ramène l’expert au niveau du débutant. La prévisibilité n’est pas l’ennemie de la personnalisation : si le contenu gagne a être personnalisé en fonction du contexte de l’utilisateur, les éléments qui permettent d’agir sur l’interface doivent, quant à eux, rester parfaitement prédictibles.
Charge cognitive
La théorie de la charge cognitive de Sweller rappelle que la mémoire de travail est très limitée. Re-décoder une interface métamorphosée impose une charge extrinsèque massive, sans aucun bénéfice pour la tâche : l’utilisateur ne peut plus suivre une piste d’information (le scent of information cher à la recherche UX), il doit reconstruire la carte à chaque visite. Ces mécanismes relèvent de l’ergonomie cognitive et s’appliquent à tous types d’interfaces quelles soient générées ou précodées.
Reste un contre-exemple : pour une requête unique, ponctuelle, sans réutilisation attendue, il n’y a pas de mémoire spatiale à préserver. C’est précisément là que la GenUI se défend le mieux.
Le contrôle halluciné
Le vrai risque de la GenUI n’est pas le texte faux, c’est le contrôle faux : un bouton « Valider le paiement » généré, parfaitement crédible, connecté à rien. L’utilisateur clique, rien ne se passe, et la confiance s’effondre d’un coup.
Le bon cadre est celui de la confiance calibrée, formalisée par Google PAIR et le HAX Toolkit de Microsoft : concevoir l’échec honnêtement, communiquer l’incertitude, dire à l’utilisateur ce que le système fera ensuite. Nous avons détaillé ces frameworks dans les règles de conception d’un produit IA ; la GenUI les rend plus nécessaires, pas moins.
Testabilité et support
Comment faire de l’A/B testing sur une interface qui n’est jamais exactement la même ? Les cartes de chaleur perdent leur sens dès que le bouton se déplace au gré de l’inférence, et le support client hérite du problème : reproduire le bug d’un utilisateur suppose de reproduire l’interface qu’il a vue (en risquant de consommer de nouveau des tokens), et la capture d’écran redevient la seule preuve.
Accessibilité et Gen UI
Une contrainte légale
L’European Accessibility Act s’applique depuis le 28 juin 2025, avec un alignement sur WCAG 2.1 et 2.2 niveau AA ; en France, le RGAA porte la même exigence. L’accessibilité numérique a donc quitté le registre de la bonne intention pour celui du risque juridique et commercial : marchés publics, grands comptes et appels d’offres l’exigent contractuellement.
Pourquoi la GenUI ouverte et sans contrôle ne passera pas
Un modèle probabiliste qui écrit du HTML libre ne garantit ni la sémantique attendue par les lecteurs d’écran, ni un ordre de tabulation cohérent, ni les rôles ARIA, ni les contrastes. Surtout, une conformité ne peut pas être « probablement » atteinte : elle s’audite sur un rendu donné, et un rendu qui change à chaque appel n’est pas auditable. C’est ce critère, plus encore que le coût, qui disqualifie la GenUI ouverte pour tout produit soumis à l’EAA.
La seule voie viable est la GenUI contrôlée : des composants pré-codés déjà audités, un schéma strict qui injecte les attributs ARIA, un post-traitement de validation. Là encore, opter pour la GenUI sans savoir comment le WCAG et le RGAA vont se positionner nous paraît prématuré. Il est préférable d’attendre que l’accessibilité numérique statue sur les impacts de cette technologie.
La grille d’arbitrage : un portefeuille de trois interfaces
Neuf critères, trois colonnes
Critère | UI traditionnelle | UI traditionnelle + IA | GenUI contrôlée |
|---|---|---|---|
Coût de construction | Élevé (une fois) | Élevé + intégration modèle | Élevé + catalogue + orchestration |
Coût de service au runtime | Quasi nul | Faible (inférence ciblée) | Élevé (inférence à chaque rendu) |
Latence | < 100 ms | < 100 ms hors suggestion | Dizaines de secondes possibles |
Fiabilité | Déterministe | Déterministe (données à valider) | Probabiliste |
Exactitude visuelle | Totale | Totale | Dépend du catalogue |
Flexibilité / personnalisation | Prévue en amont | Contenu personnalisé | Maximale dans le catalogue |
Testabilité | Classique (A/B, heatmaps) | Classique | Quasi impossible à standardiser |
Conformité accessibilité | Auditable | Auditable | Auditable si composants audités |
Maintenabilité | Connue | Connue + dérive du modèle | Dépend du couple catalogue / modèle |
Les verdicts, type par type
L’UI traditionnelle reste la solution la plus viable partout où le trafic est important et la fiabilité priment : navigation principale, paramètres, processus métier critiques, actions de routine. Rappel utile : traditionnel ne veut pas dire statique. Slack ou Spotify sont des interfaces très dynamiques et profondément personnalisées, sans un token d’inférence dépensé au rendu. Et en environnement professionnel, où l’expertise des utilisateurs se construit sur la stabilité, l’UX des applications métier plaide massivement pour cette colonne.
L’UI traditionnelle augmentée d’IA est le point d’équilibre : assistance à la rédaction, pré-remplissage intelligent, suggestion de données, aide au support. La mise en page reste déterministe, seules les données injectées viennent du modèle. On garde la confiance d’une interface connue et la conformité acquise, tout en captant la valeur de l’automatisation. C’est notre recommandation par défaut pour la grande majorité des produits B2B, et nous l’assumons.
La GenUI contrôlée : exploration de données analytiques, requêtes uniques et imprévisibles, cas où aucune interface pré-dessinée ne peut couvrir la demande. Sa condition de viabilité est que l’utilisateur ait consciemment accepté de payer ce rendu, en argent ou en attente. C’est le cas dans un assistant conversationnel ; ce ne l’est pas dans un tunnel de commande.
Le contre-exemple : Netflix
Netflix résout la personnalisation à très grande échelle sans générer d’interface : enrichissement des métadonnées par l’IA, moteur de vignettes produisant une dizaine de variantes pré-dessinées, et un modèle qui choisit laquelle afficher à qui. C’est de la sélection pilotée par le serveur, pas de la génération. La leçon vaut pour tous les ateliers produit : avant d’acheter de la génération, vérifiez que le problème n’est pas résoluble par de la sélection.
En conclusion
Ne raisonnez pas en remplacement mais en portefeuille. La question à poser en atelier n’est jamais « faut-il faire de la GenUI », c’est « quelles fonctionnalités justifient un coût de rendu récurrent ». C’est un arbitrage de conception produit à part entière, du ressort d’une démarche de product design outillée pour chiffrer.
Faites l’exercice chiffré avant la maquette : coût de construction, coût de service par utilisateur actif, disposition réelle à payer. Le marché B2B accepte de payer pour l’automatisation d’une tâche, beaucoup moins pour la génération visuelle de l’interface.
Traitez l’accessibilité comme un critère d’architecture, pas comme une phase de fin de projet. Si le rendu n’est pas auditable, le produit n’est pas conforme.
Investissez en priorité dans le design system : c’est lui qui rend la GenUI possible, et c’est lui qui reste utile si la GenUI ne tient pas ses promesses. Le seul investissement à valeur certaine dans les deux scénarios, et le bon point de départ pour cadrer une stratégie UX qui intègre l’IA sans lui signer un chèque en blanc.
La GenUI est un outil de plus dans la boîte du designer, pas la boîte elle-même.
