Un outil MCP qui paie à l’appel via L402

Voici une petite idée qui porte une longue ombre : et si un seul tool dans la boîte à outils d’un agent IA avait une étiquette de prix — et que l’agent le payait, en sats, à chaque fois qu’il l’appelait? Pas un abonnement. Pas une clé API liée à votre identité. Juste un tool qui répond à un 402 Payment Required, prend un paiement Lightning, et s’exécute. C’est ce que vous obtenez lorsque vous placez deux normes ouvertes bout à bout : MCP, la façon dont les agents appellent des tools, et L402, la façon dont Lightning facture le HTTP. C’est là que « posséder son code » rencontre « posséder son argent », et c’est plus réalisable que ça n’en a l’air.

L’idée : un tool MCP avec un prix

TL;DR. Déployez un serveur MCP qui expose un ou plusieurs tools. Placez un mur de péage L402 devant l’endpoint d’appel de tool. Désormais, tout agent IA qui veut appeler votre tool doit d’abord régler une invoice Lightning — pas de compte, pas d’inscription, pas de plateforme au milieu qui prélève une commission. L’agent paie des sats par invocation, la réponse revient, et l’argent atterrit dans un node que vous contrôlez. C’est du pay-per-tool-call, construit entièrement à partir de normes ouvertes.

La plupart des histoires de monétisation pour l’outillage IA finissent au même endroit : s’inscrire, obtenir une clé API, attacher une carte de crédit, espérer que la facture soit raisonnable à la fin du mois. Chacune de ces étapes est un compte que quelqu’un d’autre contrôle et une identité attachée à votre usage. La forme MCP-plus-L402 enlève tout cela. Le « compte », c’est le paiement lui-même. La « clé », c’est la preuve que l’invoice a été payée. Il n’y a rien à révoquer parce qu’il n’y avait rien à accorder.

Deux revendications de propriété, fusionnées en un seul endpoint :

• Possédez votre code — le tool est à vous, le serveur MCP est à vous, la logique s’exécute sur une machine que vous opérez. Aucun gardien de marketplace ne décide si votre tool a le droit d’exister.
• Possédez votre argent — le paiement se règle en Bitcoin sur le Lightning Network, dans un node que vous opérez. Pas de processeur de cartes, pas de calendrier de versements, pas de bureau de rétrofacturation.

MCP, en un paragraphe

Le Model Context Protocol (MCP) est une norme ouverte publiée par Anthropic à la fin de 2024 qui donne aux agents IA une façon propre et structurée d’appeler de vrais tools au lieu de deviner sur des pages web fragiles. Un server MCP annonce une liste de tools — des fonctions nommées qu’un agent peut invoquer, chacune avec un schéma d’entrée typé — et des resources que l’agent peut lire. L’agent (le client MCP) découvre ce qui est disponible, décide quoi appeler, et reçoit des réponses lisibles par machine. On le décrit comme le USB-C de l’IA : un protocole pour que tout agent compatible puisse se brancher sur tout système compatible. Anthropic a publié la spécification en source ouverte, c’est exactement pourquoi un petit opérateur peut implémenter un server et faire en sorte que Claude Code, Codex ou un agent local adossé à Ollama lui parle sans la permission de quiconque. Nous bâtissons sur cette épaule, sans inventer une nouvelle roue.

Pourquoi L402 s’accorde au tool-calling

L402 est un protocole ouvert de Lightning Labs qui combine le code de statut HTTP 402 Payment Required avec une invoice Lightning et un token d’authentification (un macaroon). Le flux est court : un client demande une ressource payante, le server répond 402 avec une invoice et un macaroon, le client paie l’invoice sur Lightning, puis renvoie la requête en portant le macaroon plus le preimage de paiement comme preuve. Preuve valide, la requête s’exécute; pas de preuve, un autre 402. L’implémentation de référence côté server est Aperture, aussi de Lightning Labs. Il n’y a de compte nulle part dans cette boucle.

Regardez maintenant ce qu’est réellement un appel de tool MCP : une requête discrète, autonome, avec des entrées structurées et une réponse structurée. Un appel entre, une réponse sort. Cette granularité est exactement ce que la facturation pay-per-call veut. Vous ne mesurez pas une « session » floue ni un siège mensuel — vous tarifez une seule invocation bien définie. L’ajustement est presque suspectement propre :

• Facturation atomique. Un appel de tool est une unité de travail naturelle, donc une unité de prix naturelle. Une invocation, un micropaiement.
• Pas d’inscription. Les agents ne sont pas des personnes. Ils n’ont pas de boîtes de réception à confirmer, de mots de passe à retenir, ni de documents KYC à téléverser. L402 permet à un appelant non humain de payer et de poursuivre sans rien de tout cela.
• Natif pour les machines. Les deux extrémités sont du logiciel. Un agent qui parle MCP peut être branché pour payer une invoice Lightning et réessayer — aucun humain dans la boucle qui clique « s’abonner ».
• Portée sans permission. Tout agent qui peut payer peut appeler. Vous ne maintenez pas une liste blanche de clients approuvés; l’invoice est le contrôle d’accès.

