Vitalik Buterin Teste Une IA Privée Pour Ses Données Santé

Et si le prochain conseil nutritionnel que vous demandez à une machine suffisait à dessiner votre emploi du temps, votre ville d’étape et, à la longue, votre identité ? Le 4 octobre 2026, Vitalik Buterin a publié le récit d’un essai personnel qui part exactement de cette crainte. Il veut des recommandations de régime et d’exercice taillées sur ses propres données de santé et de déplacement. Il veut aussi que les modèles les plus capables n’emportent pas, au passage, le dossier qui a servi à les produire. Le geste est modeste en apparence. Il touche en réalité au point le plus sensible de l’intelligence artificielle grand public : la frontière entre un service utile et une fuite permanente.

Le cofondateur d’Ethereum n’a pas présenté un produit fini, ni un audit, ni un score médical. Il a décrit un bricolage assumé. Un modèle local réécrit les questions. Un mécanisme de paiement tente de détacher l’argent de la requête. Un routage via Tor cherche à masquer l’adresse réseau. Trois protections, dit-il, parce qu’une seule ne suffit jamais. Cette phrase mérite d’être prise au sérieux. Elle résume mieux le sujet que n’importe quel slogan sur la confidentialité.

Un essai personnel, pas une promesse de produit

L’expérience tient dans une idée simple. Les fichiers sensibles restent sur la machine de l’utilisateur. Le modèle local, ici Qwen3.8-Flash-Next d’Alibaba, lit ce contexte, décide ce qu’un modèle distant a vraiment besoin de savoir, puis reformule la demande. Le système lointain répond sur un extrait appauvri. La réponse revient, et le modèle local peut la recoller au dossier privé. En théorie, le fournisseur d’intelligence artificielle voit une question nettoyée, pas une biographie.

Buterin a précisé que le modèle local tournait autour de 20 à 30 tokens par seconde dans son installation. Il estime qu’un usage confortable commencerait au-delà de 100 tokens par seconde. Le détail a l’air technique. Il change pourtant le ressenti. Une couche de confidentialité qui met plusieurs secondes à reformuler chaque demande devient vite un frein. On la contourne. On colle le dossier entier dans la fenêtre du modèle distant. La vie privée perd alors non par faille cryptographique, mais par fatigue.

Il a aussi indiqué que les réponses des modèles de pointe amélioraient le résultat final. C’est le cœur du compromis. Si le modèle local suffisait, l’essai n’aurait pas de raison d’exister. S’il ne suffit pas, il faut accepter d’envoyer quelque chose dehors. La question n’est plus « faut-il une IA distante ? ». Elle devient « quelle quantité minimale d’information rend encore la réponse utile ? ».

Pourquoi la santé change la nature du risque

Un prompt banal sur un protocole ou un cours de change laisse peu de traces durables. Un prompt de santé n’a pas le même poids. Une allergie, une contrainte alimentaire, un fuseau horaire récurrent, une ville d’arrivée : chacun de ces fragments est anodin seul. Alignés, ils deviennent une signature. Le style d’écriture ajoute une deuxième signature. Buterin le dit à sa manière : le modèle local ne se contente pas de retirer des noms. Il reconstruit la question pour que ni le fond ni la tournure ne trahissent l’auteur.

C’est plus difficile qu’il n’y paraît. Un conseil d’exercice utile a besoin de contraintes réelles. Genou fragile, décalage horaire, semaine de conférences, accès ou non à une salle. Si l’on retire tout, la réponse devient un article de magazine. Si l’on garde tout, le modèle distant peut recouper. L’essai se place exactement sur cette ligne étroite, et Buterin admet que les règles d’écriture doivent encore être améliorées. Plus on est prudent, moins le modèle lointain peut aider. La formule est sèche. Elle est aussi la plus honnête du récit.

Le choix du domaine n’est pas un hasard de communication. La santé concentre ce que les régulateurs, les assureurs et les plateformes convoitent déjà : des signaux personnels, répétés, difficiles à anonymiser après coup. Un voyage ajoute la géographie. Ensemble, les deux fichiers racontent une vie en mouvement. Les utiliser comme banc d’essai, c’est tester le montage là où l’échec coûte le plus.

Trois couches, parce qu’une identité a plusieurs portes

Buterin décrit une séparation en trois plans. Le contenu de la requête. L’information de paiement. Le trafic internet. Chacun peut, à lui seul, rattacher une session à une personne. Cacher le paiement ne sert à rien si le prompt contient un détail unique. Cacher le prompt ne sert à rien si l’adresse IP et l’horaire suffisent à regrouper les appels. D’où la phrase qu’il a posée sans détour : il faut les trois.

