LEAN · Trouver le bon problème

1. La Pyramide Cible-Problème-Solution

Avant d'écrire le Lean Startup, Eric Ries a brûlé 300 000 dollars et six mois sur un produit dont personne ne voulait. Il était développeur en Silicon Valley, donc le code n'était pas le problème. Le problème, c'est qu'il ne savait pas pour qui il construisait.

Si tu lances quelque chose en ce moment, tu es exactement dans la même position que lui au début. Ce n'est pas un défaut, c'est la condition de départ.

Ce que personne ne te dit au tout début

Une startup, par définition, c'est une boîte qui ne sait pas trois choses : à qui elle parle, quel problème elle résout, et avec quoi. Un entrepreneur classique, lui, connaît les trois. Il ouvre une boulangerie dans un quartier sans boulangerie, il sait pour qui, pour quoi, et comment. La startup, non. Elle découvre. C'est ça, la différence.

Le réflexe normal, quand on démarre, c'est de tout dire pour se rassurer. On vise large, parce qu'on a peur de se couper du monde. On liste plusieurs problèmes, parce qu'on n'est pas sûr du vrai. On empile les features, parce qu'on confond "produit complet" et "produit fini". Le résultat tient en une phrase : un message que personne ne comprend, donc personne ne réagit, donc aucun signal sur la valeur de l'idée. Six mois plus tard, on en est au même point qu'au jour 1, mais avec moins d'argent et plus de fatigue.

La Pyramide Cible-Problème-Solution sert à sortir de là. Pas à avoir raison du premier coup. Juste à avoir une hypothèse assez précise pour qu'un humain te dise oui ou non, sans hésitation.

Trois lignes, trois règles

Cible. Une seule, et la plus précise possible. "Les PME" n'existe pas, parce que personne ne se lève le matin en se disant "je suis une PME". Vise plutôt "les agences de recrutement de moins de 10 personnes en région parisienne qui facturent au succès". Si quelqu'un de ce segment lit ta phrase, il doit se reconnaître au premier coup d'œil.

Problème. Une seule phrase, le problème principal. "Elles n'ont pas d'outils" ne dit rien. "Elles recopient leurs candidats à la main d'un ATS à un autre, tous les jours" dit quelque chose. Si tu décris l'action concrète qui les use, c'est bon signe.

Solution. Une seule feature. La plus petite chose qui répond au problème principal. "Une plateforme tout-en-un" est un mot poli pour dire "je n'ai pas choisi". "Un bouton qui pousse une fiche candidat de LinkedIn vers leur ATS en un clic" est une vraie pyramide.

Une pyramide, c'est un concept à tester, donc un message à matraquer. Si tu en lances deux en parallèle, tu n'en lances aucun. Tu obtiens du bruit, pas un signal.

L'exercice, maintenant

Prends une feuille. Écris :

Cible    : ...
Problème : ...
Solution : ...

Trois forces vont essayer de te ramener vers le flou.

La première, c'est l'envie d'élargir. "Et puis aussi les freelances, et aussi les indépendants, et aussi…" Non. Tu peux toujours élargir plus tard. Pour l'instant, tu veux savoir si ton message parle à un humain précis. Et quand une cible ne fonctionne pas, on n'élargit pas, on en change.

La deuxième, c'est l'envie d'empiler les problèmes. Choisis-en un. Celui qui revient le plus quand tu écoutes des futurs clients. Les autres ne disparaissent pas, ils attendent leur tour.

La troisième, c'est l'envie de tout lister côté solution. Une seule feature. La plus petite qui résout le problème principal. Tout le reste est un v2.

Si tu n'arrives pas à choisir, ce n'est pas un blocage intellectuel. C'est que tu n'as pas encore assez parlé à des gens. On y vient au prochain chapitre.

Le plan B explicite

Tu peux préparer une deuxième pyramide en réserve, avec une cible différente. Si la première ne tient pas après quelques tests, tu bascules dessus sans repartir de zéro. C'est ton plan B explicite, pas un filet émotionnel.

La différence n'est pas une nuance. Un filet, on le garde pour ne pas avoir à choisir. Un plan B, on l'écrit pour pouvoir choisir vite, le jour où les données disent que la première n'est pas la bonne.

Ce qui doit rester sur ta feuille à la fin

Une pyramide lisible à voix haute, sans pause, sans "et aussi". Si tu mets plus longtemps qu'une respiration, c'est qu'il y a trop de choses dedans.

Tu n'as pas besoin que ce soit juste. Tu as besoin que ce soit précis. Le reste, c'est ce qui se passe après, quand tu vas confronter cette pyramide à du vrai monde.

2. Trouver un problème qui vaut le coup

Tu as une pyramide. Bravo, c'est déjà rare. Le problème, c'est que tu ne sais pas encore si la ligne du milieu, celle où tu as écrit "Problème", vaut le temps de ta vie.

C'est la section où on filtre.

Le piège de la validation gentille

Quand on parle de son idée à des proches, à des collègues, à des inconnus sur LinkedIn, la grande majorité va dire que c'est une bonne idée. Ils n'ont pas tort par méchanceté. Ils ont tort parce que tu leur as posé la mauvaise question.