La forme de référence : serveur MCP → porte L402 → votre node LN

Réduisez-le à trois couches, toutes les vôtres :

1. Votre serveur MCP. Le tool vit ici — la logique réelle qu’un agent veut exécuter. Il annonce ses tools et schémas via MCP comme tout autre server, sur du matériel que vous opérez à la maison, au bureau, ou dans un Hashcenter.
2. Votre porte L402. Devant l’endpoint du tool payant se trouve une couche L402 — Aperture ou un équivalent — qui répond aux appels non payés par un 402 plus une invoice, et laisse passer les appels payés une fois que le macaroon et le preimage sont validés. C’est le péage.
3. Votre node Lightning. Les invoices sont émises par, et les sats se règlent dans, un node que vous opérez. L’argent ne touche jamais le grand livre d’un dépositaire. Quand l’appel est accepté, le paiement est déjà dans un canal que vous contrôlez.

Le chemin de la requête se lit comme une conversation : l’agent demande d’appeler le tool; la porte dit « ça coûte X sats, voici l’invoice »; le portefeuille de l’agent paie; l’agent redemande avec la preuve; le tool s’exécute; la réponse revient. Rien dans cet échange ne connaît le nom de l’appelant. La porte ne vérifie pas qui vous êtes — seulement que l’invoice a été payée. C’est le même modèle de confiance que Bitcoin nous a enseigné : vérifiez, ne demandez pas la permission.

Ça tourne sur votre serveur, pas sur un mineur

Il vaut la peine de le dire clairement, parce qu’Internet confond constamment les choses : le serveur MCP et ses tools tournent sur du matériel polyvalent que vous possédez — un VPS, une station de travail, un serveur maison, une boîte de node. Ils ne tournent pas sur un ASIC de minage Bitcoin. Un ASIC SHA-256, la puce à l’intérieur d’un S19, S21, ou de tout mineur de classe Antminer, est un moteur de hachage à fonction fixe : il calcule le double SHA-256 des milliards de fois par seconde et littéralement rien d’autre. Il n’a pas de cœurs polyvalents pour héberger un serveur web, une implémentation MCP, ou une quelconque logique de tool. Le mineur et la machine qui sert votre tool sont deux machines différentes, souvent détenues par le même opérateur, jamais le même silicium. La seule chose que votre mineur contribue à cette histoire, c’est qu’il se trouve probablement à côté du node Lightning qui fait le règlement.

Ce que vous pouvez vendre de cette façon

Le modèle brille quand le tool fait quelque chose avec un vrai coût marginal ou une vraie valeur, et quand l’appelant est une machine qui préférerait payer quelques sats plutôt que de négocier un contrat. Quelques exemples honnêtes :

• Une consultation de données dont d’autres agents ont besoin. Un tool qui renvoie un jeu de données de niche, un scrape frais, ou un résultat calculé que vous maintenez — tarifié par requête.
• Une transformation lourde en calcul. Tout ce qui vous coûte du CPU, du GPU ou de la bande passante à exécuter — rendu, conversion, un modèle que vous servez localement — facturé par invocation pour que l’appelant paie ce qu’il consomme.
• L’accès à du matériel que vous opérez. Une action contrôlée contre un appareil ou un service que vous faites tourner, verrouillée pour que seuls les appels payés s’exécutent.
• Une compétence spécialisée. Un tool qui encapsule une logique de domaine que vous avez construite et que vous préféreriez louer par appel plutôt que licencier par siège.

Le fil commun : l’acheteur est fréquemment un autre agent, pas un humain qui remplit un formulaire. C’est le régime où le pay-per-call bat les abonnements sans appel — du logiciel qui paie du logiciel, dans la plus petite unité qui a du sens, sans relation à maintenir de part et d’autre.

Limites honnêtes : précoce, de niche, et vous opérez le node

Nous préférons sous-promettre plutôt que de vous vendre un fantasme. C’est réel et ça fonctionne, mais c’est précoce et c’est de niche. Les frontières honnêtes :

