Le 9 novembre 2026, un utilisateur de Bitcoin pouvait faire entrer une transaction dans le prochain bloc pour 1 satoshi par octet virtuel, le tarif que mempool.space recommandait ce matin-là pour toutes les vitesses, de la plus rapide à l’économique. Le même jour, la carte publique du Lightning Network affichait environ 3 218 BTC bloqués dans quelque 28 050 canaux de paiement entre environ 15 030 nœuds, et LNbits, un logiciel très répandu qui tourne au-dessus des nœuds Lightning, demandait à tous ses opérateurs d’éteindre leurs serveurs après une vague d’attaques. Ces deux faits décrivent le même système. Le Lightning rend les paiements en bitcoin rapides et peu coûteux, mais à une condition : que quelqu’un, vous ou une entreprise en qui vous avez confiance, garde en ligne et à jour un logiciel.
Cette leçon explique ce qui se passe à l’intérieur de ce logiciel. Elle prolonge notre leçon sur SegWit et Taproot, et le lien est direct : les canaux Lightning reposent sur des transactions signées avant que celles qu’elles dépensent ne soient confirmées, ce qui était risqué tant que SegWit n’avait pas corrigé la malléabilité des transactions en 2017, et Taproot a ensuite donné aux canaux une empreinte plus légère et plus discrète sur la chaîne. Si vous voulez d’abord la version courte, notre guide des réseaux de couche 1 et de couche 2 consacre une partie au Lightning comme couche 2 de Bitcoin.
Qu’est-ce que le Lightning Network ? Des canaux de paiement au-dessus de Bitcoin
Le Lightning Network est un réseau de canaux de paiement à deux participants, bâti sur Bitcoin. Deux personnes bloquent des bitcoins dans une sortie partagée sur la blockchain, avec une seule transaction. Ensuite, elles déplacent le solde entre elles en échangeant des transactions signées qu’elles conservent sans les diffuser, aussi souvent qu’elles le veulent et presque sans frais. Quand elles ont fini, une dernière transaction règle le résultat sur la chaîne. Comme les canaux sont reliés entre eux, un paiement peut en traverser plusieurs pour atteindre quelqu’un avec qui vous n’avez jamais ouvert de canal, sans que les intermédiaires puissent le voler en route. Le Lightning n’a pas de monnaie propre : l’unité est le bitcoin, compté en satoshis ou en millièmes de satoshi, et tout « jeton Lightning » vendu en ligne n’a rien à voir avec le protocole.
L’idée a été mise par écrit par Joseph Poon et Thaddeus Dryja. Leur document, daté du 14 janvier 2016 dans sa version provisoire 0.5.9.2, part d’un constat sans détour : « Currently, Bitcoin supports less than 7 transactions per second with a 1 megabyte block limit » (Bitcoin ne traite aujourd’hui pas même 7 transactions par seconde avec un bloc limité à 1 mégaoctet), à comparer aux 47 000 transactions par seconde que Visa a absorbées lors de son pic des fêtes de 2013 (Poon et Dryja, The Bitcoin Lightning Network, en anglais). Leur réponse n’était pas une chaîne plus grande, mais moins d’allers-retours vers elle. La blockchain de Bitcoin ressemble à un bureau de poste qui tamponne chaque lettre du monde entier ; le Lightning est la caisse posée à côté, où deux parties tiennent un compte courant et ne postent que le total.
smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il a fallu deux ans de plus pour qu’il voie le jour. Le 15 mars 2018, Lightning Labs a publié lnd 0.4-beta, qu’elle présentait comme « the first release of lnd that has the option to run on Bitcoin’s mainnet » (la première version de lnd qui peut tourner sur le mainnet de Bitcoin), tout en recommandant aux utilisateurs de n’« experiment with only small amounts » (expérimenter qu’avec de petits montants) (Lightning Labs, annonce de lnd beta, en anglais). Ce délai compte : SegWit, activé en août 2017, a supprimé le risque qu’un tiers modifie l’identifiant d’une transaction avant sa confirmation, ce qui aurait cassé la chaîne de transactions présignées dont un canal dépend.
Un canal Lightning, c’est une sortie 2-sur-2 et une pile de transactions non diffusées
Tout, dans un canal, utilise des outils vus dans notre leçon sur les transactions et les scripts Bitcoin : les sorties multisignatures, les verrous temporels relatifs (CSV) et absolus (CLTV). Le Lightning n’ajoute aucun opcode. Il assemble ces briques dans un ordre précis, décrit dans les spécifications BOLT.
Ouverture : une transaction de financement sur la blockchain
Alice et Bob conviennent d’ouvrir un canal. Alice construit une transaction de financement qui verse, disons, 1 000 000 sats vers une sortie de type pay-to-witness-script-hash verrouillée par un script 2-sur-2 : 2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG, les deux clés étant triées pour que les deux parties construisent exactement le même script (BOLT 3, transactions, en anglais). Dépenser cette sortie exige désormais les deux signatures.
Avant qu’Alice ne diffuse la transaction de financement, Bob signe sa première transaction d’engagement, qui dépense la sortie de financement et rend à Alice ses 1 000 000 sats. C’est le filet de sécurité : si Bob disparaissait juste après la confirmation du financement, Alice pourrait quand même récupérer son argent. Ce n’est qu’alors que la transaction de financement part vers le réseau, et le canal devient utilisable quand elle a obtenu le nombre de confirmations choisi par les deux côtés.
Quelques règles du protocole entre pairs (BOLT 2, en anglais) déterminent ce qu’un canal peut contenir. Sauf si les deux nœuds acceptent l’option des grands canaux, un canal doit rester inférieur à 224 satoshis, soit 16 777 216 sats ou environ 0,168 BTC ; la spécification parle d’un plafond provisoire, hérité de l’époque où les implémentations n’étaient pas jugées stables. Chaque côté garde une réserve, la spécification suggérant 1 % du canal, afin d’avoir toujours quelque chose à perdre s’il triche. Et chaque côté accepte au plus 483 paiements en attente en même temps.
Le coût sur la chaîne : en novembre 2026, l’ouverture est bon marché. À 1 sat/vB, une transaction de financement de quelques centaines d’octets virtuels coûte quelques centaines de sats (un exemple, pas un devis : les frais bougent, et notre leçon sur le mempool et les frais de transaction explique pourquoi ils montent quand les blocs se remplissent). Un canal ouvert pendant un pic de frais peut coûter bien plus, et sa fermeture aussi.
Mise à jour : de nouveaux engagements, les anciens révoqués
Chaque paiement dans le canal remplace la paire de transactions d’engagement par une nouvelle paire. Alice détient une version signée par Bob, Bob détient une version miroir signée par Alice, et aucune n’est diffusée. Sur la copie d’Alice, la part de Bob va directement à Bob, tandis que la part d’Alice repose dans une sortie to_local qui a deux issues : Alice peut la récupérer après un délai de to_self_delay blocs, imposé par un CSV, ou Bob peut la prendre immédiatement avec une clé de révocation.
Cette clé de révocation est la partie ingénieuse. Bob ne peut pas l’utiliser tant que l’engagement est en vigueur, car il lui manque un secret que seule Alice connaît. Quand le canal passe à un nouvel état, Alice remet à Bob le secret de l’ancien engagement, et à partir de là Bob peut dériver la clé qui déverrouille l’ancienne sortie to_local. Révoquer un état, c’est donc donner à son partenaire le pouvoir de vous punir si jamais vous le publiez.
Si Alice diffuse plus tard un engagement périmé qui lui versait davantage, Bob dispose de toute la fenêtre de to_self_delay pour s’en apercevoir et balayer la sortie d’Alice avec la clé de révocation : la tricheuse perd tout son solde dans le canal, et pas seulement la somme qu’elle voulait prendre. La spécification de gestion sur la chaîne avertit même qu’il est dangereux de regrouper toutes les sorties révoquées dans une seule transaction de pénalité, car le tricheur peut la bloquer ; chaque sortie doit être balayée séparément (BOLT 5, en anglais). La pénalité ne fonctionne que si quelqu’un surveille la chaîne pendant cette fenêtre, et c’est là qu’interviennent les tours de guet, plus loin dans cette leçon.
Fermeture : coopérative ou forcée
Une fermeture coopérative est la fin normale. Les deux nœuds s’accordent sur une transaction finale qui verse à chacun son solde directement depuis la sortie de financement, sans délai et avec des frais qu’ils négocient. Sur la chaîne, cela ressemble à une transaction ordinaire.
Une fermeture forcée survient quand un côté est hors ligne, ne répond plus ou se comporte mal. L’autre côté diffuse son dernier engagement. La partie qui a fermé attend l’expiration de son propre to_self_delay avant de toucher son argent, et les paiements encore en cours sont réglés par des transactions supplémentaires sur la chaîne. Les engagements étant signés à l’avance, leurs frais peuvent se révéler trop bas le moment venu. Depuis que le format à sorties d’ancrage est entré dans la spécification en août 2020, chaque engagement porte deux petites sorties d’ancrage de 330 sats, une par côté ; chaque propriétaire peut dépenser la sienne dans une transaction fille qui paie des frais plus élevés pour les deux (CPFP), et après 16 blocs, n’importe qui peut balayer une ancre restante. En mai 2026, la spécification a ajouté une variante à engagement sans frais (bits de fonctionnalité 40/41), fondée sur les transactions de version 3, dans laquelle l’engagement ne paie aucun frais et c’est une transaction fille qui paie tout. Les fermetures forcées sont le point de rencontre du Lightning avec le marché des frais, et c’est la sortie coûteuse.
Comment un paiement Lightning traverse deux inconnus, étape par étape
La plupart des paiements n’empruntent pas un canal direct. Alice veut payer Carol, elle a un canal avec Bob, et Bob en a un avec Carol. Bob est un inconnu pour les deux, et le protocole doit garantir qu’il ne peut ni garder l’argent ni perdre le sien. L’outil est le contrat à verrou de hachage et de temps (HTLC) : un paiement conditionnel que le destinataire peut réclamer en révélant un secret, et qui revient à l’expéditeur si le secret n’apparaît pas avant une hauteur de bloc donnée.
Le tableau suit un paiement avec des chiffres d’exemple. Les frais utilisent la formule de la spécification de diffusion, un frais de base plus un taux proportionnel en millionièmes, avec une base de 200 millisatoshis et un taux de 100 parties par million, proches des médianes du graphe public le 9 novembre 2026 (200 msat et 103 ppm selon l’explorateur mempool.emzy.de, le taux étant arrondi ici). Les hauteurs de bloc partent du bloc 975 158, la pointe de la chaîne ce matin-là. Tout le reste est illustratif.
| Étape | Qui agit | Ce qui se passe (chiffres d’exemple) |
|---|---|---|
| 1 | Carol | Tire un secret au hasard, la préimage, et place son empreinte SHA-256 dans une facture de 100 000 sats. La facture expire au bout de 3 600 secondes par défaut et demande au moins 18 blocs de marge sur le dernier saut (valeurs par défaut de BOLT 11). |
| 2 | Alice | Trouve un itinéraire via Bob à partir de la carte publique des canaux et construit un oignon : une couche chiffrée par saut, si bien que Bob sait seulement d’où vient le paiement et où l’envoyer ensuite. |
| 3 | Alice vers Bob | Ajoute un HTLC de 100 010,2 sats à son canal avec Bob (100 000 plus les frais de Bob : 0,2 sat de base plus 10 sats proportionnels). Il expire au bloc 975 216. Les deux signent de nouveaux engagements. |
| 4 | Bob vers Carol | Ouvre sa couche, vérifie les frais et l’échéance, puis ajoute un HTLC de 100 000 sats à son canal avec Carol, qui expire plus tôt, au bloc 975 176. |
| 5 | Carol | Révèle la préimage à Bob pour réclamer ses 100 000 sats. Le canal passe à un nouvel état. |
| 6 | Bob | Utilise la même préimage pour réclamer 100 010,2 sats à Alice. Il garde 10,2 sats. Rien n’a touché la blockchain. |
Les deux échéances sont le cœur du dispositif. Le HTLC sortant de Bob vers Carol expire 40 blocs avant le HTLC entrant venu d’Alice ; cet écart est son cltv_expiry_delta, qu’il annonce dans les messages channel_update qu’il diffuse pour ce canal. Si Carol réclame à la dernière minute, Bob dispose encore d’environ 40 blocs, soit à peu près six heures et demie, pour utiliser sa préimage contre Alice. Chaque saut a besoin d’une marge de ce genre, de sorte qu’un itinéraire de cinq sauts immobilise l’argent de l’expéditeur plus longtemps qu’un itinéraire de deux en cas de problème.
Si Carol ne révèle jamais le secret, les HTLC expirent simplement ou sont annulés saut après saut, et chacun retrouve son solde précédent. Si Bob disparaît alors qu’il détient le HTLC d’Alice, Alice peut forcer la fermeture et récupérer ses fonds sur la chaîne après l’expiration. La préimage fait aussi office de reçu : Alice peut montrer que Carol a été payée, puisque seule Carol connaissait le secret.
L’oignon lui-même est un paquet de taille fixe, 1 366 octets : un octet de version, une clé publique de 33 octets, 1 300 octets de données de saut et un contrôle de 32 octets (BOLT 4, routage en oignon, en anglais). Tous les paquets ont la même taille quelle que soit la longueur de l’itinéraire, si bien que le paquet ne dit pas à un saut à quelle distance il se trouve de l’expéditeur ou du destinataire.
Routage, liquidité et confidentialité : le réseau derrière le paiement
Pourquoi les paiements Lightning échouent parfois
Les nœuds s’informent des canaux par des messages de diffusion (gossip) : qui est relié à qui, la capacité du canal, les frais et le delta de verrou temporel. Cette diffusion ne dit pas comment la capacité se répartit entre les deux côtés, car cela change à chaque paiement et le publier révélerait qui a payé qui. Alice sait donc qu’un canal entre Bob et Carol contient 2 millions de sats au total, mais pas si le côté de Bob a les 100 000 dont elle a besoin. Son portefeuille devine, essaie, et en cas d’échec tente un autre itinéraire.
Des chercheurs travaillent depuis des années sur cette devinette. René Pickhardt et Stefan Richter ont montré en 2021 que choisir les itinéraires au plus bas frais ignore les soldes inconnus ; modéliser la probabilité de succès et fractionner un paiement en plusieurs parts pourrait, selon eux, augmenter la taille des paiements qui passent de façon fiable « by several orders of magnitude » (de plusieurs ordres de grandeur) (Pickhardt et Richter, arXiv 2107.05322, en anglais). Fractionner un paiement sur plusieurs chemins, ce qu’on appelle les paiements multi-parts, fait aujourd’hui partie de la spécification. Les taux de réussite publiés viennent chaque fois d’un seul portefeuille, d’un seul opérateur de nœud ou d’une seule équipe de recherche : un « taux d’échec du Lightning » cité en ligne décrit donc cet échantillon, pas le réseau.
Liquidité : entrante, sortante et rôle des fournisseurs de service
Le solde d’un canal a une direction. Alice peut envoyer seulement ce qui se trouve de son côté, moins sa réserve : c’est sa liquidité sortante. Pour recevoir, il lui faut des fonds du côté de son partenaire dans un canal, sa liquidité entrante. Un nouvel utilisateur qui ouvre un canal avec 1 000 000 sats peut payer mais ne peut pas recevoir un seul sat tant que l’argent ne revient pas. Un commerçant a le problème inverse.
Les fournisseurs de services Lightning (LSP) existent pour régler cela. De nombreux portefeuilles mobiles ouvrent un canal vers l’utilisateur depuis le côté du fournisseur au premier paiement, ou vendent de la capacité entrante contre des frais. Le splicing permet d’agrandir ou de réduire un canal sans le fermer : la sortie de financement est dépensée vers une nouvelle sortie contenant plus ou moins de fonds pendant que les paiements continuent de circuler. La spécification du splicing (bits de fonctionnalité 62/63) a été fusionnée dans le dépôt BOLT le 23 mars 2026 (demande de fusion BOLT 1160, en anglais), et la prise en charge varie selon les implémentations : Lightning Labs écrivait en juin 2026 que ses nouveaux canaux Taproot « lay the groundwork for splicing » (préparent le terrain pour le splicing), donc LND 0.21 ne l’embarque pas.
Confidentialité : oignons, chemins aveuglés et ce que révèle la carte des canaux
Le routage en oignon cache l’itinéraire complet aux intermédiaires, et le paiement n’apparaît jamais sur la blockchain. C’est un vrai gain par rapport aux paiements sur la chaîne, où chaque montant et chaque adresse sont publics. Il a ses limites. Un canal public annonce sa sortie de financement, si bien que chacun peut relier un nœud à une transaction sur la chaîne et à sa capacité. Un nœud placé juste à côté d’un destinataire peut deviner beaucoup de choses. Les chemins aveuglés, utilisés par les offres BOLT 12, permettent au destinataire de cacher les derniers sauts, et même l’identifiant de son nœud, au payeur. Les canaux privés, non annoncés, n’apparaissent pas du tout sur la carte, ce qui protège leurs propriétaires et, comme le montrent les chiffres plus bas, rend le réseau plus difficile à mesurer.
Les spécifications BOLT, quatre implémentations et les évolutions de 2026
La technologie est définie par les documents Basis of Lightning Technology, les BOLT, conservés dans un dépôt public dont le fichier de présentation indique qu’ils sont encore en cours de rédaction (lightning/bolts sur GitHub, en anglais). Ils vont du BOLT 1 (messages de base) au BOLT 12 (offres). Il n’y a pas de BOLT 6 dans le dépôt. Tout nœud qui les suit peut ouvrir des canaux avec n’importe quel autre, quel que soit le logiciel de chacun.
Quatre implémentations portent l’essentiel du réseau. LND, de Lightning Labs, écrit en Go, est le logiciel de la plupart des nœuds publics et se trouve dans des plateformes de nœud clés en main comme Umbrel. Core Lightning, écrit en C, est né chez Blockstream. Eclair, écrit en Scala par la société française ACINQ, fait tourner le grand nœud de routage d’ACINQ ; le portefeuille Phoenix de la même entreprise utilise lightning-kmp, une autre implémentation en Kotlin conçue pour les téléphones. LDK est une bibliothèque que les éditeurs de portefeuilles intègrent à leurs propres applications, plutôt qu’un nœud prêt à l’emploi.
| Évolution | Ce qu’elle change | Statut (date) |
|---|---|---|
| Sorties d’ancrage | Deux sorties de 330 sats sur chaque engagement pour pouvoir relever les frais au moment de la fermeture | Dans la spécification (BOLT 3) ; bits de fonctionnalité 22/23 |
| Canaux Taproot simples | La sortie de financement devient une sortie Taproot qui ressemble à une dépense à clé unique lors d’une fermeture coopérative | Adoptée dans la spécification le 4 mai 2026 (PR 995) ; jugée prête pour la production sur le mainnet dans LND 0.21, 11 juin 2026 |
| Splicing | Ajouter ou retirer des fonds sans fermer le canal | Adopté dans la spécification le 23 mars 2026 (PR 1160) ; absent de LND 0.21 |
| Offres BOLT 12 | Codes de paiement réutilisables ; une facture neuve pour chaque paiement, demandée par messages en oignon | Intégrées à la spécification le 24 septembre 2024 (PR 798) ; preuves de paiement ajoutées en juillet 2026 |
| Engagements sans frais | L’engagement ne paie aucun frais ; une transaction fille les paie via une ancre partagée | Dans BOLT 3 ; bits de fonctionnalité 40/41 |
Les canaux Taproot sont la suite directe de la leçon précédente. Le script multisignature 2-sur-2 disparaît de la chaîne : les deux parties combinent leurs clés en une seule, de sorte qu’une fermeture coopérative ressemble à n’importe quelle dépense Taproot à signature unique et occupe moins de place. L’article de Lightning Labs sur LND 0.21 indique que les canaux Taproot simples « graduate » (sortent) du statut expérimental, avec les scripts définitifs des bits de fonctionnalité 80/81 (Lightning Labs, lancement de LND 0.21, en anglais). La prise en charge dans les autres implémentations diffère et change de version en version.
Le BOLT 12 change la façon de demander de l’argent. Une facture BOLT 11, la longue chaîne commençant par lnbc que la plupart des portefeuilles affichent aujourd’hui, est à usage unique et expire par défaut au bout d’une heure. Une offre BOLT 12, qui commence par lno, peut être imprimée sur une page de dons ou sur une caisse et réutilisée : le portefeuille du payeur envoie une demande de facture par messages en oignon et reçoit une facture neuve, valable par défaut 7 200 secondes (BOLT 12, encodage des offres, en anglais). Cela suppose un relais des messages en oignon le long du chemin, que LND 0.21 limite désormais par défaut aux pairs qui ont un canal avec le nœud.
Les tours de guet (watchtowers) répondent au problème de la présence en ligne. Une tour de guet est un serveur qui reçoit de votre nœud de quoi punir un partenaire tricheur, et qui diffuse la transaction de pénalité si ce partenaire publie un état révoqué pendant que vous êtes hors ligne. LND embarque à la fois une tour et un client de tour, à activer dans sa configuration, et sa documentation qualifie ces tours d’altruistes : elles ne reçoivent aucune rémunération pour ce travail (documentation des tours de guet de LND, en anglais). Les portefeuilles mobiles s’en remettent souvent à leur fournisseur pour le même travail.
Reste une ambition : porter autre chose que le bitcoin. Lightning Labs et Tether ont annoncé le 30 janvier 2025 que l’USDT serait émis sur Bitcoin et circulerait sur le Lightning grâce au protocole Taproot Assets (annonce de Lightning Labs, en anglais). C’est un protocole distinct des canaux Taproot, et l’annonce ne mesure pas l’usage.
Lightning Network en chiffres, novembre 2026 : une capacité publique en baisse de 45 % depuis son pic
Les chiffres ci-dessous viennent de l’explorateur Lightning de mempool.emzy.de, une instance communautaire du logiciel mempool.space tenue par l’opérateur Emzy, dont les statistiques quotidiennes courent jusqu’au 9 novembre 2026. Le flux de statistiques Lightning de mempool.space lui-même s’arrête au 30 août 2026 ; sa dernière lecture est affichée à titre de comparaison. Les deux instances explorent le réseau séparément et ne voient pas exactement le même graphe : le 30 août, seul jour couvert par les deux, l’instance d’Emzy comptait 3 755,1 BTC dans 32 569 canaux et mempool.space 3 793,8 BTC dans 32 665 canaux, soit environ 1 % d’écart. L’essentiel de la différence entre les colonnes d’août et de novembre vient donc de l’évolution du réseau, et une petite part du changement de source.
| Graphe public | 28 déc. 2025 (plus haut sur un an) | 30 août 2026 (mempool.space) | 2 nov. 2026 | 9 nov. 2026 |
|---|---|---|---|---|
| Capacité (BTC) | 5 851,2 | 3 793,8 | 3 200,7 | 3 217,6 |
| Canaux | 41 866 | 32 665 | 28 936 | 28 051 |
| Nœuds | 17 409 | 16 235 | 15 905 | 15 030 |
| Taille médiane d’un canal (sats) | n. d. | 2 040 000 | 2 000 000 | 2 154 895 |
| Taux de frais médian (ppm) | n. d. | 100 | 100 | 103 |
Source : API de statistiques Lightning de mempool.emzy.de (points quotidiens des 28 décembre 2025, 2 et 9 novembre 2026), API de statistiques Lightning de mempool.space (30 août 2026), lues toutes deux le 9 novembre 2026. D’après un calcul à partir de ces chiffres, 3 217,6 BTC se situent 45 % sous la lecture la plus haute de l’année écoulée, et représentent environ 0,016 % des quelque 20 millions de bitcoins existants. Au cours de mempool.space de 74 166 dollars à 9 h 50 UTC le 9 novembre 2026, cela valait environ 239 millions de dollars.
Trois avertissements accompagnent ces chiffres. Ils ne comptent que les canaux publics : les canaux privés ouverts par de nombreux portefeuilles mobiles n’apparaissent dans aucun explorateur. Les différents outils de suivi explorent des tranches différentes du réseau et donnent des totaux différents le même jour. Et la capacité est le stock de bitcoins bloqués dans les canaux, pas le flux de paiements : un canal peut porter des milliers de paiements sans que sa capacité change. Ces séries montrent combien de capacité a quitté le graphe public depuis décembre 2025, pas pourquoi : aucun de ces outils ne peut dire si ces bitcoins sont revenus sur la chaîne, sont passés dans des canaux privés ou sont allés ailleurs.
Le flux raconte autre chose. River, une société de services financiers autour du bitcoin, a estimé que le Lightning avait porté environ 1,17 milliard de dollars en quelque 5,22 millions de transactions en novembre 2025, avec un paiement moyen de 223 dollars contre 118 un an plus tôt, comme l’a rapporté Bitcoin Magazine le 19 février 2026 (Bitcoin Magazine sur l’estimation de River, en anglais). River construit cette estimation à partir de données anonymisées de grands opérateurs de nœuds, qui couvrent selon elle plus de la moitié de la capacité, et extrapole le reste. C’est une estimation, pas un comptage.
Le Lightning est-il décentralisé ? Le 9 novembre 2026, les cinq plus grands nœuds publics par capacité, annoncés sous les alias Binance, bfx-lnd0, ACINQ, block-iad-1 et bfx-lnd1, détenaient 1 395,7 BTC à eux cinq. C’est au plus 43 % environ de la capacité publique (calcul à partir de ces chiffres ; un canal entre deux d’entre eux compte aux deux bouts, la part réelle est donc un peu plus basse). Le nœud d’ACINQ avait le plus de canaux, 1 760. N’importe qui peut faire tourner un nœud, mais une grande part de la liquidité se trouve chez des plateformes d’échange et des sociétés de paiement.
Utiliser le Lightning Network : custodial, non custodial ou nœud personnel
Les portefeuilles Lightning se répartissent en trois familles, et la différence décide qui peut perdre votre argent. La distinction générale entre portefeuilles custodial et en auto-conservation est traitée dans notre guide des portefeuilles crypto ; voici ce qu’elle signifie sur le Lightning.
| Type | Qui détient les clés | Ce que vous gérez | Risque principal |
|---|---|---|---|
| Portefeuille custodial | L’entreprise | Rien : un solde de compte | L’entreprise fait faillite, gèle les fonds ou quitte votre pays |
| Portefeuille non custodial avec un LSP | Vous, sur votre téléphone | Une sauvegarde ; le fournisseur gère canaux et liquidité pour vous | Perte de la sauvegarde ; indisponibilité du fournisseur ; frais de liquidité |
| Votre propre nœud | Vous | Canaux, liquidité, sauvegardes, mises à jour, disponibilité | Bogues, logiciel non mis à jour, erreurs lors des fermetures forcées |
Deux épisodes datés montrent le poids de la réglementation sur les deux premières familles. Le 24 novembre 2023, Wallet of Satoshi, un portefeuille Lightning custodial très utilisé, a retiré son application des boutiques américaines et annoncé qu’il ne servirait plus les clients américains ; les utilisateurs pouvaient retirer leurs fonds, et l’entreprise n’a donné aucune raison (The Block, 24 novembre 2023, en anglais). Le 26 avril 2024, ACINQ a annoncé que son portefeuille non custodial Phoenix quitterait les boutiques américaines le 3 mai 2024, en invoquant un doute sur la possibilité que les fournisseurs de portefeuilles en auto-conservation, les fournisseurs de services Lightning, voire les nœuds Lightning, soient traités comme des prestataires de services monétaires (No BS Bitcoin, 26 avril 2024, en anglais).
Le texte américain à l’origine de ce doute est la doctrine FIN-2019-G001 du FinCEN, datée du 9 mai 2019. Elle dit que « hosted wallet providers are account-based money transmitters » (les fournisseurs de portefeuilles hébergés sont des transmetteurs de fonds fondés sur des comptes), alors qu’une personne qui utilise un portefeuille non hébergé pour acheter des biens ou des services pour elle-même n’en est pas un (doctrine du FinCEN, mai 2019, en anglais). Le texte ne mentionne pas le Lightning. Un portefeuille Lightning custodial correspond à sa description d’un portefeuille hébergé ; son application aux LSP et aux nœuds de routage est précisément l’incertitude que pointait ACINQ.
Dans l’Union européenne, conserver des crypto-actifs pour le compte de clients est un service qui exige un agrément au titre de MiCA, et la période transitoire a pris fin le 1er juillet 2026 en France et en Italie. Un portefeuille Lightning custodial qui sert des résidents de l’UE entre dans ce périmètre ; un portefeuille dont les clés restent sur votre appareil ne détient rien pour vous. Notre guide de MiCA explique comment vérifier un prestataire dans le registre de l’ESMA.
Le Salvador a mené la plus grande expérience étatique de paiements quotidiens en bitcoin, et sa leçon porte surtout sur les portefeuilles et l’adoption. Quand la loi Bitcoin est entrée en vigueur en septembre 2021, le gouvernement a distribué l’équivalent de 30 dollars en bitcoin par son portefeuille public, Chivo. Selon le FMI, les enquêtes au plus fort du projet montraient que seules 20 % des entreprises acceptaient le bitcoin et que 4,9 % des ventes étaient payées avec. Dans le cadre de l’accord de 40 mois avec le FMI, d’environ 1,4 milliard de dollars et approuvé le 26 février 2025, la loi a été modifiée pour rendre l’acceptation facultative pour le secteur privé, les impôts se paient uniquement en dollars, et la participation publique à Chivo devait cesser d’ici la fin de juillet 2025 (rapport pays 25/58 du FMI, en anglais).
Là où le Lightning fait encore mal en 2026
Ce réseau fonctionne bien pour ce pour quoi il a été conçu : des paiements fréquents, de petits à moyens, entre des parties connectées. En dehors de cette zone, la conception montre son prix.
Quelqu’un doit rester en ligne. Un partenaire de canal hors ligne ne peut ni recevoir, ni relayer, ni attraper un pair tricheur, sauf si une tour de guet le fait. Les portefeuilles mobiles masquent cela en déléguant à leur fournisseur, ce qui réintroduit un tiers de confiance. Les gros paiements sont plus difficiles que les petits, car chaque saut de l’itinéraire doit avoir assez de liquidité du bon côté ; le fractionnement aide, mais quelques centaines de dollars passent plus facilement que des dizaines de milliers.
Le dispositif s’appuie aussi sur le mempool. En octobre 2023, le développeur Bitcoin Antoine Riard a révélé le « replacement cycling » (cycle de remplacement), une attaque dans laquelle un pair malveillant se sert du remplacement par frais pour chasser la transaction HTLC urgente d’un nœud des mempools des mineurs jusqu’à l’expiration d’un verrou temporel, puis réclame les fonds (The Block, 23 octobre 2023, en anglais). Eclair, LND et Core Lightning avaient déjà livré des parades, surtout la rediffusion de ces transactions, et aucune attaque utilisant cette méthode n’avait été signalée. Riard lui-même doutait que les correctifs arrêtent des formes plus avancées de l’attaque.
Le point le plus douloureux de 2026 est le logiciel. Le 11 août, Lightning Labs a publié dix avis de sécurité sur LND, dont trois classés élevés ; une prépublication de Saurabh Kumar, de Bitcoin Data Labs, estimait que 550 nœuds LND publics, soit 14,9 % des nœuds LND actifs, tournaient ce jour-là sur une version exposée, et que 71 % de ce groupe l’étaient encore le 13 octobre. La part est calculée sur le groupe exposé, pas sur le réseau, et aucun vol lié à ces failles n’a été signalé (notre article sur les nœuds LND non corrigés). En octobre, ACINQ a livré Eclair v0.14.4 pour que des pages web ne puissent plus envoyer de commandes à un nœud via le navigateur de son propriétaire (notre article sur le correctif d’Eclair).
Novembre a ensuite apporté deux alertes venues de la couche applicative. BTCPay Server a demandé le 1er novembre à ses opérateurs d’arrêter leurs serveurs après des signalements de portefeuilles chauds vidés ; son fondateur Nicolas Dorier a indiqué que les cas semblaient concerner des versions antérieures à la 2.4.2 (notre article sur l’alerte de BTCPay Server). Le 8 novembre, LNbits a demandé à tous ses opérateurs d’arrêter les leurs ; un opérateur a déclaré avoir perdu 2 285 545 sats, et le matin du 9 novembre aucune version corrigée n’était publiée (notre article sur l’arrêt de LNbits). Aucun de ces deux projets n’est le protocole Lightning : BTCPay est un outil d’encaissement et LNbits un serveur de portefeuilles, tous deux posés au-dessus de nœuds. Pour celui dont les sats dorment sur ces serveurs, la nuance change peu de chose.
Le fil rouge est qu’un nœud Lightning est un portefeuille chaud qui doit rester en ligne, connecté et à jour. La même prépublication a constaté que les nœuds LND se mettent à jour quand des plateformes comme Umbrel livrent une nouvelle version, plutôt que quand un avis de sécurité paraît. Faire tourner votre propre nœud, sujet de la prochaine leçon de ce parcours, vous donne la maîtrise des clés et des mises à jour, avec le devoir de les appliquer.
Payer en Lightning et déclarer ses cryptos aux impôts
Sur le plan fiscal, un paiement Lightning est un paiement en bitcoin. La rapidité n’en change pas la nature. Aux États-Unis, l’IRS traite les actifs numériques comme des biens ; payer des biens ou des services avec des bitcoins est donc une cession : vous devez l’impôt sur l’éventuelle plus-value entre le prix d’achat des sats et leur valeur en dollars au moment où vous les dépensez, comme l’explique notre guide de la fiscalité crypto aux États-Unis. Un café acheté en Lightning est, juridiquement, une petite vente de bitcoin suivie d’un achat, et la tenue des comptes vous revient, puisque les portefeuilles en auto-conservation n’envoient aucun formulaire 1099-DA.
Le Royaume-Uni traite lui aussi la dépense de cryptos comme une cession pour l’impôt sur les plus-values, comme le détaille notre guide de la fiscalité crypto britannique. En France comme en Italie, payer avec des cryptos est aussi une cession imposable. En France, la flat tax (PFU) sur les plus-values de 2026 est de 31,4 %, d’après la page crypto de l’administration fiscale (DGFiP) du 17 juillet 2026 (notre guide de la fiscalité crypto en France). L’Italie taxe à 33 % les plus-values crypto réalisées depuis le 1er janvier 2026, contre 26 % auparavant, selon la brochure de l’Agenzia delle Entrate sur la loi de finances 2025 (Agenzia delle Entrate, en italien). Les portefeuilles Lightning exportent rarement un historique propre avec la valeur de chaque paiement : tenez votre propre registre dès le départ. Rien de tout cela n’est un conseil fiscal.
