Après l'interdiction de Fable, DeAI deviendra-t-il le prochain point chaud ?

Auteur : CoinW Research

Le 25 juin, la controverse autour de la sécurité des modèles, du contrôle d’accès et de la fuite des capacités d’Anthropic s’est intensifiée. Anthropic a accusé publiquement Alibaba d’avoir systématiquement extrait des informations liées aux capacités du modèle Claude via près de 25 000 comptes frauduleux. Cette accusation a rendu le processus de rétablissement de Fable 5, déjà bloqué, encore plus complexe, et a remis au premier plan une question centrale : lorsque les modèles de pointe possèdent des capacités accrues en cybersécurité, analyse de code et automatisation, l’accès aux modèles, le contrôle des comptes, l’utilisation transfrontalière et la fuite des capacités sont tous intégrés dans un cadre réglementaire et de gouvernance de plateforme.

Pour comprendre cette controverse, il faut revenir au 12 juin. Ce jour-là, Claude Fable 5 et Mythos 5, propriétés d’Anthropic, ont soudainement été suspendus, attirant rapidement l’attention de l’industrie de l’IA et du marché des cryptomonnaies. Fable 5 était à l’origine un modèle de niveau Mythos ouvert au public, avec des restrictions de sécurité supplémentaires pour limiter les abus dans des domaines à haut risque comme la cybersécurité et la biosécurité. Mais après la découverte d’une faille contournable dans la protection de sécurité, le gouvernement américain a limité l’accès des ressortissants étrangers aux modèles concernés via des contrôles à l’exportation, et Anthropic a ensuite étendu les restrictions d’accès à tous les utilisateurs. Presque au même moment, Microsoft a également temporairement restreint l’utilisation de ce modèle par ses employés en raison des exigences de conservation des données de Fable 5. Cette série de réactions montre que les préoccupations des clients professionnels sont passées des capacités du modèle elles-mêmes à la conservation des données, à la protection du code interne et des secrets commerciaux.

Depuis, les attentes de rétablissement de Fable 5 n’ont cessé de fluctuer. Le 18 juin, des responsables du gouvernement américain ont demandé à Anthropic de prouver, avant de republier le modèle, que ses protections de sécurité ne pouvaient pas être contournées. Le 22 juin, la page de documentation API correspondante est réapparue dans les résultats de recherche, mais le point d’accès réel n’a toujours pas été restauré. Les prévisions de Polymarket montrent que le marché parie toujours sur un rétablissement final de Fable 5 : la probabilité d’un redémarrage aux États-Unis avant fin juillet est d’environ 90 %, et avant fin août d’environ 94 %. Ces fluctuations montrent que le droit d’accès à l’IA de pointe n’est plus seulement une question de lancement ou de retrait de produit, mais le résultat combiné de la preuve de sécurité, des décisions politiques et de l’exécution par la plateforme.

Source : https://x.com/AnthropicAI/status/1936225551521312934

Ainsi, le point clé de l’incident Fable 5 n’est pas de savoir quand un modèle particulier retrouvera son accès, mais plutôt la mise en évidence concentrée des limites structurelles de l’IA centralisée de pointe : plus un modèle est puissant, plus il est susceptible d’être contraint par des examens de sécurité, des contrôles à l’exportation, la conformité des données d’entreprise et les autorisations de la plateforme. Pour l’industrie de la cryptomonnaie, cela offre précisément une occasion de repenser DeAI. L’IA décentralisée vise à réduire le contrôle d’une seule plateforme sur l’accès aux modèles, le traitement des données et les processus d’exécution en utilisant des ressources de calcul ouvertes, l’inférence distribuée, les incitations on-chain, le calcul confidentiel et l’exécution vérifiable. En suivant cette piste, le CoinW Research commencera par revenir sur l’incident Fable, puis analysera successivement trois types de lacunes de l’IA centralisée, les problèmes que DeAI peut résoudre, trois voies techniques pour l’IA vérifiable, et la différenciation des projets représentatifs à différents niveaux d’infrastructure, avant de conclure sur les limites réelles et les opportunités à long terme de DeAI.

1. Analyse de l’incident Fable : plus qu’une simple mise hors ligne d’un modèle

Fil conducteur : des chercheurs d’Amazon ont découvert une voie de contournement des garde-fous

La sensibilité de Fable 5 et Mythos 5 vient de leurs capacités en cybersécurité. Mythos 5 est principalement ouvert aux institutions partenaires sélectionnées pour détecter et corriger des vulnérabilités logicielles ; Fable 5 est une version publique plus largement diffusée, conservant certaines capacités de niveau Mythos tout en bloquant la génération de contenu offensif via des restrictions de sécurité.

Le problème réside dans ces restrictions. Selon les informations publiques, des chercheurs d’Amazon ont découvert lors de tests que les garde-fous de Fable 5 pouvaient être contournés. Le PDG d’Amazon, Andy Jassy, a ensuite exprimé ses inquiétudes à la Maison-Blanche. Peu après, des hauts responsables de la Maison-Blanche ont eu plusieurs échanges avec le PDG d’Anthropic, Dario Amodei, en 24 heures, exigeant que l’entreprise retire volontairement le modèle et corrige la faille. Anthropic considérait que le contournement était plus un problème localisé et ne constituait pas une « jailbreak » généralisée ; la Maison-Blanche estimait que le risque de sécurité justifiait une intervention au niveau de la sécurité nationale.

