Une transaction bitcoin : comment la lire et la suivre

Au cœur du bitcoin se trouve un registre ouvert, donc avec les compétences appropriées, tout transfert peut être retracé d'adresse en adresse. Une industrie entière a émergé de cela : les traders suivent les baleines et les flux vers les échanges, les experts en criminalistique blockchain aident à récupérer des fonds volés, et la conformité filtre les pièces "sales".

Dans ce guide, nous allons étape par étape analyser les transactions manuellement, comment automatiser le travail avec l'aide d'outils et d'automatisation, et aussi pourquoi même le traçage le plus avancé donne une probabilité plutôt qu'une réponse à cent pour cent.

Nous laisserons de côté les définitions de base et les métriques de marché — il existe un matériel séparé pour cela sous forme de carte.

Partie 1. Analyser les transactions manuellement

Étape 1. Trouver une transaction par TXID

Chaque transfert sur la blockchain a un identifiant unique — le TXID, le hachage de la transaction. C'est une longue chaîne, généralement de 64 caractères, que le réseau obtient en exécutant toutes les données de transfert — entrées, sorties, montants et signatures — à travers l'algorithme SHA-256.

Il est pratiquement impossible de falsifier un tel hachage : la moindre modification des données donne une chaîne complètement différente, donc deux TXID identiques n'existent pas. En essence, c'est un "numéro de reçu" par lequel n'importe quel nœud sur le réseau peut trouver et vérifier l'opération.

La façon d'obtenir le hachage dépend de ce que vous avez déjà :

• si le transfert a déjà été effectué — il peut être ouvert dans l'historique d'un portefeuille ou d'un échange. À côté de l'opération, il y a généralement un lien tel que "Voir dans l'explorateur" : il mène à la page de la transaction, où l'identifiant est affiché en entier ;
• si vous n'avez que l'adresse de l'expéditeur ou du destinataire — elle est collée dans la barre de recherche de n'importe quel explorateur de blockchain. L'historique de l'adresse s'ouvrira avec tous les transferts ; la transaction nécessaire peut être identifiée par le montant et la date, et son hash trouvé sur la page de la transaction elle-même.

Étape 2. Comprendre la structure d'une transaction : entrées, sorties et changement

Contrairement à un compte bancaire, le bitcoin ne stocke pas le solde comme un seul nombre. Le réseau fonctionne sur le modèle UTXO (sortie de transaction non dépensée) : les fonds existent sous forme de "billets" séparés de différentes dénominations, tandis que le portefeuille ne stocke que les clés qui y sont associées. Le solde disponible est la somme de toutes ces sorties contrôlées par le propriétaire.

Un "billet" ne peut pas être dépensé partiellement. Lors d'un paiement, une telle sortie entre dans la transaction en entier, et en retour, le réseau crée deux nouvelles sorties : une pour le destinataire, la seconde comme changement de retour à l'expéditeur à une nouvelle adresse.

Prenons un exemple. Alice a une sortie de 5 BTC, et elle transfère 0,01 BTC à Bob. Sur la blockchain apparaissent une entrée de 5 BTC, un paiement de 0,01 BTC, et un changement d'environ 4,99 BTC (moins les frais).

Tout observateur peut voir l'ensemble de l'opération à travers un explorateur — un paiement "rond" est facile à distinguer d'un changement "fractionné". La détermination de l'adresse de changement dans la criminalistique blockchain est basée sur cette caractéristique.

Étape 3. Vérification des confirmations et du mempool

Une transaction envoyée n'atteint pas la blockchain instantanément. D'abord, le transfert se retrouve dans le mempool — une file d'attente commune d'opérations en attente d'inclusion dans un bloc. À ce stade, des retards sont possibles : les mineurs priorisent généralement les opérations avec des frais plus élevés, donc avec des frais trop bas, un transfert peut rester dans la file d'attente pendant longtemps.

Dès que l'opération atteint un bloc, elle obtient sa première confirmation. Après que l'enregistrement soit inclus dans un bloc, il reçoit sa première confirmation. Avec chaque confirmation suivante, le niveau de fiabilité augmente, et la probabilité d'annulation devient de plus en plus faible. Pour de petites sommes, une ou deux confirmations suffisent généralement, tandis que pour de gros paiements, il est d'usage d'attendre six.

Il est pratique de suivre cela en temps réel par le hachage : l'explorateur montrera si le transfert est bloqué dans la file d'attente, dans quel bloc il s'est retrouvé, combien de confirmations il a obtenues, et quels frais l'expéditeur a payés. Si l'opération est bloquée pendant longtemps, la même page suggérera la raison — le plus souvent des frais sous-évalués.

