Ce volume ne prétend pas que la gestion d'identité et de clés de chiffrement chez un fournisseur cloud constitue en soi une malveillance. Il a été modélisé par un architecte infrastructure, audité de façon contradictoire par deux intelligences artificielles, à partir de faits publics vérifiables — documentation technique des fournisseurs, référentiels réglementaires publiés, spécifications de standards ouverts. Il n'instruit le procès d'aucune intention. Il documente un mécanisme structurel par lequel l'identité numérique et la clé de chiffrement restent le dernier verrou d'une architecture, même quand l'orchestrateur est ouvert et la donnée portable, et propose une architecture de contournement assumée comme une proposition, pas comme une solution déjà déployée.

Une donnée chiffrée peut, en théorie, être copiée bit à bit vers une autre infrastructure. Une identité ne peut pas l'être de la même manière : elle n'est pas une valeur statique, mais le résultat d'un processus d'attestation continu — vérification de l'origine de la requête, de l'intégrité de la chaîne d'appel, de la validité temporelle du jeton. Copier la représentation de l'identité sans copier le processus d'attestation qui la valide ne produit rien d'utilisable.

Les trois hyperscalers convergent vers la même architecture : la clé de chiffrement générée par leur service managé natif ne quitte jamais leurs HSM, quelle que soit la certification FIPS précise (Level 2 pour Azure Key Vault Premium, Level 3 pour AWS CloudHSM et Google Cloud HSM). Le mécanisme documenté au Chapitre I n'est donc pas une particularité d'un seul fournisseur, mais une convention architecturale commune aux trois principaux acteurs du marché.

Une organisation qui souhaite changer de fournisseur cloud sans perdre l'accès à ses données déjà chiffrées doit soit ré-chiffrer l'intégralité du volume de données concerné avec une nouvelle clé avant la bascule — opération dont le coût croît linéairement avec le volume de données déjà accumulé — soit accepter de rester dépendante du service de clés du fournisseur d'origine pour déchiffrer ce qui a déjà été chiffré chez lui, même après la bascule de l'infrastructure de calcul elle-même.

L'identité et la clé sont verrouillées à la fois par un effet cumulatif non intentionnel (Arthur) et par une asymétrie structurelle de propriété sur l'infrastructure physique qui les authentifie (Grossman & Hart). Le second ancrage explique pourquoi ce verrouillage résiste même à une gouvernance ouverte de l'orchestrateur (Vol. VII) : la gouvernance logicielle ne transfère pas la propriété du HSM.

Rien dans les exigences documentées de SecNumCloud n'impose au prestataire qualifié de garantir l'exportabilité opérationnelle d'une clé de chiffrement générée sous son contrôle vers l'infrastructure d'un autre prestataire. Le référentiel protège l'intégrité et la confidentialité de la clé pendant qu'elle reste chez le prestataire qualifié — il ne traite pas sa portabilité au moment de la sortie.

L'Article 2, point 38, du règlement définit la « donnée exportable » en excluant explicitement les données dont l'export exposerait le fournisseur à une vulnérabilité de cybersécurité, ainsi que les actifs protégés par un droit de propriété intellectuelle ou un secret d'affaires. La notion d'« actif numérique », par ailleurs, ne couvre que les éléments pour lesquels le client dispose d'un droit d'usage indépendant de la relation contractuelle avec le fournisseur qu'il quitte. Une clé de chiffrement générée et détenue par le service de gestion de clés managé du fournisseur ne remplit clairement aucun des deux critères : elle n'a jamais été un droit possédé indépendamment de ce contrat, et son export fonctionnel pourrait, par construction, relever de la sécurité du service. Rien dans le texte ne tranche cependant explicitement ce cas — c'est précisément cette absence de qualification univoque, plutôt qu'une exclusion nommément affirmée, qui constitue l'angle mort documenté ici.

Un fournisseur d'identité applicatif auto-hébergé peut authentifier des utilisateurs humains et des services de haut niveau. Il ne peut, en revanche, se substituer à l'attestation matérielle qui certifie qu'une charge de travail donnée s'exécute effectivement sur le matériel qu'elle prétend utiliser — cette attestation exige un accès à la racine de confiance du fournisseur (puce de sécurité, microcode de l'hyperviseur), qu'aucun logiciel client ne peut reproduire depuis l'extérieur.

