UX d'un produit IA : 5 patterns qui multiplient le feedback par 5

L'UX est le levier d'optimisation IA le plus sous-estimé¶

Quand un produit IA fonctionne mal, les équipes techniques se ruent sur le pipeline : nouveau modèle d'embeddings, reranker plus malin, prompt retravaillé, chunking modifié. Tout ça est utile, mais ça passe à côté du levier qui a le meilleur rapport effort / impact : l'interface utilisateur.

L'UX ne fait pas que présenter la réponse. Bien conçue, elle devient un capteur qui collecte de la donnée d'amélioration en continu. C'est exactement le type de donnée qui manque à 80 % des projets que j'audite, et sans laquelle aucune optimisation pipeline ne fonctionne vraiment.

Dans cet article, je détaille 5 patterns UX que j'applique systématiquement sur mes projets, avec les chiffres derrière chacun.

Pour le pipeline technique d'un RAG (chunking, retrieval, génération), voir le guide RAG complet.

Pourquoi l'UX est devenue un levier d'optimisation IA¶

Un produit IA, contrairement à un produit logiciel classique, apprend de son usage, à condition d'avoir mis en place les capteurs pour ça. C'est le rôle de l'UX dans un produit IA mature.

Trois raisons à ça :

1. La vérité terrain est rare et chère. Construire un dataset d'évaluation propre prend des jours, parfois des semaines. Les utilisateurs vous donnent gratuitement des milliers de signaux par mois, s'ils sont sollicités intelligemment.
2. Les hard negatives sont impossibles à inventer. Les exemples "presque pertinents mais pas tout à fait" sont indispensables pour entraîner un reranker. Les générer synthétiquement donne des résultats moyens. Les récolter via l'UX, c'est de l'or.
3. Le feedback explicite est massivement sous-collecté. Un bouton "👍 / 👎" récolte typiquement 1 à 3 % de réponses. C'est 30 fois moins que ce qu'on peut obtenir avec les bons patterns.

Les 5 patterns qui suivent visent à transformer cette UX-capteur en réalité.

Pattern 1 : La question de feedback fermée et spécifique¶

La règle : plus une question de feedback est précise et fermée, plus le taux de réponse explose.

L'exemple le plus parlant vient de Zapier, partagé par Jason Liu : ils utilisaient la formulation classique "How did we do?". En remplaçant simplement par "Did we answer your question today?", le volume de feedback a été multiplié par 5.

Le mécanisme est cognitif. Une question vague demande à l'utilisateur de synthétiser son expérience ("comment ça s'est passé ?"). Une question précise demande juste un rappel ("est-ce qu'on a répondu ?"). Le coût mental n'est pas le même.

Les formulations qui fonctionnent¶

Ce qu'il faut éviter¶

• Les échelles 1-10. Trop coûteuses cognitivement. Préférez binaire (oui/non) ou ternaire (oui / partiellement / non).
• Le timing trop précoce. Demander juste après l'affichage de la réponse, avant que l'utilisateur ait eu le temps de lire, donne du bruit. Attendre 15-30 secondes ou déclencher au clic suivant.
• L'omniprésence. Demander le feedback après chaque réponse fatigue. Échantillonnez : 1 réponse sur 5 ou sur 10 selon le volume.

Pattern 2 : Les citations cliquables comme source de hard negatives¶

La règle : afficher les sources de la réponse, et permettre à l'utilisateur de marquer celles qui ne sont pas pertinentes.

Concrètement : sous chaque réponse, vous affichez les 3-5 chunks utilisés pour générer la réponse, avec un bouton "Pas pertinent" ou un picto "×" pour chacun. L'utilisateur qui repère un document non pertinent dans la liste va instinctivement cliquer.

Pourquoi c'est de l'or pour le pipeline¶

Chaque clic "pas pertinent" sur une source vous donne un hard negative gratuit : un document qui ressemblait suffisamment pour être récupéré, mais que l'utilisateur a explicitement rejeté. C'est exactement ce dont vous avez besoin pour :

