UX Designer / UX Researcher : ce que l'IA change dans le métier

Deux sujets à ne pas confondre

Il existe aujourd'hui deux conversations distinctes autour de l'IA et du design. La première porte sur les outils : générer des variantes, produire des maquettes plus vite, résumer des verbatims de recherche. La seconde, beaucoup moins traitée, porte sur l'objet conçu : que devient une interface lorsque le système derrière elle produit un résultat variable, parfois faux, souvent plausible ? C'est cette seconde question qui redéfinit réellement le métier de designer et de chercheur.

Concevoir avec l'incertitude comme matériau

Dans une interface classique, l'incertitude est une exception : un chargement, une erreur réseau, un champ invalide. Dans une interface adossée à un système IA, l'incertitude est permanente. Le système ne sait pas toujours qu'il se trompe, et l'utilisateur ne peut pas toujours le vérifier. La conception consiste donc à rendre cette incertitude manipulable plutôt qu'à la masquer.

• Montrer sur quoi la réponse s'appuie, quand la source existe et peut être ouverte.
• Distinguer visuellement ce que le système a produit de ce que l'utilisateur a écrit.
• Traiter l'absence de réponse comme un état de conception, pas comme un vide.
• Rendre la modification aussi accessible que l'acceptation.
• Éviter les formulations d'autorité lorsque le système ne peut pas garantir la réponse.

Une règle utile : l'interface ne doit jamais afficher plus de certitude que le système n'en a réellement. C'est autant une question de crédibilité produit que d'éthique.

Expliquer ce que le système sait faire — et ne sait pas faire

La plupart des échecs d'adoption d'une fonctionnalité IA viennent d'un décalage d'attente : l'utilisateur croit parler à un système qui comprend tout, puis découvre une limite arbitraire et abandonne. Le rôle du design est de poser le périmètre au bon moment, c'est-à-dire au moment de l'usage et non dans une page d'aide.

• Un premier écran qui montre trois usages réels plutôt qu'un champ vide.
• Des exemples cliquables qui enseignent le périmètre sans texte explicatif long.
• Un message clair et non culpabilisant quand la demande sort du périmètre.
• Une indication de fraîcheur quand la réponse dépend de données datées.

Le champ de saisie libre est la promesse la plus large qu'une interface puisse faire. Si le système ne tient qu'une partie de cette promesse, mieux vaut contraindre l'entrée que décevoir la sortie.

Viser une confiance calibrée, pas une confiance maximale

L'objectif n'est pas que l'utilisateur fasse le plus confiance possible au système : c'est qu'il lui fasse confiance au bon niveau. Une confiance excessive produit des erreurs acceptées sans relecture. Une confiance insuffisante produit un abandon, ou une double vérification qui annule tout le bénéfice. Entre les deux, la calibration se construit avec des signaux constants et honnêtes.

• Cohérence : le système se comporte de la même manière dans des situations semblables.
• Vérifiabilité : l'utilisateur peut confirmer une réponse en un geste, pas en cinq.
• Aveu de limite : le système signale ce qu'il n'a pas trouvé au lieu de combler le vide.
• Réparabilité : une erreur se corrige sans perdre le travail déjà fait.

Erreurs, réponses imparfaites et états de repli

Concevoir un produit IA, c'est surtout concevoir ses états dégradés. La plupart des maquettes présentées en revue montrent le cas idéal ; l'expérience réelle se joue ailleurs. Quatre familles d'états méritent d'être dessinées explicitement, au même niveau de soin que l'état nominal.

• Réponse partielle : le système a trouvé une partie de l'information et le dit.
• Réponse incertaine : la réponse existe mais mérite une vérification ; le chemin de vérification est fourni.
• Absence de réponse : le système s'abstient et propose une alternative utile (recherche, contact, modèle vierge).
• Réponse fausse détectée par l'utilisateur : signalement immédiat, correction possible, trace conservée.

Le dernier état est le plus négligé et le plus déterminant. Un utilisateur qui repère une erreur et ne peut rien en faire perd confiance durablement ; un utilisateur qui la corrige en un geste devient contributeur de la qualité du système.

Garder l'utilisateur en contrôle

