Ethereum Active ZkAPI Pour Payer Les API Sans Identité

Et si la facture d’une requête d’intelligence artificielle pouvait être réglée sans que le service sache qui tient le portefeuille ? Le 1er octobre 2026, la Fondation Ethereum a mis en production sur le réseau principal un dispositif nommé zkAPI, pensé pour payer des interfaces facturées à l’usage sans rattacher chaque appel à une identité. L’annonce, publiée sur le blog de la Fondation, ne décrit pas un prototype de laboratoire : le coffre-fort est déjà actif, les dépôts se font en USDC, et l’autorisation de dépense passe par une preuve cryptographique produite sur l’appareil de l’utilisateur.

Le geste paraît simple. On dépose des crédits une fois. On n’ouvre pas de compte chez le fournisseur. On ne colle pas une clé d’API à un nom, à un e-mail ou à un historique de paiement. Le prestataire voit la requête. Il ne voit pas qui la paie. Cette séparation, longtemps discutée dans les cercles de recherche, sort du papier. Elle arrive au moment où les modèles de langage, les générateurs d’images et les interfaces de calcul se facturent au jeton, à la seconde ou à l’appel.

Derrière le nom, un design déjà connu des lecteurs d’Ethereum Research, signé Davide Crapis et Vitalik Buterin, a été porté en production avec l’Open Anonymity Project. Vittorio Rivabella, membre de l’équipe dAI de la Fondation, a résumé l’intention sans détour : déposer des crédits dans un coffre Ethereum, puis autoriser un usage borné avec des preuves à divulgation nulle de connaissance, au lieu d’une identité. Le reste de l’histoire tient dans les détails que la Fondation assume aussi : l’anonymat n’est pas total, le réseau n’est pas masqué, et le contenu des prompts peut encore trahir.

Ce que le lancement du 1er octobre change vraiment

Jusqu’ici, payer une API ressemblait à ouvrir un compte. Une carte, un solde prépayé, une clé secrète, parfois un plafond mensuel. Le fournisseur reliait l’usage à un client. Les journaux de facturation devenaient un registre de comportement. zkAPI inverse la logique du rattachement. Le paiement est prouvé. L’identité du payeur n’est pas livrée avec la preuve.

La Fondation précise que le système est déjà opérationnel sur le réseau principal d’Ethereum. Un déploiement sur le testnet Sepolia permet d’essayer le circuit sans engager de fonds réels. Cette double présence compte. Elle distingue une démo de conférence d’un contrat que l’on peut appeler avec de vrais crédits. Le coffre, baptisé ZkApiVault, enregistre les dépôts. Les dépenses ultérieures ne repassent pas par une signature qui désignerait le même compte à chaque appel.

Le premier terrain visé est celui des modèles d’IA. Le client local expose les interfaces habituelles d’OpenAI et d’Ollama. Une application déjà écrite peut être pointée vers localhost, sans réécriture du code métier. Le développeur ne change pas sa bibliothèque. Il change l’adresse à laquelle il parle. Le reste, preuve, plafond, clé de courte durée, se joue entre l’appareil et le coffre.

Une facture sans visage, pas une cape d’invisibilité

Il faut poser le mot juste. zkAPI ne promet pas de disparaître d’Internet. Il promet de dissocier le paiement de l’identité. La nuance est le cœur du produit. Beaucoup de lecteurs confondent paiement privé et navigation invisible. Ici, la Fondation écrit noir sur blanc les deux limites : pas d’anonymat réseau, et une fuite possible par le contenu des requêtes.

Autrement dit, le commerçant ne reçoit pas votre nom sur le ticket. Le facteur, lui, peut encore voir la rue. L’adresse IP, l’heure de l’appel, la régularité des sessions restent des signaux. Un prompt qui contient un nom de projet interne, une adresse, un extrait de contrat ou un détail médical peut reconstituer une personne même si le coffre reste muet. La technique cryptographique ne répare pas une phrase trop bavarde.

La suggestion officielle pour renforcer le volet réseau est de passer par Tor, avec un circuit neuf à chaque session. Ce n’est pas une option activée par défaut dans le coffre. C’est un geste de l’utilisateur. Le système sépare donc les couches : preuve de paiement d’un côté, transport de l’autre, contenu du message au milieu. Chacune peut fuir pour des raisons différentes.

zkAPI vous permet de payer pour une API facturée sans être connu. Déposez des crédits dans un coffre-fort Ethereum une fois, puis autorisez un usage borné avec des preuves à divulgation nulle de connaissance au lieu d’une identité.

Vittorio Rivabella, équipe dAI de la Fondation Ethereum

Pourquoi ce sujet arrive maintenant

Les interfaces d’IA se sont installées dans les outils du quotidien. Un éditeur appelle un modèle pour reformuler. Un tableur interroge un assistant. Un script nocturne résume des journaux. Chaque appel laisse une trace chez le fournisseur : clé, compte, parfois carte. Pour une entreprise, cette trace est un registre de conformité. Pour un particulier, c’est un dossier d’habitudes.

Le paiement à l’usage accentue le phénomène. On ne souscrit plus seulement un abonnement mensuel. On paie le jeton, l’image, la minute. Plus la facture est fine, plus le journal est précis. zkAPI vise cette granularité sans livrer le client à chaque ligne. Le dépôt est unique. Les autorisations sont bornées en dollars. La clé qui parle au modèle n’existe que le temps de la session, dans la mémoire de l’appareil.

Le calendrier n’est pas anodin. Le design Crapis-Buterin circulait déjà sur Ethereum Research. Le 1er octobre 2026 en est la première mise en œuvre en production sur le réseau principal. Entre le billet de recherche et le contrat appelé par de vrais crédits, il y a le passage du possible au disponible. C’est ce passage que l’annonce documente.

Le coffre ZkApiVault, un dépôt qui ne se répète pas

Le parcours commence par un geste classique sur Ethereum : envoyer des USDC vers un contrat. Ce dépôt devient un engagement dans un arbre de Merkle de 32 niveaux. L’arbre ne publie pas une liste nominative de clients. Il publie une racine. Chaque dépôt y entre comme une feuille engagée. Prouver plus tard qu’un dépôt existe ne désigne pas lequel.

Trente-deux niveaux, ce n’est pas un détail de décoration. C’est une capacité. Un arbre binaire de cette profondeur peut accueillir un très grand nombre de feuilles. Le coffre est donc pensé pour beaucoup d’utilisateurs, pas pour une démo à dix comptes. L’engagement cache le lien entre l’adresse qui a déposé et les dépenses futures. La dépense ne renvoie pas à la transaction d’origine de façon lisible.