Il faut les trois protections. Masquer le paiement ne suffit pas si le contenu ou le réseau racontent encore qui vous êtes.

Vitalik Buterin, à propos de son essai du 4 octobre 2026

La première couche est donc éditoriale autant que technique. Un fichier de consignes, une skill dans le vocabulaire des agents, indique au modèle local quand appeler un système distant et comment formuler la demande. Les dossiers restent disponibles localement. Le distant ne reçoit que la portion jugée nécessaire pour la tâche. Ce n’est pas du chiffrement du prompt. C’est une réduction volontaire, et donc faillible, de ce qui sort.

La deuxième couche s’appelle zkAPI. L’Ethereum Foundation l’a présentée le 1er octobre 2026, trois jours avant l’essai. Le projet a été construit par l’Open Anonymity Project avec la fondation, et il tourne sur le réseau principal d’Ethereum. L’utilisateur alimente un solde privé, puis prouve qu’il dispose d’assez de fonds sans révéler quel dépôt paie quelle requête. Le service qui encaisse n’a pas besoin du prompt. Le fournisseur du modèle reçoit le prompt sans apprendre l’identité de facturation attachée au dépôt.

La troisième couche est Tor. Elle cache l’adresse IP habituelle aux services qui reçoivent les requêtes. Buterin a toutefois jugé cette brique la plus faible du montage actuel. Tor n’a pas été conçu pour délier chaque appel du suivant dans le rythme d’un agent qui pose question après question. Dans ses tests, la latence était environ 10 à 100 fois plus haute que ce qu’il jugeait souhaitable.

zkAPI sépare l’argent de la question, pas la question du modèle

Il faut lire zkAPI pour ce qu’il est, pas pour ce qu’un titre peut laisser croire. Le système casse le lien entre un solde approvisionné et un usage unitaire d’API. Il ne rend pas le prompt invisible. La documentation officielle le dit : le fournisseur en amont voit toujours les invites. Des informations de réseau et de timing peuvent rester observables en dehors de la preuve à divulgation nulle de connaissance. L’Ethereum Foundation a fait la même distinction au lancement. Le paiement masque le lien entre une personne et une requête. La confidentialité du contenu et l’anonymat réseau exigent d’autres protections.

Cette limite n’est pas un défaut caché. C’est le périmètre du outil. Une preuve peut montrer qu’un solde suffit sans montrer lequel. Elle ne peut pas empêcher un modèle de lire ce qu’on lui a écrit. Des détails personnels réutilisés, des tics de langage, un historique de conversation ou des documents peuvent encore relier des sessions entre elles. Le modèle local de Buterin vise précisément cette exposition de contenu. Il ne la supprime pas par magie cryptographique. Il tente de la réduire avant l’envoi.

Le mécanisme de solde privé mérite un arrêt. Dans un paiement classique d’API, chaque clé est une identité. Les journaux du fournisseur alignent les appels, les montants et parfois l’adresse de facturation. Ici, l’utilisateur prouve une capacité de paiement sans exhiber le dépôt. Le service de paiement n’a pas le texte. Le service de modèle n’a pas le compte. Les deux moitiés existent, mais elles ne se rejoignent pas chez le même acteur. C’est déjà beaucoup. Ce n’est pas tout.

Couche	Ce qu’elle cherche à cacher	Ce qu’elle laisse voir
Modèle local	Le dossier complet et le style d’origine	La portion réécrite, choisie par l’agent
zkAPI	Le lien entre dépôt et requête	Le prompt, côté fournisseur du modèle
Tor	L’adresse IP habituelle	Un trafic plus lent, parfois regroupable dans une conversation

Le tableau clarifie une confusion fréquente. Beaucoup de lecteurs entendent « zéro connaissance » et concluent que le modèle ne sait rien. La preuve porte sur le paiement. Le texte, lui, voyage en clair vers le fournisseur, une fois réécrit. Confondre les deux, c’est annoncer une confidentialité que le montage ne revendique pas.

Le correctif Tor, encore ouvert au moment de l’essai

Buterin a pointé un changement dans le dépôt zkAPI d’Ethereum. Au 4 octobre, la proposition de fusion numéro 16 était ouverte. Un commit touchait sept fichiers. Elle n’était pas encore intégrée à la branche principale. Le code proposé crée un client Tor temporaire et frais au démarrage du démon, avec un nouveau répertoire de données et une nouvelle connexion. Une autre commande peut relancer le service pour obtenir une identité réseau neuve avant une requête isolée ou le début d’une conversation.

