Parcours utilisateur d'un produit IA

Pourquoi ce chapitre change la façon de concevoir

Un parcours utilisateur classique se cartographie autour d'écrans, de clics et d'étapes de conversion. Un parcours autour d'un produit IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire se cartographie autour de la confiance : à chaque étape, l'utilisateur réévalue silencieusement s'il continue à croire ce que le système lui dit ou lui propose. Cette réévaluation permanente est la différence structurelle entre un formulaire et un assistant conversationnel, et elle ne se voit dans aucune maquette.

La conséquence pratique est simple à énoncer et difficile à appliquer : concevoir un produit IA, ce n'est pas concevoir le chemin du succès et ajouter des messages d'erreur en périphérie. C'est concevoir en priorité les points où la confiance peut se rompre, parce que ce sont eux qui déterminent si l'utilisateur revient. Un produit qui répond bien neuf fois sur dix mais s'effondre silencieusement à la dixième perd davantage d'utilisateurs qu'un produit qui répond correctement sept fois sur dix mais le signale clairement à chaque fois qu'il se trompe.

Le taux de réussite technique d'un modèle et le taux de confiance perçu par l'utilisateur sont deux courbes différentes. La conception de produit IA agit sur la seconde, pas seulement sur la première.

Ce qu'un parcours utilisateur classique ne capture pas

Dans un produit logiciel déterministe, une action produit toujours le même résultat pour les mêmes entrées. L'utilisateur apprend vite les règles du système et ajuste son comportement en conséquence. Ce mécanisme d'apprentissage ne fonctionne plus de la même façon face à un modèle génératif : la même question, posée deux fois, peut produire deux réponses de qualité différente. L'utilisateur ne peut donc pas construire un modèle mental stable de « ce que fait le système », seulement une estimation probabiliste de « ce que fait le système en général ».

Cette instabilité a trois conséquences directes sur la conception du parcours :

• La première impression pèse disproportionnellement. Un utilisateur qui reçoit une réponse médiocre lors de son premier essai généralise cette expérience à l'ensemble du produit, même si les essais suivants sont meilleurs.
• La marge d'erreur tolérée n'est pas linéaire. Une erreur sur une tâche perçue comme critique (chiffre, date, engagement contractuel) coûte beaucoup plus cher en confiance qu'une erreur sur une tâche perçue comme exploratoire (brainstorming, reformulation).
• L'absence de retour est interprétée comme un échec, même quand le système fonctionne. Une latence de quelques secondes sans signal visuel est lue comme un blocage, pas comme un calcul en cours.

Cartographier le parcours d'un produit IA

La carte ci-dessous découpe un parcours type en six étapes. Trois d'entre elles concentrent l'essentiel du risque de perte de confiance : le premier promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire, la réponse, et l'évaluation qui s'ensuit. Les deux autres étapes à risque — la latence et l'évaluation — sont des points où des modes d'échec précis apparaissent de façon récurrente en production.

Les moments de vérité, un par un

Le premier prompt

Le premier prompt est l'instant où l'utilisateur traduit une intention floue en une formulation précise, souvent sans savoir ce que le système attend. C'est un moment de vérité parce que la qualité de la réponse dépend directement de la qualité de cette formulation, et que l'utilisateur n'a, à ce stade, aucune idée de la marge d'erreur du système face à une requête ambiguë.

Deux erreurs de conception reviennent régulièrement : laisser un champ de saisie vide sans aucune amorce, ce qui reporte tout le travail de formulation sur l'utilisateur ; ou au contraire proposer des suggestions tellement génériques qu'elles ne réduisent pas l'ambiguïté initiale. Un bon premier prompt s'accompagne d'exemples contextualisés au métier de l'utilisateur, pas d'exemples génériques copiés d'un produit concurrent.

La latence

