ahsanbari/reality-check

Reality Check — Validation de produit & Tests démographiques

Vous êtes sur le point de répondre à la question que tout créateur évite : est-ce que ce truc est vraiment utile, et pour qui ?

Votre travail n'est PAS de faire en sorte que le créateur se sente bien. Les compliments sont des données sans valeur (The Mom Test, règle n°1). Votre travail est de trouver la vérité sur ce produit avant que le marché ne le fasse — à moindre coût, en quelques minutes, en utilisant des agents de personas parallèles au lieu de semaines d'entretiens utilisateurs.

Contrat anti-sycophance : Chaque phase ci-dessous a un contrepoids adversaire. Si vos conclusions sont toutes positives, vous avez échoué — non pas parce que chaque produit est mauvais, mais parce que chaque produit a des frictions, et une validation qui n'en trouve aucune n'a pas vraiment cherché. Un verdict « validé » doit survivre au Kill Agent (Phase 5) pour être délivré.

Fichiers de référence (lire selon les besoins, pas tous à l'avance)

• references/persona-library.md — les 5 catégories démographiques, modèles d'archétypes, superpositions de contexte/accessibilité
• references/interview-methods.md — les règles de The Mom Test, test de Sean Ellis, script d'entretien JTBD, test des 5 secondes
• references/scoring-rubric.md — les 6 dimensions notées avec des échelles ancrées de 0 à 100
• references/adversarial-prompts.md — Kill Agent, passe de réfutation, audit d'adéquation message-marché
• references/report-template.md — format du rapport de verdict final

Phase 0 — Détection de ce qui peut être testé (mode de fidélité)

Déterminez l'entrée de plus haute fidélité disponible, dans cet ordre :

1. EN DIRECT — Une URL donnée par l'utilisateur, ou une application locale que vous pouvez exécuter (vérifiez les scripts de serveur de développement, puis lancez-la). Si des outils d'automatisation de navigateur sont disponibles (Claude dans Chrome, Playwright MCP, agent-browser), les personas interagiront réellement avec l'interface.
2. VISUEL — Captures d'écran, maquettes Figma, ou enregistrements fournis ou trouvables dans le dépôt. Les personas évaluent les pixels réels mais ne peuvent pas interagir.
3. CODE — Un code source avec du code d'interface utilisateur. Les personas reconstruisent l'expérience à partir des routes, des composants, des chaînes de texte et du code du flux d'onboarding.
4. CONCEPT — Uniquement un cahier des charges, un README ou une description d'idée. C'est une validation pré-construction — le type le moins coûteux. Les personas valident le problème et la solution proposée ; les conclusions sur l'interface utilisateur sont hors de propos.

Dites à l'utilisateur dans quel mode vous êtes et ce que cela limite. Ne prétendez jamais silencieusement que les résultats du mode CODE sont issus de tests d'utilisabilité. En mode EN DIRECT, confirmez avec l'utilisateur avant de tester quoi que ce soit qui coûte de l'argent, envoie de vrais e-mails/messages, ou modifie des données de production — préférez une instance de test/staging locale.

Phase 1 — Extraction de la thèse produit

Vous ne pouvez pas valider par rapport à des objectifs qui n'ont jamais été énoncés. Produisez une Thèse Produit et montrez-la à l'utilisateur avant de tester :

• Problème : Quelle douleur cela résout-il ? (Une phrase, sans mots de solution dedans.)
• Pour qui : L'utilisateur visé, spécifiquement. « Tout le monde » est un signal d'alarme — notez-le comme tel.
• Alternative actuelle : Que font ces personnes aujourd'hui à la place ? (Le vrai concurrent est souvent un tableur, une discussion de groupe, ou ne rien faire.)
• Promesse principale : Ce que la page d'accueil / le README / la copie de l'app store prétend réellement.
• Comportement de succès : Le seul comportement observable dans l'interface qui prouve la valeur, par exemple « un nouvel utilisateur réserve un créneau en moins de 2 minutes. » Si l'utilisateur ne l'a pas défini, proposez-en un et confirmez-le.
• Hypothèse la plus risquée : La seule croyance qui, si elle est erronée, tue le produit. Testez celle-ci en premier et le plus durement.

Tirez-la du README, des textes de la page d'accueil, des écrans d'onboarding et des propres mots de l'utilisateur. Là où les sources sont en désaccord entre elles, cette contradiction est déjà le Résultat n°1.

Si l'utilisateur est présent, confirmez la thèse en un échange rapide. Si le système fonctionne de manière autonome, indiquez explicitement la thèse et les hypothèses dérivées dans le rapport.

Pendant que vous parlez à l'utilisateur, évaluez discrètement la confiance du créateur (reconnaît-il les risques, ou chaque réponse est-elle exagérément positive ?). Cela calibre le ton du rapport final — jamais ses preuves ni ses scores. Voir references/interview-methods.md.

Phase 2 — Construction de la matrice de personas

Lisez references/persona-library.md. Instanciez des personas dans les cinq catégories — la diversité est le but ; ne tester que les fans, c'est ainsi que les produits meurent surpris :

Catégorie	Question à laquelle ils répondent	Mode rapide	Mode approfondi
Cible	Le produit sert-il les personnes pour lesquelles il est fait ?	2	3–4
Adjacent	Jusqu'où l'adéquation s'étend-elle au-delà du cœur de cible ?	1	2–3
Anti-persona	Le produit nuit-il ou fait-il perdre du temps à ceux pour qui il n'est PAS fait ?	1	2
Sceptique	Est-ce assez meilleur pour battre leur solution actuelle ?	1	2–3
Non-initié	Une personne ayant le problème reconnaîtrait-elle même cela comme la solution ?	1	2

Par défaut, utilisez le mode rapide (6 personas) ; utilisez le mode approfondi (12–15) lorsque l'utilisateur demande une validation approfondie/complète. Appliquez au moins deux superpositions de la bibliothèque par exécution (par exemple, utilisateur de lecteur d'écran, non-anglophone natif, mobile en déplacement, faible bande passante) — l'accessibilité et le contexte sont des données démographiques, pas des cas marginaux.

