Concevoir une interface utilisateur générative plus sûre

La frontière de production de l’UI générative, c’est l’intention

Un modèle renvoie un bouton avec onclick= »shutdownInstances([‘i-123’, ‘i-456’]) ». Si une application en production injecte ce HTML généré et exécute le gestionnaire, le modèle peut influencer le comportement de l’application. Il fait plus que choisir la manière de présenter une tâche.

Une conception plus sûre attribue au modèle un rôle plus limité. Le modèle décrit l’intention de l’interface. L’application décide comment cette intention devient une UI et un comportement. Cette distinction est importante pour les produits pilotés par l’IA qui assemblent dynamiquement des graphiques, des tableaux, des formulaires, des confirmations ou des étapes de workflow.

Il s’agit d’un problème d’architecture à l’exécution. ChatGPT, GitHub Copilot, Cursor ou un autre assistant de codage IA peuvent générer des composants, des templates, des feuilles de style, des tests et des fonctionnalités pendant le développement. Les développeurs peuvent relire, modifier, tester, valider et maintenir cette production dans le cadre du cycle de vie logiciel habituel. Elle devient alors une partie de la base de code de l’application.

Une réponse de modèle en direct arrive comme donnée externe pendant une session utilisateur et peut changer à chaque requête. L’architecture de production a besoin d’une règle explicite sur le niveau d’autorité accordé à cette réponse.

La génération de code à l’exécution confère au modèle une autorité sur l’application

Prenons une enquête sur les coûts cloud. Un utilisateur demande pourquoi les dépenses ont augmenté et ce qu’il est possible de faire. Une réponse utile peut inclure une comparaison des coûts, une ventilation par service, des anomalies, les ressources concernées et des contrôles de remédiation. Du HTML et du JavaScript arbitraires peuvent exprimer tous ces éléments. Ils peuvent aussi permettre au modèle de prendre des décisions qui relèvent normalement de plusieurs couches de l’application.

Le balisage généré détermine la structure. Les styles générés peuvent définir la présentation en dehors des composants établis du produit. Les gestionnaires générés définissent le comportement et peuvent faire apparaître une opération comme disponible. L’état généré peut façonner ce que l’interface indique à l’utilisateur.

Un système de composants peut intégrer des comportements d’accessibilité, des règles d’interaction, des états de chargement et d’erreur, des conventions d’analytics, des choix de performance et des pratiques de test. Une UI produite en dehors de ce système n’hérite pas automatiquement de ces règles.

Le JavaScript généré porte une autorité plus grande, car l’application peut l’exécuter. Un gestionnaire généré par le modèle peut appeler une fonction interne, transmettre des paramètres inattendus ou exposer une opération que l’application place normalement derrière un workflow d’approbation.

L’autorisation montre pourquoi la génération d’interface et l’autorité opérationnelle doivent faire l’objet de décisions distinctes. La présence d’un bouton « Shut down » indique à l’utilisateur qu’une opération semble disponible. L’autorisation d’arrêter une ressource dépend de l’identité actuelle, du périmètre de la ressource, des règles métier et de l’autorisation côté serveur. Produire le contrôle n’établit aucune de ces conditions.

L’état crée un problème connexe. L’interface peut refléter le contexte conversationnel alors que l’application dispose de données plus récentes. Un modèle peut décrire une ressource comme inutilisée, puis cette ressource peut changer par la suite. L’application a besoin de l’état courant avant de présenter ou d’exécuter une opération fondée sur cette description.

Les composants, les actions, l’état, les approbations et l’autorisation portent tous des formes d’autorité applicative. Un modèle en direct a donc besoin d’un contrat qui lui permette d’influencer la composition tout en laissant à l’application le contrôle de ces capacités.

Générez plutôt une intention d’UI générative contrainte

Ce contrat peut prendre la forme d’une intention d’UI structurée : des données d’exécution qui identifient des blocs d’interface prédéfinis et fournissent des paramètres issus d’un vocabulaire autorisé.

Pour la demande sur les coûts cloud, la réponse pourrait demander les blocs cost-summary, service-cost-breakdown, anomaly-list et remediation-options. cost-summary pourrait accepter current-week ou current-month comme période, ainsi qu’une période précédente autorisée pour la comparaison. anomaly-list pourrait accepter un niveau de gravité medium ou high. remediation-options pourrait être limité à compute, storage ou network.

Le modèle exerce toujours son jugement. Il décide quels blocs pris en charge correspondent à la demande et choisit leurs paramètres pris en charge. L’application définit ce que signifie chaque bloc, son apparence, l’origine de ses données, le fonctionnement des erreurs et les interactions qu’il expose.

Une union discriminée TypeScript est une manière d’exprimer ce contrat dans le code. Une union discriminée est un type dont les membres portent un champ d’identification afin que le code puisse distinguer les cas autorisés. Un type UIBlock peut énumérer cost-summary, service-cost-breakdown, anomaly-list, remediation-options et confirmation, ainsi que les props que chacun accepte. Le compilateur peut alors vérifier la manière dont le code de l’application traite ces cas déclarés.

