Approbations de jetons : les permissions que vous ne cessez d'accorder

Chaque fois que vous utilisez une application DeFi — un swap sur un DEX, un dépôt sur un marché de prêt, un pont d'un ERC-20 — vous avez presque certainement accordé une approbation de jeton. La plupart des utilisateurs les signent en quelques secondes et les oublient. Pourtant, cette unique transaction d'approbation est l'une des choses les plus lourdes de conséquences que vous faites sur Ethereum : elle donne à un smart contract une permission permanente de déplacer vos jetons, souvent sans confirmation supplémentaire. Ce guide explique ce qu'est une approbation de jeton, pourquoi les dApp en demandent, les risques des allowance illimités et ce que tout cela implique lorsque vous signez des approbations via SSP.

Pourquoi les approbations existent

Les jetons ERC-20 ne sont pas stockés "dans" votre portefeuille comme l'est ETH. Un contrat de jeton ERC-20 est un grand livre : un mappage d'adresses vers des soldes. Quand vous détenez 1 000 USDC, ce qui existe en chaîne est une ligne dans le contrat USDC qui indique que votre adresse possède 1 000 unités.

Comme le solde réside dans le contrat du jeton, seul ce contrat peut le déplacer. Quand vous envoyez des USDC à un ami, votre portefeuille appelle directement la fonction transfer du jeton.

Mais un DEX, où un contrat différent (le router) doit retirer des USDC de votre adresse pour exécuter un swap, ne peut pas plonger la main dans le contrat du jeton pour prendre votre solde. ERC-20 résout cela par un schéma de délégation en deux étapes :

1. Vous appelez approve(spender, amount) sur le contrat du jeton. Cela définit un allowance : un enregistrement indiquant que le spender est autorisé à déplacer jusqu'à amount de vos jetons.
2. Le spender appelle plus tard transferFrom(yourAddress, destination, amount) sur le contrat du jeton. Le contrat vérifie l'allowance, le décrémente et déplace les jetons.

L'approbation est la clé. Sans elle, le router ne peut pas toucher à vos USDC.

Ce qui est réellement accordé

Lisez approve(spender, amount) au pied de la lettre. Vous dites au contrat ERC-20 : "cette adresse peut retirer jusqu'à tant de mes jetons, à tout moment, dans n'importe quel nombre de transactions, jusqu'à ce que je change cela."

Plusieurs choses en découlent :

• Permission permanente, pas action ponctuelle. Une fois accordée, le spender n'a pas besoin de votre signature à nouveau pour tirer des jetons tant que l'allowance n'est pas épuisé ou révoqué.
• Par jeton. Approuver le router du DEX pour USDC ne lui permet pas de toucher à votre DAI ; il vous faut une approbation séparée pour DAI.
• Par spender. Un contrat différent — même provenant de la même dApp — possède son propre allowance.
• Pas d'expiration. ERC-20 n'a pas de date limite intégrée. Un allowance défini en 2023 reste actif en 2026 à moins d'être consommé ou révoqué.

Vous pouvez inspecter n'importe quel allowance sur un explorateur de blocs tel qu'etherscan en lisant la fonction allowance(owner, spender) du contrat du jeton.

Le motif de l'allowance infini

Si les approbations sont par montant, pourquoi presque tous les DEX vous demandent-ils un nombre énorme — généralement 2^256 - 1, affiché comme "illimité" ou MaxUint256 — au lieu du seul montant que vous échangez ?

La réponse est UX et gas. Si un DEX demandait un allowance neuf égal à la taille du trade à chaque swap, vous paieriez une transaction d'approbation à chaque fois et devriez confirmer deux transactions pour ce qui ressemble à une seule action. Demander un allowance illimité une seule fois vous permet ensuite de swapper librement avec une seule transaction par trade.

C'est véritablement pratique. C'est aussi véritablement plus risqué. Un allowance illimité signifie que le contrat du spender a la permission de vider l'intégralité de votre solde actuel de ce jeton — ainsi que tout solde futur — à tout moment, sans que vous ne signiez quoi que ce soit d'autre.

Pour un contrat connu, audité et immuable, le risque pratique est généralement faible. Pour une dApp fraîchement déployée, un proxy upgradable ou un contrat inconnu, un allowance illimité représente une surface bien plus large que l'opération que vous comptiez faire.

Le vrai risque : une clé permanente vers vos jetons

Le danger des approbations n'est pas la transaction d'approbation elle-même. C'est ce qui se passe après. Considérez quelques scénarios :

• Le contrat du spender contient un bug. Un attaquant exploite sa logique transferFrom et chaque portefeuille avec un allowance non nul est vidé.
• Le contrat du spender est upgradable. Celui qui contrôle les clés d'upgrade déploie une nouvelle logique qui tire des jetons de quiconque possède un allowance actif.
• Vous avez approuvé un clone malveillant. Un site de phishing imitait l'URL d'une vraie dApp, et le contrat que vous avez approuvé était contrôlé par un attaquant depuis le départ.
• Les clés de signature du spender sont compromises. Le contrat officiel est correct ; le portefeuille de l'opérateur ne l'est pas, et les allowance sont exercés par un intrus.

Dans tous les cas, vous ne signez rien au moment du vidage. L'approbation donnée des semaines plus tôt est la seule autorisation dont l'attaquant a besoin. "Approuvez seulement ce dont vous avez besoin et révoquez ce que vous n'utilisez plus" n'est pas de la paranoïa ; c'est le même principe que ne pas laisser des doubles de vos clés à tous les artisans que vous avez engagés.

