ZkAPI Ethereum : Payer Une API Sans Lier L’identité

Vous avez déjà payé un modèle de langage avec une clé d’API collée à votre carte bancaire. Le fournisseur n’a pas seulement vu la question. Il a vu qui la posait, à quelle heure, dans quel ordre, et combien de fois le même compte revenait. Le 1er octobre 2026, l’Ethereum Foundation a mis en ligne une parade nommée zkAPI. L’idée tient en une phrase : le service peut vérifier que vous êtes solvable sans apprendre quel dépôt vous appartient. Ce n’est pas un slogan marketing. C’est un protocole, un coffre, des preuves, et une frontière de confidentialité que ses auteurs décrivent eux-mêmes comme partielle.

L’annonce est venue de Vittorio Rivabella, côté équipe dAI de la fondation, et le logiciel a été construit avec l’Open Anonymity Project. Derrière le nom, un vieux problème d’infrastructure. Chaque appel payant emporte aujourd’hui une identité. La clé désigne un compte. Le compte désigne un moyen de paiement. Le dossier qui en résulte peut recoller des années d’usage. zkAPI tente de casser ce fil sans obliger l’utilisateur à régler chaque requête sur la chaîne.

Pourquoi une clé d’API n’est jamais neutre

Une clé d’API ressemble à un mot de passe technique. Dans la pratique, c’est un identifiant commercial. Elle ouvre un quota, elle déclenche une facture, elle laisse un journal. Le fournisseur d’intelligence artificielle, le relais RPC, le service d’images ou l’API de données n’a pas besoin de votre nom civil pour vous profiler. Il lui suffit de la continuité du compte.

Le schéma classique est simple. Vous créez un compte. Vous associez une carte, un virement ou un stablecoin nominatif. Vous recevez une clé. Chaque prompt, chaque appel, chaque octet repart vers le même dossier. Au bout de quelques mois, le prestataire détient un historique plus parlant qu’un relevé bancaire : sujets, horaires, volumes, erreurs, reprises. La clé n’authentifie pas seulement la dépense. Elle signe l’usage.

L’alternative naïve, payer chaque requête on-chain, règle le problème d’intermédiaire au prix d’un autre problème. La transaction est lente, chère, et publique. Le graphe des paiements devient un journal lisible par n’importe quel explorateur. On remplace le dossier privé du fournisseur par un dossier public de la chaîne. zkAPI refuse les deux extrêmes. Un dépôt unique alimente un solde privé. Des autorisations sans nom remplacent la clé nominative.

Le fil qui relie le prompt au payeur

Le problème n’est pas théorique. Les interfaces d’IA grand public facturent à l’usage ou à l’abonnement, et les deux modèles exigent un compte. Les API professionnelles font de même, avec une granularité plus fine : tokens entrants, tokens sortants, outils appelés, images générées, secondes de calcul. Chaque ligne de facture est une ligne de comportement.

Pour un développeur isolé, la gêne reste limitée. Pour une entreprise qui envoie des documents internes, un cabinet qui résume des dossiers, un média qui classe des sources, ou un particulier qui formule des questions médicales, le compte devient un concentrateur de secrets. Le prestataire n’a pas besoin d’être malveillant. Une fuite, une réquisition, une revente de journaux anonymisés mal faite, ou un simple employé trop curieux suffit.

La fondation formule l’enjeu sans détour. zkAPI doit permettre de payer des API d’IA et d’autres API avec de l’ETH, et d’effectuer des requêtes impossibles à relier au dépôt. Le service vérifie la solvabilité. Il n’apprend pas quel coffre a financé la session. C’est une séparation des rôles, pas une invisibilité totale.

Pourquoi le paiement requête par requête ne suffit pas

Payer à la requête sur Ethereum a trois défauts structurels. Le premier est le coût. Un appel de modèle peut valoir une fraction de centime. Une transaction de base, même sur une couche secondaire bon marché, reste disproportionnée si elle doit accompagner chaque prompt. Le deuxième est la latence. Un utilisateur n’attend pas une inclusion de bloc pour obtenir une réponse. Le troisième est le graphe. Même si le montant est minuscule, l’adresse qui paie reste visible, et les montants successifs racontent une fréquence.