Une validation à l’exécution reste nécessaire, car la sortie du modèle arrive comme donnée externe. Les vérifications de TypeScript à la compilation ne valident pas une réponse entrante. L’application peut utiliser JSON Schema, Zod, Valibot ou un autre mécanisme de validation pour traiter la sortie entrante comme une donnée inconnue et la vérifier avant le rendu.

La validation peut rejeter des types de blocs inconnus, des props mal formées, des références d’action non prises en charge et des structures en dehors du contrat déclaré. Un schéma de production peut aussi contraindre les règles de mise en page, les limites de composants, l’imbrication autorisée, les références d’action et les versions du contrat. Le modèle peut proposer de nombreuses descriptions. L’application n’admet que celles qui satisfont à son contrat.

L’échec doit suivre un chemin défini. Si la validation échoue, l’application peut afficher une solution de repli sûre, demander à l’utilisateur de reformuler ou renvoyer une réponse textuelle classique. Une sortie mal formée doit rester en dehors des chemins de rendu et d’exécution.

La validation établit la forme de la demande. La question de conception suivante est de savoir ce que cette demande validée est autorisée à afficher et à faire.

Le rendu et l’exécution ont besoin de plans de contrôle distincts

Un registre de composants peut contrôler le rendu. Un registre de composants est une correspondance détenue par l’application entre des identifiants autorisés et des implémentations de composants de confiance. Un registre d’actions peut contrôler séparément les opérations détenues par l’application qu’une interface est autorisée à demander.

Par exemple, le registre de composants peut faire correspondre cost-summary à l’implémentation CostSummary de l’application et anomaly-list à AnomalyList. Lorsqu’une intention validée demande l’un de ces identifiants, le code applicatif ordinaire instancie le composant correspondant avec des props validées.

Les règles d’ingénierie restent à l’intérieur du composant. CostSummary peut obtenir les données de facturation via des API établies, utiliser les modèles de chargement et d’erreur du produit, mettre en œuvre les exigences d’accessibilité et enregistrer les analytics via l’instrumentation en place. La sortie du modèle choisit le composant enregistré. Elle ne redéfinit pas ce composant à chaque requête.

L’exécution a besoin d’un mécanisme distinct, car les interfaces dynamiques peuvent contenir des contrôles ayant des effets réels, comme arrêter une instance, redimensionner une base de données, ouvrir un ticket de support, approuver un déploiement, mettre à jour une politique ou modifier les paramètres du compte.

Supposons que le modèle propose une confirmation demandant s’il faut ouvrir une tâche de remédiation pour des instances de calcul inutilisées. Sa sortie structurée peut référencer actionId: « create-remediation-task ». Cet identifiant demande une opération enregistrée. L’application peut définir un contrat UIAction contenant des opérations telles que create-remediation-task et open-support-ticket. Un actionRegistry détenu par l’application peut faire correspondre ces identifiants à createRemediationTask et openSupportTicket.

C’est ainsi que le cas initial shutdownInstances évolue dans la conception contrainte. Le modèle ne fournit pas un gestionnaire onclick qui appelle directement shutdownInstances. Il peut demander un identifiant d’action autorisé, tandis que le code applicatif contrôle l’implémentation qui se trouve derrière.

Plusieurs vérifications doivent intervenir entre la demande et l’exécution. L’opération doit être enregistrée, l’utilisateur actuel doit avoir l’autorisation de la demander et les ressources référencées doivent relever du périmètre de cet utilisateur. L’opération doit aussi rester valide au regard de l’état courant de l’application.

Les opérations à plus haut risque peuvent exiger une confirmation, un audit, un routage d’approbation ou une vérification supplémentaire des autorisations côté serveur. Ce sont des règles applicatives. Le modèle peut sélectionner un chemin dans l’interface sans les définir.

La validation du schéma et l’autorisation répondent à des questions différentes. Un objet généré peut satisfaire à un schéma de confirmation tout en faisant référence à une action que l’utilisateur actuel ne peut pas exécuter. La validation établit que les données ont une forme acceptée. L’autorisation établit si un acteur donné peut produire un effet donné dans les conditions actuelles.

La même distinction s’applique aux paramètres. Un schéma peut établir que resourceIds est un tableau de chaînes. L’autorisation et la logique applicative doivent déterminer si ces ressources relèvent du périmètre autorisé de l’utilisateur et si l’opération demandée est valide au regard de leur état courant.

Pour les opérations qui modifient des ressources protégées, le serveur doit imposer la décision finale d’autorisation. Le front end peut utiliser les informations de permission pour décider quelles actions présenter. Le serveur applique les règles métier avant que l’opération protégée ne prenne effet.

