Pendant la majeure partie de l’histoire de l’informatique, les données ont été protégées dans deux états : au repos, avec le chiffrement des disques, et en transit, avec TLS. Le troisième état, les données en cours d’utilisation, restait en clair dans la mémoire dès qu’un processeur y touchait. Quiconque contrôlait l’hôte, l’hyperviseur ou disposait d’un accès physique à la machine pouvait les lire. Pour les charges de travail réglementées et souveraines en Europe, c’est précisément là que réside tout le problème.
Le confidential computing comble cette lacune. Combiné à des primitives d’isolation modernes comme les microVM, il change ce que vous pouvez promettre de manière crédible à propos d’une charge de travail : que l’opérateur de l’infrastructure ne peut pas lire les données, que vous pouvez le prouver cryptographiquement, et que l’ensemble s’exécute sous le droit de l’UE et sur le sol de l’UE. Cet article couvre les deux volets de cette histoire, les standards et le matériel qui les sous-tendent, ainsi qu’une lecture honnête de l’état réel de la technologie en 2026.
En quoi consiste le confidential computing
Le confidential computing protège les données pendant leur traitement en les exécutant à l’intérieur d’un Trusted Execution Environment (TEE) reposant sur le matériel. Le TEE chiffre la mémoire de manière transparente et isole la charge de travail de tout ce qui se trouve à l’extérieur, y compris le système d’exploitation hôte, l’hyperviseur, les autres locataires et le personnel même de l’opérateur cloud. C’est le chiffrement en cours d’utilisation, le troisième état manquant.
La conséquence pratique compte davantage que le mécanisme. Dans un TEE correctement attesté, l’entité qui exploite le matériel ne peut pas voir vos données en clair. Un hébergeur, un hyperscaler ou une équipe plateforme interne devient techniquement incapable de lire ce qui s’exécute à l’intérieur de l’enclave, et pas seulement contractuellement interdit de le faire. Pour les charges de travail dont le modèle de menace inclut l’opérateur, ou lorsqu’une juridiction étrangère pourrait contraindre cet opérateur, c’est un changement de nature.
Pourquoi c’est important pour la souveraineté et le RGPD
La souveraineté des données et la résidence des données sont deux choses différentes. La résidence, c’est l’endroit où les octets se trouvent physiquement. La souveraineté, c’est quelles lois les régissent et qui peut légalement en contraindre l’accès. La résidence des données dans l’UE ne suffit pas à empêcher qu’une société mère hors UE soit soumise à des demandes légales extraterritoriales.
Le confidential computing renforce l’argument de souveraineté au niveau technique. Lorsque les données sont traitées à l’intérieur d’un TEE et que les clés de déchiffrement ne sont libérées qu’après une attestation auprès de clés détenues hors du contrôle de l’opérateur, ce dernier ne peut pas produire de données en clair lisibles, quelle que soit la demande légale qui lui est signifiée. Soyons précis sur le statut réglementaire : aucune autorité de protection des données de l’UE n’a encore reconnu le confidential computing comme une mesure supplémentaire autonome au titre de l’article 46(2) du RGPD. Considérez-le comme une défense en profondeur solide qui améliore matériellement une analyse d’impact relative aux transferts (Transfer Impact Assessment), et non comme une solution miracle de conformité. Le cadrage honnête est celui qui est crédible.
Le matériel : SEV-SNP, TDX, CCA
Trois fabricants de processeurs proposent aujourd’hui du confidential computing au niveau de la VM, chacun protégeant une machine virtuelle entière plutôt que de vous demander de réécrire des applications pour une petite enclave :
- AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging) chiffre la mémoire de la VM par invité et ajoute une protection d’intégrité afin qu’un hyperviseur malveillant ne puisse pas remapper, rejouer ni altérer la mémoire de l’invité. Largement disponible sur les plateformes serveur.
- Intel TDX (Trust Domain Extensions) crée des « domaines de confiance » isolés par le matériel, avec mémoire chiffrée et isolation de l’hyperviseur, plus une attestation à distance intégrée. Disponible sur les récentes générations Xeon.
- ARM CCA (Confidential Compute Architecture) introduit les « Realms », des environnements isolés par le matériel pour le code et les données. C’est le plus récent des trois et il vise clairement l’edge et l’écosystème serveur ARM, même si sa disponibilité large accuse encore un retard sur x86.
L’ancien modèle d’enclave, Intel SGX, protège une petite portion d’une application plutôt qu’une VM entière. Il reste pertinent pour des secrets à portée étroite, mais il est plus difficile à adopter que les approches au niveau de la VM ci-dessus. Le bon choix dépend de votre silicium, de votre partenaire cloud ou matériel et de votre charge de travail, ce qui est exactement le type de décision qu’un cabinet de conseil indépendant des fournisseurs devrait prendre avec vous plutôt qu’au profit d’un produit.
L’attestation est la pièce maîtresse
Un TEE n’est utile que si vous pouvez prouver qu’une charge de travail s’exécute bien à l’intérieur d’un environnement authentique et non modifié avant de lui confier des secrets. Cette preuve, c’est l’attestation à distance, et c’est la partie que la plupart des équipes sous-estiment.
Le modèle mental indépendant des fournisseurs provient de l’architecture IETF RATS (RFC 9334), qui nomme trois rôles : l’Attester produit des preuves signées concernant son environnement, le Verifier vérifie ces preuves par rapport à des valeurs de référence connues comme valides, et le Relying Party ne libère les clés ou les données que si le résultat est positif. En pratique, le flux ressemble à ceci : le TEE génère des preuves signées par le matériel, un vérificateur confirme le firmware et les mesures, et c’est seulement alors qu’un courtier de clés (key broker) libère les secrets nécessaires pour déchiffrer les données ou récupérer un modèle. Pas d’attestation valide, pas de clés.
La pile logicielle open source
Le matériel confidentiel a besoin de logiciels pour être utilisable dans des environnements cloud native. L’effort open source de référence est Confidential Containers (CoCo), un projet de la CNCF qui exécute chaque pod Kubernetes à l’intérieur de son propre TEE et standardise le confidential computing au niveau du pod. CoCo couvre les principaux backends matériels (SEV-SNP, TDX, SGX, IBM Secure Execution) et se combine au projet Trustee pour l’attestation, y compris un Key Broker Service qui conditionne la libération des secrets à une attestation positive. CoCo s’appuie sur Kata Containers, abordé plus bas, pour son runtime isolé par VM. D’autres implémentations ouvertes existent dans le même domaine, et la force de l’écosystème tient à ce que les schémas d’attestation et de libération de clés convergent vers des standards partagés plutôt que vers l’API d’un seul fournisseur.
MicroVM et isolation sécurisée
Le confidential computing répond à la question « l’opérateur peut-il lire ceci ». Les microVM répondent à une question connexe mais distincte : « si une charge de travail est compromise, peut-elle atteindre les autres ». Ces deux approches sont complémentaires, pas interchangeables.
Le conteneur Linux standard partage le noyau de l’hôte. Une seule évasion du noyau, comme CVE-2024-21626 dans runc, et le rayon d’impact, c’est le nœud entier. Pour du code véritablement multi-locataire ou non fiable, un noyau partagé est une cloison trop fine. Les alternatives :
- Firecracker est un VMM minimal écrit en Rust, conçu spécifiquement pour le serverless. Il démarre une microVM en environ 125 ms avec une empreinte de quelques Mo par VM, en réduisant le modèle de périphériques à l’essentiel. Il fait notamment tourner AWS Lambda et Fargate.
- Cloud Hypervisor est un autre VMM moderne en Rust, avec un modèle de périphériques plus riche que Firecracker et une large prise en charge matérielle. C’est le backend par défaut de Kata Containers.
- Kata Containers donne à l’isolation de niveau VM l’apparence de conteneurs : chaque pod s’exécute dans une VM légère derrière une interface OCI/Kubernetes standard. Il prend en charge Cloud Hypervisor, Firecracker et QEMU comme backends, ce qui vous permet d’ajuster le compromis isolation/compatibilité.
- gVisor emprunte une voie différente, un noyau en espace utilisateur qui intercepte les appels système. Pas de VM complète, une surcharge plus faible que la virtualisation, une isolation solide pour de nombreux cas multi-locataires, avec quelques limites de compatibilité pour les charges de travail riches en appels système.
Où chacun s’inscrit
Adaptez l’outil à la charge de travail, pas au battage médiatique :
- SaaS multi-locataire et Kubernetes partagé : Kata Containers ou gVisor pour contenir les locataires derrière une frontière dure.
- Bacs à sable à démarrage rapide et fonctions serverless : Firecracker, là où les démarrages à froid en moins d’une seconde et la densité priment.
- CI sécurisée et exécution de code non fiable : des microVM pour exécuter des builds arbitraires ou du code client sans leur faire confiance.
- Isolation de l’inférence IA : une frontière de VM dédiée par modèle ou par locataire pour qu’un chemin d’inférence compromis ne puisse pas se propager latéralement.
Les deux couches s’empilent. Vous pouvez exécuter un pod Kata ou CoCo dont la VM sous-jacente est elle-même une VM confidentielle sur SEV-SNP ou TDX, obtenant ainsi à la fois la cécité de l’opérateur et l’isolation des locataires à partir d’un seul déploiement.
Inférence IA confidentielle
Le moteur dont la croissance est la plus rapide, c’est l’IA. Envoyer des prompts, des documents récupérés ou des données de fine-tuning à un LLM revient à exposer une partie de vos données les plus sensibles à quiconque exécute l’inférence. L’IA confidentielle réduit cette exposition.
Le NVIDIA H100 a été le premier GPU doté d’un TEE matériel : en mode confidentiel, il protège le code et les données sur le GPU avec une VRAM chiffrée et une racine de confiance intégrée à la puce, et il se combine à une VM CPU confidentielle (SEV-SNP ou TDX) pour que les données restent chiffrées de bout en bout entre le CPU et le GPU. L’attestation s’étend au GPU, de sorte qu’un relying party peut vérifier à la fois l’environnement CPU et GPU avant de libérer les poids du modèle ou les données. La surcharge publiée est modeste, de l’ordre d’un faible pourcentage à un chiffre sur le débit pour de nombreuses charges de travail d’inférence LLM, plus un coût d’attestation unique au démarrage. Résultat : les prompts et les sorties restent privés même vis-à-vis de l’hôte, et l’exécution est vérifiable cryptographiquement. Pour les organisations européennes qui veulent une IA moderne sans envoyer des données réglementées dans un environnement opaque, c’est le pont.
Maturité honnête et compromis
C’est puissant, mais ce n’est ni gratuit ni achevé :
- La maturité varie fortement. SEV-SNP et TDX sont prêts pour la production ; ARM CCA et certaines parties de l’écosystème TEE pour GPU sont plus précoces. L’outillage, en particulier la plomberie d’attestation, est encore en cours de maturation.
- L’attestation est un travail opérationnel. Les vérificateurs, les valeurs de référence et les courtiers de clés sont la partie difficile, et c’est vous qui en êtes responsable, ou votre partenaire.
- La surcharge de performance est réelle mais généralement faible. Prévoyez quelques pour cent, davantage pour les profils limités par la mémoire ou intensifs en E/S, et mesurez votre propre charge de travail.
- Ce n’est pas une case à cocher de conformité. Cela renforce une posture RGPD et de souveraineté ; cela ne remplace pas la revue juridique, la gouvernance des clés et une architecture globale solide.
- Les frontières de confiance se déplacent, elles ne disparaissent pas. Vous faites toujours confiance à la racine de confiance du fabricant du silicium et à votre logique de vérification. Sachez ce qui se trouve dans votre base de calcul de confiance (trusted computing base).
FAQ
Le confidential computing remplace-t-il le chiffrement au repos et en transit ? Non. Il ajoute le troisième état, en cours d’utilisation, et fonctionne aux côtés des deux autres.
L’opérateur cloud peut-il quand même lire mes données à l’intérieur d’un TEE ? Avec une attestation correcte et un contrôle externe des clés, non. L’opérateur ne peut pas produire de données en clair lisibles, ce qui constitue le bénéfice fondamental en matière de souveraineté.
Ai-je besoin de matériel confidentiel pour utiliser les microVM ? Non. Firecracker, Cloud Hypervisor, Kata et gVisor offrent une forte isolation sur du matériel standard. Le confidential computing est une couche distincte que vous pouvez ajouter par-dessus.
Est-ce conforme au RGPD dès le départ ? Cela renforce la conformité et les analyses d’impact relatives aux transferts en tant que défense en profondeur, mais aucune APD de l’UE ne l’a confirmé comme mesure supplémentaire autonome. Considérez-le comme l’un de plusieurs contrôles solides.
Sur quel processeur devrais-je me standardiser ? Cela dépend de votre pile, de vos partenaires et de votre charge de travail. Nous évaluons SEV-SNP, TDX et CCA au regard de vos besoins réels plutôt que de pousser une seule option.
La place de Rapid Solutions
Nous sommes un cabinet de conseil en ingénierie et un partenaire de services managés indépendant des fournisseurs, pas un fournisseur cloud. Nous concevons et exploitons des charges de travail confidentielles, isolées par le matériel, sur des fondations open source, avec la résidence des données dans l’UE et la souveraineté intégrées d’emblée, et nous nous adaptons à la pile que vous possédez déjà plutôt que de vous enfermer dans la nôtre. Que vous évaluiez SEV-SNP par rapport à TDX, mettiez en place Confidential Containers avec une attestation appropriée, isoliez des charges de travail multi-locataires avec Kata ou Firecracker, ou exécutiez de l’inférence IA confidentielle, nous vous aidons à le faire correctement et à prouver que cela fonctionne.