Les canaux de paiement et les state channels ont déjà tenté de sortir la micro-facturation de la chaîne. Ils exigent en général une relation continue entre deux parties identifiées. zkAPI reprend l’idée du prépaiement, mais remplace l’identité du canal par une preuve. Le serveur apprend qu’une note couvre le montant. Il n’apprend pas laquelle.

zkAPI vous permet de payer des API d’IA et d’autres API avec de l’ETH et d’effectuer des requêtes impossibles à relier. Il sépare l’utilisation des API de votre dépôt sur la chaîne : le service peut vérifier que vous êtes en mesure de payer sans savoir quel dépôt vous appartient.

Ethereum Foundation, présentation du 1er octobre 2026

Quatre temps, du coffre à la clé jetable

Le parcours publié le jour du lancement tient en quatre mouvements. L’application de l’utilisateur parle à un petit client local, avec la même interface qu’avant. Ce client n’envoie pas le prompt au serveur zkAPI. Il envoie une preuve de paiement, sans identité. Le serveur vérifie la preuve et émet une clé d’API neuve, de courte durée, plafonnée en dollars. Cette clé n’existe que dans la mémoire de l’appareil. Les prompts partent ensuite de l’appareil vers le fournisseur d’IA, avec cette clé, et non avec le compte qui a déposé les fonds.

À l’expiration, un reçu signé enregistre la consommation réelle. Le serveur débite le solde privé de ce montant, pas du plafond qui avait été réservé. Le plafond fonctionne donc comme une caution de session. Si vous avez réservé cinq dollars et n’en avez consommé que deux, le reste ne doit pas être brûlé par le simple fait d’avoir ouvert la session. Ce détail change l’économie du protocole : sans reçu de clôture, un plafond trop large pénaliserait l’utilisateur ; avec un reçu, le plafond devient un filet, pas une facture.

Le coffre, lui, est un contrat Ethereum. Ce n’est pas un compte d’entreprise. On peut clôturer le solde et retirer sur la chaîne, même si les serveurs zkAPI disparaissent. Cette propriété de sortie est le point qui distingue un prépaiement custodial d’un crédit adossé à un contrat. Si l’opérateur s’arrête, le dépôt ne doit pas rester prisonnier d’une interface morte.

Ce que voit chaque acteur, et ce qu’il ne voit pas

La séparation est à trois regards. Le serveur zkAPI apprend qu’un paiement valide existe, et le total en dollars de la session. Le fournisseur d’IA apprend les prompts et les réponses, pas qui paie. La chaîne voit les dépôts, les clôtures et les retraits, pas ce que les soldes ont payé. Aucun de ces trois regards ne reconstitue seul le lien complet. C’est le cœur du dessin.

La fondation est explicite sur la frontière. Le protocole ne cache ni l’adresse IP, ni le contenu. Une IP stable permet au serveur de recouper les sessions. Un style d’écriture, un détail personnel, un historique réutilisé dans le prompt peuvent recoller les séances du côté du fournisseur. La parade avancée est double : un circuit Tor neuf à chaque session pour l’adresse, et un modèle local ou un environnement d’exécution de confiance lorsque le texte lui-même est trop parlant.

Autrement dit, zkAPI coupe le lien comptable. Il ne coupe pas le lien réseau, et il ne coupe pas le lien sémantique. Confondre les trois serait survendre le produit. Les auteurs ne le font pas. Le billet suggère Tor. Il assume aussi le compromis des requêtes isolées : plus privées, moins utiles sans contexte.

Groth16, BN254, Poseidon : la mécanique sous le capot

Les preuves de dépense sont vérifiées hors chaîne en Groth16, sur la courbe BN254, avec Poseidon pour les engagements et les nullificateurs. Le choix n’est pas décoratif. Groth16 produit des preuves courtes et une vérification peu coûteuse, au prix d’une cérémonie de configuration spécifique au circuit. BN254 est la courbe historiquement la mieux supportée par les précompiles Ethereum. Poseidon est une fonction de hachage pensée pour les circuits arithmétiques, bien moins lourde à prouver qu’un hachage pensé pour les processeurs classiques.

Les nullificateurs empêchent de dépenser deux fois la même note. Quand une note est consommée, un identifiant unique est révélé. Toute tentative de réutiliser la même note produit le même nullificateur, et le vérificateur refuse. C’est le même geste que dans les systèmes de notes privées déjà connus sur Ethereum : on prouve la connaissance d’un engagement non dépensé, on révèle de quoi empêcher la double dépense, on ne révèle pas l’engagement lui-même.

