Pourquoi s'embêter avec des interfaces quand on a des LLM

De la ligne de commande à l'interface — et retour

Au début de l'ère informatique, on apprenait aux gens à parler le langage de la machine : interrupteurs, cartes perforées, commandes dans un terminal. Une erreur sur un seul caractère, et rien ne se passait. Quand les ordinateurs sont devenus un produit de masse, cette approche s'est effondrée. On ne pouvait pas demander à chaque utilisateur de mémoriser des dizaines de commandes et leurs paramètres. Sont apparus les fenêtres, les menus, les icônes, la souris. On pouvait glisser un fichier vers la corbeille plutôt que de taper une commande de suppression. Une couche s'est formée entre l'humain et le programme : l'interface.

Aujourd'hui, la logique s'inverse. Les LLM permettent à l'humain de reparler à l'ordinateur dans son propre langage, mais c'est désormais la machine qui comprend le langage naturel, et non l'humain qui apprend la syntaxe du système. Prenez l'analyse d'entreprise : au lieu de chercher une section, choisir un rapport, démêler des filtres et des conditions, vous dites simplement : « Montre-moi les clients qui achetaient régulièrement avant, mais qui ont arrêté ces trois derniers mois.

» Le système décompose lui-même la requête, la met en correspondance avec les données disponibles, construit une requête structurée et livre le résultat. Même logique pour les billets d'avion : au lieu de choisir des villes, des dates, des filtres et des réglages de vol retour, on dit simplement : « Je veux trouver des billets pour Pékin la semaine prochaine, sans escale, de préférence sous 200 euros, retour dimanche soir.

Formuler la question et recevoir la réponse — deux tâches distinctes

Quand on parle d'interface LLM, on imagine un chat : texte → réponse-texte. En réalité, ce sont deux paramètres indépendants. La requête peut être prononcée à voix haute — des phrases longues avec plusieurs conditions se disent plus vite qu'elles ne s'écrivent sur un téléphone. La phrase « montre-moi les projets de mon équipe où le délai de livraison a augmenté le mois dernier sans que le périmètre ait changé » peut se dire presque d'une traite.

Mais le fait d'avoir posé la question à voix haute n'implique pas du tout que la réponse doive être vocale. Si vous demandez comment ont évolué les dépenses par catégorie ces six derniers mois, vous entendrez à l'oral un résumé bref : « Sur six mois, vous avez dépensé un million de roubles, principalement en loyer, infrastructure et prestataires. » Sur l'écran apparaîtront en même temps un diagramme et un tableau détaillé par mois.

Cela fonctionne aussi avec une requête textuelle : vous écrivez quelque chose, et vous obtenez une carte, un graphique, des fiches produits, un formulaire de confirmation ou un tableau interactif. Choisir le mode de saisie et choisir le mode de restitution du résultat sont deux tâches distinctes.

Aujourd'hui, le mode de saisie et le mode de restitution sont liés à un seul appareil : la question posée au téléphone obtient sa réponse sur le téléphone. C'est une particularité des produits existants, pas une limite technique. Les appareils pourraient être reliés via une session utilisateur commune : une enceinte connectée comme dispositif de saisie vocale et de réponse audio courte, le téléphone affichant une interface interactive, l'ordinateur portable comme poste de travail principal, l'écran de la salle de réunion comme grand écran partagé.

Le choix de l'appareil devient alors une partie du routage de la réponse. Les données financières ne devraient pas s'afficher automatiquement sur l'écran de la salle de réunion, et un graphique à 20 indicateurs est illisible à travers une enceinte.

Quatre façons de mettre cela en œuvre

N°1. Generative UI contrôlée

Le produit prévoit un ensemble de composants : ExpenseChart, ComparisonTable, HotelCards, Map, Confirmation. Le modèle ne dessine pas l'écran, il choisit le composant adapté, récupère les données et renvoie un JSON structuré :

``` { "component": "ExpenseBreakdown", "period": "6m", "data": [...], "groupBy": "category" } ```

Le designer et le développeur contrôlent entièrement l'apparence, le comportement, l'accessibilité et les états d'erreur. Le modèle se contente de choisir la représentation et de lui transmettre les données. Cette approche est implémentée dans CopilotKit.

N°2. Description déclarative à partir de blocs de construction

Le modèle reçoit non pas des écrans tout faits, mais des éléments de base : conteneur, texte, métrique, tableau, carte, graphique, bouton, formulaire. Il renvoie une description déclarative de l'interface, que le client assemble à partir de son propre kit d'UI, en préservant le système de design partout : web, application mobile, autres clients. Une même réponse peut être rendue dans différents environnements. Cette approche est développée par A2UI de Google.

N°3. MCP Apps avec interface prête à l'emploi

L'outil renvoie une interface interactive que le client affiche dans une iframe sandboxée. On peut utiliser des technologies web classiques : HTML, CSS, JavaScript, créer des formulaires, des graphiques, des cartes, des scénarios à plusieurs étapes. Cela est pris en charge par différents clients MCP et par des applications à l'intérieur de ChatGPT. Ici, c'est le fournisseur de l'outil qui contrôle davantage l'apparence, et non le client.

N°4. Génération complète HTML/CSS/JavaScript

Le modèle génère le code entièrement à la volée. Cela offre une liberté maximale, mais pose des questions de qualité, de sécurité, de stabilité et de cohérence visuelle. Pour un prototype ou une tâche rare, cela peut être pratique, mais faire de ce mode le socle d'un système d'entreprise critique est risqué.

Comment le développement va changer

Avec l'approche classique apparaissent rapidement : page d'accueil, catalogue de rapports, pages de détail, constructeur de filtres, vues enregistrées, écran de comparaison de périodes, export, paramètres. Chaque nouveau scénario augmente le nombre d'états du produit qu'il faut concevoir, implémenter, tester et adapter à différentes tailles d'écran.

Avec les LLM, cette logique change. Au lieu de prévoir toutes les combinaisons possibles de composants sur des écrans séparés, le développeur crée un ensemble d'éléments de base et des règles qui régissent leur interaction. Le modèle assemble lui-même la combinaison nécessaire pour la requête spécifique de l'utilisateur. Il y a moins d'écrans, plus de logique dans le système, et il est plus agréable de travailler avec.