Planifiez des entretiens utilisateurs avec un prototype fonctionnel en 48 heures : recrutez rapidement, rédigez des scripts de tâches, prenez des notes et transformez les retours en demandes de construction claires.
01_Recruiting\n- 02_Recordings\n- 03_Notes\n- 04_Synthesis\n- 05_Tickets\n\nNommez 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.\n\n## Recruter rapidement sans trop y réfléchir\n\nLa 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.\n\nCommencez 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.\n\nRé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.\n\nSi 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.\n\nLes 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.\n\nEnfin, réservez des extras. Visez deux personnes de plus que nécessaire. Les no-shows arrivent, et des remplaçants préservent votre planning.\n\n## Filtrer, programmer et obtenir le consentement en une seule passe\n\nGagnez 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.\n\nUn screener léger peut se résumer à trois questions :\n\n- Que utilisez-vous actuellement pour résoudre ce problème (ou que faites-vous à la place) ?\n- Parlez-moi de la dernière fois où vous avez essayé de le faire. Que s'est-il passé ?\n- Laquelle de ces descriptions vous correspond le mieux : [vos rôles cibles], et pourquoi ?\n\nRepé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.\n\nPour 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é.\n\nLe 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.\n\nEnvoyez 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.\n\n## Préparer le prototype pour que les sessions ne déraillent pas\n\nUn 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.\n\nGardez 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.\n\nFaites 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.\n\nAvant 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.\n\nMettez 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).\n\nChoisissez 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.\n\n## Rédiger des scripts de tâches qui produisent des signaux clairs\n\nUn 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.\n\nCommencez 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.\n\n### Un script simple réutilisable\n\nUtilisez la même structure à chaque session pour que les résultats soient comparables :\n\n- Intro (1 min) : « Nous testons le produit, pas vous. Pensez à voix haute. »\n- Échauffement (2 min) : « Qu'attendriez-vous de ce produit ? »\n- Tâches (20–25 min) : 2 à 4 tâches, une à la fois.\n- Conclusion (3 min) : noter rapidement et demander une amélioration.\n\nRé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. »\n\nAprè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 ? »\n\nSi 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.\n\n## Mener les sessions et rester cohérent\n\nCommencez chaque session de la même façon. Cela réduit le stress et facilite la comparaison des résultats entre personnes.\n\nOuvrez 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.\n\nDonnez 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.\n\nQuand 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.\n\nLes 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.\n\nClô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.\n\n## Prendre des notes faciles à synthétiser ensuite\n\nDe 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.\n\n### Utilisez une feuille partagée pour tout le monde\n\nChoisissez 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 :\n\n- Horodatage (mm:ss) et ID participant\n- Numéro de tâche et écran sur lequel ils étaient\n- Ce qu'ils ont essayé, ce qu'ils attendaient, ce qui s'est passé\n- Une citation (uniquement quand elle compte)\n- Étiquette : sévérité (haut/moyen/faible) + type\n\nLes 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.\n\n### Capturez des preuves, pas des opinions\n\nQuand 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.\n\nExemple : « T2 06:14 : Cliqué sur ‘Enregistrer’ en s'attendant à une confirmation, mais rien n'a changé et il a demandé si cela avait fonctionné. »\n\nAjoutez 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.\n\nGardez les tags simples pour filtrer rapidement :\n\n- Sévérité : high (bloquant), med (ralentit), low (ennuyeux)\n- Type : confusion, confiance, manquant, bug\n\nSi 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é.\n\nRègle finale : si vous ne pouvez pas transformer une note en titre de ticket, réécrivez-la jusqu'à ce que vous puissiez.\n\n## Transformer les retours en demandes de construction précises\n\nLa 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.\n\nCommencez 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.\n\nUtilisez un format de demande cohérent pour que chaque problème soit comparable :\n\n- Problème : ce que l'utilisateur n'a pas pu faire (une phrase)\n- Preuve : observation ou citation exacte + où cela s'est produit\n- Impact : pourquoi c'est important (temps perdu, confusion, abandon, données erronées)\n- Changement proposé : ce qu'il faut modifier dans l'UI ou le flux\n- Critère d'acceptation : comment vérifier que c'est réglé lors du prochain test\n\nSé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.\n\nPuis 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).\n\nSi 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.\n\n## Exemple : cinq interviews transformées en cinq tickets actionnables\n\nUn 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.\n\nLe 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.\n\nChaque session utilise les mêmes trois tâches, lues mot pour mot :\n\n- Importer une petite liste de contacts (CSV ou copier-coller)\n- Créer un premier deal pour un contact et le déplacer à l'étape suivante\n- Planifier un rappel pour demain à 9:00\n\nSur 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.\n\nÀ la fin de la journée, ces observations deviennent des demandes de construction que l'on peut implémenter immédiatement :\n\n- 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.\n- Renommer “Rappel” en “Suivi” partout. Critère d'acceptation : étiquette mise à jour sur le bouton, le titre du modal et le message de confirmation.\n- 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.\n- 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.\n- 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.”\n\nC'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.\n\n## Pièges courants qui gaspillent vos entretiens\n\nLa plupart des mauvais résultats d'entretien viennent de quelques petites erreurs, pas du prototype lui-même.\n\n### Pièges qui embellissent les retours\n\nLes 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.\n\nTenter de tester trop de choses en une session crée des commentaires de surface et des signaux faibles. Choisissez 2 à 3 flux centraux.\n\nChanger le script en cours de route brise la comparabilité. Mettez les idées nouvelles dans un backlog et gardez les tâches stables.\n\nDes 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.\n\nUn 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.\n\n### Pièges lors de l'interprétation des résultats\n\nUne 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.\n\nSi 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.\n\n## Checklist rapide et prochaines étapes\n\nAvant de programmer le premier appel, verrouillez les bases :\n\n- Objectif pour ce cycle (une phrase)\n- Profil utilisateur cible (pour qui, et pour qui ce n'est pas)\n- Questions du screener + plan de recrutement\n- Script de tâches (2 à 4 tâches) + une question de suivi par tâche\n- Plan de réinitialisation du prototype (état initial, données de test)\n- Méthode d'enregistrement (et plan B) et texte de consentement\n- Modèle de notes (problèmes, citations, sévérité, preuve)\n\nJuste 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.\n\nLe 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.\n\n### Wrap-up le jour même (20 minutes)\n\n- Motifs : ce que vous avez vu au moins deux fois\n- Priorités : sélectionnez les trois premiers correctifs\n- Prochaines étapes de construction : rédigez le plus petit changement possible qui pourrait résoudre chaque problème\n\nPuis 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é.\n\nSi 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.Visez 3 à 5 sessions. Trois sessions révèlent généralement les principaux blocages, et cinq suffisent souvent pour confirmer des motifs récurrents. Arrêtez plus tôt si les mêmes deux problèmes principaux se répètent lors de trois sessions consécutives, puis repartez sur la construction et le re-test.
Utilisez une phrase qui nomme l'utilisateur, la tâche et un seuil mesurable. Un bon format : “Un·e premier·ère utilisateur·rice [type] peut-il/elle réaliser [tâche] en moins de [temps] sans aide ?” Cela garde la session centrée sur un comportement observable.
Choisissez 2 à 4 tâches qui représentent les moments les plus importants d'un même flux, comme la configuration initiale et l'accomplissement d'une action significative. Gardez les tâches orientées résultat pour tester si les gens peuvent réussir, pas s'ils peuvent trouver un nom de bouton précis.
Commencez par les sources les plus rapides : personnes déjà proches du produit comme les utilisateurs en essai, la liste d'attente, des conversations récentes de support ou des demandes de démo. Rédigez une invitation courte, précisez que ce n'est pas un appel commercial et proposez deux créneaux concrets (aujourd'hui ou demain) pour réduire les échanges.
Posez trois questions rapides : ce qu'ils utilisent aujourd'hui, ce qui s'est passé la dernière fois qu'ils ont fait la tâche, et quel rôle les décrit le mieux (et pourquoi). Évitez les personnes trop éloignées de votre cible, trop investies (amis proches, concurrents) ou trop occupées pour être attentives.
Demandez la permission d'enregistrer, expliquez l'usage des enregistrements et des notes (améliorer le produit), et promettez d'anonymiser les citations si vous partagez les résultats. Offrez une option simple pour refuser l'enregistrement : vous prendrez des notes à la place.
Limitez le prototype aux écrans nécessaires pour vos tâches et rendez le contenu crédible afin que les utilisateurs réagissent naturellement. Créez un compte test dédié et une routine de remise à zéro pour que chaque participant parte du même état, ce qui rend les résultats comparables.
Démarrez chaque session de la même manière : même introduction, mêmes tâches, et gardez le silence pendant qu'ils travaillent. Posez des questions neutres comme « Que cherchez-vous en ce moment ? » et évitez d'enseigner ou de défendre le design, car cela masque les vrais échecs du produit.
Écrivez des notes courtes et cohérentes par tentative de tâche : ce qu'ils ont essayé, ce à quoi ils s'attendaient et ce qui s'est passé, plus une citation quand elle compte. Ajoutez une étiquette de sévérité simple (bloquant, ralentit, mineur) pour prioriser rapidement tant que les preuves sont fraîches.
Transformez chaque problème récurrent en une demande de construction avec cinq parties : le problème (une phrase), la preuve (observation exacte ou citation + emplacement), l'impact (temps perdu, confusion, abandon), le changement proposé (UI ou flux) et un critère d'acceptation simple vérifiable lors du prochain test. Regroupez les problèmes par tâche plutôt que par participant.