Le contrat du coffre ne vérifie pas chaque micro-dépense. Il vérifie les preuves au dépôt, à la clôture et en cas de sortie forcée. Le gros du travail de session reste hors chaîne, là où la latence d’un appel d’API est acceptable. La chaîne sert de racine de confiance et de porte de sortie, pas de caisse enregistreuse en temps réel.

Le cahier des charges de février, et ce qui n’a pas été repris

Le dessin date du 11 février 2026. Davide Crapis, responsable IA de la fondation, et Vitalik Buterin publient sur ethresear.ch le fil ZK API Usage Credits: LLMs and Beyond. Cointelegraph en a parlé le lendemain. Le texte vise d’abord l’inférence des grands modèles, là où l’utilisateur envoie des données personnelles. Il élargit ensuite le périmètre : appels RPC Ethereum, génération d’images, calcul, VPN, API de données.

L’exemple du fil est concret. Cent dollars d’USDC déposés. Cinq cents requêtes vers un modèle hébergé. Le fournisseur ne peut pas rattacher ces requêtes au même déposant. Ce n’était pas encore le protocole d’octobre. C’était un cahier des charges. Le lancement transforme ce dessin en implémentation, sans en reprendre toute la mécanique.

Deux pièces du fil de recherche ne figurent pas dans la version mise en ligne. Les nullificateurs de limite de débit, d’une part. Le mécanisme de slashing vers une adresse de brûlage, d’autre part. Leur absence n’est pas un détail de communication. Une limite de débit prouvée empêche un même solde d’ouvrir trop de sessions en parallèle sans révéler l’identité. Un slashing vers une adresse de brûlage punit un comportement abusif sans rendre les fonds à un opérateur identifiable. Le protocole d’octobre vit sans ces deux garde-fous. Il faudra juger, à l’usage, si le plafond de session et le reçu signé suffisent.

La place de zkAPI dans la vision Ethereum et IA

Deux jours avant le fil de recherche, le 9 février 2026, Vitalik Buterin publiait une vision d’Ethereum mêlée à l’intelligence artificielle. Il y plaçait déjà les paiements à connaissance nulle pour des appels d’API, sans lien d’identité, dans le quadrant Infrastructure / Survivre. Crapis n’y figurait pas. Le fil n’était pas encore le sujet. Le quadrant disait pourtant l’intention : ce n’est pas une fonctionnalité de confort, c’est une brique pour que des agents et des utilisateurs continuent d’appeler des services sans se livrer entièrement.

Ce qui change en octobre, c’est que le mécanisme tourne. Une note de recherche peut rester un schéma. Un contrat et un client qui émettent une clé jetable deviennent un objet que l’on peut critiquer, mesurer, abandonner ou étendre. Le passage du quadrant à l’implémentation est le vrai événement. Le reste, la courbe, le hash, le coffre, est la manière de tenir la promesse sans rouvrir le graphe de paiement.

Ce que le prompt révèle encore

Couper le paiement ne rend pas le texte anonyme. Un prompt qui contient un nom de projet interne, une adresse, un extrait de contrat, une question sur un traitement, ou simplement un tic de formulation, réidentifie l’auteur mieux qu’une clé. Les modèles sont doués pour ça. Les journaux du fournisseur aussi, s’ils conservent les entrées.

La parade avancée dans le texte de lancement est un modèle local, ou un environnement d’exécution de confiance, avec une mémoire partagée, plutôt que de tout renvoyer à la main. L’idée est de garder le contexte du côté de l’utilisateur, et de n’envoyer au fournisseur que des requêtes isolées. Le gain de confidentialité est réel. L’utilité baisse, parce qu’un assistant sans mémoire répète, oublie, et force l’utilisateur à recopier le contexte. Le compromis est assumé. Il mérite d’être dit à voix haute : zkAPI ne remplace pas une politique de minimisation des prompts.

Tor, de son côté, traite un autre canal. Une IP stable permet au serveur zkAPI, ou au fournisseur, de regrouper des sessions qui n’ont pourtant pas la même clé. Un circuit neuf à chaque session casse cette continuité réseau, au prix d’une latence et d’une fiabilité que tous les usages ne tolèrent pas. Un VPN commercial réidentifie souvent autant qu’il masque, s’il est lié à un compte. Le billet cite Tor, pas un VPN nominatif. La nuance compte.

