L'IR : Le contrat qui fiabilise l'IA générative

Poursuivant l’analyse des limites du “Prompt-to-UI”, cet article introduit la Représentation Intermédiaire (IR) comme solution architecturale. Il explique comment une IR structurée, paramétrée et hiérarchique permet de fiabiliser l’IA générative en production, en séparant l’intention de l’utilisateur de la génération de code déterministe.

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

Reprise du problème

Dans l’article précédent, on a vu pourquoi le “prompt-to-UI” est une impasse en production. Il se heurte à des problèmes insolubles de déterminisme (le LLM est stochastique), de maintenance (le “prompt-babysitting” ne scale pas) et d’intention (le texte est linéaire, l’UI est systémique).

Le problème n’est pas le LLM lui-même, mais l’architecture simpliste.

Pour industrialiser l’IA, il faut revenir à nos fondamentaux d’ingénierie : la séparation des préoccupations.

L’IR : Le “plan directeur”

La solution est d’insérer une couche d’abstraction, un “contrat” formel entre l’intention de l’utilisateur et la génération du code final. C’est ce qu’on appelle une Représentation Intermédiaire (IR).

Dans le domaine de la génération d’interfaces, le modèle de référence est SPEC (Structured, Parameterized, Hierarchical Intermediate Representation), introduit par le système de recherche SpecifyUI.

SPEC est un format JSON léger qui possède trois attributs essentiels :

1. Structuré : Encode les directives de conception et les hiérarchies d’éléments dans un format rigoureux
2. Paramétré : Combine des champs numériques déterministes (ex: #FFFFFF pour les couleurs, 8px pour les espacements) avec des étiquettes sémantiques
3. Hiérarchique : Permet la composition de composants à plusieurs niveaux (layout → régions → composants → sous-composants)

Cette IR résout une dualité fondamentale : elle garantit le déterminisme computationnel (pour les machines) tout en préservant l’interprétabilité humaine (pour les designers).

C’est un “plan directeur” (un blueprint) que l’on peut inspecter, versionner, et modifier.

Le pivot architectural : Séparer le “Quoi” du “Comment”

L’adoption d’une IR change radicalement le workflow. On ne demande plus au LLM de générer directement du code (le “comment”). On lui demande de générer le plan (le “quoi”).

1. Le LLM (Créatif) génère le “Quoi” : L’utilisateur (ou un autre LLM) exprime une intention. Le LLM principal traduit cette intention en une Représentation Intermédiaire (IR) structurée.
2. Le Code (Déterministe) génère le “Comment” : Un générateur de code (un script, un moteur de template) prend cette IR propre et validée et la transforme en code final (React, HTML/CSS, etc.) de manière 100% déterministe.

On passe d’une boîte noire (Prompt -> Code) à une pipeline transparente (Prompt -> IR -> Validation -> Code).

Les 3 bénéfices concrets sur le terrain

Ce pattern architectural résout directement les trois problèmes du “prompt-direct”.

1. On récupère le déterminisme et la fiabilité Le LLM est contraint de produire un plan structuré de type SPEC, pas du code aléatoire. On peut valider ce plan (cette IR) à plusieurs niveaux avant que la moindre ligne de code ne soit générée :

• Validation syntaxique : Le JSON est-il conforme au schéma ?
• Validation métier : Les couleurs, espacements, contraintes sont-ils respectés ?
• Validation sémantique : Le plan est-il cohérent avec l’intention ?

Le stochastique est maîtrisé. La nature hiérarchique et paramétrée de SPEC garantit que les modifications sont prévisibles.

2. On gagne en agilité et en maintenance Une IR hiérarchisée (comme SPEC) rend chaque élément de l’interface adressable et modifiable par son chemin.

Si je veux changer la marge du header, je ne refais pas un prompt. Je fais une opération ciblée sur l’IR : <opération: update, chemin: header.spacing, valeur: 12px>. Le diff est atomique, propre, et le générateur déterministe se charge du reste.

Les itérations deviennent rapides et prévisibles. SpecifyUI a mesuré des itérations 10x plus rapides qu’avec la génération directe par prompt.

3. L’intention est explicite et auditable L’IR devient un artefact central de notre système. On peut la stocker, la versionner dans Git, la comparer, l’auditer.

L’intention du design n’est plus noyée dans un historique de prompts ; elle est externalisée dans un format structuré lisible par la machine et par l’humain.

Les designers de SpecifyUI ont rapporté un contrôle créatif significativement supérieur avec cette approche, car l’IR rend l’IA transparente plutôt qu’opaque.

La suite (La Stack)

Ce n’est pas théorique. Ce pattern est au cœur du système SpecifyUI, qui utilise une IR de type SPEC pour générer des interfaces utilisateur production-ready.

Les résultats mesurés :

• Contrôle créatif significativement supérieur vs génération directe
• Designs jugés plus cohérents et corrects par des experts UI
• Itérations 10x plus rapides grâce aux modifications ciblées sur l’IR

Mais une question demeure : comment forcer un LLM (un outil probabiliste) à générer à coup sûr un plan structuré (une IR de type SPEC) qui soit 100% conforme à notre schéma ?

C’est là qu’intervient l’outillage moderne : le “Constrained Decoding” et des bibliothèques comme Zod avec le Vercel AI SDK (en TypeScript).

Lire la série : ⬅️ Partie 1 : Pourquoi le ‘Prompt-to-UI’ ne scale pas | Partie 3 : Stack TypeScript (Zod & Vercel AI SDK) ️