Bitcoin Core 32.0 arrive le 10 octobre : comment vérifier si votre node sort de la maintenance

Le premier candidat à la publication de Bitcoin Core 32.0 est disponible depuis le 14 septembre 2026. Pour vous, exploitant d'un node personnel, cela signifie deux choses : le périmètre fonctionnel de la prochaine version majeure est arrêté, et sa parution fera sortir la série 29 de la fenêtre de maintenance du projet. Qui tourne encore aujourd'hui en 29.x ne recevra plus de correctifs de sécurité après la date prévue du 10 octobre. La vérification prend deux minutes, la mise à jour coûte une demi-heure selon l'installation.

Un décompte que nous avons réalisé nous-mêmes le matin du 15 septembre, sur les nodes joignables dans le monde entier, montre l'ampleur du groupe concerné : près de six nodes Bitcoin joignables sur dix tournent sur une version qui ne sera plus entretenue une fois 32.0 parue. Les chiffres et la méthode figurent plus bas.

Bitcoin Core 32.0 : ce qui s'est passé le 14 septembre

Bitcoin Core est le logiciel de référence du réseau Bitcoin. Il contrôle les blocs et les transactions au regard des règles de consensus, conserve sa propre copie de la chaîne de blocs et constitue ainsi le socle de quiconque ne confie pas ses paiements à une infrastructure tierce. Selon son propre calendrier, le projet publie une version majeure tous les six mois environ.

Le 14 septembre 2026, l'étiquette v32.0rc1 est apparue dans le dépôt de code du projet, soit le premier candidat à la publication de la prochaine version majeure. Le média sectoriel TFTC indique 12h58 UTC et donne le 10 octobre 2026 comme date prévue de l'étiquette finale. Entre le candidat et la publication s'ouvre donc une fenêtre d'essai d'environ quatre semaines. À titre de comparaison : la dernière version majeure publiée, la 31.0, date du 19 avril 2026 selon le plan de cycle de vie du projet, et la version de maintenance correspondante, la 31.1, porte la date du 7 juillet 2026 dans le répertoire de téléchargement.

Un candidat à la publication n'est pas un essai préalable au sens d'une bêta. Le code est réputé fonctionnellement complet. Ce qui s'y ajoute encore, ce sont exclusivement des correctifs pour les défauts repérés pendant la fenêtre d'essai. Pour vous, exploitant, cela veut dire que le contenu de la prochaine version est connu et que vous pouvez dès à présent confronter votre configuration à celui-ci, plutôt que d'être surpris le jour de la publication.

Candidat, gel des fonctions, fenêtre de maintenance : trois notions pour cet article

Candidat à la publication

Un candidat à la publication est une version que le projet estime prête à paraître et qu'il fait tester largement avant la publication définitive. Elle porte la mention rc1, rc2 et ainsi de suite, et elle est retirée ou remplacée si un défaut grave apparaît.

Gel des fonctions

Le gel des fonctions est le moment à partir duquel plus aucune fonction nouvelle n'est intégrée à une version. Il précède le premier candidat à la publication et explique que le périmètre fonctionnel de la 32.0 puisse déjà être décrit.

Fenêtre de maintenance

La fenêtre de maintenance est la période durant laquelle une version majeure reçoit encore des correctifs de défauts et de sécurité. Selon son propre plan de cycle de vie, Bitcoin Core entretient toujours les trois versions majeures les plus récentes. Dès qu'une nouvelle version majeure paraît, la plus ancienne des trois en sort et passe en fin de vie. Les versions en fin de vie ne reçoivent en règle générale plus de correctifs de sécurité non plus.

Notre décompte : 60 % des nodes joignables perdent leur maintenance avec la 32.0

Cette analyse a été réalisée par cryptoticker.io le 15 septembre 2026. La méthode en une phrase : à 06h35 UTC, nous avons récupéré l'instantané public du compteur de nodes btcnodes.io (anciennement bitnodes.io) et dénombré par version majeure l'identifiant de version que chaque node déclare lui-même.

