À retenir

Le confidential computing protège les données en cours de traitement (in use), la troisième brique après le chiffrement au repos et en transit, via des enclaves matérielles appelées Trusted Execution Environment (TEE).
Azure, AWS et Google Cloud proposent chacun leur version : Azure combine AMD SEV-SNP, Intel SGX et Intel TDX selon les services, AWS s'appuie sur ses Nitro Enclaves propriétaires, Google Cloud sur Intel TDX pour ses VM confidentielles récentes (source : Microsoft Learn, 2026 ; AWS, docs.aws.amazon.com).
L'ANSSI a publié le 1er octobre 2025 une position technique qui tempère l'enthousiasme : face à un administrateur cloud hostile menant des attaques actives, la technologie n'apporte pas à elle seule une garantie suffisante d'intégrité et de confidentialité (source : ANSSI, Technical Position Paper on Confidential Computing, 01/10/2025).
Ne confondez pas confidential computing et cloud souverain SecNumCloud : ce sont deux réponses différentes à deux problèmes différents, et l'ANSSI elle-même rappelle qu'aucun cloud, même qualifié, ne maîtrise toute sa chaîne technologique (source : Vincent Strubel, DG ANSSI, cité par Solutions Numériques, 07/01/2026).

Le confidential computing répond à une question précise : comment garder le contrôle de données sensibles quand elles doivent être calculées sur une infrastructure que vous ne maîtrisez pas entièrement, qu'il s'agisse d'un cloud public, d'un prestataire ou d'un partenaire. C'est un chantier d'architecture, pas une case à cocher dans un contrat cloud.

Ce sujet monte dans les priorités DSI pour une raison concrète : entre l'usage croissant de LLM externes, les obligations RGPD et AI Act sur les traitements de données personnelles, et la pression pour héberger des charges sensibles hors de son propre datacenter, de plus en plus d'organisations calculent des données critiques sur du matériel qui appartient à quelqu'un d'autre.

Qu'est-ce que le confidential computing, concrètement

Le Confidential Computing Consortium (CCC), projet hébergé par la Linux Foundation dont Microsoft est cofondateur depuis 2019, définit la technologie ainsi : elle protège les données en cours de traitement en exécutant le calcul dans un environnement d'exécution de confiance (TEE) matériel et attesté (source : Microsoft Learn, What is confidential computing?, learn.microsoft.com/azure/confidential-computing/overview).

Concrètement, trois états de la donnée existent : au repos (stockage), en transit (réseau), en cours de traitement (mémoire vive pendant le calcul). Les deux premiers sont chiffrés depuis longtemps et de façon standard. Le troisième restait, jusqu'ici, en clair dans la RAM le temps du calcul. Concrètement, un hyperviseur compromis, un administrateur cloud malveillant ou un accès physique non autorisé pouvait lire ces données pendant qu'elles étaient traitées.

Le TEE ferme cette fenêtre : le processeur chiffre la mémoire utilisée par l'enclave, et un mécanisme d'attestation cryptographique permet de prouver à distance que le code tourne bien dans un environnement matériel légitime, non modifié, avant de lui transmettre des secrets (clés de chiffrement, données sensibles).

État de la donnéeProtection historiqueProtection ajoutée par le confidential computingAu repos (disque)Chiffrement disque, BitLocker, LUKSInchangéEn transit (réseau)TLS/SSLInchangéEn cours de traitement (mémoire)Aucune, données en clair en RAMChiffrement mémoire matériel + attestation (TEE)

Vous voulez évaluer où se situent vos propres angles morts sur le traitement des données sensibles ? Un audit de sécurité informatique permet de cartographier qui accède à quoi, y compris pendant le calcul.

Pourquoi ce sujet devient stratégique pour les DSI de PME et ETI

Trois dynamiques poussent le confidential computing hors du seul cercle des grands comptes bancaires ou de la défense.

D'abord, l'IA générative. Les collaborateurs envoient des données métier, parfois sensibles, à des LLM externes (ChatGPT, Claude, Mistral, Grok) hébergés sur des infrastructures cloud tierces. IT Systèmes a détaillé ailleurs les risques de ce Shadow AI et les mesures de sécurisation de ChatGPT, Claude et Mistral en PME : le confidential computing est l'une des briques techniques qui permettent de traiter ces prompts sans que l'opérateur du LLM ni le fournisseur cloud n'y aient accès en clair.

