Lightning Network : canaux, routage, HTLC, LSP, état 2026

Bitcoin a un problème de scalabilité connu depuis ses origines. La blockchain traite environ 7 transactions par seconde dans son fonctionnement nominal, là où Visa en traite 1 700 en pic. Pendant les pics d'activité, les frais grimpent, les transactions s'accumulent dans le mempool, et payer un café à 4 EUR peut coûter 8 EUR de frais.

Cette tension a divisé la communauté en 2017 : augmenter la taille des blocs, ou construire une couche au-dessus qui scale autrement ? La réponse historique a été la seconde, avec Lightning Network. L'idée : ouvrir un canal de paiement entre deux parties, échanger des sats hors-chaîne autant qu'on veut, et ne toucher la blockchain qu'à la fermeture du canal. Frais quasi nuls, finalité instantanée, capacité limitée seulement par les fonds engagés dans les canaux.

Cet article explique le cadre théorique de Lightning, la mécanique des canaux et du routage, la différence entre node custodial et non-custodial, le choix d'un wallet adapté (Phoenix, Muun, Aqua, Wallet of Satoshi), et les limites résiduelles (liquidité entrante, fermeture forcée, watchtowers, confidentialité limitée).

Le problème : Bitcoin ne scale pas en l'état

Pour comprendre Lightning, il faut comprendre les contraintes structurelles de Bitcoin on-chain.