Des implémentations de composants stables et des points d’entrée d’action nommés créent aussi des unités claires pour les tests. Les équipes peuvent tester le comportement des composants, les vérifications de permissions et d’état, ainsi que les implémentations d’action comme du code applicatif, même lorsque les compositions sélectionnées par le modèle varient d’une requête à l’autre.

Le modèle conserve un rôle utile. Il peut décider qu’un utilisateur a d’abord besoin d’une comparaison, puis d’une liste d’anomalies, puis d’un flux de remédiation. Il peut sélectionner des capacités enregistrées qui correspondent à une demande ouverte. L’application contrôle ce que ces sélections peuvent provoquer.

L’application doit aussi rester l’autorité sur l’état

Les contrôles sur les composants et les actions dépendent toujours d’un état fiable. Une session pilotée par l’IA peut contenir des synthèses, des inférences, des résultats d’outils antérieurs et des déclarations précédentes de l’utilisateur. Ces entrées peuvent aider le modèle à décider quoi afficher, mais elles peuvent devenir obsolètes.

Une instance de calcul décrite comme inutilisée peut ensuite changer d’état. Les données de facturation à l’origine d’une suggestion de remédiation peuvent être mises à jour. Un workflow en attente peut se terminer ou échouer après avoir été évoqué.

Les composants sélectionnés dynamiquement doivent obtenir un état vérifié via les chemins applicatifs ordinaires. CostSummary doit recevoir ou récupérer les informations de facturation via les mêmes mécanismes applicatifs de confiance que ceux utilisés ailleurs. Une action de remédiation doit mettre à jour l’état via le workflow normal. Un composant de confirmation doit obtenir les faits actuels dont il a besoin pour décider ce qu’il peut présenter.

Dans cette conception, l’UI générée devient une projection de l’état de l’application. Le modèle choisit une vue utile. Les systèmes applicatifs conservent l’enregistrement opérationnel.

Cette distinction devient plus importante à mesure que les applications agentiques évoluent sur plusieurs tours. Un utilisateur peut examiner un résultat, demander une opération, changer d’avis, se heurter à une exigence d’approbation, partir puis revenir plus tard. Le produit a besoin d’un compte rendu durable de ce qui a été mené à bien, de ce qui a échoué, de ce qui reste en attente et de ce qui requiert encore une approbation humaine.

L’état du workflow relève de systèmes conçus pour le persister, le mettre à jour, l’invalider et l’autoriser. Le contexte du modèle peut éclairer la composition de l’interface sans devenir le système qui enregistre si une opération a réellement eu lieu.

La contrainte préserve la raison d’utiliser un modèle

Une question de conception naturelle s’ensuit : si le rendu, l’exécution, l’autorisation et l’état restent sous le contrôle de l’application, quel rôle reste-t-il au modèle ?

Le scénario des coûts cloud donne la réponse. Des demandes différentes peuvent exiger des compositions différentes à partir des mêmes capacités de confiance. Une enquête peut appeler une synthèse et une comparaison. Une autre peut appeler des anomalies et des liens vers les ressources. Une troisième peut appeler des choix de remédiation, des confirmations et plusieurs étapes de workflow.

Une application classique peut encoder des parcours anticipés. Un modèle apporte un moyen d’interpréter une demande ouverte et de sélectionner une composition à partir des composants et des actions que le produit a choisi d’exposer.

La variabilité utile réside dans la sélection et la composition. L’implémentation des composants, l’exécution des actions, l’autorisation et l’état durable restent des responsabilités de l’application.

Points clés à retenir pour les dirigeants

• N’intégrez pas de code exécutable dans la sortie d’un modèle en direct : Traitez les réponses de modèle à l’exécution comme des données externes. Les modèles peuvent façonner l’intention de l’interface, tandis que le code applicatif relu conserve l’autorité sur le comportement.
• Générez plutôt une intention d’UI structurée : Définissez un contrat contraint et validé pour les composants et les paramètres qu’un modèle peut demander. Rejetez toute sortie mal formée ou non prise en charge avant qu’elle n’atteigne les chemins de rendu ou d’exécution.
• Séparez le rendu de l’exécution : Utilisez des registres de composants et d’actions détenus par l’application pour contrôler ce que les interfaces générées peuvent afficher et demander. Gardez l’autorisation, les vérifications de permissions, les confirmations et les opérations protégées hors du contrôle du modèle.
• Faites de l’état de l’application la source d’autorité : Utilisez des systèmes applicatifs de confiance pour l’état courant et durable plutôt que de vous appuyer sur le contexte conversationnel. Les composants et les actions doivent vérifier les conditions actuelles avant de présenter ou d’exécuter des opérations.
• Préservez la flexibilité grâce à une composition contrôlée : Utilisez les modèles pour interpréter des demandes ouvertes et composer dynamiquement des capacités de confiance. Cela préserve la valeur de l’UI générative sans donner aux modèles le contrôle de l’implémentation, de l’autorisation, de l’exécution ou de l’état.