• C’est expérimental. MCP est jeune (fin 2024) et l’outillage L402 mature encore. Les brancher ensemble est un projet à construire soi-même, pas un plug-in à installer. Attendez-vous à lire du code source et à déboguer.
• Vous opérez l’infrastructure. Un node Lightning en auto-garde est le vôtre à opérer — canaux, liquidité, sauvegardes, disponibilité. Si le node est hors service, le tool ne peut pas encaisser. La souveraineté a une facture d’opérations, et vous la payez en attention.
• L’auditoire est petit aujourd’hui. La population d’agents qui peuvent payer de façon autonome une invoice Lightning en plein milieu d’une tâche croît, mais n’est pas grande. Vous bâtissez pour l’endroit où cela se dirige, pas pour un marché de masse qui existe à cette minute.
• Aucune promesse de revenus. Nous décrivons un mécanisme, pas une imprimante à argent. Que quiconque paie pour votre tool dépend entièrement de si le tool vaut la peine d’être payé. Le rail ne crée pas la demande.
• Ça ne tourne pas sur votre ASIC. Dit une fois déjà, répété exprès : un mineur SHA-256 ne peut pas héberger cela. Le serveur est du silicium polyvalent que vous possédez.

Rien de tout cela n’est une raison de le rejeter. C’est la raison de le construire maintenant, pendant que les normes sont ouvertes et que le terrain est assez vide pour qu’un opérateur soigneux puisse apprendre la forme avant que tout le monde n’arrive. Si vous voulez le contexte plus large sur pourquoi ce modèle compte, notre hub Bitcoin × IA cartographie tout le terrain, et l’article sur la boucle de calcul souverain définit le modèle canonique dont cette idée au niveau du tool est une tranche. Pour le cousin côté mineur — exposer un Bitaxe à un agent via MCP — voir le firmware DCENT_axe, dont le propre serveur MCP est une cible de conception planifiée en bêta, pas un téléchargement aujourd’hui. Et si vous préférez piloter des mineurs depuis une ligne de commande ordinaire plutôt que depuis l’intérieur d’un agent, la DCENT_Toolbox est le compagnon CLI en source ouverte.

Questions fréquentes

Que signifie vraiment « un tool MCP qui paie par appel »?

Cela signifie un tool exposé via le Model Context Protocol dont l’endpoint est derrière un mur de péage L402. Avant qu’un agent IA puisse invoquer le tool, il doit régler une invoice Lightning; une fois qu’il présente une preuve de paiement valide, le tool s’exécute et renvoie son résultat. L’agent paie des sats pour chaque appel individuel — pas d’abonnement, pas de compte, pas de clé API liée à une identité.

Qui a créé MCP et L402?

MCP — le Model Context Protocol — est une norme ouverte publiée par Anthropic à la fin de 2024 pour permettre aux agents IA d’appeler des tools structurés. L402 est un protocole ouvert de Lightning Labs qui utilise le code de statut HTTP 402 Payment Required avec une invoice Lightning et un token macaroon pour permettre un accès pay-per-call sans inscription. Aperture est l’implémentation de référence côté server de L402 par Lightning Labs. Nous créditons clairement les deux projets : cette idée, c’est deux de leurs normes ouvertes boulonnées ensemble, rien de plus malin que ça.

Les appelants ont-ils besoin d’un compte ou de KYC pour payer le tool?

Non, et c’est tout le point. L402 transporte la preuve de paiement à l’intérieur de la requête — un macaroon plus le preimage de paiement Lightning — donc il n’y a rien pour quoi s’inscrire et aucune identité à vérifier. Si un appel arrive avec une preuve de paiement valide, il est servi; sinon, il reçoit un 402. Pas de courriel, pas de mot de passe, pas de KYC, de part et d’autre.

Puis-je faire tourner le serveur MCP sur mon mineur Bitcoin?

Non. Un ASIC de minage Bitcoin est une puce SHA-256 à fonction fixe sans cœurs polyvalents — il ne peut pas héberger un serveur web, une implémentation MCP, ni de logique de tool. Le serveur MCP tourne sur du matériel ordinaire que vous possédez, comme un VPS, une station de travail ou un serveur maison. Le même opérateur peut faire tourner à la fois un mineur et le serveur, mais ce sont deux machines différentes, jamais le même silicium. Nous détaillons la différence matérielle dans Peut-on faire tourner de l’IA sur un mineur Bitcoin?

Est-ce prêt pour la production?

Traitez-le comme expérimental. MCP est jeune et l’outillage L402 mature encore, donc brancher les deux ensemble est un projet à construire soi-même, pas un produit prêt à l’emploi. Vous opérez aussi le node Lightning qui encaisse les sats, ce qui est de la vraie infrastructure à faire tourner. Construisez-le parce que les normes sont ouvertes et que le territoire est précoce, pas parce qu’il existe un chemin clé en main — il n’y en a pas encore.

En quoi est-ce différent de vendre du pay-per-inference?

Le pay-per-inference place toute une API de modèle derrière L402; ceci place un seul tool MCP derrière L402. Le mécanisme est le même — invoice Lightning, macaroon, pas de compte — mais l’unité est plus fine. Un endpoint d’inférence vend « demandez n’importe quoi au modèle »; un tool MCP vend un seul appel de fonction spécifique et bien défini. Les deux sont des tranches de la même boucle de calcul souverain : posséder le code, posséder l’argent, facturer en sats sans intermédiaire.