---
id: 7
title: "Cadre d'informatique de confiance : comment ZK, TEE et MPC se répartissent le travail pour une IA vérifiable"
slug: trusted-computing-framework
date: 2026/08/12
summary: Ce que les preuves à divulgation nulle de connaissance, les environnements d'exécution de confiance et le calcul multipartite prouvent, supposent et coûtent respectivement — et comment ils se combinent avec le règlement on-chain et les réseaux de calcul plutôt que de se remplacer — ainsi que la manière de lire les objectifs d'ingénierie associés.
keywords: preuves à divulgation nulle,TEE,MPC,IA vérifiable,Bitroot
heroImage: /images/community-bg.png
---

Une chaîne peut garantir que les mises à jour d'état suivent des règles ; elle ne peut pas garantir automatiquement qu'une multiplication matricielle hors chaîne n'a pas été substituée. L'IA vérifiable place le calcul dans des frontières contrôlables. ZK, TEE et MPC sont souvent vendus comme un slogan à trois ; il est plus utile de séparer ce sur quoi chacun ancre la confiance — les mathématiques, le matériel ou l'honnêteté de seuil — et ce à quoi chacun convient : l'acceptation d'un entraînement, l'inférence confidentielle à faible latence, ou les clés et les statistiques conjointes.

## Définition du problème : quoi prouver

Pour les charges d'IA, les objets courants à prouver ou à protéger incluent :

- **Intégrité** : la sortie provient réellement du modèle et des entrées revendiqués (ou satisfait une politique).
- **Confidentialité** : les entrées, les poids ou les activations intermédiaires restent cachés des nœuds d'exécution.
- **Disponibilité** : certains nœuds peuvent tomber tandis que la signature ou la reconstruction réussit encore (schémas à seuil).

