Tu as une hypothèse à valider. Pour la tester proprement, il te faut quelque chose que des utilisateurs peuvent toucher. Et ce quelque chose demande deux ou trois sprints d'une équipe qui a déjà sa roadmap. Alors l'idée attend, ou elle part en maquette Figma que personne ne prend vraiment au sérieux.
Je suis CPTO de quatre start-up en parallèle. Depuis que je construis avec Claude Code, ce goulot a changé de place : un Product Manager peut mettre lui-même un prototype en ligne, le faire tester, et revenir vers l'équipe avec des preuves plutôt qu'avec une intuition. Voici ce que ça change, ce que tu peux faire seul, et ce que tu ne dois pas faire seul.
Ce que Claude Code change pour un Product Manager
Claude Code est l'agent de programmation d'Anthropic. Contrairement à une conversation avec Claude où tu copies-colles du code, il travaille directement dans les fichiers de ton projet : il lit, écrit, lance les commandes et vérifie le résultat. Tu l'utilises depuis l'application Claude, dans l'onglet Code, avec un abonnement payant.
Pour un PM, la différence est simple : tu décris ce que tu veux construire, en français, et il construit. Tu n'as pas besoin de savoir coder. Tu as besoin de savoir ce que tu veux tester, et c'est précisément ton métier.
Trois usages reviennent chez les PM avec qui je travaille :
- Le prototype de discovery : une version qui tourne d'une fonctionnalité, mise devant cinq ou dix utilisateurs avant d'engager l'équipe.
- La démo qui convainc : un parcours cliquable avec de vraies données, pour un comité, un CPO ou un client.
- L'outil interne : un petit tableau de bord ou un formulaire que personne n'a le temps de faire, mais qui te fait gagner des heures chaque semaine.
Un prototype qui tourne vaut mieux qu'une maquette
Une maquette montre une intention. Un prototype qui tourne montre un comportement. La différence se voit dès la première séance de test : l'utilisateur ne commente plus des écrans, il essaie de faire quelque chose, et tu vois où il bloque.
C'est aussi ce qui change la conversation avec ton CPO. « Voici ce que j'imagine » se discute. « Voici ce que huit utilisateurs ont fait avec, et ce qu'ils ont demandé ensuite » se décide.
Le piège, c'est de croire que ce prototype est le produit. Il ne l'est pas. Il sert à apprendre vite, puis l'équipe reprend ce qui mérite de l'être, avec ses standards.
Ce que tu peux construire seul, et ce que tu ne dois pas faire seul
Tu peux construire seul :
- un prototype autonome, sur un compte et un hébergement à part, sans toucher au produit en production ;
- une page de test d'une proposition de valeur, avec inscription ;
- un parcours complet avec des données fictives ou anonymisées ;
- un outil interne qui ne manipule pas de données sensibles.
Tu ne dois pas faire seul :
- toucher au code de l'équipe ou à la base de production ;
- manipuler des données personnelles de vrais clients sans l'accord de ta DSI ;
- présenter le prototype comme une fonctionnalité livrée.
Cette frontière n'est pas une précaution de principe. C'est ce qui te permet d'aller vite sans créer de problème à ton équipe technique, et donc de pouvoir recommencer la semaine suivante.
Cadrer Claude avant de lui faire écrire une ligne
Le résultat de Claude Code dépend surtout de ce que tu lui donnes au départ. Sans cadre, il produit vite quelque chose qui marche à moitié, avec des choix techniques que personne n'a faits.
Avant de construire, je lui donne toujours trois choses :
- Le problème à tester, en une phrase : qui, quelle situation, quel comportement tu veux observer.
- Le périmètre : les trois écrans ou actions qui suffisent pour le test, et ce qui est explicitement hors du prototype.
- Les consignes de construction : la pile technique, la sécurité minimale, la façon de mettre en ligne. Ce sont elles qui évitent de repartir de zéro à chaque projet.
C'est cette troisième partie que la méthode Komette apporte toute faite : des consignes tirées de mes projets, que Claude applique à chaque étape, pour qu'un PM arrive à un prototype propre au lieu d'un brouillon fragile.
Un premier prototype en cinq étapes
- Écris l'hypothèse : « Les responsables RH abandonnent l'onboarding parce qu'ils ne savent pas quoi faire en premier. »
- Choisis le plus petit parcours qui permet de l'observer : un écran d'accueil, une liste de tâches, une action.
- Demande un plan à Claude avant tout code, relis-le, retire ce qui n'est pas nécessaire au test.
- Fais construire, étape par étape, en vérifiant chaque écran dans le navigateur avant de passer au suivant.
- Mets en ligne sur une adresse à part et partage-la à tes utilisateurs de test, avec une question précise.
Compte une à deux journées pour un premier prototype, le temps de prendre tes repères. Les suivants vont plus vite.
Les limites à connaître
Claude Code ne remplace ni une équipe produit, ni une vraie architecture. Il te donne la capacité d'apprendre avant de demander du temps de développement. Trois limites à garder en tête :
- La sécurité : un prototype en ligne est public. Pas de vraies données sensibles, des accès protégés si besoin, et des secrets jamais écrits dans le code.
- La maintenance : un prototype qui marche attire des utilisateurs. Décide à l'avance s'il sera repris par l'équipe ou arrêté après le test.
- Ta DSI : préviens-la avant de mettre quoi que ce soit en ligne au nom de ton entreprise. Arriver avec un périmètre clair et des données fictives rend la conversation facile.
Le vrai changement, ce n'est pas l'outil. C'est que la discovery n'attend plus le prochain sprint : tu peux tester cette semaine l'idée que tu aurais présentée au prochain trimestre.