--- id: 6 title: "La pile d'IA décentralisée : pourquoi la couche d'exécution décide si le Web3 et l'IA peuvent fonctionner ensemble" slug: aibitrootweb3ai date: 2026/07/28 summary: La convergence du Web3 et de l'IA dépasse l'empilement de récits. Cet article suit le comportement on-chain des agents d'IA, l'ordonnancement du calcul et la vérifiabilité des résultats pour montrer pourquoi la couche d'exécution est souvent le premier goulot d'étranglement d'une pile d'IA décentralisée — et comment les capacités associées de Bitroot s'articulent. keywords: pile d'IA décentralisée,Web3,agent d'IA,couche d'exécution,Bitroot heroImage: /cms-media/file/1The%20Future%20of%20Decentralized%20AI%20Stack.jpg --- Mettre le Web3 et l'IA sur la même diapositive est facile ; les faire fonctionner sur la même chaîne est difficile. L'IA veut du débit, une faible latence et un calcul orchestrable ; le Web3 veut de la vérifiabilité, une résistance à la manipulation et une responsabilité claire. Ces objectifs ne sont pas naturellement compatibles. Cet article laisse de côté les slogans et découpe une « pile d'IA décentralisée » en couches — montrant pourquoi l'exécution est souvent la première couche à s'enrayer. ## Ce qui manque à l'IA n'est pas des modèles, mais un environnement d'exécution digne de confiance L'entraînement et l'inférence grand public restent concentrés dans quelques clouds. Le problème n'est pas seulement la dépendance à un fournisseur : les appelants peuvent rarement vérifier de manière indépendante quelle version de modèle a été exécutée, quelles entrées ont été consommées, ou si les sorties ont été altérées. Pour des applications de chat, cela peut être acceptable ; pour des agents qui rééquilibrent, règlent et déclenchent des contrats, une boîte noire constitue un risque systémique. Le Web3 devrait apporter la vérifiabilité, mais la plupart des couches d'exécution de chaînes publiques supposent encore « qu'un humain clique occasionnellement sur une transaction ». Les agents peuvent émettre des rafales de transactions interdépendantes : devis, fractionnement d'ordres, appels inter-protocoles, rapprochement a posteriori. Si la confirmation est lente, la gestion des conflits grossière et les frais volatils, les agents se dégradent soit vers une orchestration hors ligne avec de rares règlements — soit échouent sous la congestion. Pourquoi les EVM monothread peinent : [Le goulot d'étranglement du monothread de l'EVM](/fr/blog/evm-single-thread-bottleneck). ## Vue en pile : cinq couches, une mission chacune Vu comme une pile plutôt qu'un « récit full-stack », l'IA décentralisée a besoin d'environ cinq capacités découplées : 1. **Règlement et exécution des contrats** : qui gagne les courses à l'état, comment les conflits convergent. Sans finalité rapide et prévisible, l'orchestration des agents au-dessus n'a aucun sens. 2. **Ordonnancement du calcul** : répartir l'entraînement et l'inférence vers des GPU hétérogènes ou des nœuds edge ; enregistrer les métadonnées de tâche et les preuves d'achèvement — sans prétendre « entraîner un modèle de 100 milliards de paramètres dans chaque bloc ». 3. **Calcul vérifiable** : ZK, TEE ou MPC pour que des tiers puissent contrôler par échantillonnage ce qui a été calculé — voir [Cadre d'informatique de confiance](/fr/blog/trusted-computing-framework). 4. **Droits sur les données et les modèles** : contributeurs, versions de modèles et répartitions de revenus nécessitent des règles exécutables, et non des promesses de livre blanc — voir [Droits sur les actifs d'IA](/fr/blog/ai-data-ownership). 5. **Applications et agents** : stratégie, contrôles des risques, humain dans la boucle ; gardez le calcul lourd hors ligne ou sur un réseau dédié ; laissez le règlement et les changements d'état critiques on-chain. Le poids narratif de Bitroot repose principalement sur la couche 1 (EVM parallèle optimiste) et sur les jointures avec les couches 2 et 3 : la chaîne ordonne et règle ; le réseau de calcul porte la charge lourde ; l'informatique de confiance couvre les contrôles ponctuels et les frontières de confidentialité. Positionnement : [Positionnement de Bitroot](/fr/blog/bitroot-positioning). Interface de calcul : [Calcul distribué GPU et edge](/fr/blog/gpuai). Inventaire des capacités « natif pour l'IA » : [Chaîne de blocs native pour l'IA](/fr/blog/ai-native-blockchain). ## Pourquoi la couche d'exécution est particulièrement décisive On blâme souvent « le gaz est cher » ou « pas d'opcodes IA natifs ». Un mode de défaillance plus courant : le consensus a déjà ordonné les transactions, mais l'exécution ne suit pas — ou s'effondre vers un comportement sériel sur les contrats chauds. Pour les agents, cela signifie : - **Latence imprévisible** : la même stratégie dérive sous différentes congestions ; les contrôles des risques se cassent. - **Taxe de composabilité** : les flux atomiques multi-protocoles déclenchent davantage de conflits et de réexécutions ; les points chauds écrasent le débit — voir [Points chauds de conflit et charges de travail](/fr/blog/parallel-evm-workload-hotspots). - **Coût de vérification croissant** : si les nœuds ne peuvent pas relire efficacement les résultats parallèles, la vérification décentralisée ne reste que sur le papier. Ainsi, l'exécution parallèle, le découplage consensus/exécution et la détection explicite des conflits ne servent pas « à faire des affiches de TPS » — ils donnent aux entités automatisées un substrat de règlement planifiable. Cartes : [Vue d'ensemble de l'architecture EVM parallèle de Bitroot](/fr/blog/bitrootevm), [Pipeline BFT et découplage de l'exécution](/fr/blog/bitroot-pipeline-bft), [Parallélisation optimiste](/fr/blog/bitrootevm-). Dans des conditions de testnet, les documents Bitroot ont cité des objectifs et résultats d'ingénierie de l'ordre de milliers à dizaines de milliers de TPS par shard et une confirmation d'environ une seconde (parfois inférieure à la seconde) ; les chiffres dépendent du matériel, de la charge et du taux de conflit. Il ne s'agit pas de performances stables de mainnet, ni d'une promesse de rendement. Comment lire les métriques : [Glossaire des métriques de performance](/fr/blog/performance-metrics-glossary). ## Pièges narratifs à surveiller - **Mythes de l'entraînement on-chain** : le pré-entraînement complet a presque toujours lieu hors ligne ou sur des réseaux dédiés ; les chaînes conviennent aux tâches, aux paiements et aux empreintes de vérification. - **Le minage de calcul comme rendement** : les réseaux GPU distribués peuvent réduire les taux d'inactivité ; ce ne sont pas des retours stables. - **Des slogans de compatibilité au lieu d'ingénierie** : la véritable compatibilité EVM repose sur le bytecode et l'outillage — voir [Ce que signifie la compatibilité EVM](/fr/blog/evm-compatibility-explained). - **La « convergence » qui masque les lacunes de confiance** : inventaire dans [Convergence entre le Web3 et l'IA](/fr/blog/web3-ai-convergence). ## Quelle couche construire en premier Avec des ressources limitées, privilégiez : un règlement prévisible sous charge automatisée, puis les tâches/paiements avec acceptation légère, puis TEE/ZK selon un modèle de menace, puis les droits et marchés complexes. Un centre commercial de modèles bâti sur un règlement instable ne fait qu'amplifier les litiges. Compromis : [Compromis décentralisation–performance](/fr/blog/decentralization-performance-tradeoff) ; entrée pour le public : [Qui devrait lire sur l'EVM parallèle](/fr/blog/who-should-read-parallel-evm). ## Comment les défaillances se propagent entre les couches Les piles aident en découplant ; les défaillances voyagent tout de même par les interfaces. Une acceptation de calcul vague fait que le règlement paie fidèlement la mauvaise partie ; des droits manquants laissent les applications d'agents traiter les conditions de la plateforme comme vérité de référence ; l'effondrement des conflits d'exécution casse même une orchestration de stratégie parfaite, sur les frais et la latence. Dessiner cinq couches ne concerne pas les noms de modules — il s'agit de spécifier les entrées, l'acceptation et l'endroit où l'état s'arrête en cas de défaillance pour chaque interface. Pour les développeurs, un ordre d'intégration raisonnable est : stabiliser d'abord les machines à états des tâches et des paiements sur l'EVM parallèle, puis y rattacher l'ordonnancement du calcul et les preuves, et seulement ensuite peaufiner l'expérience utilisateur des agents. Partir d'un chatbot et remonter vers une chaîne oblige presque toujours à revoir la latence de confirmation et les sorties non vérifiables. Contraintes de compatibilité : [Ce que signifie la compatibilité EVM](/fr/blog/evm-compatibility-explained). ## Grille d'évaluation pour la lecture des documents de projet Pour les affirmations d'« IA décentralisée », vérifiez au minimum : si le règlement rapporte le taux de conflit et le coût de relecture — pas seulement le TPS de pointe ; si le calcul décrit l'acceptation et les contestations — pas seulement le nombre de GPU ; si les droits incluent des mécanismes de révocation et de paiement — pas seulement des frappes d'images ; si l'informatique de confiance énonce un modèle d'adversaire — pas seulement des empilements de noms. Lisez les documents liés à Bitroot selon la même grille : EVM parallèle et Pipeline BFT pour le règlement, calcul et informatique de confiance pour le travail lourd hors ligne et les contrôles ponctuels, droits pour l'exécution des règles. Toute phrase unique affirmant que « le L1 d'IA est prêt » devrait être redécoupée en cases à cocher de cette grille. Positionnement : [Positionnement de Bitroot](/fr/blog/bitroot-positioning). Le rôle de la carte des piles est de réduire les erreurs de catégorie : n'utilisez pas le règlement pour résoudre l'entraînement, le calcul pour résoudre la finalité, ou des NFT de droits pour résoudre l'acceptation. Une fois les catégories clarifiées, le Web3×IA dispose d'interfaces discutables. ## Ordre de lecture avec les articles de mécanismes Pour le substrat de règlement : goulot d'étranglement du monothread et carte de scalabilité → trois voies parallèles et introduction à l'OCC → cette carte de pile → vue d'ensemble et positionnement de l'EVM parallèle. Pour les produits d'IA : après la carte de pile, lisez les lacunes de confiance, l'informatique de confiance, les réseaux de calcul et les droits. Les deux parcours mènent au même fait : sans couche d'exécution prévisible, les récits supérieurs ne peuvent pas livrer de manière stable. ## À retenir Une pile d'IA décentralisée ne fonctionne que si l'intelligence reste dans des frontières vérifiables tandis que le règlement demeure assez rapide et prévisible. L'exécution est le premier segment que les agents mettent à l'épreuve. Les articles suivants détaillent l'architecture parallèle, l'informatique de confiance et les droits ; cet article ne trace que la carte en couches afin que « Web3 + IA » n'ait pas à porter tous les problèmes dans une seule phrase. ## Pour aller plus loin - [Convergence entre le Web3 et l'IA](/fr/blog/web3-ai-convergence) - [Vue d'ensemble de l'architecture EVM parallèle de Bitroot](/fr/blog/bitrootevm) - [Ce dont une chaîne de blocs native pour l'IA a besoin](/fr/blog/ai-native-blockchain)