Six patterns d'interface pour les produits IA

Les produits IA échouent rarement sur le modèle. Ils échouent sur l'interface qui l'entoure : l'attente qu'on ne met pas en scène, l'incertitude qu'on transfère à l'utilisateur, l'écran vide qui l'accueille, l'action qu'on ne peut pas défaire.

Voici six patterns que j'applique systématiquement, avec pour chacun l'anti-pattern qu'il remplace.

1. La latence mise en scène plutôt que masquée

Anti-pattern : un spinner générique pendant quarante secondes.

Un bouton classique répond en 200 millisecondes. Un agent met parfois quarante secondes. Entre les deux, il n'y a pas un problème de performance : il y a un problème de design. Pendant ces quarante secondes, l'utilisateur ne se demande pas « c'est lent », il se demande « est-ce que ça marche ». S'il en doute, il recharge la page, relance la requête, ou abandonne le produit.

Trois règles :

• Nommer l'étape en cours. « Recherche des entreprises » puis « Vérification des emails » : le même délai devient une progression au lieu d'un blocage.
• Livrer en flux, pas en bloc. Le premier résultat visible à trois secondes change complètement la perception d'un traitement qui en dure quarante. La durée totale ne bouge pas ; l'attente perçue, si.
• Rendre l'attente annulable. Un traitement qu'on ne peut pas arrêter est un traitement auquel on ne fait pas confiance la fois suivante.

Le principe derrière les trois : la latence d'une IA n'est pas un temps mort à masquer. C'est le seul moment où l'utilisateur peut observer le raisonnement de la machine et décider s'il y croit.

2. L'incertitude traduite en action, pas en pourcentage

Anti-pattern : « Confiance : 87 % ».

Deux problèmes. D'abord, ce chiffre est rarement une probabilité calibrée : c'est souvent un score interne reformaté pour rassurer, et 87 % ne veut pas dire « juste 87 fois sur 100 ». Ensuite, même calibré, personne ne sait quoi en faire. À partir de quel seuil je vérifie ? 80 ? 95 ? L'interface transfère à l'utilisateur une décision qu'elle aurait dû prendre.

Trois alternatives, de la plus simple à la plus aboutie :

• Montrer la source plutôt que le score. « Trouvé dans le registre officiel » informe mieux sur la fiabilité que n'importe quel pourcentage.
• Traduire le score en action. Trois états suffisent : utilisable directement / à vérifier / écarté. C'est le produit qui applique le seuil, pas l'utilisateur.
• Rendre le doute visible dans la donnée. Un champ estimé ne s'affiche pas comme un champ confirmé. La différence se voit sans qu'on ait besoin de la lire.

Un produit IA honnête ne demande pas à l'utilisateur d'interpréter l'incertitude. Il l'a déjà interprétée pour lui, et il assume ce choix.

3. La réversibilité perçue plutôt que technique

Anti-pattern : une action d'agent définitive, protégée par une modale « êtes-vous sûr ? ».

L'adoption d'une fonctionnalité automatisée ne dépend presque jamais de sa qualité. Elle dépend de ce qui se passe quand elle se trompe. Or beaucoup d'actions d'agent sont réellement irréversibles : un email parti est parti, un crédit consommé est consommé.

Trois formes de réversibilité quand l'annulation stricte est impossible :

• Le délai de rattrapage — décision immédiate, exécution différée de trente secondes.
• Le brouillon par défaut — l'agent produit, l'humain envoie.
• La visibilité avant engagement — coût, volume et échantillon affichés avant de lancer.

Aucune ne rend l'action réversible techniquement. Toutes rendent la décision réversible pour l'utilisateur, et c'est cette perception qui détermine si l'automatisation est utilisée ou contournée.

4. Le premier écran qui a déjà travaillé

Anti-pattern : un champ de saisie vide et un curseur qui clignote.

C'est l'écran d'accueil de la majorité des produits IA, et c'est le meilleur moyen de perdre un utilisateur en douze secondes. Le problème n'est pas esthétique : un champ libre demande deux choses que l'utilisateur n'a pas encore, savoir ce que le produit sait faire et savoir le formuler. C'est un examen présenté comme une invitation.

Trois remplacements, du moins bon au meilleur :

• Les suggestions d'amorce. Trois exemples cliquables. Ça aide, mais ça reste générique et l'effet s'épuise après la première session.
• Le point de départ contextuel. Ouvrir sur ce que l'utilisateur regardait — une liste, un document, un dossier — avec les actions possibles depuis cet objet. On passe d'un « que voulez-vous ? » à un « voilà ce qu'on peut faire d'ici ».
• Le produit qui a déjà travaillé. Le meilleur premier écran n'est pas vide : il montre un résultat déjà calculé, et le champ de saisie sert à le corriger.

Réagir est toujours plus facile que produire. C'est vrai en entretien utilisateur, et c'est vrai ici.

5. La trace lisible plutôt que le log

Anti-pattern : aucune trace, ou une trace technique illisible.

Quand un agent agit sans supervision continue, l'utilisateur a besoin de pouvoir reconstituer après coup ce qui s'est passé. Pas pour auditer — pour comprendre, et donc pour faire confiance la fois suivante.

Une bonne trace répond à quatre questions dans le vocabulaire du métier, pas dans celui du système : quoi, quand, sur quelle base, avec quel résultat. « Relance envoyée à Marie Dupont le 12/09, parce qu'aucune réponse depuis 5 jours, ouverte le 13/09. » Ce n'est pas un log, c'est une phrase.

Le test est simple : si un utilisateur ne peut pas expliquer à son responsable pourquoi le système a fait ce qu'il a fait, la trace est insuffisante.

6. Le coût affiché avant l'action

Anti-pattern : un compteur de crédits caché dans les paramètres.

Ce pattern est spécifique aux produits IA, et il est souvent traité comme une contrainte de facturation plutôt que comme du design. C'est une erreur : sur un produit où chaque action a un prix, l'économie devient une dimension de l'expérience.

Trois règles :

• Afficher le coût avant l'action, pas après — et en unités que l'utilisateur comprend.
• Distinguer le gratuit du payant visuellement, pour que le réflexe économique devienne un réflexe d'usage.
• Réutiliser avant de dépenser. Un résultat déjà payé se ressert gratuitement, et il faut le dire.

Une contrainte économique bien exposée cesse d'être une contrainte : elle devient un parcours. Les utilisateurs apprennent vite à optimiser eux-mêmes, à condition qu'on leur en donne les moyens.

Ce que ces six patterns ont en commun

Aucun ne concerne la qualité du modèle. Tous concernent la relation entre l'utilisateur et une machine qui décide à sa place : ce qu'elle lui montre pendant qu'elle travaille, ce qu'elle lui dit de sa propre incertitude, ce qu'elle lui laisse défaire, ce qu'elle lui propose au démarrage, ce qu'elle lui permet de relire, et ce qu'elle lui coûte.

C'est là que se joue l'adoption. Un modèle légèrement moins performant dans une interface honnête sera utilisé ; l'inverse ne se vérifie presque jamais.