La reprise en main n'est pas une option de secours, c'est une composante centrale de l'expérience. Elle se conçoit sur trois plans : avant l'action (choisir le périmètre, ajuster la demande), pendant (interrompre, reformuler, restreindre) et après (modifier, annuler, revenir à l'état précédent).

• Toute action irréversible passe par une validation explicite, jamais par un enchaînement automatique.
• Toute sortie générée est modifiable dans l'interface où elle apparaît.
• L'historique permet de comprendre ce qui a été produit, quand et à partir de quoi.
• L'utilisateur peut désactiver l'assistance sans perdre l'accès à la fonctionnalité de base.

Human-in-the-loop : concevoir le geste de supervision

Quand une organisation décide qu'un humain valide les sorties du système, cette validation devient un vrai parcours utilisateur, avec sa charge cognitive et son risque propre. Un dispositif mal conçu produit une validation de façade : l'utilisateur clique « accepter » sans lire, et le contrôle n'existe plus que sur le papier.

• Rendre visible ce qui doit être vérifié en priorité plutôt que la totalité de la sortie.
• Différencier les éléments à fort enjeu (montants, dates, engagements) du reste du texte.
• Limiter le volume à valider par session : au-delà, la vigilance chute.
• Rendre le refus aussi simple que l'acceptation, et enregistrer le motif quand il est utile.

Un contrôle humain que l'on peut exécuter en une seconde sans lire n'est pas un contrôle : c'est une signature. La conception décide de laquelle des deux existe réellement.

Le feedback utilisateur comme boucle produit

Le pouce levé ou baissé est le degré zéro du feedback : il indique une insatisfaction sans dire laquelle. Un dispositif utile capte la nature du problème avec un effort minimal, et se relie au travail d'évaluation mené côté produit et ingénierie.

• Proposer deux ou trois motifs concrets plutôt qu'un champ libre : information manquante, information fausse, ton inadapté, hors sujet.
• Capter la correction réelle quand l'utilisateur réécrit la sortie : c'est le signal le plus riche.
• Fermer la boucle : indiquer que le signalement a été pris en compte lorsque c'est vrai.
• Ne pas demander de feedback sur chaque interaction ; l'échantillonnage suffit.

Transparence utile sans surcharge d'interface

Tout expliquer revient à ne rien expliquer : un bandeau d'avertissement permanent devient invisible en une semaine. La transparence pertinente est contextuelle et progressive : une indication courte au niveau de la réponse, un accès à la source en un clic, un détail complet uniquement pour qui le demande.

Conversationnel : un choix, pas un réflexe

Le chat est devenu la forme par défaut des fonctionnalités IA, souvent sans raison. Une conversation est pertinente quand la demande est imprévisible, exploratoire ou itérative. Elle l'est beaucoup moins quand la tâche est répétitive et bien connue : dans ce cas, un formulaire, un bouton contextuel ou une suggestion en ligne produisent une expérience plus rapide et plus fiable.

• Tâche connue et cadrée : action contextuelle ou champ structuré.
• Tâche exploratoire, formulation libre : conversation.
• Tâche répétée à fort volume : automatisation avec revue par exception.
• Tâche à fort enjeu : parcours guidé avec vérification explicite.

Copilote ou automatisation complète

Le choix entre assister et automatiser est un choix de conception, pas un niveau de maturité. Un copilote laisse la décision à l'utilisateur et gagne en acceptabilité ce qu'il perd en gain de temps. Une automatisation complète produit le gain maximal mais suppose que l'erreur soit rare, détectable et réversible. Entre les deux, l'automatisation avec revue par exception traite seuls les cas sûrs et n'envoie à l'humain que les cas incertains.

Le rôle du designer est de rendre ce choix visible à l'équipe, avec ses conséquences : qui porte la responsabilité de la sortie, ce que l'utilisateur voit du travail effectué, et ce qui se passe quand le système se trompe sans que personne ne le remarque.

Faire de la recherche sur un parcours non déterministe

La recherche utilisateur classique s'appuie sur un parcours stable : on observe plusieurs personnes réaliser la même tâche dans la même interface. Sur un produit IA, deux participants qui posent la même question peuvent recevoir deux réponses différentes. Le protocole doit donc s'adapter, sans perdre en rigueur.

• Tester une tâche et un objectif, pas un écran figé : ce qui compte est la capacité à aboutir.
• Préparer plusieurs sorties possibles à l'avance — bonne, partielle, fausse — et observer la réaction à chacune.
• Introduire délibérément un cas d'erreur : c'est le seul moyen de savoir si l'utilisateur la détecte.
• Distinguer l'incompréhension du système de l'incompréhension de l'interface.
• Documenter le contexte exact de chaque session : version, données disponibles, réponse obtenue.

Deux mesures méritent une attention particulière : la détection d'erreur — l'utilisateur repère-t-il une réponse fausse ? — et la sur-confiance — accepte-t-il une réponse plausible sans vérifier ? Ces deux signaux disent plus sur la viabilité d'une fonctionnalité IA qu'une note de satisfaction.

Cas concret : une recommandation qui se trompe

Un outil interne de gestion de contrats propose une clause type à partir du contexte du dossier. Dans la version initiale, la clause s'insère directement dans le document, sans indication d'origine. Lors d'un test, un participant valide une clause inadaptée à son cas : elle était bien rédigée, elle semblait cohérente, et rien ne l'invitait à la vérifier. Le problème n'est pas la qualité du modèle, c'est l'absence de conception autour de l'erreur.

Ce que la version révisée prévoit :

• La proposition apparaît dans un état distinct du texte validé, tant qu'elle n'a pas été acceptée.
• Elle indique le modèle de référence utilisé et la date de sa dernière mise à jour.
• Les éléments variables (durée, montant, juridiction) sont mis en évidence comme à vérifier.
• Quand le contexte est incomplet, le système propose une clause vide plutôt qu'une clause plausible.
• Un rejet en un clic, avec motif optionnel, alimente la revue qualité hebdomadaire.
• L'historique conserve qui a accepté quoi, et à partir de quelle proposition.

Aucune de ces décisions ne relève du modèle. Toutes relèvent de la conception de l'expérience, et ce sont elles qui décident si la fonctionnalité est utilisable dans un contexte à enjeu.

Travailler avec le produit et l'ingénierie IA

Sur ce type de produit, la frontière habituelle entre design, produit et technique se déplace. Le comportement du système est en partie une décision de design : que se passe-t-il en cas de doute, qu'affiche-t-on, que refuse-t-on. Réciproquement, une contrainte technique — latence, coût, fraîcheur des données — devient une contrainte d'expérience.

• Participer à la définition des cas de test : les cas limites du produit sont souvent des cas limites d'interface.
• Demander à voir de vraies sorties, y compris ratées, avant de dessiner les écrans.
• Exprimer les besoins d'interface en termes de comportement attendu, pas de composant.
• Anticiper le coût d'expérience de la latence : ce qui prend plusieurs secondes se conçoit autrement.

Un designer qui a vu cent sorties réelles d'un système conçoit une interface radicalement différente de celui qui a vu trois exemples de démonstration. C'est probablement le changement de méthode le plus utile de toute cette liste.

• Expérience IA
• Human-in-the-loop
• Copilotes