Vendre sur Nostr : les places de marché NIP-15 et le commerce natif Bitcoin

NIP-15 est la norme de place de marché de Nostr : un marchand publie une échoppe (kind 30017) et des produits (kind 30018) sous forme d’événements remplaçables, puis règle les commandes par messages directs chiffrés avec Lightning, LNURL, en chaîne, ou une facture externe. C’est puissant mais désormais marqué « non recommandé » au profit de NIP-99. Voici comment ça fonctionne et où ça s’inscrit.

Pour un bitcoineur souverain, l’attrait est évident : une vitrine sans compte de plateforme, sans barrière KYC, et sans entreprise unique qui peut supprimer vos annonces. Votre identité est un npub, votre catalogue vit sur des relais que vous choisissez, et le paiement arrive dans un portefeuille que vous contrôlez. Ce guide parcourt les véritables événements Nostr derrière une échoppe NIP-15, la poignée de main de commande, le paysage des clients, et les compromis honnêtes face à une boutique BTCPay Server plus WooCommerce auto-hébergée. Rien de ceci n’est un plaidoyer pour un rail plutôt qu’un autre — c’est une carte pour que vous choisissiez le bon outil.

Ce qu’est réellement NIP-15

NIP-15 (« Nostr Marketplace ») est l’une des propositions d’amélioration de Nostr (Nostr Improvement Proposals) maintenues sur github.com/nostr-protocol/nips. Elle définit un petit ensemble de kinds d’événements qui, ensemble, décrivent une boutique et font passer une commande du panier à la confirmation. Le gros du travail est fait avec des événements remplaçables paramétrés — des événements dont la dernière version pour un identifiant donné écrase la précédente, de sorte que modifier un prix ou un niveau de stock revient simplement à publier un événement plus récent avec le même tag d.

Les kinds principaux sont :

• 30017 — set_stall : crée ou met à jour une « échoppe » de marchand (une boutique), incluant sa devise et ses zones d’expédition.
• 30018 — set_product : crée ou met à jour un seul produit, lié à une échoppe.
• 30019 — interface de place de marché : permet à une façade de place de marché de personnaliser l’apparence et de regrouper les marchands.
• 30020 — produit aux enchères : un produit vendu par enchères, avec les mises portées en kind 1021 et les confirmations de mise du marchand en kind 1022.

Parce que les échoppes et les produits sont des événements signés par la clé du marchand, ils sont portables. La même échoppe peut être lue par n’importe quel client compatible, répliquée sur de nombreux relais, et vérifiée comme authentiquement la vôtre — aucun « compte » de place de marché ne se tient entre vous et l’acheteur. Cette portabilité est tout l’intérêt de bâtir le commerce sur Nostr plutôt que sur une plateforme hébergée.

À l’intérieur d’un événement échoppe et produit

Le champ content de chaque événement est une chaîne JSON. Une échoppe (kind 30017) porte l’identité de la boutique et sa façon d’expédier. Un produit (kind 30018) référence son échoppe parente et décrit un article. Le tableau ci-dessous liste les champs que la spécification définit.

Deux règles de balisage importent. Le tag d doit être égal à l’id de l’échoppe ou du produit — c’est ce qui rend l’événement remplaçable. Et les produits peuvent porter des tags t pour les catégories, ce qui est la façon dont une interface de place de marché construit des vues de navigation par catégorie. Notez soigneusement la sémantique de quantity : les relais sont à cohérence éventuelle, alors le « stock » est un nombre au mieux que le marchand republie, pas un registre transactionnel. Pour une boutique sur commande vendant du matériel assemblé à la main, une quantity à null est souvent la réponse honnête.

La poignée de main de commande et de paiement

Les annonces sont publiques ; le paiement est privé. NIP-15 fait passer la commande par messages directs chiffrés — historiquement les DM NIP-04 (kind 4), bien que la plupart des clients actuels soient passés aux messages privés NIP-17, emballés en cadeau et résistants à la fuite de métadonnées. Dans les deux cas, la charge utile est un objet JSON avec un champ type qui pilote un échange en trois étapes :

