Préserver les éléments de preuve sur la chaîne

Une blockchain conserve son historique, mais presque tout ce qu’un enquêteur utilise pour consulter cet historique peut changer. Les explorateurs remanient leurs pages et modifient les étiquettes des adresses, les outils d’analyse mettent à jour leurs attributions, les sites web et les publications sur les forums disparaissent, et les blocs les plus récents peuvent encore être remplacés. Préserver les éléments de preuve sur la chaîne consiste à figer chacune de ces vues à un moment connu, afin qu’une personne chargée de la vérification puisse, des années plus tard, examiner exactement ce que vous avez vu et le confirmer à partir de la chaîne elle-même.

Ce qu’il faut réellement préserver

Le registre brut est la seule partie d’un dossier qu’il est rarement nécessaire de sauvegarder d’urgence : dès qu’un bloc est finalisé, tout nœud honnête renvoie les mêmes données. Ce qu’il faut préserver, c’est le contexte qui l’entoure. Le tableau présente les éléments habituels.

Considérez les données brutes comme les éléments de preuve et tout le reste comme une vue datée de celles-ci. Si une capture d’écran d’explorateur et le nœud se contredisent, le nœud fait foi, et la divergence doit figurer dans vos notes.

Rattacher chaque fait à un bloc

Un txid identifie une transaction, mais ne suffit pas à fixer sa position dans la chaîne que vous avez examinée. Consignez, pour chaque transaction sur laquelle vous vous appuyez :

• la chaîne et le réseau (réseau principal Bitcoin, Ethereum avec l’identifiant de chaîne 1, une L2 nommée et son identifiant de chaîne) ;
• le txid et, pour les chaînes fondées sur un modèle de comptes, l’index de journal de tout événement sur lequel vous vous appuyez ;
• la hauteur du bloc et son hachage ;
• les confirmations, ou le statut de finalité, au moment de la capture ;
• la source : votre propre nœud et la version de son client, ou une API publique nommée ;
• l’heure de récupération en UTC et le fichier dans lequel les données brutes ont été enregistrées, avec son hachage SHA-256.

{
  "fact_id": "F-012",
  "chain": "bitcoin-mainnet",
  "txid": "4f3a…c21e",
  "block_height": 966204,
  "block_hash": "0000…3b9e",
  "confirmations_at_capture": 4828,
  "source": "own node, client v30.x",
  "cross_check": "public explorer API, retrieved 2026-10-14T10:05Z, fields match",
  "retrieved_utc": "2026-10-14T09:42:10Z",
  "raw_file": "raw/4f3a_c21e.json",
  "raw_file_sha256": "0072…33a9"
}

Cet enregistrement relie un fait utilisé dans le rapport (F-012) à la transaction, au bloc et à la source exacts, ainsi qu’à un fichier brut enregistré dont le hachage peut être vérifié. Les empreintes sont abrégées pour l’impression ; l’enregistrement réel contient les 64 caractères hexadécimaux. La ligne de vérification croisée indique qu’une deuxième source, indépendante, a fourni les mêmes valeurs. La leçon Qualité, normalisation et provenance des données présente un enregistrement similaire pour des jeux de données entiers ; l’apport propre à l’investigation numérique est que chaque fait cité dans un rapport peut être rattaché à l’un de ces enregistrements.

Réorganisations et finalité

Les données capturées près de la pointe de la chaîne peuvent être invalidées par une réorganisation, au cours de laquelle les nœuds basculent vers une branche concurrente et les blocs récents deviennent obsolètes. La leçon Blocs, en-têtes et API de nœuds en explique les mécanismes. Pour les éléments de preuve, les règles sont simples :

