Un logiciel classique promet une chose et la tient : tu cliques, il fait. Un produit IA propose quelque chose qui est probablement juste. Toute la difficulté de conception tient dans ce « probablement ». Le cacher produit des utilisateurs qui font aveuglément confiance jusqu'au jour où ils se font avoir, puis qui n'y reviennent plus. L'exposer maladroitement produit des utilisateurs qui vérifient tout, donc qui n'y gagnent rien.
Entre les deux, il y a une poignée de patterns qui fonctionnent. Les voici, avec les erreurs qui vont avec.
Montrer d'où ça vient
Le pattern le plus rentable, et le plus simple à implémenter : à côté de chaque élément produit, indique la source.
Le document et la page dont l'information est extraite. Le champ du système d'origine. Les trois dossiers passés sur lesquels s'appuie la recommandation. Idéalement cliquable, pour ouvrir la source à l'endroit exact.
Ce que ça change : l'utilisateur passe de « est-ce que je peux croire ce truc » à « est-ce que cette source est la bonne ». La seconde question, il sait y répondre en deux secondes — c'est son métier. La vérification devient un geste rapide au lieu d'un doute diffus.
Sur Wavestay et sur Pulse Outdoor Training Club, les deux produits que j'ai construits seule en no-code assisté par IA, c'est la règle que j'ai le plus vite intégrée : dès qu'un contenu est généré, il porte sa provenance. Ça évite exactement le moment où l'on se demande, trois semaines plus tard, d'où sortait cette information.
Exprimer l'incertitude sans inventer un pourcentage
« Confiance : 87 % ». Ce chiffre ne veut presque jamais dire ce que l'utilisateur croit qu'il veut dire, et il donne une précision que le système n'a pas.
Ce qui marche mieux :
- Trois niveaux, pas cent. Sûr / à vérifier / incertain. Trois traitements visuels distincts, sur l'élément lui-même et pas dans une légende à part.
- Un seuil sur le comportement. Sous un certain niveau, on ne pré-remplit pas : on propose, ou on demande. L'incertitude se traduit en interaction plutôt qu'en indicateur.
- Le doute nommé. « Deux dates figurent dans le document, j'ai retenu celle de l'en-tête. » C'est plus utile qu'un score, parce que ça dit quoi vérifier.
La règle générale : si l'utilisateur ne peut pas agir différemment selon le niveau affiché, l'affichage ne sert à rien. Une information d'incertitude doit changer un geste.
Rendre la correction moins coûteuse que la saisie
C'est le critère qui décide de l'adoption, plus que la qualité du modèle.
Si l'utilisateur doit effacer le champ, retrouver l'information et la retaper, tu lui as ajouté du travail. Il désactivera la fonctionnalité dès qu'il pourra, et il aura raison.
Ce qui rend une correction bon marché :
- le champ est directement éditable, sans passer par un mode « modifier » ;
- une alternative est proposée en un clic quand il y en a une plausible ;
- corriger un élément ne détruit pas le reste de la proposition ;
- le rejet global est accessible en un geste, sans confirmation ni justification.
Cette dernière ligne est celle qu'on ampute le plus souvent, par crainte que les gens refusent trop vite. C'est l'inverse qui se produit : un refus facile rend l'acceptation sincère. Quand refuser coûte cher, les gens acceptent par lassitude, et tes indicateurs d'adoption ne mesurent plus rien.
Garder la trace de ce qui a été modifié
Distinguer visuellement ce que le système a proposé de ce que l'utilisateur a écrit. Puis conserver cette distinction en base, avec un horodatage.
Trois usages, dans l'ordre d'importance :
- La confiance. L'utilisateur voit ce qui reste automatique et ce qu'il a repris. Il n'a pas besoin de se rappeler.
- Le pilotage. Le taux de correction par champ est le meilleur indicateur de qualité que tu auras jamais, et il est gratuit.
- L'amélioration. Les corrections récurrentes indiquent exactement où retravailler le prompt, la source ou le périmètre.
Mais garder la trace sans jamais la regarder, c'est de l'archivage. Prévois qui lit ces données et à quelle fréquence, sinon ne les collecte pas.
Les anti-patterns que je vois le plus
L'avertissement générique. « L'IA peut faire des erreurs, vérifiez les informations importantes. » Affiché partout, tout le temps, il disparaît de la perception au bout de deux jours. Un avertissement doit être contextuel et rare pour rester lu.
Le ton trop assuré. Une formulation péremptoire sur un résultat incertain. Le registre du texte fait partie de l'interface : « il semble que » et « c'est » n'engagent pas la même vigilance chez le lecteur.
Le chargement sans issue. Une animation, aucune indication de durée, aucun moyen d'annuler. Sur un traitement long, il faut un état intermédiaire et une sortie.
L'anthropomorphisme mal placé. Un prénom, un avatar, un ton de conversation sur un outil qui remplit un formulaire. Ça déplace les attentes vers une compréhension que le système n'a pas, et rend la déception plus violente.
La suggestion sans action. Un encart pertinent, mais l'utilisateur doit ouvrir un autre écran pour en faire quelque chose. Une recommandation qu'on ne peut pas appliquer sur place devient du bruit.
Le tout ou rien. Une proposition qu'on accepte ou refuse en bloc, alors que quatre champs sur cinq étaient bons. Le grain de l'acceptation doit correspondre au grain de l'erreur.
Le test à faire sur ta prochaine maquette
Prends l'écran où l'IA intervient et chronomètre trois gestes : accepter, corriger un élément, tout refuser. Si le refus prend plus longtemps que l'acceptation, ton produit pousse les gens à dire oui sans regarder. Ce n'est pas de l'adoption, et ça se retournera contre toi au premier incident.