• Type 0 — commande du client. L’acheteur envoie un id, ses name et address, un message optionnel, des coordonnées (nostr, phone, email), un tableau items de product_id + quantity, et le shipping_id choisi.
• Type 1 — demande de paiement du marchand. Le vendeur répond avec l’id de commande, un message, et un tableau payment_options. Chaque option a un type et un link.
• Type 2 — mise à jour du statut de commande. Le vendeur confirme avec l’id de commande, un message, et deux booléens : paid et shipped.

Le tableau payment_options est là où NIP-15 se branche sur la pile Bitcoin plus large. Les types d’option définis sont :

C’est délibérément minimal. NIP-15 n’exécute pas d’entiercement, ne détient pas de fonds, et n’arbitre pas les litiges. Il normalise la conversation ; le règlement se fait sur le rail que le marchand offre. Cela garde le protocole non-dépositaire par défaut, mais cela signifie aussi que les remboursements, les expéditions partielles et les litiges sont gérés d’humain à humain par DM — il n’y a pas de bouton « ouvrir un dossier » de plateforme.

L’étiquette « non recommandé » et le passage à NIP-99

Lisez la spécification aujourd’hui et vous verrez un avertissement franc en haut : NIP-15 est marqué non recommandé, décrit comme « trop compliqué », avec un renvoi vers NIP-99 à la place. C’est la chose la plus importante à savoir avant de bâtir dessus. Les primitives de place de marché fonctionnent encore et les clients les prennent encore en charge, mais le centre de gravité de l’écosystème se déplace.

NIP-99 (« Classified Listings », kind 30402) adopte une vue plus simple : chaque annonce est une petite annonce autonome plutôt qu’un graphe structuré échoppe-et-produit. Elle interopère plus proprement entre les clients Nostr généraux, parce qu’une annonce n’est qu’un autre événement lisible, pas un schéma de boutique sur mesure. Le coût est que vous perdez une partie de la structure de NIP-15 (échoppes explicites, zones d’expédition, la poignée de main de commande typée) et reconstruisez davantage de la logique de paiement vous-même ou vous fiez à votre client pour la fournir.

En pratique : si vous choisissez une pile en 2026, traitez NIP-15 comme une norme fonctionnelle mais héritée et vérifiez ce que votre client choisi utilise sous le capot. Plusieurs ont déjà migré vers NIP-99, ou l’ont superposé. La bonne nouvelle pour un marchand est que ceci est surtout un détail d’implémentation — votre identité npub, vos relais et votre portefeuille de paiement Lightning se reportent quel que soit le kind d’annonce qui l’emporte.

Le paysage des clients

Vous ne fabriquez presque jamais ces événements à la main ; un client le fait. Trois projets valent la peine d’être connus, chacun open-source et crédité aux bâtisseurs de Nostr qui ont fait avancer le commerce marchand.

Shopstr (GPL-3.0, github.com/shopstr-eng/shopstr, en ligne sur shopstr.market) se présente comme une place de marché Nostr mondiale et sans permission pour le commerce Bitcoin. Son README liste un large ensemble de NIP incluant les annonces classées NIP-99, les messages privés NIP-17, les zaps NIP-57, et notamment NIP-60/NIP-61 — un portefeuille d’ecash Cashu intégré et les « nutzaps ». Shopstr penche donc vers le règlement Lightning et Cashu et représente là où la spécification a évolué au-delà du NIP-15 brut.

Plebeian Market (GPL-3.0, PlebeianTech sur GitHub) est l’angle « place de marché auto-souveraine ». Elle est bâtie sur NIP-15, paie par Lightning, et — la partie qui intéresse les bâtisseurs souverains — est auto-hébergeable. Vous pouvez exécuter votre propre instance sur un VPS ou à la maison sur un nœud Umbrel ou Start9, ce qui fait de la place de marché elle-même quelque chose que vous exploitez plutôt que simplement utilisez. Leur modèle achemine les paiements Lightning par un portefeuille Alby vers le vendeur, avec un partage de contribution valeur-pour-valeur optionnel. Leur vision déclarée est de nombreuses petites places de marché gérées par la communauté — « le mycélium du commerce libre ».