Étape 4. Suivre le chemin d'une pièce

Chaque entrée d'une nouvelle opération fait référence à une sortie spécifique de l'une des précédentes — par son hash, et elle peut avoir plusieurs entrées et sorties à la fois. Par conséquent, les transferts ne forment pas une seule chaîne mais un réseau ramifié : les pièces à l'intérieur convergent et divergent entre les adresses.

Le long de ce réseau, le mouvement des fonds peut être tracé dans les deux sens — vers de nouvelles adresses et en arrière, jusqu'à la transaction coinbase dans laquelle elles sont apparues pour la première fois comme une récompense pour un bloc miné.

En pratique, un analyste suit les adresses de sortie et regarde où les fonds sont allés ensuite. Ensuite, il répète la même chose avec les nouvelles adresses — étape par étape, jusqu'à ce qu'une chaîne complète se forme.

C'est ainsi que des routes caractéristiques émergent sur la blockchain : un transfert vers un échange, le fractionnement d'une grande somme en parties, ou le retrait de fonds volés à travers plusieurs portefeuilles intermédiaires.

Exemple : en 2025, l'adresse d'un investisseur précoce a montré une activité pour la première fois après 13 ans de dormance, transférant 909 BTC (environ 85 millions de dollars) vers un nouveau portefeuille. Ces pièces ont été reçues en 2012–2013, lorsque le prix du bitcoin ne dépassait pas quelques dollars.

Un tel transfert est visible dans n'importe quel explorateur : il suffit d'ouvrir l'adresse, de suivre les chaînes de sortie et de voir où les fonds ont été déplacés ensuite.

Partie 2. Mettre l'analyse sur un convoyeur

L'analyse manuelle est bonne lorsqu'il y a une ou deux transactions. Mais le registre se renouvelle chaque seconde, et des milliers de transferts ne peuvent pas être couverts à l'œil.

Ici, l'automatisation vient à la rescousse : les programmes demandent eux-mêmes des données au réseau, calculent des métriques et envoient une notification au bon moment. Examinons ses trois niveaux : accès aux données, analyses et surveillance.

Étape 5. Connexion aux données via API

