Nvidia et Azure démocratisent le Confidential Computing

Le confidential computing a passé une décennie comme une curiosité de conférence en cryptographie — une fonctionnalité matérielle que les architectes d'entreprise classaient comme « intéressante, pas urgente ». Cela a changé en 2026. L'inférence IA multi-tenant a placé des données sensibles et des poids de modèles propriétaires sur les mêmes clusters GPU partagés, et le chiffrement au repos et en transit standard a cessé de suffire, car dès qu'un modèle s'exécute, les données d'entrée et les poids se retrouvent en clair en mémoire.

Le marché reflète ce basculement : les analystes estiment le marché du confidential computing à environ 16,7 milliards de dollars en 2026, contre environ 12,3 milliards en 2025, soit un taux de croissance supérieur à 35 % par an. Les services financiers représentent près de la moitié de l'adoption en entreprise, la santé un peu plus d'un tiers, et environ les trois quarts des agences fédérales américaines utilisent désormais une forme de technologie d'enclave sécurisée pour les workloads sensibles. Ce n'est plus une simple case à cocher de conformité de niche — cela devient la condition de base pour quiconque exécute de l'IA sur des données qu'il ne peut légalement ou contractuellement exposer.

Ce qui a réellement changé

Le déclencheur n'a été ni une brèche unique ni une régulation. Ce fut l'arrivée de workloads d'IA qui requièrent deux choses simultanément : les données sensibles du client (dossiers médicaux, positions de trading, données biométriques) et les poids de modèle propriétaires du fournisseur, colocalisés sur le même matériel, n'appartenant à aucune des deux parties seules. Un hôpital envoyant des données de patients à un modèle de diagnostic tiers a besoin d'être assuré que le fournisseur cloud et le fournisseur du modèle ne peuvent pas voir les données. Le fournisseur du modèle a besoin d'être assuré que l'hôpital ne peut pas extraire les poids. Aucune des deux parties ne fait confiance à l'infrastructure de l'autre, et aucune ne peut simplement « chiffrer et déchiffrer » pour s'en sortir, car le calcul lui-même doit avoir lieu sur des données non chiffrées à un moment donné — à moins que ce moment ne se produise à l'intérieur d'un matériel qu'aucune des deux parties ne contrôle.

Voilà le problème spécifique que les Trusted Execution Environments (TEE) résolvent : des régions mémoire isolées et chiffrées matériellement où le code et les données sont protégés même contre un hyperviseur compromis, un opérateur cloud ou un utilisateur root. En 2026, cette racine de confiance matérielle s'étend au-delà du CPU et entre dans le GPU pour la première fois à grande échelle.

Le matériel : les CPU et les GPU le font désormais tous les deux

Quatre architectures TEE dominent les déploiements actuels :

• Intel TDX (Trust Domain Extensions) — isole des VMs entières, largement utilisé sur les instances de VM confidentielles Azure et Google Cloud.
• AMD SEV-SNP (Secure Encrypted Virtualization–Secure Nested Paging) — l'option la plus déployée sur AWS, Azure et Google Cloud, privilégiée pour son overhead moindre sur les workloads limités par le calcul grâce au chiffrement mémoire accéléré matériellement AES-NI.
• ARM CCA (Confidential Compute Architecture) — plus récent, ciblant les appareils mobiles et edge où l'inférence confidentielle doit se faire en dehors du datacenter.
• Nvidia Hopper confidential computing — le H100 a été le premier GPU avec un TEE matériel ancré dans une racine de confiance sur puce ; le H200 l'étend. C'est l'élément qui a rendu l'inférence IA confidentielle viable, car il protège les données et les poids du modèle pendant que le GPU calcule, pas seulement lorsqu'ils résident en mémoire CPU.

L'histoire des performances ici est meilleure que ce que la plupart des ingénieurs supposent. Sur les workloads CPU limités par le calcul, SEV-SNP et TDX tournent tous deux avec un overhead d'environ 1 à 5 %. Sur le mode GPU confidentiel de Nvidia, des benchmarks indépendants placent l'inférence LLM typique entre 95 et 99 % du débit natif — pour la plupart des requêtes, l'overhead reste sous les 5 %, et il approche zéro pour les modèles plus grands et les séquences plus longues, car le coût du chiffrement est amorti sur davantage de calcul par octet déplacé à travers la frontière CPU-GPU.

Qui l'utilise réellement en production

Tous les trois grands hyperscalers livrent aujourd'hui une infrastructure IA confidentielle, pas comme une promesse sur une roadmap. Azure Confidential Computing associe Intel TDX et AMD SEV à des VMs GPU confidentielles construites sur les H100, commercialisées spécifiquement pour le déploiement LLM dans les secteurs réglementés. AWS propose Nitro Enclaves aux côtés des familles d'instances EC2 adossées à SEV-SNP. Google Cloud's Confidential Space et Confidential VMs ciblent le même cas d'usage, positionnés pour la collaboration multi-parties où aucune entité ne peut voir les données des autres.

