Venice Token dévoile ce que ChatGPT vous cache sur vos prompts

Chaque fois que vous saisissez un prompt dans une IA centralisée, votre texte part vers un serveur, y est traité… et consigné.

L’entreprise qui opère ce serveur peut le lire. Elle peut le stocker, l’utiliser pour entraîner ses futurs modèles, et le transmettre aux régulateurs sur demande.

La plupart des utilisateurs acceptent ce compromis sans vraiment y réfléchir.

Mais une nouvelle vague de projets blockchain — dont Venice est aujourd’hui la figure de proue — construit une architecture radicalement différente : un système où ni l’opérateur du réseau, ni aucun tiers, ne peut voir ce que vous avez demandé.

Pour comprendre comment cela fonctionne, il faut distinguer deux problèmes. D’abord, où vont vos données lorsque vous interrogez une IA. Ensuite, quels outils cryptographiques peuvent réellement empêcher ces données de fuiter.

Les réponses sont plus concrètes qu’on ne l’imagine.

En résumé

Les fournisseurs d’IA centralisés comme OpenAI journalisent par défaut les prompts utilisateurs, ce qui leur donne une visibilité totale sur vos requêtes.

L’inférence d’IA privée on-chain achemine les requêtes via des réseaux de nœuds décentralisés et s’appuie sur du hardware de calcul confidentiel pour traiter les données sans les exposer, même à l’opérateur du nœud.

Venice Token (VVV) est aujourd’hui l’implémentation la plus scrutée de ce modèle, en exécutant l’inférence sur Base avec une approche « privacy-first » dès la couche applicative.

Les principaux arbitrages portent sur la vitesse, le coût et la taille des modèles : l’inférence privée reste plus lente et plus chère qu’un appel d’API classique.

Cette architecture est la plus critique pour les requêtes médicales, juridiques, financières ou sensibles pour l’entreprise, où la confidentialité du prompt est non négociable.

Pourquoi l’« inférence » est le vrai goulet d’étranglement de la vie privée

Un modèle d’intelligence artificielle vit en deux temps. Le premier est la phase d’entraînement, où il apprend sur un vaste jeu de données. Le second est la phase d’inférence, où le modèle entraîné reçoit un nouvel input — votre question — et produit une réponse. L’inférence, c’est ce qui se passe chaque fois que vous utilisez ChatGPT, Claude ou Gemini.

C’est au moment de l’inférence que la confidentialité se brise. Pendant l’entraînement, vos données personnelles ne sont pas en jeu. Mais à l’inférence, votre prompt exact doit être visible par le système qui le traite, au moins le temps du calcul. On ne peut pas poser une question à un modèle « dans une boîte noire » sans que le modèle la lise d’une façon ou d’une autre.

Dans les systèmes centralisés, ce problème n’est tout simplement pas traité en priorité.

Les conditions d’utilisation d’OpenAI autorisent l’entreprise à exploiter les inputs de l’API pour la supervision de sûreté, et potentiellement à les utiliser pour améliorer les modèles, sauf si vous négociez explicitement un opt-out dans un contrat entreprise. La quasi-totalité des utilisateurs grand public ne le fait pas. Résultat : un volume massif de pensées sensibles se retrouve stocké dans des bases de données privées.

Le problème de confidentialité de l’inférence d’IA n’est pas théorique : c’est l’état par défaut de toutes les grandes plateformes d’IA centralisées aujourd’hui.

L’inférence décentralisée renverse l’hypothèse. Au lieu de faire confiance à un serveur central, la vraie question devient : peut-on rendre tout nœud d’un réseau distribué incapable de lire votre prompt, tout en lui faisant exécuter le modèle qui y répond ?

Comment fonctionne réellement la journalisation dans l’IA centralisée

Quand vous envoyez un prompt à une API d’IA centralisée, la requête transite en HTTPS jusqu’à l’infrastructure du fournisseur. Ce chiffrement protège les données en transit : un tiers sur le réseau ne peut pas les intercepter en clair. Mais une fois la requête arrivée sur le serveur, la couche HTTPS est retirée.

Le logiciel du fournisseur voit alors le texte en clair. À partir de là, c’est lui qui décide de ce qu’il en fait.

La plupart des offres entreprises proposent des modes à rétention zéro, où les prompts ne sont pas conservés une fois la session terminée. Microsoft Azure OpenAI Service, par exemple, permet aux clients corporate de configurer des endpoints où les inputs ne sont pas écrits sur disque.