Le coffre comme sortie, pas comme compte bancaire

Déposer dans un contrat n’est pas la même chose que créditer un solde chez un prestataire. Le prestataire peut geler, retarder, exiger une pièce d’identité, ou disparaître avec la caisse. Le contrat du coffre, s’il est correctement écrit et si la sortie forcée est réellement exécutable, laisse à l’utilisateur un chemin qui ne dépend pas de l’opérateur. C’est la propriété que le lancement met en avant : on peut clôturer et retirer même si les serveurs zkAPI ne répondent plus.

Cette propriété a un coût de conception. Une sortie forcée doit empêcher la double dépense. Si l’utilisateur retire sur la chaîne un solde qu’une session hors chaîne est en train de consommer, le protocole doit trancher. Les preuves vérifiées à la clôture et en sortie forcée servent à ça. Sans délai, sans nullificateur, sans règle de priorité, le coffre serait un distributeur que l’on peut vider deux fois. Le détail de ces règles n’est pas toute l’annonce. Il sera le point que les relecteurs de contrat iront chercher en premier.

Le choix des actifs, ETH ou USDC, n’est pas neutre non plus. L’ETH expose au mouvement de prix entre le dépôt et la dépense. L’USDC expose à l’émetteur du stablecoin, à une éventuelle liste noire d’adresses, et à la visibilité du transfert d’entrée. Une fois la note créée, le lien vers le dépôt doit être rompu par la construction de la preuve. L’entrée, elle, reste un événement de chaîne. Qui a financé le coffre peut rester observable. Qui a dépensé la note ne doit pas l’être.

Au-delà des modèles : RPC, images, VPN, données

Le fil de février ne s’arrêtait pas aux modèles de langage. Un appel RPC Ethereum révèle quelles adresses vous lisez, quels contrats vous simulez, quels blocs vous suivez. Un service d’images conserve les descriptions. Un VPN commercial voit les destinations. Une API de données voit les séries que vous interrogez. Dans chacun de ces cas, la clé d’API est le fil. zkAPI propose le même geste : prépayer, prouver, recevoir une autorisation courte, ne pas laisser le prestataire recoller l’autorisation au dépôt.

L’usage le plus parlant reste l’inférence, parce que le contenu est intime. L’usage le plus structurel pour Ethereum est peut-être le RPC. Aujourd’hui, interroger un nœud public ou un fournisseur RPC avec une clé, c’est souvent accepter qu’un tiers voie votre graphe de lecture. Des clients légers et des preuves d’état réduisent cette dépendance. Ils ne règlent pas la facturation d’un accès premium. Un crédit d’usage à connaissance nulle est une réponse partielle : le fournisseur sert la requête, il ne sait pas quel dépôt l’a payée.

Pour un VPN ou un relais, la limite d’IP demeure décisive. Payer sans identité ne sert à rien si la session réseau pointe vers la même adresse à chaque fois. Le protocole a donc plus de sens comme couche de paiement que comme couche d’anonymat complète. Il se combine. Il ne remplace pas.

Agents, stablecoins et factures sans compte

Le calendrier n’est pas isolé. Au même moment, des institutions s’inquiètent d’agents logiciels qui paient déjà en stablecoins, et des banques centrales qui voudraient encadrer ces flux. Un agent qui doit ouvrir un compte, passer un contrôle, et conserver une clé nominative n’est pas un agent autonome. C’est un compte déguisé. Un agent qui peut déposer une fois, puis prouver une solvabilité sans révéler la note, se rapproche d’un payeur intermittent.

zkAPI ne résout pas la question de savoir qui est responsable d’un agent. Il retire un obstacle technique : l’obligation de lier chaque appel à une identité de facturation. Pour un portefeuille qui délègue des tâches, pour un bot de recherche, pour un service qui appelle plusieurs modèles selon le prix, la clé jetable est plus cohérente qu’une clé mensuelle. Le plafond en dollars borne le dégât si la clé fuit. La mémoire de l’appareil borne sa durée de vie. Le reçu borne la facture au réel.

Il reste un point de tension. Un agent qui envoie des prompts identifiants recrée le lien que le paiement a coupé. La confidentialité d’un agent se joue autant dans ce qu’il écrit que dans la manière dont il paie. Les deux couches doivent être conçues ensemble, sinon la plus bavarde annule la plus soigneuse.