Une fois les crédits en place, l’utilisateur n’a plus à signer chaque appel avec le compte qui a financé le coffre. C’est le point qui casse le graphe habituel. Dans un paiement classique, la même adresse revient. Un observateur relie dépôt, appels et retrait. Ici, la dépense publie un nullifier. La preuve atteste qu’un dépôt valide existe. Elle n’indique pas lequel.

Le nullifier a un second rôle, moins poétique et plus utile : empêcher la double dépense. Tenter de consommer deux fois le même solde produit un nullifier dupliqué. La tentative est exposée. Le reste de l’historique ne l’est pas. On punit le rejeu sans ouvrir le dossier. C’est la grammaire habituelle des systèmes à divulgation nulle appliquée à un porte-monnaie de crédits API.

Ce que voit le fournisseur, et ce qu’il ne voit pas

Le prestataire reçoit une requête bien formée. Il peut la traiter, la journaliser, la refuser si elle viole ses règles. Il ne reçoit pas, dans le mode prévu, le nom du payeur ni le compte Ethereum qui a alimenté le coffre. La Fondation le formule ainsi : le fournisseur voit les requêtes, jamais qui les paie.

Cette phrase mérite d’être lue lentement. Voir la requête, c’est déjà beaucoup. Un prompt long, un fichier, une suite de questions très spécifiques racontent une activité. Ne pas voir le payeur, c’est retirer le lien direct vers un portefeuille et, en principe, vers une personne identifiée par ce portefeuille. Les deux informations ne se valent pas. L’une décrit l’acte. L’autre désigne l’acteur.

Pour un service qui facture à l’appel, l’acteur était jusqu’ici la clé. La clé ouvrait le compte. Le compte ouvrait la facture. zkAPI remplace cette chaîne par une autorisation bornée. Le service peut encore appliquer ses filtres de contenu. Il ne construit plus, par le seul paiement, un fichier client.

Le mode runtime-key, une clé qui n’habite que la mémoire

Le mode dit runtime-key est le plus intéressant pour qui veut limiter ce que le serveur apprend. L’appareil produit une preuve. Le serveur la vérifie. Il émet alors une clé d’API de courte durée, plafonnée en dollars. Cette clé n’est pas un secret collé dans un fichier de configuration pour six mois. Elle n’existe que dans la mémoire de l’appareil.

À l’expiration, l’usage est consigné dans un reçu signé et déduit du dépôt privé. Le plafond en dollars évite qu’une preuve trop large ne devienne un chèque en blanc. L’utilisateur autorise une enveloppe. Pas un accès illimité. Si la session s’arrête, la clé s’éteint. Un voleur qui arriverait après coup ne trouve pas une clé permanente dans un dossier.

Ce choix répond à une critique ancienne des clés d’API. Une clé qui vit des mois dans un dépôt de code, un fichier .env ou un outil d’équipe devient un passe-partout. Ici, la durée est courte et le montant est borné. La preuve, elle, reste le geste d’autorisation. La clé n’est qu’un jeton de session, produit après vérification.

Le mode proxy, plus simple et plus bavard

Un second mode existe, assumé comme plus simple. Le serveur zkAPI relaie les requêtes vers le fournisseur. L’intégration est plus directe. Le prix de cette simplicité est clair : le relais voit tout le trafic. Qui choisit le proxy échange une partie de la confidentialité contre une mise en route plus courte.

Ce n’est pas un détail caché dans une annexe. C’est une bifurcation de produit. Le mode runtime-key garde la clé dans la mémoire de l’appareil et limite ce que le serveur doit observer pour autoriser. Le mode proxy fait passer le contenu par le relais. Pour un test, le second peut suffire. Pour un usage où le prompt est sensible, le premier est le seul qui respecte l’intention affichée.

La Fondation rappelle toutefois un point qui vaut pour les deux modes. Le contrat du coffre vérifie les preuves au dépôt, à la clôture et en cas de sortie d’urgence. Le retrait ne dépend jamais de l’honnêteté du serveur. Même si le relais disparaît, trafique ou refuse de coopérer, la sortie des fonds repose sur le contrat. C’est la différence entre un solde chez un intermédiaire et un solde verrouillé par des règles vérifiables.

Sortie d’urgence : le serveur n’est pas le coffre

Dans beaucoup de systèmes de crédits prépayés, l’argent est chez l’opérateur. S’il ferme, les soldes deviennent un litige. zkAPI place le dépôt dans un contrat. Les preuves sont vérifiées on-chain aux moments qui comptent pour l’argent : entrée, clôture, urgence. L’usage courant peut passer par un serveur. La garde des fonds, non.

Cette architecture mérite d’être dite sans lyrisme. Elle ne rend pas le serveur inutile. Elle le rend non souverain sur le retrait. Un opérateur malveillant peut encore gêner une session, journaliser un proxy, ou refuser une clé. Il ne peut pas, selon le design annoncé, confisquer le dépôt en refusant simplement de signer. La sortie d’urgence est le filet.

Pour un lecteur habitué aux exchanges, l’image est familière : la différence entre un solde affiché par une plateforme et un solde que l’on peut reprendre avec une transaction. Ici, le solde est un engagement dans un arbre, pas une ligne dans un tableur privé. Reprendre ses crédits exige une preuve valide, pas la bonne volonté d’un support client.

Des interfaces déjà connues, pointées vers la machine locale

L’adoption d’un schéma de paiement échoue souvent sur l’intégration. zkAPI tente de contourner cet écueil. Le client local parle le langage qu’OpenAI et Ollama ont déjà imposé à des milliers d’outils. On change l’URL. On ne réécrit pas l’application. Un script qui appelait un point d’accès distant peut appeler localhost.

Ce choix est pragmatique. Les équipes n’ont pas le temps d’apprendre un nouveau protocole pour chaque expérience de confidentialité. En parlant les interfaces standard, le client s’insère dans des éditeurs, des agents et des chaînes d’outils déjà en place. La nouveauté reste sous le capot : preuve, plafond, nullifier, reçu.

La Fondation indique que le même schéma pourrait couvrir autre chose que les modèles de langage. Requêtes RPC vers une blockchain, génération d’images et de vidéos, bande passante de VPN, paiements entre machines. La liste n’est pas un catalogue livré le jour du lancement. C’est un périmètre possible. Le premier usage documenté reste l’API facturée, à commencer par l’IA.

Le design Crapis-Buterin sort du forum

Les idées de paiement anonyme pour des services ne datent pas d’octobre 2026. Le billet d’Ethereum Research signé Davide Crapis et Vitalik Buterin posait déjà la structure : engagement, preuve, nullifier, usage borné. Le lancement est la première mise en œuvre en production sur le réseau principal. Entre les deux, l’Open Anonymity Project a porté le travail avec l’équipe de la Fondation.