Mais ces options exigent un contrat payant et une configuration active. Par défaut, côté grand public, les données sont conservées.

La journalisation intervient à plusieurs niveaux. Les logs applicatifs capturent la requête brute. L’infrastructure de déploiement du modèle peut mettre en cache les prompts pour des raisons de performance. Les filtres de sûreté analysent le contenu avant et après génération. Chaque couche est un système supplémentaire où vos données existent en clair. Même avec des politiques de suppression strictes, ces données ont existé sur des machines qui peuvent, en théorie, être auditées, piratées ou faire l’objet d’une requête judiciaire au moment du traitement.

Les incitations économiques aggravent le phénomène. Un modèle entraîné sur les requêtes réelles des utilisateurs est plus performant. Les entreprises qui collectent les prompts disposent d’un avantage structurel pour améliorer leurs produits. Cela crée une tension permanente entre la confidentialité de l’utilisateur et l’optimisation business, une tension que les fournisseurs centralisés ne peuvent pas résoudre complètement par nature.

Les deux briques cryptographiques qui rendent l’inférence privée possible

Deux grandes techniques permettent d’exécuter une inférence sans exposer les données d’entrée à la partie qui calcule. Elles ne s’excluent pas et, dans la pratique, les implémentations les combinent souvent.

Les Trusted Execution Environments (TEE) sont des enclaves sécurisées au niveau matériel, intégrées dans les processeurs modernes. SGX chez Intel et SEV-SNP chez AMD sont les exemples les plus déployés. Un TEE crée une zone mémoire isolée que le système d’exploitation hôte, l’opérateur du nœud, voire même le fondeur du processeur ne peuvent pas lire. Le code exécuté dans un TEE est « attesté » : une partie distante peut vérifier cryptographiquement qu’un programme donné, non modifié, tourne bien dans une enclave authentique. Votre prompt entre chiffré dans l’enclave, le modèle s’exécute à l’intérieur, et la sortie en ressort chiffrée. L’exploitant de la machine ne voit rien passer en clair.

Le chiffrement entièrement homomorphe (FHE) adopte une autre approche. Il permet de réaliser des calculs sur des données chiffrées, sans jamais les déchiffrer. Le modèle travaille directement sur le ciphertext et produit une sortie chiffrée que seul le demandeur initial peut déchiffrer. Sur le plan théorique, c’est élégant ; sur le plan pratique, c’est d’une lourdeur extrême. Faire tourner un grand modèle de langage en FHE est aujourd’hui des ordres de grandeur plus lent qu’une inférence classique. Les déploiements actuels se limitent à de petits modèles ou à des sous-composants ciblés plutôt qu’à des réponses LLM complètes.

Les TEE permettent dès aujourd’hui une inférence privée à des vitesses proches de la normale. Le FHE offre des garanties théoriques supérieures, mais reste trop lent pour la plupart des cas d’usage LLM en production à mi‑2026.

Une troisième voie émerge : le calcul multipartite sécurisé (MPC), où les poids du modèle et l’input utilisateur sont fragmentés entre plusieurs parties qui coopèrent pour produire une sortie sans que personne ne voie l’ensemble des données. Le MPC est très flexible mais implique une coordination lourde.

Comment Venice bâtit une inférence privée sur blockchain

Venice fonctionne sur la blockchain Base, un réseau Layer 2 Ethereum décrit dans ce guide Layer 2. L’architecture de Venice dissocie trois fonctions que les acteurs centralisés regroupent généralement : l’hébergement du modèle, le calcul d’inférence et le règlement des paiements.

Les opérateurs de nœuds du réseau Venice apportent leur puissance de calcul GPU.

Ils téléchargent des poids de modèles open source — Llama, Mistral et d’autres modèles libres — et traitent les requêtes d’inférence à partir de ces poids. Comme les modèles sont ouverts, il n’y a pas de secret industriel à protéger côté modèle. Le problème de confidentialité porte exclusivement sur les entrées et sorties des utilisateurs.

Venice s’appuie sur des TEE au niveau des nœuds participants. Lorsqu’un utilisateur envoie une requête via l’interface Venice, celle‑ci est routée vers un nœud dont l’enclave TEE l’exécute. Le système hôte contrôlé par l’opérateur ne peut pas inspecter le contenu de l’enclave. Des preuves d’attestation permettent au client de vérifier que le bon logiciel d’inférence, non altéré, tourne bien avant d’envoyer le prompt.

