Qu’est-ce qu’un standard de token ?

Un standard de token est une spécification technique qui indique quelles fonctions un programme de token doit fournir, quelles entrées il accepte et comment il communique ses résultats aux portefeuilles et aux autres applications. Il permet à des tokens créés par des développeurs différents d’être reconnus et appelés selon un même ensemble de règles.

On peut voir un standard comme une convention d’interface : il précise « comment communiquer vers l’extérieur », mais il ne décide à la place d’aucun projet de l’émission, de l’usage, des droits d’administration ou des droits hors chaîne. Deux tokens peuvent suivre le même standard tout en employant un code différent, en détenant des droits différents et en représentant des objets totalement distincts.

Que se passerait-il sans standard commun

Si chaque token nommait à sa manière ses fonctions de consultation de solde, de transfert et d’autorisation, portefeuilles et applications devraient écrire une connexion distincte pour chacun. Un nouveau token, même capable de se transférer normalement, pourrait ne pas s’afficher dans les portefeuilles existants ni être appelable par d’autres programmes en chaîne.

Un standard commun fixe des points d’entrée uniformes pour les opérations courantes. Un portefeuille sait comment demander un solde, une application sait comment demander un transfert, un explorateur de blocs sait quels événements lire, et d’autres programmes peuvent appeler plusieurs tokens dans le même format. Les développeurs n’ont pas besoin de connaître à l’avance chaque token pour offrir une prise en charge de base.

Ce qu’un standard améliore, c’est la compatibilité logicielle, pas la qualité d’un token. Une fois les interfaces uniformisées, une implémentation erronée ou malveillante peut aussi se brancher plus facilement sur des applications existantes : qui l’utilise doit donc encore vérifier le code et les droits précis.

Ce qu’un standard définit généralement

La portée d’un standard de token varie selon le réseau et le type de token. Les contenus courants relèvent des catégories suivantes.

Fonctions de consultation

Un standard peut préciser comment consulter le solde d’une adresse, l’émission totale d’un token, ou qui contrôle actuellement un numéro distinct. Une méthode de consultation uniforme permet aux portefeuilles et aux applications d’afficher les informations de base.

Les résultats d’une consultation ne reflètent que les données renvoyées par le programme à cet instant. Un standard ne vérifie pas si un nom d’affichage est authentique, si une émission bénéficie d’un adossement hors chaîne, et il ne garantit pas que les éléments complémentaires décrivant un token — ses métadonnées — resteront accessibles durablement à leur lien.

Fonctions de transfert

Un standard peut préciser comment un expéditeur transfère des tokens à un destinataire, quels paramètres l’appel exige et comment répondre en cas de succès ou d’échec. Pour les tokens à numéro distinct, un transfert doit en outre indiquer le numéro concerné.

Certains standards proposent une méthode de transfert plus sûre, qui vérifie si le programme destinataire sait traiter les tokens reçus. Cela peut réduire certains transferts par erreur, mais n’empêche pas les pertes dues à une mauvaise adresse, à une autorisation malveillante ou à une faille de programme.

Fonctions d’autorisation

Une autorisation permet à un détenteur de laisser une autre adresse ou un autre programme agir pour son compte dans des limites définies. Un détenteur peut par exemple autoriser une application à transférer une certaine quantité de tokens fongibles, ou habiliter un opérateur à gérer un ensemble de tokens à numéro distinct.

Un standard précise comment créer, consulter et révoquer une autorisation, mais ne décide pas si un utilisateur devrait en accorder une. Le montant du plafond, sa durée et le comportement du programme autorisé restent à apprécier d’après l’implémentation concernée et par la personne qui l’utilise.

Événements et formats d’enregistrement

Lorsqu’un programme en chaîne exécute un transfert, une frappe ou une autorisation, il peut émettre des événements structurés. Un événement est une indication d’enregistrement d’exécution destinée à être lue par les applications ; portefeuilles, explorateurs de blocs et services de données peuvent s’en servir pour mettre à jour une interface ou constituer un index.

Un événement ne remplace pas l’état final. Une application doit encore confirmer la réussite de la transaction et lire les données courantes selon les règles du réseau ; voir un seul événement non confirmé, ou provenant du mauvais contrat, ne suffit pas à prouver qu’un solde a valablement changé.

Fonctions optionnelles et extensions

Un standard peut classer comme optionnels le nom, le code de cotation, les métadonnées ou une fonction listant tous les numéros distincts — l’énumération —, et il peut aussi permettre d’activer des frais de transfert, un gel, une suspension ou d’autres extensions. Une application ne peut pas présumer que toutes les fonctions optionnelles existent simplement parce qu’un token déclare adopter un standard donné.

Les extensions peuvent en outre être incompatibles entre elles, ou exiger une adaptation volontaire des portefeuilles. Des transferts de base identiques ne signifient pas qu’une application ancienne comprendra tous les droits et champs de données ajoutés ensuite.

