Qu`est-ce qu`un soft fork ? Explication de la rétrocompatibilité de Bitcoin

Bloc 481 824. C'est à ce moment-là que SegWit, la première mise à jour majeure de Bitcoin, a été intégrée au protocole le 24 août 2017. Ce nombre est important car une mise à jour logicielle permet à une blockchain comme Bitcoin de se moderniser sans scinder le réseau. De nouvelles règles sont déployées, tandis que l'ancien système continue de fonctionner. Les deux restent sur la même chaîne.

Demandez à la plupart des gens ce qu'est un soft fork et vous obtiendrez une réponse laconique : une modification rétrocompatible d'un protocole blockchain. Techniquement exact. Peu utile. La réalité est plus complexe et plus intéressante. Un soft fork est le fruit d'un long processus : les développeurs proposent des modifications de règles, les mineurs manifestent leur soutien ou leur refus discret, les opérateurs de nœuds choisissent le logiciel à exécuter et les utilisateurs, en coulisses, insistent sur ce qui est considéré comme du Bitcoin. Cet article explique ces mécanismes en termes simples. Il présente ensuite les exemples classiques (SegWit et Taproot) bloc par bloc. Et il se termine par le débat actuel sur la prochaine modification à apporter.

Définition de Soft Fork : une mise à niveau de la blockchain rétrocompatible

Imaginez une mise à jour logicielle (soft fork) comme un renforcement des règles. Tout ce qui est légal selon les nouvelles règles le reste selon les anciennes. Ainsi, les anciens nœuds continuent d'accepter les nouveaux blocs sans problème. Les nouveaux nœuds rejettent les blocs de l'ancien format qui enfreignent les règles plus strictes, mais les règles elles-mêmes sont plus strictes, pas différentes. L'esprit du réseau reste le même. Seule la définition de ce qui est valide est différente.

Un bon exemple : le BIP 16 de Bitcoin, le soft fork Pay-to-Script-Hash (P2SH). Il a été activé le 1er avril 2012, au bloc 173 805. Avant le BIP 16, le type de transaction P2SH n'existait pas dans le code de Bitcoin. Après son déploiement, les nœuds mis à jour ont imposé le P2SH. Les anciens nœuds, voyant dans les mêmes résultats un code étrange que n'importe qui pouvait utiliser, ont haussé les épaules et accepté les blocs sans broncher. Ils ignoraient l'existence de cette règle à enfreindre. La chaîne est restée unifiée, car la nouvelle règle était un sous-ensemble de l'ancienne. Ainsi, Bitcoin a discrètement acquis une nouvelle fonctionnalité.

Voilà donc le secret de cette stratégie. Les anciens logiciels acceptent un ensemble de fonctionnalités plus vaste que celui des nouveaux logiciels. Pas de scission de la chaîne. Pas de période de réclamation. Pas de nouvelle cryptomonnaie. Le réseau blockchain continue de produire une seule et même chaîne, acceptée par tous, quelle que soit la version du logiciel utilisée. C'est une manipulation sociale d'une élégance surprenante, dissimulée sous l'apparence d'un simple changement de logiciel.

Cette propriété constitue également la limite entre un soft fork et toute modification incompatible avec l'ancienne version du logiciel. Si une mise à jour peut soudainement invalider un bloc auparavant valide aux yeux de l'ancienne version, il ne s'agit pas d'un soft fork, mais d'un hard fork. Les compromis sont alors complètement différents. En termes de technologie blockchain, la divergence entre ces deux types de forks se résume à une question pratique : les nœuds qui n'effectuent pas la mise à jour acceptent-ils toujours les nouveaux blocs comme valides ?

Fourche souple vs fourche rigide : la vraie différence

Une bifurcation dure (hard fork) fonctionne à l'inverse. Elle assouplit les règles, ou les modifie de telle sorte que l'ancien logiciel les rejette catégoriquement. Les anciens nœuds examinent un nouveau bloc, le jugent invalide et refusent de le suivre. Soit tout le monde met à jour son système, soit le réseau se divise. Ce sont les deux seules options.

Deux cas reviennent fréquemment. Le fork DAO d'Ethereum, le 20 juillet 2016, au bloc 1 920 000, a déplacé environ 12 millions d'ETH provenant de deux contrats compromis. Les anciens nœuds ont refusé ce changement, ont continué à faire fonctionner la chaîne originale, et Ethereum Classic est né de ce refus. Bitcoin Cash a suivi un an plus tard. Le 1er août 2017, au bloc 478 559, Bitcoin Cash a augmenté la taille maximale des blocs de 1 Mo à 8 Mo. Les anciens nœuds Bitcoin ont immédiatement rejeté ces blocs plus volumineux. Dès lors, Bitcoin Cash est devenu une cryptomonnaie distincte sur une nouvelle blockchain.

