Pourquoi un appel de contrat échoue après simulation réussie

2026-09-03

Votre portefeuille affiche un aperçu du swap, indique ce que vous allez recevoir et ne signale aucun problème. Vous signez, et la transaction atterrit sur la chaîne comme un échec qui vous prélève quand même du gas. L’aperçu ne vous a pas menti. Il a répondu à une question portant sur un instant, et votre transaction a été exécutée dans un autre.

Pourquoi un appel de contrat échoue après simulation réussie : les points clés en un coup d’œil

Ce qu’exécute réellement une simulation

Un aperçu de portefeuille est un essai à blanc. Un nœud exécute votre appel sur une copie de l’état de la chaîne, indique ce qui se passerait, puis jette le résultat. La documentation développeur d’Ethereum décrit la méthode sous-jacente comme exécutant immédiatement un nouvel appel de message sans créer de transaction sur la chaîne de blocs, et décrit la méthode de gas associée comme renvoyant une estimation alors que la transaction ne sera pas ajoutée à la chaîne de blocs.

Deux propriétés découlent de cette description, et toutes deux comptent par la suite. L’essai à blanc est exécuté sur un bloc choisi : sa réponse est donc épinglée à l’état de ce bloc. Et il tourne seul, sans que rien d’autre ne s’exécute entre l’appel et le résultat.

L’état sur lequel vous avez simulé n’est pas celui dans lequel vous atterrissez

Entre l’aperçu et l’exécution, votre transaction doit faire un trajet. Elle est signée, diffusée, conservée dans un mempool, sélectionnée par un producteur de blocs, puis seulement exécutée selon les règles du bloc qui la contient. Chaque étape de ce trajet prend du temps, et la chaîne ne s’arrête pas pendant ce temps.

Le code du contrat lit l’état au moment de l’exécution, jamais au moment de la simulation. Les réserves d’un pool, la réponse d’un oracle, une autorisation de dépense accordée, une entrée en liste blanche, un indicateur de pause, un plafond par adresse, une enchère déjà close : chacune de ces valeurs peut valoir une chose quand l’aperçu tourne et une autre quand le bloc est construit. Un contrat qui inspecte une telle valeur et s’arrête lorsque la condition n’est pas remplie se comporte de façon identique dans les deux instants. Ce qui a changé, c’est l’entrée.

Sortie minimale et échéance : les contrôles qui échouent exprès

Un appel de swap peut porter deux garde-fous dans l’appel lui-même. Le premier est un plancher sur ce que vous devez recevoir, dérivé de votre tolérance au slippage. Le second est un horodatage au-delà duquel l’appel n’est plus valide. Tous deux sont des arguments que vous signez, donc tous deux sont figés sur les valeurs calculées par l’aperçu.

Supposons que l’aperçu annonce 10 000 USDC pour les jetons que vous vendez et que votre tolérance soit réglée sur 0,5 %. L’appel porte alors un plancher de 9 950 USDC, et le contrat reçoit l’instruction d’abandonner toute l’interaction plutôt que de livrer moins. Lorsque le prix bouge au-delà de votre tolérance pendant que la transaction est en route, le garde-fou fait exactement ce que vous lui avez demandé. L’échéance se comporte de la même façon : un appel qui reste non confirmé au-delà de son propre horodatage est refusé à son arrivée, alors que le même appel serait passé quelques minutes plus tôt.

C’est le cas où l’échec est la protection qui fonctionne. Un garde-fou qui ne se déclenche jamais laisserait l’interaction se régler au prix vers lequel le marché aurait dérivé au moment de la construction du bloc.

Ordonnancement : la même transaction à une autre place

Un bloc est une séquence, et l’ordonnancement des transactions décide quelle interaction voit quel état. Votre aperçu a placé l’appel en tête d’une file vide. Le bloc le place derrière tout ce que le producteur y a mis, et ces voisins peuvent consommer la liquidité, l’autorisation de dépense ou le solde restant sur lesquels comptait votre appel.

Un mint à plafond strict le montre clairement. Dix portefeuilles peuvent chacun simuler avec succès le dernier exemplaire disponible, parce que chaque aperçu tourne sur un état où cet exemplaire n’est pas encore pris. L’un d’eux atterrit le premier et les neuf autres rencontrent un contrat épuisé. Rien n’était faux dans ces neuf aperçus. Ils ont répondu à une question qui avait une réponse avant l’existence du bloc et une autre ensuite.

Gas : une estimation n’est pas une réservation

Une estimation de gas se produit de la même manière que l’aperçu, en exécutant l’appel une fois et en le mesurant. La même documentation prévient que l’estimation peut être nettement supérieure à la quantité de gas réellement utilisée par la transaction, et c’est le sens inverse qui fait mal : une estimation mesurée sur un chemin bon marché peut être insuffisante pour le chemin que la transaction finit par emprunter.

