Beaucoup de discussions traitent le déploiement de Dusk comme un constat final, mais cette phrase manque de sujet essentiel. Des captures d’écran du site officiel des fournisseurs classent Dusk Native L1 en tant que Live, DuskEVM en tant que Testnet, Hedger en tant que Testnet, et Dusk Trade en tant que Building. Ces quatre appellations désignent des couches différentes : le réseau lui-même, le chemin d’exécution compatible EVM, les modules liés à la confidentialité, et l’orientation de la couche applicative vers des actifs financiers tokenisés. Les compresser en un seul « état » pousse à confondre un réseau déjà existant, des fonctionnalités testables et un produit qui est encore en construction.
Si le problème de l’équipe est de savoir quoi vérifier aujourd’hui, il faut d’abord annoncer le nom du module, puis son état public. Un snapshot Live de Native L1 ne peut pas servir à déclarer la disponibilité en production de DuskEVM ; un Testnet de DuskEVM ou de Hedger ne peut pas être présenté comme un déploiement complet ; et « Building » pour Dusk Trade ne signifie pas non plus que la négociation est déjà ouverte. Ce n’est pas pour casser l’élan, mais pour fixer des limites claires à l’évaluation : selon qu’on discute du socle de règlement, d’un chemin de test ou d’une feuille de route applicative, la force des preuves n’est pas la même, donc le jugement doit aussi différer.
Pour un responsable produit, la question la plus utile n’est pas de savoir si Dusk est vraiment « en ligne » ou non, mais comment s’appelle cette couche que nous devons utiliser, dans quel état elle se trouve, et quelles conclusions cet état permet. En complétant d’abord le sujet, puis en abordant l’usage et la prochaine étape, on transforme des formulations vagues en jugements techniques vérifiables.
Cela explique aussi pourquoi, sous un même nom de projet, on peut voir apparaître simultanément Live, Testnet et Building. Ces étiquettes ne classent pas le « bien » ou le « mal » : elles indiquent au lecteur qu’il doit utiliser des méthodes de validation différentes. Pour la couche déjà déployée, on peut discuter des faits du réseau existant ; pour les modules en test, il faut les limiter au périmètre d’essai ; et pour la couche applicative en construction, il ne convient de discuter que des orientations publiques.
@Dusk $DUSK #dusk
Si le problème de l’équipe est de savoir quoi vérifier aujourd’hui, il faut d’abord annoncer le nom du module, puis son état public. Un snapshot Live de Native L1 ne peut pas servir à déclarer la disponibilité en production de DuskEVM ; un Testnet de DuskEVM ou de Hedger ne peut pas être présenté comme un déploiement complet ; et « Building » pour Dusk Trade ne signifie pas non plus que la négociation est déjà ouverte. Ce n’est pas pour casser l’élan, mais pour fixer des limites claires à l’évaluation : selon qu’on discute du socle de règlement, d’un chemin de test ou d’une feuille de route applicative, la force des preuves n’est pas la même, donc le jugement doit aussi différer.
Pour un responsable produit, la question la plus utile n’est pas de savoir si Dusk est vraiment « en ligne » ou non, mais comment s’appelle cette couche que nous devons utiliser, dans quel état elle se trouve, et quelles conclusions cet état permet. En complétant d’abord le sujet, puis en abordant l’usage et la prochaine étape, on transforme des formulations vagues en jugements techniques vérifiables.
Cela explique aussi pourquoi, sous un même nom de projet, on peut voir apparaître simultanément Live, Testnet et Building. Ces étiquettes ne classent pas le « bien » ou le « mal » : elles indiquent au lecteur qu’il doit utiliser des méthodes de validation différentes. Pour la couche déjà déployée, on peut discuter des faits du réseau existant ; pour les modules en test, il faut les limiter au périmètre d’essai ; et pour la couche applicative en construction, il ne convient de discuter que des orientations publiques.
@Dusk $DUSK #dusk