LNbits nostrmarket (github.com/lnbits/nostrmarket) est une extension pour la pile LNbits qui implémente le côté marchand de NIP-15. Si vous exécutez déjà LNbits sur votre nœud, elle laisse votre backend Lightning existant agir comme le moteur de commande et de facture de l’échoppe. C’est l’option la plus « boulonner sur mon nœud » des trois.

La lecture honnête : c’est une niche jeune et en mouvement rapide. Les clients vont et viennent, les schémas migrent, et les relais varient en fiabilité. Testez avec de petites annonces à faible enjeu avant de lui confier votre catalogue principal, et gardez la source de vérité de vos produits quelque part que vous contrôlez.

Câbler les paiements : Lightning, zaps, NWC et BTCPay

Les options de paiement de NIP-15 correspondent directement à des outils que vous exécutez peut-être déjà. Les options ln et lnurl sont satisfaites par n’importe quel nœud Lightning ou service LNURL ; l’option btc par n’importe quel portefeuille qui peut vous remettre une adresse fraîche ; et l’option url par une page de facture hébergée.

Cette option url est le pont naturel vers BTCPay Server. BTCPay est une infrastructure de facturation auto-hébergée et non-dépositaire : il génère une page de paiement, surveille le paiement Lightning ou en chaîne, expose l’API Greenfield pour l’automatisation, et vous donne des reçus, des exports comptables et un outillage de remboursement que la messagerie NIP-15 brute n’a pas. Un marchand peut répondre à une demande de paiement de Type 1 avec un url pointant vers une facture BTCPay et obtenir une comptabilité de niveau exécution tout en vendant par une échoppe Nostr. C’est une séparation propre des responsabilités — Nostr pour la découverte et la conversation de commande, BTCPay pour le règlement et les registres.

Deux autres pièces complètent un montage souverain. Les zaps (NIP-57) ne sont pas un mécanisme de paiement mais sont utiles pour les pourboires, la valeur-pour-valeur, et l’amorçage d’une réputation autour de votre npub. Et Nostr Wallet Connect (NIP-47) laisse un client demander des factures à, ou payer par, votre propre nœud sans remettre les clés — le même motif de style signature-à-distance qui garde la garde chez vous. Si vous ne l’exécutez pas déjà, notre guide Nostr Wallet Connect couvre comment cette poignée de main fonctionne et pourquoi elle importe pour garder les paiements sous votre contrôle.

Quand une échoppe Nostr a du sens — et quand une boutique auto-hébergée en a

C’est la question qui importe vraiment, et la réponse est « ça dépend de votre modèle de menace et de votre catalogue ». Les deux rails sont légitimes ; aucun n’est universellement meilleur. Une échoppe NIP-15 et une boutique WooCommerce + BTCPay auto-hébergée optimisent des choses différentes.

Alors une échoppe Nostr gagne sa place quand la résistance à la censure et l’annonce sans permission sont la priorité, quand vos acheteurs sont déjà natifs de Nostr, quand le catalogue est petit ou numérique, et quand une exécution manuelle et conversationnelle est acceptable. Une boutique WooCommerce + BTCPay auto-hébergée gagne sa place quand vous avez besoin d’un inventaire faisant autorité, d’une vraie automatisation de taxe et d’expédition, d’une découvrabilité par moteur de recherche, et d’un paiement que votre client le moins technique peut compléter — tout en gardant l’auto-garde de chaque sat par BTCPay. La plupart des marchands sérieux reconnaîtront leur propre boutique dans la colonne de droite pour le volume quotidien.

Un hybride pragmatique pour les marchands souverains

Ces rails ne sont pas mutuellement exclusifs, et la posture la plus résiliente utilise les deux. Gardez votre catalogue faisant autorité, votre inventaire et votre comptabilité sur une pile que vous exécutez — une boutique auto-hébergée réglant par BTCPay — et traitez une échoppe Nostr comme une vitrine secondaire résistante à la censure et un canal de portée. Annoncez un sous-ensemble sélectionné sur Nostr, pointez l’option de paiement url de NIP-15 vers vos factures BTCPay, et vous obtenez la découvrabilité et la maturité opérationnelle d’une vraie boutique plus une présence répliquée sur les relais qu’aucune plateforme unique ne peut éteindre.

