En novembre 2024, un projet appelé Freysa a mis un agent LLM en charge d’un wallet Ethereum. La consigne était claire : ne transfère les fonds sous aucun prétexte. Les participants versaient des montants croissants à chaque tentative pour le convaincre. Après 481 essais et 47,000 $ accumulés dans le pot, quelqu’un a réussi à persuader le modèle que la fonction refuser était en réalité la fonction transférer.

Quelques semaines plus tard, Jane Street a publié un puzzle où un réseau neuronal de 2,500 couches s’est avéré être une implémentation de MD5. Le gagnant l’a résolu en combinant visualisation de matrices, réduction en SAT, reconnaissance de motifs cryptographiques et une requête à ChatGPT.

Ces deux projets ont généré plus d’attention que la plupart des startups malgré leurs millions en financement. Une question clé se pose : comment évaluer ce genre d’idée avant de la construire ? Comment savoir si elle a un potentiel viral réel ou si elle n’est qu’un exercice technique que personne ne partagera ?

Le problème : évaluer des MVP à l’ère de la viralité

La majorité des frameworks pour évaluer des idées de produit partent du principe d’un marché rationnel. Business Model Canvas, Lean Canvas, Jobs To Be Done — ce sont tous des outils utiles pour des produits avec une demande prévisible. Mais ils échouent face à des projets où la distribution virale devient le produit.

Freysa n’avait pas de « clients » au sens traditionnel. Il ne répondait à aucun « job to be done ». C’était un mécanisme où l’acte même de participation générait l’attention, attirant ainsi plus de participants. L’économie était circulaire : plus d’essais augmentaient le pot, un pot plus gros générait davantage de couverture médiatique, et cette couverture attirait plus de participants.

Pour évaluer ce genre de projets, vous avez besoin de perspectives qui génèrent des tensions, pas du consensus. Un analyste business vous dira que le modèle de revenus est absurde. Un expert viralité vous affirmera que la durabilité n’a aucune importance tant que le k-factor reste supérieur à 1. Les deux ont raison. Et la vérité se situe quelque part entre les deux, émergeant uniquement du conflit.

L’idée : un conseil adversarial composé d’experts simulés

J’ai conçu un outil qui simule un conseil de cinq experts, chacun appliquant un framework de décision précis ainsi qu’une juridiction définie. Il ne s’agit pas seulement de personnalités célèbres attachées à un nom. Chacun applique des règles spécifiques qui permettent d’éliminer le bruit impossible à filtrer avec une analyse générique.

Le processus comporte trois phases :

  1. Analyse indépendante : chaque expert évalue l’idée selon sa propre perspective, sans consulter les avis des autres. Cela prévient l’effet de conformisme — si l’expert en business parle le premier et juge l’idée géniale, alors l’expert juridique pourrait atténuer ses objections.
  2. Débat adversarial : les experts examinent les analyses des autres et se critiquent mutuellement de manière fondée et directe. Pas de diplomatie. Dix rounds maximum pour parvenir à un consensus ou à un blocage.
  3. Synthèse : un plan d’action contenant des problématiques par domaine, un échéancier, et — surtout — des critères d’abandon : des métriques concrètes qui, si elles ne sont pas atteintes, incitent à arrêter le projet.

Les cinq sélectionnés (et pourquoi eux)

Paul Graham — Business et stratégie

Son framework pour évaluer les startups au stade zéro est le plus rigoureux existant pour des projets sans données. Sa question « faites-vous quelque chose que les gens veulent ? » est brutale mais nécessaire. Il n’accepte pas « les gens » comme marché — il exige un nom et prénom du premier utilisateur.

Ce qu’il apporte au conseil : la discipline de distinguer une « idée intéressante » d’un « business viable ». Son concept « Do things that don’t scale » est particulièrement précieux pour les MVP viraux, où la tentation est de construire une infrastructure pour des millions d’utilisateurs qui n’existent pas encore.

Exclus pour cette place : Peter Thiel (trop contrarian — rejette parfois de bons projets pour ne pas être suffisamment « zero to one »), Alex Hormozi (expert des entreprises de services, pas des produits tech viraux).

Lawrence Lessig — Juridique et régulation