Les délais réseau sont allongés, ce qui colle à l’expérience vécue. Le temps accordé à la liste des modèles passe d’une minute à trois minutes. D’autres limites montent de 15 secondes à 60 secondes, et de 5 secondes à 30 secondes. Un script séparé précise qu’un serveur frais est créé pour une requête unique ou pour le début d’une conversation. Les messages suivants de la même conversation gardent le serveur en place. Ils ne reçoivent donc pas automatiquement une nouvelle identité Tor à chaque échange.

Ce dernier point est décisif. Un agent qui discute pendant dix minutes sur le même circuit offre une continuité. Utile pour le contexte. Mauvaise pour le déliement. Buterin veut idéalement que des appels séparés soient difficiles à associer. Le correctif, dans l’état décrit, fait un pas vers une identité fraîche au démarrage, puis accepte la continuité intra-conversation. Ce n’est pas une contradiction. C’est un arbitrage entre usage et discrétion, écrit dans le code avant même d’être mergé.

Vingt tokens par seconde, et le mur du confort

Alibaba a publié Qwen3.8-Flash-Next le 26 août. Le dépôt officiel le présente comme un modèle à poids ouverts, exécutable via des cadres d’inférence locale, dont vLLM et SGLang. Buterin expérimentait déjà des modèles Qwen en local avant cet essai. La nouveauté est le rôle d’intermédiaire : le modèle ne fait plus toute la tâche sur l’appareil. Il trie, reformule, puis s’efface devant un système plus fort.

La vitesse reste le frein visible. À 20 ou 30 tokens par seconde, une reformulation longue se sent. Au-delà de 100, elle commencerait, selon lui, à paraître rapide. Le chiffre n’est pas une norme de laboratoire. C’est un seuil de patience. Les outils de confidentialité meurent souvent là : pas dans une équation, dans le moment où l’utilisateur clique sur le chemin le plus court.

Un modèle local lent pousse aussi à de mauvais réflexes. On envoie des extraits plus gros pour éviter un aller-retour. On garde la même conversation distante plus longtemps. On désactive Tor « juste pour cet essai ». Chaque raccourci recolle une couche que le montage avait séparée. La performance n’est donc pas un sujet annexe de matériel. Elle fait partie de la sécurité opérationnelle.

Le fil avec les positions déjà prises sur la vie privée

L’essai ne sort pas de nulle part. En avril 2025, Buterin avait déjà lié la montée des capacités des modèles et la collecte centralisée de données à un besoin plus fort d’outils de protection. Le geste d’octobre 2026 est une mise en pratique de cette ligne. Il ne s’agit plus seulement de dire que les portefeuilles et les preuves doivent limiter ce qui fuit. Il s’agit de brancher un dossier intime sur un agent, puis de mesurer ce qui passe encore.

Le même souci apparaît dans le travail protocolaire. En août, la feuille de route mise à jour d’Ethereum incluait une confidentialité de protocole plus forte, aux côtés de la résistance quantique et des rollups natifs. zkAPI n’est pas ce protocole. C’est une couche applicative, construite avec la fondation, posée sur le réseau principal. Le rapprochement reste utile. Ethereum sert ici de rail de paiement privé pour un usage qui n’est pas, au départ, une transaction financière classique. Payer une inférence sans laisser une trace nominative, c’est étendre le réflexe de minimisation hors du seul transfert de jetons.

On peut lire l’essai comme un prototype de cette idée. Le jeton, ou plutôt le solde prouvé, n’achète pas un café. Il achète une réponse. Si cette réponse porte sur le corps et les déplacements, le rail de paiement devient un morceau d’infrastructure sanitaire improvisée. D’où l’intérêt, et d’où la prudence.

Ce que l’expérience a produit, et ce qu’elle n’a pas montré

Buterin a indiqué que le montage avait bien généré des recommandations de régime et d’exercice, et que les modèles de pointe amélioraient le rendu. Il n’a pas publié les dossiers sous-jacents, ni le détail des conseils, ni une évaluation indépendante de leur justesse. L’absence n’est pas un oubli anecdotique. Publier le dossier annulerait l’objet de l’essai. Publier les conseils détaillés pourrait encore permettre un recoupement. L’évaluation externe manque néanmoins. Un lecteur ne peut pas savoir si les réponses étaient prudentes, génériques ou simplement fausses.

