Partager son idée de startup sur Reddit : le vol d'idée est-il un vrai risque ?

Un fondateur qu'on connaît a passé 14 mois en stealth mode sur une idée de « Notion pour essais cliniques ». NDA sur sa designer. Nom de couverture sur son repo GitHub. Il refusait de montrer la wireframe à un cofondateur potentiel sans NDA mutuel signé. Quatorze mois. Pendant qu'il affinait le carnet d'adresses de son avocat, un open builder a livré un produit quasi identique sur Twitter, atteint 14 000 $ MRR au troisième mois et répondu au thread « quelqu'un travaille là-dessus ? » de la niche subreddit avec une capture Stripe.

Il ne s'est pas fait voler. Il s'est fait dépasser par quelqu'un qui avait choisi l'invisibilité comme étant le plus gros risque, et qui agissait en conséquence.

Notre thèse : pour 95 % des cas, le vol d'idée est un risque à faible probabilité et faible impact qui sert à éviter la réalité à haute probabilité et haut impact d'être ignoré. Les données — l'absence de cas de vol et la présence de wins en public — pointent dans la même direction. Parlez fort. La menace, ce n'est pas le lurker. La menace, c'est le silence.

La fréquence réelle du vol d'idée au pré-seed

On a lu beaucoup de threads de fondateurs. Probablement plus que ce qui est sain. À travers les postmortems IndieHackers, les chaînes de commentaires Show HN, r/SaaS, r/startups, la longue traîne des solo-founders sur Twitter — quelque part dans les milliers de threads — le nombre d'histoires crédibles de type « un inconnu a lu mon idée partagée publiquement et l'a livrée avant moi » est à peu près zéro.

Il y a des histoires de cofondateurs qui se brouillent. Des histoires de freelances qui partent dans le décor. Des histoires d'ex-employés qui lancent un quasi-clone. Tout ça est réel — et c'est une autre catégorie. Ce sont des gens qui avaient votre contexte complet, votre liste clients, vos discussions de cap table. Pas des inconnus sur Reddit.

Le dossier juridique va dans le même sens. Les procès pour appropriation d'idée business au stade pré-seed sont extrêmement rares. Les rares qui existent impliquent presque toujours un ex-employé, un développeur sous contrat ou un litige cofondateur — des relations construites sur des spécifiques partagés, pas des posts Reddit. Les procès « idée seule » ne mènent nulle part parce que la plupart des juridictions ne reconnaissent pas une idée non protégée comme propriété. On ne peut pas attaquer quelqu'un parce qu'il a entendu votre concept et tenté le coup.

Le scénario du lurker — un utilisateur Reddit anonyme lit votre post un mardi à 23h, plaque son job, apprend votre industrie, trouve votre audience, construit le produit, monte le funnel et livre avant vous — n'a pas été documenté de façon crédible à un volume qui compte. Pas dans les vingt ans de postmortems YC. Pas dans l'archive IndieHackers. Pas dans le dossier juridique.

Comparez à la probabilité de passer six mois à construire un truc dont personne ne veut, parce que vous n'avez pas testé en public. Sur les mêmes threads de fondateurs, celle-là, c'est la règle, pas l'exception.

L'argument Pieter Levels : livrer en public, gagner en public

Le contre-argument live le plus fort à la peur du vol d'idée, c'est le banc des indie hackers. Pieter Levels construit plus de 3 M$/an de revenu sur Nomad List, Remote OK et ses side projects, ouvertement, sur Twitter, avec le code source à moitié visible. Ses threads de bilan annuel capturent ses dashboards Stripe réels. Il a posté son MRR chaque mois pendant presque dix ans. Il a écrit son stack sur un seul fichier PHP, et il l'a tweeté.

Personne ne l'a copié dans l'oubli. L'inverse — l'ouverture était le moat. Pieter s'est construit une réputation d'indie hacker que les indie hackers lisent, et l'audience qui va avec a converti en utilisateurs payants. Le funnel de transparence était plus gros que toute menace de clonage imaginable.

Marc Lou applique la même méthode. ShipFast, IndieVoice, ZenVoice — captures Stripe ouvertes, roadmap publique, chaque tweet « j'ai fait X $ cette semaine » devient un événement marketing. Sa collection de side projects a passé le million d'ARR en diffusant ses étapes de build et ses tests de prix à un demi-million de followers Twitter. Les clones existent. Aucun ne le rattrape, parce qu'aucun n'a son audience ni son rythme d'exécution.

