Pourquoi les autorisations de token existent-elles ?

Intermédiaire4 nov. 2026 · 6 min de lecture

Les autorisations de token existent pour qu’un smart contract précis puisse dépenser plus tard un token depuis votre wallet — jusqu’à une allowance que vous fixez — sous des règles de token courantes qui interdisent les prélèvements libres. Le contrat ne peut pas simplement prendre les tokens.

Points clés

Les autorisations de token existent parce que les règles de token courantes empêchent un contrat de prélever librement vos soldes — un spender nommé a d’abord besoin d’une allowance.
Sur les parcours DEX et dApp depuis le wallet, Approve / autoriser est la couche de permission. Le swap ou le dépôt est en général une confirmation séparée.
L’allowance est typiquement par token et par spender. Une autorisation ne couvre pas tous les tokens ni tous les contrats.
Les autorisations illimitées existent pour la commodité (moins de répétitions, moins de gas). Elles laissent aussi un risque persistant plus large si ce spender échoue plus tard.
L’allowance restante est un état on-chain. Fermer le site ou déconnecter le wallet ne l’efface pas.
Les flux plus récents de type Permit / Permit2 accordent encore un pouvoir de dépense — souvent avec moins de friction, pas avec une lecture optionnelle.

Réponse courte

Les autorisations de token existent pour qu’un smart contract précis puisse dépenser plus tard un token depuis votre wallet — jusqu’à une allowance que vous fixez — sous des règles de token courantes qui interdisent les prélèvements libres.

En clair :

Le contrat ne peut pas simplement prendre les tokens. Il a d’abord besoin d’une permission de dépense. Cette permission est écrite on-chain. Elle peut survivre au clic du trade. Illimité, reste, révocation et raccourcis de type Permit découlent de ce design.

La définition du glossaire — ce qu’est une autorisation — est sur Qu’est-ce qu’une autorisation de token ?.

Cette page clarifie une chose : Approve / autoriser n’est pas une friction au hasard. C’est ainsi que le pouvoir de dépense est délégué.

La vraie question de trading

Vous ouvrez un swap depuis le wallet. La cotisation paraît bonne. Vous continuez — et le wallet demande Approve / autoriser avant que le trade puisse se terminer.

Demandez :

Est-ce seulement des clics inutiles — ou la plateforme demande-t-elle le pouvoir de dépense qu’exigent les règles du token ?

Ce sont deux histoires différentes.

Voir des clics inutiles pousse à valider sans lire.

Voir un design vous fait lire token / spender / montant avant de signer.

Scène live : swap bloqué jusqu’à Approve

Vous détenez de l’USDC et voulez swaper sur un DEX depuis le wallet.

Vous connectez le wallet. Connecter n’est pas autoriser.
Vous saisissez la taille et voyez une cotisation.
La confirmation bloque : le wallet affiche Approve USDC / autoriser USDC pour un contrat spender (souvent un router).
Vous signez l’allowance. Cela coûte en général du gas.
Une deuxième confirmation exécute le swap.
Après l’exécution, l’allowance non utilisée peut rester on-chain pour ce token et ce spender.

Aha :

« Ah — le trade avait d’abord besoin d’une permission. Et la permission peut rester après le trade. »

Ce qu’est l’allowance, et comment lire l’invite → Qu’est-ce qu’une autorisation de token ?.

Comment revoir ou révoquer des permissions restantes → quand vous avez besoin de la checklist, voir les User Guides gérer/révoquer.

Raison de design : pourquoi la règle existe

Sous des règles de style ERC-20 largement utilisées, les soldes ne passent pas dans un contrat quelconque juste parce qu’un site l’a demandé.

Un parcours de prélèvement typique a besoin de :

Vous (le owner) autorisez un spender.
Ce spender appelle ensuite quelque chose comme `transferFrom` dans l’allowance restante.

Sans cette autorisation, le contrat ne devrait pas pouvoir vider le token de votre adresse.

C’est la valeur de sécurité par défaut — et la raison pour laquelle les flux DEX affichent Approve quand ils doivent déplacer un token que vous détenez déjà.

Les coins natifs du réseau sautent souvent cette même étape approve de style ERC-20.

Les autorisations d’opérateur de style NFT sont une famille de permission voisine : un clic peut autoriser un contrat sur de nombreux items.

Cette page reste sur le motif fongible d’approve que les traders spot DEX rencontrent en premier.

Pourquoi le DEX demande avant (ou autour) du trade

Une plateforme qui swap, dépose ou déplace autrement votre solde ERC-20 a besoin d’un pouvoir de dépense pour un spender précis.

Le produit fait donc en général :

demander une allowance quand il n’en existe pas (ou quand une allowance plafonnée est épuisée)
puis vous demander de confirmer l’action de marché

Autoriser accorde une permission.

Le trade dépense des tokens sous cette permission (ou échoue si la permission manque).

Traiter les deux clics comme « juste continuer » fond deux décisions différentes en une seule habitude.

Conséquences de design que vous rencontrerez encore