Le gouvernement américain a ensuite imposé des contrôles à l’exportation sur Fable 5 et Mythos 5, interdisant aux ressortissants étrangers d’utiliser les modèles concernés. Comme Anthropic ne pouvait pas identifier de manière fiable la nationalité et l’identité de tous les utilisateurs à court terme, l’entreprise a finalement suspendu l’accès à tous les clients. Cette étape a transformé l’incident Fable, d’une controverse sur la sécurité des modèles à un événement concernant le droit d’accès à l’IA de pointe.

Détail 1 : Double usage des capacités de niveau Mythos

Le cœur de la controverse Fable ne réside pas dans les questions-réponses ordinaires, mais dans la frontière de plus en plus floue entre « capacités défensives » et « capacités offensives ». Un modèle de cybersécurité peut aider les entreprises à découvrir des vulnérabilités et à réparer des systèmes, mais aussi aider les attaquants à trouver des points d’entrée et à exploiter automatiquement les failles.

C’est aussi la raison de l’intervention rapide du gouvernement. Si un modèle ne peut qu’écrire des textes ou générer du code, la pression réglementaire est relativement limitée ; dès qu’il possède des capacités avancées de découverte et d’exploitation de vulnérabilités, il est placé dans le cadre de la sécurité nationale. Fable 5, en tant que version publique, visait à réduire les risques via des garde-fous ; lorsque ces garde-fous peuvent être contournés, les régulateurs y voient une « porte d’entrée vers des capacités à haut risque potentiellement activables ».

Détail 2 : La restriction d’utilisation par Microsoft révèle les risques côté entreprise

Une autre piste de l’incident Fable vient de Microsoft. Microsoft a temporairement restreint l’utilisation de Claude Fable 5 par ses employés en raison des nouvelles exigences de conservation des données d’Anthropic. Les prompts et les sorties de Fable 5 peuvent être conservés pendant 30 jours, et les contenus marqués par le système de sécurité peuvent l’être plus longtemps. Microsoft craignait que les employés, en utilisant le modèle, n’entrent des données clients, des informations d’entreprise ou du code interne, et que si ces contenus étaient conservés et soumis à une enquête, cela pourrait entraîner des risques de conformité et concurrentiels.

Ce détail est crucial. Il montre que les risques de l’IA de pointe sont passés de « le modèle est-il dangereux ? » à « l’entreprise peut-elle contrôler ses propres données ? ». Lorsqu’une entreprise utilise l’IA, elle ne se soucie pas seulement de la qualité des réponses, mais aussi de savoir si les prompts sont sauvegardés, si les données peuvent être supprimées, si l’appel au modèle est conforme en interne, et si le fournisseur peut accéder à des informations sensibles lors d’enquêtes de sécurité.

Détail 3 : Les contrôles à l’exportation soulèvent la question de la souveraineté de l’IA

L’incident Fable a également déclenché un débat plus large sur la souveraineté de l’IA. La question centrale soulevée par le marché est la suivante : d’un côté, le gouvernement américain souhaite promouvoir l’IA américaine à l’étranger ; de l’autre, il peut, via des contrôles à l’exportation, interrompre temporairement l’accès aux modèles de pointe à l’étranger, ce qui pousse les clients mondiaux à réévaluer la fiabilité de l’offre d’IA américaine.

Cela signifie que l’impact de l’incident Fable ne se limitera pas à Anthropic. Les entreprises, les États et les développeurs doivent repenser la chaîne d’approvisionnement de l’IA : si les modèles principaux proviennent d’un petit nombre d’entreprises américaines, la stabilité de l’accès est-elle garantie ? Si les flux de travail des entreprises dépendent fortement d’un modèle, un changement de politique peut-il provoquer une interruption d’activité ? Si les règles de sécurité et de conformité sont déterminées en interne par la plateforme, les utilisateurs externes peuvent-ils obtenir suffisamment de preuves ?

À ce stade, l’incident Fable n’est plus un simple retrait isolé d’un modèle. Ce qui a véritablement déclenché la discussion sur DeAI, c’est que trois lacunes structurelles de l’IA centralisée ont été simultanément amplifiées : l’accès est déterminé conjointement par la plateforme et la réglementation, le flux de données reste à l’intérieur de la plateforme, et le processus d’exécution du modèle et des agents manque de preuves externes vérifiables.

2. Les lacunes de l’IA centralisée : accès, données et exécution non vérifiables

Accès incontrôlable : le service de modèle peut être interrompu par des règles externes

L’incident Fable prouve que les modèles de pointe ne sont plus de simples services Internet ordinaires. Ils sont soumis à la sécurité nationale, aux contrôles à l’exportation, à l’identification, aux retours des partenaires et aux relations géopolitiques. Une fois qu’une entreprise intègre la R&D, l’audit de code, la gestion des risques, le service client ou des tâches d’automatisation à un seul modèle, une suspension soudaine de ce modèle devient un problème de continuité d’activité.

Ce type de risque a été sous-estimé par le marché par le passé. Les utilisateurs comparaient souvent les capacités, les prix et la rapidité des modèles, mais rarement la probabilité qu’un modèle devienne soudainement indisponible. Après le retrait de Fable, ce risque a été réellement démontré. À l’avenir, lors du choix d’un fournisseur d’IA, les entreprises pourraient envisager des solutions de redondance, des modèles de secours et la capacité de basculer entre fournisseurs, comme elles le feraient pour un service cloud.

Données invisibles : les entreprises ont du mal à confirmer comment les informations sensibles sont traitées