Nous avons examiné 26 516 nodes issus de cet instantané. Parmi eux, 25 902 portent un identifiant de la forme habituelle avec numéro de version ; les 614 restants annoncent un autre logiciel, dont 556 à eux seuls une implémentation sous forme de bibliothèque sans lien de version avec Bitcoin Core. Le décompte porte sur ces 25 902 nodes.

• 29.x : 8 629 nodes (33,31 %) – précisément la série qui sort de la maintenance avec la parution de la 32.0.
• 28.x et antérieures : 7 017 nodes (27,09 %) – déjà sans maintenance aujourd'hui. La série 28 est en fin de vie depuis le 19 avril 2026.
• 30.x : 1 732 nodes (6,69 %) et 31.x : 8 512 nodes (32,86 %) – les deux séries qui resteront entretenues aux côtés de la 32.x après la publication.
• 32.x : 12 nodes (0,05 %) – vraisemblablement des systèmes d'essai faisant déjà tourner le candidat.

En additionnant la série 29 et tout ce qui est plus ancien, on obtient 15 646 nodes, soit 60,40 %. Cette majorité se retrouvera sans logiciel entretenu au lendemain de la publication. Constat annexe du même décompte : 4 459 nodes (17,2 %) annoncent en outre l'identifiant de l'implémentation divergente Bitcoin Knots, qui suit son propre rythme de publication et n'est pas concernée par ce plan de maintenance.

Ce que cette enquête ne peut pas faire en fait également partie. L'instantané ne comporte aucun champ de pays ; il est donc impossible d'en déduire un chiffre distinct par pays. L'identifiant de version est une déclaration sur l'honneur, techniquement falsifiable. Et seuls sont comptés les nodes joignables depuis l'extérieur. Qui exploite son node derrière un pare-feu ou le rend joignable uniquement par Tor n'apparaît pas dans ces statistiques. Le nombre réel d'installations obsolètes est donc probablement plus élevé que celui indiqué ici.

Fenêtre de maintenance de Bitcoin Core : quelle version sort et quand

Le plan de cycle de vie du projet est un tableau public, qui se lit ligne par ligne. Les entrées importantes pour vous :

• 29.x, parue le 14 avril 2025 : fin de vie à la parution de la 32.0, soit, en l'état actuel, le 10 octobre 2026.
• 30.x, parue le 10 octobre 2025 : fin de vie seulement avec la 33.0.
• 31.x, parue le 19 avril 2026 : fin de vie seulement avec la 34.0.
• 28.x : en fin de vie depuis le 19 avril 2026.

Le projet recommande expressément de faire tourner la version de maintenance la plus récente de la version majeure la plus élevée vers laquelle on peut basculer. Une particularité plaide ici pour un chemin de mise à niveau serein : le projet livre les propositions de modification des règles de consensus d'abord dans les versions de maintenance, et non dans les versions majeures. Qui actualise de façon conservatrice reste malgré tout compatible, tant que sa propre version majeure est entretenue. C'est exactement cette compatibilité qui s'achève en octobre pour la série 29.

Lire la version de Core : comment savoir ce que fait tourner votre node

Avant de télécharger quoi que ce soit, établissez où vous en êtes. Trois voies, selon l'installation.

Ligne de commande

Sur un serveur ou un ordinateur monocarte, bitcoind --version donne le numéro de version directement en première ligne. Avec le service en fonctionnement, cela passe aussi par bitcoin-cli --version ou, si vous dialoguez déjà avec le node, par l'appel bitcoin-cli getnetworkinfo ; l'identifiant s'y trouve dans le champ subversion, sous la forme même qu'a utilisée notre décompte ci-dessus.

Interface graphique

Dans l'application de bureau, le numéro de version se trouve via l'entrée de menu Aide, dans la fenêtre des informations relatives à l'application. Il figure également dans la fenêtre des informations de débogage, que l'application propose sous l'entrée de menu Fenêtre.

Ensemble de node préconfiguré

Qui exploite une solution clés en main, c'est-à-dire un système d'exploitation préconfiguré pour un node domestique, lit en règle générale la version de Core dans la vue détaillée de l'application concernée. Ce qui compte ici, c'est la version de Bitcoin Core lui-même, et non le numéro de version de l'interface qui l'entoure. Les deux chiffres diffèrent presque toujours, et seul le premier décide de la maintenance.