1. Ne préservez pas comme finalisé ce qui ne l’est pas. Sur Bitcoin, six confirmations constituent la convention courante, et les éléments de preuve destinés à un rapport doivent se situer bien au-delà de ce seuil. Sur Ethereum, utilisez des blocs situés au niveau du point de contrôle finalized ou avant celui-ci, généralement à environ 13 minutes de la tête de chaîne.
2. Consignez le statut au moment de la capture. Si vous avez dû effectuer une capture précoce, par exemple pour documenter un vol en cours, marquez l’enregistrement comme provisoire.
3. Vérifiez à nouveau les enregistrements provisoires une fois qu’ils sont finalisés : récupérez à nouveau la transaction, confirmez qu’elle se trouve dans un bloc ayant le même hachage et consignez la vérification. Si le hachage du bloc a changé, la transaction peut avoir été déplacée ou avoir disparu, et tout ce qui repose sur elle doit être réexaminé.
4. Les couches 2 nécessitent un examen supplémentaire. Les blocs propres à un rollup peuvent sembler finalisés en quelques secondes, mais la garantie la plus forte n’est obtenue que lorsque le lot qui les contient est finalisé sur la chaîne de base, et les retraits depuis les rollups optimistes ajoutent un délai de contestation. Consignez le niveau de finalité sur lequel vous vous êtes appuyé.

La documentation en temps réel reste précieuse : une capture précoce montre ce qui était visible et à quel moment. Elle doit simplement être désignée pour ce qu’elle est.

Vérifier auprès d’une deuxième source

Une source unique peut se tromper : un explorateur peut mal décoder un jeton, afficher un solde périmé ou attribuer une étiquette erronée. Avant qu’un extrait ne devienne un élément de preuve, comparez-le à une source indépendante, idéalement votre propre nœud avec un nœud public, ou deux fournisseurs sans lien entre eux. La requête ci-dessous suppose que l’examinateur a chargé les faits cités dans le rapport dans evidence_facts, et un nouvel extrait provenant d’une deuxième source dans node_check.

-- Faits dont le txid est absent ou se trouve dans un bloc différent dans la deuxième source
SELECT f.fact_id, f.txid, f.block_hash AS cited_block, n.block_hash AS check_block
FROM evidence_facts f
LEFT JOIN node_check n ON n.txid = f.txid
WHERE n.txid IS NULL
   OR n.block_hash <> f.block_hash
   OR n.value_sats <> f.value_sats;   -- pour les chaînes EVM, comparer la valeur en wei et log_index

Chaque ligne renvoyée est un problème à résoudre avant la diffusion du rapport. Un txid absent de la deuxième source indique généralement une erreur de saisie ; le même txid dans un bloc différent signifie que l’enregistrement a été capturé sur une branche remplacée ultérieurement lors d’une réorganisation ; une valeur différente indique généralement une erreur d’unité ou de nombre de décimales. Un résultat vide, accompagné de la requête et de la consignation des deux sources, constitue en lui-même une trace utile de la vérification.

Figer les étiquettes et les résultats des outils

Les étiquettes deviennent obsolètes. Une adresse étiquetée comme appartenant à un prestataire de paiement cette année peut être réétiquetée comme appartenant à une plateforme d’échange l’année prochaine, ou fusionnée dans un cluster plus vaste. Si votre rapport indique qu’un dépôt a été envoyé à la « Plateforme d’échange X », une personne chargée de la vérification doit pouvoir voir l’étiquette telle qu’elle était lorsque vous vous êtes appuyé dessus. Exportez, pour chaque étiquette utilisée : le nom de l’entité, l’adresse ou le cluster qu’elle couvre, la source (publication de l’entité elle-même, enregistrement d’un fournisseur, liste communautaire, outil d’analyse), la version ou la date de la source, et sa note de A à D. La leçon De l’adresse à l’entité puis à la personne : attribution et étiquetage traite de la notation des étiquettes ; il s’agit ici de les figer.

Les résultats des outils nécessitent le même traitement. Enregistrez le fichier de projet natif si l’outil en possède un, un export lisible (CSV ou JSON des nœuds et des arêtes) et une image du rendu, puis consignez la version de l’outil, la méthode de traçage, les limites de sauts et les autres paramètres. Relancer le même dossier dans une version ultérieure peut produire un graphe différent, et vous devrez expliquer la différence. La leçon Outils, reproductibilité et validation explique comment réconcilier les résultats d’outils qui divergent.