La raison principale de la restriction de Fable 5 par Microsoft était la conservation des données. Plus un modèle est puissant, plus il est susceptible d’être utilisé avec du code source, des données clients, des documents financiers, des documents stratégiques et des bases de connaissances internes. Dans ce cas, la conservation des prompts et des sorties, leur durée, qui y a accès et s’ils sont utilisés pour des enquêtes de sécurité deviennent des facteurs déterminants pour qu’une entreprise adopte ou non un modèle.

Les services d’IA centralisés placent généralement ces processus à l’intérieur de la plateforme. Les utilisateurs ne peuvent que lire les conditions générales, mais il leur est difficile de vérifier techniquement si les données ont réellement été supprimées, si elles sont entrées dans un classificateur, ou si elles ont été consultées dans le cadre d’une enquête. Les entreprises ont besoin de déclarations de confidentialité plus claires et de preuves d’exécution vérifiables de l’extérieur.

Exécution invérifiable : il est difficile pour les parties externes de juger si la couche de sécurité fonctionne réellement

La controverse de Fable portait également sur la couche de sécurité. Le modèle se présente comme ayant des limitations, mais il est difficile pour un utilisateur externe de vérifier si ces limitations sont correctement appliquées à chaque fois. La version du modèle, les prompts système, le mécanisme de routage, le classificateur de sécurité et le filtre de sortie sont tous réalisés à l’intérieur de la plateforme. L’utilisateur voit la réponse, mais pas le chemin d’exécution derrière.

Dans les scénarios à faible risque, cette opacité peut être acceptable ; dans les domaines financiers, de cybersécurité, d’audit de code, de transactions on-chain et de gestion d’actifs, elle devient un problème de responsabilité. Les utilisateurs doivent savoir si le modèle a été remplacé, si l’environnement d’exécution est fiable, si les entrées et sorties ont été falsifiées, et si l’agent IA a outrepassé ses droits. La lacune structurelle de l’IA centralisée est là : les capacités augmentent, mais le mécanisme de vérification externe ne mûrit pas en parallèle.

Ainsi, la question à laquelle DeAI doit répondre devient plus concrète : existe-t-il des points d’entrée alternatifs en cas de coupure d’accès ? Lorsque des données sensibles doivent entrer dans le flux de travail du modèle, peut-on fournir un environnement de traitement prouvable ? Lorsque les agents IA commencent à exécuter des transactions, appeler des contrats et gérer des autorisations, peut-on laisser une chaîne de preuves imputables ? L’importance de l’IA vérifiable commence à se manifester à ce niveau.

3. Ce que DeAI peut résoudre : de l’accès ouvert à l’exécution de confiance

Si l’incident Fable a trouvé un écho dans l’industrie de la cryptomonnaie, c’est parce qu’il touche à une question familière : une infrastructure critique peut-elle être arrêtée par un seul acteur ? La valeur fondamentale de Bitcoin ne réside pas seulement dans le prix de l’actif, mais dans la fourniture d’un réseau mondial, sans permission et résistant à la censure pour le transfert de valeur. L’IA devient une nouvelle infrastructure critique, et lorsque les capacités des modèles commencent à influencer le code, la sécurité, les processus d’entreprise et l’exécution des actifs, le marché se demande naturellement : ne faut-il pas aussi une couche d’accès et d’exécution pour l’IA plus ouverte, commutable et vérifiable ?

Cela ne signifie pas que toute IA doit être entraînée via un réseau décentralisé, ni que la technologie peut complètement contourner la réglementation. Une évaluation plus réaliste est que les utilisateurs auront besoin simultanément de deux types de capacités : d’une part, l’intelligence forte fournie par les modèles centralisés de pointe, et d’autre part, la redondance d’accès, la protection de la vie privée et l’exécution vérifiable offertes par les réseaux ouverts. Lorsque des modèles comme Fable sont soudainement suspendus pour des raisons politiques ou de règles de plateforme, le marché comprendra à nouveau le besoin d’une IA sans permission. Actuellement, la valeur de DeAI se manifeste principalement à trois niveaux :

Résoudre le point d’accès unique : réduire la dépendance à un seul fournisseur de modèles

DeAI peut d’abord atténuer le problème du point d’accès unique. L’incident Fable montre qu’un modèle de pointe peut être soudainement coupé pour des raisons politiques ou de règles de plateforme. Concrètement, DeAI peut réduire ce risque de trois manières : premièrement, en introduisant un routage multi-modèles permettant aux utilisateurs de basculer entre des modèles centralisés, des modèles open source et des réseaux d’inférence décentralisés ; deuxièmement, via un marché de modèles ouvert, où différents modèles et services d’inférence peuvent être librement connectés, réduisant ainsi le contrôle d’un seul fournisseur ; troisièmement, via des points d’entrée d’inférence privée et des combinaisons de modèles locaux, permettant aux utilisateurs de conserver des chemins de secours pour les tâches critiques.

À court terme, DeAI ne pourra peut-être pas entraîner un autre Claude. Sa valeur plus réaliste est de permettre aux flux de travail critiques de ne pas dépendre entièrement d’un seul point d’entrée de modèle. Pour l’utilisateur ordinaire, c’est un choix d’accès ; pour l’entreprise, c’est une continuité d’activité ; pour les pays et les régions, c’est une partie de la souveraineté de l’IA.

Résoudre la confiance dans les données : permettre aux calculs sensibles de s’exécuter dans un environnement prouvable

La deuxième valeur de DeAI est d’offrir une plus grande prouvabilité pour les calculs sensibles. Lorsque les entreprises et les applications on-chain appellent l’IA, elles impliquent souvent des données privées, du code, des stratégies de trading ou des actifs d’utilisateurs. Les environnements d’exécution de confiance (TEE), les attestations à distance, le calcul confidentiel et les audits on-chain permettent aux utilisateurs de confirmer que les données sensibles sont traitées dans un environnement protégé.