Une bifurcation douce évite tout ce désordre par conception même. Les anciens nœuds ne sont pas sollicités. Ils continuent de valider les blocs selon leurs règles moins restrictives. Lorsqu'une nette majorité de mineurs applique les nouvelles règles, chaque bloc miné est valide simultanément selon les deux ensembles de règles. Une seule chaîne économique. Un seul registre. Cette asymétrie est la raison structurelle pour laquelle la culture Bitcoin privilégie les bifurcations douces et considère les bifurcations dures comme une solution de dernier recours.

Comment une bifurcation logicielle (soft fork) s'active-t-elle réellement sur Bitcoin ?

La plupart des explications s'arrêtent là. Elles vous diront qu'une mise à jour logicielle « renforce les règles » et passent à autre chose. Ce que personne ne semble vouloir aborder, c'est comment ce renforcement se met concrètement en œuvre. Une mise à jour logicielle n'est pas un simple interrupteur actionné par un développeur. C'est un processus lent, parfois complexe, de coordination. Et cette coordination est intrinsèquement liée à la conception même de Bitcoin.

La méthode d'activation classique repose sur la signalisation des mineurs. Une proposition de soft fork devient une BIP (Bitcoin Improvement Proposal) et se voit attribuer un bit dans le champ de version de l'en-tête du bloc. Les mineurs utilisant une version logicielle mise à jour activent ce bit. La puissance de minage de ces blocs sert de signal au reste du réseau pour évaluer la disponibilité du fork. Dès que le pourcentage de blocs signalant le fork atteint un certain seuil dans un intervalle de temps défini, le fork est activé. Le modèle utilisé jusqu'en 2017 était la BIP 9 : 95 % sur une fenêtre glissante de 2016 blocs. La BIP 8 est apparue plus tard. Elle a introduit une date limite stricte afin qu'une proposition bloquée ne puisse pas stagner indéfiniment.

Ce modèle a fonctionné jusqu'à un certain point. Début 2017, SegWit s'est retrouvé bloqué à un taux de soutien des mineurs compris entre 30 et 45 %, et ce pendant des mois. Les gros mineurs avaient des raisons de ne pas signaler leur présence, et aucune n'était flatteuse. La communauté a dû trouver une solution de contournement. Le BIP 91 a abaissé le seuil effectif et a été déployé rapidement. Parallèlement, un mouvement parallèle, le soft fork activé par les utilisateurs, plus précisément le BIP 148, a fixé le 1er août 2017 comme date butoir. Après cette date, les nœuds BIP 148 commenceraient à rejeter tout bloc ne signalant pas SegWit. La combinaison du BIP 91 d'une part et de la pression politique de l'UASF d'autre part a permis de débloquer la situation. La plupart des gens n'avaient jamais rien vu de tel. Nombreux sont ceux qui débattent encore pour savoir quelle initiative a réellement permis de débloquer la situation.

Pour Taproot, la communauté a opté pour une solution plus simple : l’essai rapide. Un seuil de signalisation de 90 % est requis sur une période de 90 jours. Si ce seuil est atteint, la branche est activée. Dans le cas contraire, la proposition expire sans problème et peut être retentée. Taproot a franchi ce seuil sans difficulté et a été activé le 14 novembre 2021, au bloc 709 632.

Modèles d'activation de fourche souple

Soft Forks de Bitcoin : études de cas SegWit et Taproot

SegWit, abréviation de Segregated Witness, est la mise à jour logicielle la plus souvent citée dans l'histoire de Bitcoin. Elle a permis d'extraire les signatures de transaction, les « données de témoin », du corps principal de la transaction et de les stocker séparément. Les anciens nœuds ont interprété ces nouvelles données comme des scripts utilisables par tous et ont accepté les blocs les contenant. Les nouveaux nœuds ont ensuite appliqué correctement les règles relatives aux témoins. L'astuce résidait dans le fait qu'une modification subtile de la structure sous-jacente des transactions a permis d'obtenir un gain de capacité effectif. La limite stricte de 1 Mo pour la taille des blocs Bitcoin a été remplacée par une limite de 4 millions d'unités de poids. En pratique, un bloc typique contient désormais environ 1,8 Mo de données. La capacité maximale théorique se situe aux alentours de 2,4 Mo.