C’est un point que les récits d’agents passent souvent sous silence. Une architecture élégante peut délivrer un mauvais conseil avec beaucoup de discrétion. La confidentialité ne valide pas le contenu médical. Rien, dans le message du 4 octobre, ne présente ces recommandations comme un avis clinique. Les prendre ainsi serait un contresens. L’essai parle d’un tuyau. Il ne parle pas d’une autorisation de soin.

Il manque aussi une mesure de fuite. Combien de détails identifiants restaient dans les prompts réécrits ? Un relecteur externe a-t-il tenté de deviner l’auteur à partir des seules questions envoyées ? Sans ce test, la promesse reste qualitative. Elle est intéressante. Elle n’est pas démontrée.

Le paradoxe que Buterin formule lui-même

La limite est dite sans habillage. Plus on retire de contexte personnel, moins le modèle distant peut assister. La documentation de zkAPI pose une distinction voisine. La couche de paiement peut rompre le lien entre un solde et un usage. Elle ne peut pas retirer une information identifiante qu’un utilisateur, ou un agent local, a placée dans le prompt. Les deux textes se répondent. L’un vient de l’essai. L’autre vient du outil. Ensemble, ils ferment la porte aux slogans absolus.

Plus on est prudent avec ce qui part au loin, moins le modèle distant peut réellement aider.

Vitalik Buterin, sur la limite de son montage

Ce paradoxe va structurer les prochains mois d’agents personnels. Les éditeurs voudront des dossiers complets pour « mieux personnaliser ». Les utilisateurs voudront le contraire dès qu’un incident montrera ce qu’un journal de prompts contient. Le montage de Buterin est une troisième voie, incomplète : personnaliser en local, n’externaliser qu’un résidu. Elle échoue si le résidu reste trop parlant. Elle échoue aussi si le résidu devient trop pauvre pour justifier l’appel.

On peut illustrer le dilemme sans chiffre inventé. Une question du type « quel en-cas après un vol de nuit si je digère mal les laitages » aide un modèle. Elle livre aussi un trait de santé et un mode de déplacement. Remplacer cela par « propose un en-cas sans produit laitier pour un adulte » protège mieux et répond moins juste. Le fichier de consignes doit trancher ce genre de cas des dizaines de fois. C’est un travail d’édition, pas seulement d’infrastructure.

Pourquoi le paiement anonyme ne suffit jamais seul

Imaginons un utilisateur qui paie chaque appel via une preuve, mais envoie ses notes brutes. Le fournisseur du modèle n’a pas le nom du dépôt. Il a mieux : le texte. Un calendrier de voyages, des dosages, des prénoms de proches glissés par habitude. Le solde privé devient alors un habillage. L’identité se reconstruit par le contenu. C’est exactement le scénario que la première couche tente de bloquer.

Inversons. Le prompt est propre, le paiement est détaché, mais toutes les requêtes partent de la même adresse, aux mêmes heures, vers le même point de sortie. Un observateur du réseau n’a pas le texte. Il a un rythme. Pour un essai isolé, cela pèse peu. Pour un agent quotidien, le rythme devient une signature. Tor vise ce plan. Sa latence actuelle, et le maintien du même circuit pendant une conversation, montrent que le viseur n’est pas encore réglé pour un usage fluide.

Le troisième scénario est le plus discret et le plus sournois. Contenu réduit, IP masquée, mais paiement nominatif classique. Une facture mensuelle relie alors des milliers de prompts « anonymes » à un nom. zkAPI existe pour couper ce lien. Sans lui, les deux autres couches protègent la session et laissent le relevé parler.

Ce que change le fait de tourner sur le réseau principal

zkAPI n’est pas resté sur un réseau de test. La présentation du 1er octobre le situe sur le réseau principal d’Ethereum. Cela a une conséquence concrète. Les dépôts, les preuves et les soldes privés s’inscrivent dans un environnement où la valeur est réelle et où les erreurs de conception coûtent. Ce n’est pas une garantie de confidentialité parfaite. C’est un signal de maturité relative : le rail n’est plus une démo de conférence.

Pour un lecteur crypto, l’intérêt dépasse le conseil alimentaire. Si un solde peut payer une inférence sans lier l’appel au dépôt, le même schéma peut payer d’autres API mesurées : données de marché, exécution, recherche. Chaque fois, la même coupure s’applique. Le prestataire voit la requête. Il ne voit pas qui a approvisionné le solde. Le reste de la discrétion dépend de ce que la requête contient et d’où elle part.