"Est-ce que tu utiliserais un truc qui fait X ?" Réponse : "Ah ouais, ce serait cool." Ce "cool" ne vaut rien. C'est la politesse qui parle, pas le portefeuille. Rob Fitzpatrick a écrit un livre entier là-dessus, The Mom Test, et le titre dit tout : si tu poses ta question d'une façon où même ta mère pourrait te mentir sans mauvaise intention, tu n'apprends rien.

La vraie question n'est jamais sur ton produit. Elle est sur la vie de la personne, avant que tu existes.

Trois questions qui marchent

Pour savoir si le problème de ta deuxième ligne mérite ton année, tu n'as besoin que de trois angles. Tu peux les poser à toute personne dans ta cible, sans jamais pitcher ton idée.

La fréquence. À quelle fréquence elle rencontre le problème ? Une fois par an, une fois par mois, une fois par semaine, tous les jours ? Un problème mensuel mobilise rarement un budget. Un problème quotidien, oui.

L'intensité. Qu'est-ce que ça lui coûte quand le problème arrive ? Du temps, de l'argent, du moral, des clients, du sommeil ? Si tu n'arrives pas à formuler le coût en une phrase, c'est probablement que ce n'est pas un problème, c'est un inconfort.

Le workaround. Comment elle fait aujourd'hui pour s'en sortir ? Un fichier Excel ? Un stagiaire ? Un outil qu'elle déteste mais qu'elle paie ? Le bricolage actuel est ton meilleur indicateur. Quelqu'un qui a déjà construit un système maison autour d'un problème t'a déjà dit, sans le savoir, qu'elle paierait pour mieux.

Trois angles, quelques minutes par personne. C'est suffisant pour commencer à voir un pattern.

Les signaux qui disent "abandonne"

Il y a aussi des choses que tu vas entendre, et que tu ne dois pas surinterpréter. Le réflexe humain, c'est de retenir ce qui valide et d'oublier ce qui invalide. C'est un piège d'ego, pas de réflexion.

"Ce serait bien à avoir." Traduction : ce n'est pas un problème, c'est un confort.

"Je n'avais jamais pensé à chercher une solution." Traduction : ce n'est pas assez douloureux pour que la personne se soit déjà mise en mouvement.

"On a essayé un outil il y a deux ans, mais on a laissé tomber." Pose la question d'après : pourquoi vous avez laissé tomber ? Si la réponse est "ça n'allait pas assez vite à mettre en place", tu as une opportunité. Si la réponse est "en fait, on n'en avait pas besoin", tu as un signal d'arrêt.

Un bon fondateur jette ses idées à la poubelle régulièrement. S'accrocher quand le marché dit non, c'est de l'ego, pas de la conviction.

Les signaux qui disent "creuse"

Tu sais que tu es sur quelque chose quand la personne en face change de posture. Elle se penche en avant. Elle te coupe pour décrire son propre cas avant que tu finisses ta question. Elle te raconte ce qu'elle a essayé. Elle finit par te demander si tu veux parler à un collègue qui vit pareil.

À l'autre bout du spectre, il y a le signal infaillible, celui que tu rencontreras peut-être dans un an ou deux. Si un jour tu te demandes "est-ce que j'ai atteint le product-market fit ?", la réponse est non. Quand c'est là, tu n'as pas le temps de te poser la question, parce que tu es sous l'eau.

Tu n'en es pas là. Et c'est très bien. Pour l'instant, tu cherches juste à voir si la posture de tes interlocuteurs change quand tu décris le problème de ta deuxième ligne.

Ce qui doit rester sur ta feuille à la fin

À côté de ta pyramide, ajoute trois choses, observées et pas devinées :

Fréquence  : ...
Coût       : ...
Workaround : ...

Si tu peux remplir les trois pour une poignée de personnes différentes de ta cible, et que les réponses se ressemblent, tu as un problème qui vaut la peine d'être attaqué. Si tu n'arrives à en remplir aucune, ce n'est pas ton idée qui a un problème. C'est que tu n'as pas encore eu les bonnes conversations.

On y vient maintenant.

3. Tester le marché par interview

Tu as une pyramide. Tu as listé une fréquence, un coût, un workaround pour quelques personnes. C'est bien. Maintenant tu vas faire la chose que tout le monde dit qu'il va faire et que presque personne ne fait : tu vas appeler des gens.

L'objectif n'est ni de vendre ni de pitcher. Tu veux comprendre.

Pourquoi ce n'est pas naturel

Personne n'aime appeler des inconnus. Personne. Même les founders qui le font tous les jours t'avoueront, hors caméra, qu'ils repoussent le premier message de la journée. Le réflexe normal, c'est de remplacer l'interview par un sondage Tally, un poll LinkedIn, ou pire, une conviction. "Je connais mon marché, j'ai bossé dedans pendant cinq ans." C'est exactement comme ça qu'on dépense six mois à construire un produit pour la version d'il y a cinq ans d'un marché qui a bougé.