L’objectif de cette voie est de permettre aux utilisateurs d’obtenir des preuves sur l’environnement d’exécution sans exposer leur vie privée. Par exemple, une entreprise peut exiger que l’inférence IA se déroule dans un TEE et confirmer la version du code et du modèle via une attestation à distance ; une application on-chain peut enregistrer le hash de la tâche, le résultat d’exécution et la preuve sur la chaîne ; l’utilisateur peut confirmer que l’environnement de calcul n’a pas été remplacé arbitrairement sans divulguer les données brutes. Pour la finance, la santé, la conformité d’entreprise et la gestion d’actifs on-chain, cela est plus important que de simplement rechercher un modèle plus puissant.

Résoudre la responsabilité d’exécution : laisser une chaîne de preuves pour les actions des agents IA

La troisième valeur de DeAI est d’établir une chaîne de responsabilité pour les agents IA. À l’avenir, les agents IA appelleront des portefeuilles, des échanges, des services cloud, des systèmes d’entreprise et des contrats on-chain. Ils passeront de la réponse à des questions à l’exécution directe de tâches. Le marché aura alors besoin non seulement des sorties du modèle, mais aussi des journaux d’exécution, des enregistrements d’autorisations, des chemins d’appel, des flux de fonds et des mécanismes de responsabilisation en cas d’erreur.

Les systèmes on-chain sont mieux adaptés pour enregistrer ces comportements. Grâce aux journaux on-chain, aux dépôts de garantie, aux mécanismes de contestation et aux sanctions économiques, DeAI peut transformer l’exécution de l’IA, d’une « opération interne à la plateforme » en un comportement traçable, vérifiable et imputable. Par exemple, chaque fois qu’un agent appelle un contrat, lit des données, initie une transaction ou soumet un résultat, une trace vérifiable peut être laissée ; lorsqu’un nœud soumet un résultat erroné, il peut être vérifié par un mécanisme de contestation et sanctionné. C’est précisément ce besoin que l’incident Fable a mis en évidence.

4. Comment DeAI établit une exécution de confiance : trois voies pour l’IA vérifiable

D’après les projets existants et les pistes de recherche, l’IA vérifiable n’est pas une technologie unique, mais une combinaison de solutions autour de « l’environnement d’exécution, du résultat de calcul et du comportement d’exécution ». Chaque voie résout des problèmes différents et a un rythme de déploiement différent.

Vérifier l’environnement d’exécution : confirmer d’abord où le modèle s’exécute

La première voie est l’environnement d’exécution de confiance (TEE). Son objectif est de prouver que le modèle s’exécute dans un environnement matériel protégé. Sans voir le serveur en coulisses, l’utilisateur peut confirmer via une attestation à distance que le code, le modèle et l’environnement d’exécution n’ont pas été falsifiés arbitrairement. Ce type de solution est plus proche des applications réelles, adapté aux modèles privés d’entreprise, à l’exécution d’agents IA, à la gestion des risques financiers et aux tâches d’automatisation on-chain.

Son avantage réside dans un coût et une latence relativement maîtrisables, permettant de résoudre d’abord les problèmes de « où le modèle s’exécute-t-il ? les données sont-elles traitées dans un environnement protégé ? ». Sa limite est qu’il dépend encore du fabricant de matériel, du TEE et du mécanisme d’attestation à distance. Si le matériel sous-jacent ou le mécanisme d’attestation échoue, la base de vérification en est affectée.

Vérifier le résultat de calcul : faire accompagner les sorties de l’IA d’une preuve

La deuxième voie est la preuve cryptographique, les directions courantes incluant les preuves à connaissance nulle (zk) et zkML. Son objectif est de générer un justificatif de calcul vérifiable pour le calcul IA, permettant à un tiers de confirmer que le résultat provient bien du processus de calcul spécifié sans avoir à réexécuter l’intégralité du modèle.

Cette voie est plus proche d’une « preuve mathématique ». Son avantage est une plus grande certitude, adapté aux scénarios où l’exactitude du résultat est cruciale ; sa limite est le coût élevé de génération de la preuve, la latence élevée, et le support encore limité pour les grands modèles de pointe. Des recherches sur l’inférence vérifiable légère ont commencé à utiliser l’échantillonnage et les mécanismes d’engagement pour réduire les coûts, mais le passage de la recherche à un déploiement commercial à grande échelle prendra du temps.

Vérifier le comportement d’exécution : donner un coût aux erreurs et aux excès de pouvoir

La troisième voie est l’incitation économique et les journaux audibles. Elle n’exige pas qu’une preuve complète soit générée à chaque inférence IA ; l’essentiel est de faire payer les résultats erronés et les comportements malveillants via des mécanismes de contestation, de recalcul, de vérification par échantillonnage, de sanctions sur les dépôts de garantie et d’enregistrements on-chain. Un nœud qui soumet un faux résultat peut voir son dépôt confisqué, tandis que celui qui découvre l’erreur peut recevoir une récompense.

Cette voie est particulièrement importante pour les agents IA. À l’avenir, les utilisateurs ne se contenteront pas de voir les réponses du modèle, ils voudront aussi savoir quelle interface l’agent a appelée, quelles autorisations ont été utilisées, s’il y a eu des excès de pouvoir, et si l’exécution a été conforme aux autorisations. Les journaux audibles transforment le comportement de l’IA, d’une opération en arrière-plan, en une trace enregistrée et potentiellement plus facile à déployer que la vérification complète d’un grand modèle.