Comment les approbations s'accumulent silencieusement

Un portefeuille actif depuis un ou deux ans en DeFi a accumulé des dizaines d'approbations : chaque DEX, chaque agrégateur, chaque dépôt sur un marché de prêt, chaque marketplace de NFT, chaque pont. Les utilisateurs ne reviennent quasiment jamais pour révoquer. Le résultat est une longue traîne de permissions permanentes, beaucoup illimitées, beaucoup accordées à des contrats avec lesquels l'utilisateur n'interagit plus.

C'est la surface d'attaque silencieuse. Elle n'apparaît dans aucune transaction unique ; c'est le dépôt cumulé d'un usage normal. Auditer et élaguer cette liste est l'une des habitudes de sécurité les plus efficaces en self-custody — l'article suivant explique exactement comment dans révoquer les approbations de jetons depuis SSP.

Un schéma plus récent : EIP-2612 permit

ERC-20 précède une grande partie de la DeFi moderne, et la danse à deux transactions approve-puis-swap a longtemps été reconnue comme maladroite. EIP-2612 a introduit une alternative pour les jetons qui s'y prêtent : au lieu d'envoyer une transaction approve en chaîne, l'utilisateur signe un message hors chaîne (un permit) autorisant un spender, un montant et une date limite spécifiques. La dApp soumet cette signature en même temps que le swap dans une seule transaction.

permit est économe en gas, borné (il porte un montant et une expiration explicites) et plus difficile à laisser traîner car la date limite le force à expirer. Tous les ERC-20 ne le supportent pas — USDC et DAI le font, beaucoup de jetons plus anciens non — mais là où c'est disponible, c'est généralement plus sûr qu'un allowance approve à long terme. Cela dit, les signatures permit elles-mêmes peuvent faire l'objet de phishing : un site malveillant vous demandant de "vous connecter" peut glisser un permit en dessous. Lisez ce que vous signez.

Ce que cela signifie dans SSP

SSP est un portefeuille multisig 2-sur-2 self-custodial : chaque transaction on-chain est co-signée par l'extension SSP du navigateur et l'application mobile SSP Key. Sur Ethereum et les réseaux EVM que SSP prend en charge (Polygon, Base, BNB Smart Chain, Avalanche), cela est implémenté comme un smart account ERC-4337 avec une signature Schnorr agrégée — mais au niveau applicatif, une approbation ressemble à n'importe quelle autre transaction.

Quelques points à garder en tête :

• Une approbation est une transaction que votre 2-sur-2 doit co-signer. Quand une dApp demande approve, SSP la présente comme n'importe quelle autre tx. Vous voyez l'adresse du spender et le montant demandé sur les deux appareils avant de confirmer.
• Une fois accordée, le spender n'a plus besoin de SSP pour agir. Le multisig protège l'instant de l'approbation, pas la permission permanente qui suit. Si vous accordez un allowance illimité à un contrat malveillant, votre multisig ne vous sauvera pas du vidage qui suivra.
• Surveillez l'adresse du spender. Les dApp mettent parfois à jour leurs routers ; si le spender affiché sur l'écran d'approbation ne correspond pas au contrat attendu, arrêtez-vous et vérifiez.
• Les approbations initiées via WalletConnect ont la même apparence. Que la dApp vous interroge dans sa page ou via WalletConnect, le flux et les risques sont identiques.

Des habitudes à cultiver

Quelques pratiques concrètes gardent la surface d'approbation maîtrisable :

• Préférez l'allowance le plus petit possible. Quand une dApp propose "montant exact" face à "illimité", l'exact est l'option la plus sûre pour les contrats que vous n'utilisez pas régulièrement.
• Traitez les allowance illimités comme des engagements. Réservez-les à un petit ensemble de contrats auxquels vous faites confiance et que vous utilisez souvent. Pour tout le reste, bornez.
• Auditez régulièrement. Une fois par trimestre, listez vos approbations actives sur chaque réseau et révoquez tout ce que vous n'utilisez plus. Des outils comme revoke.cash rendent cela routinier.
• Méfiez-vous des dApp inconnues. Un protocole neuf sans historique d'audit qui demande un allowance illimité est la combinaison la plus risquée en DeFi.
• Protégez les clés qui accordent les approbations. Le multisig de SSP relève le niveau, mais l'hygiène standard reste de mise — voir bonnes pratiques pour la phrase de récupération.

Le modèle mental à retenir

Une approbation de jeton n'est pas un clic ; c'est une clé. Chacune reste dans la serrure jusqu'à ce que vous l'en retiriez, et chacune accorde à son détenteur la capacité de déplacer des jetons que vous n'avez pas encore gagnés. Utilisés avec soin, les allowance sont la plomberie qui fait fonctionner la DeFi. Traités comme des clics jetables, ils sont l'accumulation lente de risques que vous aviez oubliés.

Comprenez la permission que vous accordez, préférez des concessions bornées quand la dApp le permet et taillez vos approbations permanentes selon un rythme régulier. Pour les détails plus profonds du protocole, la documentation du standard ERC-20 sur ethereum.org est la référence canonique. Nouveau dans l'utilisation de SSP sur Ethereum ? Notre guide Ethereum dans SSP couvre les bases.