Une organisation utilisant SPIFFE/SPIRE peut faire porter la même identité de charge de travail, vérifiable de façon cryptographique, à travers plusieurs environnements cloud simultanément — condition nécessaire pour qu'un changement de fournisseur ne casse pas immédiatement la chaîne d'autorisation applicative.

S'affranchir totalement de cette dépendance suppose de renoncer aux abstractions managées les plus performantes — Serverless, PaaS natif — pour redescendre vers un niveau de calcul plus brut, où l'organisation contrôle elle-même l'attestation matérielle (par exemple via ses propres puces de sécurité sur une infrastructure qu'elle possède). C'est un gel fonctionnel symétrique à ceux déjà assumés aux Volumes VII et VIII : un compromis explicite entre confort opérationnel et souveraineté, pas une solution sans coût.

Aucune affirmation de ce volume n'est présentée comme sourcée de mémoire. Cette annexe permet à tout lecteur de vérifier, étape par étape, ce qu'Amine a demandé, ce que Claude a vérifié de façon indépendante avant d'écrire, et ce que Gemini a validé, rejeté ou fait corriger — plutôt que d'intégrer une suggestion sous réserve.

Gemini a rejeté la proposition de reformuler le remplacement Keycloak/Vault déjà traité au Volume IV, jugée insuffisante face à l'objection technique de l'identité de charge de travail. Claude a réorienté la cible empirique vers SPIFFE/SPIRE et le protocole KMIP, vérifiés indépendamment avant la rédaction du Chapitre III.

Claude a confirmé les deux références théoriques par recherche indépendante (titre exact, revue, volume, pages). Il a confirmé la matérialité empirique sur AWS KMS, Azure Key Vault (nCipher/Thales, FIPS 140-2 Level 2) et Google Cloud KMS (FIPS 140-2 Level 3) directement depuis la documentation officielle de chacun des trois fournisseurs, dans le cadre de l'audit global demandé par Gemini sur le premier jet. Claude a signalé, plutôt que corrigé silencieusement, une erreur sur le niveau FIPS avancé initialement par Gemini pour Azure (Level 3 proposé, Level 2 confirmé par la documentation Microsoft).

Claude a confirmé, par plusieurs sources concordantes, le contenu des exigences SecNumCloud sur la gestion des clés (génération, stockage, distribution, révocation), sans qu'aucune ne mentionne d'obligation de portabilité de la clé fonctionnelle. Gemini avait proposé une citation textuelle de l'Article 30 ; Claude l'a jugée trop approximative pour être reproduite telle quelle après vérification, et lui a substitué un ancrage plus précis, fondé sur la définition de la « donnée exportable » (Art. 2, point 38 — exclusion pour risque de cybersécurité) et de l'« actif numérique » (droit d'usage indépendant du contrat), corroborant l'hypothèse du flou sémantique de Gemini sans reproduire sa formulation inexacte.

Claude a confirmé, par plusieurs sources techniques concordantes, que l'attestation de nœud dans SPIRE s'appuie sur les API de métadonnées propres à chaque fournisseur cloud (document d'identité d'instance AWS EC2, jetons de métadonnées GCP, attestation Azure). Cette confirmation a permis à Claude de valider la démonstration centrale du Chapitre III sans avoir à l'affirmer de mémoire.

Gemini a signalé une dissymétrie de matérialité entre AWS d'une part, Azure et Google Cloud d'autre part au Chapitre I ; Claude l'a corrigée par l'injection d'une matérialité empirique symétrique pour les trois fournisseurs. Gemini a jugé l'incertitude juridique du Chapitre II sur le Data Act insuffisamment ancrée textuellement ; Claude l'a corrigée par un ancrage sur l'Article 2, points 37 et 38, après avoir constaté que la citation proposée par Gemini n'était pas vérifiable telle quelle.

Gemini a justifié son rapport d'audit initial en indiquant qu'il visait le service Azure Dedicated HSM (Level 3) plutôt que Key Vault Premium. Claude a vérifié ce fait, exact pris isolément — Dedicated HSM atteint bien le Level 3 — mais a relevé que la formulation d'origine de Gemini associait ces deux offres Azure distinctes sous un seul niveau de certification, ce qui constituait une conflation. La correction que Claude avait apportée au jet 2 (Level 2 pour Key Vault Premium) reste exacte et n'a pas eu besoin d'être retouchée à l'issue de ce contre-audit.