Tester ses maquettes avec des personas joués par Claude : 4 insights que l'équipe n'aurait jamais trouvés

Quand tu démarres un produit, tu fais des maquettes. Tu les regardes. Toi tu les aimes. Ton cofondateur les aime. Ton designer les aime. Le problème, c'est que vous êtes tous biaisés : vous savez ce que vous avez voulu, vous savez ce que vous avez construit, et donc vous voyez ce que vous avez voulu construire — pas ce qu'un client va voir.

Le coût classique de désambiguïsation est connu : 4 à 8 utilisateurs cible recrutés à 150 €/test, 2 à 4 semaines pour caler les agendas, transcriptions et analyse derrière. Plusieurs k€ et un mois. La voie courte — un atelier interne entre fondateurs — est gratuite mais biaisée par les convictions partagées : l'équipe répète ses propres certitudes et confond consensus avec validation. La voie longue est solide mais lente. Entre les deux, les fondateurs solos ou en duo prennent souvent la décision la plus chère : ils tranchent au feeling et partent en dev.

Je viens de tester en 24 heures une quatrième voie sur un projet B2B en cours de discovery — un produit complémentaire à mon académie de formation IA, ciblant cette fois des publics non-tech. Cinq variantes UX produites par Claude Design, quatre puis six personas joués par des sessions Claude Code isolées, des verbatims structurés en retour. Coût direct : zéro. Insights produit générés : quatre décisions structurantes qu'un atelier interne n'aurait pas sorties spontanément. Je ne pense pas une seconde que ça remplace les tests utilisateurs réels — j'expliquerai pourquoi à la fin. Mais c'est devenu un passage obligé de mon workflow amont, et ça vaut un article long.

La méthode, en quatre étapes

Le process tient en quatre étapes courtes, dont une seule est vraiment nouvelle.

Étape 1 — Produire plusieurs variantes esthétiques. J'ai commandé à Claude Design quatre directions UX radicalement différentes pour le même produit : un SaaS éditorial style « magazine », une variante illustrée façon papier-crayon, un compagnon conversationnel dark, et un hybride. Chaque variante : 28 à 30 pages HTML navigables localement.

Étape 2 — Trancher à l'œil entre les variantes. L'équipe regarde, débat, préfère plus ou moins. On élimine ce qui ne marche pas, on garde ce qu'on aime, on rédige un cinquième brief « E » qui synthétise. Claude Design produit E. À ce stade, l'équipe se sent bien — mais n'a aucune preuve qu'un client achèterait. C'est exactement le point où la plupart des fondateurs partent en dev.

Étape 3 — Tester les variantes sur des personas joués par Claude, en aveugle. Je construis quatre personas très spécifiques (cf. § règles), j'ouvre quatre sessions Claude Code séparées sans contexte projet partagé, je leur donne un prompt détaillé et un accès Playwright pour screenshotter les écrans. Chaque persona navigue, juge, vote. En vingt minutes par persona, j'obtiens une matière structurée que je n'aurais pas eue autrement.

Étape 4 — Itérer, valider, trancher. Je synthétise les retours en treize corrections priorisées, je commande une variante E-prime, et je refais un round 2 avec un protocole hybride : deux anciens personas en revue ciblée sur leurs critiques V1, deux nouveaux en aveugle sur la V2 seule. Au verdict du round 2 : six personas sur six achètent sous conditions. On entre en dev, sans plus aucun débat interne ouvert.

Les quatre insights qu'un atelier interne n'aurait pas sortis

C'est le cœur de la valeur. Voilà quatre retours qui ont concrètement modifié le produit — et qu'on n'aurait pas trouvés à dix dans une salle.

1. La notif WhatsApp du dirigeant

Comment le canal qu'on avait prévu pour l'apprenant a basculé côté dirigeant.