Ensuite, la réglementation. Le règlement européen sur l'IA (UE 2024/1689, dit AI Act), entré en vigueur le 1er août 2024, impose des obligations croissantes sur les traitements de données par les systèmes d'IA, avec des exigences renforcées à partir du 2 août 2026 pour les usages à haut risque. La directive NIS2 (UE 2022/2555) élargit en parallèle le périmètre des entités soumises à des obligations de sécurité renforcées. Ces deux textes ne citent pas nommément le confidential computing, mais ils poussent les DSI à documenter comment les données sensibles sont protégées à chaque étape de leur cycle de vie, y compris pendant le traitement. Le guide pratique de mise en conformité NIS2 détaille les mesures techniques attendues.

Enfin, la dépendance croissante au cloud public. Migrer vers Azure, AWS ou Google Cloud implique de confier le calcul à un tiers. Pour des secteurs réglementés (santé, finance, secteur public), cette dépendance pose une question simple : qui, techniquement, peut lire vos données pendant qu'elles sont traitées ? Le confidential computing est une des réponses possibles, pas la seule.

‍

Migration ou consolidation cloud en cours ?

Documentez la protection de vos données sensibles

Vous devez justifier la protection des données sensibles pour un audit ou un appel d'offres ? Un expert IT Systèmes peut évaluer votre architecture cloud actuelle et identifier où le confidential computing apporte une réponse pertinente, ou non.

Évaluer mon architecture

‍

Comment fonctionne le TEE : attestation, enclaves et chiffrement mémoire

