---
title: "Pourquoi certaines approbations de jetons doivent-elles d'abord être remises à zéro ?"
description: "Certains jetons ERC-20 refusent le passage direct d'une allowance non nulle à une autre. Découvrez quand la remise à zéro est nécessaire, pourquoi les deux transactions doivent être confirmées dans l'ordre et quels risques subsistent."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Pourquoi certaines approbations de jetons doivent-elles d'abord être remises à zéro ?
> À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Tout investissement peut entraîner des pertes.
## Réponse directe
Certaines implémentations ERC-20 refusent `approve(spender, newAmount)` lorsque l'allowance existante et `newAmount` sont toutes deux non nulles. Pour ces jetons, soumettez d'abord `approve(spender, 0)`, attendez sa confirmation, puis seulement soumettez la nouvelle approbation non nulle.
Cette contrainte n'est pas imposée à tous les jetons ERC-20. ERC-20 définit `approve` comme le remplacement de l'allowance actuelle et recommande aux interfaces clientes de commencer par zéro pour atténuer une course lors du changement d'approbation, tout en précisant que les contrats de jetons ne devraient pas l'imposer pour préserver la compatibilité. Certains jetons déployés l'imposent néanmoins. La remise à zéro est donc à la fois une procédure de compatibilité et un point de contrôle utile, mais elle ne garantit pas que l'ancienne allowance ne sera pas dépensée avant la confirmation de la transaction de remise à zéro.
## Fonctionnement
1. Vérifiez la chaîne, le contrat du jeton, le propriétaire, le spender et le montant prévu. Lisez `allowance(owner, spender)` dans le contrat du jeton au lieu de vous fier uniquement à un libellé du portefeuille.
2. Si l'allowance vaut déjà `0`, soumettez une seule fois l'approbation souhaitée. Si elle est non nulle, son remplacement direct par une valeur non nulle peut réussir sur une implémentation standard ou être annulé sur un jeton exigeant la remise à zéro.
3. Pour cette procédure, soumettez `approve(spender, 0)` et attendez un reçu positif. Relisez ensuite l'allowance du même couple propriétaire-spender et confirmez qu'elle vaut `0`.
4. Revérifiez le solde du jeton, le spender et l'objectif. Soumettez alors seulement `approve(spender, newAmount)` et attendez sa confirmation avant de considérer la nouvelle allowance comme active.
5. Vérifiez l'allowance finale et examinez les événements `Transfer` et `Approval` intervenus. Un reçu de transaction positif prouve l'exécution, tandis que l'état actuel du contrat indique l'autorisation restante.
`SafeERC20.forceApprove` d'OpenZeppelin fournit un repli de compatibilité aux contrats : il essaie la valeur souhaitée puis, si l'appel échoue, essaie `0` et la valeur souhaitée dans cet ordre. Cet utilitaire modifie l'allowance propre au contrat appelant. Il ne corrige pas automatiquement l'approbation du portefeuille d'un utilisateur et ne dispense pas de vérifier l'ordre des transactions et l'état final.
## Exemple
Un propriétaire a accordé à un spender une allowance de `1000` jetons et veut la réduire à `100`. Sur un jeton exigeant la remise à zéro, `approve(spender, 100)` est annulé : l'allowance on-chain reste donc à `1000`. Un appel annulé ne met pas partiellement l'état à jour.
Le propriétaire soumet plutôt `approve(spender, 0)`. Avant sa confirmation, le spender utilise `400`, ce qui laisse `600` ; la transaction de remise à zéro ensuite confirmée remplace ce reliquat par `0`. Après avoir constaté la baisse de son solde, le propriétaire peut décider d'accorder ou non les nouveaux `100`. S'il les accorde, le spender a déjà utilisé `400` et peut encore utiliser jusqu'à `100`. La remise à zéro révèle cette dépense intermédiaire avant la nouvelle autorisation, mais ne l'annule pas.
## Risques
- L'ancienne allowance reste utilisable jusqu'à l'exécution de la remise à zéro. Un spender peut devancer une révocation ou une réduction en attente.
- Diffuser la remise à zéro et le remplacement sans attendre la première confirmation supprime le point de contrôle prévu et peut masquer une dépense intermédiaire.
- Une chaîne, une adresse de jeton ou une adresse de spender erronée peut créer ou révoquer une autre autorisation que celle visée. Les symboles des jetons ne sont pas des identifiants uniques.
- La procédure en deux étapes coûte deux transactions lorsque les deux sont nécessaires ; chacune peut échouer, être remplacée ou rester en attente. Ne déduisez pas l'état d'une simple signature soumise.
- Les approbations illimitées et les spenders évolutifs ou compromis peuvent exposer les dépôts futurs. Utilisez le plus petit montant pratique et vérifiez l'allowance restante après usage.
- Les intégrations de contrats doivent traiter explicitement les valeurs de retour et comportements d'approbation non standard. Un wrapper de compatibilité ne sécurise pas un spender non fiable.
## Idées reçues
- **Tous les ERC-20 exigent une remise à zéro.** La norme recommande la séquence côté client, mais indique que les contrats de jetons ne devraient pas l'imposer ; seules certaines implémentations refusent un passage direct entre deux valeurs non nulles.
- **La remise à zéro élimine totalement la course d'approbation.** Le spender peut encore utiliser l'ancienne allowance avant la confirmation de la remise à zéro.
- **Un remplacement annulé a effacé l'ancienne allowance.** Une annulation rétablit l'état antérieur à la tentative ; l'allowance précédente subsiste donc normalement.
- **Envoyer les deux transactions ensemble revient à attendre.** Le point de contrôle vient de la confirmation et de l'inspection de l'état nul avant de décider du remplacement.
- **Déconnecter un site révoque son approbation.** L'état de connexion du portefeuille et l'allowance on-chain du contrat de jeton sont distincts.
## Sujets connexes
- [Course d'approbation ERC-20](/fr/crypto/erc20-approval-race-condition/)
- [Approbation de portefeuille](/fr/crypto/wallet-approval/)
- [Nonce et deadline d'un Permit ERC-2612](/fr/crypto/erc2612-permit-nonce-deadline/)
- [Risque des signatures Permit2](/fr/crypto/permit2-signature-risk/)
## Sources
- [ERC-20 : norme de jeton](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulté le 2026-08-21)
- [ERC20 | Documentation OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20) - OpenZeppelin (consulté le 2026-08-21)
- [SafeERC20.sol](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol) - OpenZeppelin (consulté le 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/token-approval-zero-first/index.mdx