5. Projets représentatifs : DeAI se différencie en différentes couches d’infrastructure

En suivant les trois voies de vérification mentionnées précédemment, les projets DeAI se différencient en différentes couches d’infrastructure : Bittensor et Gensyn sont plus orientés vers les réseaux d’offre d’intelligence, Venice est plus orienté vers le point d’entrée utilisateur, tandis qu’OpenGradient et Ritual sont plus proches de la couche de calcul vérifiable et d’exécution on-chain. Ces différences montrent également que DeAI est un écosystème combiné autour de l’accès, de la vie privée, de la preuve et de l’exécution.

5.1 Bittensor : filtrer l’offre d’intelligence machine via des mécanismes de sous-réseaux

X : https://x.com/bittensor

En tant que réseau pionnier et à l’écosystème relativement vaste dans l’IA décentralisée, Bittensor représente la voie du marché ouvert de l’intelligence. Il est composé de nombreux sous-réseaux, chacun étant un marché d’intelligence machine relativement indépendant : les mineurs produisent des biens numériques (puissance de calcul, stockage, inférence IA, entraînement, prévisions financières, etc.) ; les validateurs évaluent la qualité des productions des mineurs ; les créateurs de sous-réseaux conçoivent les mécanismes d’incitation ; les détenteurs de TAO peuvent soutenir les validateurs via le staking. Le réseau distribue finalement les récompenses TAO aux participants considérés comme les plus contributeurs.

En termes de structure capitalistique, Bittensor diffère des projets de financement par actions typiques. Il n’a pas eu de levée de fonds privée ou d’ICO traditionnelle ; le protocole central est maintenu par la Fondation Opentensor, et TAO n’a pas de part réservée aux premiers investisseurs. Cela ne signifie pas l’absence de capitaux : Polychain a participé à l’incubation de Bittensor dès 2019 et a accumulé environ 200 millions de dollars de positions en TAO via le marché secondaire, le minage et la validation ; Digital Currency Group, via sa filiale Yuma, a acheté en continu, devenant l’un des plus grands détenteurs, avec environ 500 000 TAO, soit environ 2,4 % du total.

En termes d’activité on-chain, la page des sous-réseaux de Taostats montre que le volume total de transactions sur 24 heures du marché des sous-réseaux Bittensor est d’environ 193 000 TAO, dont les tokens Alpha de chaque sous-réseau (jetons natifs de sous-réseau reflétant la tarification, le staking et les flux de capitaux) représentent environ 139 000 TAO (71,93 %) ; les transactions liées à Root TAO (l’actif TAO natif du réseau principal, servant d’actif de base pour entrer et sortir des tokens Alpha) représentent environ 54 300 TAO (28,07 %). Cela montre que l’activité de trading provient principalement des actifs des sous-réseaux spécifiques, et non du côté TAO principal.

Source : https://x.com/bittensor/status/1886073193101304298

Parmi les sous-réseaux, les plus remarquables incluent SN3 τemplar et SN64 Chutes : SN3 τemplar se concentre sur l’entraînement décentralisé de grands modèles ; son équipe a terminé l’entraînement du modèle Covenant-72B (72 milliards de paramètres) sur Bittensor Subnet 3, représentant la capacité d’entraînement du réseau. SN64 Chutes se concentre sur l’inférence IA sans serveur, ayant traité plus de 9 100 milliards de tokens cumulés, avec un pic quotidien de plus de 50 milliards de tokens, ce qui en fait un sous-réseau d’inférence très utilisé. Par ailleurs, CoinW a lancé une zone dédiée à l’écosystème TAO et a déjà listé en premier trois sous-réseaux : Chutes-SN64, Gradients-SN56 et Targon-SN4.

Bittensor est passé d’un réseau IA unique à un marché d’intelligence ouvert multi-tâches, multi-actifs et à courbes d’incitation multiples, décomposant différents biens numériques (inférence IA, entraînement, données, prévisions financières, puissance de calcul, stockage) en marchés indépendants, où l’offre est assurée par les mineurs, l’évaluation par les validateurs, et la distribution des récompenses en tokens.

Plus intéressant encore, certains sous-réseaux d’inférence commencent à renforcer la couche d’évaluation et de vérification des résultats. Cette « vérification » est plus proche d’un mécanisme de filtrage de qualité interne au réseau : les mineurs soumettent des sorties de modèles ou des résultats de tâches, les validateurs évaluent la qualité via des scores, des backtests, des vérifications par échantillonnage, des tâches de référence et des règles d’incitation, ce qui influence finalement les récompenses TAO des mineurs. La valeur de Bittensor réside dans le fait de transformer « qui peut fournir un service d’intelligence » en un problème de concurrence ouverte, la difficulté étant que la qualité varie considérablement d’un sous-réseau à l’autre, et que les normes de vérification et les mécanismes anti-triche déterminent si le réseau peut réellement filtrer des services IA de haute qualité.

5.2 Venice : point d’entrée IA privé côté utilisateur

X : https://x.com/AskVenice

Venice est plus orienté vers le point d’entrée applicatif de DeAI. Il intègre plusieurs capacités IA (texte, image, vidéo, audio, code, recherche) et met l’accent sur l’accès privé ou anonyme. Au niveau des modèles, Venice prend en charge Claude, Google, DeepSeek, OpenAI, Mistral, Meta, Qwen, Grok, Kimi, etc., tout en fournissant une API compatible OpenAI, qui peut s’intégrer aux stacks d’outils d’agents, aux appels de fonctions, à la recherche web et à la génération multimodale.

