Expérience utilisateur IA : l’alerte de Victoria McClune
Victoria McClune alerte sur le déclassement silencieux par l’IA. Comprenez ses effets sur les utilisateurs et les entreprises, et apprenez à mieux l’évaluer.
Quand l'IA change les règles sans prévenir : l'enquête de Victoria McClune
On juge l'intelligence artificielle à ce qu'elle produit : une réponse, un résumé, une recommandation. Mais il y a une question plus discrète, pourtant décisive : dans quelles conditions cette réponse a-t-elle été générée ? Et est-ce que tout le monde vit la même expérience ?
C'est précisément le sujet des travaux de Victoria McClune, spécialiste de l'interaction humain-machine au sein de Current Futures Group.
Son enquête, Silent Downgrade, part d'un constat simple. Une personne peut obtenir des réponses moins utiles, ou plus prudentes, sans comprendre pourquoi. Est-ce sa façon de formuler ? Le contexte de la conversation ? Ou des réglages du système ? Et au final, elle peut conclure trop vite que « ça vient de moi », alors que le problème se situe peut-être ailleurs : dans la façon dont l'outil est configuré.
Cette question ne concerne pas seulement les particuliers. Pour les entreprises, elle touche aussi un nerf économique très concret : si les équipes doivent multiplier les essais pour obtenir un résultat exploitable, la promesse de productivité devient beaucoup plus difficile à mesurer et à défendre. C'est ce que recouvre l'idée de « déclassement silencieux » : pourquoi l'expérience utilisateur doit entrer dans l'évaluation des outils, et comment s'y prendre sans confondre hypothèse, preuve et responsabilité.
De la création numérique à l'étude de l'IA
Le parcours de Victoria McClune suit plusieurs vagues technologiques. Encore étudiante en école d'art au moment des premiers iPad, elle lance une entreprise consacrée aux livres interactifs pour enfants. L'objectif n'est pas seulement de numériser un livre papier : il s'agit de repenser la manière dont un enfant vit une histoire, clique, explore, comprend.
L'entreprise collabore avec des illustrateurs de Disney, se fait remarquer à South by Southwest et fonctionne entièrement à distance, à une époque où le travail distribué restait encore moins courant. Et dès le départ, une idée revient : une technologie ne vaut quelque chose que si elle produit une expérience compréhensible et utile pour les personnes qui l'utilisent.
Quand l'économie de l'édition numérique change, McClune se tourne vers la réalité augmentée et la réalité virtuelle, notamment pour le marketing. À travers sa propre agence, elle participe à des projets qui impliquent plusieurs multinationales. Elle reste donc au contact de technologies en mouvement rapide, mais aussi d'un problème familier : faire en sorte que l'innovation serve vraiment ceux qui doivent l'adopter.
Une approche centrée sur les comportements
Après la pandémie, elle revient dans un secteur transformé par l'essor de l'intelligence artificielle. Elle étudie alors cette technologie au MIT, en s'appuyant sur ce qu'elle connaît déjà : psychologie, publicité et conception d'interfaces.
Ce positionnement compte. McClune ne se présente pas comme ingénieure, mais comme conceptrice d'interactions humain-machine, un métier qu'elle pratique depuis plus de vingt ans. Du coup, sa question ne s'arrête pas à la performance d'un modèle sur un test. Elle porte aussi sur le chemin réel : comment une personne formule une demande, interprète la réponse, repère un écart et décide de continuer ou de changer de stratégie.
Dans son travail, elle raconte un point de départ assez concret : après avoir intégré, dans ses conversations, des éléments liés aux enfants et à la santé, elle a eu l'impression que les réponses d'un modèle évoluaient. Elle a eu le sentiment que le système « prenait en charge » la situation d'une certaine manière. Alors elle a cherché ce qui pouvait influencer ces réponses.
Ce ressenti devient une porte d'entrée pour mener l'enquête, pas une preuve que tous les modèles fonctionnent pareil. La nuance est importante. Un doute peut signaler un vrai sujet à explorer, mais il ne suffit pas à expliquer une cause. Il faut ensuite reproduire, contrôler les variables et comparer ce qui se passe réellement.
Le « déclassement silencieux », une expérience difficile à repérer
Le terme Silent Downgrade, que l'on peut traduire par « déclassement silencieux », désigne la possibilité qu'un système réduise la qualité ou l'utilité des réponses, sans que la personne qui utilise l'outil voie clairement ce qui a changé. Selon McClune, l'expérience peut être influencée par des processus techniques et par le contexte, bien avant même que l'utilisateur ne formule une demande précise.
Pour expliquer cela, elle utilise la métaphore d'une pièce. L'utilisateur entre dans un espace dont les conditions sont déjà là : les interactions possibles et les réponses accessibles dépendent en partie de la façon dont le système a été conçu et configuré. Le problème, c'est que la personne ne voit pas forcément ces conditions. Elle ne connaît que sa demande et la réponse qu'elle obtient.
Pourquoi l'utilisateur peut croire que l'erreur vient de lui
Quand une réponse déçoit, la réaction la plus naturelle consiste à reformuler. On ajoute des détails, on change le ton, on découpe le problème, on tente autre chose. Et parfois, oui : cela améliore le résultat. Après tout, les modèles génératifs dépendent du contexte et de la manière dont une tâche est exprimée.
Mais ça ne devrait pas devenir la seule explication. Si les réponses restent vagues, excessivement prudentes ou difficilement exploitables, la difficulté peut aussi venir du modèle, de ses réglages, de l'interface ou des règles appliquées à l'échange. Sans information sur ces éléments, l'utilisateur risque de passer du temps à corriger sa méthode, alors que le problème ne dépend pas entièrement de lui.
Il ne s'agit pas non plus d'affirmer que toute réponse décevante prouve une discrimination ou une intention de manipulation. Une réponse peut varier pour plein de raisons : formulation, historique de conversation, mise à jour du modèle, caractère probabiliste de la génération. L'enjeu est plutôt de rendre ces variations observables et de ne pas faire porter automatiquement la responsabilité sur la personne qui interagit.
Une IA sans intention propre, mais pas sans effets
McClune ne décrit pas l'IA comme une entité consciente, dotée d'intentions indépendantes. Elle la voit comme une technologie générative et prédictive, construite à partir de modèles et d'informations d'origine humaine. Cela permet d'éviter de prêter au système une volonté qu'il n'a pas, tout en prenant au sérieux les effets produits par ses réponses.
Dans un cadre professionnel, ces effets peuvent compter : une réponse peut faire évoluer la façon d'accomplir une tâche, le temps consacré à une décision, ou la confiance accordée à un résultat. L'essentiel, c'est donc de distinguer ce qu'on suppose comme intention et ce qui se passe effectivement. Un outil n'a pas besoin de « vouloir » nuire pour produire une expérience déstabilisante ou des résultats inégaux.
Concrètement, la question devient alors : quelles décisions de conception, quels paramètres et quels mécanismes de contrôle contribuent à ce résultat ? Pour répondre, il faut regarder au-delà d'une moyenne de performance et observer les interactions dans des situations réelles.
Pourquoi l'expérience utilisateur est un enjeu économique
Les laboratoires d'IA mettent souvent en avant ce que les modèles savent faire : précision, vitesse, capacité de traitement, raisonnement, etc. C'est utile, mais ça ne suffit pas à dire si un outil fonctionne dans une organisation. Une démonstration peut être impressionnante, puis l'usage quotidien se révèle coûteux : les salariés passent alors leur temps à corriger, vérifier ou contourner ce que le système propose.
C'est aussi là que McClune critique la place trop limitée accordée à l'expérience utilisateur. Les entreprises veulent des résultats cohérents et vraiment utilisables. Or si l'interface complique la compréhension ou si les réponses demandent trop d'effort pour être interprétées, le travail de correction s'invite dans le flux normal. Résultat : le coût réel se rapproche de ce que l'entreprise pensait réduire.
Le coût caché des interactions fragiles
Dans un déploiement, le coût d'un outil ne se limite pas à l'abonnement ou à l'intégration technique. Il faut ajouter le temps nécessaire pour apprendre à s'en servir, vérifier les sorties, corriger les erreurs et gérer les cas où le modèle ne répond pas comme attendu.
Ces coûts sont souvent dispersés. Une personne reprend un texte pendant quelques minutes. Une autre vérifie une synthèse. Puis, à force, une équipe finit par produire un guide interne pour compenser les limites de l'interface. Pris séparément, chaque ajustement paraît acceptable. Mais répétés sur des dizaines de collaborateurs et sur des tâches différentes, ces petits coûts finissent par réduire nettement le bénéfice attendu.
Cela dit, l'objectif n'est pas d'exiger des réponses parfaites. Dans beaucoup de cas, un outil imparfait reste utile s'il accélère une première étape et si l'utilisateur sait ce qu'il doit vérifier. Le bon critère reste la valeur nette : le temps et la qualité gagnés, comparés aux efforts de contrôle et de correction.
Pour une direction, cette manière d'évaluer permet aussi de dépasser les indicateurs de démonstration. Plutôt que demander seulement si le modèle « sait faire », il faut mesurer ce que cela donne dans le travail réel : combien de temps pour obtenir une sortie acceptable ? À quelle fréquence faut-il reprendre ? Les utilisateurs arrivent-ils à reconnaître quand une réponse est incertaine ?
Le risque d'une adoption jugée uniquement sur des capacités
Une entreprise qui se contente d'évaluer un assistant sur des jeux de tests peut passer à côté des difficultés d'usage. Les situations réelles sont plus floues : les demandes sont incomplètes, les employés n'ont pas tous la même expérience, et les conséquences d'une erreur ne sont pas les mêmes selon le métier. Le système doit donc être observé dans son environnement, pas seulement à travers des performances isolées.
C'est particulièrement vrai quand l'IA intervient dans des processus qui touchent des personnes : recrutement, service client, accompagnement, traitement de dossiers. En France et en Europe, la protection des données et le cadre réglementaire, notamment le RGPD, font partie du décor. Mais la conformité ne remplace pas l'évaluation de l'expérience. Un outil peut respecter des règles formelles tout en restant difficile à utiliser correctement.
Pour les directions produit et les équipes métiers, le sujet touche donc à la fois l'efficacité, la responsabilité et la qualité de service. L'expérience utilisateur n'est pas une couche décorative à ajouter après le développement : elle conditionne la capacité des équipes à tirer parti de l'outil et à repérer ses limites.
Comment évaluer un outil d'IA sans blâmer l'utilisateur
L'idée de McClune invite aussi à élargir les compétences dans les équipes qui conçoivent et déploient l'IA. Les ingénieurs sont essentiels, mais ils ne couvrent pas à eux seuls les questions liées aux comportements, à la compréhension et aux usages. Psychologie, communication et conception d'interfaces humain-machine ont aussi leur place.
Cette approche ne consiste pas à opposer le technique et l'expérience. Elle vise plutôt à faire travailler ensemble des personnes capables de regarder différentes dimensions d'un même système. L'une pourra s'intéresser à la performance du modèle ; une autre observera ce que les utilisateurs comprennent, et comment ils réagissent quand la réponse devient incertaine.
Une grille de contrôle pour les équipes
Avant un déploiement à grande échelle, une organisation peut structurer l'évaluation autour de questions assez simples :
- La tâche est-elle clairement définie ? Précisez ce que l'outil doit produire et ce qui n'entre pas dans son rôle.
- Les résultats sont-ils évalués sur des cas réels ? Testez des situations représentatives du travail, y compris les demandes ambiguës ou incomplètes.
- Les utilisateurs peuvent-ils comprendre les limites ? Vérifiez qu'ils savent quand contrôler une réponse, et comment signaler un problème.
- Les variations sont-elles suivies ? Comparez les résultats selon les formulations, les contextes d'utilisation et les profils de tâches, sans conclure à partir d'un seul exemple.
- Le coût de correction est-il mesuré ? Estimez le temps passé à vérifier, reformuler et reprendre les productions.
- Existe-t-il un recours humain ? Définissez qui peut examiner un résultat contesté et comment le processus corrige le dispositif.
Cette grille ne garantit pas, à elle seule, qu'un système soit fiable ou équitable. Elle sert surtout à éviter une erreur fréquente : expliquer toute difficulté par un manque de compétence côté utilisateur, ou, à l'inverse, conclure trop vite que tout vient du modèle. Les observations doivent être documentées, comparées et interprétées avec prudence.
Rendre les décisions et les états du système lisibles
Chez Current Futures Group, McClune s'intéresse à la façon de rendre plus clairs les décisions et les états du système pour les personnes concernées. En pratique, cela veut dire fournir assez d'éléments pour comprendre ce que l'outil fait, ce qu'il ne fait pas, et quelles limites encadrent le résultat.
La transparence ne se résume pas à publier une documentation technique longue. Une information utile doit être disponible au bon moment. Dans une interface, ça peut prendre la forme d'une indication claire quand une réponse est incertaine, d'explications sur les usages prévus, ou d'un moyen simple de signaler un problème. La forme dépend du contexte : les besoins d'une équipe juridique ne sont pas ceux d'un service client.
McClune se montre aussi prudente vis-à-vis d'une régulation qui reposerait uniquement sur l'autorégulation des entreprises. Les organisations qui développent et commercialisent ces outils ont leurs intérêts et leurs incitations : il faut donc pouvoir examiner leurs pratiques. Pour les entreprises utilisatrices, cela implique de ne pas déléguer entièrement son jugement au fournisseur. Il faut demander des éléments vérifiables, tester le système dans son propre contexte et conserver une responsabilité claire sur les décisions prises.
L'objectif n'est pas d'attendre un système parfait avant de l'utiliser. Il s'agit plutôt de construire un processus assez solide pour détecter les problèmes, comprendre leurs causes probables et corriger le dispositif. Une IA utile, ce n'est pas seulement un modèle performant : c'est un outil dont les conditions d'usage sont assez lisibles pour que les personnes puissent travailler sans avancer à l'aveugle.
Conclusion : évaluer ce que l'IA fait vivre, pas seulement ce qu'elle produit
L'enquête de Victoria McClune remet sur la table une question que l'on met trop souvent de côté derrière les performances : qu'est-ce que la personne, elle, vit vraiment pendant l'usage ? Le « déclassement silencieux » mérite d'être examiné avec méthode, pas utilisé comme explication automatique à chaque réponse décevante. Mais son intérêt est bien réel : rappeler que le système, son contexte et l'interface comptent aussi dans le résultat.
Pour les entreprises, la décision ne devrait donc pas reposer uniquement sur une démonstration convaincante ou sur le nombre de tâches qu'un modèle sait accomplir. Il faut mesurer l'effort de vérification, observer les usages réels et donner aux équipes des moyens concrets de signaler ce qui ne marche pas.
L'IA n'a pas besoin d'être parfaite pour être utile. En revanche, elle doit rester assez lisible et assez contrôlable pour que ses limites ne soient pas confondues avec des erreurs de l'utilisateur.
Pour approfondir le contexte de cette recherche, vous pouvez consulter l'article de The Next Web consacré à Victoria McClune. Si votre organisation déploie déjà des outils d'IA, commencez par un audit simple : choisissez une tâche, observez le travail réel et mesurez le temps nécessaire pour transformer une réponse en résultat fiable.