Un projet passe à un nouveau contrat, vous ouvrez la page de migration et, avant qu’un seul jeton n’ait bougé, votre portefeuille vous demande d’approuver l’ancien. La demande ressemble à une étape ajoutée par quelqu’un au parcours. Elle ne l’est pas. Dans ERC-20, c’est le seul moyen de confier un solde à quelqu’un d’autre que vous, et savoir la lire sépare une migration d’un portefeuille vidé.
Ce que l’approbation accorde réellement
Une approbation est une écriture dans un registre qui vit à l’intérieur du contrat de l’ancien jeton. Elle consigne un seul nombre pour une paire d’adresses : combien de ce jeton un dépensier nommé est autorisé à sortir de votre compte. La signer ne déplace rien, n’envoie rien au projet et ne vous engage à aucun échange.
Dans la norme jeton ERC-20, ce registre est atteint par deux fonctions. `approve` autorise un dépensier à prélever sur votre compte de façon répétée, jusqu’à un montant fixé, et `transferFrom` est l’appel qui déplace réellement les jetons d’une adresse à une autre. La spécification présente la paire comme un flux de retrait qui laisse les contrats transférer des jetons en votre nom, et un contrat de migration est l’un de ces contrats, sans statut particulier.
L’endroit où l’écriture est stockée compte plus qu’il n’y paraît. L’autorisation réside dans l’ancien jeton, pas dans le contrat de migration, elle survit donc à la page de migration, à l’échange lui-même et au projet. Fermer l’onglet ne l’efface pas.
Pourquoi le contrat d’échange doit le demander
Un échange doit prendre les anciennes unités avant de pouvoir créditer les nouvelles. Le contrat ne peut pas puiser seul dans votre compte, et au sujet de votre solde, le contrat du jeton n’écoute que le compte qui le détient.
L’alternative apparente consiste à envoyer vous-même les anciens jetons au contrat par un transfert ordinaire. Cela déplace bien les jetons, et cela échoue aussi : un transfert simple arrive comme un solde sans appel qui l’accompagne, le contrat n’est donc jamais informé du transfert et n’a rien à créditer. La norme ERC-223 a été écrite autour de cette panne précise. Tirer via `transferFrom` donne au contrat un appel unique dans lequel il reçoit les anciennes unités et verse les nouvelles, et cet appel exige une autorisation au préalable.
Deux transactions, et seule la seconde échange
L’approbation et l’échange sont des transactions distinctes, chacune avec son propre gas. ERC-2612 énonce la forme sans détour : si un utilisateur doit interagir avec un contrat intelligent, alors il lui faut 2 transactions, `approve` et l’appel du contrat qui appellera en interne `transferFrom`.
Parce qu’elles sont distinctes, la première peut réussir tandis que la seconde échoue quand même. Une fenêtre d’échange refermée, une réserve de paiement vidée, un contrat en pause : rien de tout cela n’est visible pour l’approbation, qui se contente d’écrire un nombre et de rendre la main. Une approbation confirmée ne prouve pas que la migration derrière elle fonctionne.
Le piège inverse se tient un cran plus loin. Un échange après une simulation réussie peut toujours être annulé on chain, car la simulation répond à une question sur l’état à un instant et non sur l’état dans lequel votre transaction atterrit. Quand l’échange est annulé, l’autorisation accordée reste intacte et toujours en vigueur.
Les migrations qui n’ont aucune raison de demander
Toutes les migrations ne reposent pas sur une autorisation. La forme qu’on vous a annoncée devrait correspondre à la demande que vous avez reçue.
| Comment la migration est menée | Ce que vous envoyez | Une approbation a-t-elle sa place ici |
|---|---|---|
| Un contrat d’échange tire vos anciennes unités | Une approbation, puis l’appel d’échange | Oui |
| Vous transférez les anciens jetons vers une adresse publiée | Un transfert ordinaire | Non |
| Les détenteurs inscrits sont crédités depuis un instantané | Rien | Non |
| Une plateforme convertit son propre solde mutualisé | Rien | Non |
La ligne qui doit vous arrêter est la troisième. Une distribution annoncée comme automatique n’a aucun mécanisme qui ait besoin de votre autorisation : une page qui la réclame demande donc quelque chose que la migration décrite n’utilise pas. Repérer ce décalage ne coûte rien et ne dépend du jugement de personne sur le site.
Les trois champs de la demande qui décident de tout
Toute demande d’approbation porte les trois mêmes champs, quel que soit le nom que leur donne votre portefeuille.
| Champ | Ce qu’il accorde | À quoi le comparer |
|---|---|---|
| Jeton | Dans le registre de quel contrat l’écriture est faite | L’adresse de l’ancien contrat issue de l’annonce du projet |
| Dépensier | Quelle adresse peut prélever sur votre compte | L’adresse du contrat de migration issue de la même annonce |
| Montant | Le plafond de ce que cette adresse peut prendre | La tranche que vous comptez échanger maintenant |
Comparez les adresses en entier. Une adresse ressemblante peut partager avec la vraie ses premiers et derniers caractères, et la différence se loge au milieu.
Le champ du dépensier est celui qui porte la perte, et c’est pourquoi un drainer de portefeuille n’a besoin de rien casser. Il place sa propre adresse dans ce champ et vous laisse signer une approbation valide et correctement formée. La transaction réussit exactement comme elle est écrite, et le solde part plus tard, au rythme de l’attaquant plutôt qu’au vôtre.
Quand la demande est une signature et non une transaction
Une autorisation n’arrive pas toujours sous forme de transaction. ERC-2612 étend la norme ERC-20 avec une fonction `permit` qui permet aux utilisateurs de modifier la table allowance au moyen d’un message signé, au lieu de passer par `msg.sender` ; un permit valide fixe l’autorisation de ce dépensier à la valeur indiquée, incrémente un nonce et émet un événement d’approbation.
La conséquence est qu’un écran affichant un simple message à signer, sans gas et sans transaction en attente, peut accorder exactement ce qu’accorde une transaction d’approbation. Au moment où vous signez, il ne laisse d’ailleurs rien dans votre propre historique de transactions, puisque le message signé est soumis par quelqu’un d’autre.
Lisez donc une demande de signature selon ces mêmes trois champs. Un permit nomme le dépensier et la valeur qu’il fixe, plus une deadline que la spécification exige de ne pas dépasser par l’heure du bloc courant. Si une page présente la signature comme une connexion ou une confirmation alors que les données typées nomment un dépensier et un montant, ce sont les données typées qui seront exécutées.
Montant exact ou illimité, et l’autorisation qui reste
Prenons un exemple. Un portefeuille détient 10 000 anciennes unités et le projet a ouvert un échange. Approuver 2 500, échanger cette tranche et confronter ce qui arrive au ratio annoncé transforme la migration en quelque chose d’observé plutôt que de supposé. Les 7 500 restantes exigent ensuite une seconde approbation, soit un paiement de gas de plus, et c’est tout le coût de la méthode.
Une approbation illimitée supprime ce second paiement et le remplace par une autorisation permanente sur ce jeton tant que l’écriture subsiste. Le contrat de migration conserve le droit de tirer toute ancienne unité qui atteint votre compte par la suite, y compris un solde d’anciens jetons que vous récupérez des années plus tard dans un vieux portefeuille.
Terminez en effaçant ce qui reste. Une approbation au montant exact est consommée par l’échange pour lequel elle a été accordée, tandis que tout ce qui dépasse laisse une écriture vivante, et une approbation de jetons qui survit à son objet est une autorisation que plus personne ne surveille. Remettre l’autorisation à zéro est elle-même une transaction avec son propre gas : faites-le délibérément une fois la migration terminée.
En résumé
Une migration demande une approbation parce qu’ERC-20 ne lui laisse aucun autre moyen de prendre vos anciens jetons. L’approbation elle-même est un nombre inscrit dans le contrat de l’ancien jeton, nommant une adresse et un plafond : elle ne déplace rien, ne prouve rien sur la migration qui la suit et n’expire pas quand la page se ferme.
Cela ramène tout le travail à trois vérifications. Cette forme de migration a-t-elle seulement besoin d’une autorisation, le dépensier est-il l’adresse publiée par le projet, et le montant est-il la tranche que vous vouliez échanger. Une demande de signature répond aux trois mêmes, et une autorisation accordée survit à tout ce qui l’entoure : effacez-la une fois l’échange fait. Pour continuer à apprendre les fondamentaux, retrouvez d’autres articles de Bitbase Academy.
Articles associés
Autres articles Bitbase sur ce sujet :
- Comment révoquer une délégation de gouvernance
- Comment calculer l’autonomie de la trésorerie d’un token
- La mécanique de l'offre d'un jeton
- L'ATR et la mesure de la volatilité
- Les bandes de Bollinger expliquées
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en septembre 2026 ; référez-vous aux informations officielles les plus récentes.
Sources
[1] Ethereum Improvement Proposals, ERC-20: Token Standard, les méthodes approve et transferFrom (statut : Final) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-2612: Permit Extension for EIP-20 Signed Approvals, sections Abstract et Specification (statut : Final) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-223: Token with transaction handling model, section Motivation (statut : Final) eips.ethereum.org