Ce passage du texte au contrat change le statut de l’idée. Un design de recherche peut être élégant et inutilisable. Un contrat sur le réseau principal peut être appelé, critiqué, audité, contourné. Les limites publiées dans le billet d’annonce, absence d’anonymat réseau et fuite par les prompts, font partie de cette mise à l’épreuve. La Fondation ne vend pas une confidentialité absolue.

On peut lire cette franchise comme un signe de maturité. Les systèmes à divulgation nulle ont souvent été présentés comme des capes. Ici, le texte officiel découpe le problème. La preuve cache le lien entre dépôt et dépense. Elle ne cache pas l’adresse IP. Elle ne réécrit pas le prompt. Qui veut aller plus loin doit ajouter une couche réseau, et faire attention à ce qu’il envoie.

Les protections de zkAPI ont deux limites : l’absence d’anonymat réseau et la fuite de vie privée via le contenu des prompts.

Billet d’annonce de la Fondation Ethereum

Cette phrase devrait figurer en tête de toute présentation du produit. Elle évite la déception. Un journaliste, un développeur ou un lecteur pressé qui retiendrait seulement « payer sans être connu » manquerait la moitié du contrat. Être inconnu du fournisseur en tant que payeur n’est pas être inconnu du réseau, ni inconnu par ce que l’on écrit.

Ce que « divulgation nulle » veut dire ici, sans jargon inutile

Une preuve à divulgation nulle de connaissance permet de convaincre un vérificateur qu’une affirmation est vraie, sans révéler les données qui la rendent vraie. Dans zkAPI, l’affirmation ressemble à ceci : il existe un dépôt valide, non encore consommé de cette façon, et l’autorisation respecte le plafond. Le vérificateur n’apprend pas quelle feuille de l’arbre correspond au dépôt.

L’image utile n’est pas celle du masque. C’est celle du tampon. Vous montrez un tampon qui dit « ce crédit est bon ». Vous ne montrez pas le carnet d’où il vient. Si vous tentez d’utiliser deux fois le même tampon, le registre des nullifiers sonne. Le son révèle la triche, pas l’identité.

Cette propriété est forte sur le lien de paiement. Elle est silencieuse sur tout le reste. Un observateur du mempool voit une transaction de preuve. Un observateur du serveur voit une requête. Un observateur du réseau voit une adresse IP. Empiler ces trois vues peut, dans certains cas, rétrécir l’anonymat. La Fondation ne prétend pas que l’ensemble est étanche. Elle prétend que le paiement, lui, n’apporte pas le nom.

USDC comme unité de crédit, un choix de lisibilité

Les dépôts sont libellés en USDC. Le plafond des clés éphémères est exprimé en dollars. Le choix évite de facturer une API en ether volatil au moment de l’appel. Pour un service qui pense en centimes par requête, une unité stable simplifie le reçu. L’utilisateur dépose une somme qu’il peut comparer à une facture classique.

Ce choix a une conséquence. Le dépôt initial en USDC est, lui, une transaction visible. L’adresse qui alimente le coffre peut être observée à cet instant. La promesse du système n’est pas de cacher cet approvisionnement. Elle est de ne pas rattacher les dépenses ultérieures à cette adresse de façon directe. Qui veut soigner cette première marche doit réfléchir à l’origine des fonds, comme pour tout transfert on-chain. zkAPI ne réécrit pas cette réalité.

Le reçu signé en fin de session boucle la comptabilité privée. L’usage est déduit du dépôt. L’utilisateur peut suivre son enveloppe sans publier une facture nominative chez le fournisseur. Le fournisseur, de son côté, a été payé pour des appels qu’il a servis. Les deux livres ne partagent pas le même index de clients.

Une séance type, racontée sans mode d’emploi commercial

Imaginons une rédactrice qui interroge un modèle pour structurer des notes. Elle a déposé, une fois, des USDC dans le coffre. Le soir, elle lance le client local. L’appareil construit une preuve. Le serveur la vérifie et remet une clé de courte durée, plafonnée. Son éditeur, pointé vers localhost, parle comme il parlerait à une API classique.

Le modèle voit les notes, parce qu’elle les envoie. Le fournisseur ne reçoit pas son nom via le paiement. Son adresse IP, si elle n’a pas changé de circuit, reste un signal réseau. Si les notes contiennent le nom d’un client, ce nom voyage dans le prompt. À la fin de la session, la clé s’éteint. Un reçu signe l’usage. Le nullifier empêche de représenter la même autorisation.

Rien dans cette scène n’exige de réécrire l’éditeur. Tout exige de comprendre ce qui est caché et ce qui ne l’est pas. La rédactrice gagne une dissociation du paiement. Elle ne gagne pas le silence du contenu, ni l’invisibilité du réseau, sauf si elle les ajoute elle-même.

Ce que les équipes techniques peuvent retenir

Pour une équipe qui consomme des modèles, le point d’entrée est la compatibilité. Si l’outil parle déjà une interface OpenAI ou Ollama, le branchement local évite un projet d’intégration. Le travail réel se déplace vers la gestion du dépôt, le choix du mode, et la discipline sur les prompts.

Pour une équipe qui fournit une API, la question est autre. Accepter une preuve plutôt qu’une clé de compte change le modèle de confiance. Il faut vérifier, émettre une clé courte, respecter un plafond, signer un reçu. Le mode proxy simplifie, au prix du trafic visible. Le mode runtime-key demande plus de rigueur, et correspond mieux à l’annonce.

Dans les deux cas, le contrat reste l’arbitre de l’argent. Un fournisseur ne devient pas le dépositaire du solde. Cette séparation peut rassurer des utilisateurs qui refusent de laisser un prépaiement chez un tiers opaque. Elle peut aussi déplaire à des opérateurs qui vivaient sur la rétention des soldes. Le design choisit le contrat.

Au-delà des modèles : RPC, images, VPN, machines

La Fondation évoque des extensions naturelles. Une requête RPC facturée, par exemple l’accès à un nœud archive, ressemble à une API. Générer une image ou une vidéo aussi. Acheter de la bande passante VPN, ou régler un micropaiement entre deux machines, entre dans la même famille : un service mesurable, un prix, une preuve, un plafond.

Ces pistes ne sont pas livrées comme des produits finis le jour de l’annonce. Elles indiquent que zkAPI n’est pas un connecteur pour un seul éditeur de modèles. C’est un schéma de paiement pour des interfaces à l’usage. Si le schéma tient, d’autres fournisseurs peuvent s’y brancher sans inventer chacun un porte-monnaie nominatif.

Le paiement entre machines est le plus spéculatif, et le plus cohérent avec l’idée. Un agent qui appelle un autre agent n’a pas de carte bancaire. Il peut avoir un dépôt et une preuve. Borner la dépense en dollars limite le dégât si l’agent dérape. La clé éphémère évite de laisser un secret durable dans un processus automatisé.

Ce que ce n’est pas

