Test utilisateur d’un prototype IA : un oui en réunion ne valide pas votre produit
Test utilisateur d’un prototype IA : un oui en réunion ne valide pas votre produit
En réunion, le fondateur clique, explique les écrans et rattrape les hésitations. Tout le monde trouve le prototype convaincant. Puis une personne extérieure l’essaie seule : elle ne sait pas quoi faire après avoir envoyé sa demande. L’équipe avait validé une démonstration accompagnée, pas un parcours utilisable.
Un test utilisateur de prototype IA consiste à observer une personne représentative accomplir une tâche réaliste, sans lui indiquer le chemin. Il sert à repérer ce qui empêche l’usage avant de financer la suite. Il ne démontre, à lui seul, ni une demande solvable, ni la fiabilité technique du futur produit.
Que voulez-vous apprendre avant de développer davantage ?
« Est-ce que vous aimez ? » produit facilement des compliments. « Vous devez retrouver le devis reçu hier et demander une correction » met le parcours à l’épreuve. La seconde consigne donne une action observable et permet de constater un échec, même si l’interface plaît.
Le Service Manual de GOV.UK décrit le test d’utilisabilité modéré comme l’observation de participants réalisant des tâches précises. Il recommande des consignes plausibles, pertinentes pour eux et qui ne révèlent pas la réponse. Ce repère méthodologique s’applique aussi à une maquette générée avec Lovable, Bolt ou v0 ; il ne constitue pas une certification de ces outils.
Choisissez donc une décision avant la séance : faut-il simplifier l’envoi d’une demande, rendre son statut compréhensible ou revoir la promesse d’accueil ? Tester tout le produit à la fois rendra l’arbitrage plus difficile. Pour cadrer le reste de la V1, le PRD issu du prototype IA rassemble les exigences ; le test doit ici éclairer une incertitude précise.
Qui recruter, et quelle tâche confier ?
Une personne qui connaît déjà le projet n’a plus le regard d’un premier utilisateur. Recherchez des utilisateurs actuels ou plausibles, avec les contraintes du public visé : vocabulaire métier, équipement, aisance numérique et éventuel besoin d’assistance. Le guide GOV.UK sur les besoins utilisateurs rappelle que les opinions d’autres parties prenantes restent des hypothèses à vérifier.
Scénario illustratif : une PME veut tester un portail de demandes de devis. Le participant reçoit une situation : « Le montant proposé ne correspond plus à votre besoin. Faites demander une nouvelle estimation et vérifiez que votre demande a été prise en compte. » Évitez « Cliquez sur Modifier puis sur Confirmer » : cette consigne fournirait précisément la solution à tester.
Utilisez des données fictives cohérentes si la confidentialité ou les capacités du prototype empêchent d’employer des données réelles dans de bonnes conditions. Indiquez ce qui est simulé. Une confirmation affichée ne prouve pas qu’un email est envoyé, qu’un devis est enregistré ou qu’un système métier a été mis à jour.
Que noter quand l’utilisateur hésite ?
L’animateur veut naturellement aider. Mais s’il explique chaque écran, le test finit par mesurer sa pédagogie. Laissez au participant une possibilité de chercher, demandez-lui ce qu’il comprend et consignez toute aide donnée. Une intervention peut être nécessaire pour poursuivre la séance ; elle ne doit pas disparaître du compte rendu.
- Résultat observable : la tâche est-elle accomplie ? Distinguez réussite autonome, réussite avec aide et abandon.
- Point de rupture : notez l’écran, le libellé ou l’information qui a déclenché l’hésitation, plutôt qu’un jugement vague comme « manque de fluidité ».
- Compréhension : demandez ce que la personne pense avoir envoyé et ce qu’elle attend maintenant. Le clic final ne suffit pas si elle croit qu’un devis est accepté alors qu’il a seulement été reçu.
- Conditions : conservez la version du prototype, le scénario, le type de participant et les limites de simulation. Sans cela, une prochaine séance sera difficile à comparer.
Le temps passé peut compléter ces observations, à condition de conserver des tâches et des conditions comparables. Quelques séances qualitatives n’autorisent pas à annoncer un taux de réussite représentatif de tout le marché.
Comment transformer les observations en décision ?
Si le participant ne trouve pas l’action, commencez par le parcours ou le libellé. S’il comprend mais ne voit aucune raison de revenir, explorez la valeur du service et son besoin réel. S’il attend une confirmation que le prototype ne sait que simuler, ouvrez un chantier d’intégration. Ces trois constats ne justifient pas le même investissement.
Dans notre exemple, une demande envoyée sans statut lisible appelle d’abord une correction de l’interface. Réécrire tout le produit ne résoudrait pas nécessairement ce problème. À l’inverse, un bouton parfaitement compris ne valide pas le traitement de la demande dans le logiciel commercial.
Consignez ensuite chaque arbitrage avec sa preuve : observation, modification proposée, personne responsable et critère de vérification. Par exemple : « Après l’envoi, le participant doit pouvoir expliquer que sa demande attend une réponse, sans intervention de l’animateur. » Refaites le test sur la version corrigée au lieu de considérer la nouvelle maquette comme validée par défaut.
Quand passer du prototype à la V1 ?
Gardez trois preuves distinctes : utilisabilité — la personne comprend et agit ; valeur — elle accepte un engagement concret, à vérifier au-delà de cette séance ; exécution — les données et actions sont réellement traitées. Un test de parcours renseigne surtout la première. La volonté de payer demande une enquête ou une expérimentation commerciale adaptée ; la fiabilité exige des tests techniques.
Le MVP métier permet ensuite de tester une hypothèse dans un fonctionnement réel limité. Dans le Say Digital Framework, les observations du prototype alimentent les critères d’acceptation du développement. Les tests et le CI/CD — contrôles automatisés avant livraison — protègent ces critères, puis un déploiement contrôlé permet de mesurer l’usage réel.
Deux questions avant de lancer les séances
Faut-il un nombre universel de participants ?
Non. Le recrutement dépend des publics, des parcours et de la décision à prendre. Une première série peut révéler des blocages ; elle ne couvre pas automatiquement tous les profils, l’accessibilité ou la demande commerciale. Prévoyez de nouvelles séances après correction.
Un prototype IA doit-il déjà tout exécuter ?
Non, si la question porte sur la compréhension du parcours. Mais ses limites doivent être annoncées et notées. Pour vérifier un paiement, une notification ou une permission, il faut une preuve d’exécution supplémentaire, pas seulement un écran de succès.
Votre prochaine décision produit
Avant de financer davantage d’écrans, choisissez la tâche qui met votre promesse à l’épreuve. Say Digital peut cadrer ce test, préparer le prototype et traduire les observations en décisions de V1 : ce qui change, ce qui attend et ce qui exige une preuve technique.
Clarifier mon prototype IA avec Say Digital
Sources méthodologiques
- GOV.UK — Using moderated usability testing : tâches réalistes, observation, animation et limites des données fictives.
- GOV.UK — Learning about users and their needs : recherche auprès des utilisateurs et distinction entre besoins et hypothèses.
Sources consultées le 28 octobre 2026. Méthodes établies, non étude récente sur les performances de l’IA. Le portail de devis est un exemple illustratif, pas un résultat client.