SegWit a été activé au bloc 481 824 le 24 août 2017 à 01:57:37 UTC. Les huit mois qui ont précédé ce bloc font désormais partie de l'histoire de la gouvernance de Bitcoin. Le support des mineurs était bloqué pendant la majeure partie de l'année 2017. Le déblocage a finalement été rendu possible par le BIP 91, la menace UASF et l'accord dit SegWit2x. Je reviens sans cesse sur cette période car elle constitue l'étude de cas de référence pour chaque activation ultérieure.

Taproot est la deuxième mise à jour logicielle la plus citée, et probablement l'activation la plus réussie de Bitcoin depuis SegWit. Elle a été activée quatre ans après SegWit, le 14 novembre 2021, au bloc 709 632. Le franchissement du seuil de 90 % pour le Speedy Trial s'est déroulé sans incident majeur. Taproot a introduit trois nouveautés : les signatures Schnorr, les arbres MAST et un type de sortie unifié pour les dépenses à signature unique, à signatures multiples et par chemin de script. Ces changements ont également préparé le terrain pour que des solutions comme le Lightning Network gagnent en efficacité au fil du temps.

L'histoire de Taproot mérite d'être racontée. Son adoption a progressé régulièrement tout au long de 2023, atteignant un pic d'environ 42 % des transactions Bitcoin début 2024, portée par l'essor des inscriptions Ordinals. Mi-2025, elle était retombée à environ 20 %, le nombre d'inscriptions ayant diminué. Un débat s'est ouvert quant à la vulnérabilité du système de signature de Taproot face à de futures attaques informatiques quantiques. Rien de tout cela n'a empêché son activation. Cependant, la courbe d'utilisation nous rappelle qu'une mise à jour logicielle réussie du protocole ne se traduit pas automatiquement par une adoption massive par les portefeuilles ou les utilisateurs.

Lignée des soft forks de Bitcoin

Débat sur les Soft Forks 2025-2026 : OP_CTV et OP_CAT

Le premier débat sérieux sur une bifurcation logicielle de Bitcoin depuis Taproot a lieu en ce moment même. La discussion porte principalement sur le degré d'expressivité que devrait avoir le script de Bitcoin. Deux propositions dominent le débat, mais aucune ne l'emporte pour l'instant.

L'OP_CHECKTEMPLATEVERIFY, formalisé sous la référence BIP 119, ajouterait un opcode de script permettant à une transaction de s'engager sur un modèle de dépenses futures spécifique. L'OP_CAT, formalisé sous la référence BIP 347 après avoir finalement reçu un numéro BIP en avril 2024, réactiverait la concaténation d'éléments de script. Cette fonctionnalité avait été supprimée par Satoshi Nakamoto en 2010 en raison de risques de déni de service. Ces deux opcodes sont des primitives de passerelle pour ce que les développeurs Bitcoin appellent les « covenants ». Les covenants sont des scripts qui restreignent les destinations des pièces pouvant être envoyées. Ils permettent d'accéder aux coffres-forts, au traitement par lots pour la gestion de la congestion et à l'amélioration du débit du réseau sur les couches construites au-dessus de la blockchain Bitcoin.

Avec la proposition 2026, les paramètres d'activation d'OP_CTV sont officiellement examinés pour la première fois depuis 2022. Le seuil proposé est de 90 % de signalement des mineurs. OP_CAT est testé sur Signet, le réseau de test pour développeurs. Aucun des deux ne fait l'objet d'un consensus communautaire. Le compromis auquel la communauté est confrontée est bien réel. Une plus grande expressivité ouvre de nouveaux cas d'utilisation. Elle augmente également la surface d'attaque de Bitcoin. Tout nouvel opcode est permanent. Je ne suis pas convaincu que l'un ou l'autre soit adopté lors de la proposition 2026, mais ce débat est le signe le plus clair à ce jour que la gouvernance de Bitcoin peut encore envisager des soft forks.

Ce que signifie une fourchette souple pour les portefeuilles et les étuis

Pour les détenteurs de bitcoins, la question pratique est de savoir si un soft fork nécessite une action. La réponse est presque toujours non. Rien à faire, rien à réclamer, rien à migrer. Un soft fork ne crée pas de nouvel actif numérique. Les portefeuilles existants continuent d'envoyer et de recevoir des bitcoins selon les anciennes règles, sans aucune intervention de l'utilisateur.