Une interview, dans ce contexte, ce n'est pas un entretien d'embauche. Ce n'est pas non plus un focus group. C'est une conversation de quinze à vingt-cinq minutes, en visio ou au téléphone, où la personne parle de sa vie professionnelle et où toi tu écoutes. Tu ne parles pas de ton idée. Tu ne montres pas de maquette. Tu n'expliques pas ce que tu veux construire. Tu poses des questions sur avant, sur ce qu'elle vit aujourd'hui, sans toi.

Rob Fitzpatrick, dans The Mom Test, le résume en une règle : si la personne en face peut répondre poliment sans rien savoir de ton idée, alors tu lui poses les bonnes questions.

La structure qui marche

Tu n'as pas besoin d'un script de douze pages. Tu as besoin de trois moments.

Le contexte. Tu commences par lui faire raconter une journée type, ou la dernière fois qu'elle a rencontré le problème que tu suspectes. Surtout, tu parles au passé. "La dernière fois que vous avez dû recopier des candidats d'un ATS vers un autre, vous pouvez me raconter comment ça s'est passé ?" Le passé, c'est du vécu. Le futur, c'est de l'imagination, et l'imagination ment.

La douleur. Tu creuses sur l'impact réel. Combien de temps ça lui a pris, à elle ou à son équipe ? Qu'est-ce qu'elle aurait préféré faire à la place ? Est-ce qu'elle s'est déjà énervée sur ce sujet en interne ? Si oui, devant qui ? Tu cherches les signaux d'émotion, parce que les émotions précèdent les achats. Personne ne sort sa carte bleue pour résoudre un inconfort tiède.

Le workaround. Tu termines par comment elle fait aujourd'hui. Outil acheté, fichier maison, stagiaire dédié, prestataire ? Est-ce qu'elle paye déjà pour une solution qui fait moitié du job ? Combien ? C'est la question la plus importante de toute l'interview, parce qu'elle te dit ce qu'elle est déjà en train de payer. Quelqu'un qui paye un outil qu'elle déteste, c'est un client. Quelqu'un qui n'a jamais cherché de solution, c'est rarement un acheteur.

À la fin, tu poses une dernière phrase, toujours la même : "Est-ce qu'il y a une autre personne dans votre réseau qui vit le même problème et avec qui je pourrais avoir cette conversation ?" Si la personne dit oui sans hésiter et te donne un nom, c'est un signal énorme. Si elle dit "euh, je vais voir", c'est que ton problème n'est pas si vif chez elle.

Comment trouver les gens

C'est la partie où la majorité bloque. Tu n'as pas besoin d'un CRM. Tu as besoin de cinq à dix conversations avec des gens qui matchent ta cible. Voici les endroits où ils sont, du plus simple au moins simple.

Ton réseau direct. Tu as déjà des collègues, des anciens collègues, des copains qui sont dans la cible, ou qui en connaissent. C'est le pool le moins gênant à activer. Pose la question en privé, jamais en post LinkedIn.

LinkedIn, en DM, à la main. Tu cherches ta cible via Sales Navigator si tu y as accès, ou via les filtres LinkedIn classiques. Tu envoies un message court, en disant que tu fais une recherche sur leur métier, que tu cherches quinze à vingt minutes, et que tu ne vends rien. Le ratio acceptation est faible et c'est normal. Vise une centaine de DMs sortis si tu veux dix interviews.

Les communautés où ta cible parle. Discord, Slack, sous-reddits, Facebook groups si ta cible y vit. Tu observes avant d'intervenir. Quand tu interviens, tu poses une vraie question, jamais ton lien Calendly en premier message.

Une intro chaude par quelqu'un qui te recommande. C'est l'option la plus puissante. Elle vient naturellement après tes trois premières interviews, parce que tu poses la question de fin.

Tu ne paies personne pour faire ces interviews. Tu offres ton temps en échange du leur. La gratitude se manifeste par un message de remerciement, et par le fait que tu reviennes plus tard partager ce que tu as appris.

Ce que tu écris pendant et après

Pendant l'interview, tu prends des notes courtes. Tu n'enregistres pas, sauf si tu as demandé l'accord. Tu notes des verbatim, c'est-à-dire les phrases textuelles que la personne dit. Pas tes interprétations, pas tes conclusions, ses mots à elle.

Juste après, tu te donnes cinq minutes. Tu remplis un mini-template, toujours le même.

Interview : prénom / rôle / boîte / date
Cible matchée : oui / non / partielle
Fréquence du problème : ...
Coût du problème : ...
Workaround actuel : ...
Verbatim qui m'a marqué : "..."
Signal de douleur : faible / moyen / fort
Référence donnée : oui / non

Au bout de cinq interviews, tu mets les huit fiches côte à côte. Tu cherches les phrases qui se ressemblent. Pas une fois, pas deux. Trois fois la même formulation, sur trois personnes différentes, c'est un pattern. Une fois, c'est une anecdote.

Le piège du "je t'avais bien dit"

Ton cerveau va vouloir entendre ce qui valide ton hypothèse. C'est mécanique, c'est le biais de confirmation, et même les meilleurs founders y tombent. La meilleure protection, c'est de lire tes notes avec une question contraire : "qu'est-ce que je viens d'apprendre qui devrait me faire arrêter ?". Pose-toi cette question à voix haute, à chaque pile de cinq fiches.