Karim, le premier persona, est un dirigeant de TPE — une boulangerie de 26 salariés en région. Dans le brief initial, on avait prévu des notifications soignées pour l'apprenant : email à J+0, push à J+1, WhatsApp à J+3 en cas de décrochage. Karim regarde les maquettes vingt minutes et répond :

« Si je paye lundi et que vendredi personne s'est connecté, l'argent est perdu et j'ai l'air d'un con auprès de mon équipe. Ce qu'il me faut, c'est pas une belle maquette — c'est une notif WhatsApp tous les soirs qui me dit qui a fait son exercice et qui décroche. »

Je doute qu'un atelier interne aurait sorti ça en première intention. C'est le verbatim d'un dirigeant qui paie de sa poche, qui n'a pas le temps d'ouvrir une console, et qui veut un canal qu'il consulte déjà en boucle. Conséquence directe : un canal de notification dirigeant distinct du canal apprenant. Pas un dashboard. Un message WhatsApp court, le soir, une ligne par personne, fait/pas fait. Le persona suivant — une Office Manager d'une agence — a validé ce nouveau design avec un 5/5 et un commentaire en majuscules : « CECI EST DU GÉNIE. »

2. Le mot « vacances » qui claque la porte dans l'industrie

Quand un nom marketing fort devient un mur de vente sur certains segments.

Le projet a un nom marketing fort, taillé pour la presse et le contenu d'été. Yannick, RRH d'un sous-traitant automobile de la métropole lilloise, le dit sans détour :

« Si je peux retirer toute mention "vacances" dans les écrans que je montre en interne et ne garder que "le programme IA métier", c'est plié. »

Il a raison. Dans un site industriel où on parle production et tableau de bord HSE, un nom léger fait perdre l'achat avant le pitch. Conséquence : un mécanisme de rebrand tenant-side. Chaque client configure un nom interne — par exemple « Programme IA Métier · MétalRoubaix » — qui remplace le nom marketing dans tous les écrans authentifiés. Le nom externe reste celui qui claque pour la presse et les contenus publics. Sans cette fonctionnalité, on perdait probablement 30 à 40 % des cibles industrie et grand compte. Aucun moyen de l'anticiper en interne — c'est un détail qu'on ne voit que quand un RRH te le dit avec ses mots à lui.

3. Le ROI en heures, pas en pourcentages

La vraie question qu'un DG pose dans 3 mois, et la métrique qui y répond.

Sur l'écran « slide COMEX » — celui que le décideur projette en comité exécutif pour justifier l'achat — on affichait des KPI propres : 94 % de places activées, 79 % d'exercices terminés, 3,6/5 de compétences acquises. Sandrine, DRH d'une PME de bureau d'études à Nantes, lit la slide et répond :

« Si mon DG me demande "qu'est-ce que ça a changé ?" dans 3 mois, je veux pas dire "ils se sentent mieux". Je veux dire "40 heures économisées sur les fiches de poste et 60 heures sur les relances candidats". »

Conséquence : un module Heures économisées sur le COMEX. « 25 h économisées sur 60 jours · équivalent ~½ ETP de gain sur ton équipe », avec un tableau par cas d'usage. C'est ce qui transforme un produit de formation en un produit avec ROI mesurable, lisible par un DG qui ne lit jamais le détail. Au round 2, Sandrine donne 5/5 à cet écran et écrit : « La slide que je veux mettre devant mon DG. Pas du sentiment, des heures. Et le ½ ETP, c'est traduit en langage DAF. »

4. Les concurrents qu'on n'avait pas vus : les cabinets de conseil

Quand l'angle d'attaque concurrentiel ne vient pas du marché SaaS mais de PowerPoint vendus 300 k€.

Dans l'analyse de marché initiale, on avait listé les acteurs SaaS de la formation IA. Plateformes en ligne, mentorat, e-learning. Patricia, DRH d'une ETI de 1 200 personnes à Paris, identifie un concurrent qu'on n'avait pas inscrit :

