Entretiens utilisateurs avec un prototype fonctionnel en 48 heures

Ce que vous pouvez apprendre en 48 heures

Un prototype fonctionnel met fin à la plupart des débats rapidement. Quand quelqu'un essaie d'accomplir une vraie tâche, vous arrêtez de deviner ce qu'il ferait et commencez à voir ce qu'il fait réellement. C'est pourquoi les entretiens utilisateurs avec un prototype fonctionnel surpassent les débats en chat, même si le prototype est rudimentaire.

Avec 3 à 6 sessions, vous pouvez apprendre beaucoup si vous maintenez le périmètre restreint. Vous n'obtiendrez pas des statistiques parfaites, mais vous verrez des motifs répétés que vous pouvez corriger cette semaine.

En 48 heures, vous pouvez de manière fiable identifier où les gens se coincent ou reviennent en arrière, quels libellés les confondent, ce qu'ils essaient en premier (et ce qu'ils ignorent), ce qui manque avant qu'ils ne fassent confiance au flux, et quels moments génèrent du doute — comme le prix, les autorisations ou l'enregistrement de la progression.

Cette approche évite les gros projets de recherche, les longues enquêtes et les pêches en eaux troubles. Vous ne cherchez pas à cartographier tout le marché. Vous cherchez à supprimer la plus grande friction dans un flux important.

Définissez un objectif d'apprentissage unique avant de programmer qui que ce soit. Un format simple marche bien : « Un·e premier·ère utilisateur·rice peut-il/elle faire X en moins de Y minutes sans aide ? » Si vous construisez un CRM simple, cela pourrait être : « Un nouvel utilisateur peut-il ajouter un contact, le taguer et le retrouver ? »

Si vous avez construit rapidement votre prototype dans un outil comme Koder.ai, l'objectif reste le même : choisissez un flux, regardez de vraies personnes l'essayer, et capturez exactement ce qu'il faut changer.

Définir un objectif étroit (pour garder les entretiens concentrés)

Un cycle de 48 heures ne fonctionne que si vous réduisez le périmètre. Choisissez un type d'utilisateur spécifique et un scénario qu'il comprend déjà. Si vous essayez de couvrir l'onboarding, la tarification, les paramètres et les cas limites dans la même session, vous finirez avec des opinions plutôt qu'avec des preuves.

Rédigez un objectif en une phrase comme : « Un·e designer freelance débutant·e peut-il/elle créer une facture et l'envoyer en moins de 3 minutes sans aide ? » Cette phrase dit qui est la personne, ce qu'elle doit faire et à quoi ressemble le « bon » résultat.

Choisir un signal de succès observable

Décidez de ce que vous mesurerez avant de parler à qui que ce soit. Gardez-le simple et visible pendant la session. Pour la plupart des équipes, c'est un mélange de rapidité (temps d'exécution), friction (combien de fois ils se bloquent ou demandent « et maintenant ? »), problèmes de navigation (hésitations, relectures, retours en arrière) et signaux de confiance (inquiétude au sujet du paiement, de la confidentialité ou des erreurs).

Puis rédigez 3 à 5 questions auxquelles vous devez répondre à la fin du cycle. Exemples :

• Où les gens s'attendent-ils à commencer ce flux ?
• Quel écran provoque la première vraie confusion ?
• Quel libellé les met mal à l'aise ?
• Qu'essaient-ils qui n'est pas supporté par le prototype ?
• Qu'est-ce qui leur ferait dire « oui, j'utiliserais ça » ?

Définir une règle d'arrêt

Ne continuez pas les entretiens simplement parce que vous le pouvez. Décidez à l'avance quand arrêter pour pouvoir revenir à la construction. Une règle pratique : arrêter après cinq sessions, ou plus tôt si les deux mêmes problèmes principaux se répètent pendant trois sessions consécutives.

Exemple : si trois participants sur cinq ne trouvent pas « Créer une facture » parce qu'il est caché sous « Facturation », vous avez déjà une demande de construction claire : renommer le libellé, déplacer le point d'entrée et retester ce changement unique.

