Ce que la génération d'interface fait très bien
Produire un écran qui fonctionne, à partir d'une description, en quelques minutes : c'est réel et cela change la façon de démarrer un projet. Il faut le reconnaître avant d'en poser les limites.
Le gain est particulièrement net sur trois choses. La mise en page, qui est répétitive et bien couverte par les conventions. Le câblage des états simples, formulaires, listes, filtres. Et la production de plusieurs variantes d'un même écran, ce qui coûtait cher et se fait maintenant en série.
Ce dernier point change réellement la conception : on peut montrer trois propositions au métier au lieu d'en décrire une.
Les quatre chantiers qui restent
L'accessibilité, les états d'erreur, les tests et l'intégration ne sont pas produits, et ce sont eux qui font la différence entre un écran et un logiciel. Aucun n'est visible sur la démonstration.
L'accessibilité arrive en premier parce qu'elle est la plus systématiquement absente : navigation au clavier, contrastes, libellés des champs, gestion du focus. Sur un service public ou un logiciel destiné à des salariés, ce n'est pas optionnel.
Les états d'erreur ensuite. Une interface générée traite le cas passant. Elle ne traite ni le service indisponible, ni la donnée manquante, ni la saisie invalide, ni la double soumission.
Les tests, troisième chantier, sont paradoxalement là où l'assistant aide le plus, mais il faut le lui demander.
L'intégration enfin : authentification, droits, journalisation, et le branchement au système existant. C'est le plus long, et c'est exactement le sujet de brancher un modèle sur un progiciel sans API.
Ce qui coûte plus cher ajouté après qu'écrit d'emblée
- L'accessibilité, qui touche la structure du balisage et se rattrape mal sans reprendre les composants.
- La gestion du focus et du clavier, qui dépend de l'architecture des états.
- Les états d'erreur, qui remontent souvent jusqu'à la forme des appels au service.
- La journalisation, qu'il faut poser tôt sous peine de ne rien pouvoir diagnostiquer. Voir l'observabilité des systèmes IA.
L'usage où cette génération est indiscutable
Le prototype destiné à être jeté est le cas où la génération d'interface apporte le plus, sans aucune contrepartie. Il faut simplement l'assumer comme tel.
Un prototype sert à trancher une question de conception avec le métier : est-ce que ce parcours tient, est-ce que cet écran dit ce qu'il faut. Il n'a pas besoin d'accessibilité, ni de tests, ni d'intégration.
Le danger n'est pas le prototype, c'est sa promotion silencieuse en production. Le schéma est connu : la démonstration convainc, quelqu'un demande quand ce sera en ligne, et le prototype devient la base du produit sans que la décision ait été prise.
La parade tient en une phrase posée au moment de la démonstration : ceci est un prototype, la mise en production demande tel travail supplémentaire, chiffré. C'est le premier des verrous décrits dans sortir du prototype.
Comment j'utilise ces outils en mission
Pour explorer vite en cadrage, et pour produire les écrans internes qui n'ont pas d'utilisateur externe. Deux usages, et je ne les mélange pas.
En cadrage, générer trois versions d'un écran fait avancer une discussion bien mieux qu'un document. Le métier réagit à ce qu'il voit, et les vraies contraintes sortent en une réunion au lieu de trois.
Pour les écrans internes d'exploitation, tableaux de bord, consoles de vérification, interfaces de supervision, le rapport bénéfice-effort est excellent : peu d'utilisateurs, tous internes, exigences d'accessibilité réduites, et un besoin réel qui n'aurait jamais obtenu de budget autrement.
C'est d'ailleurs par là que je commence souvent, parce qu'un tableau de bord d'exploitation est ce qui manque le plus aux systèmes que je reprends.
La phrase à dire avant toute démonstration
« Cet écran tourne, il n'est pas accessible, il ne gère pas les erreurs, il n'est pas testé et il n'est branché à rien. » Elle prend cinq secondes et elle évite qu'un prototype devienne un produit par malentendu.
Ce que ça change au métier de concepteur
Le travail se déplace de la production d'écrans vers la définition de ce qu'ils doivent faire dans les cas difficiles. C'est un déplacement vers le haut, pas une disparition.
Décrire un écran qui marche devient rapide. Décider ce qu'il affiche quand le service est indisponible, quand la donnée est incomplète, quand l'utilisateur n'a pas les droits, reste entièrement à faire, et c'est là que se joue la qualité perçue.
La compétence qui prend de la valeur est donc celle du cas limite. C'est la même évolution que celle observée sur les systèmes documentaires, où l'écriture du prompt compte moins que la définition du périmètre de refus, comme développé dans le refus de répondre est une fonctionnalité.
Questions fréquentes
Que ne produit pas une interface générée ?
L'accessibilité, les états d'erreur, les tests et l'intégration au système existant. Aucun des quatre n'est visible sur l'écran qui tourne en démonstration.
Peut-on rattraper l'accessibilité après coup ?
Difficilement : elle touche la structure du balisage et la gestion du focus, donc l'architecture des états. C'est le chantier qui coûte le plus cher ajouté après.
Quel usage est indiscutable ?
Le prototype destiné à être jeté, et les écrans internes d'exploitation : peu d'utilisateurs, tous internes, exigences réduites, et un besoin réel qui n'aurait pas obtenu de budget.
Quel est le risque principal ?
La promotion silencieuse d'un prototype en production. La démonstration convainc, quelqu'un demande la date de mise en ligne, et la décision n'a jamais été prise.