Venice a été lancé en mai 2024 par Erik Voorhees, fondateur de ShapeShift, ce qui lui confère un fort soutien fondateur. Son financement et ses incitations reposent davantage sur les tokens que sur les tours de capital-risque traditionnels. En janvier 2025, Venice a émis son token natif VVV sur le réseau Base, avec une offre initiale de 100 millions d’unités, dont environ la moitié distribuée via un airdrop aux premiers utilisateurs et à la communauté crypto-AI, le reste étant détenu par l’équipe, les pools de liquidité et un fonds d’incitation. Ensuite, Venice a lancé le token DIEM, formant une structure à double token : chaque DIEM correspond à un quota API fixe quotidien, et ne peut être frappé que par les détenteurs de VVV, liant ainsi la demande de tokens à la consommation réelle de puissance de calcul de la plateforme.

Revenons au produit lui-même : la différence de Venice réside dans la stratification de la vie privée. Il propose quatre types d’architecture de confidentialité : accès anonymisé à des modèles tiers, conservation zéro donnée sur des modèles open source auto-hébergés, réduction de la visibilité côté plateforme via TEE, et chiffrement de bout en bout. Pour l’utilisateur ordinaire, c’est plus facile à comprendre que les réseaux de preuve sous-jacents : ce qui compte, c’est de savoir s’il peut accéder, si ses données seront conservées, si l’appel sera utilisé pour l’entraînement ou la censure de la plateforme. Après l’incident Fable, ce type de besoin deviendra plus direct, car la désactivation d’un modèle n’est pas seulement un problème pour les développeurs, elle affecte aussi la confiance des utilisateurs ordinaires dans la continuité des outils IA.

Venice répond au problème du point d’entrée utilisateur de DeAI. Le réseau de preuve sous-jacent résout « le calcul peut-il être vérifié », tandis que le point d’entrée IA privé résout « l’utilisateur peut-il utiliser de manière sécurisée, continue et avec peu de friction ». Venice ne peut pas remplacer zkML ou la couche d’exécution TEE, ni éliminer complètement les restrictions des fournisseurs de modèles, mais il montre que la voie de commercialisation de DeAI ne part pas forcément de la couche la plus basse : ce que les utilisateurs perçoivent en premier, ce sont souvent l’accessibilité, la commutabilité, la faible friction et la protection de la vie privée.

5.3 OpenGradient : hébergement de modèles, inférence vérifiée et agents on-chain dans un même réseau

X : https://x.com/opengradient

OpenGradient est plus proche d’un réseau de calcul IA vérifiable full-stack. Il tente d’intégrer l’hébergement de modèles, l’appel à l’inférence, le paiement x402, les agents on-chain et la couche de preuve dans un même réseau de développeurs, plutôt que de fournir un seul point d’entrée de modèle. L’objectif est de placer le déploiement, l’appel, le règlement et la preuve de confiance du modèle dans un même flux de travail pour les développeurs.

En termes de financement, OpenGradient a bouclé un tour de seed de 8,5 millions de dollars en 2024, mené par a16z, avec la participation de Coinbase Ventures, Symbolic Capital, Wintermute Ventures, GSR, etc. Les investisseurs couvrent à la fois le capital IA de la Silicon Valley, l’infrastructure de trading crypto et les teneurs de marché, une combinaison favorable pour faire progresser simultanément l’écosystème des développeurs, le règlement on-chain et le marché des ressources de calcul.

Selon les données on-chain, la page Portal d’OpenGradient montre que le réseau compte 4 448 modèles, environ 874 900 transactions d’inférence, environ 332 200 transactions x402, et une hauteur de bloc actuelle d’environ 1 599 860 ; sur les 30 derniers jours, environ 2 510 transactions par jour.

Source : https://x.com/opengradient/status/1885983257888587996

D’après les données produit, OpenGradient a déjà formé un chemin complet comprenant l’hébergement de modèles, l’appel à l’inférence, le paiement x402, les agents on-chain et la couche de preuve. On peut le considérer comme un marché de calcul IA destiné aux développeurs : une fois le modèle hébergé, il peut être appelé directement, l’appel génère des transactions et des paiements, et les résultats clés sont ensuite rendus plus fiables via zkML ou TEE.

L’avantage d’OpenGradient réside dans une chaîne produit relativement complète et la fourniture de données d’utilisation on-chain vérifiables. La prochaine étape consistera à observer deux questions : le nombre de transactions peut-il se transformer en paiements récurrents ? Le besoin de preuve peut-il couvrir le coût supplémentaire du calcul ? Le nombre de modèles et de transactions d’inférence peut augmenter rapidement via des incitations ; ce qui déterminera vraiment la valeur du réseau, c’est la volonté des développeurs de payer à long terme pour des appels stables, une exécution privée et des résultats vérifiables.

5.4 Gensyn : du réseau de puissance de calcul au marché de l’intelligence machine

X : https://x.com/gensyn

Gensyn est un projet qui se distingue par son background capitalistique et son ambition technique parmi les réseaux sous-jacents de DeAI. Initialement parti d’un réseau de puissance de calcul regroupant des GPU inactifs, il vise à se développer progressivement en un réseau d’intelligence machine plus complet, permettant à l’entraînement, à l’inférence, à la collaboration de modèles et aux services d’intelligence d’être appelés et échangés sur un réseau ouvert.