Cette généralisation a une limite que l’essai de santé rend évidente. Plus la requête est personnelle, plus la coupure de paiement est insuffisante. Payer anonymement une cotation publique est presque assez. Payer anonymement une analyse de dossier ne l’est pas. Le domaine dicte le nombre de couches nécessaires. Buterin a choisi le domaine qui en exige trois.

Latence, délais et usage réel d’un agent

Les timeouts allongés dans la proposition de code ne sont pas un détail de développeur. Ils racontent l’expérience. Une liste de modèles qui peut prendre trois minutes, des requêtes qui passent de quelques secondes à une minute : un agent conversationnel supporte mal ce rythme. L’utilisateur pose une question sur un repas. Il attend. Il reformule. Il attend encore. À ce stade, beaucoup abandonnent la couche lente et gardent seulement le modèle local, ou seulement le modèle distant.

Buterin a situé la latence Tor entre 10 et 100 fois ce qu’il souhaitait. L’écart est large, ce qui suggère des mesures variables selon le circuit, l’heure et la taille de l’échange. Un outil dont la pénalité n’est pas stable est difficile à intégrer dans une routine. On ne sait pas si la prochaine question coûtera une poignée de secondes ou une pause longue. L’incertitude elle-même pousse à désactiver la protection.

Il existe un second effet, moins discuté. Des délais longs augmentent la tentation de grouper les questions. On envoie un paquet plus riche pour « rentabiliser » l’attente. Le paquet plus riche est précisément ce que la première couche devait éviter. La lenteur du réseau dégrade donc la qualité du filtrage de contenu. Les couches ne sont pas indépendantes. Quand l’une faiblit, elle abîme les autres.

Le rôle exact du modèle ouvert dans le montage

Le choix d’un poids ouvert n’est pas neutre. Un modèle que l’on peut faire tourner chez soi peut lire le dossier sans l’expédier. Il peut aussi être inspecté, remplacé, bridé par des consignes locales. Un modèle uniquement accessible par API ne peut pas tenir ce rôle de filtre, sauf à lui confier déjà les données. L’architecture a donc besoin d’un exécutable local crédible, pas seulement d’un rail de paiement.

Crédible ne veut pas dire équivalent aux frontières. Buterin envoie encore certaines questions dehors lorsque le raisonnement ou la connaissance exigés dépassent le local. Le filtre décide. Cette décision est le point fragile. Un mauvais critère envoie trop. Un critère trop dur n’envoie rien d’utile. Le fichier de consignes devient, en pratique, la politique de confidentialité vivante de l’utilisateur. Peu de gens écriront la leur avec autant de soin. C’est là que l’essai d’un cofondateur et l’usage d’un public large divergent.

On peut toutefois retenir une méthode. Séparer les fichiers sensibles de la fenêtre de chat distante. Faire reformuler par un processus qui a le droit de tout lire. N’autoriser la sortie qu’à un texte plus pauvre. Payer sans rattacher. Router sans montrer l’adresse habituelle. Chaque étape est imparfaite. L’ensemble est déjà plus strict que le réflexe courant, qui consiste à coller un export complet dans un chatbot généraliste.

Ce que les journaux de prompts révèlent d’habitude

Les fournisseurs de modèles conservent souvent des invites, pour la facturation, la sécurité ou l’amélioration des systèmes. Même une politique de non-entraînement ne fait pas disparaître le texte au moment où il est traité. Un employé, une requête légale, une fuite interne ou une mauvaise configuration peuvent exposer ce qui a été envoyé. Réduire le prompt avant l’envoi réduit la matière exposée. C’est une défense en profondeur, pas une disparition du risque.

Le style compte autant que les faits. Un lecteur attentif reconnaît une façon de poser les problèmes, des anglicismes, une structure de liste, une obsession pour tel paramètre. Buterin mentionne explicitement ce risque de style. Le modèle local doit donc non seulement ôter des données, mais réécrire. Une réécriture mécanique laisse parfois des empreintes. Une réécriture trop libre invente des contraintes. Encore un arbitrage, encore sans chiffre public de réussite.

Les conversations longues aggravent le phénomène. Le correctif Tor garde le même serveur pour les messages d’une même discussion. Côté contenu, une discussion longue accumule des précisions. Même si chaque message est pauvre, la somme ne l’est plus. Un adversaire qui voit la série reconstitue le dossier que chaque message avait cherché à fragmenter. D’où l’intérêt, encore théorique, d’un déliement requête par requête. D’où aussi son coût, que les tests jugent aujourd’hui excessif.