Ce que le protocole n’achète pas

Il est utile de lister les promesses que zkAPI ne fait pas. Il ne rend pas le contenu du prompt illisible pour le fournisseur. Il ne masque pas l’adresse IP. Il ne garantit pas qu’un style d’écriture ne vous trahisse. Il ne reprend pas, dans la version d’octobre, les limiteurs de débit prouvés ni le slashing vers une adresse de brûlage décrits en février. Il ne transforme pas le fournisseur d’IA en service aveugle. Il transforme le lien de paiement en énoncé vérifiable.

Cette modestie est une force si elle est tenue. Les systèmes de confidentialité meurent souvent d’une phrase de trop. Ici, la phrase juste est celle de la fondation : séparation entre l’usage et le dépôt. Pas anonymat intégral. Pas résistance à un adversaire qui voit à la fois le réseau, le texte et le calendrier. Un adversaire qui ne voit que la chaîne ne relie pas la dépense au dépôt. Un adversaire qui ne voit que le fournisseur ne relie pas le prompt au payeur. Un adversaire qui voit les deux bouts et l’horloge peut encore tenter une corrélation statistique. Le protocole réduit la surface. Il ne l’abolit pas.

Le fournisseur voit les requêtes. La couche de paiement voit la dépense. Aucun des deux ne voit le lien. L’adresse et le texte, eux, restent des fils.

Lecture du périmètre réel de zkAPI

Cette lecture évite deux erreurs symétriques. La première serait de traiter zkAPI comme un mélangeur de prompts. Ce n’en est pas un. La seconde serait de le traiter comme un gadget de communication, sous prétexte que l’IP demeure. Le lien de paiement est précisément celui que les régulateurs, les fraudeurs et les services marketing exploitent le plus facilement, parce qu’il est structuré. Le casser a une valeur propre, même si d’autres liens survivent.

Une session, racontée sans abstrait

Imaginons un dépôt de cent dollars en USDC, l’exemple du fil de février. L’utilisateur envoie les fonds au coffre. Le contrat enregistre un engagement. Côté utilisateur, une note privée représente ce solde. Personne d’autre ne peut la dépenser. Personne d’autre ne devrait pouvoir la relier aux requêtes futures.

L’utilisateur ouvre une session pour un modèle. Le client local construit une preuve : une note approvisionnée couvre le plafond demandé, et son nullificateur n’a pas déjà été vu. Le serveur zkAPI vérifie. Il n’apprend pas l’identité de la note. Il émet une clé courte, plafonnée, stockée en mémoire. L’application envoie les prompts au fournisseur avec cette clé. Le fournisseur facture la clé, pas le coffre.

La session se ferme. Un reçu signé dit que deux dollars ont été consommés sur un plafond de cinq. Le solde privé est débité de deux dollars. Le nullificateur empêche de rejouer la même note. Si l’utilisateur veut sortir, il clôture et retire. Si les serveurs ne répondent plus, la sortie forcée doit permettre le retrait de ce qui n’a pas été consommé de façon prouvable. Cinq cents requêtes peuvent ainsi passer sans que le fournisseur sache que c’est le même dépôt de cent dollars qui les a financées.

Le rôle de l’Open Anonymity Project

La fondation ne présente pas zkAPI comme un logiciel écrit en vase clos. Le protocole a été construit avec l’Open Anonymity Project. Le nom indique l’intention : sortir l’anonymat du statut de fonctionnalité optionnelle pour en faire une couche réutilisable. Un coffre de crédits d’usage peut servir à autre chose qu’à un modèle de langage. La même note, la même preuve, la même clé jetable peuvent théoriquement ouvrir un RPC, un relais, un service de calcul.

Cette mutualisation a un intérêt et un risque. L’intérêt est la réutilisation des circuits, des cérémonies et des clients. Le risque est la contagion. Si un nullificateur ou un paramètre de circuit est partagé trop largement, une faille sur un usage se propage aux autres. Groth16 exige une configuration honnête. Poseidon exige une implémentation sans biais. Le coffre exige une sortie qui ne peut pas être bloquée par l’opérateur. La qualité du projet partenaire compte autant que le nom de la fondation sur l’annonce.

Vitesse, coût, et ce que l’utilisateur ressent

