Depuis trois ans, la même scène se répète dans les produits métier : une petite bulle apparaît dans un coin de l'écran, on clique, un textarea s'ouvre. Hi, how can I help you today ? Le produit est devenu « AI ready ». Sauf qu'il ne l'est pas vraiment, et que personne ne l'utilise réellement au-delà des premiers essais.
Le problème ne vient pas des LLM. Il vient du fait que personne n'a encore trouvé la bonne forme d'interface conversationnelle pour une application métier. Et tant qu'on n'aura pas posé clairement les contraintes, on continuera à recycler le pattern le plus paresseux du design d'IA : le champ texte vide.
Un formulaire bien conçu gagne contre un chat sur presque tous les critères qui comptent dans une application métier. D'abord, il montre les options possibles, ce qui permet à l'utilisateur de découvrir naturellement ce qu'il peut faire et d'enrichir sa connaissance au fur et à mesure de son utilisation. Ensuite, il contraint l'entrée : les champs attendent un certain format de donnée et on a tout de suite un retour sur ce qui est valide ou non, ce qui est rassurant pour l'utilisateur. Enfin, son utilisation est rapide, car cliquer est plus rapide que de taper au clavier. En gros, il décharge la cognition : l'utilisateur reconnaît, il ne formule pas.
Un champ texte unique, vide, même couplé à un LLM, est exactement l'inverse. Cela fait l'effet d'une page blanche, il n'y a pas d'affordance, pas de garantie sur la formulation acceptée, une lenteur de saisie, et un coût mental élevé pour traduire une intention en phrase. Ce qui est peut-être viable pour le grand public en mode exploration ne l'est pas pour un professionnel qui répète les mêmes opérations encore et encore et pour qui la cognition doit être ailleurs.
Pourtant l'envie d'intégrer un LLM est légitime, parce qu'il apporte quelque chose qu'aucune interface classique ne sait faire à coût raisonnable.
Ce que fait un LLM, et qu'on ne refera pas en code sans y consacrer des mois entiers, c'est de transformer l'expression humaine floue, en données strictes. C'est en fait potentiellement un bon adaptateur de coercition entre la manière dont les gens pensent leurs intentions et la manière dont les API les acceptent.
Concrètement, un LLM absorbe par nature :
Les expressions temporelles floues : « lundi », « dans deux semaines », « fin du mois », « le 14 ou le 15 si c'est complet ». Plus besoin de regex multilingues ou de bibliothèques de parsing de date tels que Duckling.
La résolution d'entités contextuelles : « le client qu'on a vu hier », « la commande de Mme Dupont », « comme la dernière fois ». L'autocomplétion classique demande qu'on tape une chaîne reconnaissable, alors qu'un LLM peut interroger l'historique et choisir.
La composition implicite : « annule jeudi et déplace à la semaine prochaine » correspond à deux appels d'API distincts que le modèle orchestre sans qu'on ait à coder le workflow.
La tolérance à la formulation : fautes de frappe, synonymes, formulations régionales, jargon métier = plus de mappings à maintenir.
Le multilingue : l'utilisateur écrit dans sa langue, le backend reçoit du structuré.
La désambiguïsation interactive : si l'intention est ambiguë, le LLM peut rendre la main avec une question ciblée, là où une UI classique doit anticiper en amont tous les cas.
C'est vraiment cette capacité là qui est la plus impressionnante selon moi, et qui n'est pas encore bien exploitée. Et la question n'est pas de savoir s'il faut s'en servir, mais sous quelle forme on l'expose à l'utilisateur pour qu'il puisse en tirer profit ?
Toute interface utilisateur fait un compromis sur trois axes :
L'expressivité : l'étendue de ce que l'utilisateur peut exprimer dans une seule action.
La discoverabilité : la facilité à découvrir ce qu'on peut faire sans documentation.
La rapidité : l'effort réel pour formuler la demande.
Un chat seul maximise l'expressivité, mais sacrifie la discoverabilité, et perd en rapidité dès qu'il faut taper. La voix peut pallier à cela mais introduit d'autres problèmes (encore peu utilisé dans le monde du travail, confidentialité...). Le formulaire classique fait l'inverse : forte discoverabilité, rapidité correcte, mais expressivité limitée à ce qui a été prévu.
Dans la section suivante nous allons voir quelques patterns émergents, qui négocient ces trois axes différemment.
1. La coercition de champ, invisible. Le formulaire reste là, visuellement classique, mais chaque champ devient tolérant : le champ date accepte « lundi », le champ quantité accepte « douze », le champ destinataire accepte « le client de la semaine dernière ». L'interface ne change pas de forme, seule la tolérance d'entrée change. Cette approche est conservatrice, mais c'est probablement le pattern qui passe le mieux à l'échelle parce qu'il ne demande aucun apprentissage de la part de l'utilisateur. Le seul bémol c'est que l'on perd la composition, et qu'on n'exploite pas pleinement l'orchestration.
2. Le canal d'accélération. Le formulaire reste visible, mais un champ unique permet à l'utilisateur pressé de tout dicter d'un coup. Le LLM remplit ensuite les champs, et l'utilisateur peut ajuster à la souris. C'est le pattern adopté par Linear, Raycast et Fantastical. La hiérarchie est respectée : clavier pour les power users, souris pour les autres. Le formulaire reste un mécanisme de confiance car on voit ce qui a été compris avant de valider.
3. Le pré-rempli + correction. L'app fait une hypothèse à partir du contexte et l'utilisateur corrige ce qui ne va pas, plutôt que de construire depuis zéro. Le travail cognitif passe de la composition à la vérification. Cette approche qui est notamment très discuté dans le monde du développement, me semble aller dans le mauvais sens. Il y a une perte de sens de la maîtrise de la part du professionnel et la sensation de lassitude est forte selon moi.
4. Les chips de désambiguïsation. L'utilisateur exprime une intention courte par la voix, un bouton ou une requête tapée brièvement, et le LLM répond non par une réponse mais par une série de petits choix structurés à confirmer. Par exemple, « Réservation vendredi 4 personnes » produirait trois chips cliquables 19h / 20h / 21h, puis intérieur / terrasse. La conversation devient une chaîne de validations tactiles. C'est sans doute le pattern le moins exploré et le plus prometteur pour le mobile.
5. L'UI générative. Le LLM ne remplit pas un formulaire, il en génère un sur mesure pour chaque intention. Vercel v0, les artefacts Claude, l'écosystème generative UI explorent cette piste. Cette approche, radicale, est encore mal adaptée au métier car elle manque de déterminisme, d'accessibilité, et pose des problèmes pour les tests d'interface, l'audit etc. Mais c'est probablement là que la trajectoire à long terme se joue.
Chacun de ces patterns fait un compromis sur le triangle expressivité / discoverabilité / rapidité et aucun ne s'impose pour le moment. Mais le "chat-everything" reste selon moi dans la plupart des cas un mauvais choix et relève plutôt du non-design qui procure peut-être un effet "wahou" pour les investisseurs, mais s'avère coûteux à maintenir et frustrant à utiliser.
Le travail intéressant des deux prochaines années sera donc de tester ces patterns (et de nouveaux) sur de vrais flux métier, d'observer ce que les utilisateurs adoptent réellement, et d'anticiper que les futures interfaces métier ne ressembleront probablement pas à celles d'aujourd'hui (et certainement pas à un chat).
Quoi qu'il en soit, le bon réflexe consiste à découpler dès maintenant la couche d'exposition du modèle de la forme d'interface choisie. Des protocoles comme MCP servent précisément à cela : les API typés qui sont exposées au LLM restent les mêmes, qu'elles soient déclenchées depuis un champ tolérant, une série de chips ou une UI générée. C'est ce qui permet d'itérer côté design sans tout recâbler à chaque essai.