Le 24 septembre 2026, le Product Meetup SXB a inauguré sa formule en deux temps : une formation, puis des ateliers. Deux entrepreneurs sont venus, l’un pour vendre des MVP, l’autre pour faire croître sa boutique en ligne. Tous deux sont repartis avec le même chantier : savoir qui sont leurs clients avant de construire quoi que ce soit.
Jeudi 24 septembre 2026, à Strasbourg. Autour de la première table, un entrepreneur que j’appellerai Thomas (le prénom est changé) présente son offre : il construit en trois semaines un MVP, c’est-à-dire une première version d’application, pour des clients qui ne savent pas coder. Il vient de signer son premier contrat, 1 300 euros, avec un professionnel de santé qui veut tester une idée. Thomas veut savoir comment vendre davantage de missions comme celle-là. Une heure plus tard, il repartait avec une autre interrogation, bien plus inconfortable : à qui vendre.
Mais à la table voisine, un second entrepreneur, que j’appellerai Julien, se posait une question toute différente : sa boutique en ligne, qui revend des produits et vend ceux de son propre laboratoire, ne fait plus progresser son chiffre d’affaires depuis des mois. Pendant l’atelier, un détail a tout arrêté. Julien n’avait jamais rencontré un seul de ses clients.
Deux entrepreneurs, deux sujets sans rapport. Le même trou au milieu.
La formation : apprendre à l’assistant nos méthodes de travail
Mais avant les ateliers, la soirée a commencé autrement. Cette vingt-deuxième édition du Product Meetup SXB était la première à s’ouvrir sur une heure de formation. Le thème tenait en une promesse : gagner du temps en apprenant à l’assistant nos propres méthodes de travail.
Les habitués l’avaient réclamé au fil des éditions précédentes : ils voulaient repartir avec un concept compris, puis l’essayer aussitôt, plutôt que de découvrir la méthode au détour d’une discussion entre deux verres.
J’ai commencé par l’histoire du prompt, la consigne qu’on écrit à l’assistant. Aux débuts de ChatGPT, OpenAI conseillait de placer la consigne en tête, puis de la séparer du texte à traiter par des dièses ou des guillemets triples. On écrivait court.
Puis la fenêtre de contexte, la quantité de texte que le modèle lit d’un coup, a grandi. La recommandation s’est inversée. Radicalement. Anthropic conseille désormais de placer les longs documents en haut du prompt, au-dessus de la question, des consignes et des exemples.
Plus le prompt s’enrichit, plus il coûte à réécrire. J’ai pris l’exemple d’un point hebdomadaire : chaque semaine, on recolle le contexte, le format attendu, le ton et un exemple. Personne ne tient ce rythme longtemps : au bout de quelques semaines, on oublie l’exemple, puis le ton, et le point hebdomadaire redevient le texte générique que l’assistant produisait au premier jour.
Une skill supprime cette répétition. Anthropic, l’éditeur de l’assistant Claude, la décrit comme un dossier de fichiers qui donne à l’assistant l’expertise d’un domaine. Concrètement, ce dossier contient au minimum un fichier texte, SKILL.md. Il s’ouvre sur un nom et une description qui dit quand s’en servir, puis décrit en langage courant les étapes du travail, les règles à respecter et les pièges connus. Au démarrage, Claude ne charge que le nom et la description de chaque skill, environ cent tokens, ces fragments de mots que le modèle compte. Le reste n’est lu qu’au moment où la tâche le demande.
Reprenons le point hebdomadaire. Le dossier point-hebdo contient un SKILL.md dont la description précise de s’en servir quand je prépare mon point du lundi. Son corps fixe le format, le ton et les documents à lire. À côté, un exemple de point réussi montre le résultat attendu, et un petit programme peut aller chercher les chiffres de la semaine. Vous écrivez tout cela une fois. Ensuite, il suffit de demander le point de la semaine.
Mais le point central de la formation tenait en une règle : une skill commence par sa table de notation. Avant d’écrire la moindre instruction, j’écris les critères qui diront si le résultat est bon, chacun assez précis pour que deux lecteurs lui donnent la même note. Exiger que chaque chiffre porte sa source se vérifie. Exiger un texte clair ne se vérifie pas. La skill produit, se note sur cette table, corrige et recommence, et ne présente son résultat qu’une fois le seuil atteint.
Cette grille, personne n’a à l’écrire seul. En créant la skill avec un prompt, on peut demander à Claude d’identifier les expertises que le travail mobilise, puis de rédiger la grille critère par critère, chaque critère confié à l’une d’elles : le journaliste pour les sources, le pédagogue pour les définitions, l’expert du domaine pour la justesse. À mes yeux, c’est le geste le plus puissant de toute la méthode.
Anthropic recommande la même discipline à ceux qui écrivent des skills : créer les évaluations avant d’écrire une documentation abondante, pour que la skill résolve de vrais problèmes plutôt que d’en documenter d’imaginaires. Sans table de notation, une skill ne sait pas quand elle a fini. Elle s’arrête quand elle a écrit.
J’ai ensuite montré qu’une skill peut imposer une seconde discipline. Le procédé que j’ai présenté vient de la documentation d’Anthropic contre les hallucinations, ces affirmations fausses produites avec aplomb : après sa réponse, Claude cherche pour chaque affirmation une citation qui l’appuie, et retire celle qu’il ne peut pas étayer. Le procédé réduit les erreurs. Il ne les supprime pas.
Enfin, j’ai montré les deux skills que j’utilise chaque semaine. La première, que j’ai baptisée assistant produit, fait intervenir tour à tour les spécialistes qu’un livrable demande, puis construit une grille de notation avant toute production. Il s’en sert ensuite pour noter ce que produit le modèle, Claude Opus 5.5 dans mon cas, et relance la production tant que la note n’atteint pas le seuil. La seconde, l’usine logicielle, enchaîne le cadrage, la spécification, l’implémentation et les tests, chaque phase tenue par un rôle distinct. Puis, ce jeudi soir à Strasbourg, j’en ai lancé une en direct, et en vingt minutes une petite application est sortie, phase après phase, sous les yeux de la salle.
La séance est restée une discussion ouverte. Les participants pouvaient interrompre à tout moment, comparer avec leurs propres usages et demander, à chaque étape de la démonstration, ce qu’une skill change concrètement dans une semaine de travail ordinaire. La réponse tenait dans la démonstration : une skill ne répond pas à une question, elle déroule un métier.
Les ateliers : deux tables, deux problèmes réels
Puis la salle s’est partagée en deux tables, chacune autour d’un problème apporté par un participant. Avant que le porteur n’expose son problème, les contributeurs de la table lui soumettent toujours le même questionnaire de contexte, en six points :
- Quel âge a ton produit ?
- À quel problème répond-il ?
- Comment y répond-il ?
- Comment l’équipe est-elle organisée, et quel est ton rôle ?
- Quel problème veux-tu résoudre ce soir ?
- Quelles conséquences, et à quelle fréquence ?
Ce questionnaire sert d’abord les contributeurs. Il leur permet de se mettre à la place de celui qui s’apprête à parler, dans son contexte à lui et pas dans celui qu’ils imaginent. Sans lui, chacun projette le porteur dans une situation qu’il connaît déjà, et l’atelier se remplit de raccourcis, de biais et de jugements qui le rendent inefficace. Le contexte d’abord. Le problème ensuite.
Cas 1 : vendre un MVP à 1 300 euros
Revenons à la première table. L’offre de Thomas tient en une phrase : cadrer le projet d’un client qui n’est pas technicien, puis lui livrer une première version d’application en trois semaines. Thomas ne code pas. Il s’appuie sur l’intelligence artificielle pour produire l’application, et vend surtout son accompagnement.
Très vite, la table a laissé le prix de côté pour trois sujets : ce que le client de Thomas veut mesurer, la cible de l’offre, et la façon dont cette offre gagne de l’argent. Le client, lui, veut savoir si son idée vaut la peine. Il compte le découvrir en faisant construire l’application, en la montrant à quelques collègues, puis en décidant s’il continue ou s’il arrête, sans avoir fixé à l’avance ce qui ferait pencher la balance.
Un MVP sert à apprendre, pas à livrer
Or Eric Ries, qui a popularisé le terme MVP avec la méthode Lean Startup, le définit comme la version d’un nouveau produit qui permet à une équipe d’apprendre le plus possible sur ses clients, preuves à l’appui, avec le moins d’effort. Rien dans cette définition n’exige du code.
Une page de présentation, une série d’entretiens ou un service rendu à la main peuvent jouer ce rôle.
Dans la méthode que je publie sous le nom d’usine à impact, un test est un mini-projet guidé par un indicateur, dont on mesure l’effet pour décider de la suite. On enchaîne les tests dans l’ordre qui coûte le moins : d’abord vérifier que le besoin existe, puis que des gens paieraient pour y répondre, puis que la solution est utilisable, enfin qu’on sait la construire à un coût raisonnable.
Or le client de Thomas n’a mené aucun test de désirabilité, celui qui vérifie que l’offre donne envie à ceux qui devraient l’acheter. Le besoin existe-t-il vraiment ? Les payeurs sont-ils identifiés ? Sont-ils prêts à investir ? Aucune de ces vérifications ne demande une application. Quelques entretiens, une page de présentation et un rendez-vous avec les trois personnes qui signent les budgets auraient dit au client, en quelques jours, s’il valait la peine de dépenser 1 300 euros, puis beaucoup plus ensuite.
Dans cet escalier, l’application n’entre en scène qu’au moment de vérifier qu’on sait s’en servir et qu’on sait la construire. Même à ce stade, un prototype suffit souvent pour tester l’application envisagée : des écrans cliquables, dessinés par un designer ou générés par une intelligence artificielle, sans rien derrière.
Sauter l’escalier revient à jouer au loto pour devenir millionnaire. Ça arrive. Le vrai problème tient à ce qu’on apprend quand on perd. Souvent, rien.
Ce point a retourné la table, parce qu’il change le sens même de l’échec. Si l’application ne trouve pas son public, le client conclura que le marché n’était pas prêt, ou que l’application était mal faite, sans aucun moyen de savoir laquelle de ses hypothèses a lâché. Et si elle réussit, il ne saura pas davantage pourquoi. Un test incapable de désigner la cause n’a rien testé. Il a seulement coûté.
Le prix révèle à qui l’offre s’adresse
Puis vint le calcul du prix. La mission de Thomas représente quinze jours ouvrés de travail réel, pour 1 300 euros. Thomas se paie donc environ 87 euros par jour. Avant charges.
Sur la plateforme Malt, en septembre 2026, les product managers indépendants qui ont huit à quinze ans d’expérience facturent en moyenne 684 euros par jour, et les débutants, jusqu’à deux ans d’expérience, 400 euros. Au tarif moyen des expérimentés, les mêmes quinze jours vaudraient environ 10 000 euros.
Mais le prix journalier n’est pas le seul souci. Un porteur de projet isolé coûte cher à convaincre et ne rapporte qu’une mission, si bien que le coût d’acquisition, ce qu’il faut dépenser en temps et en argent pour signer un client, n’est jamais amorti. Si le test échoue, le client ne revient pas.
Thomas a une parade : constituer un portfolio, quoi qu’il arrive. Mais ce portfolio montrera des applications, alors que Thomas n’est pas développeur et veut vendre le cadrage et l’accompagnement. Ses réalisations raconteraient un autre métier que le sien.
Un indicateur transforme un livrable en test
Livrer une application et répondre à une question sont donc deux prestations différentes. Prenons une question précise : l’utilisateur comprend-il à quoi sert l’outil au premier coup d’œil ?
Les designers y répondent avec le test des cinq secondes, qui montre un écran brièvement puis demande ce qu’on en a retenu. Selon Nielsen Norman Group, cinq secondes ne suffisent pas pour lire le texte, mais permettent de se faire une impression.
L’utilisateur trouve-t-il ensuite le bon bouton pour avancer ? Cette question-là se mesure autrement, par le taux de réussite : la part des participants qui parviennent au bout d’une tâche donnée. Nielsen Norman Group en fait l’indicateur d’utilisabilité le plus simple.
Or la question du client de Thomas est plus vague : est-ce que ça vaut le coup de continuer ? Il compte y répondre en montrant l’application à des utilisateurs, sans jamais rencontrer ceux qui la paieraient. Dans son secteur, celui qui utilise un outil n’est pas toujours celui qui le finance, et un utilisateur enthousiaste ne dit rien de la décision d’achat d’un établissement, d’un associé ou d’un financeur qui, lui, n’a jamais vu l’écran.
La table a donc recommandé à Thomas trois chantiers, dans cet ordre. D’abord décrire sa cible et ses moyens sous forme de personas, ces portraits fictifs mais réalistes d’un client type, dont Nielsen Norman Group rappelle qu’ils se fondent sur une recherche menée auprès de vraies personnes. Ensuite clarifier l’offre et l’indicateur sur lequel le client jugera le résultat. Enfin seulement, retravailler le modèle économique. Pas avant.
Avec le recul, j’ajoute une piste que la table n’a pas explorée : vendre le parcours plutôt que le livrable. Des entretiens d’abord, un prototype ensuite, le code en dernier. Chaque marche serait facturée avec son indicateur, et chaque marche franchie prouverait la valeur de l’accompagnement de Thomas.
Cas 2 : une boutique qui vend sans connaître ses clients
À la seconde table, l’histoire de Julien commençait bien. En quelques années, Julien a bâti une clientèle fidèle.
Il revend des produits achetés à des fournisseurs, vend ceux qu’il fabrique lui-même dans son laboratoire, et confie des liens personnalisés à des partenaires qui touchent une commission sur chaque vente passée par eux, ce qui lui amène des acheteurs qu’il ne voit jamais.
La table voulait aider Julien à transformer sa boutique en véritable accompagnement de ses clients, avec des offres complémentaires. Elle a donc commencé par la question la plus simple de la soirée, en lui demandant qui achète. Julien ne le savait pas. Depuis des années, il vendait à des clients qu’il n’avait jamais rencontrés, dont une partie lui arrivait par les liens de partenaires qu’il ne voyait pas davantage.
Alors l’atelier a changé de cap. La table a dressé avec Julien la liste de tout ce qu’il possédait déjà pour construire ses personas : la base de ses commandes, ses partenaires affiliés, les salons où il expose, ses chaînes YouTube et TikTok. Sans s’en rendre compte, Julien avait accumulé en quelques années un gisement de données sur ses clients.
Julien a aussi repéré un salon où il pourra observer ses clients sous l’angle des cinq forces de Porter. L’économiste Michael Porter désigne ainsi les cinq pressions qui pèsent sur la rentabilité d’un secteur : les concurrents en place, le pouvoir des clients, celui des fournisseurs, la menace de nouveaux entrants et celle des produits de substitution. Sur un salon, les cinq se croisent dans les mêmes allées. Julien pourra y voir vers quels concurrents ses clients se tournent, quels produits de remplacement ils regardent et ce qu’ils acceptent de payer. Ses personas y gagneront ce qu’une base de commandes ne dit jamais : ce que le client aurait pu acheter à la place.
Julien peut d’abord se servir de ce gisement pour repérer ses clients potentiels et le parcours que chacun suit jusqu’à l’achat. Prenons un exemple fictif, un site de cuisine, pour ne rien dévoiler de l’activité de Julien. Trois personas peuvent s’y croiser : le professionnel qui veut se former à de nouvelles pratiques ou recettes, le père de famille qui veut impressionner ses enfants avec un plat raffiné, et l’élève de CAP cuisine, en formation pour devenir cuisinier, qui veut simplement progresser. Tous trois viennent sur le même site. Aucun pour la même raison.
Or chaque persona appelle un autre dispositif de vente. Si l’élève est le client le plus intéressant, le site suivra sa progression et lui proposera le matériel dont il aura besoin, au fil de sa formation. Si c’est le père de famille, il faudra plutôt l’inciter à revenir et à recommander le site aux convives qu’il a impressionnés, par exemple avec un abonnement qui débloque de nouvelles recettes. Choisir un persona ne change pas une page du site. Il change ce qu’il faut construire pour vendre, et donc le modèle économique.
Les données disent ce que les clients achètent. Seules les rencontres disent pourquoi.
Le persona est une décision, pas un portrait
Ainsi, les deux ateliers ont buté sur le même mur. Thomas ne pouvait pas fixer son prix sans savoir qui paie, ni sur quel indicateur ce payeur juge le travail. Julien ne pouvait pas choisir un levier de croissance sans savoir qui achète. Dans les deux cas, toute la stratégie dépendait d’un portrait de client qu’ils n’avaient pas encore dessiné.
Pourtant l’objection la plus sérieuse mérite d’être entendue. Un entrepreneur qui passe trois mois à dessiner des personas ne vend rien pendant ce temps. Elle est juste. Mais elle vise un travail mal dosé : cinq conversations avec des clients cette semaine coûtent moins cher qu’une application inutile, et elles font avancer la vente en même temps. L’intelligence artificielle ajoute une seconde objection : si coder une application ne coûte plus que quinze jours, autant coder tout de suite. Ce raisonnement oublie que le coût d’un test raté ne tient pas au code. Il tient à la mauvaise conclusion qu’on en tire.
Voilà ce qu’une heure d’atelier a permis d’offrir aux deux porteurs de problèmes venus au meetup jeudi dernier : Thomas repart avec une cible à clarifier avant de fixer son prix, Julien avec un gisement de données qu’il n’avait jamais regardé. Merci encore à toutes celles et ceux qui étaient là, et à cette communauté qui continue de grandir. Merci pour votre contribution, votre confiance. Et c’est reparti pour une année de folie !