Il est rare qu'une seule technique soit la meilleure sur les trois. La composition est la norme — voir les rôles de la pile dans [La pile d'IA décentralisée](/fr/blog/aibitrootweb3ai). Inventaire des lacunes de confiance : [Convergence entre le Web3 et l'IA](/fr/blog/web3-ai-convergence).

## Preuves à divulgation nulle : vérifiables mathématiquement, coûteuses en circuits

ZK permet à un vérificateur de contrôler une affirmation sans réexécuter tout le calcul ni voir les entrées privées. Son atout on-chain est une vérification relativement bon marché (surtout pour la classe SNARK) ; la partie difficile est la génération de preuve et l'ingénierie des circuits.

- **zk-SNARK** : preuves compactes, vérification rapide ; certains schémas nécessitent une configuration de confiance — les cérémonies MPC peuvent réduire la confiance en une seule partie.
- **zk-STARK** : pas de configuration de confiance, un discours davantage post-quantique, des preuves plus volumineuses, des courbes de coût différentes.

Pour les grands modèles, le « ZK sur toute l'inférence » reste souvent peu viable économiquement ; plus réaliste est de circuitiser des contraintes critiques (règles de conformité, statistiques agrégées, liaison au hachage du modèle) ou de prouver un calcul échantillonné/replié. Les chiffres de performance dépendent fortement des circuits et des accélérateurs — traitez-les comme des objectifs d'ingénierie, et non comme des SLA universels. Exécuter des contrats de vérification ZK sur un EVM parallèle améliore le débit de règlement/vérification ; cela ne rend pas magiquement la génération de preuve moins chère.

## TEE : enfoncer la frontière dans le matériel, faire confiance à la puce et à la chaîne d'approvisionnement

Les TEE (par exemple SGX, TrustZone, SEV) recourent à une exécution isolée et à une attestation à distance pour que les utilisateurs puissent vérifier que le code a tourné dans une enclave / un monde sécurisé revendiqué. Ils conviennent à l'inférence sensible à la latence, aux opérations sur clés et à la confidentialité lorsque le coût complet du ZK n'est pas souhaité.

Les coûts incluent une surcharge de performance, des limites de mémoire/API, des canaux auxiliaires, un risque de chaîne d'approvisionnement et une dépendance au fournisseur pour la portabilité. La pratique honnête consiste en une **base de confiance minimale (TCB)** : seules les clés et les tranches sensibles entrent dans le TEE ; le reste demeure ordinaire, avec des contestations et des hachages de journaux. Comment les réseaux de calcul rattachent l'acceptation : [Calcul distribué GPU et edge](/fr/blog/gpuai).

L'attestation à distance doit elle-même entrer dans la machine à états : l'expiration, les listes de révocation des fournisseurs et la gouvernance du cas « on a attesté le mauvais code » ne disparaissent pas parce qu'un badge TEE a été apposé.

## MPC : personne ne voit le texte en clair complet ; les parties calculent ensemble

Le MPC (par exemple le partage de secret) permet à des parties de calculer conjointement sans révéler les entrées complètes. Usages typiques :

- **Clés à seuil** : fragmenter les clés privées ; agréger les signatures ; ne jamais matérialiser la clé complète.
- **Statistiques conjointes / mises à jour de type fédéré** : partager des gradients ou des agrégats, pas les jeux de données bruts.
- **Inférence à poids fragmentés** : rejoint la conception des droits — voir [Droits sur les actifs d'IA](/fr/blog/ai-data-ownership).

Les tours de communication et l'explosion du calcul dominent le coût ; le nombre de parties et le modèle d'adversaire (semi-honnête ou malveillant) changent nettement la faisabilité. Le MPC n'est pas « du cloud chiffré par défaut » ; c'est un outil pour des scénarios à forte valeur où les parties refusent de centraliser les données.

## Composer, ne pas empiler

| Besoin qui penche vers | Préférer d'abord | Coût principal |
|-------------------|--------------|-----------|
| Vérifiable publiquement, vérificateurs légers | ZK | Génération de preuve + circuits |
| Inférence confidentielle à faible latence | TEE (+ audit/contestation) | Confiance matérielle + canaux auxiliaires |
| Entrées multipartites jamais centralisées | MPC | Communication + complexité protocolaire |
| Règlement et litiges | Contrats on-chain + preuves/engagements | Latence de confirmation + gaz |

La chaîne (en particulier une couche de règlement à EVM parallèle) possède les machines à états des tâches et les paiements ; elle ne remplace pas la cryptographie ci-dessus — architecture : [Vue d'ensemble de l'architecture EVM parallèle de Bitroot](/fr/blog/bitrootevm). Routage hybride des tâches légères et lourdes : [Chaîne de blocs native pour l'IA](/fr/blog/ai-native-blockchain). La latence de confirmation et le TPS d'un testnet décrivent le substrat de règlement — guide de lecture : [Glossaire des métriques de performance](/fr/blog/performance-metrics-glossary).

## Inscrire le modèle de menace dans le choix

Avant de choisir, précisez si un adversaire peut contrôler le système d'exploitation de l'exécuteur, corrompre les prouveurs, combien de temps les secrets doivent tenir et quels budgets matériels de vérification existent. Le TEE aide quand les hôtes peuvent être compromis mais que l'attestation à distance est difficile à falsifier ; le ZK convient à une re-vérification publique de longue durée ; le MPC est presque incontournable quand les parties ne partagent jamais le texte en clair. « La sécurité d'entreprise » réduite à une note masque des dimensions incomparables. Lacunes des agents : [Convergence entre le Web3 et l'IA](/fr/blog/web3-ai-convergence).

L'exploitation doit aussi nommer qui prouve et qui vérifie : auto-preuve par les exécuteurs, marché de preuve indépendant, ou recalcul échantillonné par le protocole. Des rôles flous transforment l'attestation TEE et les preuves ZK en théâtre. Les transactions de vérification de preuve consomment du débit de règlement ; l'EVM parallèle aide ces transactions à suivre — il n'abaisse pas l'asymptotique de la génération de preuve. Place dans la pile : [La pile d'IA décentralisée](/fr/blog/aibitrootweb3ai).

Les circuits et le code d'enclave nécessitent aussi une gouvernance des versions : des circuits de preuve périmés, des mesures non renouvelées ou des changements de microcode du fournisseur peuvent briser aujourd'hui le chemin de vérification d'hier. Les hachages de version appartiennent aux métadonnées de tâche et devraient s'aligner sur le versionnage des artefacts de [Droits sur les actifs d'IA](/fr/blog/ai-data-ownership).

## Les modèles de menace appartiennent au brief produit

La même combinaison ZK/TEE/MPC signifie des choses différentes selon que l'adversaire est semi-honnête ou malveillant. Des documents qui énumèrent des noms de technologies sans préciser le pouvoir de l'adversaire laissent les lecteurs incapables de juger la solidité du « vérifiable ». Indiquez au minimum si les exécuteurs peuvent retenir des entrées, s'ils peuvent se coaliser, comment fonctionnent l'expiration des preuves et la rotation des clés, et qui fait avancer les fenêtres de litige on-chain.

Pour les marchés d'inférence d'IA, un compromis courant consiste à utiliser des TEE ou un recalcul échantillonné pour la latence quotidienne, des preuves plus fortes pour les règlements à forte valeur, et des tâches d'entraînement s'appuyant sur des points de contrôle, la redondance et des pénalités économiques plutôt que sur un ZK complet par gradient. Routage hybride : [Chaîne de blocs native pour l'IA](/fr/blog/ai-native-blockchain). Rôle dans le règlement : [Vue d'ensemble de l'architecture EVM parallèle de Bitroot](/fr/blog/bitrootevm).

## Comptabilité des coûts : ne classez pas seulement « le degré de sûreté »

Le choix est souvent aplati en un classement de sécurité. Plus utile est le coût de preuve par tâche, les centiles de latence et le coût d'intervention humaine en cas d'échec. Le TEE peut gagner sur la latence p50 et perdre sur l'audit de chaîne d'approvisionnement ; le ZK peut gagner en vérifiabilité publique et faire la queue à la génération de preuve ; le MPC peut gagner sur le « ne jamais centraliser les données » et perdre sur la charge opérateur.

Rassemblez ces trois coûts dans un même tableau, ajoutez le gaz de règlement et la latence de confirmation, et jugez seulement alors si un flux d'IA est économiquement reproductible. Glossaire : [Glossaire des métriques de performance](/fr/blog/performance-metrics-glossary). Cycle de vie du calcul : [Calcul distribué GPU et edge](/fr/blog/gpuai).

L'IA vérifiable mûrit lorsque les défaillances et les litiges peuvent répondre : où la confiance est ancrée, comment les preuves sont soumises et comment l'état on-chain converge. Sans cela, le cadre reste une diapositive.

## Contrat d'interface avec le règlement

Les preuves, les citations d'attestation ou les signatures MPC doivent devenir des entrées compréhensibles par les contrats. Convenez des champs qui vont on-chain, de ceux qui ne sont que des engagements, de la manière dont l'état de la tâche évolue en cas d'échec de vérification, et de l'annulation automatique éventuelle des preuves expirées. Des interfaces floues laissent une cryptographie robuste se diluer dans une « confirmation manuelle » au niveau applicatif. Un EVM parallèle rend ces transitions rapides ; il ne génère pas les preuves.

## À retenir

La valeur d'un cadre d'informatique de confiance est d'offrir des options d'intégrité et de confidentialité discutables pour le calcul d'IA, avec des hypothèses de confiance explicites pour chaque option. Il n'y a pas de solution miracle — seulement un choix guidé par le modèle de menace. Toute affirmation selon laquelle ZK/TEE/MPC serait « la sécurité d'entreprise en un clic » devrait être ramenée à : sous des hypothèses énoncées, certains risques diminuent. Ceci ne constitue pas un conseil en investissement.

## Pour aller plus loin

- [La pile d'IA décentralisée](/fr/blog/aibitrootweb3ai)
- [Calcul distribué GPU et edge](/fr/blog/gpuai)
- [Convergence entre le Web3 et l'IA](/fr/blog/web3-ai-convergence)