Testnet possède son historique de blocs et ses soldes, distincts du réseau principal, appelé mainnet. Les pièces de test, souvent notées TBTC, sont destinées à des expériences sans valeur financière. Une interface similaire n’implique pas la même fiabilité, les mêmes frais ni la même sécurité qu’avec de vrais BTC.
Anna veut apprendre à recevoir et envoyer des bitcoins avant d’utiliser son argent. Dans une application compatible avec Testnet, elle crée un portefeuille de test séparé. Un faucet, service distribuant de petites quantités de pièces de test, lui fournit des fonds ; elle en envoie une partie à Pavel sur le même réseau. Elle découvre une adresse, une transaction et l’attente d’une confirmation sans dépenser de vrais BTC. C’est un exemple, pas un mode d’emploi pour une application précise : tous les portefeuilles ne proposent pas ce mode. Les pièces de test ne sont pas des bitcoins gratuits. Leur solde ne peut être basculé ni transféré sur mainnet, et l’indisponibilité d’un faucet ne justifie pas de les acheter comme placement. [11]
Testnet n’est pas un compte d’entraînement à l’intérieur du réseau principal de Bitcoin. C’est une autre chaîne de blocs, qui commence par son propre Genesis Block. Un bloc regroupe des transactions dans l’historique commun ; le Genesis Block en est le point de départ. Ce réseau possède aussi ses UTXO, les sorties de transactions qui n’ont pas encore été dépensées. Une sortie indique un montant et les conditions pour le dépenser, par exemple une signature requise. Recevoir des fonds sur un réseau ne crée donc aucun solde sur l’autre. Les logiciels distinguent les réseaux par leurs paramètres, notamment les identifiants de début des messages et les ports. Pourtant, des réseaux différents n’ont pas forcément des adresses visiblement différentes. Une clé privée est une donnée secrète permettant au portefeuille de créer une signature qui autorise la dépense des fonds correspondants. Même des clés privées identiques ne fusionnent pas les deux historiques en un portefeuille au solde commun. [12] [15]
Une adresse commençant par tb1 peut appartenir à Testnet3, Testnet4 ou Signet. Anna et Pavel conviennent donc du réseau exact et le vérifient dans les deux applications ; dire « réseau de test » ne suffit pas. Anna emploie de nouvelles clés et une sauvegarde séparée. Elle ne saisit jamais la Seed Phrase (les mots de récupération) d’un portefeuille contenant de vrais fonds dans une application d’essai. Changer de mode ne rend pas sûr un logiciel douteux. Un faucet n’a besoin, au plus, que d’une adresse publique de réception, jamais des mots de récupération ni d’une clé privée. Séparer fichiers de portefeuille, clés et sauvegardes limite les confusions et les rapprochements indésirables entre essais et paiements personnels. [12] [14]
Le Testnet public sert aux expériences avec des participants inconnus et un minage ouvert. Signet est également un environnement de test, mais exige, en plus de Proof of Work (le travail de calcul nécessaire pour trouver un bloc valide), le respect d’une condition de bloc, généralement une signature créée avec des clés autorisées. La production des blocs peut ainsi être mieux coordonnée, sans garantie de fonctionnement continu. Regtest convient au développeur qui doit maîtriser son expérience : il exploite son environnement et crée les blocs à la demande, par exemple pour un test automatisé. Si Anna apprend seulement à manier son portefeuille, les réseaux pris en charge par l’application comptent aussi. Aucun de ces réseaux ne convertit ses pièces en bitcoins du réseau principal. [10] [11] [16]
Le paiement d’essai de Pavel peut passer rapidement avec peu de frais. Cela ne permet pas de prévoir le coût du même parcours sur mainnet. L’activité, la puissance de minage et les motivations des participants diffèrent. Un Testnet public peut attendre longtemps un bloc, subir une panne de service ou une réorganisation : les nœuds, des ordinateurs qui vérifient les règles du réseau, remplacent alors une branche récente de l’historique par une autre branche valide. Ces situations révèlent des défauts dans les applications, mais toute panne n’est pas intentionnelle. Un essai réussi a vérifié un comportement donné dans des conditions données ; il ne prouve à lui seul ni la sécurité des clés ni la robustesse d’un service utilisant de l’argent réel. [10] [2]
Les anciens guides parlent de Testnet3, lancé en 2011. Au fil des années, des problèmes de distribution des pièces et de règles de difficulté sont apparus. Les block storms étaient des rafales de blocs minés très vite : la hauteur de la chaîne progressait anormalement et la subvention des nouveaux blocs diminuait plus vite que ne le suggérait le calendrier. Des pièces de test ont même été échangées contre de l’argent, alors qu’elles devaient rester un outil accessible. Une nouvelle génération repart donc avec un nouvel historique ; elle ne réévalue pas les anciens soldes. Dans un guide, vérifiez le numéro du réseau, pas seulement le nom Testnet. [1]
La proposition technique BIP 94 décrit Testnet4, pris en charge à partir de Bitcoin Core 28.0. Outre un nouveau Genesis Block, il modifie le calcul de difficulté et les règles d’horodatage afin de limiter des causes connues de block storms. Il conserve toutefois une exception : sauf pour le premier bloc d’une période de difficulté, un horodatage dépassant de plus de 20 minutes celui du bloc précédent impose la difficulté minimale. Cela ne promet pas une confirmation de paiement sous 20 minutes. Testnet4 applique aussi dès le départ les changements de règles actifs sur mainnet lors de sa proposition en mai 2024. Ces améliorations n’en font pas une reproduction sans faille du réseau principal. [1] [9]
Au 17 octobre 2026, BIP 95 pour Testnet5 porte le statut Draft, c’est-à-dire un projet en cours. Il propose de supprimer l’exception de difficulté minimale, de relever ce minimum et d’appliquer dès le premier bloc BIP 54, un ensemble de modifications proposées des règles de consensus. Les données définitives du Genesis Block et le lien vers une implémentation de référence manquent encore. Ce texte ne permet donc pas de présenter Testnet5 comme un réseau Bitcoin Core couramment déployé. Tester de nouvelles règles ne les active pas non plus sur mainnet. Lors d’une lecture ultérieure, il faut vérifier le statut de la proposition et la documentation de sa version du logiciel, sans se fier au numéro plus élevé. [2]
Dans Bitcoin Core, l’option testnet4 sélectionne Testnet4 ; la documentation de votre version donne la syntaxe exacte. Dans le fichier de configuration, [test] désigne Testnet3 et [testnet4] désigne Testnet4. Les données occupent des sous-dossiers séparés : testnet3, testnet4, signet ou regtest. Vérifiez aussi le logiciel en cours d’exécution : getblockchaininfo indique le réseau dans son champ chain. Contrôlez également l’empreinte du Genesis Block, la synchronisation et les nœuds connectés. Pour un Signet personnalisé, le genesis commun ne suffit pas ; sa condition de bloc particulière doit aussi être vérifiée. Un titre de fenêtre ou une adresse ressemblante ne remplace pas ces contrôles. [8] [12] [13] [14] [10]
Anna vérifie d’abord que les deux portefeuilles utilisent le même réseau. Elle essaie ensuite réception et envoi, puis distingue paiement envoyé et paiement confirmé. Elle ne teste la restauration qu’avec une sauvegarde d’essai séparée. Un développeur peut ajouter le redémarrage de l’application, un nœud indisponible, une réorganisation ou le rejet d’un mauvais réseau. Pour les frais, il peut tester RBF, le remplacement d’une transaction non confirmée, et CPFP : une transaction fille mieux rémunérée incite les mineurs à inclure aussi sa transaction parente non confirmée. Le résultat doit préciser réseau, version du logiciel et comportement effectivement vérifié. Testnet permet de faire les erreurs qu’on souhaite éviter avec de l’argent réel ; il ne dispense pas des contrôles suivants. [11] [9]
Pour une vision complète, lisez aussi Bitcoin Core, Signet, Minage, Portefeuille, Bitcoin, Full Node. Cette entrée est également citée par Sidechain, Liquid Network, Éducation à Bitcoin, Signet.