Si tu n'as rien à répondre, c'est suspect.

Si tu trouves quelque chose, c'est précieux. Tu viens de gagner du temps.

Ce qui doit rester sur ta feuille à la fin

Cinq à dix fiches d'interviews remplies, et un mini-paragraphe de synthèse en français simple, qui répond à trois questions :

Est-ce que les gens que tu as interviewés vivent vraiment le problème de ta ligne du milieu, fréquemment et avec une vraie douleur ?
Est-ce qu'ils paient déjà, ou bricolent, pour s'en sortir ?
Est-ce que ton hypothèse de pyramide tient debout après ces conversations, ou est-ce qu'elle a besoin de bouger ?

Si tu réponds non à une seule de ces trois, ce n'est pas un échec. C'est une économie de plusieurs mois. Tu retournes à la pyramide, tu modifies ce qui doit l'être, et tu reprends cinq interviews. C'est ça, le travail.

Si tu réponds oui aux trois, on passe à l'étape suivante : poser ton modèle sur une seule page.

4. Lean Canvas

Tu as une pyramide. Tu as cinq à dix interviews qui se ressemblent. Tu commences à voir un pattern.

C'est le moment de poser le reste sur une page.

Pourquoi une page, pas un business plan

Un business plan classique, c'est trente pages que personne ne lit, écrites pour rassurer une banque qui ne te financera pas de toute façon à ce stade. Tu écris ça quand tu sais déjà ce que tu fais. Au début, tu ne le sais pas. Tu as une série d'hypothèses, et tu cherches à les confronter au réel le plus vite possible.

Ash Maurya, un entrepreneur qui a galéré dans plusieurs startups avant d'écrire Running Lean, est parti du Business Model Canvas d'Alexander Osterwalder, un outil utilisé en grand groupe, et l'a adapté pour les startups très early. Sa version tient sur une page. Elle force à dire l'essentiel et à laisser ce qui ne sert à rien.

Tu vas remplir cette page. Mais pas dans l'ordre que la grille suggère. Pas non plus en commençant par ce qui te rassure. Tu commences par ce qui fait peur, parce que c'est là qu'il y a de l'information.

Les neuf cases, dans l'ordre où on les remplit vraiment

La page est divisée en neuf zones. L'ordre dans lequel tu les remplis compte beaucoup plus que la propreté de ta calligraphie.

1. Segments de clients (en haut à droite). Tu commences ici. C'est la ligne du haut de ta pyramide. Tu mets ta cible la plus précise possible. Si tu vises plusieurs segments, tu en choisis un seul pour cette page, et tu fais une autre page pour les autres plus tard. Une page, un segment. Pas de mélange.

2. Problème (en haut à gauche). Les trois problèmes principaux de ce segment, listés. Pas dix, trois. Si tu en as plus, c'est que tu n'as pas encore choisi celui qui mérite ton année. Tu peux aussi noter, juste en dessous, les workarounds actuels que tu as vus en interview. Cette case, c'est le résumé de ta ligne du milieu.

3. Proposition de valeur unique (au centre). Une phrase, lisible par un non-initié, qui dit ce que tu offres et pour qui. Pas de jargon. Pas de "plateforme tout-en-un". Pas de "révolutionner". Tu peux t'inspirer de la formule classique : "Pour [cible précise], qui [problème], on offre [solution] qui [bénéfice mesurable]." Ce n'est pas un slogan marketing. C'est un test de clarté.

4. Solution (en haut à gauche, sous Problème). Les trois plus petites features qui répondent aux trois problèmes. Pas tout ce que tu veux construire un jour. Juste ce qu'il faut pour vérifier ton hypothèse. C'est la ligne du bas de ta pyramide.

5. Canaux (à droite, sous Segments). Comment tu vas atteindre ces gens. Outbound LinkedIn, cold email, communautés Slack, événements, contenu LinkedIn, partenariats. Trois maximum, ceux que tu peux activer demain matin. Si tu écris "SEO" alors que tu n'as ni site ni article, ce n'est pas un canal, c'est un rêve.

6. Sources de revenus (en bas à droite). Combien tu vas faire payer, et comment. Pas de "freemium à étudier". Si tu ne sais pas, écris un prix au crayon. Cinquante euros par mois ? Mille euros par an ? Trois pour cent de leurs ventes ? Ce chiffre va bouger, et c'est exactement pour ça que tu dois en écrire un. Sans chiffre, tu n'as rien à confronter.

7. Structure de coûts (en bas à gauche). Ce que ton lancement va te coûter, en cash et en temps. Outils, hébergement, achats de leads, prestataires. Tu n'as pas besoin d'un fichier comptable. Une dizaine de lignes claires.

8. Indicateurs clés (au centre, sous UVP). Deux ou trois métriques que tu vas suivre cette semaine et la suivante. Nombre d'interviews bouclées, taux de conversion sur ta landing, nombre de paiements reçus. Si tu mets "MRR" alors que tu n'as zéro client, c'est de la fiction. Choisis des métriques que tu peux faire bouger toi-même cette semaine.