zkAPI n’est pas un mélangeur de fonds présenté comme tel. Ce n’est pas un réseau d’anonymat. Ce n’est pas un substitut à Tor. Ce n’est pas une garantie que le contenu d’une conversation restera privé. Ce n’est pas non plus un conseil pour contourner une obligation légale. C’est un moyen de payer une API facturée sans attacher chaque appel à une identité de client.

Le distinguo protège la lecture. Les systèmes de confidentialité sur Ethereum ont plusieurs familles. Certaines cachent le graphe des transferts. D’autres cachent un solde. zkAPI cache le lien entre un dépôt de crédits et les dépenses d’API, dans le cadre d’un coffre spécialisé. Étendre la promesse au-delà de ce cadre, c’est lire l’annonce de travers.

Le testnet Sepolia sert à regarder le mécanisme sans fonds réels. C’est le bon endroit pour comprendre le cycle, pas pour conclure que la confidentialité est totale. Le réseau principal sert à ceux qui veulent un dépôt véritable. Les deux ne racontent pas la même histoire de risque.

Limites assumées, et pourquoi elles comptent plus que le slogan

La première limite est réseau. Pas de masquage d’adresse IP. Pas de masquage des horaires. Une série d’appels à heures fixes, depuis la même connexion, dessine une routine. Tor avec un circuit neuf par session est la piste suggérée. Elle demande un geste. Elle n’est pas magique non plus : un contenu trop personnel peut encore identifier.

La seconde limite est sémantique. Le prompt est le message. Un système de paiement ne chiffre pas, à lui seul, ce message vis-à-vis du fournisseur qui doit le lire pour répondre. Si le service doit comprendre la question, il voit la question. La vie privée du contenu se joue alors dans ce que l’on accepte d’envoyer, pas dans le nullifier.

Il existe une troisième limite, moins citée dans le slogan et pourtant mécanique : l’observation du dépôt initial. Alimenter le coffre est une transaction. Selon la façon dont les USDC ont été obtenus, cette transaction peut être reliée à d’autres activités. zkAPI coupe le fil vers les dépenses d’API. Il ne réécrit pas l’historique antérieur.

Une quatrième limite tient au mode choisi. Le proxy voit le trafic. Le présenter comme équivalent au mode runtime-key serait inexact. La documentation d’usage, lorsqu’elle circulera plus largement, devra maintenir cette distinction. Sinon, des utilisateurs croiront avoir la version discrète alors qu’ils ont la version relais.

Ce que gagne un utilisateur prudent

Il cesse de créer un compte chez chaque fournisseur d’API pour le seul motif du paiement. Il cesse de laisser une clé longue durée dans un fichier. Il borne la dépense. Il peut sortir ses crédits sans demander la permission du serveur. Il réduit le dossier que le prestataire constitue via la facturation.

Il ne devient pas invisible. Il devient plus difficile à relier, par le seul paiement, à un portefeuille. C’est déjà un déplacement net par rapport à la clé d’API classique, collée à un e-mail et à une carte. Pour des usages répétitifs et peu sensibles, le gain est surtout organisationnel. Pour des usages où le rattachement du payeur pose problème, le gain est plus direct.

La prudence reste locale. Circuit réseau séparé. Prompts sobres. Mode runtime-key plutôt que proxy. Plafond serré. Session courte. Ces gestes ne sont pas dans le contrat. Ils sont dans l’usage. Un outil de confidentialité mal employé raconte encore beaucoup.

Ce que gagne, ou perd, un fournisseur

Le fournisseur est payé pour un usage qu’il peut mesurer. Il n’accumule pas, par le paiement, une base de clients identifiés. Certains modèles d’affaires reposent précisément sur cette base : relance, profil, vente croisée. zkAPI s’adresse plutôt à une facturation à l’acte, où le service vend de la réponse, pas du fichier client.

Il conserve ses leviers de modération sur le contenu qu’il voit. Rien dans l’annonce n’oblige un prestataire à accepter toutes les requêtes. La preuve paie. Elle n’ouvre pas un droit automatique à être servi si la requête enfreint les règles du service. Cette articulation évite de confondre paiement privé et absence de politique d’usage.

Le coût d’intégration existe. Vérifier des preuves, émettre des clés courtes, signer des reçus, respecter des plafonds : ce n’est pas un compte Stripe. Les équipes qui vivent de la simplicité de la clé permanente peuvent juger l’effort élevé. Celles qui veulent des utilisateurs refusant le compte nominatif peuvent y voir un canal nouveau.

Un arbre de Merkle à 32 niveaux, à quoi ça sert concrètement

L’arbre de Merkle permet de prouver qu’une feuille appartient à un ensemble sans lister l’ensemble. La racine est publique. Le chemin de la feuille, dans la preuve, convainc le vérificateur. Avec 32 niveaux, l’ensemble peut devenir très grand avant que la structure ne soit à l’étroit. Le coffre est donc dimensionné comme un service, pas comme une expérience de table.

Pour l’utilisateur, le chiffre 32 n’a pas à être mémorisé. Il signale que le design a pensé l’échelle. Pour l’auditeur, il fait partie des paramètres à relire : profondeur, format d’engagement, domaine du nullifier, moments où le contrat vérifie. L’annonce grand public ne remplace pas cette relecture. Elle la rend utile, parce que le contrat est appelable.

Le nullifier, publié à chaque dépense, est l’autre moitié du dispositif. Sans lui, une preuve d’appartenance pourrait être rejouée. Avec lui, le rejeu est visible. L’équilibre est classique : cacher l’origine, révéler la tentative de double usage. C’est ce que l’on demande à un porte-crédits qui ne veut pas de découvert fantôme.

Clé éphémère contre clé permanente

Une clé permanente est commode et fragile. Elle survit aux sessions. Elle se copie. Elle se commit par erreur. Une clé éphémère, plafonnée, tenue en mémoire, meurt avec la session. Le vol après coup ne sert à rien. Le dépassement de budget est coupé par le plafond, pas par une alerte le lendemain.

Le reçu signé relie l’usage effectif à la déduction. Sans reçu, un système de crédits prépayés dérive : le serveur affirme une consommation, l’utilisateur n’a pas de trace vérifiable. Ici, la fin de session produit un objet signé. La déduction porte sur le dépôt privé. La comptabilité ne repasse pas par un relevé nominatif.

Ce couple, clé courte et reçu, est plus important pour l’usage quotidien que le nom du schéma de preuve. C’est lui qui change la vie d’un script. On n’entre plus une clé dans un secret manager pour six mois. On ouvre une enveloppe, on consomme, on ferme.

Sepolia pour essayer, le réseau principal pour déposer