L'exception concerne les soft forks qui introduisent un nouveau format d'adresse. SegWit a ajouté le préfixe d'adresse bc1. Les portefeuilles ont dû prendre en charge ce nouveau format pour permettre aux utilisateurs d'envoyer et de recevoir des cryptomonnaies depuis ou vers des adresses SegWit, et pour bénéficier des économies de frais offertes par la nouvelle structure de transaction. Les utilisateurs d'anciens portefeuilles pouvaient toujours envoyer et recevoir des cryptomonnaies sur les anciennes adresses sans problème. La mise à jour vers la nouvelle version était facultative. Taproot a procédé de la même manière avec les adresses bc1p. C'est précisément cette possibilité d'adoption volontaire qui est essentielle. Un soft fork est moins perturbateur qu'un hard fork car son adoption est progressive et volontaire.

Pour les opérateurs de nœuds, la situation est légèrement différente. Après une mise à jour logicielle (soft fork), l'exécution d'un nœud d'ancienne version signifie que vous n'êtes plus responsable de l'application des nouvelles règles. Vous vous fiez alors aux mineurs et aux autres nœuds ayant mis à jour leur système. Les nœuds qui ne sont pas mis à jour peuvent toujours valider les blocs selon l'ancien protocole logiciel. Ils ne peuvent simplement pas valider les nouvelles contraintes introduites par la mise à jour. La plupart des opérateurs effectuent néanmoins la mise à jour rapidement. C'est l'une des raisons pour lesquelles l'écosystème complet de nœuds de Bitcoin est si important.

Pourquoi les soft forks sont supérieurs aux hard forks pour la santé du réseau

L'argument en faveur des soft forks comme voie de mise à niveau par défaut repose sur la résilience du réseau, et le calcul est sans appel. Bitcoin exploite environ 22 992 nœuds complets accessibles dans le monde, selon un instantané Bitnodes du 27 avril 2026. À cela s'ajoute un nombre inconnu de nœuds protégés par des pare-feu. Un hard fork qui entraîne la perte de 10 % de ces nœuds, par inertie ou en raison de désaccords, provoque, par définition, une scission de la chaîne. Deux cryptomonnaies. Deux registres. Deux marchés. Deux communautés.

Une mise à jour logicielle (soft fork) qui entraîne la perte de 10 % des mineurs en raison de leur non-signalisation se traduit par un léger ralentissement de la confirmation, tandis que la majorité (90 %) applique les nouvelles règles. La chaîne économique reste ainsi unifiée. C'est cette asymétrie qui explique la préférence de Bitcoin pour la rétrocompatibilité. Une mise à jour logicielle réussie récompense la coordination sans pénaliser les mineurs lents. Une mise à jour logicielle ratée n'est tout simplement pas activée et peut être retentée au cycle suivant. Une mise à jour matérielle ratée crée une nouvelle blockchain, avec une nouvelle identité visuelle et un poids politique permanent non souhaité.

C’est pourquoi, depuis 2012, toutes les mises à jour majeures de la blockchain Bitcoin, à l’exception de la bifurcation controversée d’août 2017 qui a donné naissance à Bitcoin Cash, ont été des bifurcations douces. La majorité des mineurs a systématiquement privilégié les modifications rétrocompatibles plutôt que les divergences. Ce choix n’est pas le fruit du hasard.

Risques et modes de défaillance des fourches souples

Les soft forks sont plus sûrs que les hard forks, mais ils ne sont pas sans risque. Le BIP 66 de juillet 2015 a provoqué une scission accidentelle de six blocs lorsque certains mineurs ont manifesté leur soutien aux nouvelles règles sans les valider. Un cas de défaillance classique : les nœuds mis à jour rejettent les blocs que les mineurs non mis à jour continuent de produire. Deux chaînes concurrentes coexistent brièvement, et la sécurité du réseau est compromise pendant quelques heures. La scission s'est résorbée d'elle-même une fois la majorité des mineurs au courant. Mais pendant plusieurs heures, Bitcoin a fonctionné simultanément avec deux chaînes concurrentes. La période d'activation de deux ans de SegWit a également engendré des dommages politiques persistants, notamment la création de Bitcoin Cash. Enfin, une UASF (Uniform Arbitration Fork) sans majorité claire de mineurs comporte un risque réel de scission permanente. La rétrocompatibilité est une contrainte importante, et non une garantie de succès.

Simon Chartan

A journalist with a strong technical background and a passion for decentralized finance. With degrees in MBA and Master of Engineering in Data Science, the author combines analytical expertise with a clear, engaging writing style. At Plisio, they cover topics such as cryptocurrency, blockchain, DeFi, and digital finance—helping readers make sense of a rapidly evolving fintech landscape.