9. Avantage déloyal (en bas, sous UVP). La case la plus difficile, et celle que la plupart laissent vide trop vite. Qu'est-ce que tu as, toi, qu'un concurrent ne peut pas copier ? Un accès à un marché de niche, une expertise pointue, une communauté préexistante, une obsession qui te fait tenir quand les autres lâchent. "Première sur le marché" n'est pas un avantage, c'est une situation temporaire. Si tu trouves vraiment rien aujourd'hui, écris "à construire" et garde la case ouverte. La pire chose est d'inventer.

Hypothèse contre fait

Sur ta page, tu vas marquer chaque case avec un petit symbole. Un point d'interrogation quand c'est encore une hypothèse, c'est-à-dire ce que tu crois sans preuve. Une coche quand c'est validé par tes interviews ou par un fait observable.

À ce stade, ta page va être très majoritairement remplie de points d'interrogation. C'est normal. Le travail des prochaines semaines, c'est de transformer les points d'interrogation en coches, ou de changer ce qui est dans la case. Pas de tout valider d'un coup.

Tu peux te donner une règle simple : une case ne passe en coche qu'au moins trois fois confirmée sur trois personnes différentes, ou avec une donnée chiffrée vérifiable.

Le piège du "joli canvas"

Il existe des outils pour faire des Lean Canvas très propres. Canvanizer, Notion templates, Miro, Figma. Ils ne servent à rien tant que les cases sont fausses. Une feuille A4 griffonnée avec les bonnes hypothèses bat un canvas pastel rempli de banalités.

Tu peux écrire ton premier canvas à la main, en quinze minutes, sur le coin d'un bureau. Tu le reprends une fois par semaine. Tu raies, tu réécris. C'est un document vivant, pas un livrable à imprimer.

Ce qui doit rester sur ta feuille à la fin

Une page, neuf cases, remplies. Pour chaque case, un symbole hypothèse ou validé. Et en bas de la page, une seule phrase, écrite à part :

Hypothèse la plus risquée actuellement : ...

C'est celle que tu vas tester en priorité avec la prochaine étape. Parce qu'avoir un canvas plein de questions ne sert à rien si tu ne sais pas par où attaquer. Le point le plus risqué, c'est celui qui, s'il est faux, fait s'effondrer tout le reste.

Pour beaucoup de startups au début, c'est soit "est-ce que ce problème existe vraiment chez ce segment", soit "est-ce qu'ils vont payer le prix qu'on imagine". Si tu hésites, c'est sans doute l'une des deux.

On va aller la tester avec un MVP.

5. MVP : fake before make

Tu as une page. Tu as une hypothèse risquée. Tu pourrais maintenant passer six mois à construire ton produit. Tu n'as aucune raison de le faire.

Tu vas plutôt construire le plus petit truc capable de te dire si l'hypothèse tient.

Ce qu'un MVP n'est pas

MVP veut dire Minimum Viable Product. Trois mots qui ont été mal utilisés pendant quinze ans. Le piège, c'est de croire que MVP veut dire "version dégradée du produit final". Tu prends ton idée géniale, tu enlèves les features avancées, tu codes le reste, tu lances. Ça, ce n'est pas un MVP. C'est juste une bêta qui pue, et qui coûte aussi cher à produire.

Eric Ries, qui a popularisé le terme dans The Lean Startup, le définit autrement. Le MVP, c'est la plus petite chose qui te permet de vérifier l'hypothèse la plus risquée, avec le moins d'effort et le moins de code possible. Ce n'est pas un produit. C'est une expérience.

Et dans une expérience, l'important n'est pas que ça marche techniquement. C'est ce que tu apprends.

Trois patterns marchent particulièrement bien pour des founders qui démarrent. Tu n'en choisis qu'un, en fonction de ce que tu cherches à savoir.