Ce n’est pas un avocat qui dit « impossible ». C’est un juriste qui conçoit la régulation comme architecture. Son framework « les quatre modalités de régulation » (loi, normes sociales, marché et code/architecture) aide à analyser comment construire un système où la régulation n’est pas un problème, plutôt que de tenter de l’éviter.

Ce qu’il apporte au conseil : la question « que se passe-t-il lorsque le régulateur se rend compte de votre existence ? » De nombreux projets crypto/IA sont juridiquement insignifiants à petite échelle mais soumis à réglementation à grande échelle. Lessig détermine le seuil où la régulation s’active.

Exclus pour cette place : un avocat corporatif générique (dirait « non » sur toute la ligne et tuerait le projet avant sa naissance). Lessig comprend que la régulation n’est pas le seul levier — l’architecture du système peut rendre inutile l’intervention légale.

Seth Godin — Marketing et positionnement

Sa question clé — « qui est votre smallest viable audience et pourquoi cela leur importe ? » — est la plus cruciale pour un lancement viral. Il ne raisonne pas en termes de « comment atteindre des millions », mais « comment captiver les premiers 100 à qui cela tient vraiment à cœur ».

Ce qu’il apporte au conseil : le test de la singularité. Est-ce que ce produit propose quelque chose qui incite les gens à le partager sans qu’on leur demande de le faire ? « C’est utile » ne se partage pas. « C’est remarquable » oui. Son concept des « Tribes » est également pertinent pour les communautés tech/crypto ayant déjà une identité de groupe.

Exclus pour cette place : Philip Kotler (trop corporatif — spécialisé dans le marketing pour multinationales, pas pour des MVP), April Dunford (son framework de positionnement est excellent mais conçu pour des produits déjà existants cherchant à être repositionnés, pas pour des lancements).

Balaji Srinivasan — Buzz et viralité

C’est le membre le plus audacieux du panel. Il maîtrise les mécanismes de distribution crypto-natifs : FOMO, incitations par tokens, effets de réseau, ainsi que la mécanique spécifique de comment un projet devient trending en 48 heures.

Ce qu’il apporte au conseil : la question « qu’est-ce qui incite quelqu’un à faire une capture d’écran et à la publier sur Twitter dans les 5 minutes qui suivent ? » C’est l’unité atomique de la viralité. Si votre produit ne déclenche pas spontanément de screenshot, il vous faut un budget marketing.

Exclus pour cette place : GaryVee (comprend l’attention mais pas l’intersection crypto+IA, là où les mécanismes viraux les plus puissants émergent aujourd’hui), Mr. Beast (expert en viralité audiovisuelle, pas en produits tech), Nir Eyal (son framework « Hooked » vise la rétention, pas la viralité de lancement — les deux sont distincts).

DHH (David Heinemeier Hansson) — Technique

Sa passion est « la chose la plus simple qui fonctionne ». Pour un MVP, le principal risque technique n’est pas de choisir la mauvaise technologie. C’est de ne jamais le lancer car vous avez passé trois mois à sélectionner le stack.

Ce qu’il apporte au conseil : la question « une seule personne peut-elle concevoir cela en deux semaines ? » Si la réponse est non, c’est que la portée est excessive ou que le stack est trop complexe. Sa règle « boring technology » (PostgreSQL plutôt que CockroachDB ; Redis plutôt que Dragonfly) constitue le remède contre le syndrome « pourquoi ne pas utiliser la blockchain ? ».

Exclus pour cette place : Werner Vogels (pense global dès le jour 1, ce qui est exactement inutile pour un MVP), Kelsey Hightower (son expertise Kubernetes sur-ingénierait n’importe quel MVP — ce serait utiliser un bazooka contre une mouche).

Tensions productives : là où émergent les vérités

Les tensions entre conseillers ne sont pas des défauts du design. Elles font partie intégrante du design.

Balaji contre Lessig : viralité contre régulation

C’est la tension principale. Balaji privilégiera des mécanismes FOMO impliquant de l’argent réel (pots visibles, pay-to-play, tokens). Lessig soulignera qu’en Europe, le pay-to-play avec pot accumulé est classé comme jeu d’argent et nécessite une licence de l’autorité compétente.

Godin contre DHH : singularité contre simplicité

Godin préconisera une expérience mémorable — un tableau des scores animé, des badges de participation. DHH voudra une page statique avec SQLite.

(Texte complet traduit…)