Du point de vue de la structure produit, Gensyn n’est plus une simple couche d’ordonnancement de GPU. Son composant AXL sert à l’échange de poids, de gradients et de signaux entre nœuds d’apprentissage machine ; l’identité et la réputation on-chain enregistrent les performances historiques des modèles, des agents et des nœuds de calcul ; le mécanisme de vérification sert à confirmer si une partie du calcul a été effectuée comme demandé. Le marché d’information Delphi de Gensyn teste en outre des scénarios où humains et agents IA participent ensemble à des prédictions, avec règlement par oracle IA.

En termes de financement, le background capitalistique de Gensyn est remarquable parmi les projets similaires. En 2022, Gensyn a bouclé un tour de seed de 6,5 millions de dollars, mené par Eden Block, avec la participation de Galaxy Digital, CoinFund, etc. ; en 2023, il a réalisé un tour de série A de 43 millions de dollars, mené par a16z, pour un total d’au moins 49,5 millions de dollars en financement public. Un cycle de R&D plus long et un soutien continu des principaux capitaux lui permettent de faire progresser simultanément plusieurs lignes techniques : entraînement distribué, marché de l’intelligence machine, identité on-chain et mécanismes de vérification.

Gensyn répond à la vulnérabilité de l’offre après une concentration excessive des capacités d’IA de pointe. L’incident Fable montre que l’accès aux modèles peut être rapidement interrompu entre politiques, zones géographiques et stratégies de sécurité des entreprises. Gensyn souhaite faire de l’intelligence machine un marché ouvert, accessible, compétitif et vérifiable, afin que l’entraînement de modèles, la collaboration de modèles, les transactions d’agents et les services d’intelligence machine ne dépendent pas entièrement d’une seule plateforme. Sa difficulté réside dans les exigences élevées de l’entraînement décentralisé en termes de bande passante, de synchronisation des données, de vérification des gradients et de conception des incitations ; à court terme, il est plus probable qu’il se concrétise d’abord dans des modèles verticaux, l’optimisation de modèles ouverts, la collaboration d’agents et les marchés de prédiction.

5.5 Ritual : transformer les tâches IA en exécution on-chain appelable et traçable

X : https://x.com/ritualnet

Ritual cible la couche d’exécution de l’IA, en mettant l’accent sur la manière dont les appels de modèles, les comportements d’agents et les tâches complexes peuvent être directement orchestrés, exécutés et réglés sur la chaîne, plutôt que de rester dans des boîtes noires hors chaîne. Ritual Chain utilise une architecture EVM avec des tâches machine vérifiables hors chaîne. Les tâches déterministes comme les transferts ordinaires et les lectures de stockage sont toujours exécutées de manière répliquée par l’EVM, tandis que les tâches coûteuses comme l’inférence LLM, les appels d’agents et la génération d’images sont exécutées dans un environnement TEE, puis les résultats sont liés à la requête originale et renvoyés sur la chaîne. Des contrats système tels que AsyncJobTracker, TEEServiceRegistry, Scheduler et AsyncDelivery gèrent respectivement l’état des tâches, l’enregistrement des exécutants, l’ordonnancement et le rappel des résultats. Ritual développe également Infernet, permettant aux smart contracts d’appeler des modèles et des calculs externes, positionnant le produit plus proche d’un « système d’exploitation d’exécution IA on-chain ».

En termes de financement, Ritual a bouclé un tour de 25 millions de dollars en 2023, mené par Archetype, avec la participation d’Accomplice, Robot Ventures, dao5, Avra, Hypersphere, etc. ; en 2024, Polychain est devenu investisseur stratégique, renforçant encore ses ressources en infrastructure crypto.

L’avantage de Ritual est d’être plus proche des besoins réels on-chain, adapté aux transactions automatisées, aux oracles IA, aux agents on-chain, aux paiements machine et à l’orchestration de tâches complexes. Il ne s’agit pas d’entraîner un modèle plus puissant, mais de permettre aux appels de modèles d’entrer dans le système de permissions et de règlement des smart contracts. Le risque réside dans le fait que le TEE dépend toujours d’une racine de confiance matérielle, et que la sélection des exécutants, la sécurité des rappels asynchrones et les barrières pour les développeurs nécessitent une validation continue. La question de savoir si Ritual peut atteindre une masse critique dépendra en fin de compte de la volonté des applications on-chain de confier des tâches IA de grande valeur à cette couche d’exécution.

6. Limites réelles : DeAI ne peut pas encore résoudre tous les problèmes

L’entraînement décentralisé reste confronté à des contraintes physiques

La valeur à long terme de DeAI doit reposer sur des limites réelles. Le pré-entraînement de grands modèles nécessite une bande passante extrêmement élevée, des clusters GPU stables, d’énormes quantités de données de haute qualité et un système d’ingénierie mature. Bien que les réseaux décentralisés puissent abaisser certains seuils de puissance de calcul, la communication sur Internet public, la coordination de matériel hétérogène et la qualité des ensembles de données peuvent affecter l’efficacité de l’entraînement. Cela ne diminue pas la valeur de DeAI. Une voie plus réaliste est la suivante : la couche d’entraînement sert d’abord les modèles de niche et les optimisations de modèles ouverts ; la couche d’inférence sert d’abord la vie privée, le coût et le routage multi-modèles ; la couche de vérification sert d’abord la preuve et l’audit dans les scénarios à haute valeur ; la couche d’exécution sert d’abord les agents on-chain et les tâches automatisées. La première direction de maturité pour DeAI pourrait être l’ensemble de l’infrastructure de confiance autour des appels de modèles.

La capacité de vérification a également des limites d’application claires