Standard, implémentation et token ne sont pas la même chose

Un standard est une convention de fonctionnalités, qui indique comment un programme compatible doit répondre vers l’extérieur. Une implémentation est le code précis qu’un développeur écrit et déploie selon cette convention. Un token est l’enregistrement en chaîne et les unités gérés par une implémentation particulière.

Un standard peut avoir de nombreuses implémentations de code ; une même implémentation peut aussi servir à créer plusieurs tokens différents. Une implémentation peut encore ajouter des frais, un gel, des listes, des mises à niveau ou d’autres logiques au-delà de ce qu’exige le standard.

« Adopter un standard » n’indique donc qu’une intention de prendre en charge un ensemble d’interfaces. Cela ne prouve pas que le code est exempt de défauts, ni que toutes les interfaces ont été correctement implémentées. Lors d’une intégration, une application doit vérifier l’adresse déployée, les résultats réellement renvoyés, les droits supplémentaires et les comportements exceptionnels.

Comment un standard se forme et se diffuse

Un standard de token apparaît généralement d’abord sous forme de proposition technique, de document de spécification ou de programme partagé. Les auteurs exposent le problème à résoudre, les exigences d’interface et les raisons de la conception ; après discussion par la communauté et les développeurs, la proposition peut atteindre un état relativement stable, continuer d’évoluer ou cesser d’avancer.

L’état du document et l’adoption par le marché sont deux choses distinctes. Une proposition peut être rédigée complètement et rester peu employée ; un autre standard peut compter de nombreuses implémentations avant d’être finalisé. La prise en charge par les portefeuilles et les applications dépend des déploiements réels, des besoins d’usage et des choix des développeurs — pas du numéro lui-même.

La mise à jour d’un standard ne modifie pas non plus forcément les tokens déjà déployés. Un ancien contrat peut continuer de fonctionner avec l’ancienne interface, tandis que les nouvelles fonctions arrivent par un nouveau contrat, une nouvelle version ou une extension optionnelle. En lisant un standard, il faut confirmer en même temps le réseau, la version, l’état et l’implémentation concernée.

L’interface commune des tokens fongibles

Les tokens fongibles sont enregistrés par quantité, et des unités égales peuvent généralement s’échanger entre elles. Ce type de standard précise couramment la consultation de solde, l’émission totale, le transfert, ainsi qu’une fonction d’autorisation permettant à une autre adresse de transférer pour le compte du détenteur dans la limite d’un plafond.

Sur Ethereum, par exemple, les propositions de standards de couche applicative sont appelées Ethereum Request for Comments (ERC). ERC-20 est le standard ERC qui définit les interfaces de base des tokens fongibles, permettant aux portefeuilles et aux applications en chaîne de consulter des soldes, de demander des transferts et de traiter des autorisations de façon commune.

ERC-20 n’impose pas à un token d’avoir une émission fixe et n’interdit pas aux développeurs d’ajouter des logiques supplémentaires comme une suspension, des frais de transfert ou des listes. Les informations d’affichage telles que nom, code de cotation et nombre de décimales ne remplacent pas non plus l’adresse de contrat pour identifier un token de façon unique.

L’interface commune des tokens à numéro distinct

Les tokens non fongibles (non-fungible token, NFT) exigent un suivi distinct de chaque numéro. Les standards correspondants précisent généralement comment consulter le détenteur d’un numéro, transférer un numéro déterminé et autoriser une autre adresse à opérer sur un token ou un ensemble de tokens.

Ces interfaces sont implémentées différemment selon les réseaux. Sur Ethereum, par exemple, ERC-721 définit les opérations de base de détention, de transfert et d’autorisation des tokens à numéro distinct, tandis que les métadonnées et la liste complète des numéros relèvent d’extensions optionnelles. Adopter ce standard ne signifie pas qu’une image ou un autre contenu est nécessairement stocké en chaîne, et ne prouve pas que l’objet hors chaîne représenté par le token existe réellement.

Certains standards permettent aussi à un même programme de gérer à la fois des unités fongibles, des unités à numéro distinct ou plusieurs exemplaires sous un même numéro. Ils répondent à des besoins d’enregistrement différents ; cela ne signifie pas qu’un standard soit globalement supérieur à un autre.

Les approches de normalisation selon les réseaux

Un standard de token ne signifie pas forcément « déployer un contrat par token, chacun implémentant la même interface ». Différentes blockchains peuvent obtenir la compatibilité par des règles de protocole, un programme partagé ou des extensions optionnelles.

Ainsi, le programme de tokens de Solana fournit au même endroit des instructions de frappe, d’enregistrement de comptes, de transfert et d’autorisation. Chaque mint consigne l’émission et les droits d’un token donné, tandis que portefeuilles et applications traitent de nombreux mints via le même programme de tokens.

