Confidential Computing et TEE : protéger les données dans le cloud
Le cloud de confiance : pourquoi la sécurité des données en cours de traitement devient un enjeu stratégique
Pendant longtemps, les équipes sécurité se sont concentrées sur deux états bien identifiés de la donnée : au repos (chiffrement des disques, des bases de données) et en transit (TLS, VPN). Mais il existait un angle mort persistant, presque structurel : que se passe-t-il lorsque la donnée est en cours de traitement ? À ce moment précis, elle doit nécessairement être déchiffrée en mémoire vive pour être manipulée par le processeur. Et c'est là que tout se joue.
Cette vulnérabilité n'était pas un problème théorique tant que les workloads restaient dans des datacenters maîtrisés de bout en bout. Mais l'adoption massive du cloud public a changé la donne. Déléguer l'exécution à un hyperviseur tiers, c'est accepter — au moins en théorie — qu'un opérateur malveillant ou compromis puisse accéder à la mémoire de vos machines virtuelles. Pour des données personnelles, médicales, financières ou relevant du secret des affaires, ce risque est tout simplement inacceptable.
C'est précisément pour répondre à ce défi que le Confidential Computing et les Trusted Execution Environments (TEE) ont émergé comme des primitives de sécurité fondamentales. Dans un contexte où l'IA agentique multiplie les traitements automatisés sur des données sensibles — parfois sans intervention humaine directe — maîtriser ces technologies devient un avantage compétitif autant qu'une nécessité réglementaire.
Confidential Computing et TEE : de quoi parle-t-on exactement ?
Le Confidential Computing désigne un ensemble de technologies matérielles et logicielles visant à protéger les données pendant leur traitement, en isolant leur exécution dans un environnement sécurisé que même l'infrastructure hôte ne peut inspecter. Le concept repose sur une idée simple mais puissante : déplacer la frontière de confiance du système d'exploitation et de l'hyperviseur vers le silicium lui-même.
Un Trusted Execution Environment (TEE) est la concrétisation matérielle de ce principe. Il s'agit d'une enclave sécurisée au sein du processeur, dont la mémoire est chiffrée et dont l'intégrité est garantie par des mécanismes cryptographiques ancrés dans le hardware. Les données qui entrent dans ce TEE ne peuvent être lues ni modifiées de l'extérieur — ni par l'hyperviseur du cloud provider, ni par le système d'exploitation de la machine hôte, ni même par un administrateur disposant d'accès physique au serveur.
Les principales implémentations matérielles
- Intel TDX (Trust Domain Extensions) et l'historique Intel SGX (Software Guard Extensions) : SGX permet de créer des enclaves applicatives de taille limitée ; TDX élève le niveau de protection à la machine virtuelle entière.
- AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging) : protège l'intégrité et la confidentialité des machines virtuelles contre un hyperviseur compromis.
- ARM TrustZone : très répandu dans les environnements mobiles et embarqués, il crée deux "mondes" isolés — secure et non-secure — sur le même processeur.
Les grands hyperscalers ont intégré ces technologies dans leurs offres : Azure Confidential Computing, Google Cloud Confidential VMs et AWS Nitro Enclaves proposent aujourd'hui des instances basées sur ces primitives matérielles. La maturité est suffisante pour des déploiements en production.
L'attestation : la clé de voûte du système
L'attestation est le mécanisme qui rend tout cela vérifiable. Avant de déchiffrer des données sensibles pour les envoyer vers une enclave, un client distant doit pouvoir prouver cryptographiquement que l'enclave est bien ce qu'elle prétend être — qu'elle tourne bien sur du matériel certifié, avec le bon code, non altéré. Ce rapport d'attestation, signé par le fabricant du processeur, constitue une garantie que même le cloud provider ne peut pas contrefaire. C'est là que réside la rupture fondamentale : la confiance ne repose plus sur une relation contractuelle avec un opérateur, mais sur des preuves mathématiques ancrées dans le hardware.
Zero Trust : Confidential Computing comme mise en œuvre concrète
Le modèle Zero Trust — "ne jamais faire confiance, toujours vérifier" — est souvent présenté comme un principe architectural. Mais dans la pratique, beaucoup d'organisations peinent à aller au-delà de la microsegmentation réseau et de la gestion des identités. Le Confidential Computing offre une implémentation concrète du Zero Trust au niveau le plus bas de la pile technique : le traitement des données lui-même.
Appliquer le Zero Trust de manière cohérente, c'est accepter que même l'infrastructure sur laquelle vous vous exécutez ne doit pas être implicitement considérée comme de confiance. Dans un environnement cloud, cela signifie que le cloud provider lui-même, les administrateurs système, les opérateurs réseau — tous font partie du périmètre de menace à adresser. Le TEE permet de matérialiser ce principe : le code et les données dans l'enclave sont protégés même si l'hôte est compromis.
Du modèle périmétrique à la confiance distribuée
Dans l'architecture traditionnelle à périmètre défini, la sécurité reposait sur le fait que "ce qui est à l'intérieur est sûr". Le Zero Trust renverse ce paradigme : chaque composant, chaque service, chaque agent doit prouver son identité et son intégrité à chaque interaction. Le TEE introduit une notion supplémentaire : non seulement qui vous êtes, mais dans quel état matériel vous vous exécutez. C'est une dimension de confiance que les approches purement logicielles ne peuvent pas adresser.
Pour les équipes sécurité de nos clients, cela se traduit par un changement de posture : au lieu de demander "est-ce que je fais confiance à ce cloud provider ?", la question devient "est-ce que je peux vérifier cryptographiquement l'environnement d'exécution, indépendamment du provider ?". Ce glissement est fondamental, et il aligne parfaitement le Confidential Computing avec les exigences réglementaires croissantes — NIS2, DORA, RGPD — qui demandent des garanties techniques prouvables, pas seulement contractuelles.
L'Agentic Mesh et le défi de la sécurité des données en mouvement
Les Tech Trends 2026 de SFEIR et WEnvision le soulignent clairement : nous basculons dans l'ère de l'IA agentique. Les agents IA ne se contentent plus de suggérer ou d'assister — ils agissent de manière autonome, orchestrent des workflows complexes, manipulent des fichiers, appellent des API, et prennent des décisions sans intervention humaine systématique.
Cette évolution donne naissance à ce que l'on appelle l'Agentic Mesh : un réseau d'agents autonomes interconnectés, chacun spécialisé dans une tâche, capable de déléguer, de sous-traiter et de collaborer avec d'autres agents. Ce modèle architectural est extrêmement puissant pour automatiser des processus métier complexes. Mais il introduit une surface d'attaque radicalement nouvelle.
Pourquoi l'Agentic Mesh pose un problème de sécurité inédit
Dans un Agentic Mesh, les données sensibles circulent entre de nombreux agents, potentiellement hébergés sur des infrastructures différentes, développés par des équipes différentes, voire fournis par des tiers. Chaque transit, chaque traitement intermédiaire représente un point de vulnérabilité potentiel. Les problématiques classiques se complexifient :
- Prompt injection et manipulation de contexte : un agent malveillant ou compromis peut tenter d'injecter des instructions dans le flux de traitement pour exfiltrer des données.
- Mémorisation involontaire : les LLMs utilisés par les agents peuvent, sans précautions adéquates, mémoriser des données sensibles dans leurs contextes d'exécution.
- Traçabilité des décisions : lorsqu'un agent prend une décision en traitant des données confidentielles, comment garantir que le traitement s'est bien déroulé de manière confidentielle et intègre ?
- Chaîne de confiance entre agents : comment un agent orchestrateur peut-il vérifier qu'un agent sous-traitant s'exécute bien dans un environnement sécurisé ?
Le TEE comme brique de confiance de l'Agentic Mesh
Le Confidential Computing apporte une réponse structurelle à ces défis. En exécutant les agents IA dans des TEE, on garantit que :
- Les données traitées par l'agent ne sont jamais exposées en clair à l'infrastructure hôte.
- Le code de l'agent n'a pas été altéré avant ou pendant l'exécution (intégrité).
- L'agent peut prouver cryptographiquement son état d'exécution à d'autres composants du mesh (attestation).
Cette combinaison permet de construire une chaîne de confiance vérifiable dans le mesh : chaque agent peut attester de son environnement d'exécution auprès des agents avec lesquels il interagit, créant ainsi un tissu de confiance distribuée qui ne repose pas sur une autorité centrale susceptible d'être compromise. C'est exactement ce que le Zero Trust à l'échelle de l'IA agentique requiert.
Cas d'usage concrets : où le Confidential Computing change vraiment la donne
Au-delà des principes, le Confidential Computing trouve des applications concrètes dans plusieurs secteurs que nous accompagnons chez SFEIR.
Santé et données médicales
Les établissements de santé souhaitent exploiter la puissance du machine learning pour améliorer les diagnostics, mais se heurtent à des contraintes réglementaires strictes sur les données patients. Le federated learning combiné aux TEE permet d'entraîner des modèles sur des données distribuées entre plusieurs hôpitaux sans que ces données quittent jamais les établissements — et sans que même les coordinateurs de l'entraînement puissent accéder aux données brutes. L'attestation garantit que chaque nœud participant s'exécute bien avec le code approuvé, dans un environnement sécurisé.
Services financiers et calcul multi-parties
Dans la finance, plusieurs institutions peuvent avoir intérêt à collaborer sur des analyses de risque ou de fraude sans révéler leurs données propriétaires à leurs concurrents. Le Secure Multi-Party Computation (MPC) enrichi par des TEE permet ces collaborations : chaque participant apporte ses données dans son enclave, les calculs se font de manière confidentielle, et seul le résultat agrégé est partagé. Aucune institution n'a jamais accès aux données brutes des autres.
IA agentique sur données RH et juridiques
Lorsqu'un agent IA doit analyser des contrats confidentiels, des dossiers employés ou des données de due diligence, l'exécution dans un TEE garantit que même les équipes DevOps du cloud provider ne peuvent pas accéder au contenu traité. C'est un prérequis pour de nombreux clients grands comptes qui souhaitent déployer des agents IA sur des données relevant du secret professionnel ou du secret des affaires.
Souveraineté et cloud de confiance
Dans le contexte de la doctrine française et européenne sur la souveraineté numérique — et des labels tels que SecNumCloud de l'ANSSI — le Confidential Computing permet d'aller plus loin que le simple hébergement local. Même si les données sont hébergées chez un hyperscaler américain disposant d'une offre souveraine, les TEE offrent une garantie technique supplémentaire : même en cas de contrainte légale extraterritoriale exercée sur le provider, les données en cours de traitement restent inaccessibles. Ce niveau de garantie était jusqu'ici impossible à obtenir de manière purement contractuelle.
Les défis et limites à ne pas sous-estimer
Le Confidential Computing est une technologie mature et prometteuse, mais son adoption en entreprise requiert une compréhension lucide de ses contraintes actuelles.
Complexité opérationnelle
Adapter une application pour s'exécuter dans un TEE — particulièrement dans une enclave SGX classique — demande souvent des modifications significatives de l'architecture. Les contraintes de mémoire, les appels système restreints, la gestion du cycle de vie des enclaves : tout cela requiert une expertise spécialisée. Les approches plus récentes comme TDX et SEV-SNP, qui protègent la VM entière plutôt que des enclaves applicatives fines, réduisent significativement cette friction.
Performance et surcoût
Le chiffrement de la mémoire et les mécanismes d'attestation ont un coût en termes de latence et de throughput. Ce surcoût est variable selon les workloads et les implémentations — il peut être négligeable pour des traitements batch, mais plus sensible pour des applications à faible latence. Un dimensionnement et des tests de charge spécifiques sont nécessaires avant tout déploiement en production.
La surface d'attaque résiduelle
Le TEE protège contre une classe importante de menaces, mais il ne résout pas tous les problèmes de sécurité. Les side-channel attacks (attaques par canaux auxiliaires, comme Spectre et Meltdown) ont montré que même les enclaves matérielles pouvaient être vulnérables à des attaques sophistiquées. La sécurité du code s'exécutant dans l'enclave reste de la responsabilité des développeurs. Et l'attestation suppose une chaîne de confiance qui remonte jusqu'au fabricant du processeur — ce qui introduit une forme de dépendance envers Intel, AMD ou ARM.
Gestion des clés et orchestration
Le déploiement de TEE à grande échelle pose des défis de gestion des secrets et des clés cryptographiques. Quels secrets injecter dans les enclaves ? Comment les renouveler ? Comment orchestrer l'attestation entre des dizaines d'agents dans un mesh ? Ces questions nécessitent une architecture de gestion des identités et des secrets robuste, souvent basée sur des Key Management Services (KMS) configurés pour intégrer les rapports d'attestation dans leurs politiques d'accès.
Comment SFEIR accompagne ses clients sur le Confidential Computing
Chez SFEIR, nous observons une accélération nette de la demande sur ces sujets, portée par deux dynamiques convergentes : d'un côté, les exigences réglementaires (RGPD, NIS2, DORA, réglementation IA) qui demandent des garanties techniques de plus en plus précises ; de l'autre, l'émergence de l'IA agentique qui multiplie les traitements automatisés sur des données sensibles.
Notre approche s'articule autour de trois niveaux d'intervention.
Évaluation et cartographie des risques
Avant toute chose, nous aidons nos clients à identifier les workloads pour lesquels le Confidential Computing apporte une valeur réelle. Tous les traitements ne justifient pas la complexité opérationnelle d'une enclave. Nous construisons une cartographie des flux de données sensibles, des modèles de menace associés et des options techniques disponibles — TEE natif, offres managées des cloud providers, frameworks open source comme Gramine ou Occlum pour faciliter le portage d'applications.
Architecture et mise en œuvre
Nos architectes cloud et sécurité, forts de leur expertise sur les plateformes Azure, GCP et AWS, conçoivent les architectures de Confidential Computing adaptées aux contraintes de chaque client. Cela inclut la conception des flux d'attestation, l'intégration avec les KMS existants, et le design des pipelines CI/CD pour garantir l'intégrité du code déployé dans les enclaves. Dans le contexte d'architectures agentiques, nous concevons les mécanismes de chaîne de confiance entre agents du mesh.
Montée en compétences des équipes
Le Confidential Computing reste une discipline relativement nouvelle, et les compétences sont rares sur le marché. SFEIR investit dans la formation de ses consultants et dans le transfert de compétences vers les équipes de nos clients. Nous contribuons également à la veille technologique collective — comme en témoignent les Tech Trends 2026 — pour anticiper les évolutions d'un domaine qui évolue rapidement, tant du côté des menaces que des solutions.
Perspectives : vers un cloud nativement confidentiel
Le mouvement de fond est clair : le Confidential Computing va progressivement devenir une caractéristique standard des infrastructures cloud, et non plus une option premium pour des cas d'usage de niche. Plusieurs signaux confirment cette trajectoire.
Les hyperscalers investissent massivement dans ces technologies. Le Confidential Computing Consortium, hébergé par la Linux Foundation et qui regroupe AMD, Intel, ARM, Google, Microsoft, IBM et d'autres, standardise les interfaces et les protocoles d'attestation. Des frameworks comme TEEP (Trusted Execution Environment Provisioning) et RATS (Remote ATtestation procedureS) au sein de l'IETF posent les bases d'une interopérabilité qui facilitera les déploiements multi-cloud.
Dans le domaine de l'IA agentique, les prochaines années verront probablement émerger des standards d'attestation pour les agents : la capacité pour un agent de prouver non seulement son identité, mais aussi l'intégrité de son modèle, de ses paramètres et de son environnement d'exécution. C'est une évolution naturelle de l'Agentic Mesh vers un tissu de confiance vérifiable de bout en bout.
Pour les entreprises françaises et européennes, ce n'est pas seulement une question de sécurité technique — c'est un enjeu de souveraineté numérique opérationnelle. Pouvoir démontrer, preuves cryptographiques à l'appui, que vos données sensibles n'ont jamais été exposées à une infrastructure tiers, même dans le cloud : c'est un argument différenciant face aux clients, aux régulateurs et aux partenaires.
La transformation vers l'IA agentique que décrivent les Tech Trends 2026 de SFEIR ne pourra se déployer à grande échelle que si les fondations de confiance sont au rendez-vous. Le Confidential Computing et les TEE ne sont pas un sujet de niche réservé aux experts en cryptographie : ils sont en train de devenir un pilier architectural du cloud moderne, au même titre que le chiffrement en transit l'est devenu il y a vingt ans.
La question n'est plus de savoir si votre organisation devra intégrer ces technologies dans son architecture cloud, mais quand — et si vous serez prêts à le faire de manière maîtrisée, avant que la pression réglementaire ou un incident de sécurité ne vous y contraigne dans l'urgence.