Vous avez cliqué sur Send dans votre portefeuille, vous avez vu l’interface tourner, puis… vous avez fixé l’écran en attendant. Vous avez peut-être instinctivement pensé que l’argent allait arriver sur le compte du destinataire en quelques secondes, comme pour un virement depuis une appli bancaire. Mais parfois, le statut reste sur Pending pendant plus de dix minutes ; parfois, vous voyez qu’un hash de transaction a déjà été généré, alors que le destinataire dit n’avoir rien reçu.
C’est précisément là que les choses deviennent déroutantes : après avoir cliqué sur Send, il se passe beaucoup de choses avant qu’une transaction ne devienne réellement un enregistrement immuable sur la blockchain. Il ne s’agit pas d’une action instantanée de type « envoi—réception », mais d’un parcours avec des étapes bien définies. Cet article suit le cycle de vie complet d’une transaction et décompose ce processus étape par étape, pour vous aider à comprendre quand votre action est réellement terminée et par quelles étapes elle est passée.
Ce que fait d’abord le portefeuille lorsque vous cliquez sur Send
Lorsque vous saisissez l’adresse du destinataire, indiquez le montant et appuyez sur Send, la première chose que fait le portefeuille n’est pas « d’envoyer l’argent ». Il assemble une transaction localement, sur votre appareil.
L’adresse du destinataire et le montant que vous saisissez ne sont, au fond, que votre intention. C’est comme écrire « payer 100 yuans à Zhang San » sur un formulaire de virement vierge : ce formulaire n’a encore aucune valeur — il exprime seulement ce que vous voulez faire. Le travail du portefeuille consiste ensuite à rassembler toutes les informations nécessaires à cette transaction.
Cette transaction contient généralement les informations clés suivantes :
- L’adresse du destinataire
- Le montant du transfert
- L’identifiant associé à l’expéditeur
- Les paramètres de frais (combien de frais vous êtes prêt à payer pour cette transaction)
- Le nonce ou numéro de séquence (utilisé pour identifier l’ordre des transactions émises depuis votre compte et éviter qu’une transaction soit soumise plusieurs fois ou traitée dans le désordre)
Une fois ces champs assemblés, le portefeuille fait une chose essentielle : il signe numériquement les données de la transaction avec votre clé privée.
Cette étape est le maillon de sécurité le plus important de tout le processus. Vous seul possédez la clé privée. Signer une transaction avec elle revient à prouver à l’ensemble du réseau que « ce transfert est bien autorisé par le propriétaire des actifs ». Sans cette signature, les nœuds n’accepteront pas la transaction.
Une fois la signature terminée, les données de la transaction produisent un hash de transaction unique. Vous pouvez le voir comme la « carte d’identité » de la transaction — une chaîne unique calculée à partir du contenu de la transaction. Plus tard, lorsque vous consulterez le statut de la transaction dans un explorateur de blocs, c’est ce hash que vous utiliserez.
Mais attention : à ce stade, rien ne s’est réellement produit. La transaction a seulement été préparée et signée sur votre appareil. Elle n’est pas entrée dans la blockchain, et personne d’autre ne l’a encore vue.
Pour utiliser une analogie : c’est comme rédiger et signer un formulaire de virement avec le destinataire et le montant, mais le formulaire est encore entre vos mains et n’a été remis à personne. La signature termine l’autorisation, mais les fonds n’ont pas bougé.
Comment une transaction entre dans le réseau blockchain
Une transaction signée ne va pas voler d’elle-même jusqu’à la blockchain. Le portefeuille doit la diffuser.
Concrètement, le portefeuille envoie généralement la transaction signée via un nœud RPC ou un service d’API blockchain. Ce nœud fait office de point d’entrée : c’est par lui que la transaction pénètre dans le réseau blockchain.
Après réception de la transaction, le nœud effectue d’abord quelques vérifications de format de base — par exemple, les champs sont-ils complets, la taille de la transaction respecte-t-elle les exigences — puis il la place dans un espace appelé mempool.
La mempool peut être comprise comme une « salle d’attente des transactions en attente ». Toutes les transactions qui ont passé les vérifications de base mais n’ont pas encore été intégrées à un bloc y restent temporairement. Ce n’est pas un état sur la blockchain ; c’est simplement une « liste de tâches » tenue localement par chaque nœud.
Une fois la transaction entrée dans la mempool, le nœud continue aussi à la propager à d’autres nœuds. Un nœud la transmet à quelques voisins, ces voisins la transmettent à davantage de voisins, et bientôt un grand nombre de nœuds du réseau reçoivent la transaction. C’est ce que l’on appelle la diffusion.
C’est ici que vous rencontrez le premier malentendu courant. Beaucoup de gens pensent qu’après avoir cliqué sur Send, l’argent arrive immédiatement sur le compte du destinataire. En réalité, cliquer sur Send ne fait que terminer la signature locale et la diffusion initiale ; la transaction a seulement commencé à se propager dans le réseau et n’a été écrite dans aucun bloc. Le destinataire ne verra pas de changement de solde à ce moment-là, car l’état on-chain n’a pas encore changé.
Si vous saisissez le hash de transaction dans un explorateur de blocs à ce stade, vous pouvez voir un statut Pending. Cela signifie que la transaction est entrée dans la mempool et attend d’être intégrée à un bloc, mais qu’elle n’est pas « on-chain ». Le fait que le hash soit trouvable indique seulement que le réseau connaît déjà l’existence de la transaction.
Comment les nœuds vérifient une transaction
Une transaction déjà entrée dans la mempool n’est pas forcément valide. Les nœuds la vérifient selon plusieurs dimensions.
La vérification de signature est la première étape. Le nœud vérifie si la signature de la transaction provient bien de la clé privée correspondant à l’adresse de l’expéditeur. Si la signature ne correspond pas, la transaction est rejetée directement.
La vérification du solde est la deuxième étape. Le nœud vérifie si l’adresse de l’expéditeur dispose de suffisamment d’actifs pour payer le montant du transfert et les frais. Par exemple, l’adresse d’Alice contient 10 ETH et elle essaie d’envoyer 2 ETH. Le nœud confirme que son solde couvre bien 2 ETH plus les frais. Si le solde est insuffisant, la transaction est rejetée et ne reste pas dans la mempool.
La vérification du nonce ou du numéro de séquence est tout aussi importante. Sur les blockchains à modèle de compte, chaque transaction émise depuis un compte possède un numéro de séquence croissant. Le nœud vérifie si le nonce de la transaction correspond à l’ordre que l’expéditeur devrait avoir à ce moment-là. Si Alice a déjà envoyé une transaction avec le nonce 5, une deuxième transaction avec le nonce 5 ne peut pas être acceptée à nouveau — cela empêche les mêmes fonds d’être dépensés deux fois et empêche aussi la relecture malveillante de transactions. Si le nonce saute trop loin, la transaction peut également ne pas être traitée, car les transactions précédentes n’ont pas encore été confirmées.
La vérification des paramètres de frais fait aussi partie des contrôles. La transaction doit respecter les frais minimaux exigés par le réseau. Des frais trop bas peuvent être rejetés par les nœuds, ou la transaction peut rester longtemps dans la mempool sans être sélectionnée pour être intégrée à un bloc.
Seules les transactions qui passent ces vérifications restent dans la mempool et continuent à se propager vers d’autres nœuds. Cela explique aussi pourquoi certaines transactions échouent — non pas parce que « le réseau est cassé », mais parce que les nœuds jugent, selon les règles, que la transaction n’est pas valide.
De la mempool au bloc : comment les transactions sont intégrées
Les transactions restent dans la mempool, en attendant d’être « sélectionnées » et intégrées à un bloc. Ce choix n’appartient pas à l’utilisateur, mais au producteur de blocs.
Selon la blockchain, le producteur de blocs peut être un mineur (chaînes PoW) ou un validateur (chaînes PoS), mais la logique de base est similaire : ils choisissent des transactions dans la mempool et les assemblent en un bloc candidat.
Il existe ici une contrainte clé : chaque bloc a une limite de capacité. Cette capacité peut être une taille maximale de bloc ou une limite de gas. Cela signifie qu’un bloc ne peut pas contenir toutes les transactions de la mempool. Le producteur doit faire des choix.
Les règles de sélection ne sont pas entièrement publiques et transparentes, mais elles ont généralement une tendance commune : des frais ou un tip plus élevés augmentent généralement la probabilité d’être sélectionné en priorité. Toutefois, les règles précises varient selon la chaîne, et l’expérience d’une chaîne ne peut pas être appliquée directement à toutes les autres.
Cela explique une question fréquente : pourquoi la transaction de l’autre personne est-elle arrivée on-chain avant la mienne alors que j’ai envoyé la mienne plus tôt ? Parce que l’ordre d’intégration dans les blocs ne dépend pas entièrement de l’heure d’arrivée. La mempool n’est pas une file d’attente ; elle ressemble plutôt à une salle d’attente. Le bus a un nombre de places limité, et l’ordre d’embarquement ne dépend pas uniquement de qui est arrivé en premier.
Pour utiliser une analogie : la mempool est la salle d’attente, et les blocs sont les bus. Chaque bus a un nombre fixe de places. Certaines personnes arrivent plus tôt mais ne montent pas, tandis que d’autres arrivent plus tard mais ont acheté un billet plus cher et peuvent monter en premier.
Lorsqu’une transaction est sélectionnée dans un bloc candidat, elle ne devient pas immédiatement un enregistrement final. Le bloc candidat doit encore passer par la validation du réseau et le consensus avant de pouvoir être réellement ajouté à la chaîne.
Comment un bloc est accepté par le réseau et produit des confirmations
Après avoir assemblé le bloc candidat, le producteur de blocs le diffuse aux autres nœuds du réseau.
Lorsque les autres nœuds reçoivent ce bloc candidat, ils le vérifient selon les règles de leur chaîne respective : la structure du bloc est-elle valide, chaque transaction du bloc est-elle valide, y a-t-il une double dépense, le bloc respecte-t-il les règles de consensus, etc. Seuls les blocs qui passent la validation sont acceptés.
Après le mécanisme de consensus, ce bloc est ajouté à la fin de la blockchain. Lorsque le bloc contenant votre transaction devient un maillon de la chaîne, la transaction obtient sa première confirmation.
Le nombre de confirmations est une notion cumulative. Supposons que votre transaction soit incluse dans le bloc de hauteur 100. Lorsque le bloc de hauteur 101 est ajouté, votre transaction a 2 confirmations ; lorsque la hauteur 102 est ajoutée, elle a 3 confirmations, et ainsi de suite.
Par analogie, la première confirmation ressemble à l’apposition d’un premier sceau officiel, et chaque nouveau bloc ensuite ajoute comme un nouveau sceau. Plus il y a de sceaux, plus il est difficile d’annuler cet enregistrement.
Il faut particulièrement noter ceci : les temps de confirmation et la sémantique de finalité diffèrent selon les blockchains. Certaines chaînes produisent des blocs rapidement, avec un bloc toutes les quelques secondes ; d’autres produisent des blocs plus lentement. Certaines chaînes disposent d’un mécanisme explicite de « finalité », après lequel une transaction est presque impossible à inverser une fois qu’une certaine condition est remplie ; d’autres s’appuient sur la probabilité — plus il y a de confirmations, plus la probabilité d’inversion est faible, mais en théorie elle n’est jamais absolument nulle. On ne peut donc pas appliquer un nombre fixe de confirmations à toutes les chaînes.
Le nombre de confirmations représente le niveau de sécurité, pas la vitesse. Une transaction avec 1 confirmation peut avoir été ajoutée on-chain très récemment ; une transaction avec 100 confirmations a accumulé des confirmations pendant longtemps, et le coût de son inversion est extrêmement élevé.
De Pending à Success : comment savoir si une transaction est réellement on-chain
Après avoir compris l’ensemble du processus, vous pouvez correctement interpréter les différents statuts affichés dans les portefeuilles et les explorateurs de blocs.
Pending signifie généralement que la transaction attend encore dans la mempool et n’a été incluse dans aucun bloc. À ce stade, la transaction attend seulement d’être traitée ; elle n’est pas on-chain.
Lorsqu’une transaction est incluse dans un bloc accepté par le réseau, l’explorateur de blocs affiche que la transaction est confirmée et indique le nombre de confirmations. Dans les détails de la transaction, vous pouvez voir dans quel bloc elle a été incluse et quelle est la hauteur de ce bloc. C’est là la base essentielle pour déterminer qu’elle est « réellement on-chain ».
Success signifie que la transaction a été exécutée et a atteint un état accepté par le réseau. Mais attention : les chaînes n’ont pas toutes exactement la même sémantique de finalité. Certaines chaînes peuvent être considérées comme très difficiles à inverser après un petit nombre de confirmations, tandis que d’autres nécessitent davantage de confirmations pour atteindre un niveau de sécurité élevé. En outre, Success décrit le résultat d’exécution de la transaction ; cela ne signifie pas qu’elle est absolument irréversible dans tous les cas. Il faut aussi tenir compte des règles de finalité propres à la chaîne concernée.
Si une transaction reste longtemps en Pending, les causes courantes incluent des frais fixés trop bas, la congestion du réseau ou un ordre de nonce bloqué. Dans ce cas, de nombreux portefeuilles et réseaux permettent de remplacer la transaction en augmentant les frais, ou proposent des moyens fournis par le portefeuille pour la gérer. Mais il existe une ligne de démarcation importante : une fois qu’une transaction a été confirmée on-chain, elle ne peut pas être annulée directement. L’annulation n’a de sens que pour les transactions qui n’ont pas encore été intégrées à un bloc.
C’est aussi un point où un malentendu courant doit être corrigé : une transaction restée longtemps en Pending n’est pas condamnée à attendre passivement. Vous pouvez consulter l’état actuel du réseau et les fonctionnalités prises en charge par votre portefeuille, puis choisir activement de la remplacer ou de l’accélérer. Mais une transaction confirmée ne peut pas être retirée.
Enfin, pour vérifier le statut d’une transaction, fiez-vous aux informations de confirmation affichées par l’explorateur de blocs et le portefeuille. Le hash de transaction est le point d’entrée pour la recherche, mais voir le hash ne signifie pas en soi que la transaction a réussi à passer on-chain ; ce qu’il faut vraiment regarder, c’est si elle a été incluse dans un bloc confirmé et quel est le nombre de confirmations.
—
Pour récapituler l’ensemble du processus : lorsque vous cliquez sur Send, le portefeuille construit la transaction localement et la signe avec votre clé privée. Cela termine l’autorisation, mais les fonds ne bougent pas. Après avoir été diffusée aux nœuds, la transaction entre dans la mempool, où elle attend la validation et l’intégration dans un bloc. Les nœuds vérifient la signature, le solde, le nonce et les paramètres de frais, et seules les transactions qui passent la validation continuent à se propager. Les producteurs de blocs sélectionnent des transactions dans la mempool, dans la limite de la capacité des blocs, et le niveau des frais influence la probabilité d’être sélectionné. Le bloc candidat est ajouté à la chaîne après validation et consensus par les nœuds du réseau, et la transaction obtient sa première confirmation. Au fur et à mesure que les blocs suivants sont ajoutés, le nombre de confirmations augmente et la difficulté d’inverser la transaction devient de plus en plus grande.
D’un « vous avez cliqué sur un bouton » à « un enregistrement immuable on-chain », une transaction passe essentiellement par trois étapes : autorisation par signature, diffusion et validation, intégration dans un bloc et confirmation. La différence entre Pending et Success est au fond la différence entre « encore en attente » et « déjà on-chain ». Le nombre de confirmations n’est pas un indicateur de vitesse, mais une accumulation de sécurité. Une fois ce processus compris, vous ne serez plus dérouté par Pending et vous pourrez déterminer précisément où en est une transaction.