Pattern 1 : la landing page (pour tester l'intention)

Tu crées une page web seule, sans produit derrière. Tu décris la promesse, à qui c'est destiné, ce que ça résout. Tu mets un bouton qui dit "Demander un accès" ou "Réserver", suivi d'un formulaire qui capte l'email ou un numéro. Tu envoies du trafic dessus : posts LinkedIn, DMs ciblés, communautés où ta cible vit, ads si tu as quelques dizaines d'euros à mettre.

Tu ne mesures pas combien de visites. Tu mesures combien de personnes laissent leur email ou cliquent sur "Je veux payer" si tu es prêt à ce niveau. Le ratio dit beaucoup. Cent personnes qui voient ta page, zéro qui veut en savoir plus, c'est un signal. Cent personnes qui voient ta page, vingt qui laissent un email pour beta tester, c'est un autre signal.

Le cas public le plus connu est Dropbox. En 2008, Drew Houston ne pouvait pas faire de démo réelle, parce que la techno qu'il voulait montrer n'était pas opérationnelle. Il a publié une vidéo de quatre minutes sur Hacker News, qui montrait l'expérience attendue. Sa liste d'attente est passée de cinq mille à soixante-quinze mille personnes en une nuit. Il avait validé qu'il y avait une demande, sans avoir produit le produit.

Tu n'as pas besoin de cinquante mille inscrits. Tu cherches à voir si quelqu'un, quelque part, dit "oui, prends mon email" avec un peu d'enthousiasme. Vingt à cinquante inscriptions qualifiées te suffisent largement à ce stade.

Pattern 2 : le Wizard of Oz (pour tester la valeur)

Le concept est simple. Tu fais croire à tes premiers utilisateurs que tout est automatisé, alors que tu fais le travail à la main, derrière. Comme dans le film, quand on tire le rideau et qu'on découvre que le magicien était un type avec des manivelles.

L'exemple le plus cité est Zappos, qui voulait vendre des chaussures en ligne avant que ce marché existe. Nick Swinmurn, le fondateur, ne savait pas s'il y aurait une demande. Il a pris des photos de chaussures dans des magasins physiques, les a mises sur un site basique. Quand quelqu'un achetait, il allait au magasin, achetait la paire, l'expédiait à la main. Aucune logistique automatisée. Il faisait l'expérience d'un site e-commerce, sans en avoir construit un seul.

Tu peux faire pareil pour à peu près n'importe quel SaaS. Un outil d'analyse ? Tu fais l'analyse toi-même dans un Google Sheet et tu envoies un rapport PDF. Un outil de matching ? Tu lis les profils à la main et tu fais les intros dans un mail. Un outil d'automatisation ? Tu fais tourner l'automation dans ta tête et tu envoies le résultat. L'utilisateur paie pour le résultat, pas pour la techno.

Le travail manuel est insoutenable à dix clients. C'est exactement le point. Tu n'es pas censé scaler ça. Tu es censé apprendre. Et tu apprends bien mieux en faisant chaque étape toi-même, que tu ne pourras le faire en lisant un dashboard six mois plus tard.

Pattern 3 : le concierge (pour tester la promesse)

Variante du Wizard of Oz, plus assumée. Tu ne caches pas que tu fais à la main. Tu dis explicitement à tes premiers clients : "Je vais m'occuper de votre cas personnellement pendant les premières semaines, le temps de comprendre ce qui marche pour vous." Le client le sait. Souvent il apprécie, parce qu'il a accès au founder en direct.

L'exemple souvent cité est Airbnb, dans ses tout débuts. Brian Chesky et ses cofondateurs allaient personnellement à New York chez les hôtes, prenaient les photos eux-mêmes, refaisaient les fiches d'annonce. Ils ne savaient pas si une plateforme suffisait. Donc ils ne supposaient pas qu'elle suffirait. Ils faisaient le travail.

Le concierge marche bien pour les promesses qu'on n'a jamais testées sur soi. Tu apprends, dans chaque interaction, ce qui compte, ce qui agace, ce qui surprend. Et tu construis la première version de ton produit avec un niveau de précision que tu ne pourrais pas atteindre par interview seule.

La règle qui va avec : tu factures dès la première semaine. Pas le prix final, pas forcément le prix juste, mais un prix. Le moment où quelqu'un sort sa carte, c'est le seul vrai signal. Tout le reste est de l'intention.

Quels outils en 2026

Si tu décides de partir sur une landing page, tu n'as pas besoin de coder. Plusieurs outils permettent à n'importe qui de mettre en ligne une page propre en quelques heures :

Framer (framer.com) : ergonomie design, bon SEO, idéal si tu veux un rendu soigné.
Webflow (webflow.com) : standard du marché côté no-code, plus de flexibilité.
Carrd (carrd.co) : minimaliste, parfait pour une seule page avec un formulaire de capture.

Pour générer une première version assistée par IA, v0 (v0.dev) et Lovable (lovable.dev) permettent de produire un site simple à partir d'un prompt. Le rendu n'est pas magique. Tu auras à éditer. Mais tu démarres en heures, pas en semaines.

Tu ne choisis pas le meilleur outil. Tu choisis celui que tu peux mettre en ligne cette semaine. La vitesse de boucle est plus importante que la propreté du résultat à ce stade.

Le piège du polish prématuré

Tu vas être tenté de soigner ton MVP. Le faire propre. Le faire joli. C'est compréhensible, surtout si tu viens du design ou de l'ingénierie. Tu vas devoir te retenir.

Un MVP bien produit, qui ne te dit rien sur ton hypothèse, est un échec coûteux. Un MVP moche, qui te donne un signal clair en cinq jours, est une victoire. Le but n'est pas que tes proches te disent "wahou c'est beau". Le but est que tu prennes une décision plus informée le vendredi qu'avant le lundi.

Si tu te trouves en train de retoucher la typographie du titre une troisième fois, tu es en train de procrastiner. Tu arrêtes, tu publies, tu envoies à dix personnes, tu observes ce qui se passe.

Ce qui doit rester sur ta feuille à la fin

Un MVP en ligne ou un concierge en cours, et une fiche d'expérimentation, toujours la même, qui dit :

Hypothèse testée : ...
Pattern choisi    : landing / wizard / concierge
Métrique cible    : ...
Seuil de succès   : ...
Délai             : ...
Résultat observé  : ...
Décision          : pivot / persist / kill

La dernière ligne, on va l'attaquer maintenant.

6. La boucle IMAP : pivot, persist, kill

Tu as un MVP en ligne, ou un concierge en cours. Tu observes ce qui se passe. À un moment, tu vas devoir trancher.

Trois options : tu pivotes, tu persists, tu tues. Pas une de plus, pas une de moins.

Pourquoi on ne sent rien sans boucle

Le piège qui tue le plus de projets, ce n'est pas le mauvais code, ni le mauvais marché. C'est l'absence de cycle. Tu lances quelque chose, tu regardes pendant trois mois en croisant les doigts, tu te dis "il faut laisser le temps", tu rajoutes une feature parce que quelqu'un l'a demandée, tu continues. Six mois plus tard, tu as bossé énormément, et tu n'as pris aucune décision réfléchie.

Eric Ries a popularisé une idée simple : pour apprendre quoi que ce soit, tu as besoin d'une boucle. Construire, mesurer, apprendre. Tu construis le plus petit truc qui répond à une question, tu mesures, tu décides quoi faire de l'information, tu recommences.

Dans la matérialisation swanbase, on appelle ce cycle IMAP. Quatre étapes, dans cet ordre, et c'est important.

Idée → Produire → Mesurer → Apprendre → (Idée)

L'ajout par rapport à la version d'origine, c'est l'étape "Idée" en amont. Tu ne te lances pas dans "Produire" parce que tu en as envie. Tu décides explicitement quelle question tu attaques, quelle hypothèse tu testes, et qu'est-ce qui validera ou invalidera.

La cadence : une semaine, idéalement 48h

À ce stade, ta boucle doit tourner vite. La cible, telle qu'elle est cadrée chez swanbase, c'est une boucle par semaine, idéalement quarante-huit heures. Tu ne vas pas tenir cette cadence chaque semaine. Mais c'est l'horizon vers lequel tu pousses, et chaque fois que tu déroges, tu sais que tu perds du temps.

Une boucle d'un mois, c'est confortable. Trop confortable. Tu fais une chose, tu attends, tu en fais une autre. Au bout d'un an, tu as appris douze fois. Une boucle d'une semaine te fait apprendre cinquante fois. Une fréquence par cinq, c'est colossal sur la trajectoire d'un projet.

Pour tenir cette cadence, il y a deux règles dures :

Une boucle = une seule hypothèse. Pas trois questions empilées dans la même expérience. Si tu testes en même temps le canal d'acquisition, le prix et la promesse, tu n'apprends rien sur aucun des trois. Tu fais des changements séquentiels.

Une boucle se termine par une décision écrite. Pas une intuition gardée pour toi. Une phrase, dans un fichier, qui dit ce que tu as appris et ce que tu fais ensuite. Sans ça, tu boucles dans le vide.

Les trois décisions possibles

À la fin d'une boucle, tu as exactement trois options. Pas dix. Trois.

Persist. L'hypothèse tient. Le signal est là, modeste ou fort, mais lisible. Tu doubles. Tu refais la même expérience, en plus grand, ou tu attaques la prochaine hypothèse risquée du Lean Canvas. La persistance n'est pas de la passivité. C'est une décision active de doubler la mise sur quelque chose qui marche.

Pivot. L'hypothèse ne tient pas, mais tu as appris quelque chose qui change ce qu'il faut tester. Le segment était trop large, mais une sous-niche réagit. Le prix était mal calé, mais les gens payent volontiers pour une version dégradée. Le pivot, c'est garder ce qui marche, changer ce qui ne marche pas. Pas tout jeter, pas tout garder. Tu mets à jour ta pyramide, ton canvas, et tu repars sur la boucle suivante.

Kill. Aucun signal. Trois boucles consécutives qui n'apprennent rien. Le marché ne réagit pas, et ton intuition te dit qu'il ne réagira pas avec une nième variation. Là, tu tues. C'est la décision la plus rare, et la plus mature. Tuer un projet sur lequel tu as mis trois mois est dur. C'est aussi ce qui te libère du temps pour le bon projet, qui est probablement le suivant.

Les pièges des trois décisions

Chaque décision a son piège, et c'est rarement celui qu'on imagine.

Le piège du Persist : continuer par défaut. Tu n'as pas vraiment un signal, mais tu n'as pas envie d'arrêter, donc tu refais la même chose. Ce n'est pas du Persist, c'est de l'inertie. Le vrai Persist a un signal concret, écrit, qui justifie de doubler.

Le piège du Pivot : pivoter par mode. Tu lis un thread Twitter sur une niche à la mode, tu pivotes vers cette niche, tu pivotes encore la semaine suivante. À cette vitesse, tu ne testes rien, tu cours après le bruit. Un vrai Pivot vient d'une donnée que tu as observée toi-même dans tes boucles, pas d'un thread.

Le piège du Kill : tuer par fatigue. Tu as eu deux semaines difficiles, ton expérience n'a pas marché, tu décides de tout arrêter. Le Kill mérite un délai de réflexion d'au moins 48 heures, et idéalement une conversation avec quelqu'un qui t'a vu bosser dessus. L'idée n'est pas qu'on te convainque de continuer, mais que tu vérifies que tu ne décides pas sous le coup de l'épuisement.

Le journal de boucles

À partir de maintenant, tu tiens un journal. Pas un blog, pas une newsletter. Un fichier privé, où tu loges chaque boucle. Le format peut tenir en quatre lignes.

Boucle n° / dates :
Hypothèse testée :
Résultat observé :
Décision (P/P/K) + raison :

Au bout de cinq boucles, tu relis. Tu vas voir ce qu'aucun dashboard ne te dirait. Les patterns dans tes propres décisions. Les hypothèses qui ressortent. Les choses que tu te promets toujours et que tu repousses toujours. Le journal est l'outil que les bons founders gardent et que les autres oublient.

Ce n'est pas pour la postérité. C'est pour toi, dans trois mois, quand tu auras besoin de te rappeler ce que tu avais déjà essayé.

Comment savoir si tu boucles trop vite ou trop lentement

Trop lent, c'est facile à repérer. Si tu n'as pas tranché en deux semaines, tu as un problème de cadence. Souvent ce n'est pas un problème d'idée, c'est un problème d'expérience mal calibrée, trop grosse, qui demande des semaines de prod avant de mesurer quoi que ce soit. Réduis la taille de l'expérience, pas le temps de réflexion.

Trop vite, c'est plus subtil. Si tu changes d'hypothèse tous les trois jours, sans avoir laissé le temps à la donnée d'arriver, tu n'apprends rien non plus. Un cold email envoyé à dix personnes ne te dit rien sur l'efficacité du canal. Cent, oui. Le seuil minimal pour tirer une conclusion dépend du test, mais une règle saine : tu te demandes "combien il faut d'observations pour que je sois prêt à miser sur le résultat ?". Si la réponse est cinq, tu en fais au moins cinq.

Ce qui doit rester sur ta feuille à la fin

Un journal vivant, alimenté à chaque cycle. Et après chacune des cinq premières boucles, une page de synthèse, courte, qui répond à trois questions :

Quelle est la chose la plus surprenante que tu as apprise cette semaine ?
Qu'est-ce qui a confirmé ou invalidé ta plus grosse hypothèse du Lean Canvas ?
Quelle est la prochaine hypothèse la plus risquée à tester ?

Si tu peux répondre à ces trois questions chaque semaine, tu es dans le bon rythme. Si tu n'arrives à répondre à aucune, tu n'as pas vraiment fait une boucle. Tu as bossé sans direction.

La porte de sortie de ce chapitre

Tu sais que tu peux passer à CH2 quand trois choses sont vraies :

Ta pyramide est stable. Tu n'en changes plus à chaque conversation. Elle a tenu sur trois boucles consécutives.
Tu as une poignée de personnes qui paient ou se sont engagées à payer, même de façon symbolique, pour ce que tu fais.
Tu sais articuler ta proposition en une phrase, et quand tu la dis, la posture en face change.

Ces trois conditions ne sont pas des victoires. Ce sont des conditions minimales pour mériter de passer à l'étape suivante, où on va attaquer les dix premiers clients qui paient pour de vrai, à la main, un par un.

C'est ce qu'on fait dans le chapitre suivant.

CH1 . Tu as ton problème, ton MVP, tes premiers signaux

Tu n'es plus en train de "réfléchir à une idée". Tu as une pyramide, des interviews qui se ressemblent, un MVP en ligne, et une boucle IMAP qui tourne. Tu as fait la chose la plus dure du parcours d'un founder : tu as accepté de chercher le problème avant de chercher la solution.

C'est rare. La plupart de ceux qui passent six mois à coder n'ont pas ça.

L'artefact que tu dois avoir

À la fin de ce chapitre, tu devrais pouvoir, en cinq minutes, montrer à un inconnu :

Une pyramide CPS écrite : une cible précise, un problème nommé avec fréquence-coût-workaround, une solution en une phrase.
Cinq à dix conversations dont tu peux citer les phrases au passé (pas ce que les gens "pensent", ce qu'ils ont fait).
Un Lean Canvas rempli, ordre 1 à 9, avec des "?" honnêtes sur les cases hypothétiques.
Un MVP testable : landing page, Wizard of Oz, ou concierge. Pas trois patterns en parallèle.
Au moins trois boucles IMAP terminées, chacune avec une décision écrite (pivot, persist, kill).

Si tu coches ces cinq cases, tu as un problème validé chez 5 à 10 personnes réelles. C'est ton point de départ pour vendre.

Le piège qui te guette

Tu vas être tenté de rester en CH1. C'est confortable. Tu apprends. Tu pivotes. Tu ne risques pas le rejet d'une vente. À un moment, l'apprentissage devient une excuse pour ne pas affronter le mur du paiement. Si tu boucles depuis trois mois sans avoir reçu un euro, tu n'es plus en Lean, tu es en procrastination structurée.

Le signal que tu es prêt pour CH2 : tu as un MVP qui suscite des "où je signe ?" non sollicités, ou ton concierge a déjà reçu un premier paiement informel.

Ce qui t'attend en CH2

Tu vas passer de "apprendre" à "vendre". L'intention change : tu ne testes plus une hypothèse, tu cherches dix personnes qui te paient, à la main, sans te cacher derrière un funnel automatisé. Tu vas signer ton premier prix v1, tester trois canaux, et installer chez tes premiers utilisateurs comme un concierge.

Pas de growth hack, pas d'industrialisation. La main, le téléphone, le DM.