C’est aux embranchements de l’exécution que cet écart s’ouvre. Un swap routé par un pool lors de l’aperçu peut passer par deux à l’exécution ; la première écriture dans un emplacement de stockage coûte plus cher qu’une écriture ultérieure au même endroit ; une boucle qui a touché trois positions peut en toucher neuf. Si la limite que vous avez signée s’épuise en cours d’exécution, le travail est défait et le gas est tout de même consommé, ce qui relève de la même arithmétique que pour toute transaction échouée. Laisser de la marge au-dessus de l’estimation n’augmente pas les frais quand cette marge reste inutilisée, car comment le gas est tarifé sépare la quantité de travail du prix par unité de travail.

Quand la simulation ne simulait pas la transaction que vous avez envoyée

Parfois, l’aperçu et l’exécution ne sont même pas le même appel. Une simulation est réalisée sur un point d’accès d’un réseau donné : un portefeuille pointé vers une autre chaîne ou vers un nœud dont l’état est périmé répond donc au sujet d’un monde différent de celui dans lequel votre signature est diffusée.

Votre propre file d’attente en attente de confirmation est une deuxième source de ce décalage. Les transactions d’un compte s’exécutent dans l’ordre du nonce : un appel antérieur non confirmé issu du même portefeuille tourne donc en premier et peut modifier l’état dont dépend un appel ultérieur. Lorsque cet appel antérieur est une approbation non confirmée, l’interaction placée derrière lui peut être simulée sur l’autorisation que vous attendez et exécutée sur celle dont vous disposez réellement.

Ce que montrait l’aperçu	Ce qui avait changé à l’exécution	Où regarder
Un montant de sortie annoncé	Les réserves ou la réponse de l’oracle ont bougé	L’argument de sortie minimale dans l’appel signé
Un appel valide	L’horodatage signé était dépassé	L’argument d’échéance et le temps passé en attente
De la liquidité ou du solde disponible	Une autre transaction du bloc l’a pris avant	La place de votre transaction au sein de son bloc
Une estimation de gas	L’exécution a pris une branche plus longue	Le gas consommé face à la limite de gas du reçu
Un essai à blanc propre	Le portefeuille était sur un autre réseau ou nœud	L’identifiant de chaîne et le point d’accès à la signature

À quoi ressemble l’échec ensuite

Une interaction qui s’arrête ainsi est enregistrée. Elle occupe une position dans un bloc, elle consomme du gas, et son reçu porte un champ de statut : l’EIP-658 a remplacé la racine d’état intermédiaire du reçu par un code de statut où zéro signale l’échec et un le succès. Les explorateurs transforment ce champ en l’étiquette annulée.

L’étiquette nomme le résultat et non la cause. Certains contrats joignent une chaîne de motif lorsqu’ils s’arrêtent, et un explorateur ou une trace peut la faire remonter ; d’autres s’arrêtent sans rien joindre. Lire la transaction échouée à côté des arguments que vous avez réellement signés est ce qui transforme un code de statut en diagnostic, car ces arguments sont la partie de l’histoire que le reçu ne peut pas reconstituer pour vous.

Ce qui réduit vraiment le taux d’échec

Réduisez l’écart. Un aperçu pris juste avant de signer décrit un état plus proche de celui que contiendra le bloc, et une transaction qui se confirme vite a moins de temps pour se faire doubler.

Dimensionnez les garde-fous en fonction de l’actif plutôt que de l’habitude. Un plancher assez serré pour refuser une minute ordinaire de mouvement sur un marché peu profond arrêtera vos interactions encore et encore, tandis qu’un plancher assez lâche pour tout accepter abandonne la protection pour laquelle vous l’aviez posé. Le même jugement vaut pour l’échéance, qui doit être assez longue pour survivre à une période de congestion.

Traitez un échec répété comme une information. Quand la même interaction s’arrête plusieurs fois avec les mêmes arguments, le contrat signale une condition qui ne peut pas être satisfaite actuellement, et renvoyer le même appel dépense du gas pour obtenir la même réponse.

En résumé

Une simulation répond à la question de ce qui se passerait si cet appel tournait maintenant, seul, sur ce bloc. Une exécution en chaîne répond à ce qui s’est passé quand l’appel a tourné plus tard, parmi d’autres transactions, sur un autre bloc. Un échec après un aperçu propre, c’est la distance entre ces deux questions, et les garde-fous que vous avez signés sont ce qui convertit cette distance en arrêt plutôt qu’en mauvaise exécution. Vérifiez les arguments de l’appel signé, la place de la transaction dans son bloc et le gas consommé face à la limite de gas : la raison se trouve dans l’un des trois. Pour continuer à apprendre les fondamentaux, suivez d’autres contenus de Bitbase Academy.

Articles associés

Autres articles Bitbase sur ce sujet :

- Comment changer de point d’accès RPC en toute sécurité

- Frais de transaction maximum dépassés : ce que signifie cet avertissement du portefeuille

- Limite de requêtes RPC dépassée et comment y remédier

- FIFO et LIFO pour le prix de revient en crypto

- Prime mémétique : pourquoi les mèmes influencent les prix

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.