Le déploiement sur Sepolia est mentionné pour essayer sans fonds réels. C’est la bonne porte pour observer le cycle de preuve, la forme des clés, le comportement à l’expiration. Le réseau principal est celui de l’annonce opérationnelle. Confondre les deux mènerait à parler d’un test comme d’un service, ou l’inverse.

La date du 1er octobre 2026 ancre l’événement. Avant, le design vivait sur Ethereum Research. Après, un coffre peut recevoir des USDC. Les mois qui suivent diront si des fournisseurs s’y branchent, si le mode runtime-key est celui que les clients retiennent, et si les limites écrites sont comprises ou gommées par les résumés.

Un lancement n’est pas une adoption. Beaucoup de primitives Ethereum ont été appelables longtemps avant d’être utilisées. zkAPI a l’avantage d’un point d’entrée familier, les interfaces de modèles. Il a le désavantage de demander une discipline que la clé classique ne demandait pas. Les deux forces joueront en sens inverse.

Vie privée des paiements et vie privée des questions

Il faut séparer deux dossiers que le marketing mélange. Le dossier du paiement demande : qui a réglé ? Le dossier de la question demande : qu’a-t-on demandé ? zkAPI traite le premier avec une preuve. Il laisse le second au fournisseur, parce que le fournisseur doit lire pour répondre.

Des techniques existent par ailleurs pour interroger un modèle sans lui montrer la question en clair. Elles ne sont pas ce que décrit cette annonce. Les présenter comme incluses serait inventer un produit. Le billet parle de paiement, de clé courte, de relais optionnel, de limites. Il ne parle pas d’un calcul chiffré de bout en bout sur le modèle.

Cette honnêteté de périmètre est utile. Un lecteur peut vouloir les deux, paiement dissocié et question cachée. Il n’obtiendra que le premier avec zkAPI. Le second reste un autre chantier, plus lourd, et non livré ici.

Tor comme couche suggérée, pas comme fonction du coffre

La Fondation suggère Tor, avec un circuit neuf à chaque session, pour renforcer la confidentialité réseau. La suggestion est précise. Un circuit réutilisé relie les sessions. Un circuit neuf coupe ce lien-là, sans couper le contenu. L’utilisateur qui enchaîne les deux gestes, preuve et circuit, couvre deux fuites distinctes.

Ce n’est pas une configuration décrite comme activée d’office. Qui lance le client sur une connexion habituelle publie encore son IP au service qu’il joint. Le coffre n’intercepte pas cette réalité. Le rappeler évite qu’un tutoriel ultérieur ne vende zkAPI comme un mode anonyme complet.

Horaires et volume restent des métadonnées. Une personne seule à appeler un modèle chaque nuit à la même minute, depuis un petit ensemble d’adresses, peut être distinguée même sans nom sur la facture. La dissociation du paiement réduit un lien. Elle n’abolit pas les autres.

Pourquoi l’Open Anonymity Project est dans la phrase

Le système a été construit avec l’Open Anonymity Project. La Fondation n’a pas seulement publié un billet. Elle a associé un projet dont le nom dit l’objectif : anonymat ouvert, au sens d’un mécanisme public, pas d’un service fermé. Le design de recherche et la construction logicielle se rencontrent dans le coffre déployé.

Cette attribution compte pour qui voudra suivre le code, les paramètres et les suites. Un lancement de Fondation sans équipe de construction nommée serait plus difficile à situer. Ici, le billet relie trois pôles : l’équipe dAI, le projet d’anonymat, et le design Crapis-Buterin. Le contrat est le quatrième pôle, celui que l’on peut appeler.

Aucun de ces noms ne transforme les limites en options cachées. Ils situent la responsabilité du discours. Quand le billet dit que le réseau n’est pas anonymisé, ce n’est pas une note de bas de page d’un tiers. C’est le texte de l’annonce.

Comparé à une clé d’API classique

La clé classique est un identifiant de facturation. Elle ouvre, elle trace, elle dure. La révoquer demande une action. La copier est facile. zkAPI remplace l’identifiant durable par une autorisation prouvée et une clé de session. Le fournisseur sert. Il ne classe pas le payeur dans un compte.

La contrepartie est une préparation. Il faut un dépôt. Il faut un client local. Il faut accepter que la première transaction d’approvisionnement soit visible. Pour un prototype d’après-midi, la clé classique gagne. Pour un usage où l’on refuse le dossier client, le coffre devient rationnel.

Il y a aussi un effet de plafond. La clé classique peut être illimitée jusqu’à l’alerte de facture. La clé zkAPI est bornée en dollars dès l’émission. Moins de surprise en fin de mois. Moins de marge pour un script qui s’emballe. Le bornage est une fonction, pas un défaut.

Comparé à un abonnement nominatif

L’abonnement échange un nom contre un forfait. Il est simple. Il concentre l’historique. zkAPI échange un dépôt contre des enveloppes. Il est moins simple. Il disperse le lien d’identité. Les deux peuvent coexister. Un laboratoire peut garder un abonnement pour l’équipe, et un coffre pour des essais qu’il ne veut pas rattacher au compte société.

Rien n’oblige un fournisseur à proposer les deux. L’annonce décrit un système que l’utilisateur peut employer pour payer des API, à commencer par les modèles. L’offre commerciale de chaque prestataire reste la sienne. Le point nouveau est la possibilité technique, sur le réseau principal, de présenter une preuve plutôt qu’un compte.

Pour le lecteur non technique, l’image tient en une caisse. On met des crédits dans la caisse. On présente un reçu cryptographique pour ouvrir un tiroir limité. Le caissier ne demande pas la carte d’identité. Il voit ce que l’on achète. Si l’on passe par l’entrée de service du proxy, un intermédiaire voit aussi le sac.

Risques à nommer sans les gonfler

Tout contrat nouveau peut contenir un défaut. L’annonce ne tient pas lieu d’audit public détaillé dans le texte repris ici. Un dépôt de crédits réels suppose une lecture des sources et, pour des montants significatifs, des revues indépendantes. Le filet de la sortie d’urgence est un argument de design, pas une preuve que le code est sans faille.

Le serveur, même non souverain sur les fonds, reste un point d’observation en mode proxy, et un point d’émission de clés dans les deux modes. Une clé émise peut être journalisée côté serveur pendant sa courte vie. La promesse porte sur l’identité du payeur, pas sur l’absence totale de journaux d’appels.

Enfin, le contenu. Le risque le plus banal est aussi le plus fréquent : coller dans le prompt ce que l’on ne dirait pas à un inconnu. Aucun nullifier ne retire une phrase déjà envoyée. La pédagogie du produit devra le répéter, sinon les retours d’expérience parleront de déception plutôt que de mécanisme.

Ce que l’actualité dit, et ce qu’elle ne tranche pas