L’IA vérifiable a aussi des limites d’application claires. Les TEE peuvent prouver l’environnement d’exécution, mais ils nécessitent de faire confiance au matériel et au mécanisme d’attestation à distance ; zkML peut prouver le résultat du calcul, mais le coût et la latence restent des contraintes ; les incitations économiques peuvent faire payer les méfaits, mais nécessitent un mécanisme de contestation raisonnable, une conception de dépôt de garantie et une incitation des validateurs. Différentes solutions résolvent différents problèmes, et on ne peut pas résumer toutes les capacités sous une seule étiquette « vérifiable ». Par conséquent, à l’avenir, pour sélectionner un projet, il faudra examiner ce qu’il prouve spécifiquement : prouver l’identité du modèle, prouver l’environnement d’exécution, prouver le résultat en sortie, etc. Cela correspond à différentes frontières produit. Plus un projet est capable de clarifier ce qu’il prouve, plus il est susceptible de répondre aux besoins réels des entreprises et des applications on-chain.

L’enthousiasme du marché n’équivaut pas à une utilisation réelle

L’incident Fable générera une émotion autour du secteur DeAI, mais l’émotion ne se traduit pas directement en valeur à long terme. Ce qu’il faut vraiment observer, c’est si le projet a une demande de tâches continue, si les utilisateurs sont prêts à payer pour la vérifiabilité, si les revenus du réseau proviennent d’appels réels, et si le coût de vérification peut être inférieur à la prime de sécurité que les utilisateurs sont prêts à payer. Sans utilisation réelle, DeAI finira par revenir à des transactions conceptuelles.

7. Résumé : l’opportunité de DeAI réside dans la reconstruction d’une couche de confiance pour l’IA

Ce qui mérite vraiment l’attention dans l’incident Fable, ce n’est pas qu’un modèle particulier d’Anthropic ait été temporairement suspendu, mais que l’IA de pointe a pour la première fois clairement révélé la contradiction structurelle entre l’amélioration des capacités des modèles et la baisse de la stabilité de l’accès. Par le passé, le marché supposait par défaut qu’une capacité de modèle plus élevée entraînerait un taux d’adoption plus élevé ; mais l’incident Fable montre que lorsqu’un modèle possède des capacités hautement sensibles en cybersécurité, biosécurité, exécution de code, ses limites opérationnelles sont plus facilement intégrées dans les cadres de contrôle à l’exportation, de conformité d’entreprise et de sécurité nationale. Plus un modèle est puissant, plus la plateforme doit ajouter des couches de sécurité ; plus les couches de sécurité sont complexes, plus il est difficile pour les utilisateurs externes de vérifier le processus d’exécution ; plus la régulation s’implique, plus le droit d’accès au modèle cesse d’être un simple problème de produit. Cela signifie qu’à l’avenir, la concurrence dans l’IA ne se limitera pas aux capacités des modèles, mais s’étendra également à la stabilité de l’accès, à la contrôlabilité des données et à la fiabilité de l’exécution.

C’est là que DeAI doit être repensé. À court terme, DeAI ne pourra peut-être pas reproduire des modèles de pointe comme Claude, mais peut d’abord cibler les maillons les plus faibles de l’IA centralisée : le modèle peut-il être remplacé ? Les données peuvent-elles être protégées ? Le processus de calcul peut-il être prouvé ? Les actions des agents peuvent-elles être imputables ? Les projets DeAI vraiment précieux ne se contentent pas de transférer les capacités de l’IA sur la chaîne, mais décomposent le processus d’appel de l’IA en plusieurs maillons vérifiables : qui fournit le modèle, qui exécute l’inférence, comment le résultat est produit, qui supporte les erreurs, et si l’utilisateur peut basculer entre différents services. Par le passé, la plupart de ces questions étaient cachées à l’intérieur des plateformes centralisées ; à l’avenir, elles pourraient devenir un nouveau marché d’infrastructure.

De ce point de vue, l’IA vérifiable pourrait être la direction la plus prometteuse dans DeAI. L’IA passe d’un outil de génération de contenu à un agent intelligent capable d’exécuter des tâches. Lorsque l’IA est principalement utilisée pour générer du texte, les utilisateurs peuvent tolérer une certaine opacité ; mais lorsque l’IA commence à participer à l’audit de code, à la gestion d’actifs, aux appels de portefeuille, à l’exécution de transactions et aux interactions contractuelles, l’opacité se transforme en risque systémique. À l’avenir, le marché ne paiera pas seulement pour des capacités de modèle plus fortes, mais aussi pour un processus d’exécution prouvable, vérifiable et imputable.

Par conséquent, après l’incident Fable, la logique d’investissement dans DeAI doit passer du récit émotionnel au récit de vérification. Par le passé, le marché avait tendance à courir après les concepts IA, les noms de modèles et les points chauds à court terme ; à l’étape suivante, il faut plutôt se concentrer sur trois types d’indicateurs : existe-t-il une demande d’appels réels ? Le mécanisme de preuve vérifiable est-il en place ? Les utilisateurs sont-ils prêts à payer une prime pour une exécution de confiance ? Ce n’est qu’en réunissant ces conditions que l’IA vérifiable pourra passer d’un point chaud cyclique du marché des cryptomonnaies à une nouvelle couche de confiance pour l’ère de l’IA. Le cœur de la future concurrence dans l’IA ne sera plus seulement les capacités des modèles eux-mêmes, mais la capacité à appeler les modèles de manière stable, fiable et vérifiable dans un environnement ouvert. C’est là l’espace à long terme que DeAI peut réellement ouvrir.