Un pont entre portefeuille et agent personnel

Depuis des années, une partie de la recherche Ethereum tourne autour d’une question : que peut-on prouver sans montrer. Soldes, appartenances, votes, parfois l’historique. zkAPI déplace cette question vers un geste quotidien, payer une API. L’essai de Buterin la déplace une fois de plus, vers un agent qui touche au corps. Le portefeuille n’est plus seulement un coffre. Il devient un moyen de consommer du calcul sans laisser une identité de facturation.

Ce déplacement a une conséquence pour les applications. Une interface de santé, de voyage ou de finance personnelle qui prétendrait « utiliser zkAPI » ne dirait presque rien sur la protection réelle. Il faudrait demander où tourne le modèle qui voit les fichiers, ce qui est réécrit, si le circuit réseau change, et si la conversation est continue. Sans ces réponses, la marque de la preuve ne couvre que le reçu.

Les équipes qui construiront ces interfaces hériteront du paradoxe déjà formulé. Leurs utilisateurs voudront des réponses précises. Leurs avocats voudront des prompts pauvres. Le fichier de consignes sera le champ de bataille. L’essai d’octobre montre à quoi ressemble une première version de ce champ, encore lente, encore manuelle, encore non évaluée de l’extérieur.

Comparé au simple chatbot, qu’est-ce qui change vraiment

Dans l’usage dominant, une personne ouvre un service distant, colle des notes, paie avec un compte, et parle depuis son adresse habituelle. Les trois portes sont ouvertes. Le montage testé en ferme une par une, sans prétendre les sceller. Le modèle local tient le dossier. La preuve tient le paiement. Tor tient, mal pour l’instant, le chemin. La différence est réelle. Elle n’est pas totale.

Il existe une autre école, plus radicale : ne jamais appeler de modèle distant dès qu’un fichier personnel est en jeu. Elle évite la fuite de contenu. Elle renonce à la qualité que Buterin dit avoir gagnée en interrogeant des systèmes plus forts. L’essai refuse ce tout ou rien. Il parie qu’une question bien pauvre peut encore valoir le détour. Le pari n’est pas tranché par une étude. Il est illustré par un usage personnel.

Une troisième école chiffre le prompt ou calcule dessus sans le révéler au fournisseur. Ces approches, plus lourdes, visent justement la faille que zkAPI laisse ouverte : le texte lu par le modèle. L’essai d’octobre ne prétend pas les remplacer. Il combine un filtre local, un paiement détaché et un réseau masqué, avec les outils disponibles maintenant. C’est un bricolage de 2026, pas la fin de l’histoire.

Les délais du code disent déjà la suite

Regarder la proposition encore ouverte, c’est voir l’ordre des priorités. D’abord faire passer le client par Tor. Ensuite accepter des attentes plus longues. Ensuite distinguer une requête isolée, qui peut avoir une identité fraîche, d’une conversation, qui garde son serveur. L’intégration n’était pas faite au moment du message. L’essai a donc couru en parallèle d’un correctif non fusionné. C’est cohérent avec un autotest, pas avec un service que l’on recommanderait tel quel à un public non technique.

Pour un développeur, la leçon est pratique. Si vous ajoutez Tor sous un client d’API, prévoyez des délais qui ne ressemblent plus à ceux d’un appel direct. Si vous voulez une identité neuve à chaque message, prévoyez un coût que l’auteur juge aujourd’hui 10 à 100 fois trop haut. Si vous gardez la conversation, documentez que les messages se suivent. Ne vendez pas un déliement que le script ne fait pas.

Pour un utilisateur, la leçon est plus simple. Un bouton « privé » qui ne dit pas laquelle des trois portes il ferme est un bouton incomplet. Demandez si le dossier quitte la machine. Demandez si le paiement porte un nom. Demandez si l’adresse habituelle est visible. Trois non francs valent mieux qu’un logo.

Santé, voyage, et la tentation du dossier unique

Le couple santé et voyage est redoutable parce qu’il est utile. Un régime dépend du décalage, des repas d’aéroport, du sommeil. Un programme d’exercice dépend des hôtels et des journées assises. Séparer les deux fichiers appauvrirait les conseils. Les fusionner crée un journal de bord. L’essai assume cette fusion, mais du côté local. C’est le bon côté, à condition que la réécriture ne recolle pas les deux dans le prompt sortant.