Tony Dinh joue la même partition depuis Singapour. TypingMind, BlackMagic, et un stack de micro-produits — tous construits fort, tous monétisés, tous distançant les copycats post-launch par pure vitesse d'itération. Sa formulation sur la peur du lurker : « Tous ceux qui pourraient copier mon produit sont déjà occupés à copier le produit de quelqu'un d'autre. »

Ces trois-là ne sont pas des cas isolés. C'est la partie visible d'une génération entière d'indie hackers qui traite le build in public comme une feature, pas une vulnérabilité. Daniel Vassallo, Justin Welsh, Arvid Kahl, Sahil Lavingia — tous appliquent la même méthode dans des verticales différentes, tous franchissent les sept chiffres en diffusant à peu près tout.

Ce qu'ils ont en commun, ce n'est pas la protection IP. C'est l'audience. L'audience, c'est ce qu'un voleur d'idée ne peut pas répliquer.

Pourquoi même les grosses boîtes ne volent presque jamais une idée précoce

L'objection plus profonde — « OK, des inconnus ne le feront pas, mais une grosse boîte pourrait voir ma landing page et cloner la feature » — passe le même test de réalité.

Les grosses boîtes ne pivotent pas à cause de la landing page d'un inconnu. Leur roadmap est gelée six mois à l'avance, leurs PMs tournent sur les OKR du trimestre dernier, leur équipe juridique a une liste de risques d'infraction de brevet qui les intéressent, et un wedge testé sur Reddit par un fondateur sans nom n'est pas dans cette liste. Si un « clone » apparaît, il était déjà sur la roadmap d'un concurrent avant votre post. Votre test a fait remonter un risque concurrentiel existant plus tôt que ce que vous auriez vu autrement. C'est une feature, pas un bug — vous préférez découvrir la concurrence à six mois ou à six jours ?

L'exemple Dropbox est éclairant. Drew Houston a posté sa vidéo de démo sur Hacker News en avril 2007, sur YouTube la même semaine. Au moment où Microsoft Live Mesh est sorti dix-huit mois plus tard, Dropbox avait des centaines de milliers d'utilisateurs et une marque. La démo publique de Houston a construit le moat ; Microsoft allait livrer cette feature de toute façon. La publicité n'a pas déclenché le clone. Le clone était sur la roadmap de Microsoft depuis le début.

Le pattern tient à chaque étage. Notion était public depuis des années avant Microsoft Loop. Figma était bruyant des années avant qu'Adobe XD ne devienne sérieux, et puis Figma a été racheté quand même. Linear assumait sa philosophie de build dès le lancement. Les boîtes qui ont gagné se sont rendues visibles tôt. Celles qui se cachaient se sont fait dépasser par celles qui ne se cachaient pas.

Le vrai coût du silence

On a vu le scénario silencieux se rejouer plein de fois. Ça ressemble à ça :

• Mois 1-2 : le fondateur valide auprès d'amis, de la famille, de trois « advisors de confiance ». Tout le monde dit que c'est génial.
• Mois 3-6 : le fondateur construit en privé. Le pitch cofondateur se fait autour d'un café, jamais sur un deck public.
• Mois 7-9 : lancement. Le public voit le produit pour la première fois. Conversion : 0,8 %. Le produit est faux à trois endroits qu'un test landing page public aurait attrapés en semaine 1.
• Mois 10 : le fondateur réalise que la validation n'a jamais eu lieu. Six mois de build sont partis dans un truc auquel le marché a haussé les épaules.