Cette pensée en couches est le même principe derrière tout notre travail de souveraineté et l’argument plus large pour l’auto-hébergement de votre propre infrastructure : chaque outil retire une dépendance de plus à la permission. NIP-15 ne remplacera pas une boutique bien gérée, et il n’en a pas besoin. Il ajoute une trappe d’évasion souveraine — et le crédit en revient à fiatjaf et aux contributeurs de Nostr, aux équipes de Shopstr et de Plebeian Market, aux mainteneurs de BTCPay, et aux développeurs de Lightning et de Cashu dont il assemble le travail.

Foire aux questions

NIP-15 est-il encore sûr pour bâtir en 2026 ?

Il fonctionne et les clients le prennent encore en charge, mais la spécification elle-même est maintenant marquée « non recommandé » et oriente les bâtisseurs vers NIP-99. Si vous commencez aujourd’hui, vérifiez quelle norme d’annonce votre client choisi utilise réellement et attendez-vous à ce que NIP-99 continue de gagner du terrain. Votre identité npub, vos relais et votre portefeuille de paiement se reportent de toute façon, alors le risque de migration est surtout un détail d’implémentation plutôt qu’un verrouillage.

Dois-je abandonner l’auto-garde pour vendre sur Nostr ?

Non. NIP-15 ne détient jamais vos fonds. Les options de paiement se résolvent en une facture Lightning, un point d’accès LNURL, une adresse en chaîne, ou une page externe comme une facture BTCPay — qui peuvent toutes régler directement vers un portefeuille ou un nœud que vous contrôlez. Le protocole normalise la conversation de commande, pas la garde, alors garder vos clés dépend entièrement de votre montage.

Quelle est la différence entre NIP-15 et NIP-99 ?

NIP-15 modélise une boutique structurée : une échoppe (kind 30017) avec des produits (kind 30018) et un flux de messages commande/paiement/statut typé. NIP-99 (kind 30402) traite chaque annonce comme une seule petite annonce autonome, ce qui est plus simple et interopère mieux entre les clients Nostr généraux. NIP-99 échange une partie de la structure intégrée de NIP-15 contre une compatibilité plus large, ce qui explique pourquoi plusieurs clients ont migré.

Comment BTCPay Server s’intègre-t-il à une place de marché Nostr ?

BTCPay se glisse dans l’option de paiement url de NIP-15. Le marchand répond à la commande d’un acheteur avec un lien vers une facture BTCPay auto-hébergée et non-dépositaire qui surveille le paiement Lightning ou en chaîne et fournit des reçus, des remboursements et des exports comptables. Vous obtenez Nostr pour la découverte et la poignée de main de commande, et BTCPay pour un règlement et une comptabilité de niveau exécution.

Devrais-je remplacer ma boutique WooCommerce par une échoppe Nostr ?

Pour la plupart des marchands, non — elles se complètent. Une boutique auto-hébergée vous donne un inventaire faisant autorité, une automatisation de taxe et d’expédition, et une découvrabilité par moteur de recherche qu’une échoppe basée sur les relais ne peut pas encore égaler. Une échoppe Nostr ajoute la résistance à la censure et une portée sans permission. Un motif courant est de garder la boutique comme source de vérité et d’exploiter une échoppe Nostr comme vitrine secondaire, plus difficile à déplateformer, qui règle par le même backend BTCPay.

Les acheteurs peuvent-ils payer sans compte Nostr ?

Pour passer une commande NIP-15, l’acheteur a généralement besoin d’un client Nostr parce que le paiement se fait par messages directs chiffrés liés à sa clé. C’est une vraie friction comparée à un paiement web familier. Si votre public n’est pas natif de Nostr, une vitrine conventionnelle convertira mieux ; réservez l’échoppe Nostr aux acheteurs qui vivent déjà dans l’écosystème ou qui valorisent spécifiquement la résistance à la censure.