« Ce qui me fait peur, c'est que pendant que je négocie ça, BCG Brighthouse ou McKinsey QuantumBlack vienne pitcher au CODIR un programme transverse à 300 k€ et qu'on coupe la décision à mon niveau. »

Ce ne sont pas des produits SaaS — ce sont les branches IA de cabinets de conseil, qui ne vendent pas un outil mais un programme de transformation facturé directement au DG, court-circuitant la DRH. Pour une ETI, c'est l'angle d'attaque le plus dangereux : la décision quitte la DRH avant qu'elle ait eu le temps de comparer. Conséquence stratégique : notre positionnement doit désormais être explicite — « pilote agile sur 14 personnes, 60 jours, sortie possible » par opposition au « programme 300 k€ sur 18 mois ». Sans Patricia, on partait en go-to-market en croyant qu'on se battait contre des plateformes en ligne. On se bat aussi contre des decks PowerPoint vendus à 300 k€ — et on les bat différemment.

Les sept règles qui font que ça marche

Lancer Claude dans le rôle d'un persona, c'est trivial à dire. Le faire bien, c'est plus subtil. Voilà les règles que j'ai trouvées en pratique pour que les retours soient utilisables, et pas une bouillie polie de bons sentiments.

Règle 1 — Persona spécifique, pas archétype

Mauvais prompt : « Tu es une DRH de PME, donne ton avis. » Bon prompt : 250 mots de spec qui ancrent la persona dans un réel. Pour une DRH de PME, ça ressemble à ça :

« Sandrine Bertrand, 47 ans, DRH d'AltiSciences — bureau d'études techniques 68 salariés à Nantes. DRH depuis 9 ans là-bas. Pas tech : tu utilises Microsoft 365 quotidiennement, tu détestes les formules Excel. Tu as essayé ChatGPT 4 ou 5 fois en 2024-2025, jamais intégré dans ta semaine. Ton DG t'a demandé en mars 2026, en CODIR : "Sandrine, qu'est-ce qu'on fait sur l'IA pour les équipes ?" Tu lui as répondu "je regarde". Depuis, tu n'as pas vraiment regardé. Tu es méfiante des "outils miracles" — tu en as vu passer trop en 9 ans (Officevibe, Lattice, un LMS qu'on a payé 12 k€ et que personne n'a utilisé). Budget formation 2026 quasi épuisé ; tu peux puiser 2 à 4 k€ sur ton enveloppe discrétionnaire si tu as une vraie raison. Deux peurs : (1) que les salariés balancent des données sensibles à un LLM et qu'on se prenne la CNIL, (2) que le COMEX te demande "ROI" dans 3 mois et que tu n'aies rien à montrer. »

Plus le persona est précis, plus le retour est précis. Les détails non-fonctionnels — école, échec d'outil passé nommé, marge budgétaire au k€ près, phrase qu'elle a dite à son DG — sont ce qui transforme un archétype en personne. Sans eux, Claude joue une DRH générique et le retour est plat.

Règle 2 — Isolation totale de la session

L'agent qui joue le persona ne doit pas pouvoir lire les docs/ du repo (ils contiennent toute la stratégie produit — biais énorme), ni le git log, ni les README, ni les fichiers de style des maquettes, ni naviguer le web pour chercher ce qu'est le produit. Cette interdiction se précise dans le prompt : « Tu n'as pas le droit de lire X, Y, Z. Limite-toi au rendu visuel des maquettes. » Sans ça, Claude lit les docs/ et son retour devient celui d'un consultant qui sait ce que le produit veut faire — exactement ce qu'on essayait d'éviter.

Règle 3 — Rendu visuel, pas le HTML

Lire le HTML ne dit rien sur la qualité visuelle. La grande typo serif italique, le confort de lecture, l'effet « centre aéré pour CE2 » d'une variante illustrée — tout ça se voit, pas se lit. J'installe Playwright en local et je fournis à l'agent une commande qui screenshotte les pages clés en PNG, puis il lit les images. Sans cette étape, le persona ne « voit » pas la maquette — il en devine la structure. Avec elle, il dit « on dirait Madame Figaro, ça fait Lubéron » devant une photo placeholder. C'est ce niveau de jugement qu'on cherche.