Solana propose en outre Token Extensions, un programme de tokens auquel des fonctions supplémentaires peuvent être ajoutées. À la création d’un token, un développeur peut choisir les extensions selon ses besoins ; certaines ne peuvent pas être ajoutées après l’initialisation, et certaines peuvent être incompatibles entre elles. Cela montre qu’« utiliser le même programme de tokens » ne suffit pas encore à conclure que deux tokens se comportent de façon identique.

Lorsqu’un même nom de standard ou une interface similaire apparaît sur plusieurs réseaux, il ne faut pas non plus présumer que les adresses, les droits et les formats de transaction sont directement transposables. La portée d’un standard reste toujours liée au réseau et à l’environnement d’exécution concernés.

Compatible ne veut pas dire comportement identique

Quand un portefeuille ou une application annonce « prendre en charge un standard », cela signifie généralement qu’il sait traiter les interfaces de base exigées par ce standard. La compatibilité réelle peut encore être affectée par les situations suivantes :

• le token n’implémente pas entièrement les fonctions requises, ou renvoie des résultats inattendus ;
• le token ajoute des frais de transfert, une suspension, un gel ou des règles de listes ;
• l’application ne prend pas en charge certaines extensions optionnelles ;
• le programme destinataire ne sait pas traiter une méthode de transfert particulière ;
• une structure de mise à niveau par proxy, qui change le code exécuté derrière un point d’entrée fixe, a modifié la logique réelle ;
• des tokens de même nom sont déployés sur des réseaux ou à des adresses différents.

Les tests de compatibilité d’interface doivent donc porter sur le code précis et sur les résultats précis d’un appel. Une étiquette « conforme au standard » n’est en soi ni un audit de sécurité, ni une garantie que le comportement futur ne changera pas.

Ce qu’un standard ne définit pas

Un standard de token ne remplace généralement pas les informations suivantes :

• qui peut continuer à frapper, geler, suspendre ou mettre à niveau le token ;
• comment la quantité totale est répartie et si cela changera ;
• quel usage concret ou quelle demande de marché le token rencontre ;
• si nom, icône et métadonnées sont maintenus par une source fiable ;
• si les réserves, biens physiques ou services auxquels le token prétend correspondre existent ;
• si le détenteur dispose de droits de remboursement, de gouvernance ou d’autres droits hors chaîne.

Ces questions exigent d’examiner l’implémentation, les droits et les dispositifs hors chaîne concernés. Un standard technique ne règle qu’une partie des problèmes d’interaction logicielle ; il ne peut pas porter la preuve de l’authenticité, de la valeur ou de l’effet juridique.

FAQ

Un token doit-il suivre un standard ?

Pas nécessairement. Un développeur peut créer une interface personnalisée, mais portefeuilles et applications doivent alors s’adapter davantage. Adopter un standard largement pris en charge facilite généralement l’obtention d’une compatibilité de base.

Un numéro de standard plus récent est-il meilleur ?

Cela ne s’apprécie pas ainsi. Un standard récent peut ajouter des fonctions, mais aussi être moins pris en charge, encore en évolution, ou inadapté à un usage donné. Il faut regarder l’état de la proposition, l’adoption réelle et le besoin précis.

Un même token peut-il adopter plusieurs standards ?

C’est possible. Une implémentation peut prendre en charge plusieurs interfaces à la fois, ou ajouter des extensions à un standard de base. Savoir si ces interfaces coopèrent correctement exige encore d’examiner le code concerné.

Suivre un standard garantit-il un affichage dans tous les portefeuilles ?

Ce n’est pas garanti. Un portefeuille doit aussi prendre en charge le réseau concerné, la version du standard et les fonctions optionnelles, et reconnaître le bon contrat ou le bon mint. Les métadonnées comme le nom et l’icône peuvent en outre exiger une source supplémentaire.

Un standard garantit-il la sécurité d’un token ?

Non. Un standard ne définit que des interfaces communes ou des exigences de comportement. Défauts de code, droits d’administration, données externes, autorisations des utilisateurs et réseau sous-jacent peuvent toujours créer des risques.

Concepts associés

Poursuis avec token crypto, contrat intelligent, blockchain et portefeuille crypto, ou reviens au glossaire des cryptomonnaies.

Sources

• NISTIR 8301 : Blockchain Networks: Token Design and Management Overview — modèles de données des tokens, opérations de protocole et de compte, et portée variable des standards.
• Ethereum.org : standards de tokens — rôle des interfaces de tokens dans la compatibilité entre portefeuilles, applications et programmes en chaîne.
• Processus des standards de couche applicative d’Ethereum — catégorie ERC, états des propositions de standards et portée de l’interopérabilité applicative.
• Standard Ethereum de tokens fongibles ERC-20 — interfaces de base pour soldes, transferts, autorisations et événements.
• Standard Ethereum de tokens non fongibles ERC-721 — détention, transfert, autorisation et extensions optionnelles des tokens à numéro distinct.
• Solana Docs : tokens et extensions — programme de tokens partagé, mints, comptes de tokens et extensions optionnelles.