Des déploiements concrets étayent cela. NTT DATA et IBM ont construit SimpliZCloud, une plateforme cloud hybride pour les institutions financières indiennes qui utilise le confidential computing pour protéger les données pendant le traitement, pas seulement le stockage. Le Département de la Défense américain a autorisé une infrastructure cloud adossée au confidential computing pour des opérations critiques dans plusieurs départements fédéraux. Ce ne sont pas des pilotes — ce sont des systèmes financiers et gouvernementaux de production où « nous avons chiffré la base de données » ne satisfait plus le niveau de conformité ou contractuel.

Le problème non résolu : l'attestation

C'est là que le récit mainstream devance la technologie. Le modèle de confiance du confidential computing repose sur l'attestation à distance — une preuve cryptographique qu'un workload s'exécute bien dans un TEE authentique et non modifié avant que vous lui envoyiez des données sensibles. Pour un TEE uniquement CPU, un seul fournisseur émet cette preuve. Pour l'inférence IA confidentielle, vous avez désormais besoin d'une attestation simultanée du fournisseur CPU et du fournisseur GPU, chacun avec sa propre chaîne d'approvisionnement, sa propre racine de confiance et ses propres outils de vérification. Les chercheurs en sécurité appellent cela un problème d'« attester composite », et il n'existe pas encore de standard unique pour le vérifier de bout en bout.

Cela s'aggrave : une enquête du Register publiée le 4 juillet 2026 a détaillé comment plusieurs schémas d'« attestation intra-handshake » proposés — où le TEE se prouve pendant le handshake TLS lui-même — restent vulnérables à des attaques par relais, où un client vérifie avec succès une enclave authentique et digne de confiance mais finit par envoyer du trafic chiffré à une enclave différente et malveillante. Aucune des sept approches cryptographiques testées jusqu'à présent ne comble complètement cette lacune. Ce n'est pas un simple bug d'implémentation ; c'est une faiblesse structurelle dans la manière dont la confiance est établie, et cela signifie que « nous utilisons le confidential computing » n'est pas en soi une affirmation de sécurité complète sans demander aussi comment l'attestation est vérifiée et par qui.

Quand en avez-vous réellement besoin

Le confidential computing résout un problème spécifique : protéger les données pendant qu'elles sont calculées, par une partie que vous ne faites pas entièrement confiance avec le matériel. Le chiffrement standard au repos et en transit reste suffisant lorsque votre propre infrastructure exécute le calcul et que vous contrôlez l'hyperviseur. Vous avez besoin de TEE quand l'une de ces conditions s'applique :

• Vous exécutez de l'inférence sur un GPU cloud tiers et vous devez exclure le fournisseur cloud lui-même de votre modèle de menace — pas seulement les attaquants extérieurs.
• Vous servez un modèle propriétaire à des clients qui pourraient sinon extraire les poids de la mémoire GPU pendant l'inférence.
• Plusieurs parties (par exemple, deux hôpitaux, ou une banque et un fournisseur de détection de fraude) doivent calculer conjointement sur des données combinées sans que l'une voie les entrées brutes de l'autre.
• Des obligations réglementaires ou contractuelles imposent explicitement un traitement isolé matériellement, ce qui est désormais courant dans les accords de partage de données de santé et certains contrats de services financiers.

Vous n'en avez probablement pas besoin pour des analyses internes sur votre propre infrastructure, pour des jeux de données publics ou déjà anonymisés, ni comme substitut à un contrôle d'accès de base et à une hygiène du chiffrement — ces problèmes se résolvent à moindre coût de manière conventionnelle, et les TEE ajoutent un coût opérationnel réel : des limites d'application refactorisées, une infrastructure d'attestation et un verrouillage fournisseur sur des générations spécifiques de matériel CPU/GPU.

À retenir

• L'inférence IA confidentielle est prête pour la production sur les trois grands clouds aujourd'hui, avec des TEE GPU basés sur H100/H200 offrant plus de 95 % des performances natives pour la plupart des workloads — la performance n'est plus le frein qu'elle était il y a deux ans.
• L'attestation, et non l'overhead de calcul, est le vrai problème d'ingénierie non résolu. Avant d'adopter le confidential computing, demandez spécifiquement à votre fournisseur comment il gère l'attestation composite CPU+GPU et s'il s'appuie sur l'un des schémas intra-handshake signalés comme vulnérables aux attaques par relais.
• Réservez les TEE aux cas où vous devez exclire l'opérateur d'infrastructure de votre modèle de menace — inférence GPU tierce sur des données réglementées, ou calcul multi-parties. Ne les déployez pas comme une mise à niveau généralisée du chiffrement au repos ; le coût opérationnel ne se justifie pas dans ce cas.
• Prévoyez un budget pour la couche d'attestation, pas seulement pour le matériel TEE. Les services d'attestation indépendants et les outils de vérification open source du Confidential Computing Consortium sont actuellement le moyen pratique d'éviter de construire cela de zéro.