IA : expliquer la latence préserve la confiance

Dans les interfaces d’IA, ce n’est pas la lenteur qui coûte le plus, c’est l’attente incomprise. Des praticiens comme Bilal Skiani et des travaux fondateurs en ergonomie convergent : un produit doit décrire ce qu’il fait plutôt que promettre un délai qu’il ne maîtrise pas. À défaut, la confiance s’érode sans bruit, puis se brise.

Les équipes constatent la perte de confiance trop tard

La latence se surveille et la précision se calibre, mais la dégradation de la confiance ne dispose ni d’un tableau de bord ni d’un référentiel. Les équipes la découvrent tardivement. Bilal Skiani résume : « La latence se dégrade bruyamment. La confiance se dégrade silencieusement, puis soudainement. » La plupart des défaillances logicielles évoluent avec la charge ou la qualité des entrées ; la confiance, elle, ne suit pas cette proportionnalité. Elle s’érode attente inexpliquée après attente inexpliquée, puis s’effondre autour d’un déclencheur sans lien.

Des messages de progression inexacts aggravent le problème

Un message de progression qui décrit la mauvaise opération nuit davantage qu’une estimation de durée manquée, car il installe un modèle erroné dans l’esprit de l’utilisateur. Afficher « Analyse de votre document » alors que le système attend un appel réseau lent relève de la fiction. Bilal Skiani a rencontré ce cas : dans une version antérieure, ses messages tournaient sur un minuteur, indépendamment de l’état réel. Si les démonstrations paraissaient propres, en production le modèle pouvait finir en environ 400 millisecondes tandis que l’interface continuait d’annoncer un traitement en cours, car l’animation se fiait au temps et non à l’état. L’utilisateur attendait alors pour rien.

L’ancre du plus rapide transforme des attentes en soupçon de panne

Les utilisateurs évaluent un produit d’IA par la réponse la plus rapide observée, non par une moyenne. Tversky et Kahneman ont décrit l’ancrage : une première valeur sert de repère et l’ajustement ultérieur est insuffisant. En interface, le premier résultat rapide fixe l’ancre. Dans la pratique, des opérations de recherche ou d’export sur un petit historique finissent presque instantanément ; sur un grand historique, elles prennent plus de temps et les messages de support basculent de « comment utiliser » à « est-ce cassé ? ». Le code et l’architecture restent identiques, seule la taille d’entrée varie. Sans réinitialisation d’ancre par l’interface, « c’est généralement rapide » n’aide pas : la bonne volonté générée par le cas rapide est dépensée par le cas lent. L’exemple rapporté par Bilal Skiani avec son outil de transcription l’illustre : un retour en deux secondes a posé une promesse implicite ; une semaine plus tard, six secondes — pourtant proportionnées à la longueur du passage — ont été perçues comme une panne, alors que rien n’avait changé côté système. « La variance inexpliquée » est, selon lui, ce qui détruit la confiance.

Exposer la variance ou la lisser : deux fausses bonnes idées

Deux réponses dominent face à une variabilité élevée des temps de réponse en IA : l’exposer brute via un indicateur uniforme ou l’aplanir par un délai minimum. La première, avec un simple « en cours de réflexion » identique à une seconde comme à quarante, empêche de distinguer un long calcul d’un blocage. La seconde évite qu’un retour fulgurant fixe une ancre irréaliste, mais dégrade volontairement chaque réponse rapide, supprimant un bénéfice potentiel pour prévenir un risque que l’interface pourrait expliquer. Dans les deux cas, la variance est traitée comme le problème. Or, comme l’a formulé David Maister, des attentes expliquées ou connues paraissent plus courtes que des attentes incertaines ; une attente variable acceptable devient pénalisante quand elle reste inexpliquée. Cette question est centrale dans les produits d’IA, où le même prompt peut durer d’une à quarante secondes selon la charge, la profondeur de raisonnement, les appels d’outils et la longueur d’entrée.

Dire ce qui se passe plutôt que promettre un délai

L’enjeu n’est plus d’afficher un indicateur de progression, mais de choisir son contenu. Des travaux anciens restent pertinents : forte préférence pour les pourcentages (Brad Myers), nécessité d’informer en continu (Jakob Nielsen), principes de latence et d’anticipation (Bruce Tognazzini), et influence du comportement de la barre sur la perception (Chris Harrison et collègues). Quand la durée est inconnue, Nielsen recommande d’énumérer les unités traitées — par exemple les bases de données parcourues — plutôt que de recourir à un simple indicateur, jugé « dernier recours » car il ne dit pas ce qui est fait. Les pipelines consignent chaque étape et disposent des données pour les afficher ; la décision de les montrer à la personne en attente est souvent absente. Une voie opérationnelle consiste à nommer le travail, pas l’horloge : l’anticipation temporelle (« environ 10 secondes ») engage une promesse fragile, tandis qu’une anticipation de processus (« scan de l’historique de conversation ») place l’ancre sur l’activité. Une estimation manquée est perçue comme un retard ; un processus nommé n’est pas en retard puisqu’aucun temps n’a été promis.