AI-native & Agentic UX · 2 novembre 2026

La boîte de discussion n'est pas une interface, c'est un report de conception

Un champ vide avec un curseur qui clignote transfère à l'utilisateur tout le travail que l'équipe n'a pas fait. Pourquoi ce format s'impose, et par quoi le remplacer.

Une zone de saisie vide, un curseur qui clignote, et parfois la phrase « posez-moi n'importe quelle question ».

C'est devenu le réflexe majoritaire pour intégrer de l'IA dans un produit, et c'est presque toujours le mauvais point de départ. Non pas parce que la conversation serait un mauvais mode d'interaction, mais parce que ce champ vide n'est pas une décision de conception. C'est l'absence de décision, rendue visible.

Ce que le champ vide demande à l'utilisateur

Trois efforts, dans la première seconde, avant toute valeur reçue.

Deviner le périmètre. Qu'est-ce que ce système sait faire ? Rien ne le dit. L'utilisateur doit formuler une hypothèse et la tester, en sachant que l'échec lui coûtera du temps et un peu de confiance.

Formuler correctement. La qualité du résultat dépend de la façon dont la demande est écrite. On transfère donc à l'utilisateur une compétence que l'équipe a mis des semaines à acquérir, et on la lui demande sans l'avoir prévenu.

Évaluer seul le résultat. Rien n'indique si la réponse est fiable, d'où elle vient, ni ce qu'il faut en faire. L'utilisateur doit vérifier, ce qui annule une partie du gain promis.

Chacun de ces trois efforts correspond à un travail de conception qui n'a pas été fait. Le champ vide ne les supprime pas, il les déplace.

Pourquoi ce format s'impose quand même

Il faut être juste : il y a de bonnes raisons de s'y laisser aller.

C'est le format qu'on a tous en tête. Les assistants généralistes ont fixé la référence. Quand on pense « IA », on voit une conversation.

Il ne ferme aucune porte. Tant qu'on ne sait pas ce que les gens vont en faire, un champ libre laisse tout ouvert. C'est rassurant pour une équipe qui lance.

Il est rapide à construire. Une zone de texte, un appel au modèle, une réponse. Pas d'arbitrage sur les cas d'usage, pas de travail sur les états, pas de décision difficile.

Cette troisième raison est la vraie. Le champ vide est l'option qui permet de livrer sans avoir tranché.

Là où il est pertinent

Il existe deux situations où c'est le bon choix, et il faut les reconnaître.

Quand l'ouverture est le produit. Un assistant généraliste ne peut pas proposer trois boutons : son intérêt est précisément de couvrir ce qu'on n'avait pas prévu.

Quand on cherche encore. Un champ libre en phase d'exploration est un excellent instrument de recherche : il révèle ce que les gens essaient de faire. À condition de lire ce qu'ils tapent, et de s'en servir pour concevoir la version suivante.

Dans le second cas, le champ vide est une étape. Le problème commence quand il devient la version finale par défaut.

Ce qui fonctionne mieux dans un produit métier

Des actions là où le besoin apparaît. Plutôt qu'un assistant dans un coin, une action proposée sur l'objet concerné, au moment où l'utilisateur le regarde. Le contexte fait la moitié du travail de formulation.

Des intentions prédéfinies. Trois ou quatre entrées nommées plutôt qu'un champ ouvert. Ce n'est pas une limitation, c'est une réponse à la question « qu'est-ce que ça sait faire ». Et un champ libre peut rester disponible en complément, pour ceux qui savent déjà quoi demander.

Une sortie structurée plutôt qu'un paragraphe. Si le résultat utile est une liste, un tableau ou une modification, il doit arriver sous cette forme, directement manipulable. Un texte à recopier à la main transfère encore une fois l'effort.

Une conversation qui commence après, pas avant. Le format le plus efficace que je vois aujourd'hui inverse l'ordre : le système propose un résultat, et la conversation sert à l'ajuster. L'utilisateur n'a plus à formuler une demande dans le vide, il réagit à quelque chose.

Le test à appliquer

Devant votre interface, posez-vous une seule question : si je retire la zone de saisie, est-ce que la fonctionnalité existe encore ?

Si la réponse est non, vous avez construit une porte d'entrée, pas une fonctionnalité. Tout ce qui compte, les cas d'usage, les résultats attendus, la manière de les contrôler, reste à concevoir.

C'est le même raisonnement que celui qui gouverne la première rencontre avec une fonctionnalité d'IA : la valeur se joue dans ce que le produit propose, pas dans ce qu'il permet de demander.

Ce qu'il faut retenir

La conversation est un mode d'interaction légitime. Le champ vide posé dans un coin d'un produit métier n'en est pas un : c'est le moment où l'équipe a décidé de ne pas décider.

La bonne question n'est jamais « où mettre l'assistant ». C'est « quelles trois choses mes utilisateurs vont vouloir faire, et comment je les leur propose sans qu'ils aient à les formuler ».

Vous avez un assistant dans votre produit et peu d'usage après la découverte ? C'est le symptôme le plus courant de ce choix par défaut. Parlons-en.