Un exemple fictif, sans rapport avec des données réelles, suffit à montrer le piège. « Repas léger après une arrivée tardive, en évitant le gluten, séance courte le lendemain matin » peut sembler générique. Répété avec des villes et des dates à peine masquées, il ne l’est plus. Le fichier de consignes doit interdire ce genre de recollement. Sans publication de ce fichier, on ne sait pas jusqu’où l’essai est allé. On sait seulement que l’auteur le juge encore améliorable.

Cette amélioration est le vrai travail des prochaines semaines, plus que le choix d’un modèle. Les poids ouverts progressent. Les preuves de paiement existent déjà sur le réseau principal. Tor existe depuis longtemps. La pièce rare est la politique qui décide quoi taire. Elle ne se télécharge pas comme une bibliothèque. Elle se rédige, se teste, se rate.

Ce que l’actualité du 4 octobre laisse ouvert

Au soir de l’annonce, plusieurs questions restent sans réponse publique. Le correctif Tor sera-t-il fusionné, et avec quels délais définitifs ? Le seuil de 100 tokens par seconde sera-t-il atteint sur le matériel visé, ou faudra-t-il un autre modèle local ? Une évaluation externe de la réécriture aura-t-elle lieu, sans exposer les dossiers ? Les recommandations produites seront-elles un jour comparées à un avis humain, ne serait-ce que pour écarter les conseils absurdes ?

Aucune de ces questions n’annule l’intérêt du geste. Elles empêchent de le transformer en produit. Un cofondateur qui montre ses propres frictions rend service. Un récit qui gommerait la latence, le correctif non mergé et l’absence d’audit rendrait le sujet moins clair. Ici, les frictions sont dans le message. C’est rare enough pour être noté, et assez concret pour être discuté sans mythologie.

Le calendrier resserré compte aussi. Présentation de zkAPI le 1er octobre. Essai personnel le 4 octobre. Proposition Tor encore ouverte le jour même. On est dans une séquence de jours, pas dans une feuille de route à cinq ans. Cela explique le ton d’atelier. Cela explique aussi pourquoi les chiffres de performance sont des constats de bureau, pas des benchmarks marketing.

Comment lire l’essai sans en faire une caution médicale

Le sujet attire parce qu’il mélange un nom connu, un outil nouveau et le corps. Ce mélange appelle une frontière. Rien dans le récit ne constitue un protocole de soin, une validation de régime ou une invitation à confier un dossier clinique à un agent. L’objet publié est une architecture de minimisation. Les conseils produits restent privés, non évalués, non reproductibles par un lecteur.

On peut s’intéresser au tuyau sans adopter la sortie. La question utile pour le secteur est ailleurs. Peut-on payer une inférence sans identité de facturation ? Peut-on interposer un modèle local avant un modèle de pointe ? Peut-on accepter, noir sur blanc, que Tor ne tient pas encore le rythme d’un agent ? Les trois réponses tenues le 4 octobre sont oui, oui, et pas encore. C’est déjà un cadre de travail.

Les équipes qui voudront s’en inspirer devront ajouter ce que l’essai n’a pas : un test de réidentification sur les prompts sortants, un journal de ce qui a été retiré, une limite claire sur les sujets médicaux, et un mode dégradé quand Tor ou le modèle local sont trop lents. Sans ces garde-fous, copier l’architecture copiera surtout l’illusion.

Une grille simple pour juger les annonces suivantes

Les prochains messages sur l’IA privée dans l’écosystème Ethereum reprendront sans doute les mêmes mots. Une grille courte évite de les prendre pour argent comptant. Elle reprend les trois portes, plus la question de la preuve.

• Contenu. Qui réécrit la demande, et selon quelle consigne publiée ?
• Paiement. Le dépôt est-il détaché de l’appel, ou seulement « compatible » avec un outil qui le permet ?
• Réseau. L’adresse habituelle est-elle masquée, et le circuit change-t-il entre les sessions ?
• Preuve. Une personne extérieure a-t-elle tenté de relier les prompts à un auteur ?
• Vitesse. Le montage reste-t-il utilisé quand il est lent, ou seulement décrit ?

Appliquée à l’essai du 4 octobre, la grille donne un résultat nuancé. Le contenu est filtré localement, sans publication de la consigne. Le paiement s’appuie sur un outil lancé trois jours plus tôt sur le réseau principal. Le réseau passe par Tor, avec une latence jugée excessive et un correctif non fusionné. La réidentification externe n’est pas documentée. La vitesse locale est dite insuffisante pour le confort. Ce n’est pas un échec. C’est un état des lieux.