L’actualité est nette sur les faits. Lancement le 1er octobre 2026. Réseau principal actif. Sepolia pour l’essai. USDC. ZkApiVault. Arbre de 32 niveaux. Nullifier. Mode runtime-key. Mode proxy. Interfaces OpenAI et Ollama. Limites réseau et prompts. Construction avec l’Open Anonymity Project. Design Crapis-Buterin. Extensions envisagées vers le RPC, l’image, la vidéo, le VPN, les machines.

L’actualité ne tranche pas l’adoption. Elle ne donne pas un nombre d’utilisateurs. Elle ne publie pas, dans le texte source, une liste de fournisseurs déjà branchés au-delà du schéma décrit. Elle ne fixe pas un prix de la preuve, ni un délai moyen de session. Ces chiffres, s’ils viennent, viendront d’un usage mesuré, pas du billet de lancement.

Elle ne tranche pas non plus les débats juridiques sur l’anonymat des paiements. Le dispositif est technique. Les cadres qui s’appliquent à un utilisateur, à un fournisseur ou à un relais dépendent du pays, du service et de l’usage. Les présenter comme réglés par un contrat Ethereum serait excessif. Le contrat règle la dépense. Il ne rédige pas la loi.

Une lecture pour les curieux de la recherche Ethereum

Ethereum Research a souvent été le brouillon des mécanismes ensuite déployés. Le délai entre un billet et un contrat varie. Ici, le fil est explicite : le design publié par Crapis et Buterin trouve une première production. Pour qui suit ces textes, le 1er octobre est une date de vérification. Le mécanisme décrit est-il celui qui tourne ? Les limites écrites correspondent-elles au logiciel ?

Les éléments publics collent au récit : engagement Merkle, nullifier anti-rejeu, preuve locale, clé bornée, reçu, sortie indépendante du serveur. C’est suffisamment concret pour être discuté par des implémenteurs, pas seulement par des commentateurs. Les mois suivants diront si des variantes apparaissent, si la profondeur de l’arbre évolue, si d’autres actifs que l’USDC sont acceptés. L’annonce, elle, parle USDC.

L’équipe dAI place le sujet dans le sillage des modèles. Ce n’est pas un hasard de communication. C’est là que la facture à l’appel est devenue quotidienne. Un mécanisme de paiement privé qui ignorerait cette facture resterait abstrait. En parlant les interfaces déjà installées, zkAPI cherche l’usage, pas seulement la démonstration.

Ce qu’un lecteur pressé peut retenir sans se tromper

On peut payer une API à l’usage en déposant des crédits une fois, puis en autorisant des enveloppes par preuve, sans compte client. Le fournisseur voit la requête, pas le payeur. La clé qui sert à l’appel est courte, plafonnée, et vit en mémoire. Le retrait ne dépend pas du serveur. L’anonymat n’est pas réseau. Le prompt peut trahir. Un mode relais voit le trafic. Sepolia sert à essayer. Le réseau principal est déjà là.

Cette liste suffit à ne pas déformer l’annonce. Le reste, arbre, nullifier, reçu, extensions possibles, précise le mécanisme. Aucun de ces détails ne contredit le résumé. Ils empêchent de le survendre.

Pourquoi la mise en forme du paiement compte autant que le modèle

On parle beaucoup de la qualité des modèles, peu de la forme de la facture. Pourtant la facture décide qui peut interroger sans ouvrir un dossier. Une équipe de recherche, un journaliste, un développeur indépendant, une association peuvent vouloir un calcul sans créer une relation commerciale nominative. zkAPI vise ce cas, avec les limites dites.

Il vise aussi le cas inverse : le fournisseur qui ne veut pas devenir une banque de données clients pour vendre du jeton. Facturer l’acte, vérifier une preuve, oublier le nom. Ce modèle existe déjà dans des commerces physiques qui prennent du liquide. Le transposer à une API demandait une preuve à la place du billet. C’est l’objet du coffre.

Le liquide, lui, n’a pas de nullifier public. Le coffre, si. La différence est saine. On peut cacher l’origine d’un crédit sans permettre de le dépenser deux fois. C’est toute la tension du design, et la raison pour laquelle le nullifier est publié alors que la feuille ne l’est pas.

Une scène d’équipe, pour voir où ça coince

Une petite équipe partage un dépôt. Chacun ouvre des sessions plafonnées. Personne ne laisse de clé dans le gestionnaire commun. Le reçu de chacun déduit sa part. Sur le papier, c’est propre. En pratique, il faut une règle : qui approvisionne, qui a le droit de prouver, comment on évite qu’un script vide l’enveloppe. Le contrat borne. Il ne manage pas l’équipe.

Si l’équipe passe par le proxy pour aller plus vite, le relais voit les prompts de tout le monde. Le gain d’intégration peut annuler le gain de discrétion. Le choix du mode est donc une décision de groupe, pas une option de confort. Le mettre par écrit évite qu’un intégrateur pressé n’active le relais « pour voir ».

Cette scène n’est pas dans le billet. Elle découle du billet. Les outils de paiement changent les habitudes seulement si l’habitude est nommée. Sinon, on revient à la clé dans le fichier, parce que le fichier est là depuis des années.

Images, vidéos, bande passante : le même ticket, un autre contenu

Générer une image facturée à l’unité ressemble à interroger un modèle. Le contenu, lui, peut être encore plus identifiant : un visage, un lieu, un document photographié. Le paiement dissocié ne rend pas l’image anonyme. Il empêche d’y coller une facture nominative. La distinction vaut double pour la vidéo, plus lourde, plus longue, plus riche en détails.

La bande passante VPN est un cas différent. Le service vend du transit. Le paiement via preuve éviterait un compte. Le transit lui-même reste un problème de réseau, précisément la limite que zkAPI ne couvre pas. Empiler un VPN payé par zkAPI et un circuit séparé peut avoir du sens. Présenter le coffre comme le VPN serait une confusion.

Les requêtes RPC facturées, accès à des nœuds, historiques, index, sont plus proches de l’API classique. Peu de contenu intime, beaucoup d’appels. Le plafond en dollars protège contre un script qui interroge en boucle. Le nullifier protège contre le rejeu du crédit. C’est peut-être, après les modèles, le terrain le plus naturel.

Paiements entre machines, une promesse à garder au conditionnel

La Fondation indique que le schéma pourrait servir à des paiements entre machines. Le conditionnel est juste. Un agent qui paie un autre agent sans compte partagé est un vieux rêve des micropaiements. Les preuves bornées le rendent plus crédible que les jetons API collés dans des variables d’environnement.

Il reste à voir qui opère le serveur de vérification, comment une machine garde la capacité de produire une preuve, et comment on révoque une enveloppe si l’agent est compromis. La clé courte limite la fenêtre. Elle ne remplace pas une politique. Tant que ces questions ne sont pas des produits, la phrase juste est : le design s’y prête, le lancement du 1er octobre vise d’abord l’API facturée.