Le planning sur 48 heures (simple et réaliste)

Vous pouvez mener des entretiens utiles avec un prototype fonctionnel en deux jours si vous le traitez comme un mini-sprint : recruter, préparer, exécuter, puis synthétiser tant que les détails sont frais. Visez 3 à 5 sessions. Trois est le minimum pour repérer les plus gros problèmes. Cinq montre généralement des motifs.

Un plan réaliste ressemble à ceci :

• Heures 0–4 : Rédigez votre objectif en une phrase, choisissez 2 à 4 tâches, rédigez un bref message d'invitation et commencez le recrutement.
• Heures 4–12 : Réservez les créneaux, confirmez l'adéquation, obtenez le consentement et faites une vérification rapide du prototype pour que les bugs évidents ne gâchent pas la session.
• Heures 12–24 : Réalisez deux sessions. Juste après chacune, écrivez un résumé de cinq minutes : ce qu'ils ont tenté, où ils ont hésité, ce qu'ils attendaient.
• Heures 24–36 : Réalisez une à trois sessions supplémentaires. Gardez le script et la configuration identiques pour que les résultats puissent être comparés.
• Heures 36–48 : Synthétisez. Regroupez les notes par thèmes, choisissez les trois principaux problèmes et transformez-les en demandes de construction.

Si le recrutement est lent, n'attendez pas. Réduisez le périmètre et élargissez la disponibilité. Proposez plus de créneaux (matin tôt ou soirée), raccourcissez les sessions à 15 minutes, ou recrutez dans un cercle proche correspondant toujours à votre type d'utilisateur.

Pour rester organisé, mettez en place un petit système de dossiers avant le premier appel :

• 01_Recruiting
• 02_Recordings
• 03_Notes
• 04_Synthesis
• 05_Tickets

Nommez les fichiers comme P01_2026-01-16_Record.mp4 et P01_Notes.md. Cette petite habitude facilite la relecture des tests d'utilisabilité du prototype.

Recruter rapidement sans trop y réfléchir

La rapidité compte plus que la perfection. Votre but n'est pas un échantillon statistique parfait. C'est 5 à 8 personnes réelles qui correspondent grosso modo aux utilisateurs visés, réservées en une journée.