Pour que le protocole sorte du cercle des chercheurs, il doit être invisible. L’application parle au client local avec la même interface qu’avant. C’est le bon critère. Si l’utilisateur doit comprendre un engagement, un nullificateur et une courbe pour poser une question à un modèle, l’adoption restera expérimentale. La preuve doit se construire pendant que l’interface attend, et la clé jetable doit remplacer la clé habituelle sans changer le reste du flux.

Le coût pertinent n’est pas seulement le gaz du dépôt. C’est le temps de preuve sur la machine de l’utilisateur, la taille de ce que l’on envoie au serveur zkAPI, et la fréquence des clôtures. Une preuve Groth16 est courte à vérifier. Elle peut être lourde à produire sur un téléphone. Si la production exige un ordinateur de bureau, le périmètre réel se réduit aux usages professionnels. Le billet de lancement ne donne pas de benchmark public. Ce sera le chiffre qui départagera la démo du produit.

Le plafond en dollars, lui, est une unité que le fournisseur comprend. La chaîne peut parler ETH ou USDC. La session parle dollars, parce que les API d’IA sont tarifées ainsi. La conversion est un point de friction. Qui fixe le cours. Qui encaisse l’écart. Que se passe-t-il si l’ETH bouge pendant une session longue. Le reçu de consommation réelle limite l’exposition, il ne l’efface pas.

Menaces réalistes, au-delà du schéma idéal

Un schéma de confidentialité se juge contre un adversaire précis. Contre un observateur de la chaîne seul, zkAPI tient si la note est bien découplée du dépôt. Contre le fournisseur d’IA seul, il tient si la clé jetable n’est pas réutilisée et si le prompt ne trahit pas. Contre le serveur zkAPI seul, il tient si la preuve ne fuit pas la note et si l’IP est renouvelée. Contre une collusion entre le serveur zkAPI et le fournisseur, la corrélation par le temps et par le montant de session redevient possible. Une session à 4,17 dollars ouverte à 14 h 02 et une facture fournisseur du même montant à 14 h 03 ne prouvent rien isolément. Répétées, elles deviennent un signal.

La clé en mémoire réduit le vol persistant. Elle n’empêche pas un logiciel malveillant sur l’appareil de lire la clé pendant sa vie, ni de lire la note privée si elle est mal stockée. Le protocole déplace la confiance vers le client local. C’est un déplacement sain si le client est auditable. C’est un déplacement dangereux si le client est une boîte noire qui promet l’anonymat.

La sortie forcée, enfin, est un aimant à bugs. Les protocoles de notes privées ont déjà montré que la double dépense, le gel involontaire et la mauvaise gestion des nullificateurs sont les trois familles d’incidents. Un coffre qui promet un retrait même si les serveurs tombent doit être lisible sur ce point. L’annonce décrit l’intention. Le contrat dira si l’intention est tenue.

Régulation, listes et paiement sans nom

Un système qui sépare le paiement de l’identité attire deux lectures. La lecture utile : un journaliste, un patient, une entreprise peuvent interroger un modèle sans constituer un dossier chez le fournisseur. La lecture hostile : un acteur qui veut brouiller une dépense s’en servira aussi. Les deux lectures sont vraies de tout outil de découplage, du liquide aux preuves. Le dessin d’octobre ne crée pas cette tension. Il la déplace vers les API.

L’USDC ajoute une couche. Un émetteur peut geler une adresse. Si le gel intervient avant que la note ne soit formée, le dépôt est exposé. Si le gel ne peut plus atteindre la note une fois engagée, le coffre devient un point de passage que les politiques de liste noire observent à l’entrée et plus à la sortie. Ce point sera discuté. Il ne faut ni le cacher ni le transformer en argument unique. ETH évite l’émetteur, pas la volatilité. USDC évite la volatilité, pas l’émetteur.

Côté européen, les règles sur les transferts et l’identité des prestataires de services sur crypto-actifs regardent surtout les plateformes et les transferts entre acteurs régulés. Un appel d’API payé par une preuve n’est pas, en soi, un transfert vers un exchange. Il peut néanmoins entrer dans le champ si un intermédiaire custodial se place au milieu. Le fait que le coffre soit un contrat, et non un compte d’entreprise, est ici décisif. Un opérateur qui garderait les clés des utilisateurs retomberait dans le modèle que le protocole prétend quitter.

Ce que les développeurs peuvent déjà en tirer

