Mythe des infrastructures cryptographiques : pourquoi la simple construction ne garantit pas l'adoption ?
TechFlow SélectionTechFlow Sélection
Mythe des infrastructures cryptographiques : pourquoi la simple construction ne garantit pas l'adoption ?
Construire « n'importe quoi » est difficile.
Dédié à des analyses Web3 approfondiesAuteur : Saneel Sreeni
Traduction : TechFlow
Ce qui suit est un tweet de Jason Yanowitz :
Cela pourrait être partiellement inspiré par deux facteurs :
(1) La faible performance de nombreuses nouvelles blockchains de couche 1 récemment lancées, ainsi que
(2) Le succès marquant de Hyperliquid et de HyperEVM
Pour les lecteurs non familiers avec la cryptomonnaie, Hyperliquid est une plateforme décentralisée de trading de contrats perpétuels et au comptant, qui a rapidement pris une place dominante sur le marché, dépassant même certaines bourses centralisées. Sur la base de ce succès, ils ont lancé leur propre blockchain EVM haute performance. Au moment de la rédaction de cet article, la capitalisation boursière d’Hyperliquid est d’environ 11 milliards de dollars, avec une valorisation entièrement diluée (FDV) atteignant 33 milliards de dollars.
Hyperliquid fait partie des premiers exemples à avoir réussi à lancer une nouvelle blockchain de couche 1 grâce au succès de son application principale génératrice de revenus. J'adhère globalement au point de vue de Jason. Toutefois, la plupart des nouvelles blockchains de couche 1 n'ont pas l'avantage dont disposait Hyperliquid au démarrage ; son fondateur Jeff avait auparavant dirigé l'une des meilleures sociétés de trading à haute fréquence dans l'écosystème crypto, et disposait de réserves financières suffisantes pour ne pas dépendre du financement externe.
C’est pourquoi je souhaite proposer quelques idées alternatives concernant la stratégie et le go-to-market (GTM) des nouvelles blockchains de couche 1, ainsi que sur la manière de construire des applications dessus — en particulier lorsque l’on emprunte un chemin plus traditionnel, comme le recours au financement par capital-risque et la construction d’infrastructures entièrement nouvelles (si votre blockchain de couche 1 ne présente pas de différenciation fonctionnelle significative et se contente d’imiter d’autres projets, ces suggestions ne vous concernent probablement pas).
Mes réflexions reposent principalement sur mon expérience terrain chez Ritual, ainsi que sur une observation attentive des stratégies et exécutions des autres blockchains de couche 1 dotées d’écosystèmes solides. J’apprends encore, donc mes opinions pourraient évoluer à l’avenir.
En résumé, voici mes points de vue :
Guide actif vs. « Construisez, et ils viendront »
L’approche « Construisez, et ils viendront » (Build and they’ll come) était une mentalité stratégique largement répandue dans le domaine de la crypto avant 2021, à une époque où les infrastructures étaient gravement insuffisantes. L'idée centrale était que si vous construisiez une nouvelle chaîne ou une couche 2 (L2), les développeurs viendraient naturellement, tenteraient d’attirer de nouveaux utilisateurs, et capteraient de la valeur via le jeton de votre chaîne. Cette stratégie a fonctionné un temps, car les chaînes techniquement solides et dignes d’intérêt étaient rares, et le secteur des infrastructures bénéficiait d’une prime durable. Cependant, cette prime s’est progressivement dissipée, notamment avec l’apparition massive de nouvelles chaînes dépourvues d’utilisations réelles ou d’applications attrayantes (dont la plupart ne sont que des clones ou des forks).
Il est clair aujourd’hui que cette stratégie ne fonctionne plus, du moins pour les nouveaux projets blockchain. Parmi les rares écosystèmes ayant récemment réussi à l’appliquer, on trouve HyperEVM, mais même dans ce cas, le succès ne repose pas entièrement sur cette approche. Le succès d’HyperEVM découle surtout de Hyperliquid Core (la bourse), qui sert d’application phare, créant une valeur réelle pour les détenteurs de $HYPE et pour l’écosystème Hype dans son ensemble (et rendant riches de nombreux utilisateurs actifs avant l’événement de génération de jetons, TGE).
À l’inverse, nous observons aujourd’hui de nombreux projets de couche 1 (L1) et de couche 2 (L2) qui adoptent dès le départ cette logique, pensant compenser leurs lacunes par des subventions et une simple promotion de marque — et qui finissent par échouer.
Cela dit, construire « quoi que ce soit » est difficile. Construire une infrastructure est ardu, développer une application aussi. Dans le domaine crypto, construire va bien au-delà du simple déploiement de code — il faut aussi accomplir une quantité considérable de travail complémentaire, incluant le marketing (GTM), les opérations, la conformité juridique, etc., ce qui est souvent sous-estimé.
Lorsqu’on construit une blockchain de couche 1 (sous réserve que ce soit une architecture entièrement nouvelle, et non un simple fork), on affronte à la fois un défi technique majeur et une tâche colossale de go-to-market (GTM). Personne ne sait vraiment quelle sera la « killer app », c’est pourquoi votre rôle consiste à construire le produit, puis à collaborer avec les développeurs afin de favoriser l’émergence d’applications de haute qualité, maximisant ainsi les chances de réussite pour votre couche 1 et pour les développeurs qui lui font confiance.
Cela laisse aux équipes d’infrastructure plusieurs options :
-
Former une équipe plus forte et tout faire en interne, y compris développer des applications de premier plan :
Cette méthode peut fonctionner, mais comporte plusieurs inconvénients :
-
(a) Il est difficile de trouver des talents de haut niveau.
-
(b) Recruter ces talents en interne implique de lever davantage de fonds auprès d’investisseurs, ce qui n’est plus très bien vu aujourd’hui. (Je sais qu’Hyperliquid a réussi cela avec seulement 10 personnes, mais la plupart des fondateurs ne disposent pas, au départ, des mêmes avantages et ressources que Jeff. Même ainsi, leur performance reste folle.)
-
Vous devez non seulement embaucher des ingénieurs, mais aussi du personnel spécialisé en GTM, opérations, marketing et conformité juridique. Bien qu’il puisse exister des synergies transversales à grande échelle, cela prend beaucoup de temps à réaliser, d’autant que chaque application peut être très différente des autres.
-
-
Reprendre l’ancienne approche « Construisez, et ils viendront » + distribuer massivement des subventions de développement :
Cette stratégie attire généralement des équipes médiocres et des « chasseurs de subventions » dont les applications manquent de différenciation, ce qui donne de mauvais résultats à long terme.
-
Guider activement le développement de l’écosystème :
Je veux dire par là adopter une démarche proactive : construire des prototypes ou des applications légères sur votre infrastructure, puis collaborer avec d'autres développeurs ou partenaires pour concrétiser pleinement ces applications.
Les développeurs veulent voir que vous êtes prêts à investir du temps et des efforts, pas simplement à parler. En fin de compte, au stade initial, personne ne connaît mieux le potentiel de votre infrastructure que ceux qui l’ont conçue. Grâce à cette approche, vous pouvez :
(a) Montrer des applications nouvelles et attrayantes ;
(b) Démontrer ce qui est possible sur votre infrastructure ;
(c) Exercer une certaine influence sur la direction du développement de l’écosystème, plutôt que de vous contenter de distribuer des fonds.
La méthode (3) nécessite toujours d’avoir en interne des talents capables de construire des applications, mais elle relève davantage d’une pratique active visant à aider concrètement à créer de vrais protocoles depuis zéro, sans nécessiter d’importantes ressources ni compromettre l’amélioration de l’infrastructure centrale. Sur le plan fonctionnel, cela ressemble presque à offrir un soutien de plateforme ou un programme d’incubation pour ces entreprises.
Cette approche est-elle potentiellement plus difficile et plus lente ? Oui. Mais je pense que c’est une méthode plus orientée vers le long terme, particulièrement adaptée aux projets qui continuent d’affiner leur infrastructure de base ou qui en sont encore aux premières étapes. C’est précisément la voie que nous avons choisie chez Ritual, en développant des projets comme Ritual Shrine pour construire les applications que nous souhaitons voir émerger sur Ritual, et que nous pensons pouvoir devenir des applications phares dans les domaines de la crypto et de l’intelligence artificielle.
Mais nous ne sommes pas les seuls — Solana, dans ses débuts, a collaboré activement avec FTX, Jump et d'autres équipes. Plusieurs nouveaux projets populaires sur Crypto Twitter (CT), tels que Plasma, MegaETH ou Monad, ont déjà adopté une approche proactive en créant des ensembles de protocoles natifs à leur écosystème à partir de protocoles existants.
Je prévois que cette stratégie deviendra dominante (et rendra ainsi plus difficile de véritablement se démarquer au-delà du seul travail technique).
Dans certains cas, j’aurais aimé pouvoir construire intégralement de nombreux prototypes de Ritual Shrine en interne et les exploiter nous-mêmes. Mais je reconnais également que ces projets ont besoin d’équipes spécialisées pour réussir sur les plans produit et GTM (des équipes qui pourraient s’avérer mieux placées que nous sur le marché, même si nous disposons selon moi de l’une des meilleures équipes transversales du secteur).
Si nous pouvons construire main dans la main avec ces équipes, tout en offrant aux développeurs externes une rémunération économique solide, cela restera une victoire. Nous en « possédons » métaphoriquement une part, tout en intégrant de nouvelles perspectives et de nouveaux talents.
En résumé : oui, il est formidable d’avoir des applications phares de premier ordre sur votre nouvelle infrastructure. Mais si vos ressources sont limitées, alors efforcez-vous de guider activement le développement de votre écosystème sous forme de prototypes, construisez avec eux, au lieu de vous reposer passivement sur cette idée.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