Règle 4 — Format de réponse strict

Mauvais brief : « Donne ton avis. » Bon brief : un template figé. Pour chaque variante, première impression en 15 secondes, ce qui m'attire (verbatim 2-3 phrases), ce qui me freine (verbatim 2-3 phrases), trois notes /5 (confiance d'achat, effet wahou, crédibilité COMEX), une seule chose que je changerais avant d'acheter. Sans format imposé, Claude part en analyse design senior et noie le poisson. Avec le format, il reste dans la peau du persona qui dit « c'est moche, je vais le dire comme ça ».

Règle 5 — Ton autorisé explicite

Pour la DRH PME : « Pas de politesse excessive. Pas de "c'est très bien". Si c'est moche, dis "c'est moche". Si c'est confus, dis "j'ai pas compris". » Pour le RRH industrie : « Tu dis "machin", "ça va pas le faire", "c'est un peu m'as-tu-vu", tu détestes les anglicismes. » Pour le DG d'agence expert IA : « Direct, exigeant, vocabulaire produit ("UX", "onboarding", "north star", "jobs-to-be-done"). » C'est ce qui produit des verbatims utilisables. Sans contrainte de ton, Claude vouvoie tout le monde poliment et la matière est inexploitable.

Règle 6 — Multi-persona, diversité forcée

J'ai varié sur six axes : taille d'entreprise (12 sal. → 1 200 sal.), secteur (artisanat, industrie, services pro, agence com, bureau d'études), âge (33 → 54 ans), tech literacy (faible → expert), rôle de décision (DG, DRH, RRH, Office Manager), pression interne (aucune → COMEX dans 6 mois). Sans diversité, on obtient six fois le même retour. Avec, on obtient six retours qui se contredisent par moments — et les contradictions sont riches. La variante illustrée recueille un 8/12 du dirigeant de TPE (« c'est rigolo, ça désamorce le côté flippant ») et un 6/15 de la DRH d'ETI (« je ne peux pas mettre ça devant un COMEX d'audit financier »). Les deux ont raison pour leur cible. C'est ce diagnostic qui te dit ce que tu n'écriras pas en homepage publique mais que tu garderas pour le pitch commercial.

Règle 7 — Round 2 hybride pour la V2

Quand j'ai livré la V2 corrigée des retours V1, je n'ai pas refait tester les quatre mêmes personas en aveugle. Risque connu : ils sont contaminés, ils savent ce qu'ils ont dit, ils vont chercher si on les a écoutés — effet demand characteristics. Protocole utilisé : deux anciens en revue ciblée (« voici tes critiques V1, dis-moi si elles sont traitées, point par point »), et deux nouveaux en aveugle (persona neuve, V2 seule, pas de comparaison cross-variante). Ce protocole isole deux questions distinctes : « les corrections marchent-elles ? » (anciens, confirmation) et « le produit séduit-il un cerveau frais ? » (nouveaux, vrai signal). Au round 2, les six convergent. À ce moment-là, le débat interne s'arrête.

Les limites — ce que la méthode ne fait pas

Soyons honnête sur ce qu'un persona joué par Claude ne fait pas.

Il ne clique pas en hésitant. Pas d'observation comportementale : où la souris hésite, où le testeur abandonne, où il scrolle trois fois avant de comprendre, où il revient en arrière. Cette matière-là — précieuse pour l'UX réelle — n'existe pas dans un retour Claude. Tu auras les verbatims et les notes ; tu n'auras pas la friction de clic.