Même sans intégrer le client dès demain, le lancement fixe une interface mentale. Ne plus confondre authentification et facturation. Ne plus laisser une clé vivre des mois. Préférer un plafond court et un débit au réel. Prévoir une sortie si l’opérateur disparaît. Traiter l’IP et le prompt comme des canaux séparés du paiement. Ces cinq règles valent pour un service qui n’utilisera jamais Groth16.

Pour ceux qui intégreront le protocole, le travail utile est ailleurs que dans le slogan. Auditer le circuit. Vérifier que le nullificateur est unique et non réversible. Mesurer le temps de preuve. Tester la sortie forcée en coupant les serveurs. Envoyer des sessions via des circuits distincts. Éviter de réinjecter un identifiant dans le prompt. Documenter ce que le fournisseur voit encore. Un intégrateur qui promet l’anonymat total à ses utilisateurs trahit le protocole plus sûrement qu’un bug.

Comparé aux autres manières de payer sans tout dire

Les cartes prépayées coupent le lien bancaire au prix d’une identité d’achat souvent exigée en amont. Les mixeurs et les pools de confidentialité coupent le graphe de transfert, pas la facture d’API. Les paiements Lightning ou les canaux sur couche secondaire réduisent le coût, mais identifient souvent les deux bouts du canal. Les bons à usage unique, vendus contre du liquide ou une preuve, existent déjà dans d’autres industries. zkAPI est proche de ce dernier modèle, avec une différence : le bon est une preuve que l’on ne peut pas copier, et le solde reste dans un contrat que l’utilisateur peut quitter.

Face à un simple jeton à usage unique vendu par le fournisseur, zkAPI ajoute la vérification sans lien et la sortie non custodiale. Face à un paiement on-chain par requête, il ajoute la vitesse et retire le graphe. Face à un compte classique, il retire le dossier de facturation. Il n’ajoute pas, à lui seul, le chiffrement du prompt de bout en bout. Cette comparaison évite de le ranger dans la mauvaise famille.

Ce que le réseau principal change

Un fil de recherche peut être élégant et rester sans enjeu. Un déploiement que l’on peut appeler change la conversation. Les fonds déposés sont de vrais fonds. Les preuves acceptées ouvrent de vraies clés. Les bugs coûtent. Le 1er octobre 2026 marque ce passage, huit mois après le texte de Crapis et Buterin. Entre les deux, le quadrant de février avait déjà classé l’idée du côté de l’infrastructure de survie. L’implémentation dit que la fondation ne voulait pas laisser ce quadrant à l’état de diagramme.

Le réseau principal n’est pas une bénédiction automatique. C’est un engagement. Les paramètres de circuit, l’adresse du coffre, le comportement du serveur qui émet les clés, la politique de logs : tout cela devient attaquable. La promesse de retrait si les serveurs tombent sera testée le jour où ils tomberont, ou le jour où quelqu’un simulera la panne. Jusque-là, elle reste une propriété annoncée.

Une lecture pour les équipes qui achètent des API

Les entreprises qui envoient des données vers des modèles ont aujourd’hui trois leviers : le contrat juridique, le chiffrement applicatif, et la minimisation. zkAPI en ajoute un quatrième, orthogonal : ne pas laisser la facture devenir un identifiant. Ce levier ne dispense pas des trois autres. Un accord de traitement ne protège pas d’une réquisition. Un chiffrement mal placé laisse le fournisseur lire le prompt en clair, ce qui est le cas normal d’une API d’inférence. La minimisation reste la mesure la plus efficace. Le découplage du paiement réduit ce que le dossier commercial peut recouper ensuite.

Pour une équipe conformité, la question utile n’est pas « est-ce anonyme ». Elle est « quel registre disparaît ». Le registre du fournisseur d’IA ne contient plus le payeur. Le registre de la chaîne ne contient plus l’usage. Le registre réseau et le registre textuel demeurent. Une politique interne peut alors décider : prompts sensibles en local, prompts banals via zkAPI, secrets jamais dans le texte. C’est moins spectaculaire qu’un slogan. C’est utilisable.

Limites assumées, et suite logique