La latence n'est pas un problème technique isolé : c'est un problème de perception. Un utilisateur qui ne reçoit aucun signal pendant trois secondes suppose que quelque chose ne fonctionne pas, alors qu'un traitement de trois secondes peut être parfaitement normal pour une génération complexe. L'absence de retour visuel pendant l'attente est l'un des points d'échec les plus sous-estimés en conception de produit IA, précisément parce qu'il ne provoque pas d'erreur technique — seulement une perte de confiance silencieuse.

La réponse

La réponse est le second moment de vérité, et le plus évident. Ce qui distingue un produit IA bien conçu, ce n'est pas l'absence d'erreurs dans la réponse — elles sont statistiquement inévitables — mais la capacité de la réponse à exposer son propre niveau de fiabilité. Une réponse qui cite ses sources, indique une incertitude ou propose une correction rapide inspire davantage confiance qu'une réponse affirmative mais opaque, même si cette dernière est objectivement plus souvent correcte.

Le désaccord et la correction

À un moment ou un autre, l'utilisateur va contredire la réponse du système. La façon dont le produit gère ce désaccord est révélatrice de sa maturité. Un système qui capitule immédiatement face à toute contradiction, même infondée, perd en crédibilité autant qu'un système qui campe rigidement sur une réponse erronée. La bonne pratique consiste à faire expliciter le désaccord avant de le traiter, ce qui permet de distinguer une vraie correction factuelle d'une simple préférence de formulation.

L'escalade vers un humain

Le moment où l'utilisateur demande, explicitement ou non, à sortir du canal automatisé est un moment de vérité à part entière. Un produit qui rend cette sortie difficile à trouver, ou qui la traite comme un échec à masquer, transforme une frustration ponctuelle en rupture définitive. À l'inverse, une escalade fluide, qui transmet le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire accumulé plutôt que de faire tout répéter, peut sauver une relation utilisateur qui semblait perdue.

Prévoyez un chemin d'escalade visible dès le premier écran, pas seulement après plusieurs échecs consécutifs. Un utilisateur qui sait qu'il peut sortir facilement du canal automatisé accepte plus volontiers d'y rester.

Les modes d'échec structurels

Certains modes d'échec ne sont pas des bugs ponctuels mais des propriétés récurrentes des produits construits sur des modèles génératifs. Les connaître permet de les concevoir en amont plutôt que de les découvrir en production.

L'abandon silencieux ne remonte dans aucun tableau de bord d'erreurs, puisqu'il ne produit techniquement aucune erreur. Si votre seul indicateur de qualité est le taux d'exception ou de crash, vous ne verrez jamais ce mode d'échec — jusqu'à ce que la rétention chute sans explication apparente.

Un assistant de support reçoit trois fois la même question reformulée différemment par un utilisateur frustré, sans jamais reconnaître qu'il s'agit du même problème. Chaque réponse repart de zéro, ignorant les deux tentatives précédentes. L'utilisateur finit par écrire « tu ne comprends rien », signal fort qui, correctement détecté, aurait dû déclencher une escalade automatique dès la deuxième reformulation plutôt qu'à la troisième.

Concevoir pour l'échec, pas seulement pour le succès

La tentation naturelle en conception de produit est de dérouler le chemin optimal et de traiter l'échec comme une exception à gérer en périphérie. Pour un produit IA, cette logique s'inverse : le chemin d'échec doit être conçu avec autant de soin que le chemin de succès, parce qu'il se produit avec une fréquence non négligeable et de façon difficile à prédire au cas par cas.

Concrètement, cela signifie prévoir, dès les maquettes initiales, une réponse à chacune des questions suivantes : que voit l'utilisateur si la réponse est incomplète ? Que voit-il si elle est en contradiction avec une réponse précédente ? Que se passe-t-il s'il ne répond pas du tout après avoir reçu une proposition d'action ? Ces trois scénarios, souvent absents des spécifications initiales, sont statistiquement plus fréquents que le scénario nominal sur un produit conversationnel à fort volume.