Cet état des lieux vaut mieux qu’une promesse. Il montre où le temps d’ingénierie doit aller : consignes de réécriture, circuits plus rapides ou mieux adaptés, inférence locale au-dessus du seuil de patience. Le reste, la preuve de solde, est déjà posé. Le surprenant n’est pas que le paiement avance. C’est que le goulot soit devenu le texte et le chemin, c’est-à-dire les deux couches que la cryptographie du reçu ne couvre pas.

Ce que les utilisateurs de portefeuilles peuvent en tirer dès maintenant

Tout le monde ne fera pas tourner un modèle ouvert à côté d’un client Tor. Le réflexe transposable est plus modeste. Ne pas coller un export de santé, de messagerie ou de voyages dans un service distant payé avec un compte nominatif. Si un outil local peut résumer avant l’envoi, l’utiliser. Si un paiement peut être détaché, ne pas le remplacer par une carte « pour aller plus vite » sans y penser. Si un réseau masque l’adresse, accepter qu’il soit lent, ou assumer qu’on y renonce.

Le secteur crypto a longtemps traité la vie privée comme une option de transfert. L’essai déplace le sujet vers le calcul que l’on achète. Les mêmes personnes qui refusent d’afficher un solde en clair envoient parfois un dossier bien plus parlant à un modèle. L’incohérence n’est pas morale. Elle est pratique. Les outils de transfert sont devenus visibles. Les outils de minimisation des prompts commencent à peine à l’être.

zkAPI, dans ce paysage, est un morceau de rail, pas une application de santé. L’Open Anonymity Project et l’Ethereum Foundation le posent comme un moyen de payer des API mesurées sans lier les appels à une identité de dépôt. L’essai de Buterin est un usage parmi d’autres, choisi parce qu’il est exigeant. D’autres usages, plus neutres, profiteront du même rail avec moins de couches. Les usages intimes en demanderont davantage. Le 4 octobre sert à ne plus confondre les deux.

La suite probable, sans enjoliver le présent

Si le correctif entre dans la branche principale, les clients pourront router par Tor avec des délais explicitement plus longs. Cela ne réglera pas le souhait d’un déliement à chaque message. Buterin a déjà dit que Tor n’était pas dessiné pour cela, et que la latence rendait l’approche inefficace dans les tests actuels. Une suite crédible passe soit par un réseau plus adapté à des requêtes courtes et décorrélées, soit par l’acceptation que seule une session entière soit masquée, pas chaque tour de parole.

Côté modèle local, la marche de 20-30 vers plus de 100 tokens par seconde dépend du matériel, du cadre d’inférence et des prochaines variantes ouvertes. Le dépôt d’Alibaba indique déjà des chemins via vLLM et SGLang. Rien ne garantit que le seuil de confort soit franchi sur un ordinateur portable ordinaire. Tant qu’il ne l’est pas, l’intermédiaire privé restera un outil d’initiés patients.

Côté consignes, l’amélioration annoncée par l’auteur est la plus décisive et la moins visible. Un meilleur fichier de règles peut réduire la fuite sans nouveau théorème. Il peut aussi, s’il est trop strict, rendre les appels distants inutiles. Le bon réglage ne se décrète pas. Il se mesure, précisément par les tests que l’essai n’a pas encore montrés.

En attendant, le récit du 4 octobre tient en une scène nette. Un dossier personnel reste à la maison. Une petite modèle ouverte le résume maladroitement, pas assez vite. Une preuve sur Ethereum paie l’appel sans donner le nom du dépôt. Un oignon réseau ralentit le chemin et ne sépare pas encore chaque question. Au bout, un conseil de repas et de mouvement, non publié, non audité, un peu meilleur grâce aux grands modèles. Ce n’est pas une révolution clé en main. C’est la première fois que ces trois portes sont montrées ensemble, avec leurs grincements, par quelqu’un qui a les moyens de les ouvrir toutes.

Le secteur peut en faire deux lectures. La lecture presse s’arrêtera au nom et au mot privé. La lecture utile s’arrêtera aux chiffres de latence, au correctif non fusionné, à la phrase sur les trois protections, et à l’aveu que la prudence abîme l’aide. C’est cette seconde lecture qui prépare les outils suivants. Les annonces qui reprendront le vocabulaire sans reprendre les limites auront déjà été devancées par un autotest plus modeste, et plus clair, que la plupart des lancements.