Venice Token (VVV) est l’actif utilitaire du réseau. Il donne accès à la capacité d’inférence, les stakers bénéficiant de priorités de passage. Le token ajoute une couche économique à l’infrastructure de confidentialité : les fournisseurs de calcul perçoivent des frais, et les utilisateurs dépensent ou stakent du VVV pour accéder à l’inférence privée. On dépasse ainsi le simple argument marketing : l’architecture TEE impose la confidentialité au niveau matériel, indépendamment de la volonté de l’équipe Venice ou de ses opérateurs.

Plus largement, on parle de décéntralisation de l’inférence d’IA, un créneau où Venice côtoie d’autres projets. Gensyn, io.net et Akash Network abordent tous le problème du GPU distribué, avec des garanties de confidentialité plus ou moins fortes. Venice se distingue par son choix de faire de la protection des prompts le critère de conception principal, et non une option secondaire.

Ce que l’opérateur de nœud voit… et ne voit pas

Il faut être précis, car le terme « privé » peut être trompeur. Dans une architecture à la Venice basée sur des TEE, la visibilité de l’opérateur de nœud est strictement bornée par le périmètre matériel.

Ce que l’opérateur de nœud ne peut pas voir : le texte en clair de votre prompt, les calculs intermédiaires du modèle, ni la sortie en clair avant qu’elle ne soit chiffrée pour vous être renvoyée.

Ce que l’opérateur de nœud peut voir : le fait que sa machine traite une requête (un job arrive), la taille de la requête et de la réponse en octets, le timing de la transaction, ainsi que l’adresse de wallet ou l’identifiant rattaché à la requête si celle‑ci n’est pas anonymisée davantage.

Autrement dit, le système… privé au sens fort pour le contenu : personne ne peut lire ce que vous avez demandé ni ce que le modèle a répondu. En revanche, ce n’est pas totalement anonyme au niveau des métadonnées. Un opérateur peut constater que l’adresse X a envoyé un prompt de 340 tokens à 14h22 UTC et reçu une réponse de 1 200 tokens. Une analyse de ces schémas dans le temps pourrait permettre d’inférer des éléments sensibles sur l’usage, même sans accès au contenu.

Pour l’immense majorité des cas d’usage — un cabinet d’avocats qui interroge sur des dossiers confidentiels, un médecin qui vérifie des diagnostics différentiels, une entreprise qui analyse des données financières propriétaires — la confidentialité du contenu est le critère déterminant. La fuite de métadonnées est un risque secondaire, qui peut être atténué par des outils réseau additionnels comme un VPN ou des schémas d’identité à divulgation nulle de connaissance.

Les systèmes fondés sur des TEE garantissent la confidentialité du contenu par le matériel. La protection des métadonnées nécessite une anonymisation supplémentaire, au niveau applicatif, que les implémentations actuelles laissent à la charge de l’utilisateur.

Les vrais arbitrages entre vitesse, coût et taille de modèle

L’inférence privée n’est pas gratuite. Le surcoût vient de plusieurs sources, et les comprendre permet d’évaluer si le compromis vaut la peine pour votre cas d’usage.

Vitesse. Les enclaves TEE imposent un surcoût lié à l’isolation mémoire. La pagination chiffrée et les échanges d’attestation ajoutent de la latence par rapport à un GPU bare-metal faisant tourner un serveur d’inférence classique.

En pratique, l’inférence via TEE sur une machine AMD EPYC moderne avec SEV-SNP est environ 10 % à 30 % plus lente qu’une inférence sans TEE sur un matériel équivalent, selon les benchmarks publiés par l’équipe SUAVE de Flashbots et la documentation développeur d’AMD. C’est significatif, mais loin d’être rédhibitoire pour la plupart des applications conversationnelles.

Coût. Les réseaux de calcul décentralisés n’égalent pas encore l’économie unitaire des grappes de GPU des hyperscalers. Amazon, Google et Microsoft opèrent à une échelle telle que le coût marginal d’inférence tombe à une fraction de centime pour mille tokens. Les réseaux décentralisés n’atteignent pas cette densité d’utilisation. Venice et des réseaux similaires facturent en général l’inférence avec une prime par rapport aux API centralisées. Cette prime est le prix explicite de la confidentialité.

Taille de modèle. Les enclaves TEE disposent d’une mémoire protégée limitée. Charger intégralement un modèle de 70 milliards de paramètres à l’intérieur d’une enclave sécurisée n’est, à ce stade, pas réaliste sur la plupart des architectures.