Cette retenue évite l’article miracle. zkAPI n’automatise pas l’économie des agents le jour de sa mise en production. Il offre un coffre et deux modes. Le reste est une direction.

Le rôle du reçu signé, souvent oublié dans les résumés

Les résumés retiennent la preuve et oublient le reçu. Pourtant le reçu est ce qui transforme une session en comptabilité. À l’expiration, l’usage est consigné et déduit. Sans cette pièce, l’utilisateur aurait une autorisation, pas une trace de consommation. Avec elle, le dépôt privé reste cohérent.

Le reçu ne republie pas l’identité. Il clôt une enveloppe. Pour un usage personnel, c’est un journal. Pour une équipe, c’est la base d’un partage de coûts sans compte fournisseur commun. Encore faut-il que le logiciel local le conserve. Le design le prévoit. L’habitude de le regarder reste à prendre.

On peut comparer ce reçu au ticket de caisse sans nom. Il dit le montant. Il ne dit pas le client. Il empêche le commerçant d’inventer une consommation après coup, parce qu’il est signé. Cette propriété est moins spectaculaire que la preuve. Elle est celle qui rend le système tenable dans la durée.

Ce que change la vérification on-chain aux moments clés

Tout n’est pas vérifié on-chain à chaque jeton de modèle. Ce serait coûteux et inutile. Le contrat vérifie au dépôt, à la clôture et en sortie d’urgence. L’usage courant peut rester hors chaîne, encadré par la clé courte et le reçu. Cette répartition est le compromis classique entre coût et garantie.

Elle explique pourquoi le serveur peut exister sans devenir le coffre. Il accélère la session. Il ne détient pas le dernier mot sur les fonds. Si l’on devait vérifier chaque appel sur Ethereum, le prix de la preuve dépasserait souvent le prix de la requête. Le design évite ce non-sens.

Pour l’utilisateur, la conséquence est simple. La session est fluide. La dispute sur l’argent se règle avec le contrat, pas avec un ticket support. C’est le critère à retenir pour juger si un service « crypto » est vraiment adossé à un contrat ou seulement badgé.

Un vocabulaire minimal pour suivre la suite

Quelques mots suffisent. Le coffre est ZkApiVault. L’engagement est la feuille dans l’arbre. Le nullifier est le marqueur anti-rejeu. La preuve est produite sur l’appareil. La clé runtime est courte et plafonnée. Le proxy est le relais qui voit le trafic. Le reçu clôt la session. La sortie d’urgence ne demande pas le serveur.

Avec ce lexique, les annonces suivantes seront lisibles. Un changement de profondeur d’arbre, un nouvel actif, un fournisseur qui n’accepte que le proxy, une interface de plus : chaque nouveauté se rangera. Sans ce lexique, tout se mélange sous le mot anonymat, et le mot anonymat est précisément celui que le billet encadre.

Tenir ce vocabulaire en français clair a un sens. Les mécanismes de preuve sont souvent laissés en anglais de laboratoire, ce qui réserve le sujet à un cercle. L’enjeu, payer une API sans livrer son nom, concerne n’importe qui envoie des prompts facturés. Le mécanisme peut rester exigeant. Le récit, non.

Ce que l’on peut attendre des prochaines semaines

On peut attendre des retours d’essai sur Sepolia, des questions sur le mode choisi par défaut, des demandes de fournisseurs, et des critiques sur les métadonnées. On peut attendre aussi des confusions, le mot zk collé à une promesse trop large. Le texte de la Fondation donne les outils pour les corriger.

On ne devrait pas attendre, dès le billet, une mesure d’usage. Un lancement n’est pas un classement. La question utile est plus étroite : le cycle dépôt, preuve, clé, reçu, sortie fonctionne-t-il comme décrit, et les limites sont-elles visibles dans le client ? Si oui, le sujet mérite d’être suivi. Si des écarts apparaissent, ils vaudront mieux qu’un slogan.

Pour le lecteur de cryptomonnaies, l’intérêt n’est pas un cours. C’est une primitive de plus qui quitte le forum. Les primitives qui touchent le paiement des outils quotidiens ont une chance d’être manipulées, pas seulement citées. zkAPI a cette chance, à condition de ne pas être raconté comme une cape.

Relire l’annonce avec le bon niveau d’attente

Attendre un paiement dissocié de l’identité du client : c’est le contrat du produit. Attendre une navigation invisible : c’est un autre produit. Attendre que le modèle ne voie pas la question : c’est encore un autre. Attendre de pouvoir reprendre ses crédits si le serveur disparaît : c’est de nouveau le contrat, via la vérification des preuves à la sortie.

Ce calibrage change la valeur de la nouvelle. Bien calibrée, elle est solide. Le 1er octobre 2026, un coffre sur le réseau principal permet de payer des API à l’usage, d’abord des modèles, sans clé rattachée à une personne. Mal calibrée, elle déçoit en une session, dès que l’adresse IP ou le prompt rappellent que la cape n’était pas dans la boîte.

La Fondation a écrit les limites dans le billet. Les reprendre n’est pas une réserve ajoutée après coup. C’est le respect du texte. Un système de confidentialité se juge autant à ce qu’il refuse de promettre qu’à ce qu’il prouve.

Le geste local, là où la preuve naît

La preuve est générée sur l’appareil. Ce choix évite d’envoyer au serveur les secrets qui permettraient de désigner le dépôt. C’est la condition de la dissociation. Si la preuve était construite ailleurs, le lien que l’on cherche à cacher serait déjà parti. Le client local n’est donc pas un confort. Il est le lieu où l’autorisation devient anonyme au sens du paiement.

Pointer les applications vers localhost en découle. L’application parle au client. Le client parle au serveur avec une clé de session, après preuve. L’application n’a pas à connaître le coffre. Cette coupure est élégante pour l’intégration. Elle concentre aussi la responsabilité : le client local doit être digne de confiance, parce que c’est lui qui tient la session en mémoire.

Un client local compromis annule une partie du bénéfice, comme un portefeuille compromis. Rien de nouveau dans cette phrase. Elle rappelle que zkAPI déplace la confiance, il ne l’abolit pas. On fait confiance au contrat pour les fonds, au client pour la session, au fournisseur pour la réponse, et à soi-même pour le contenu envoyé.

Pourquoi le plafond en dollars est une fonction de sécurité

Une preuve sans plafond serait une autorisation ouverte. Une clé sans plafond aussi. Le plafond transforme l’autorisation en enveloppe. Si une clé fuite pendant sa courte vie, le dégât est borné. Si un script boucle, il s’arrête au montant. La sécurité n’est pas seulement cryptographique. Elle est budgétaire.

