Si vous avez ouvert un portefeuille Bitcoin et qu'on vous a demandé de choisir entre une adresse « Legacy », « SegWit » ou « Native SegWit » sans vous expliquer ce que cela signifiait, ce choix remonte à une seule mise à jour effectuée en 2017.
SegWit, abréviation de « Segregated Witness », est une mise à jour du protocole Bitcoin activée en août 2017 qui consiste à déplacer les données de signature numérique hors de la structure principale de la transaction pour les placer dans un champ distinct appelé « witness ». Ce simple changement architectural a permis de réduire les frais de transaction, de corriger une faille de sécurité vieille de plusieurs années appelée « malléabilité des transactions » et de créer les conditions techniques nécessaires à l'existence du Lightning Network et de Taproot.
Cet article explique en quoi consiste réellement SegWit, comment fonctionne le système de poids des blocs, l'impact des différents types d'adresses sur vos frais de transaction, ainsi que la bataille politique controversée qui a failli déchirer le réseau Bitcoin avant même sa mise en œuvre.
Gérez vos bitcoins avec le Application Bitcoin.com Wallet.
Points clés à retenir
- SegWit (Segregated Witness) est une mise à jour du protocole Bitcoin activée le 24 août 2017, officiellement désignée sous le nom de BIP 141 et proposée par Pieter Wuille, Eric Lombrozo et Johnson Lau en décembre 2015.
- Il sépare les données de signature numérique (le « témoin ») du corps principal de la transaction, ce qui corrige une faille de sécurité appelée « malléabilité des transactions » et réduit la taille de chaque transaction.
- La capacité des blocs est mesurée en unités de poids (WU) plutôt qu'en octets. Les données de témoin coûtent 1 WU par octet, contre 4 WU par octet pour les autres données, ce qui permet aux transactions SegWit de bénéficier d'une réduction de 75 % sur la taille de la signature.
- Le SegWit natif (adresses bc1q) réduit la taille d'une transaction standard d'environ 226 vbytes à environ 141 vbytes, ce qui permet de réduire les frais d'environ 38 % par rapport aux adresses traditionnelles.
- La garantie d'un TXID fixe offerte par SegWit constituait la condition préalable technique à la mise en place du Lightning Network. Sans elle, il aurait été impossible de créer des canaux de paiement en toute sécurité.
- Son système de gestion des versions de script a permis la mise en œuvre de Taproot (SegWit V1, activé en 2021) et offre un cadre pour les futures mises à jour de Bitcoin sans recourir à des hard forks.
- En 2026, environ 85 % des transactions Bitcoin utiliseront SegWit. Il s'agit de la norme du réseau, et non d'une nouvelle fonctionnalité.
Qu'est-ce que SegWit ?
SegWit, ou Segregated Witness, est une modification du format des transactions Bitcoin qui sépare les signatures numériques – la preuve cryptographique que vous avez le droit de dépenser une pièce – des données principales de la transaction, et les stocke dans une structure distincte appelée « witness ». Cela réduit la taille de chaque transaction, permet d'en inclure davantage dans chaque bloc et élimine une vulnérabilité qui rendait impossible la mise en place sécurisée de canaux de paiement sur la base de Bitcoin.
Le nom se décompose simplement : « segregated » signifie « séparé », et « witness » est le terme cryptographique désignant les données de signature qui prouvent la validité d'une transaction. Le « witness » répond à la question « le propriétaire légitime a-t-il autorisé cette opération ? », tandis que le reste des données de la transaction répond à la question « où vont les fonds et pour quel montant ? ».
The official BIP 141 header on GitHub, showing its three co-authors and December 2015 assignment date.Cette mise à jour a été officiellement définie comme la proposition d'amélioration Bitcoin n° 141 (BIP 141) et proposé par les développeurs de Bitcoin Core Pieter Wuille, Eric Lombrozo et Johnson Lau lors de la conférence Scaling Bitcoin en décembre 2015. Il a été activé sur le réseau principal Bitcoin le 24 août 2017, au bloc 481 824, sous la forme d'un soft fork, ce qui signifie qu'il était rétrocompatible. Les nœuds qui n'avaient pas été mis à jour pouvaient toujours valider les données de transaction de base ; les nœuds mis à jour voyaient l'ensemble des données, y compris le witness.
En 2026, environ 85 % de toutes les transactions Bitcoin utiliseront SegWit. Il ne s'agit plus d'une nouveauté, mais de la norme.
Les problèmes que SegWit a été conçu pour résoudre
SegWit a résolu deux problèmes distincts qui freinaient le développement du Bitcoin depuis des années.
Malléabilité des transactions
Chaque transaction Bitcoin possède un identifiant unique appelé TXID, un hachage généré à partir des données de la transaction. Avant SegWit, ce hachage était calculé sur l'ensemble de la transaction, y compris la signature.
Voici le problème : une signature cryptographique ne peut pas se signer elle-même. Cela laissait une petite faille permettant à quiconque relayant votre transaction sur le réseau de modifier légèrement la signature de manière à ce qu'elle reste mathématiquement valide tout en générant un TXID différent. Les fonds étaient toujours envoyés à la bonne adresse et la transaction était toujours validée, mais l'identifiant avait changé.
Cela ne semble pas catastrophique pour un simple paiement. Mais pour les protocoles qui enchaînent plusieurs transactions non confirmées, c'est fatal. Le Lightning Network, qui fonctionne en créant une série d'engagements de paiement hors chaîne faisant référence à des identifiants de transaction antérieurs, ne peut pas fonctionner en toute sécurité si l'un de ces identifiants venait à changer avant leur confirmation. Un TXID modifiable signifie que la chaîne se rompt, et que les fonds peuvent être bloqués ou volés.
La malléabilité des transactions a également causé des dommages concrets avant d'être corrigée. La plateforme d'échange Mt. Gox l'a citée comme l'un des facteurs ayant contribué à son effondrement en 2014, même si les historiens débattent pour savoir dans quelle mesure il s'agissait d'une cause profonde ou plutôt d'un prétexte masquant une mauvaise gestion plus profonde.
SegWit a résolu ce problème en supprimant complètement les signatures du calcul du TXID. L'identifiant est désormais calculé uniquement à partir des champs de base de la transaction. La modification de la signature n'altère plus l'identité de la transaction.
Lutter contre la congestion et la hausse des frais
En 2016 et au début de l'année 2017, le Bitcoin traitait environ 7 transactions par seconde. Lors des pics de demande, les retards de traitement des transactions se chiffraient à plusieurs dizaines de milliers et les frais grimpaient jusqu'à 50 dollars ou plus pour un transfert standard. Le problème était structurel : les blocs de Bitcoin étaient limités à 1 Mo, et les signatures représentaient environ 65 % de la taille des transactions.
La solution évidente, à savoir augmenter la limite de taille des blocs, nécessitait un hard fork, ce qui impliquait que tous les nœuds devaient se mettre à jour ou se retrouver sur une chaîne incompatible. Les hard forks sont très risqués et controversés. SegWit a permis de contourner complètement cette contrainte.
Comment fonctionne SegWit
Séparation des données des témoins
Dans une transaction Bitcoin classique, chaque entrée comprend un champ ScriptSig contenant la signature et la clé publique de l'émetteur. Dans une transaction SegWit, le champ ScriptSig est laissé vide pour les entrées SegWit. La signature et la clé publique sont déplacées vers un nouveau champ « witness » ajouté à la fin de la transaction.
Deux octets supplémentaires, un marqueur (0x00) et un indicateur (0x01), signalent aux nœuds compatibles SegWit que des données de témoin suivent. Les nœuds antérieurs à SegWit voient simplement un ScriptSig vide et traitent la transaction comme valide selon l'ancienne interprétation « n'importe qui peut dépenser », ce qui garantit la rétrocompatibilité.
Le poids du bloc remplace la taille du bloc
SegWit a remplacé la limite de taille de bloc de 1 Mo par un nouveau paramètre : le poids du bloc, plafonné à 4 millions d'unités de poids (WU).
Le point essentiel réside dans la manière dont les octets sont comptés :
- Chaque octet de données de transaction sans témoin coûte 4 unités de poids
- Chaque octet de données de témoin ne coûte qu'une unité de poids
Comme les signatures sont volumineuses et se trouvent désormais dans la section « witness », elles occupent désormais quatre fois moins d'espace qu'auparavant en termes de capacité de bloc. C'est ainsi que SegWit a permis d'augmenter la taille effective des blocs à environ 1,7 à 2 Mo dans la pratique, sans pour autant enfreindre la règle du 1 Mo appliquée par les anciens nœuds. Pour un bloc théoriquement entièrement SegWit, la taille maximale est de 4 Mo, bien que cela ne se produise jamais en pratique, car chaque bloc contient également des données non-witness.
Virtual Bytes (vBytes) : l'unité affichée dans les portefeuilles
Afin de maintenir des taux de frais comparables à ceux des transactions classiques, SegWit a introduit les « virtual bytes » (vbytes) : des unités de poids divisées par 4. Pour les transactions classiques, les bytes et les vbytes sont identiques. Pour les transactions SegWit, les vbytes sont inférieurs, car la réduction du volume des données de témoin fait baisser ce chiffre.
Les frais de portefeuille sont exprimés en satoshis par vbyte (sat/vB). Une transaction SegWit comportant moins de vbytes entraîne des frais moins élevés pour un même taux sat/vB. C'est ce mécanisme qui explique la réduction des frais que vous constatez lorsque vous utilisez une adresse bc1q plutôt qu'une adresse commençant par 1...
Types d'adresses SegWit : laquelle choisir ?
Outre ses modifications techniques, SegWit a introduit de nouveaux formats d'adresse. Le type d'adresse détermine la manière dont votre portefeuille encode les conditions de dépense, ce qui a une incidence sur vos frais, votre compatibilité avec d'autres portefeuilles et la façon dont vos transactions apparaissent sur la blockchain.
Comparaison des types d'adresse
1...3...bc1q... 42 caractèresbc1q... 62 caractèresbc1p... 62 caractères1...3...bc1q... 42 caractèresbc1q... 62 caractèresbc1p... 62 caractèresDonnées relatives au montant des transactions : Spark.money : Guide de référence sur la taille des transactions Bitcoin, 2026. Les économies réalisées sur les frais sont approximatives et varient en fonction des conditions du mempool.
Ancien (P2PKH, préfixe 1...) Il s'agit du format d'origine datant de 2009. La signature reste intégrée au corps de la transaction principale, où elle est prise en compte dans son intégralité. Aucune économie sur les frais. Ce format est toujours pris en charge partout, ce qui constitue la seule raison de l'utiliser aujourd'hui, si vous avez affaire à des logiciels très anciens qui ne peuvent pas accepter d'autres formats.
SegWit imbriqué (P2SH-P2WPKH, préfixe 3...) enveloppe un script SegWit dans une ancienne enveloppe P2SH. Lorsque SegWit a été activé en 2017, tous les portefeuilles et toutes les plateformes d'échange n'ont pas immédiatement pris en charge le nouveau format bc1. Le SegWit imbriqué a servi de pont de compatibilité : vous bénéficiez d'une réduction partielle des frais, et les expéditeurs utilisant des logiciels plus anciens peuvent toujours vous payer. En 2026, ce format existe principalement à titre de solution de secours. Le 3... Le préfixe est commun aux adresses P2SH non SegWit, ce qui signifie qu'il est impossible de déterminer, à partir de l'adresse seule, s'il s'agit d'une transaction SegWit.
SegWit natif (P2WPKH, préfixe bc1q...(42 caractères) est le choix idéal pour la plupart des utilisateurs. Il utilise le codage Bech32, qui se compose exclusivement de minuscules, offre une meilleure détection des erreurs que le Base58 et élimine les caractères qui se ressemblent (pas de O majuscule, de zéro, de I majuscule ni de l minuscule). Une transaction P2WPKH standard à 1 entrée et 2 sorties coûte environ 141 vbytes, soit environ 38 % de moins qu'une transaction traditionnelle équivalente. Tous les portefeuilles et bourses actifs le prennent en charge depuis 2026.
Multisignature SegWit native (P2WSH, préfixe bc1q...(62 caractères) Il s'agit de la variante « script-hash », utilisée pour les portefeuilles multisignature et les conditions de dépense complexes. L'adresse plus longue correspond à un hachage SHA-256 de 32 octets, plutôt qu'au hachage de 20 octets utilisé par P2WPKH. Si vous utilisez une configuration multisignature 2 sur 3, P2WSH est la méthode native SegWit pour le faire.
Taproot (P2TR, préfixe bc1p...(62 caractères) Il s'agit de la version 1 de SegWit, activée en 2021. Elle utilise les signatures Schnorr plutôt que l'ECDSA, ce qui permet d'agréger plusieurs signatures en une seule, rendant ainsi les transactions multisignatures indiscernables des transactions à signature unique sur la chaîne. Elle offre les frais les plus bas pour les dépenses à signature unique et la meilleure confidentialité. Utilisez-la lorsque vous avez confirmé que vos destinataires et leurs portefeuilles prennent en charge les adresses bc1p.
Une suggestion rapide
Pour la plupart des utilisateurs : utilisez le SegWit natif (bc1q). Il est pris en charge par pratiquement tous les portefeuilles et toutes les plateformes d'échange en activité, permet d'économiser environ 38 % sur les frais par rapport à l'ancien système et ne présente aucun risque de compatibilité en 2026 (pour les développeurs qui intègrent SegWit dans un logiciel de portefeuille, consultez le Guide de développement du portefeuille Bitcoin Core.).
Si votre portefeuille prend en charge Taproot (bc1p) et que vous effectuez des transactions à signature unique avec des destinataires dont les portefeuilles le prennent également en charge, cela vous permet de bénéficier de frais légèrement moins élevés et d'une confidentialité renforcée.
Le SegWit imbriqué (3...) est un mécanisme de secours pour assurer la compatibilité. C'est une bonne chose, mais il n'y a plus aucune raison de le choisir par défaut.
La guerre de la taille des blocs : pourquoi SegWit a suscité tant de controverses
Les arguments techniques en faveur de SegWit étaient clairs. Son processus de mise en œuvre, lui, ne l'était pas.
De 2015 à 2017, le Bitcoin a été au cœur de l'un des conflits de gouvernance les plus clivants de son histoire. Au fond, la question était simple : comment un réseau décentralisé doit-il mettre à jour ses propres règles lorsque différentes factions ont des intérêts contradictoires ?
L'impasse dans le secteur minier
Dans le cadre du processus standard de mise à jour BIP9, un soft fork nécessitait que 95 % des mineurs manifestent leur soutien au cours d'une période de deux semaines. Début 2017, SegWit était prêt à être activé depuis des mois, mais restait bloqué en dessous de ce seuil.
La plus forte opposition est venue des grandes sociétés minières, en particulier Bitmain, qui contrôlait à l'époque une part importante de la puissance de calcul du réseau Bitcoin. La raison de cette opposition est apparue clairement par la suite : Bitmain utilisait une technique brevetée appelée ASICBoost, une optimisation qui conférait à son matériel de minage un avantage significatif en termes d'efficacité. SegWit était structurellement incompatible avec l'ASICBoost dissimulé. Le blocage de SegWit permettait de préserver cet avantage.
Le BIP 148 et l'UASF
En mars 2017, un développeur anonyme utilisant le pseudonyme Shaolinfry a publié le BIP 148 : un « soft fork » activé par les utilisateurs (UASF). Plutôt que d'attendre le signal des mineurs, le BIP 148 proposait que les nœuds économiques, c'est-à-dire les bourses, les processeurs de paiement et les entreprises utilisant le logiciel Bitcoin, commencent simplement à rejeter tout bloc ne signalant pas la prise en charge de SegWit à compter du 1er août 2017.
Le raisonnement était simple : les mineurs produisent des blocs, mais ceux-ci n'ont de valeur que si le réseau les accepte. Si une majorité économique suffisante exploitait des nœuds BIP 148, les mineurs devaient soit activer SegWit, soit voir leurs blocs devenir orphelins. Le risque était tout aussi clair : si l'adoption était insuffisante, cela entraînerait une scission de la chaîne, avec deux versions incompatibles de Bitcoin fonctionnant en parallèle.
La campagne UASF était populaire et bruyante. Des badges de conférence ont fait leur apparition. Les débats sur Twitter se sont intensifiés. L'expression « gérez votre propre nœud » a pris une nouvelle importance.
L'accord de New York et le Bitcoin Cash
Face à l'échéance fixée par l'UASF, plus de 50 grandes entreprises du secteur du Bitcoin se sont réunies à New York en mai 2017 et ont signé ce qui est devenu l'« Accord de New York ». Elles ont convenu d'activer SegWit, mais aussi de procéder ensuite à un hard fork afin de doubler la taille des blocs pour la porter à 2 Mo (ce projet a été baptisé SegWit2x).
Ce compromis n'a pleinement satisfait aucun des deux camps. Les développeurs opposés à l'augmentation de la taille des blocs ont considéré SegWit2x comme un hard fork détourné auquel ils n'avaient pas donné leur accord. Quant aux mineurs et aux entreprises qui souhaitaient des blocs plus volumineux, ils n'ont toujours pas obtenu ce qu'ils voulaient au départ.
Le 1er août 2017, une faction qui souhaitait une simple augmentation de la taille des blocs, sans SegWit, a procédé à un fork de Bitcoin pour créer Bitcoin Cash (BCH), avec une limite initiale de 8 Mo par bloc. SegWit a été activé sur Bitcoin le 24 août 2017. Le hard fork SegWit2x a été abandonné en novembre 2017 après que ses organisateurs ont conclu qu'ils ne disposaient pas d'un consensus suffisant.
Ce qui a été réglé
Les conséquences de cet événement ont dépassé le simple cadre des détails techniques. L'UASF avait fonctionné : ce sont les nœuds économiques, et non les mineurs, qui ont déterminé quelles règles de consensus s'appliquaient. Cet épisode est désormais régulièrement cité pour démontrer que la gouvernance du Bitcoin repose en fin de compte entre les mains de ceux qui exploitent et utilisent le logiciel, et non de ceux qui produisent les blocs. Le 1er août est considéré par une partie de la communauté comme le « Jour de l'indépendance du Bitcoin ».
Ce que SegWit a rendu possible
Le Lightning Network
Le Lightning Network a été conçu avant même que SegWit n'existe. Ses créateurs savaient qu'il ne pourrait pas être déployé en toute sécurité tant que le problème de malléabilité des transactions n'aurait pas été résolu, car les canaux de paiement reposent sur des chaînes de transactions non confirmées qui se référencent mutuellement par leur TXID. La garantie d'un TXID fixe offerte par SegWit a permis de sécuriser ces canaux.
Le Lightning Network a été lancé sur le réseau principal de Bitcoin début 2018, environ six mois après l'activation de SegWit. Au premier trimestre 2025, il avait déjà traité plus de 100 millions de transactions. Sans SegWit, cette infrastructure n'existerait pas.
Taproot et la gestion des versions des scripts
SegWit a introduit la gestion des versions de script dans le format des transactions Bitcoin. Le programme « witness » commence par un octet de version : SegWit V0 prend en charge les schémas P2WPKH et P2WSH. Toute mise à jour future définissant un nouveau numéro de version disposera de ses propres règles sans entrer en conflit avec celles existantes, et sans nécessiter une nouvelle bataille controversée autour de la mise à jour.
SegWit V1, c'est Taproot, activé en novembre 2021. Il a introduit les signatures Schnorr, le cadre MAST (Merkelized Abstract Syntax Trees) pour les conditions de dépense complexes, ainsi que des améliorations en matière de confidentialité qui font en sorte que les transactions des portefeuilles multisignature apparaissent identiques aux transactions à signature unique sur la chaîne. Toutes les fonctionnalités techniques introduites par Taproot s'appuyaient sur l'architecture de gestion des versions créée par SegWit.
Nombres ordinaux et inscriptions
La structure de données de témoin introduite par SegWit, puis étendue par Taproot, a rendu techniquement possible l'intégration de données, d'images, de texte ou de code arbitraires directement dans les transactions Bitcoin. C'est le mécanisme qui sous-tend le protocole Ordinals et les inscriptions Bitcoin, ce qui a entraîné une forte augmentation de l'utilisation des données sur la chaîne et porté l'adoption de Taproot à environ 42 % des transactions en 2024. À mesure que l'activité d'inscription a diminué, l'utilisation de Taproot s'est stabilisée à environ 20 % des transactions à la fin de 2025, tandis que SegWit V0 reste le format dominant avec environ 85 %.
SegWit dans son contexte : le calendrier des mises à jour de Bitcoin
Adoption en cours
L'adoption de SegWit a progressé régulièrement après son activation, atteignant 30 % des transactions dès les premiers mois, puis dépassant la barre des 50 % au cours des deux années suivantes, à mesure que les portefeuilles et les plateformes d'échange mettaient à jour leurs logiciels.
En 2026, environ 85 % des transactions Bitcoin utilisent SegWit (source : Spark.money Bitcoin Network Statistics, CoinGecko). Les 15 % restants correspondent à des transactions héritées provenant de portefeuilles et de services qui n'ont pas été mis à jour. L'adoption de Taproot (P2TR, SegWit V1) a atteint un pic d'environ 42 % des transactions en 2024, principalement grâce à l'activité d'inscription d'Ordinals, avant de se stabiliser autour de 20 % fin 2025, à mesure que le volume d'inscriptions diminuait.
La courbe d'adoption reflète ce qui s'est passé avec SegWit : il faut compter entre un et trois ans pour que les nouveaux formats d'adresse soient largement adoptés, le temps que les portefeuilles matériels, les plateformes d'échange et les prestataires de paiement mettent à jour leurs logiciels. La prise en charge de Taproot continue de se généraliser dans les différentes implémentations de portefeuilles.
SegWit vs. Legacy : résumé des différences
1...bc1q... (en version native) ou 3... (imbriqué)1...bc1q... (en version native) ou 3... (imbriqué)Conclusion
SegWit est la mise à jour du protocole qui a séparé les données de signature de Bitcoin de ses données de transaction, corrigé une faille de sécurité existant depuis 2009, réduit les frais de transaction d'environ un tiers et posé les bases architecturales du Lightning Network, de Taproot et de tout ce qui a été développé à partir de ces technologies depuis lors.
Depuis 2026, il s'agit de la norme de transaction sur Bitcoin, traitant la grande majorité de l'activité sur la chaîne. Les formats d'adresse qu'il a introduits, en particulier le format natif SegWit (bc1q), sont ceux que la plupart des utilisateurs devraient utiliser par défaut aujourd'hui. La bataille politique qui a entouré son activation reste l'un des chapitres les plus instructifs de l'histoire de la gouvernance de Bitcoin : une démonstration que, dans un réseau décentralisé, le consensus n'est pas quelque chose que les mineurs accordent, mais quelque chose que les utilisateurs imposent.