• Fine-tuner un reranker (Cohere Rerank, BGE Reranker, modèle maison). Le reranker apprend la frontière fine entre "ressemble" et "répond vraiment".
• Améliorer le filtrage par métadonnées (cf. techniques d'optimisation RAG).
• Détecter les chunks toxiques qui polluent systématiquement le retrieval (chunk obsolète, doublon mal nettoyé, page de garde indexée par erreur).

À chiffrer pour le client¶

Sur un projet où on a déployé ce pattern, 18 % des réponses avaient au moins un clic "pas pertinent" sur une source. En 6 semaines, ça représentait ~2 400 hard negatives utilisables. C'est un dataset qu'on aurait mis 3 mois à annoter à la main.

Bonnes pratiques d'implémentation¶

• Affichez toujours les sources, même quand l'utilisateur ne demande pas. La citation est désormais une attente standard.
• Le picto "×" doit être visible mais discret. Trop voyant, vous biaisez le signal (les gens cliquent par jeu).
• Stockez le contexte complet à chaque clic : requête, réponse, chunks récupérés, score de chaque chunk, position du chunk rejeté.

Pattern 3 : La matrice Requêtes × Succès pour prioriser¶

La règle : classez vos requêtes utilisateur sur deux axes (volume et taux de succès) pour savoir où investir.

C'est moins un pattern UX qu'un pattern d'analyse, mais il dépend entièrement de la donnée que les patterns 1 et 2 produisent. Sans feedback explicite, cette matrice n'existe pas.

La matrice à 4 cases¶

                  Taux de succès FAIBLE        Taux de succès ÉLEVÉ
                ┌──────────────────────────┬──────────────────────────┐
Volume          │  PRIORITÉ ABSOLUE        │  CACHEZ / OPTIMISEZ      │
ÉLEVÉ           │  ces requêtes vous       │  ces requêtes sont vos   │
                │  font perdre des users   │  candidates au cache     │
                ├──────────────────────────┼──────────────────────────┤
Volume          │  IGNOREZ POUR L'INSTANT  │  METTEZ EN AVANT         │
FAIBLE          │  pas assez de volume     │  via suggestions en UI   │
                │  pour mériter du dev     │  (pattern 4)             │
                └──────────────────────────┴──────────────────────────┘

En pratique¶

Sur un projet support B2B, l'analyse de la matrice a fait apparaître :

• Quadrant haut-gauche (volume élevé, succès faible) : les questions sur les conditions générales (3 % de réussite, 22 % du volume). On a immédiatement ajouté un parser dédié aux CGV. Gain mesuré : +28 points sur ces requêtes en 2 semaines.
• Quadrant bas-droite (volume faible, succès élevé) : les questions sur l'API (94 % de réussite, 1,8 % du volume). On les a poussées en suggestions d'accueil (cf. pattern 4). Volume sur cette catégorie ×3 en un mois.

C'est ce type d'arbitrage qu'on ne peut pas faire sans les patterns 1 et 2 derrière. Et c'est ce qui transforme un produit IA en machine à amélioration continue, exactement comme l'analyse d'erreur transforme un RAG fragile en RAG fiable.

Pattern 4 : Les suggestions de requêtes intelligentes¶

La règle : au lieu de laisser l'utilisateur deviner ce que votre IA sait bien faire, montrez-lui.

Une interface IA est typiquement un champ texte vide. C'est terrible pour deux raisons : l'utilisateur ne sait pas quoi demander, et il a tendance à poser des questions sur lesquelles vous performez mal (parce qu'il imagine que vous savez tout).

Ce qu'il faut suggérer¶

Les requêtes qui vivent dans le quadrant bas-droite de la matrice (volume faible, succès élevé). Vous avez identifié des usages où votre IA performe à 90 %+ ? Mettez-les en avant. C'est gagnant trois fois :

1. L'utilisateur découvre un usage qu'il n'aurait pas imaginé.
2. Le taux de satisfaction global monte (plus de questions tombent dans la zone de confort de votre système).
3. Vous récoltez du feedback positif qui équilibre les hard negatives du pattern 2.

Formats qui marchent¶

• Chips cliquables en haut de la conversation ("Comparer 2 contrats", "Résumer un appel d'offres", "Lister les pénalités d'une clause").
• Suggestions dynamiques basées sur les documents récemment uploadés ("Vous venez de charger un PDF de 80 pages. Voulez-vous : un résumé / l'extraction des clauses sensibles / la liste des dates clés ?").
• Recommandations contextuelles après une réponse ("Vous pouvez aussi me demander…").

À éviter¶

Suggérer des requêtes sur lesquelles vous performez mal. Ça paraît évident, mais c'est l'erreur classique : on liste tout ce que le produit peut faire en théorie, et on guide les utilisateurs vers les zones les plus fragiles du système.

Pattern 5 : Afficher l'incertitude pour responsabiliser l'utilisateur¶

La règle : quand votre système n'est pas sûr de sa réponse, dites-le. Ne masquez pas l'incertitude derrière une réponse confiante.

Un LLM répond toujours avec la même tonalité, qu'il soit certain à 99 % ou en pleine hallucination à 20 %. C'est l'un des défauts UX majeurs des produits IA actuels. La solution n'est pas de retirer la réponse, c'est de communiquer la confiance.

Comment mesurer la confiance¶

Plusieurs signaux disponibles côté pipeline :

• Score moyen des chunks récupérés (similarité, rerank score). Si les meilleurs chunks sont à 0.42 alors que votre baseline est à 0.75, alerte.
• Nombre de chunks au-dessus du seuil de pertinence. Zéro chunk pertinent = pas de réponse fiable.
• Cohérence entre chunks : si les chunks récupérés se contredisent, la réponse va probablement halluciner pour réconcilier.
• Auto-évaluation LLM : demander au modèle d'évaluer sa propre confiance après réponse (à utiliser avec parcimonie, cf. évaluer un RAG en production pour les limites du LLM-as-a-judge).

Comment l'afficher¶

Le gain caché¶

Au-delà de la transparence, ce pattern génère un signal d'amélioration. Toutes les requêtes qui tombent dans le bandeau "confiance faible" sont des candidates idéales pour le quadrant haut-gauche de la matrice (pattern 3). Vous savez tout de suite ce qu'il faut ajouter à votre base de connaissances ou retravailler dans le retrieval.

Le changement de mentalité : l'UX comme capteur¶

Le fil rouge des 5 patterns, c'est de traiter l'UX comme un capteur de données, pas seulement comme une couche de présentation. Chaque interaction utilisateur est une occasion :

• de collecter un signal (positif, négatif, ou hard negative),
• de prioriser un chantier (matrice requêtes × succès),
• d'éduquer l'utilisateur (suggestions, affichage de l'incertitude).

C'est exactement la philosophie qui sépare un produit IA qui s'améliore en continu d'un produit IA figé après le déploiement. Et c'est ce qui complète, côté produit, ce que la partie technique seule ne peut pas faire : améliorer un RAG sans données d'usage, c'est tâtonner.

Récap actionnable¶

1. Patterns 1 et 2 d'abord. Ce sont les capteurs. Sans eux, le reste n'a pas de donnée à exploiter.
2. Pattern 3 ensuite. Dès que vous avez 1 000+ requêtes labellisées, la matrice révèle vos priorités réelles (généralement très différentes de ce que vous pensez).
3. Patterns 4 et 5 en consolidation. Ils ferment la boucle : suggestions pour amplifier vos forces, incertitude pour gérer vos faiblesses.

Un produit IA bien instrumenté côté UX devient sa propre source d'amélioration. C'est l'inverse de la spirale "POC qui marche, prod qui dérive" que je vois sur la majorité des projets que j'audite.

Si mes articles vous intéressent et que vous avez des questions ou simplement envie de discuter de vos propres défis, n'hésitez pas à m'écrire à anas@tensoria.fr, j'aime échanger sur ces sujets !

Vous pouvez aussi réserver un créneau d'échange ou vous abonner à ma newsletter :)

À propos de moi¶

Je suis Anas Rabhi, consultant Data Scientist freelance. J'accompagne les entreprises dans leur stratégie et mise en œuvre de solutions d'IA (RAG, Agents, NLP).

Découvrez mes services sur tensoria.fr ou testez notre solution d'agents IA heeya.fr.