Lightning Labs lance un site dédié au L402 pour les paiements d'agents IA en bitcoin

Lightning Labs, l'entreprise derrière les outils de développement du Lightning Network et responsable principal du Lightning Network Daemon (LND), l'une des implémentations de nœuds Lightning les plus déployées, a annoncé mercredi un site web dédié au L402, positionnant le protocole comme un rail de paiement permettant aux agents d'IA d'effectuer des transactions en bitcoin.

« Avec le L402, les agents peuvent payer en bitcoin et s'authentifier nativement. Pas de comptes, pas d'intermédiaires, pas d'humains impliqués », a déclaré l'entreprise dans son annonce, décrivant le L402 comme « le protocole pour le commerce de machine à machine sur Lightning ».

Le Lightning Network est une solution de mise à l'échelle de deuxième couche construite au-dessus de la blockchain Bitcoin, conçue pour permettre des micro-paiements rapides et à faible coût via des canaux de paiement hors chaîne — des caractéristiques qui correspondent aux modèles de facturation par appel et par jeton courants dans les services d'IA basés sur les API.

Le site est nouveau, pas le protocole

Ce qui est nouveau, c'est le site web, et non le protocole lui-même. L402 — abréviation de Lightning HTTP 402 — existe déjà dans la pile technologique de Lightning Labs. La norme était auparavant connue sous le nom de LSAT (Lightning Service Authentication Token) avant d'être renommée L402. Aperture, une implémentation de la norme, « est utilisée aujourd'hui par Lightning Loop, un service d'échange non dépositaire pour Bitcoin et Lightning », selon la documentation de l'entreprise.

Lightning Loop permet aux utilisateurs de déplacer des fonds entre la couche de base de Bitcoin et les canaux de paiement Lightning sans dépendre d'un intermédiaire de garde.

Conçu pour les agents IA

L402 est décrit comme « la norme pour l'achat et la vente de ressources numériques » qui « permet aux services de facturer des points de terminaison API d'une manière facile à laquelle les agents d'IA peuvent participer », indique la documentation.

Le mécanisme réutilise le code d'état 402 du protocole HTTP, un code de réponse standard initialement réservé à un usage futur dans la spécification HTTP/1.1 (RFC 2616) pour indiquer qu'un paiement est requis pour accéder à une ressource demandée. Le code a été défini dans la spécification originale mais n'a jamais été largement mis en œuvre par les navigateurs ou les serveurs, ce qui le rend disponible pour être réutilisé par des protocoles orientés paiement.

Lorsqu'un client demande un point de terminaison protégé, « le serveur répond avec HTTP 402 Payment Required et un en-tête WWW-Authenticate contenant un jeton et une facture Lightning », et le jeton contient le hachage de paiement de la facture, explique la documentation. Le client paie ensuite la facture Lightning et présente le jeton avec la préimage de paiement pour accéder au point de terminaison.

Le serveur vérifie les deux éléments sans interroger une base de données de paiement — une propriété que Lightning Labs appelle vérification sans état. Cette approche réduit la surcharge d'infrastructure pour les fournisseurs de services.

Une poussée industrielle plus large vers les paiements par agents

Ce lancement intervient alors que plusieurs entreprises développent des outils de paiement conçus pour les agents logiciels autonomes plutôt que pour les utilisateurs humains. Le protocole x402 de Coinbase, qui exploite le même code d'état HTTP sur des rails de paiement basés sur Ethereum, a été transféré à la Linux Foundation avec le soutien de Google, Stripe et Visa. Par ailleurs, Visa a publié un outil de paiement en ligne de commande pour les agents d'IA.

L402 se distingue en acheminant les paiements des agents via le Lightning Network de Bitcoin au lieu de l'infrastructure basée sur Ethereum, en s'appuyant sur le bitcoin comme actif de règlement. La conception sans état du protocole et sa dépendance à la sémantique HTTP existante signifient que les fournisseurs peuvent restreindre l'accès à l'API sans avoir à approvisionner des systèmes traditionnels de gestion de comptes ou de facturation — une différence structurelle par rapport aux modèles classiques de clés API et d'abonnement qui nécessitent généralement l'enregistrement de l'utilisateur et des flux de paiement gérés par des humains.