Pourquoi le 'Prompt-to-UI' ne scale pas
Cet article analyse pourquoi l’approche “Prompt-to-UI” directe échoue à l’échelle en production. Il met en lumière les problèmes de déterminisme, de maintenance du contexte et de décalage d’intention, et propose les “structured outputs” et les Représentations Intermédiaires (IR) comme solutions.
Série “De l’Idée au Code : IA Fiable” Partie 1 : Pourquoi le ‘Prompt-to-UI’ ne scale pas Partie 2 : La Représentation Intermédiaire (IR) Partie 3 : Stack TypeScript : Zod & Vercel AI SDK Partie 4 : Validation multi-niveaux Partie 5 : Génération de code déterministe
La promesse vs. le terrain
Les démos de “prompt-to-UI” sont partout. Elles sont impressionnantes pour l’idéation, pour générer rapidement des prototypes. Je les utilise aussi pour ça.
Le problème, c’est quand on essaie de passer à l’échelle et de mettre ça en production dans une application métier. L’approche “prompt-direct” – où le LLM génère directement le code de l’interface – se heurte à des problèmes d’ingénierie fondamentaux.
À force de travailler sur ces sujets, je constate toujours les trois mêmes points de friction majeurs qui rendent cette approche non scalable et coûteuse à maintenir.
1. Le problème du déterminisme
C’est le point le plus critique pour n’importe quelle équipe de dev. Une application en production doit être déterministe. Un commit donné doit produire un résultat prévisible.
Les LLMs sont stochastiques par nature.
Quand je demande une modification (“augmente la marge du header de 4px”), je ne veux pas que le LLM “ré-imagine” toute la page. Je veux un diff atomique : margin-top: 8px devient margin-top: 12px.
Avec une approche “prompt-direct”, le LLM ré-infère le code à chaque fois. Il peut décider de changer la taille de la police en même temps, ou de casser la grille en dessous, parce que son modèle probabiliste l’y pousse. On perd tout contrôle sur le diff.
C’est l’opposition fondamentale entre nature stochastique (LLM) et besoin déterministe (ingénierie).
C’est inacceptable pour une code review sérieuse et ça rend la non-régression impossible.
2. Le coût de maintenance du contexte
Le développement est un processus itératif. Nos applications vivent et évoluent.
Un LLM n’a pas de “mémoire” de notre design system ou de nos contraintes métier. Il n’a que le contexte qu’on lui fournit à l’instant t. Au début, le prompt est simple.
Six mois plus tard, pour maintenir la cohérence, le prompt devient un monstre de 10 pages :
“Génère un formulaire, et n’oublie pas que les boutons primaires sont bleus (token #345ABC), que les coins sont arrondis à 4px, que les labels doivent être au-dessus des champs, et que tu dois respecter les rôles ARIA…”
On ne fait plus du développement. On fait de la gestion de contexte manuelle et épuisante. C’est une architecture fragile, source d’erreurs, et qui ne passe absolument pas à l’échelle.
3. Le décalage d’intention (Texte vs. Système)
Le troisième problème est conceptuel. Une UI est un système complexe : des grilles, des relations entre composants, des design tokens, une hiérarchie visuelle.
Un prompt textuel est linéaire. C’est une description de bas niveau.
On demande à un designer de décrire un plan d’architecte par SMS. Il va forcément manquer 90% du contexte. Il ne va pas décrire pourquoi la grille est basée sur 8px ou l’intention derrière un espacement. Le LLM va “placer des boîtes” là où il pense que c’est bien, mais il ne comprendra pas le système de design qui rend l’interface cohérente.
Ce n’est pas un problème de LLM, c’est un problème d’archi
Ces trois frictions ne seront pas magiquement corrigées par “GPT-5”. C’est un problème d’architecture.
Nous appliquons un outil stochastique (le LLM) à un problème d’ingénierie qui exige du déterminisme. L’échec du “prompt-direct” n’est pas l’échec de l’IA. C’est l’échec d’une architecture simpliste.
Pour fiabiliser l’IA en production, la solution viable que j’ai trouvée combine deux éléments :
- Les “structured outputs” (sorties structurées) : Contraindre le LLM à générer un format structuré 100% conforme, via le “constrained decoding”
- Une Représentation Intermédiaire (IR) : Un contrat formel entre l’intention (le “quoi”) et la génération de code (le “comment”)
Cette approche est au cœur de systèmes comme SpecifyUI, qui utilise une IR de type SPEC (Structured, Parameterized, Hierarchical) pour générer des interfaces production-ready.
C’est le plan directeur qui nous permet de piloter l’IA, au lieu de la subir.
Lire la suite : Partie 2 : Les 3 piliers d’une IR pour l’UI ️