Le coût du secret, c'est le signal de validation que vous n'avez pas eu. Ce n'est pas hypothétique. On a chiffré ça dans comment valider une idée de produit pas cher — 150 à 300 € de trafic payant sur 14 jours attrapent environ 80 % des cas « ça ne marchera pas » que les builds privés ratent. Échangez ce test contre neuf mois de stealth et le calcul est brutal : vous payez 30 000 €+ en coût d'opportunité (votre temps à n'importe quel taux horaire raisonnable) pour éviter un risque à 0 €.

Les 10 histoires de how founders validated their SaaS — huit qui passent, deux qui tuent l'idée — ont presque toutes été menées en public. Cross-posts Reddit. Teasers Twitter. Lancements adjacents à ProductHunt. Le signal est venu parce que les fondateurs étaient trouvables.

Les quatre cas où la protection IP compte vraiment

On ne plaide pas pour la transparence absolue. Il y a des cas réels où resserrer l'idée est le bon choix. Quatre, précisément.

1. Deep tech brevetable. Nouveaux algorithmes, hardware nouveau, composé biotech, invention mécanique. La divulgation publique peut compromettre la brevetabilité dans la plupart des juridictions hors États-Unis (les US accordent un délai de grâce d'un an ; l'UE et la plupart de l'Asie, non). Si un brevet fait partie de votre moat, déposez un provisoire avec un avocat USPTO ou EPO avant que la landing page parte en public. C'est rare en software — la plupart des idées software ne sont pas brevetables — mais en biotech, hardware, science des matériaux, prenez ça au sérieux.

2. Industries régulées avec clients beta nommés. Santé, banque, défense, administration — le process achats de votre client beta vous interdit déjà de les nommer publiquement. L'idée peut être publique ; le client, non. C'est de la discrétion opérationnelle, pas de la protection d'idée.

3. Effet réseau avec un mécanisme brevetable. Une marketplace, un produit social ou un outil de coordination où le moat est dans la logique de matching/pricing/coordination, et où cette logique elle-même est brevetable. C'est rare — la plupart des effets réseau viennent de l'exécution, pas des brevets — mais si vous construisez le prochain mécanisme d'enchère style eBay avec une vraie nouveauté technique, brevetez avant de parler.

4. B2B avec un wedge à client unique nommé. Si tout votre wedge tient dans « j'ai un engagement verbal d'Acme Corp », le partager publiquement alerte des concurrents qui pourraient retourner le même wedge contre vous. Validez la catégorie de demande en public. Gardez la relation nommée privée jusqu'à signature.

Pour tous les autres — fondateurs solo, indie hackers, micro-SaaS, le cas à 95 % — le secret ne vous achète rien et vous coûte tout. Choisissez le risque le moins cher.

Ce qu'il faut partager, ce qu'il faut garder

Même dans le cas public-par-défaut, il y a une asymétrie utile : les parties d'une idée qui attirent le signal de demande ne sont pas les mêmes que celles qui construisent le moat. Partagez les premières généreusement. Gardez les secondes.

Partagez le problème. « Les designers freelances perdent 40 minutes par projet à trier le feedback client. » Ça existait avant vous, ça ne vous coûte rien, ça signale aux utilisateurs que vous les comprenez.

Partagez le résultat. « Un seul doc de feedback consolidé par round, en 60 secondes, sans threads Slack. » Voilà ce que les utilisateurs paieront. Le partager, c'est ça, le test de validation — c'est tout l'intérêt.

Partagez le prix. « 19 €/mois, gratuit pour les 100 premiers fondateurs. » Le prix est le plus puissant extracteur de signal. Le cacher rend le test bien moins utile.

Gardez le mécanisme. La chaîne de prompts précise, la logique de scraping propriétaire, le workflow en cinq étapes qui rend le résultat livrable à coût bas. C'est ça votre exécution. C'est ce qui prendrait à un concurrent un vrai temps à répliquer.

Gardez les clients nommés tant que vous n'avez pas leur accord. « Une agence de design de 12 personnes à Berlin », c'est bon. « Studio Mueller à Berlin », ça demande leur accord explicite.

On a couvert le playbook complet sans MVP dans valider sans MVP ; cet article est le pendant côté public. La version courte : montrez le quoi, cachez le comment. Le signal de demande vit dans le quoi. Le moat vit dans le comment.

La vérité plus dure

Le vol d'idée est un risque à faible probabilité et faible impact que les fondateurs utilisent pour éviter la réalité à haute probabilité et haut impact : construire un truc dont personne ne veut. L'économie est à l'envers. Les gens gèrent le petit risque obsessionnellement et ignorent le gros parce que le gros est plus dur à regarder en face.

Le lurker Reddit ne vient pas chercher votre idée. Le marché, c'est ça la menace — et le marché ne se distance pas en se cachant. Il ne se répond qu'en se montrant.

Publiez la page. Lancez les ads. Tweetez le build. Le pire cas, c'est un test silencieux qui vous dit de pivoter. Le meilleur, c'est l'audience que tout le banc des indie hackers a construite de la même façon : en public, sur le compte officiel, vite.

Validez votre idée sur LemonPage — landing page, trafic payant et mesure de conversion dans un seul workflow. Les builders en stealth nous posent des questions IP. Les fondateurs en public nous posent des questions de CPL. Une seule de ces questions mène à un client payant.

Le fondateur des 14 mois, au passage, a fini par livrer un autre produit dans le même espace. Bruyant, public, sur Twitter. Il en est à 70 clients payants, huit mois après. La première version est dans son cimetière — voir le cimetière des idées inachevées pour la raison structurelle pour laquelle les builds silencieux meurent en silence. La deuxième version lui a coûté un quart du temps et dix fois le signal. Le seul « vol » qui a vraiment eu lieu, c'est l'année qu'il s'est volée à lui-même.

FAQ

Est-ce qu'on s'est déjà vraiment fait voler une idée après l'avoir postée sur Reddit ?
Sur des milliers de threads de fondateurs passés au peigne fin sur IndieHackers, Hacker News, r/SaaS et r/startups, on trouve à peu près zéro cas crédible où un inconnu lit une idée partagée publiquement et la livre en premier. Les cas qui sont cités impliquent presque toujours un freelance, un ex-employé ou un litige entre cofondateurs — des relations avec contexte complet, pas des lurkers anonymes. Le scénario « inconnu sur Reddit » est le plus craint et le moins documenté du folklore fondateur.

Pourquoi des indie hackers comme Pieter Levels ou Marc Lou construisent-ils en public ?
Parce que l'audience est le moat. Pieter Levels génère plus de 3 M$/an avec Nomad List et Remote OK en publiant ses captures Stripe. Marc Lou a passé le million d'ARR en postant ses étapes de build chaque jour. Tony Dinh livre des micro-produits avec une roadmap publique. La transparence se transforme en confiance, en distribution et en conversion qu'aucune protection IP ne peut copier. Aucun n'a été cloné de façon significative, parce qu'aucun clone n'a leur audience ni leur rythme d'exécution.

Quand faut-il vraiment garder son idée privée ?
Quatre cas précis : invention brevetable en deep tech, biotech ou hardware (déposez le provisoire d'abord) ; industries régulées avec clients beta nommés (les règles de procurement interdisent de nommer) ; produit à effet réseau avec un mécanisme de matching brevetable ; deal B2B avec un wedge à client unique nommé. En dehors de ces cas, le secret ne vous achète rien et vous coûte le signal de validation que vous auriez eu autrement.

Une grosse boîte ne va-t-elle pas copier ma feature si elle voit ma landing page ?
Quasi jamais, et jamais à cause de votre landing page. Les roadmaps des grosses boîtes sont gelées six mois à l'avance. Si un concurrent livre une feature similaire, elle était déjà planifiée. Votre test public fait remonter un risque concurrentiel existant plus tôt — c'est une feature, pas un bug. Microsoft Live Mesh allait sortir de toute façon ; la démo publique Dropbox de Drew Houston ne l'a pas déclenchée, et Dropbox a gagné le marché en se rendant visible le premier.

Comment partager assez pour avoir du signal de demande sans donner le wedge ?
Appliquez la règle partager/garder. À partager : le problème (« les designers perdent 40 minutes sur le feedback »), le résultat (« un seul doc consolidé, 60 secondes ») et le prix (« 19 €/mois »). À garder : le mécanisme (la chaîne de prompts, la logique de scraping, le workflow qui rend la livraison pas chère), les clients beta nommés sans accord, l'unit economics. Le premier ensemble attire le signal. Le second est ce qui prendrait du vrai temps à un concurrent pour être répliqué. Montrez le quoi, cachez le comment.

Les idées software sont-elles seulement brevetables ?
Le plus souvent non. Une simple méthode business en logiciel, un pattern d'UI ou un « X pour Y » n'est généralement pas brevetable en Europe et a un seuil très haut aux États-Unis depuis Alice v. CLS Bank. Les vrais nouveaux algorithmes, les combinaisons hardware-software, certaines inventions de traitement du signal le sont parfois. Si un avocat brevet ne vous a pas indiqué la revendication précise éligible, c'est probablement que votre idée ne l'est pas — et la peur IP est mal placée. L'exécution est le moat dans 95 % des cas.