Archiver les éléments de preuve web

Les pages hors chaîne fournissent souvent les éléments d’attribution : un site frauduleux qui répertorie des adresses de dépôt, une publication sur un forum proposant des fonds volés, les conditions d’utilisation d’un service. Le Protocole de Berkeley relatif aux enquêtes numériques en sources ouvertes, publié en 2020 par le Haut-Commissariat des Nations Unies aux droits de l’homme et le Centre des droits de l’homme de l’UC Berkeley, expose les méthodes professionnelles de collecte et de préservation de ces contenus. Les méthodes de capture sont abordées dans la leçon OSINT et rapprochement des identifiants sur la chaîne et hors chaîne. L’enregistrement de préservation doit comprendre :

• un fichier d’archive au format WARC (ISO 28500:2017), qui conserve le contenu de la page et les réponses du serveur ;
• une capture d’écran de la page entière, pour la lecture humaine ;
• l’URL, l’heure de capture en UTC, l’outil utilisé et le caractère attribuable ou non de la capture ;
• le hachage SHA-256 de chaque fichier, calculé au moment de la capture ;
• lorsque c’est utile, une copie dans une archive web publique comme corroboration indépendante, jamais comme seule copie.

Pour montrer qu’une capture existait au plus tard à un moment donné, vous pouvez obtenir un horodatage de confiance pour son hachage (le RFC 3161 définit un protocole à cet effet) ou ancrer le hachage dans une transaction sur une blockchain publique. OpenTimestamps est un exemple open source de la deuxième approche.

Le dossier de preuves vérifiable à nouveau

Tous ces éléments sont réunis dans un dossier de preuves : un répertoire qui permet à une personne chargée de la vérification de contrôler chaque fait sans avoir à vous faire confiance.

CF-2026-041_onchain_v1/
  README.txt              procédure de nouvelle vérification, sources, versions des logiciels
  manifest.sha256         une ligne SHA-256 par fichier ci-dessous
  facts.json              enregistrements des faits (F-001 ... F-088)
  raw/                    transactions et blocs bruts issus du nœud
  labels/labels_2026-10-12.json
  tool/trace_graph_export.json
  web/forum_post_capture.warc
  web/forum_post_capture.png

Le manifeste répertorie le hachage de chaque fichier ; le hachage du manifeste lui-même (pour cette version, 4b91…199f) est inscrit dans le journal du dossier et le registre des éléments de preuve, de sorte qu’une seule valeur protège l’ensemble du dossier de preuves. Le README indique comment récupérer chaque transaction depuis n’importe quel nœud, la comparer à raw/ et recalculer les hachages. Ne modifiez jamais un dossier de preuves après sa mise sous scellés : publiez une version 2 avec un nouveau manifeste et consignez la raison de cette nouvelle version. La leçon Hachage, journalisation, chaîne de conservation et gestion de la qualité explique comment le dossier de preuves circule ensuite dans la chaîne de conservation.

Points clés pour l’examen : pourquoi les données brutes finalisées de la chaîne nécessitent rarement une sauvegarde d’urgence, contrairement aux pages d’explorateurs, aux étiquettes, aux résultats d’outils, aux pages web et aux prix ; les champs qui ancrent un fait (chaîne, txid, index de journal, hauteur et hachage du bloc, finalité au moment de la capture, source et version du client, heure UTC, hachage du fichier brut) ; ne pas traiter des données non finalisées comme finalisées, marquer les captures provisoires et les vérifier à nouveau ; finalité du rollup par rapport à celle de la chaîne de base ; vérification croisée auprès d’une source indépendante ; export des instantanés d’étiquettes et des paramètres des outils ; WARC, captures d’écran, hachages et horodatages de confiance pour les éléments de preuve web conformément au Protocole de Berkeley ; le dossier de preuves, son manifeste et le recours à de nouvelles versions plutôt qu’à des modifications.