Un bloc toutes les 10 minutes. Le protocole Bitcoin règle la difficulté pour qu'un bloc soit miné en moyenne toutes les 10 minutes. Pas négociable : c'est inscrit dans le consensus. Chaque bloc fait au maximum ~1 Mo de transactions utiles (un peu plus avec SegWit, mais l'ordre de grandeur tient). Cela donne mécaniquement une capacité de l'ordre de 7 transactions par seconde en moyenne longue durée.
Files d'attente quand l'activité dépasse 7 TPS. Lors de pics (rallye haussier, événement géopolitique, rush d'inscriptions Ordinals), 20 ou 50 TPS arrivent dans le mempool, qui ne se vide pas assez vite. Les mineurs priorisent les transactions qui paient le plus de frais, les autres attendent. Frais qui atteignaient 100 EUR par transaction lors des pics 2021-2024, redescendus à 1-10 EUR en 2026 hors pics, mais structurellement non bornés.
Impossible à scaler en augmentant la taille des blocs sans contrepartie. Doubler la taille des blocs double la capacité TPS, mais double aussi l'espace disque et la bande passante requis pour faire tourner un nœud. À un certain seuil, seuls les data centers peuvent faire tourner un nœud, et Bitcoin devient centralisé. Cette ligne rouge a fixé la communauté en 2017.

La solution conceptuelle adoptée a deux propriétés clés.

Déplacer les paiements quotidiens hors-chaîne. Pour payer un café, on ne touche pas à la blockchain. La transaction se fait sur une couche au-dessus, qui peut traiter des millions de TPS. La blockchain ne sert que de filet cryptographique : si la couche 2 dysfonctionne, on peut toujours revenir à la blockchain pour récupérer ses fonds.
Garder Bitcoin comme garantie cryptographique. Pas de nouveau token, pas de pré-mine, pas d'altcoin. Les bitcoins sur Lightning sont 100 % adossés à des bitcoins on-chain. L'ouverture d'un canal verrouille les bitcoins sur la blockchain, la fermeture les libère. La couche 2 n'émet rien, elle ne fait que déplacer la temporalité des règlements.

Concrètement, ce que cela permet en 2026.

Capacité quasi illimitée par paire de nœuds. Deux personnes qui ont un canal entre elles peuvent s'échanger des millions de paiements en quelques heures, à frais quasi nuls et finalité 2 secondes.
Frais découplés du montant. Payer 10 EUR ou 1 000 EUR coûte les mêmes ~0,001 EUR de frais Lightning, là où une transaction on-chain coûte la même chose en frais peu importe le montant aussi mais beaucoup plus cher en absolu.
Plus de mempool pour les paiements quotidiens. La blockchain ne voit que les ouvertures et fermetures de canaux, pas chaque paiement intermédiaire. Allègement énorme sur la blockchain elle-même.

Le compromis : ce n'est pas du Bitcoin on-chain. Cela ressemble à du Bitcoin, c'est garanti par du Bitcoin, mais le modèle de sécurité, les risques et les opérations diffèrent. C'est ce qu'explique la suite.

Le canal de paiement : la brique élémentaire

Lightning n'est pas un réseau abstrait. C'est un ensemble de canaux de paiement entre paires de nœuds. Comprendre un canal suffit à comprendre Lightning.

Imaginez deux personnes, Alice et Bob, qui vont s'échanger des paiements régulièrement. Plutôt qu'écrire chaque échange sur la blockchain (10 minutes, 3 EUR de frais à chaque fois), elles ouvrent un canal entre elles. Le canal vit en quatre phases.

Funding transaction. Alice et Bob créent ensemble une transaction on-chain qui verrouille des bitcoins dans un UTXO multisig 2-of-2 contrôlé par eux deux. Disons Alice met 500 000 sats, Bob met 500 000 sats, total 1 000 000 sats verrouillés. Cette transaction est diffusée sur la blockchain, attend 3 à 6 confirmations, et le canal est officiellement ouvert. C'est la seule transaction on-chain à l'ouverture.
Commitment transactions. Pendant la vie du canal, à chaque paiement, Alice et Bob s'échangent des commitments. Un commitment est une nouvelle transaction signée mais pas diffusée qui dépense la funding transaction. Elle dit « si on ferme maintenant, Alice a tant et Bob a tant ». À chaque paiement, ils s'envoient un nouveau commitment qui reflète la nouvelle balance. Si Alice paie 50 000 sats à Bob, le nouveau commitment dit « Alice 450 000, Bob 550 000 ». Aucun de ces commitments ne touche la blockchain : ils restent dans les mémoires des deux nœuds.
Mise à jour permanente. Au prochain paiement (Bob rend 10 000 sats à Alice), un nouveau commitment dit « Alice 460 000, Bob 540 000 ». Et ainsi de suite, des millions de fois si nécessaire. La mécanique de révocation garantit que l'ancien commitment ne peut plus être diffusé : si Alice tente de diffuser un vieux commitment qui lui était favorable, Bob peut « punir » en récupérant la totalité des fonds du canal. C'est ce qui rend la mise à jour off-chain sûre.
Closing transaction. Quand Alice et Bob veulent fermer leur canal (ou quand l'un veut récupérer ses fonds), l'un des deux diffuse le dernier commitment signé sur la blockchain. La blockchain confirme la transaction, les bitcoins du multisig 2-of-2 sont libérés selon la dernière balance. Une fermeture coopérative (les deux d'accord) prend 1 transaction. Une fermeture forcée (un seul, parce que l'autre est offline) prend plus de temps avec un délai de sécurité (typiquement 144 blocs, ~24 h) qui permet de détecter une tentative de fraude.

Trois propriétés clés de cette mécanique à retenir.

2 transactions on-chain seulement. Ouverture + fermeture. Entre les deux, des millions de paiements possibles pour le coût de 2 transactions on-chain. C'est le gain de scalabilité.
Pas de confiance requise. Alice et Bob ne se font pas confiance. La mécanique cryptographique (multisig 2-of-2, révocation) garantit que ni l'un ni l'autre ne peut tricher. Si Alice essaie de partir avec tous les fonds en diffusant un vieux commitment, Bob a 144 blocs pour réagir et la punir.
Capacité bornée par le funding. Le canal Alice-Bob avec 1 million de sats locked permet d'échanger au maximum 1 million de sats dans une direction. Si Alice a déjà tout envoyé à Bob, le canal est « épuisé » côté Alice et elle ne peut plus envoyer sans rééquilibrage ou réouverture.

Le canal Alice-Bob marche bien si Alice et Bob s'échangent souvent. Mais on ne va pas ouvrir un canal avec chaque commerçant qu'on rencontre. C'est là qu'intervient le routage entre nœuds.

Le routage par hops : payer sans canal direct

Si Alice doit ouvrir un canal direct avec chacun de ses interlocuteurs (le boulanger, le restaurant, le freelance brésilien, le serveur Patreon), elle ouvre 50 canaux par mois, paye 150 EUR de frais on-chain, et le système ne tient pas. Le génie de Lightning, c'est que les paiements se routent à travers le réseau existant.

Imaginez le scénario suivant. Alice a un canal avec Carol. Carol a un canal avec Dave. Dave a un canal avec Bob, à qui Alice veut payer 50 000 sats. Alice et Bob n'ont pas de canal direct, mais le chemin Alice → Carol → Dave → Bob existe. Lightning route le paiement par ce chemin en quelques secondes.

Mécaniquement, le paiement à plusieurs hops se passe ainsi.

Découverte du chemin. Le wallet d'Alice (ou son LSP) consulte la topologie publique du réseau Lightning (graphe de tous les canaux et nœuds connus, mis à jour via le « gossip protocol » qui propage les annonces de canaux). Il calcule un chemin entre son nœud et celui de Bob qui ait suffisamment de liquidité dans la bonne direction.
Construction du paiement. Alice paye Carol 50 000 sats + petite commission. Carol paye Dave 50 000 sats + petite commission (un peu moins). Dave paye Bob exactement 50 000 sats. À chaque hop, le nœud intermédiaire garde une fraction (typiquement 0,01 à 1 sat par paiement) comme rémunération pour le service de routage.
Atomicité par HTLC (détail à la section suivante). Soit tout le chemin réussit et chaque commitment est mis à jour, soit rien ne se passe et chacun garde ce qu'il avait. Pas de scénario intermédiaire où Carol garde les fonds d'Alice sans transférer à Dave.
Confirmation. Le wallet de Bob notifie Alice via le chemin inverse que le paiement est reçu. Total : 2 à 5 secondes pour 3 hops. Frais cumulés typiques : 0,001 à 0,01 EUR.

Le « gossip protocol » qui maintient la topologie publique est un point clé. Tous les nœuds Lightning publics annoncent leurs canaux ouverts (capacité totale, frais, politique). Ces annonces se propagent entre nœuds. En 2026, n'importe quel wallet Lightning a une vue complète du graphe : ~18 000 nœuds publics, ~85 000 canaux, mis à jour quasiment en temps réel.

Trois questions pratiques que cette mécanique soulève.

Combien de hops en moyenne ? En 2026, le réseau est suffisamment dense pour que 3 à 5 hops suffisent dans la grande majorité des cas. Au-delà, la probabilité d'échec de routing augmente, et les wallets cherchent un chemin alternatif.
Comment garantir la privacy ? Les nœuds intermédiaires ne connaissent que le hop précédent et le hop suivant, pas l'origine ni la destination du paiement. C'est le principe de l'onion routing (similaire à Tor). Carol sait qu'Alice lui paye 50 000 sats à transmettre, mais ne sait pas que c'est pour Bob.
Que se passe-t-il si un hop est offline ? Si Dave est offline au moment du paiement, le routing échoue après un timeout court (typiquement 30 secondes). Le wallet d'Alice essaye un autre chemin si disponible. Si aucun chemin n'est trouvé, le paiement est annulé, les fonds restent chez Alice. Aucune perte.

HTLC : la garantie atomique du paiement

Le routage par hops soulève une question évidente : quand Alice paye Carol pour transmettre à Dave qui paye Bob, comment être sûr que Carol ne va pas garder l'argent sans transmettre ? Et comment être sûr que Dave ne va pas faire pareil ? La réponse est un mécanisme cryptographique appelé HTLC : Hash Time-Locked Contract.

Le principe en deux temps.

Phase de verrouillage. Bob (le destinataire final) génère secrètement une valeur aléatoire R, et calcule son hash H = SHA256(R). Il envoie H à Alice via un canal séparé (par exemple dans l'invoice BOLT11). Alice construit un HTLC qui dit à Carol : « voici 50 050 sats, tu peux les réclamer en révélant un R tel que SHA256(R) = H ». Carol fait pareil avec Dave : « voici 50 010 sats, tu peux les réclamer en révélant un R tel que SHA256(R) = H ». Dave fait pareil avec Bob : « voici 50 000 sats, tu peux les réclamer en révélant un R... ».
Phase de révélation. Bob, qui connaît R (il l'a généré), le révèle à Dave pour réclamer ses 50 000 sats. Dave a maintenant R, ce qui lui permet de réclamer ses 50 010 sats auprès de Carol. Carol révèle R à Alice pour réclamer ses 50 050 sats. Et voilà, le paiement remonte atomiquement la chaîne : soit la cascade complète a lieu, soit rien.

Et si Bob ne révèle pas R ? C'est là qu'intervient le « Time-Locked » du HTLC. Chaque HTLC a une date d'expiration. Si R n'est pas révélé avant l'expiration, l'HTLC s'annule et chacun récupère ses fonds. Alice ne perd rien si Carol, Dave ou Bob est offline ou hostile.

Trois propriétés cruciales que cette mécanique garantit.

Atomicité totale. Soit tous les nœuds intermédiaires ont reçu leurs commissions, soit aucun ne l'a reçue. Il est mathématiquement impossible que Carol garde 50 050 sats sans que Dave reçoive 50 010, parce que Carol ne peut réclamer ses fonds qu'en révélant R, ce qu'elle ne peut faire que si Dave a reçu et révélé R en aval.
Pas de risque de vol intermédiaire. Aucun nœud intermédiaire ne peut « garder » les fonds qui passent par lui. Le verrou cryptographique est le hash H, et seul Bob le destinataire connaît la pré-image R. Carol et Dave gagnent leur commission s'ils participent honnêtement au routage, et rien sinon.
Échec gracieux. Si Bob est offline ou refuse de révéler R, l'HTLC expire (typiquement après 144 blocs, ~24 h), les fonds reviennent à chaque émetteur, et Alice peut réessayer un autre chemin. Pas de perte sèche.

Une limitation pratique des HTLC : la liquidité bloquée pendant l'expiration. Si Alice tente un paiement vers un Bob offline avec un timeout de 144 blocs, ses 50 050 sats sont bloqués 24 h le temps que l'HTLC expire. Pour les paiements de petit montant c'est négligeable, mais pour de gros montants ou des tentatives répétées, ça impacte la liquidité disponible. C'est l'une des raisons pour lesquelles Lightning fonctionne mieux sur des paiements de quelques centimes à quelques milliers d'euros, et moins bien au-delà.

Liquidité entrante, sortante et LSP

Une particularité contre-intuitive de Lightning : la liquidité d'un canal n'est pas symétrique. Comprendre cette asymétrie évite l'erreur classique du « j'ai 100 000 sats dans Phoenix mais je ne peux rien recevoir ».

Reprenons le canal Alice-Bob ouvert avec 1 million de sats. Si Alice a financé l'intégralité (1 000 000 sats de son côté, 0 du côté Bob), alors :

Alice peut envoyer jusqu'à 1 000 000 sats à Bob (sa liquidité sortante).
Alice ne peut rien recevoir de Bob, parce qu'il n'y a pas de sats côté Bob à faire glisser vers elle (sa liquidité entrante est nulle).

Au fur et à mesure qu'Alice envoie à Bob, sa balance côté Alice diminue et celle côté Bob augmente. Si Alice a envoyé 600 000 sats, le canal est maintenant à 400 000 / 600 000. Alice peut encore envoyer 400 000 sats, et elle peut maintenant recevoir jusqu'à 600 000 sats de Bob. La liquidité est dynamique : elle se rééquilibre avec l'usage.

Trois problèmes pratiques que cette asymétrie crée pour un utilisateur normal.

Recevoir un premier paiement. Si vous installez Phoenix et n'avez aucun canal, vous ne pouvez rien recevoir. Il faut d'abord un canal avec une liquidité entrante. Phoenix résout cela automatiquement en ouvrant un canal pour vous au premier paiement reçu (le LSP injecte la liquidité). Avant Phoenix, c'était une friction majeure pour les débutants.
Recevoir un gros paiement. Si vous avez un canal de 200 000 sats sat capacity entrante et qu'on veut vous envoyer 500 000 sats, le paiement échoue. Solution : Phoenix ouvre dynamiquement un nouveau canal plus gros, ou demande à votre LSP de splicer (étendre) le canal existant. Coût en frais on-chain ponctuels.
Envoyer après avoir tout reçu. Si vous avez accumulé 800 000 sats sur Lightning et voulez tous les envoyer, vous risquez un échec de routing partiel à cause de la capacité de canaux disponibles. Solution : envoyer en plusieurs fois, ou attendre que le wallet rééquilibre via swap on-chain.

Pour les utilisateurs grand public, la solution à toutes ces complexités est le LSP (Lightning Service Provider). Un LSP est un nœud Lightning bien connecté qui gère pour vous la liquidité, le routage et les ouvertures de canaux. Trois modèles courants en 2026.

Modèle	Exemple wallet	Comment ça marche	Compromis
LSP intégré au wallet	Phoenix (ACINQ), Aqua (Boltz)	Le LSP ouvre automatiquement les canaux, gère la liquidité entrante, splice si besoin	Simplicité maximale, mais dépendance à un opérateur unique
Wallet custodial pur	Wallet of Satoshi, Cash App	Le wallet ne gère aucun canal côté utilisateur, tout est chez le custodian	Zéro friction utilisateur, mais zéro souveraineté
LSP optionnel (semi-souverain)	Breez, Mutiny, Zeus	L'utilisateur peut choisir son LSP ou en utiliser plusieurs en parallèle	Plus de souveraineté, complexité opérationnelle accrue

Phoenix domine le marché grand public en 2026 grâce à son équilibre : LSP intégré transparent, wallet self-custody (les clés restent sur l'appareil), ouverture de canaux automatique, splice à la volée, restauration via seed phrase. Pour 95 % des utilisateurs, c'est le bon défaut. Pour les utilisateurs avancés qui veulent contrôler leurs canaux, le node personnel reste la voie souveraine (cf. article node Bitcoin).

État du réseau 2026, comparatif et limites

Quelques chiffres pour situer Lightning en 2026.

~18 000 nœuds publics, contre ~16 000 en 2023 et ~12 000 en 2021. Croissance lente mais constante. À cela s'ajoutent un nombre inconnu de nœuds privés (typiquement les nœuds des utilisateurs Phoenix / Aqua, qui ne s'annoncent pas dans le gossip).
~85 000 canaux ouverts, ratio ~4,7 canaux par nœud public en moyenne. Une dizaine de nœuds majeurs (ACINQ, Bitfinex, Wallet of Satoshi, Kraken) concentrent une part importante de la liquidité.
~6 000 BTC de capacité totale (~250 millions EUR au cours 2026), contre ~5 200 BTC en 2023. Croissance corrélée à l'adoption commerçante.
Médiane d'un canal : ~2 millions de sats (~600 EUR), avec une longue traîne : certains canaux dépassent 100 millions de sats (30 000 EUR) pour des nœuds entreprise, beaucoup sont autour de 500 000 sats pour des utilisateurs particuliers.

Tableau récapitulatif des différences pratiques on-chain vs Lightning, utile pour décider à chaque paiement.

Critère	On-chain	Lightning
Délai de finalité	10 à 60 min (1 à 6 confirmations)	2 secondes
Frais typiques	0,30 à 30 EUR selon mempool	0,001 à 0,01 EUR
Capacité par transaction	Illimitée	~50 000 à 5 000 000 sats (15 à 1 500 EUR)
Privacy	Pseudonyme, public sur la blockchain	Onion routing, beaucoup plus privé
Dépendance opérateur	Aucune (juste un nœud Bitcoin)	LSP ou node personnel + canaux à gérer
Wallet doit être online	Non (signature offline possible)	Oui (au moins ponctuellement)
Risque structurel	Faible, modèle Bitcoin mature	Plus jeune, fermeture forcée possible

Six limites actuelles de Lightning à connaître en 2026 pour avoir des attentes réalistes.

Plafonds par paiement. Le réseau gère bien les paiements jusqu'à ~5 millions de sats (~1 500 EUR) en un seul envoi. Au-delà, la probabilité d'échec de routing croît, et il faut splitter le paiement (Multi-Part Payments, MPP) ou basculer on-chain.
Liquidité inégale. Certains nœuds très demandés (ceux des grosses bourses) ont des canaux pleins dans une direction et ne peuvent plus router dans cette direction. Wallet utilise du retry, mais ça ralentit.
Fermeture forcée. Si votre LSP est down, votre wallet peut être obligé de fermer ses canaux on-chain (forced close), avec des frais on-chain supplémentaires et un délai de 24 h. Phoenix gère ça automatiquement mais le frais reste à votre charge.
SCB obligatoire. Static Channel Backup. Sans sauvegarder l'état de vos canaux périodiquement, une perte du téléphone signifie perte des fonds Lightning (la seed phrase ne suffit pas pour Lightning, contrairement à on-chain). Phoenix sauvegarde automatiquement dans iCloud / Google Drive chiffré, mais c'est à vérifier.
Dépendance à l'online. Les commitments doivent être à jour, ce qui demande que votre wallet soit online au moins ponctuellement. Un téléphone perdu pendant 6 mois peut conduire à des fermetures forcées par le LSP, avec frais on-chain.
Privacy imparfaite. Onion routing protège bien la destination des intermédiaires, mais des attaques d'analyse statistique (probing) peuvent identifier des paiements répétés entre deux nœuds. Lightning n'est pas Monero.

Avertissement

Contenu éducatif et informatif uniquement : ni conseil en investissement, ni conseil fiscal ou juridique. Bitcoin comporte des risques importants, dont une forte volatilité et la perte possible du capital investi. Chaque lecteur reste responsable de ses décisions ; en cas de doute, consultez un professionnel qualifié dans votre juridiction.

Pour aller plus loin

Comprendre Lightning ouvre plusieurs portes pratiques. Pour creuser :

Envoyer et recevoir Bitcoin : la mécanique on-chain et Lightning.
Le Lightning Network : la couche 2 des paiements instantanés.
Frais et mempool : lire la congestion et payer le bon prix.
Confirmations Bitcoin : combien attendre selon le montant.
Payer en Bitcoin : reconnaître les QR, choisir la couche.
Accepter Bitcoin en commerçant : terminal, BTCPay, fiscalité.
Satoshis vs Bitcoin : raisonner en sats sans confusion.
Wallets Lightning : choisir entre Phoenix, Muun, Aqua, BlueWallet, Wallet of Satoshi selon votre profil et usage.
Wallet mobile : panorama des wallets mobiles 2026 et ergonomie quotidienne.
Faire tourner son propre nœud Bitcoin : la voie souveraine pour gérer ses propres canaux Lightning sans LSP.
Envoyer et recevoir Bitcoin : la mécanique pratique d'envoyer et recevoir, on-chain et Lightning.

Pour replacer Lightning dans le parcours global :

Utiliser Bitcoin : vue d'ensemble des cas d'usage où Lightning excelle.
Conserver Bitcoin : custody on-chain vs petite trésorerie Lightning au quotidien.