ERC-20

À des fins éducatives uniquement ; ne constitue pas un conseil en investissement. Investir peut entraîner des pertes.

Réponse directe

ERC-20 est une interface standard pour les contrats de jetons fongibles sur Ethereum. Elle permet aux portefeuilles, aux plateformes d’échange et aux applications décentralisées d’utiliser les mêmes appels pour consulter une offre ou un solde, transférer des jetons et autoriser une autre adresse à dépenser un montant limité. Fongible signifie que des unités équivalentes d’un même jeton sont censées être interchangeables.

L’interface principale comprend :

• totalSupply et balanceOf pour consulter l’offre et les soldes des comptes ;
• transfer pour envoyer les jetons de l’appelant ;
• approve et allowance pour définir et consulter le plafond de dépense d’un tiers ;
• transferFrom pour dépenser à partir du solde d’un propriétaire dans la limite de ce plafond ; et
• les événements Transfer et Approval pour consigner les transferts et les approbations.

La norme définit l’interopérabilité, pas la qualité de l’actif. La conformité à ERC-20 ne garantit ni une offre fixe, ni une juste valeur de marché, ni la convertibilité, ni la liquidité, ni une administration sûre, ni même un comportement identique entre les différentes implémentations.

Fonctionnement

Un solde ERC-20 est une entrée dans l’état du contrat du jeton, associée à une adresse. Un portefeuille affiche cet état ; il ne détient pas de fichier de jeton distinct. Lorsque transfer(to, amount) aboutit, le contrat diminue le solde de l’appelant, augmente celui du destinataire et émet un événement Transfer. L’utilisateur paie généralement le gas du réseau en ETH. Si l’exécution est annulée, les modifications de l’état du jeton sont défaites, mais le gas déjà consommé n’est pas intégralement remboursé.

La dépense déléguée repose sur un plafond d’autorisation. L’appel approve(spender, amount) définit la part du solde de l’appelant que ce tiers peut utiliser. Celui-ci peut ensuite appeler transferFrom(owner, to, amount), tandis que allowance(owner, spender) indique le plafond restant. Une approbation concerne une seule paire propriétaire-tiers, dans un seul contrat de jeton et sur un seul réseau ; elle n’accorde aucun droit sur tous les actifs du portefeuille.

Un nouvel appel à approve remplace le plafond précédent. La spécification EIP-20 recommande aux interfaces utilisateur de ramener un plafond existant à 0 avant de définir une autre valeur non nulle, car l’ordre des transactions pourrait sinon permettre au tiers d’utiliser à la fois l’ancien et le nouveau plafond. Fixer un plafond à 0 peut empêcher les futurs appels à transferFrom pour cette combinaison propriétaire-tiers-jeton, mais ne permet pas de récupérer les jetons déjà transférés.

name, symbol et decimals sont des méthodes de métadonnées facultatives dans EIP-20. decimals influe sur les unités affichées, et non sur la comptabilité en nombres entiers du contrat. La norme ne prescrit pas non plus comment les jetons sont créés ou détruits, si les transferts peuvent être suspendus ou taxés, si des adresses peuvent être bloquées, ni si la logique d’un proxy peut être mise à niveau. Ces comportements doivent être vérifiés dans le code déployé, l’implémentation en vigueur et les autorisations administratives.

Exemple

Supposons qu’un portefeuille détienne 1,000 unités d’un jeton ERC-20 et qu’un utilisateur souhaite en échanger 100 par l’intermédiaire du routeur d’une plateforme d’échange décentralisée. L’utilisateur soumet d’abord approve(router, 100). Si l’opération aboutit, le routeur peut appeler transferFrom(user, pool, 100) ; après une dépense complète, le plafond restant ordinaire est de 0. La transaction d’approbation et la transaction d’échange sont deux actions distinctes sur la chaîne : chacune peut donc nécessiter du gas et échouer indépendamment.

Approuver la valeur maximale possible peut éviter des approbations répétées, mais expose un montant plus important pendant plus longtemps si le routeur, son autorité de mise à niveau ou l’interface utilisée pour recueillir l’approbation est compromis. Un plafond limité réduit cette exposition, sans toutefois éliminer les risques liés aux contrats intelligents, au prix du jeton, à la liquidité ou aux transactions.

Risques

• Mauvais contrat ou mauvais réseau : les noms, les symboles et les icônes peuvent être copiés ; vérifiez l’adresse du contrat sur le réseau prévu.
• Plafond excessif : un tiers malveillant ou compromis peut utiliser un plafond inutilisé jusqu’à la limite approuvée.
• Comportement non standard : certains jetons largement utilisés ne renvoient pas les valeurs exactement comme prévu, tandis que d’autres prélèvent des frais de transfert, réajustent les soldes, bloquent des adresses ou suspendent les transferts.
• Contrôle administratif : la création de jetons, le blocage, les mises à niveau ou d’autres actions privilégiées peuvent modifier le risque du jeton après son acquisition par un utilisateur.
• Transfert irrécupérable : l’envoi de jetons à la mauvaise adresse ou à un contrat incapable de les prendre en charge peut rendre toute récupération impossible.

La standardisation ERC-20 réduit les frictions d’intégration ; elle n’élimine pas les risques liés au contrat, à l’émetteur, à la conservation, au marché ou aux opérations. Avant de signer, vérifiez le réseau, le contrat du jeton, l’adresse du tiers autorisé, le montant approuvé et l’appel de transaction.

Idées reçues courantes

Mythe 1 : La mention ERC-20 prouve qu’un jeton est légitime

N’importe qui peut déployer un contrat portant un nom ou un symbole connu. La mention décrit uniquement une prétendue conformité à une interface. Vérifiez l’adresse du contrat, puis évaluez séparément le code, les autorisations, l’émetteur, la liquidité et le marché.

Mythe 2 : Une approbation transfère immédiatement les jetons approuvés

approve modifie généralement un plafond d’autorisation ; cet appel ne transfère pas lui-même les jetons au tiers autorisé. C’est l’appel ultérieur à transferFrom qui les déplace. Un plafond en cours constitue néanmoins une autorisation réelle qui peut rester utilisable jusqu’à ce qu’il soit dépensé, remplacé ou fixé à 0.

Mythe 3 : Tous les jetons ERC-20 se comportent de manière identique

La norme spécifie une interface commune minimale. Elle n’impose aucune politique d’offre particulière et n’interdit ni les frais, ni la suspension, ni les listes noires, ni le réajustement des soldes, ni la possibilité de mise à niveau. Les intégrations doivent tenir compte de l’implémentation réelle plutôt que de se fier uniquement à la mention ERC-20.

Sujets connexes

• Portefeuille à récupération sociale
• Norme de jeton
• Quelle est la différence entre une pièce et un jeton ?
• Autorisation de portefeuille
• ZK Rollup

Sources

• ERC-20: Token Standard - Ethereum Improvement Proposals (consulté : 2026-08-20)
• ERC-20 Token Standard - Ethereum.org (consulté : 2026-08-20)