Le texte de lancement assume le compromis des requêtes isolées. Sans mémoire partagée côté serveur, l’assistant est moins bon. Avec une mémoire dans un environnement de confiance, on réintroduit un matériel ou un opérateur à auditer. Avec une mémoire locale, on déplace le contexte sur l’appareil, ce qui est souvent le bon endroit, et l’on n’envoie que des extraits. Aucune de ces voies n’est gratuite. Les nommer évite de croire que la preuve résout le contexte.

La suite logique, si le protocole tient, est l’ajout des pièces laissées dans le fil de février : limites de débit prouvées, sanctions qui ne réidentifient pas, peut-être des circuits plus légers à produire sur mobile. L’autre suite est l’élargissement hors des modèles, vers les RPC et les API de données, là où le contenu est moins bavard et où le gain du découplage est plus net. La troisième suite est culturelle. Tant que les fournisseurs exigeront une clé mensuelle collée à une carte, les utilisateurs n’auront pas le choix. zkAPI n’a de sens que si des services acceptent la clé jetable comme un moyen de paiement valide.

Le 1er octobre ne clôt pas cette négociation. Il fournit un objet. Un coffre. Une preuve. Une clé qui meurt. Un reçu. Une sortie. Le reste, l’IP, le style, le calendrier, reste à la charge de celui qui appelle. C’est moins confortable qu’une promesse d’invisibilité. C’est plus honnête, et c’est déjà une rupture avec l’habitude qui voulait qu’une API ne sache jamais être payée sans savoir par qui.

Pourquoi le moment compte

Les modèles se généralisent plus vite que les pratiques de facturation. Plus l’usage devient intime, plus le dossier attaché à la clé devient sensible. Attendre qu’un standard industriel sépare le paiement de l’identité revient à laisser les comptes actuels accumuler l’historique. L’Ethereum Foundation choisit de proposer la brique pendant que les agents commencent à payer seuls, et pendant que les API restent le tuyau principal vers les modèles hébergés.

On peut juger le choix trop tôt, parce que les pièces de février ne sont pas toutes là. On peut le juger tardif, parce que le problème des clés nominatives a dix ans dans les API classiques. Les deux jugements coexistent. Ce qui est nouveau, c’est la combinaison : prépaiement dans un contrat que l’on peut quitter, preuve que le serveur vérifie sans apprendre la note, clé qui ne survit pas à la session, débit au réel. Cette combinaison n’existait pas comme produit le 10 février. Elle est décrite comme en ligne le 1er octobre.

Pour le lecteur qui ne déploiera jamais un circuit, la conclusion tient en une habitude à perdre. Une clé d’API n’est pas un détail technique. C’est un nom de dossier. zkAPI propose de payer sans donner ce nom au fournisseur, et sans écrire l’usage sur la chaîne. Entre les deux, il reste l’appareil, le réseau et le texte. Ce sont les trois endroits où la confidentialité se joue encore, une fois le paiement découpé.

Le protocole n’efface pas l’historique déjà constitué chez les fournisseurs actuels. Il ne réécrit pas les conditions d’utilisation. Il offre une voie pour les appels suivants, à condition que le service en face accepte une clé qui ne désigne personne. C’est une condition commerciale autant que cryptographique. Sans prestataire compatible, le coffre reste un solde privé sans endroit où le dépenser. Avec quelques prestataires compatibles, il devient une alternative crédible au compte nominatif. Le lancement ouvre cette possibilité. Il ne la garantit pas à l’échelle du marché.

Glossaire minimal pour lire la suite

Une note privée est un solde que seul son détenteur peut ouvrir, représenté par un engagement. Un nullificateur est l’identifiant révélé au moment de la dépense pour empêcher un second usage. Une preuve à connaissance nulle convainc un vérificateur qu’un énoncé est vrai sans révéler les données qui le rendent vrai. Ici, l’énoncé est : une note couvre ce montant et n’a pas été dépensée. Une clé jetable est une autorisation courte, plafonnée, détenue en mémoire, que le fournisseur accepte comme s’il s’agissait d’une clé classique. Le coffre est le contrat qui ancre les dépôts, les clôtures et les sorties.

Avec ces cinq mots, l’annonce du 1er octobre se lit sans folklore. On dépose. On prouve. On reçoit une clé qui meurt. On paie le réel. On peut partir. Le fournisseur garde les prompts. La chaîne garde les entrées et les sorties. Le lien entre les deux n’est plus un champ de base de données. C’est tout zkAPI, et c’est déjà beaucoup, à condition de ne pas lui demander d’être autre chose.