Notez ce chiffre. S'il indique 29 ou moins, vous avez une tâche pour les prochaines semaines. S'il indique 30 ou 31, vous êtes pour l'instant du bon côté et pouvez planifier la mise à jour tranquillement.

Ce qui change dans Bitcoin Core 32.0 : estimation des frais, index, interface

Le projet de notes de version de la 32.0 se trouve dans le wiki de développement du projet. Il s'agit expressément d'un projet, susceptible d'évoluer jusqu'à l'étiquette finale ; les points suivants sont donc à lire comme une orientation et non comme une formulation définitive.

L'accent mis sur l'exploitation plutôt que sur des fonctions visibles saute aux yeux. L'estimation des frais combinera désormais l'estimateur fondé sur les blocs et celui issu du mempool, et s'avère de ce fait plus prudente. Selon le projet de notes, l'index des transactions occupe moins de la moitié de l'espace disque antérieur, mais seulement après une reconstruction de l'index. La validation des blocs gagne une préextraction parallèle des données d'entrée, avec un réglage propre pour le nombre de fils de travail, fixé par défaut à huit et plafonné à seize.

Au niveau de la couche réseau, le projet prévoit une limitation globale, et non plus par connexion, du relais des transactions, ainsi qu'une protection par preuve pour les services Tor, là où la partie adverse la prend en charge. Le chiffrement obsolète du réseau I2P arrive en fin de course ; qui exploite son node par ce biais devrait planifier le changement avant la version 34. L'interface reçoit de nouveaux appels pour la gestion des clés et pour l'export d'un portefeuille en lecture seule, et le serveur HTTP intégré a été réécrit, avec un nouveau plafond de connexions simultanées.

Rien de tout cela ne vous oblige à agir le jour de la publication. Deux points méritent tout de même d'être notés : la reconstruction de l'index, si l'espace disque vient à manquer, et les réglages supprimés, dont traite la section suivante.

Options supprimées dans bitcoin.conf : pourquoi votre node avertit après la mise à jour

Les ennuis les plus fréquents après un saut de version majeure ne viennent pas du programme, mais du fichier de configuration personnel. Selon le projet de notes, plusieurs réglages présents pendant des années dans les tutoriels disparaissent dans la 32.0. Parmi eux, un réglage relatif à la remplaçabilité complète des transactions dans le mempool et une ancienne option réseau. Deux clés disparaissent en outre des réponses des appels au mempool, sauf si vous les réactivez expressément via le réglage destiné aux interfaces obsolètes.

Concrètement : ouvrez votre bitcoin.conf avant d'actualiser et confrontez chaque ligne aux notes de version. Un node qui ne démarre pas à cause d'un réglage inconnu, ou qui se lance avec des avertissements, c'est une nuit blanche inutile. Qui a raccordé ses propres scripts ou un logiciel de comptabilité à l'interface vérifiera en plus si l'une des clés supprimées y est lue.

Tester le candidat sans mettre en péril le node de production

Quatre semaines de fenêtre d'essai, c'est une invitation, et elle vaut aussi pour les exploitants sans bagage de développeur. Plus les installations qui font tourner le candidat sont variées, plus les défauts apparaissent avant d'atterrir dans la version publiée. Trois règles rendent l'essai inoffensif.

Premièrement, un candidat à la publication n'a pas sa place sur le node auquel votre portefeuille est raccordé. Un appareil séparé, une machine virtuelle ou un fonctionnement d'essai sur le réseau de test suffisent amplement. Deuxièmement, vous vérifiez avant le démarrage la signature des fichiers téléchargés au regard des sommes de contrôle publiées ; c'est aussi obligatoire pour une version préalable que pour une publication ordinaire. Troisièmement, vous signalez tout comportement anormal tant que la fenêtre est ouverte. Après l'étiquette finale, le chemin des correctifs est nettement plus long.

Qui veut être tranquille réalise avant chaque saut de version une sauvegarde du fichier de portefeuille et du fichier de configuration, et la conserve séparément du node. Cela vaut pour le candidat comme pour la publication ultérieure. La rigueur de cette même discipline sur les appareils matériels s'est vérifiée cette année dans le cas d'un fabricant dont le défaut de micrologiciel a touché toute une génération d'appareils.