Par token, par spender

Autoriser l’USDC pour le Router A n’autorise ni l’USDT, ni le Router B.

Une première visite avec plusieurs tokens peut entraîner plusieurs invites Approve. C’est la règle de périmètre qui travaille — pas l’app qui invente des clics « pour le sport ».

Pourquoi l’illimité existe

Les autorisations illimitées (ou au max) sont courantes parce qu’elles réduisent les invites répétées et le gas répété.

Elles élargissent aussi le risque persistant : si ce spender est malveillant maintenant, buggé, ou compromis plus tard, il peut déjà avoir la permission de prélever ce token sans un nouvel Approve de votre part.

Commodité et risque persistant sont la même pièce de design.

Pourquoi les allowances restantes persistent

L’allowance est enregistrée on-chain pour cette relation owner–token–spender.

Le frontend peut disparaître. Votre « déconnecter » peut réussir. Le mapping peut rester jusqu’à ce qu’il soit consommé, baissé ou révoqué.

C’est pourquoi d’anciennes plateformes que vous n’utilisez plus peuvent encore compter dans votre livre de risques.

Pourquoi révoquer / baisser existe

Nettoyer est une écriture on-chain séparée. Cela coûte en général du gas et demande votre signature.

Déconnecter ≠ révoquer.

Révoquer/baisser aide à stopper les prélèvements futurs. Cela ne reverse pas les tokens déjà pris.

Étapes pratiques et outils → User Guides gérer/révoquer. Détail des frais → Qu’est-ce que les frais de réseau (gas) ?.

Motifs plus récents : moins de friction, même famille de permission

Certains flux utilisent des signatures de type Permit pour fixer l’allowance sans transaction approve séparée.

Certains designs (y compris des hubs de type Permit2) passent par un contrat d’autorisation partagé : une autorisation persistante au hub, puis des signatures avec portée montant/temps pour les apps.

Ces motifs existent pour réduire la douleur en deux étapes et, dans certains designs, ajouter une échéance ou des portées plus fines.

Ils ne rendent pas la lecture optionnelle. Une page de phishing qui récolte une mauvaise signature de type permit peut encore accorder un pouvoir de dépense dans la même famille qu’un mauvais Approve classique.

L’architecture profonde de Permit2 reste hors de cette page. Le jugement d’état actuel ici est simple : les raccourcis déplacent encore le pouvoir de dépense.

Pourquoi les attaquants s’intéressent au même design

Les drainers aiment les autorisations et les signatures de type permit parce qu’ils peuvent monétiser une permission de dépense persistante sans voler votre phrase de récupération.

Les fausses invites « claim », « verify », « sync » ou « mint » demandent souvent la même surface de permission dont le vrai DEX a besoin pour des swaps honnêtes.

Le motif appartient ici. Parcours complet liens officiels et phishing → Vérifier les liens officiels et éviter le phishing.

Scènes travaillées (lecture rapide)

Scène	Ce que le design explique
Swap bloqué jusqu’à Approve	Le spender ne peut pas prélever sans allowance
Illimité « pour ne pas ré-autoriser »	Commodité UX vs risque persistant plus large
Trade terminé ; allowance encore active	Permission on-chain ≠ session du site
Hub de type Permit2 autorisé une fois	Permission persistante du hub + signatures ultérieures bornées
Faux claim demande Approve / Permit	Les attaquants réutilisent la couche de permission de dépense

Vous n’avez pas besoin de chaque ligne à chaque fois.

Nommez si vous accordez un pouvoir de dépense — et à qui — avant de fixer la taille.

À ne pas confondre avec

Ce qu’est une autorisation (définition / reconnaissance) → Qu’est-ce qu’une autorisation de token ?
Comment revoir ou révoquer (checklist pratique) → User Guides gérer/révoquer
Calcul des frais de gas → Qu’est-ce que les frais de réseau (gas) ?
Liens officiels / how-to phishing → Vérifier les liens officiels et éviter le phishing
Connecter / clés / modèle de conservation → pages sœurs wallet et auto-conservation

Cette page n’est pas « redéfinir l’autorisation. »

C’est pourquoi la couche de permission existe — et pourquoi illimité, reste, révocation et raccourcis de type Permit découlent de ce design.

Si vous tradez depuis le wallet — y compris sur une plateforme comme edgeX — traitez chaque invite Approve / autoriser ou de type permit comme l’octroi d’un pouvoir de dépense persistant sous les règles du token, pas comme une case décorative.

Lisez token, spender et montant avant de signer.

Pour la définition simple, restez sur Qu’est-ce qu’une autorisation de token ?.

Articles associés

Prêt pour la suite ?

Passez à l’inscription ou au trading depuis cette page via les liens officiels.

Commencer à trader sur edgeX

Avertissement

Ce contenu est fourni à des fins éducatives uniquement et ne constitue pas un conseil en investissement. Le trading d'actifs numériques et de produits dérivés comporte des risques. Assurez-vous de comprendre les produits et tenez compte de votre situation avant de trader.

Analyses