La friction volontaire est un autre levier sous-utilisé. Ajouter une étape de confirmation avant une action à conséquence réelle — envoi d'un message, modification d'une donnée, engagement financier — ralentit le parcours nominal de quelques secondes, mais évite les conséquences d'une hallucinationhallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire ou d'une mauvaise interprétation d'intention sur une action irréversible. Le coût de cette friction est mesurable et faible ; le coût de son absence peut être élevé et difficile à corriger après coup.

Toute friction n'est pas bénéfique. Ajouter une confirmation sur une action réversible et à faible enjeu (reformuler un texte, changer un ton) dégrade l'expérience sans réduire de risque réel. La friction doit être proportionnée à la réversibilité et à l'impact de l'action, pas appliquée uniformément par précaution générale.

Mesurer ce qui compte : métriques par étape

Les métriques produit classiques — taux de conversion, temps passé, nombre de sessions — restent utiles mais ne capturent pas les ruptures de confiance propres à un produit IA. Il est nécessaire d'ajouter des métriques spécifiques à chaque moment de vérité identifié plus haut :

• Taux de reformulation immédiate : proportion d'utilisateurs qui reposent une question similaire dans les trente secondes suivant une réponse, signal fort d'insatisfaction non exprimée.
• Taux d'abandon post-première-réponse : proportion de sessions qui se terminent juste après la toute première réponse du système, révélateur de la qualité de la première impression.
• Taux de correction acceptée : proportion de corrections proposées par l'utilisateur que le système intègre effectivement dans la réponse suivante, plutôt que de les ignorer.
• Taux d'escalade réussie : proportion de demandes d'escalade vers un humain qui aboutissent effectivement à un contact humain, sans étape supplémentaire bloquante.
• Délai perçu vs délai réel : écart entre la latence effective et le moment où l'utilisateur interrompt ou relance sa requête, qui indique le seuil de patience réel plutôt que théorique.

Ces métriques demandent une instrumentation dédiée, généralement absente des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire d'analytics génériques. Elles doivent être posées dès la phase de conception, pas ajoutées après coup une fois le produit en production, sous peine de ne disposer d'aucune donnée historique pour comparer avant et après une évolution.

Checklist de conception avant mise en production

Avant tout lancement ou évolution majeure d'un parcours reposant sur un modèle génératif, il est utile de vérifier systématiquement les points suivants :

• Le premier prompt dispose-t-il d'amorces contextualisées au métier de l'utilisateur, et non d'exemples génériques ?
• Un signal visuel explicite couvre-t-il toute période de latence supérieure à une seconde ?
• La réponse expose-t-elle un niveau de confiance ou une source, au moins pour les contenus factuels ?
• Existe-t-il un mécanisme de feedback à faible friction sur chaque réponse, pas seulement en cas d'erreur signalée ?
• Le contexte de session est-il réellement exploité d'une réponse à l'autre, ou chaque échange repart-il de zéro ?
• Le chemin d'escalade vers un humain est-il visible dès le premier écran ?
• Les actions irréversibles ou à fort impact sont-elles protégées par une confirmation explicite ?
• Les métriques de reformulation, d'abandon post-première-réponse et d'escalade sont-elles suivies dans un tableau de bord dédié ?

Cette liste ne remplace pas une analyse spécifique au produit concerné, mais elle couvre les points qui reviennent le plus fréquemment dans les retours d'expérience de produits IA déployés à grande échelle. Un produit qui coche l'ensemble de ces cases n'est pas à l'abri de tout échec, mais il dispose des instruments nécessaires pour détecter les ruptures de confiance avant qu'elles ne deviennent des désabonnements silencieux.

Le chapitre suivant s'appuie sur cette cartographie pour aborder la conception des garde-fous eux-mêmes : quels contrôles automatiques placer à chaque moment de vérité identifié ici, et comment les calibrer sans détruire la fluidité du parcours nominal.