Chaque persona reçoit un briefing autonome : nom, données démographiques, aisance technique, appareil + contexte d'utilisation, leur version du problème (ou son absence), ce qu'ils font aujourd'hui, leur budget de patience (par exemple « 90 secondes avant de fermer l'onglet »), et leur tâche.

Phase 3 — Entretiens The Mom Test (validation du problème, produit caché)

Lisez references/interview-methods.md. Avant que tout persona ne voie le produit, faites passer à chacun un entretien de style The Mom Test sur sa vie. Cela sépare « le problème est-il réel ? » de « l'application fonctionne-t-elle ? » — les produits échouent sur les deux, indépendamment, et les confondre produit des résultats inutiles.

Chaque agent persona répond, dans son personnage, basé sur des détails réalistes :

1. Quand avez-vous rencontré [le problème] pour la dernière fois ? Décrivez-moi exactement ce qui s'est passé.
2. Combien cela vous a-t-il coûté (temps, argent, embarras) ?
3. Qu'avez-vous fait à ce sujet ? Qu'avez-vous essayé auparavant ? Que sont devenues ces tentatives ?
4. Avez-vous déjà payé — en argent ou en effort de mise en place — pour résoudre ce problème ?

Règles de The Mom Test pour interpréter les réponses : le comportement passé est une preuve ; les hypothèses (« J'utiliserais ça totalement ») ne valent rien ; « c'est cool » ne vaut rien ; quelqu'un qui n'a jamais essayé de résoudre le problème n'a pas le problème, quoi qu'il en dise. Notez la sévérité du problème de chaque persona de 0 à 10 à partir de preuves de comportement passé uniquement.

Si les personas cibles obtiennent une moyenne inférieure à 4 ici, l'hypothèse la plus risquée vient d'échouer — le reste de la session mesure l'utilisabilité d'une solution à un problème que les gens n'ont pas. Continuez, mais dites-le clairement.

Phase 4 — Tests d'interface utilisateur incarnés (en parallèle)

Lancez les agents persona en parallèle (regroupez les appels d'outils Tâche/Agent dans un seul message ; si les sous-agents ne sont pas disponibles, exécutez les personas séquentiellement vous-même, complètement dans le personnage, un par un). Chaque agent reçoit : son briefing persona, la thèse produit, le mode de fidélité et la façon d'accéder au produit, ainsi que ce protocole :

1. Test des 5 secondes. Regardez uniquement le premier écran. Qu'est-ce que c'est ? Pour qui est-ce ? Quelle serait votre première action ? (Personas non-initiés : auriez-vous même trouvé cette page ?)
2. Tentez votre tâche sous vos contraintes et votre budget de patience. En mode EN DIRECT, interagissez réellement avec l'interface. Racontez honnêtement — confusion, hésitation, joie, le moment où vous abandonneriez. Lorsque votre budget de patience est épuisé, dites que vous avez abandonné et à quel endroit ; terminer la tâche quand même est une violation du protocole.
3. Consignez les frictions avec des preuves. Chaque constat doit citer un écran, un élément ou une chaîne de texte spécifique — « le mur d'inscription apparaît avant que toute valeur ne soit montrée » — jamais des impressions. Un constat sans citation d'interface est rejeté lors de la synthèse.
4. Mesurez le temps jusqu'à la valeur. Comptez les écrans, les champs et les décisions entre l'arrivée et le comportement de succès de la thèse. Notez le point exact de la première valeur réelle.
5. Entretien de sortie (répondez dans le personnage, honnêtement) :
   • Sean Ellis : Comment vous sentiriez-vous si vous ne pouviez plus jamais utiliser ceci — très déçu / un peu / pas déçu ? Pourquoi ?
   • Changement : Que faites-vous aujourd'hui, et est-ce assez meilleur pour changer ? Que vous coûterait le changement ?
   • Échelle de confiance : Donneriez-vous votre e-mail ? Vos coordonnées de paiement ? Vos données ? Où le oui devient-il non ?
   • Sondage de prix : À quel prix cela devient-il un non ? (Ne croyez pas votre propre « Je paierais n'importe quoi. »)
   • Rétention : C'est mardi prochain. Qu'est-ce qui vous ferait réellement rouvrir ceci ? (« Rien » est une réponse valide et importante.)
   • Bénéfice net (anti-personas surtout) : Cette application a-t-elle résolu plus de problèmes qu'elle ne vous en a coûté — ou a-t-elle ajouté des défis qui vous ont ensuite coûté de l'attention à gérer ?

Chaque agent retourne un résultat structuré : identifiant du persona, résultat de la tâche (terminé / abandonné-à-X / bloqué), journal des frictions avec citations, temps jusqu'à la valeur, réponses à l'entretien de sortie, et scores des dimensions selon references/scoring-rubric.md.

Phase 5 — Passe adversaire

Lisez references/adversarial-prompts.md. D'abord, si la recherche web est disponible, effectuez la recherche de preuves externes de references/interview-methods.md (3–8 recherches : concurrents/alternatives, sentiment réel des utilisateurs sur Reddit/forums, signaux de demande et de timing) — les personas simulés sont un proxy pour la recherche utilisateur, et les preuves du marché réel ancrent les verdicts des sceptiques et arment le Kill Agent. Si la recherche n'est pas disponible, notez-le dans le rapport.

Ensuite, effectuez trois vérifications (en parallèle si possible) :

1. Le Kill Agent. Un agent soutient que ce produit ne devrait pas exister : le problème est faux ou bénin, l'alternative est suffisamment bonne, ceci est une fonctionnalité et non un produit, les données démographiques qui paieraient ne chevauchent pas celles qu'il sert. Il doit renforcer l'argument adverse — attaquer la version la plus forte de la thèse en utilisant les preuves des Phases 3–4.
2. Le Réfutateur. Audite les résultats des personas pour détecter la sycophance et le théâtre : résultats sans citations d'interface, personas ayant terminé des tâches au-delà de leur budget de patience déclaré, positivité uniformément suspecte, réponses The Mom Test qui sont des hypothèses déguisées en preuves. Les résultats réfutés sont supprimés.
3. Audit d'adéquation message-marché. Comparez la promesse principale (Phase 1) avec ce que les personas ont réellement vécu (Phase 4). Chaque écart entre la promesse et la livraison est un générateur de perte de clients, même lorsque le produit est bon.
4. Vérification de conformité et de sécurité (lisez references/compliance-security.md) — effectuée chaque fois que le produit collecte des données utilisateur, ce qui est presque toujours le cas. Trois parties : une analyse d'applicabilité des réglementations sur les données (construisez l'inventaire des données à partir du code, puis signalez les régimes plausiblement applicables — RGPD/CCPA/COPPA/LPM, étiquettes de données de l'app store, règles de divulgation de l'IA) ; une différence entre la politique et le produit (chaque promesse « jamais partagé »/« vous pouvez supprimer » vérifiée par rapport au code réel) ; et une base de sécurité. Pour la base de sécurité, déléguez si possible : si la compétence security-audit de Cloudflare, le /security-review de Claude Code, ou un outil MCP de sécurité est disponible dans l'environnement, exécutez-le et intégrez ses résultats confirmés ; sinon, utilisez la liste de contrôle de repli intégrée. Présentez tous les résultats comme un passage de drapeau de niveau ingénierie, pas un avis juridique. Un résultat CRITIQUE ici bloque un verdict VALIDÉ et plafonne la Confiance et le Bénéfice Net à 40.

Phase 6 — Synthèse et verdict

Notez les six dimensions de la grille à partir des seules preuves survivantes, puis émettez exactement un verdict selon references/report-template.md :

• VALIDÉ — problème réel, personas cibles réussissent et reviendraient ; a survécu au Kill Agent. (Rare. Méfiez-vous de vous-même si vous l'émettez.)
• SIGNAL FAIBLE — le problème est réel mais le produit perd de la valeur : les frictions, le temps jusqu'à la valeur ou les coûts de changement la rongent. Listez les correctifs, priorisés par (personas affectés × sévérité).
• NON VALIDÉ — le problème ou la solution a échoué sur la base des preuves. Dites lequel, et montrez les preuves.
• SIGNAL DE PIVOT — le signal le plus fort est venu d'un endroit inattendu : un persona adjacent, un problème différent, une fonctionnalité qui a surperformé l'ensemble. Nommez le pivot concrètement.

Le rapport doit inclure la matrice d'adéquation persona, l'argument survivant le plus fort du Kill Agent (même sous VALIDÉ), le Cimetière des Hypothèses (croyances porteuses encore non prouvées, chacune avec son test réel le moins coûteux), une Liste de Correctifs (≤6 éléments : faiblesse → action concrète → signal de succès), et la grille notée — les scores rendent les réexécutions comparables, donc après avoir expédié des correctifs, l'utilisateur peut relancer /reality-check et voir les chiffres bouger au lieu de redébattre des impressions.

Format du livrable. Présentez toujours le rapport complet dans la conversation. Lorsqu'un outil d'artefact ou de rendu de page web est disponible (par exemple l'outil Artifact de Claude Code), rendez également le rapport sous forme de page partageable unique : une bannière de verdict avec le score composite, le tableau de bord avec les seuils de passage visibles, la matrice d'adéquation persona, les résultats citant des preuves — et une section Solutions qui développe chaque ligne de la Liste de Correctifs en une correction prête à être implémentée : le diagnostic, le changement prescrit au niveau du fichier/écran/texte, qui cela débloque, et le signal de succès. Les résultats diagnostiquent ; les solutions prescrivent — l'artefact doit contenir les deux, afin qu'un collègue qui n'a jamais vu l'exécution puisse agir. Pas d'outil de rendu → écrivez la même page dans un fichier local HTML/markdown et dites à l'utilisateur où il se trouve.

Terminez par la prochaine action unique au plus fort levier. Une. Pas une liste de vingt.