Pas de node personnel ? Ce que cette mise à jour dit de votre conservation

La plus grande partie du lectorat n'exploite pas de node personnel, et c'est une décision légitime. Cette publication a malgré tout quelque chose à vous dire. Qui laisse ses avoirs chez une plateforme d'échange ou un courtier compte sur le fait que quelqu'un, là-bas, surveille cette fenêtre de maintenance. Qui conserve lui-même mais accède à un serveur tiers via une application de portefeuille compte sur ce même tiers inconnu, simplement un cran plus bas.

La voie médiane pratique, pour la plupart, consiste à séparer les clés du logiciel : les clés reposent sur un appareil qui n'est jamais relié au réseau, le logiciel reste interchangeable. Quels appareils entrent en ligne de compte et en quoi ils diffèrent, c'est dans notre comparatif des portefeuilles matériels. Le node personnel arrive ensuite comme deuxième étape, et la question de version traitée ici devient alors la vôtre.

Que la maintenance ne soit pas un sujet secondaire, deux cas des dernières semaines le montrent : une faille dans une implémentation Lightning et une brèche critique dans une interface de portefeuille répandue, où seule l'accessibilité depuis internet déterminait le risque. Dans les deux cas, le remède était une mise à jour déjà disponible.

Ce que cette publication n'est pas : ni changement de consensus ni événement de marché

Une mise au point contre les conclusions hâtives. Selon le projet de notes disponible, Bitcoin Core 32.0 ne modifie aucune règle de consensus. Il n'y a ni vote, ni délai de signalisation, ni moment où un node non actualisé sortirait du réseau. Un node en version 29 continuera de valider correctement après le 10 octobre. Ce qui lui manquera, ce sont les correctifs des défauts découverts par la suite.

Une publication n'est pas davantage un événement de marché. Qui établit un lien entre numéros de version et mouvements de cours affirme quelque chose d'indémontrable. La portée de cette échéance tient uniquement à l'exploitation : à la question de savoir si le logiciel qui contrôle vos paiements est encore entretenu.

Reste la question du bon moment. Un passage à la 32.0 le jour de la publication n'est pas une erreur pour un node privé, mais ce n'est pas non plus une obligation. Qui tourne en 30.x ou 31.x dispose de plusieurs mois. Qui est en 29.x ou en dessous devrait planifier le changement en octobre, et précisément vers la version de maintenance la plus récente de la version majeure la plus élevée que permet son installation. Pour les installations où un node complet exige trop d'espace disque, le mode élagué reste une option ; le node y accomplit son travail de validation à l'identique.

Vérifier Bitcoin Core 32 : ce qu'il faut en retenir

1. Relever la version et la noter. Via bitcoind --version, via la fenêtre d'informations de l'application de bureau ou dans la vue détaillée de votre solution clés en main. Si elle indique 29 ou moins, fixez-vous une échéance en octobre. Qui ne conserve pas encore lui-même tranchera d'abord la question des clés et consultera pour cela le comparatif des portefeuilles matériels.
2. Préparer le fichier de configuration et la sauvegarde. Confronter chaque ligne de votre bitcoin.conf aux notes de version, sauvegarder séparément le fichier de portefeuille et la configuration. Qui garde ses clés dans une application sur son ordinateur vérifiera en parallèle son état de mise à jour grâce à notre comparatif des portefeuilles logiciels.
3. Tester sur un appareil séparé, puis basculer sans hâte. Ne jamais faire tourner le candidat sur le node auquel votre portefeuille est raccordé. Et si vous constatez que vous ne voulez pas exploiter de node personnel du tout, alors le choix du prestataire conservateur est la décision qui compte ici, et le comparatif des plateformes mérite alors un coup d'œil.

Les sources de cet article : le plan de cycle de vie de Bitcoin Core avec son tableau de maintenance et la liste des étiquettes du dépôt de code, où figure le candidat v32.0rc1 avec sa date.

(Au 15 septembre 2026. Cet article ne constitue pas un conseil en investissement. Les cours et les grilles tarifaires évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)