Dans la réalité, les implémentations utilisent soit des modèles plus compacts (7 à 13 milliards de paramètres), soit une approche hybride où les couches d’entrée-sortie sensibles tournent dans le TEE tandis que les multiplications de matrices non sensibles s’exécutent en mémoire non protégée, soit le chiffrement des poids du modèle plutôt qu’un chargement complet en enclave. C’est déterminant, car les modèles de frontière les plus avancés, de la classe GPT-4 avec des centaines de milliards de paramètres, ne peuvent pas aujourd’hui être exécutés en mode pleinement privé sous les contraintes actuelles des TEE.

En toute transparence, l’inférence privée aujourd’hui vous offre une forte confidentialité avec des modèles open source de 7 à 13 milliards de paramètres, pour un coût 2 à 5 fois supérieur aux API centralisées. Si votre cas d’usage rentre dans ces paramètres, l’architecture est déjà déployable en production.

Qui a réellement besoin d’inférence IA privée on-chain ?

Tous les utilisateurs d’IA n’ont pas besoin d’un tel niveau de protection. Mais certains profils sont exposés à des risques immédiats liés à la journalisation des prompts, que l’inférence privée permet de neutraliser directement.

Les juristes et responsables conformité utilisent déjà massivement l’IA pour l’analyse de documents, la revue de contrats et la recherche de jurisprudence. Soumettre des échanges avec des clients à un service centralisé qui journalise les entrées pose un risque sur le secret professionnel et peut contrevenir aux règles déontologiques de certains barreaux américains. L’inférence privée supprime ce tiers journalisant.

Les soignants et chercheurs en santé sont soumis à HIPAA, qui encadre strictement la transmission et le stockage des données de santé protégées. Utiliser un ChatGPT standard pour la documentation clinique crée une exposition réglementaire. Un système d’inférence fondé sur un TEE, qui peut prouver qu’il ne stocke jamais les données patients, change radicalement le profil de risque.

Les analystes financiers et traders manipulant de l’information privilégiée ne peuvent légalement injecter ces données dans des systèmes susceptibles de les consigner, de les voir exfiltrées ou découvertes. L’inférence privée leur permet d’exploiter l’IA sur des données de deals sensibles sans générer de traçabilité réglementaire.

Les individus en environnement de haute surveillance — journalistes, militants, dissidents — peuvent avoir besoin d’assistance IA pour des recherches sensibles sans laisser de trace de leurs requêtes. Les outils standards deviennent un passif. L’inférence privée, non.

Les entreprises qui protègent leurs secrets industriels peuvent effectuer des requêtes R&D, analyses concurrentielles et recherches sur des formules propriétaires via l’IA, sans risquer que ces informations soient stockées sur un serveur tiers susceptible d’être piraté, assigné en justice ou aspiré.

Pour l’utilisateur grand public — rédaction d’e-mails, création de contenus, réponses à des questions de culture générale — le surcoût de l’inférence privée n’est probablement pas justifié à ce stade. L’architecture finira par descendre en gamme à mesure que les coûts baissent, mais la proposition de valeur immédiate se concentre clairement sur les cas d’usage à forts enjeux évoqués ci‑dessus.

En guise de conclusion

L’inférence IA privée on-chain répond à un problème que la plupart des utilisateurs n’avaient pas identifié.

Par défaut, les fournisseurs d’IA centralisés journalisent les prompts. Cela donne aux entreprises — et potentiellement aux États — une fenêtre sur certaines des réflexions les plus sensibles de leurs utilisateurs.

La réponse n’est pas de renoncer à l’IA, mais de changer le lieu où l’inférence s’effectue.

Les environnements d’exécution de confiance (TEE) permettent dès aujourd’hui à un opérateur de nœud décentralisé de faire tourner un modèle de langage sur votre prompt sans jamais pouvoir le lire.

Le matériel porte la garantie de confidentialité à un niveau qu’aucune politique d’usage ni conditions générales ne peuvent égaler.

Venice Token est l’implémentation la plus visible de cette architecture à ce jour. Mais il s’agit en réalité d’un motif de conception plus large, appelé à se diffuser dans l’ensemble du secteur de l’IA décentralisée à mesure que le coût du calcul GPU recule et que le matériel TEE gagne en maturité.

À découvrir ensuite : Le dernier match sur terre battue de Wawrinka s’inscrit dans l’essor d’un marché de prédiction à 3 millions d’utilisateurs