#dusk $DUSK Récemment, j’ai passé un week-end à essayer de monter un environnement local de zéro en suivant la documentation développeur de @Dusk . Honnêtement, le parcours a été plus chaotique que je ne l’avais prévu.
La documentation est excellente sur le plan conceptuel : les schémas d’architecture sont clairs, les responsabilités des modules principaux sont bien expliquées, et la conception de la machine virtuelle Rusk fait l’objet de sections dédiées. Mais dès qu’on passe à la pratique, les problèmes surgissent. Les versions de dépendances dans les exemples de code ne correspondent pas aux dernières versions des dépôts, certaines descriptions des paramètres d’entrée de certaines API manquent directement dans le document : il faut aller chercher dans le code source pour trouver le format attendu. Ce n’est pas forcément un problème rédhibitoire, mais c’est très coûteux en termes de patience et de confiance pour les développeurs.
Ce qui m’inquiète surtout, c’est la stabilité du testnet. En me connectant au testnet localement pour déboguer des transactions simples, j’ai rencontré plusieurs cas où des nœuds RPC ne répondaient pas. Même si après des tentatives de reprise ça revenait, la documentation ne précise pas le niveau de service du testnet ni les fenêtres de maintenance. Pour un développeur qui vient juste « voir ce que ça donne », cette incertitude peut suffire à le décourager, et surtout, on ne lui dira pas pourquoi il part.
Mon autre constat : les outils de développement de Dusk et l’écosystème Ethereum présentent des différences nettes, ce qui en fait une épée à double tranchant. Le bon côté, c’est que Dusk peut faire une personnalisation poussée autour de sa confidentialité et de ses exigences de conformité, sans être freiné par l’héritage historique de l’EVM. Le mauvais côté, c’est que les développeurs ne peuvent pas réutiliser directement leurs compétences Solidity ni les outils existants. La documentation fournit bien un Rust SDK et des exemples de contrats, mais apprendre Rust à partir de zéro puis la manière de développer propre à Dusk rend la courbe d’apprentissage beaucoup plus abrupte que « fork un ERC-20 ».
Je comprends que la documentation et la chaîne d’outillage prennent du temps, et qu’il soit raisonnable pour l’équipe d’allouer en priorité ses ressources au mainnet et aux protocoles centraux. Mais le démarrage à froid de l’écosystème développeur ne repose pas sur les performances du protocole : il repose sur le fait de pouvoir faire tourner un « Hello World » dès le premier jour. Tant que #dusk n’aura pas fourni un testnet plus stable, des tutoriels d’entrée verrouillant clairement les versions et un nombre d’exemples de déploiements réussis par des développeurs tiers, je jugerai si l’écosystème entre dans une boucle vertueuse. Pour $DUSK , le nombre de développeurs ne se mesure pas à la taille de la communauté : c’est le nombre de contrats réellement déployés on-chain. @Dusk