Il ne dit pas n'importe quoi. Un vrai utilisateur peut dire des trucs incohérents, contredire dans la phrase suivante, ne pas savoir pourquoi il n'aime pas un truc. Claude est trop propre. Ses retours sont structurés, articulés, parfois trop intelligents pour la persona qu'il joue. Un Office Manager fictif peut sortir un raisonnement de Senior Product Designer sans s'en rendre compte. Le ton imposé et le vocabulaire interdit limitent ça, mais ne l'éliminent pas.

Il ne représente pas la diversité réelle. Six personas Claude n'égalent pas six vraies personnes. Il y a une cohérence interne au modèle qui peut homogénéiser les retours, surtout sur les sujets où le modèle a des opinions implicites. C'est précisément pour ça que la diversité forcée (règle 6) est non-négociable — et que les contradictions entre personas sont le signal qu'il faut traquer.

Il ne paie pas. Pas de prix exact testable, pas de mesure d'engagement, pas de validation économique. Pour ces sujets-là, il faut des vrais utilisateurs, point.

Quand ne pas l'utiliser. Pour décider d'un prix exact (les personas ne paient pas vraiment). Pour mesurer un effet d'engagement (pas d'observation de durée, de taux de retour). Pour des produits émotionnels complexes — luxe, dating, jeu — où le verbatim ne suffit jamais à capter l'intention d'achat.

Comment compléter. Cette méthode est un complément amont, pas un remplacement. Elle te permet d'éliminer les 80 % de fausses pistes avant d'investir dans des tests réels, d'identifier les bonnes questions à poser à de vrais utilisateurs, et d'itérer cinq fois plus vite sur les maquettes. Tu fais quand même des tests utilisateurs réels — mais trois ou quatre au lieu de douze, sur des hypothèses précises au lieu de fishing. Comme l'IA en général n'invente pas l'expertise mais l'amplifie, un persona Claude n'invente pas la voix du client : il amplifie ta capacité à formuler les bonnes questions avant de la confronter à la réalité.

Récap chiffres

Métrique	Valeur
Durée totale du process	24 heures (14 h hier → 13 h aujourd'hui)
Variantes UX explorées	5 (A, B, C, D, E)
Personas testés round 1	4
Personas testés round 2	6 (4 anciens en revue ciblée + 2 nouveaux en aveugle)
Durée moyenne d'un test persona	~20 minutes (prompt → retour structuré)
Coût direct	~0 € (sessions Claude Code Pro existante)
Coût équivalent en tests réels	4 à 5 k€ + 2 à 4 semaines
Insights produit majeurs générés	4 (notif dirigeant, rebrand tenant, ROI en heures, cabinets de conseil)
Conversion round 2	6/6 personas (~6 800 € HT de prospects warm modélisés)
Corrections produit identifiées	13 (4 bloquantes + 9 importantes) + 7 sujets roadmap

Alors, est-ce que les LLM remplacent les tests utilisateurs ?

Non. Et personne sérieux ne devrait dire le contraire. Un persona Claude ne paie pas, ne clique pas en hésitant, ne contredit pas ses propres convictions à mi-phrase. Les vrais tests utilisateurs restent indispensables pour valider une intention d'achat, une métrique d'engagement, un prix.

Mais pour un fondateur solo ou un duo en pré-revenu, avec une fenêtre de lancement courte et un budget contraint — ce qui est la situation par défaut de tout projet B2B SaaS en discovery — la méthode change la nature du jeu. Tu ne passes plus quatre semaines à recruter douze testeurs pour confirmer ton intuition. Tu passes 24 heures à confronter cinq variantes à six points de vue diversifiés, à extraire treize corrections, à éliminer 80 % des fausses pistes. Quand tu sors pour faire les vrais tests utilisateurs derrière, tu poses trois ou quatre questions précises au lieu d'aller pêcher au filet. Le ROI est dans la qualité des questions, pas dans le remplacement des réponses.

Elle est devenue un passage obligé de mon workflow pour tout projet en phase amont — et notamment sur les missions Sprint Fondateur, où le délai de deux mois ne laisse pas le luxe d'aller pêcher au filet.