Le mécanisme central est l'attestation. Avant qu'une charge sensible ne soit exécutée dans un TEE, le matériel produit une preuve cryptographique, appelée « evidence », de son état : quel firmware tourne, quelle version de code va être exécutée, si le secure boot est actif. Une partie tierce (« relying party ») vérifie cette preuve avant de transmettre des secrets, selon le modèle décrit par l'architecture RATS de l'IETF (RFC 9334, reprise dans la documentation Microsoft Azure sur l'attestation).

Deux approches techniques coexistent aujourd'hui chez les fournisseurs cloud :

‍

Approche	Principe	Exemples
VM confidentielle	Toute la machine virtuelle tourne chiffrée en mémoire, sans changement de code applicatif	Azure Confidential VM (AMD SEV-SNP, Intel TDX), Google Cloud Confidential VM (Intel TDX sur la série A3)
Enclave applicative	Seule une portion de code s'exécute dans l'enclave, le reste de l'application tourne normalement	Intel SGX sur Azure Kubernetes Service, AWS Nitro Enclaves

‍

Les Nitro Enclaves d'AWS illustrent une approche un peu différente : ils isolent le calcul via l'hyperviseur Nitro (technologie propriétaire AWS), sans accès possible depuis le compte root ou administrateur de l'instance parent, avec attestation cryptographique et intégration à AWS KMS pour la gestion des clés (source : AWS, What is Nitro Enclaves?, docs.aws.amazon.com/enclaves).

Ce que l'attestation ne couvre pas toujours

L'ANSSI souligne un point technique précis dans son document d'octobre 2025 : pour les VM confidentielles en environnement cloud, la vérification par attestation s'arrête généralement au niveau du système d'exploitation invité. Le firmware et le vTPM restent sous le contrôle du fournisseur cloud, ce qui limite la personnalisation et la complétude de la mesure de confiance (source : ANSSI, position technique sur le confidential computing, 01/10/2025, résumé par CyberVeille, 08/11/2025).

Ce que le confidential computing protège, et ce qu'il ne protège pas

C'est le point le plus important pour un DSI qui doit arbitrer un budget : cette technologie a un périmètre de protection défini, et l'ANSSI a pris soin de le préciser plutôt que de laisser le marketing des fournisseurs cloud en décider.

‍

Menace	Couverte par le confidential computing	Non couverte
Administrateur cloud hostile en lecture passive	✅	—
Hyperviseur compromis	✅	—
Administrateur hostile menant des attaques actives sophistiquées	—	🚩 protection jugée insuffisante par l'ANSSI
Attaques par canaux auxiliaires (single-stepping, compteurs de performance, patterns d'accès mémoire)	—	🚩 difficiles à mitiger, parfois besoin de changements matériels
Attaques physiques sur le matériel	—	🚩 explicitement exclues du modèle de menace
Compromission de la chaîne d'approvisionnement du fabricant de processeur	—	🚩 explicitement exclue du modèle de menace

‍

Cette table résume l'essentiel : le confidential computing réduit la surface d'attaque contre un opérateur cloud négligent ou un hyperviseur défaillant, mais ce n'est pas une protection absolue contre un attaquant déterminé disposant d'un accès physique ou de moyens sophistiqués. L'ANSSI recommande de le traiter comme une couche de défense en profondeur supplémentaire, jamais comme la seule ligne de défense, et insiste sur trois pratiques : attester l'intégralité de la chaîne de démarrage, lier cryptographiquement la livraison des secrets au résultat de l'attestation (via RA-TLS notamment), et déployer les mitigations connues contre les canaux auxiliaires malgré leurs compromis de performance (source : ANSSI, 01/10/2025).

Cas d'usage concrets pour PME et ETI

Le confidential computing sort progressivement du seul cas d'usage défense/finance de très haut niveau. Microsoft documente plusieurs déploiements réels sur Azure confidential computing qui donnent une idée du périmètre pertinent pour des organisations de taille intermédiaire :

‍

Secteur	Cas d'usage	Exemple documenté
Banque / finance	Détection de blanchiment d'argent inter-banques sans partage direct des données clients	Scotiabank, avec le partenaire Opaque (source : Microsoft Learn)
Santé	Recherche de candidats pour essais cliniques sur maladies rares sans exposer les données patients	Novartis Biome, avec le partenaire BeeKeeperAI (source : Microsoft Learn)
Multi-organisations	« Clean rooms » de données : plusieurs entreprises analysent un jeu de données combiné sans qu'aucune ne voie les données brutes des autres	Solutions de data clean room sur Azure, AWS et GCP
IA / LLM	Traitement de prompts et de données d'entraînement sans exposition à l'opérateur du modèle	Offres de confidential AI de plusieurs éditeurs partenaires cloud

‍

Pour une PME ou une ETI, l'application la plus réaliste à court terme concerne rarement une plateforme confidentielle maison, mais plutôt le choix d'un prestataire ou d'un éditeur SaaS qui s'appuie déjà sur ces briques pour traiter des données RH, de santé ou financières. La question à poser à vos fournisseurs devient alors : « votre service tourne-t-il dans un TEE attesté, ou seulement derrière un chiffrement classique au repos et en transit ? »

Panorama des offres cloud : Azure, AWS, Google Cloud

Les trois grands fournisseurs proposent des briques de confidential computing, avec des maturités et des modèles de programmation différents.

‍

Fournisseur	Technologie principale	Niveau d'intégration
Microsoft Azure	AMD SEV-SNP (VM confidentielles), Intel SGX (conteneurs/AKS), Intel TDX (VM DCesv5/ECesv5)	Le plus large éventail d'options : VM, conteneurs, clean rooms managés, ledger confidentiel
AWS	Nitro Enclaves (hyperviseur Nitro propriétaire)	Approche enclave applicative, forte intégration avec KMS
Google Cloud	Intel TDX (série de machines A3), Confidential VM	Approche VM confidentielle, montée en puissance progressive selon les familles de machines

‍

Ce choix technique a une conséquence directe sur votre architecture : une VM confidentielle (Azure, GCP) demande peu ou pas de modification de code, alors qu'une enclave applicative (Nitro Enclaves, Intel SGX) impose de redécouper l'application pour isoler la partie sensible. Le bon choix dépend de votre stack existante, pas d'un critère générique de sécurité. Si vous pilotez une migration ou une consolidation multicloud, l'accompagnement cloud & infrastructure d'IT Systèmes intègre ce type d'arbitrage technique dans le choix de la plateforme cible.

Confidential computing et cloud souverain : deux sujets à ne pas confondre

Beaucoup de DSI français associent spontanément confidential computing et souveraineté numérique. Ce sont pourtant deux réponses à deux problèmes différents, et les mélanger conduit à de mauvais arbitrages budgétaires.

Le confidential computing répond à une question technique : qui peut lire mes données pendant leur traitement, quel que soit l'endroit où elles sont hébergées. La qualification SecNumCloud de l'ANSSI répond à une question différente, plus juridique et industrielle : mon prestataire cloud est-il soumis à une loi étrangère à portée extraterritoriale (comme le CLOUD Act américain), et puis-je couper ce service sans dépendre d'une décision hors de mon contrôle.

Vincent Strubel, directeur général de l'ANSSI, a rappelé début 2026 que SecNumCloud repose sur environ 1 200 points de contrôle audités, protège contre le CLOUD Act et le risque de coupure de service, mais n'élimine pas toutes les dépendances technologiques : selon ses propres termes rapportés, aucune infrastructure cloud, même opérée par un acteur européen, ne maîtrise l'intégralité de sa chaîne technologique (source : Vincent Strubel, cité par Solutions Numériques, 07/01/2026). Un cloud qualifié SecNumCloud n'est donc pas automatiquement doté de confidential computing, et un service avec confidential computing n'est pas automatiquement souverain au sens juridique.

Pour un DSI, la bonne question de gouvernance n'est pas « lequel choisir » mais « lequel répond à quel risque » : le pilotage de la gouvernance des données doit distinguer explicitement le risque d'accès technique non autorisé (confidential computing) du risque de dépendance juridique à une loi étrangère (SecNumCloud, cloud de confiance).

Comment démarrer sans se tromper de priorité

Avant d'investir dans une architecture confidential computing, un DSI de PME/ETI a intérêt à suivre un ordre simple : classer les données par niveau de sensibilité, identifier lesquelles transitent réellement par une infrastructure non maîtrisée (cloud public, LLM externe, prestataire), puis vérifier si un chiffrement au repos et en transit correctement configuré suffit déjà à couvrir le risque identifié. Le confidential computing se justifie quand la donnée doit être calculée, pas seulement stockée ou transmise, sur une machine dont vous ne contrôlez pas l'administrateur.

Dans la majorité des PME, le chantier le plus rentable à court terme reste souvent en amont : durcissement des accès, chiffrement classique bien configuré, politique claire sur les données envoyées aux LLM externes. Le confidential computing intervient ensuite, sur un périmètre plus restreint de données réellement critiques.

FAQ

Le confidential computing remplace-t-il le chiffrement classique au repos et en transit ?

Non. Il s'ajoute aux deux protections existantes pour couvrir le troisième état de la donnée, le traitement en mémoire. Un DSI doit garder les trois chiffrements en place : au repos, en transit, et en cours de traitement pour les données les plus sensibles.

Le confidential computing suffit-il à répondre aux exigences RGPD ou AI Act ?

Non à lui seul. Il renforce la protection technique des données personnelles ou des traitements IA à haut risque, mais la conformité RGPD et AI Act impose aussi des obligations organisationnelles (registre de traitement, analyse d'impact, gouvernance) que la seule technologie ne couvre pas.

Une PME de moins de 100 salariés doit-elle investir dans le confidential computing ?

Rarement en direct. La priorité pour la plupart des PME reste le choix d'un prestataire ou éditeur SaaS qui s'appuie déjà sur ces briques pour les données sensibles (RH, santé, finance), plutôt que de construire une architecture confidentielle maison, coûteuse à opérer.

Quelle différence entre une VM confidentielle et une enclave applicative ?

Une VM confidentielle chiffre toute la machine virtuelle sans changer le code de l'application. Une enclave applicative isole seulement une portion de code réécrite pour l'occasion. La première est plus simple à adopter, la seconde offre une isolation plus fine mais demande du développement dédié.

Le confidential computing protège-t-il contre un employé malveillant ayant un accès légitime aux données ?

Non directement. Il protège contre un accès non autorisé au niveau de l'infrastructure (hyperviseur, administrateur cloud), pas contre un utilisateur qui a un droit d'accès légitime aux données en clair dans le cadre normal de son travail.

Faut-il choisir Azure, AWS ou Google Cloud spécifiquement pour le confidential computing ?

Le choix ne devrait pas se faire uniquement sur ce critère. Les trois plateformes proposent des briques matures avec des modèles différents (VM confidentielle vs enclave applicative) ; le bon choix dépend de votre stack applicative existante et de vos contraintes de migration plus que d'une supériorité technique tranchée d'un fournisseur.

Ce que propose IT Systèmes sur le confidential computing et la protection des données sensibles

IT Systèmes accompagne les PME et ETI sur l'ensemble de la chaîne de protection des données, du chiffrement classique au repos et en transit jusqu'à l'évaluation de la pertinence d'une architecture confidential computing pour des charges réellement critiques. Cet accompagnement passe par un audit de l'existant, une cartographie des flux de données vers le cloud et les LLM externes, puis un choix d'architecture cloud aligné sur vos contraintes de conformité RGPD, NIS2 et AI Act.

‍

Un doute sur la protection de vos données ?

Faites le point avec un expert IT Systèmes

Évaluez si vos données sensibles sont réellement protégées pendant leur traitement, pas seulement au repos. Parlons de votre architecture cloud et de vos priorités de sécurité.

Demander un échange

‍