Exprimer ce plafond en dollars, via des crédits USDC, le rend lisible. Un utilisateur sait ce qu’il autorise. Un fournisseur sait ce qu’il peut servir. Le reçu compare l’usage au plafond. L’écart n’est pas une surprise de conversion. C’est un choix de produit autant qu’un choix d’actif.

On peut imaginer plus tard d’autres unités. L’annonce, elle, est en USDC. S’en tenir à ce qui est écrit évite d’annoncer un coffre multi-actifs qui n’est pas dans le billet. La lisibilité en dollars suffit à comprendre l’intention : parler le langage de la facture API, pas celui de la spéculation sur l’ether.

Ce que les rédactions et les labs peuvent en faire

Une rédaction qui interroge des modèles sur des sujets sensibles peut vouloir éviter qu’une facture nominative n’accompagne chaque essai. zkAPI offre cette dissociation, pas le secret du brouillon. Le brouillon, s’il part dans le prompt, est lu. La rédaction gagne sur le dossier de paiement. Elle doit encore décider ce qu’elle accepte d’envoyer, et par quel circuit.

Un laboratoire qui automatise des appels peut préférer des enveloppes à une clé partagée dans un secret manager. La rotation devient naturelle : la clé meurt. Le reçu remplace le tableur approximatif. Le coffre évite de laisser le prépaiement chez le fournisseur. Ces gains sont concrets, même sans romantisme sur l’anonymat.

Dans les deux cas, le mode compte. Proxy pour un essai interne non sensible. Runtime-key dès que le texte ne doit pas passer par un relais supplémentaire. Écrire cette règle au mur vaut mieux qu’un paragraphe de communication.

Une chronologie courte pour situer le fait

D’abord un design sur Ethereum Research, associé aux noms de Davide Crapis et Vitalik Buterin. Ensuite une construction avec l’Open Anonymity Project et l’équipe dAI de la Fondation. Puis, le 1er octobre 2026, une mise en production sur le réseau principal, avec un essai possible sur Sepolia. L’annonce décrit le système comme déjà actif, pas comme une feuille de route.

Cette chronologie est le minimum factuel. Elle évite de présenter zkAPI comme une rumeur ou comme un fork à venir. Le coffre a un nom. Les modes ont des noms. Les limites ont des phrases. À partir de là, le commentaire peut commencer, pas avant.

Les suites éventuelles, fournisseurs, interfaces, actifs, mesures d’usage, ne sont pas dans cette chronologie. Les ajouter serait écrire l’après. L’article d’actualité s’arrête au livré, et range le reste au conditionnel, comme le fait le billet pour le RPC, l’image, la vidéo, le VPN et les machines.

Questions que l’annonce laisse ouvertes, sans les combler

Quel sera le coût réel d’une preuve par rapport au prix d’un appel de modèle ? Le billet ne le chiffre pas. Combien de fournisseurs accepteront une clé issue de ce schéma dès les premiers jours ? Le billet ne dresse pas la liste. Le client local sera-t-il assez simple pour un non-développeur ? La compatibilité OpenAI et Ollama suggère que la cible première est déjà outillée.

La sortie d’urgence a-t-elle été exercée en conditions réelles au moment de l’annonce ? Le texte décrit le mécanisme, pas un historique d’incidents. Les nullifiers dupliqués sont-ils déjà observables comme tentatives ? Le design le prévoit. L’observation publique viendra avec l’usage.

Laisser ces questions ouvertes n’affaiblit pas le fait. Cela évite de remplir les trous avec des estimations. Un lecteur peut vouloir des chiffres. Il ne les trouvera pas dans le lancement. Il y trouvera une architecture, une date, et des limites.

L’effet sur la manière de parler d’identité en ligne

Payer a longtemps été le moment où l’identité revenait. On pouvait lire sans compte. On payait avec un nom. Les API d’IA ont renforcé ce moment, parce que presque chaque appel est facturé. zkAPI tente de casser ce réflexe pour une classe de services. Pas pour tout le web. Pour la facture à l’usage.

Si le réflexe casse vraiment, d’autres services mesureront l’intérêt d’un client qui paie sans s’inscrire. Si le réflexe tient, ce sera souvent à cause des limites : IP, prompt, habitude de la clé, friction du dépôt. Les deux issues sont informatives. Aucune n’est écrite le jour du lancement.

En attendant, la phrase juste tient en une ligne. On peut, depuis le 1er octobre 2026, déposer des crédits sur Ethereum et autoriser des API sans présenter une identité de client, dans un cadre dont la Fondation a elle-même dessiné les bords.

Pour ne pas confondre preuve, promesse et précaution

La preuve dit qu’un crédit est valide. La promesse officielle dit que le payeur n’est pas livré avec. La précaution dit de masquer le réseau si on y tient, et de surveiller ce que l’on écrit. Les trois ensembles ne se recouvrent pas. Les articles qui les fusionnent produiront des utilisateurs surpris.

Garder la séparation est aussi une façon de respecter le travail décrit. Un mécanisme précis n’a pas besoin d’être gonflé. Il a besoin d’être utilisé pour ce qu’il fait. Payer. Borner. Éteindre la clé. Déduire. Sortir sans le serveur. Le reste est à la charge de qui envoie la requête.

C’est peut-être la leçon la plus utile de ce lancement. La confidentialité d’un paiement d’API n’est pas un interrupteur. C’est une pile. zkAPI enlève une couche, celle du compte. Il laisse les autres visibles, et il le dit.

Ce que retient l’actualité du jour

La Fondation Ethereum a lancé zkAPI le 1er octobre 2026. Le système permet de payer des API facturées à l’usage, en commençant par les modèles d’IA, sans dévoiler l’identité du payeur. Les crédits USDC vont dans ZkApiVault. Les dépenses s’autorisent par des preuves produites localement. Un nullifier bloque le double emploi. Une clé éphémère, plafonnée, vit en mémoire. Un proxy plus simple voit le trafic. Le contrat vérifie dépôt, clôture et sortie d’urgence. Sepolia permet d’essayer. Le réseau n’est pas anonymisé. Le prompt peut fuir. Le design vient de Crapis et Buterin. La construction associe l’Open Anonymity Project.

Tout le commentaire utile tient autour de ce paragraphe. Le coffre est ouvert. La cape n’est pas dans la boîte. Entre les deux, un moyen nouveau de régler une requête sans ouvrir un compte, déjà appelable, déjà limité, déjà plus concret qu’un fil de recherche.

Pour qui paie des modèles chaque semaine, la question n’est plus théorique. Elle est pratique. Accepte-t-on de déposer une fois, de prouver ensuite, et de garder pour soi le soin du réseau et du texte ? Si oui, zkAPI a un usage. Si l’on attend que le système fasse aussi le silence autour de la question, il faudra autre chose, et l’annonce ne prétend pas l’avoir livré.