Le premier niveau est l'accès programmatique à la blockchain via les API des nœuds et des explorateurs. C'est une interface par laquelle un script demande les mêmes informations que nous pouvions auparavant voir sur la page de transfert (mais sans intervention humaine et dans n'importe quel volume).

Le service mempool.space propose deux options. L'API REST répond aux demandes ponctuelles : statut de la transaction, solde d'adresse, état du mempool. L'API WebSocket maintient une connexion constante et envoie elle-même des mises à jour — vous pouvez vous abonner à une adresse et recevoir un signal chaque fois qu'un nouveau transfert la traverse.

Pour des vérifications en masse, Blockchair et Bitquery sont adaptés : ils renvoient des données pour de nombreuses adresses à la fois et prennent en charge les webhooks.

Étape 6. Automatisation des analyses

Le deuxième niveau est constitué de plateformes qui vous permettent d'écrire une requête une fois et de recevoir un tableau de bord prêt au lieu d'un résultat ponctuel.

Sur Dune, les données de la blockchain sont interrogées en langage SQL et affichées sur des graphiques ; un rapport sur les flux d'échange, l'activité des baleines ou les principaux détenteurs se met à jour sans requête répétée.

Flipside est organisé de manière similaire — il dispose également d'un SDK Python gratuit par lequel les données peuvent être extraites directement dans des scripts personnalisés.

La principale différence par rapport à la méthode manuelle est simple : la requête est écrite une fois mais fonctionne en permanence. Auparavant, un analyste examinait le graphique quotidiennement — maintenant, il existe des tableaux de bord qui se mettent à jour automatiquement.

Étape 7. Configuration de la surveillance et des alertes

Le troisième niveau est les notifications au lieu de rafraîchir manuellement la page. Une combinaison de "API plus bot" surveille les adresses nécessaires et envoie une notification dès que des fonds arrivent ou partent. C'est ainsi que fonctionnent à la fois les alertes publiques sur les grandes transactions de baleines et les alertes privées, par exemple concernant le retrait de pièces d'un portefeuille spécifique.

Un ensemble de base peut être configuré même sans programmation : des plateformes comme Arkham offrent des alertes prêtes à l'emploi sur les transferts et l'activité des baleines qui arrivent par e-mail ou sur l'application. Pour ceux qui ont besoin de leur propre logique de gestion des événements, les webhooks sont adaptés — ils envoient automatiquement une notification au serveur lorsqu'un événement spécifié se produit.

Partie 3. Traçage et ses limites

Étape 8. Comment fonctionne l'analyse judiciaire de la blockchain

Le summum de l'automatisation est le traçage des pièces volées et l'enquête sur les transactions. Les moteurs d'analyse judiciaire répètent la logique de l'analyse manuelle mais l'appliquent à l'échelle de l'ensemble du réseau.

Au cœur de cette technologie se trouve le regroupement d'adresses par heuristiques, c'est-à-dire des règles d'hypothèse ; deux d'entre elles sont particulièrement importantes :

• entrée commune : si plusieurs UTXO sont dépensés dans une seule transaction, ils sont avec une forte probabilité contrôlés par un seul propriétaire ;
• détermination de l'adresse de changement : par la fonctionnalité de l'étape 2 — un paiement arrondi contre un changement fractionné — le moteur détermine lequel des résultats retournés au l'expéditeur.

En plus du regroupement, la reconnaissance des schémas typiques de blanchiment est ajoutée. C'est, par exemple, le fractionnement de sommes ou le "peeling" — lorsque de petites portions sont détachées d'un grand portefeuille encore et encore.

Vient ensuite l'évaluation des risques et l'attribution : lier des clusters à de véritables échanges, services ou individus. Les deux plateformes commerciales (Chainalysis, TRM, Elliptic) et les moteurs ouverts (GraphSense, BlockSci) font cela.

Étape 9. Peut-on faire confiance à l'automatisation

L'analyse automatique a une limitation fondamentale. Le regroupement donne une probabilité, pas un fait. Les heuristiques font des erreurs : par exemple, la technologie CoinJoin combine délibérément les UTXO de différents utilisateurs dans une seule transaction, ce qui provoque un dysfonctionnement de la règle d'entrée commune.

Le risque de fuite de données peut également être réduit manuellement. La fonction de contrôle des pièces dans les portefeuilles (par exemple, Sparrow ou Trezor Suite) vous permet de choisir vous-même quel UTXO dépenser : choisissez une sortie correspondant au montant du paiement et ne mélangez pas les pièces de différentes sources dans une seule transaction. Cela réduit le changement et empêche l'heuristique d'entrée commune de se déclencher — les mêmes indices sur lesquels le regroupement est basé.

Le Bitcoin ne fournit pas d'anonymat mais de la pseudonymie — une propriété plus faible que l'analyse persistante "perfore" souvent, mais pas toujours : le résultat reste une estimation, bien que fondée. Comme le souligne Chainalysis, les heuristiques d'attribution donnent un résultat probabiliste plutôt qu'une certitude, donc une évaluation des risques n'est qu'une base pour la décision de l'analyste, pas un verdict.

D'où une conclusion pratique. Il vaut la peine de distinguer le regroupement automatique d'adresses de l'attribution vérifiée par un humain : le premier est une hypothèse, le second est une conclusion. Le résultat d'une évaluation des risques est une raison d'examiner de plus près une adresse, pas une sentence sur son propriétaire.

***

Le grand livre ouvert rend chaque transfert de bitcoin traçable — toute analyse on-chain est construite sur cela. Pour le travail manuel, les bases suffisent : savoir ce qu'est un TXID, comprendre le modèle UTXO et la mécanique du changement, lire les entrées, les sorties et les confirmations dans un explorateur. Cela suffit pour parcourir des chaînes de transactions et voir où les fonds ont été déplacés.

L'automatisation sous forme d'APIs, de tableaux de bord SQL et de bots ne supprime pas le besoin de ces bases — elle permet simplement de mettre à l'échelle le travail : ce qu'un analyste fait à la main avec une transaction, les outils le répètent pour l'ensemble du réseau.

En haut se trouvent les enquêtes judiciaires avec le regroupement et l'évaluation des risques. Cependant, cela repose sur des heuristiques probabilistes, et donne donc des hypothèses plutôt qu'une preuve.

Il est logique de maîtriser le sujet de bas en haut : d'abord l'explorateur, puis les API et les tableaux de bord, et enfin les outils d'analyse on-chain spécialisés. En même temps, plus le traçage est approfondi, plus il est important de distinguer le probable du prouvé.

Source : ForkLog