Commencez par les viviers les plus rapides, puis élargissez. Débutez par les personnes qui demandent déjà le produit (clients, utilisateurs en essai, liste d'attente), puis passez aux conversations récentes (tickets support, demandes de démo, réponses par e-mail). Si vous avez besoin de plus, cherchez des communautés où le problème est discuté, demandez des introductions via des amis de confiance (pas des avis), et contactez d'anciens collègues ou clients ayant le même flux de travail.

Rédigez l'invitation courte et précise. Précisez bien que ce n'est pas un appel commercial et que vous testez le produit, pas la personne. Indiquez ce que vous construisez et pour qui, la demande (20 minutes en visio ou audio), ce qu'ils feront (essayer 2 à 3 tâches sur un prototype), et un petit remerciement comme une carte cadeau, un mois gratuit ou un don. Proposez deux créneaux aujourd'hui ou demain.

Si vous avez construit un prototype CRM interne rapide (par exemple dans Koder.ai) pour freelances, invitez à la fois des utilisateurs « tableur en bazar » et des personnes déjà sur un CRM. Ce mélange évite de n'avoir que des retours de power users. Et évitez de ne solliciter que des amis proches : ils auront tendance à être indulgents.

Les incitations doivent sembler normales, pas gênantes. Un petit montant fixe marche mieux que « payez ce que vous voulez ». Si vous offrez un mois gratuit, assurez-vous qu'il ne nécessite aucun achat.

Enfin, réservez des extras. Visez deux personnes de plus que nécessaire. Les no-shows arrivent, et des remplaçants préservent votre planning.

Filtrer, programmer et obtenir le consentement en une seule passe

Gagnez des heures en traitant le screening, la planification et le consentement comme un seul flux rapide. Confirmez qu'ils ressemblent à votre utilisateur réel, réservez un créneau, et précisez l'enregistrement et la prise de notes avant la première rencontre.

Un screener léger peut se résumer à trois questions :

• Que utilisez-vous actuellement pour résoudre ce problème (ou que faites-vous à la place) ?
• Parlez-moi de la dernière fois où vous avez essayé de le faire. Que s'est-il passé ?
• Laquelle de ces descriptions vous correspond le mieux : [vos rôles cibles], et pourquoi ?

Repérez les signaux d'alerte qui gaspillent des sessions. Les personnes éloignées de votre cible donneront des retours confiants mais non pertinents. Les personnes trop investies (ami proche, associé, concurrent) ont tendance à pousser un agenda personnel. Les personnes trop occupées vont se précipiter, faire plusieurs choses à la fois ou ne pas se présenter.

Pour la programmation, gardez un format serré : sessions de 30 minutes avec un tampon de 15 minutes. Le tampon sert à rédiger des notes propres, nommer les enregistrements et réinitialiser le prototype. Si vous enchaînez les appels, vos notes deviennent bâclées et les motifs passent à côté.

Le consentement peut être un court message : demandez la permission d'enregistrer, expliquez que les notes serviront à améliorer le produit, et précisez que les citations seront anonymisées si partagées. Offrez une option simple : ils peuvent refuser l'enregistrement et vous prendrez des notes à la place.

Envoyez un message pré-appel simple avec l'heure, la durée prévue, l'agenda (5 minutes d'intro, 20 minutes de tâches, 5 minutes de conclusion) et ce dont ils ont besoin (ordinateur vs téléphone, connexion si nécessaire, endroit calme). Cela évite les surprises du type « je me suis connecté depuis mon mobile » qui font dérailler les tests d'utilisabilité de prototype.

Préparer le prototype pour que les sessions ne déraillent pas

Un bon entretien peut quand même échouer si le prototype est brouillon. L'objectif n'est pas d'impressionner par l'étendue. C'est de faciliter la tentative des tâches sans impasses ni explications de votre part.

Gardez le prototype petit. Incluez uniquement les écrans et chemins nécessaires aux tâches, et masquez tout le reste. Un chemin plus court bat une “application complète” à moitié finie.

Faites en sorte que le contenu paraisse réel. Remplacez le lorem ipsum par des textes et des données crédibles pour que les utilisateurs réagissent naturellement. Si vous testez un flux CRM, affichez 6 à 10 contacts avec noms, entreprises et quelques notes. Si vous testez un paiement, utilisez des prix et des options de livraison réalistes. Fake mais spécifique vaut mieux que générique.

Avant les sessions, décidez de ce que vous observerez et notez-le à chaque fois : où ils cliquent en premier, moments de confusion (ce qu'ils disent et ce qu'ils font ensuite), où ils bouclent ou reviennent en arrière, les mots qu'ils utilisent pour désigner des fonctions, et les questions révélant des informations manquantes.

Mettez en place un compte test dédié et une routine de réinitialisation pour que chaque participant parte du même état. Si le prototype crée des enregistrements, gardez une checklist de remise à zéro courte (vider le panier, supprimer le dernier élément créé, revenir à l'écran d'accueil, se déconnecter et reconnecter).

Choisissez vos outils de capture avant de parler à qui que ce soit. Enregistrez l'appel si possible et conservez un modèle de notes simple avec trois colonnes : Tâche, Observations (ce qui s'est passé) et Citations (mots exacts). Si vous utilisez Koder.ai, faire un snapshot avant la première session facilite le retour en arrière si vous modifiez quelque chose par accident en cours de journée.

Rédiger des scripts de tâches qui produisent des signaux clairs

Un bon script de tâche fait agir les gens comme dans la vraie vie, pas comme s'ils passaient un test. Gardez-le court, reproductible et lié à un scénario principal. Pour un prototype fonctionnel, 2 à 4 tâches suffisent généralement pour repérer des motifs sans précipitation.

Commencez par nommer le scénario principal en termes simples (par exemple : « Je veux configurer mon premier projet et inviter un·e coéquipier·e »). Ensuite, choisissez des tâches qui représentent les moments où l'échec ferait le plus de mal : configuration initiale, trouver une fonction clé et accomplir une action significative.

Un script simple réutilisable

Utilisez la même structure à chaque session pour que les résultats soient comparables :

• Intro (1 min) : « Nous testons le produit, pas vous. Pensez à voix haute. »
• Échauffement (2 min) : « Qu'attendriez-vous de ce produit ? »
• Tâches (20–25 min) : 2 à 4 tâches, une à la fois.
• Conclusion (3 min) : noter rapidement et demander une amélioration.

Rédigez chaque consigne de tâche sans révéler le nom du bouton ni le chemin exact. Mauvais : « Cliquez sur Snapshots et restaurez. » Mieux : « Vous avez fait une erreur et souhaitez revenir à la version d'hier. Montrez-moi ce que vous feriez. »

Après chaque tâche, posez une question courte. Avant qu'ils cliquent : « Où commenceriez-vous ? » Après : « Qu'est-ce qui vous a fait choisir cette voie ? » S'ils sont bloqués, demandez « Que cherchez-vous en ce moment ? » plutôt que « Avez-vous vu le menu ? »

Si vous avez construit le prototype dans Koder.ai, gardez les tâches ancrées sur des résultats (créer une app, exporter le code source, définir un domaine personnalisé) plutôt que sur des termes de plateforme. Ainsi, vos notes se traduisent proprement en demandes de développement.

Mener les sessions et rester cohérent

Commencez chaque session de la même façon. Cela réduit le stress et facilite la comparaison des résultats entre personnes.

Ouvrez avec un script bref : remerciez-les, expliquez que vous testez le produit (pas eux), et qu'il n'y a pas de mauvaises réponses. Demandez-leur de penser à voix haute et de partager ce qu'ils anticipent avant de cliquer.

Donnez une tâche à la fois, puis restez silencieux. Votre rôle principal est d'observer où ils hésitent et de poser de courtes questions neutres comme « À quoi pensez-vous ? » et « Qu'espériez-vous voir ? » Évitez d'enseigner, de féliciter ou de défendre le prototype.

Quand ils sont bloqués, incitez-les avant de les dépanner. Une bonne incitation porte sur leur objectif, pas sur l'interface : « Que tenteriez-vous ensuite ? » ou « Où chercheriez-vous cela ? » S'ils restent bloqués plus d'une minute, passez à la suite et notez-le comme un problème de haute sévérité. Résistez à l'envie de corriger le prototype pendant l'appel. Capturez le problème et poursuivez la session.

Les demandes de fonctionnalités sont utiles, mais ne les débattez pas. Mettez-les de côté avec une question : « Quel problème cela résoudrait-il pour vous ? » Puis revenez à la tâche en cours.

Clôturez aussi de manière cohérente. Demandez ce qu'ils ont aimé, ce qui les a frustrés, s'ils paieraient (et quel prix leur semblerait juste), et si vous pouvez les recontacter après la prochaine mise à jour.

Prendre des notes faciles à synthétiser ensuite

De bonnes notes ne sont pas « tout ce qui s'est passé ». Ce sont de petites unités cohérentes que vous pouvez trier ensuite. Si vous gardez la même structure entre les sessions, les motifs apparaissent après la troisième interview.

Utilisez une feuille partagée pour tout le monde

Choisissez un document de notes ou un tableur unique que tous les observateurs utilisent. Créez une ligne par tentative de tâche et rédigez des notes courtes et factuelles aux mêmes endroits à chaque fois. Une mise en page simple :

• Horodatage (mm:ss) et ID participant
• Numéro de tâche et écran sur lequel ils étaient
• Ce qu'ils ont essayé, ce qu'ils attendaient, ce qui s'est passé
• Une citation (uniquement quand elle compte)
• Étiquette : sévérité (haut/moyen/faible) + type

Les horodatages permettent de revenir aux enregistrements et de vérifier les formulations. Les numéros de tâche évitent de mélanger des problèmes entre flux.

Capturez des preuves, pas des opinions

Quand quelque chose tourne mal, écrivez-le comme une phrase simple qu'un·e collègue peut comprendre hors contexte. Décrivez le moment, pas votre interprétation.

Exemple : « T2 06:14 : Cliqué sur ‘Enregistrer’ en s'attendant à une confirmation, mais rien n'a changé et il a demandé si cela avait fonctionné. »

Ajoutez une citation quand elle renforce le point, surtout pour des problèmes de confiance ou de confusion (« Je ne suis pas sûr que ce soit sécurisé » ou « Par où commencer ? »). Les citations facilitent la priorisation car elles montrent l'impact.

Gardez les tags simples pour filtrer rapidement :

• Sévérité : high (bloquant), med (ralentit), low (ennuyeux)
• Type : confusion, confiance, manquant, bug

Si votre prototype a été créé dans Koder.ai, concentrez les notes sur le comportement utilisateur et le comportement produit, pas sur la façon dont le prototype a été généré.

Règle finale : si vous ne pouvez pas transformer une note en titre de ticket, réécrivez-la jusqu'à ce que vous puissiez.

Transformer les retours en demandes de construction précises

La façon la plus rapide de perdre de l'élan est de laisser les retours sous forme de citations et d'impressions. Transformez ce que vous avez vu en demandes de construction qu'un·e développeur·se peut exécuter sans deviner.

Commencez par regrouper les problèmes par tâche, pas par personne. Si trois personnes ont eu des difficultés pendant « créer un compte », c'est un seul problème avec plusieurs points de données, pas trois avis séparés.

Utilisez un format de demande cohérent pour que chaque problème soit comparable :

• Problème : ce que l'utilisateur n'a pas pu faire (une phrase)
• Preuve : observation ou citation exacte + où cela s'est produit
• Impact : pourquoi c'est important (temps perdu, confusion, abandon, données erronées)
• Changement proposé : ce qu'il faut modifier dans l'UI ou le flux
• Critère d'acceptation : comment vérifier que c'est réglé lors du prochain test

Séparez les correctifs de « formulation et clarté » des changements de « périmètre ». « Je ne sais pas ce que fait ce bouton » est souvent une correction d'étiquette ou de placement. « J'ai besoin d'exports, de rôles et d'approbations » est une décision produit plus lourde. Les mélanger crée des tickets gonflés.

Puis décidez pour chaque problème : corriger maintenant, retester, ou mettre en pause. Une méthode simple consiste à attribuer impact utilisateur, effort, confiance (s'est-ce répété ?) et action suivante (build, re-test, park).

Si vous travaillez dans Koder.ai, rédigez le critère d'acceptation en anglais clair pour pouvoir le coller dans votre chat de construction comme instruction testable.

Exemple : cinq interviews transformées en cinq tickets actionnables

Un fondateur non technique construit un simple onboarding CRM dans Koder.ai, puis réalise des entretiens le lendemain. L'objectif est étroit : un·e commercial·e peut-il/elle atteindre « premier deal créé » sans aide.

Le recrutement est rapide : il contacte son réseau et quelques communautés locales de vente, en offrant une petite carte cadeau. Cinq commerciaux réservent des créneaux de 20 minutes dans l'après-midi.

Chaque session utilise les mêmes trois tâches, lues mot pour mot :

• Importer une petite liste de contacts (CSV ou copier-coller)
• Créer un premier deal pour un contact et le déplacer à l'étape suivante
• Planifier un rappel pour demain à 9:00

Sur cinq sessions, ils enregistrent des problèmes répétés et quelques blocages. Deux commerciaux ne trouvent pas où importer. Trois pensent que « Rappel » est un paramètre de notification, pas un suivi.

À la fin de la journée, ces observations deviennent des demandes de construction que l'on peut implémenter immédiatement :

• Ajouter un bouton “Importer des contacts” dans l'état vide. Critère d'acceptation : visible sur l'écran initial ; prend en charge l'upload CSV et le copier-coller.
• Renommer “Rappel” en “Suivi” partout. Critère d'acceptation : étiquette mise à jour sur le bouton, le titre du modal et le message de confirmation.
• Auto-créer un pipeline par défaut avec trois étapes. Critère d'acceptation : nouveau compte avec “New, Contacted, Won” ; l'utilisateur peut modifier ensuite.
• Ajouter un texte d'aide en ligne sur le formulaire “Créer un deal”. Critère d'acceptation : une phrase sous “Nom du deal” avec un exemple ; réduit les soumissions vides.
• Afficher une bannière de succès avec une étape suivante après chaque tâche. Critère d'acceptation : après un import, suggérer “Créez votre premier deal” ; après un deal, suggérer “Planifier un suivi.”

C'est l'idée : tâches cohérentes, motifs répétés et tickets rédigés si clairement qu'ils peuvent être construits le jour même.

Pièges courants qui gaspillent vos entretiens

La plupart des mauvais résultats d'entretien viennent de quelques petites erreurs, pas du prototype lui-même.

Pièges qui embellissent les retours

Les questions suggestives comme « Ça a du sens, non ? » obtiennent des accords polis. Utilisez des formulations neutres comme « Que pensez-vous que cela fait ? » puis restez silencieux.

Tenter de tester trop de choses en une session crée des commentaires de surface et des signaux faibles. Choisissez 2 à 3 flux centraux.

Changer le script en cours de route brise la comparabilité. Mettez les idées nouvelles dans un backlog et gardez les tâches stables.

Des notes brouillonnes sont un autre échec silencieux. Si vous vous fiez à la mémoire, vous vous souviendrez des moments drôles, pas des moments douloureux. Notez l'étape exacte où ils se sont bloqués et ce qu'ils ont essayé ensuite.

Un simple test de réalité : si un participant dit « Ça a l'air bien » mais met 90 secondes à trouver le bouton suivant, ce sont leurs actions qui constituent les données. Le compliment est du bruit.

Pièges lors de l'interprétation des résultats

Une opinion forte peut devenir le plan. Traitez les avis marqués comme des hypothèses tant que vous ne voyez pas le même problème dans plusieurs sessions.

Si vous effectuez de grandes modifications, re-testez rapidement. Même deux courtes sessions peuvent confirmer que vous avez corrigé le problème au lieu de le déplacer.

Checklist rapide et prochaines étapes

Avant de programmer le premier appel, verrouillez les bases :

• Objectif pour ce cycle (une phrase)
• Profil utilisateur cible (pour qui, et pour qui ce n'est pas)
• Questions du screener + plan de recrutement
• Script de tâches (2 à 4 tâches) + une question de suivi par tâche
• Plan de réinitialisation du prototype (état initial, données de test)
• Méthode d'enregistrement (et plan B) et texte de consentement
• Modèle de notes (problèmes, citations, sévérité, preuve)

Juste après chaque session, faites une vérification de trois minutes tant que c'est encore frais : notez vos trois principaux problèmes et une surprise. Si vous ne pouvez pas les nommer, vos tâches sont peut-être trop larges ou vos notes trop vagues.

Le même jour, faites un court wrap-up qui transforme les notes brutes en décisions. Regroupez les problèmes similaires, choisissez ce qui importe le plus et définissez ce que vous changerez ensuite.

Wrap-up le jour même (20 minutes)

• Motifs : ce que vous avez vu au moins deux fois
• Priorités : sélectionnez les trois premiers correctifs
• Prochaines étapes de construction : rédigez le plus petit changement possible qui pourrait résoudre chaque problème

Puis planifiez un re-test dans les 72 heures après le déploiement des corrections. Même trois sessions rapides peuvent confirmer si le changement a fonctionné.

Si vous itérez dans Koder.ai (koder.ai), Planning Mode peut vous aider à reformuler les conclusions en tâches cadrées (« Changer X pour que l'utilisateur puisse faire Y sans Z »), et les snapshots facilitent l'essai de corrections rapides sans perdre une version stable.