La plupart des entreprises européennes chiffrent déjà leurs données dans AWS ou Azure. Le chiffrement au repos est activé, la case est cochée, l'auditeur passe au point suivant.

Posez pourtant une question de plus : qui détient la clé ? Dans la configuration par défaut, c'est la même entreprise que celle qui héberge les données. Vos fichiers sont dans le stockage du fournisseur cloud, et les clés qui les protègent dans son service de gestion de clés. Les deux sont exploités par une entreprise américaine.

Cela compte à cause du CLOUD Act, la loi qui permet aux autorités américaines d'exiger des données auprès des fournisseurs américains, où qu'elles soient stockées, y compris dans une région européenne. Si le fournisseur détient à la fois les données et la clé, le chiffrement vous protège de beaucoup de choses, mais pas du fournisseur lui-même, ni de ceux qui peuvent le contraindre.

Un modèle change la donne : Hold Your Own Key (HYOK), « gardez votre propre clé ». Depuis QuantumAPI 0.25.0, vous pouvez l'essayer avec une clé qui reste en Europe.

Schéma d'architecture. À gauche, votre cloud : Azure Managed HSM (EKM) ou AWS KMS (XKS), à côté de vos données dans S3, EBS, Azure Storage ou Azure SQL, qui ne détient que des clés de données enveloppées. Chaque requête de wrap ou d'unwrap passe par TLS / AES-256, un transport classique défini par le fournisseur cloud, jusqu'au magasin de clés externe QuantumAPI dans l'UE, où la clé est générée par un QRNG, stockée sous ML-KEM-768, et où chaque appel est audité. Un interrupteur d'arrêt désactive la clé ou déconnecte le magasin : QuantumAPI refuse alors, et le cloud ne peut plus désenvelopper ses clés de données. — Fonctionnement de Hold Your Own Key avec QuantumAPI. Le lien entre le cloud et QuantumAPI est du TLS / AES-256 classique, imposé par le fournisseur cloud ; ce qui est post-quantique, c'est la façon dont nous stockons la clé de notre côté.

Hold Your Own Key : le cloud demande, vous décidez

AWS et Microsoft publient tous deux un moyen de garder la clé hors de leur propre infrastructure.

AWS KMS External Key Store (XKS) permet de créer des clés KMS dont le matériel réside dans un gestionnaire de clés externe. Azure Key Vault Managed HSM External Key Management (EKM) fait de même pour les services Azure qui acceptent des clés gérées par le client.

Le principe est simple. Vos données restent où elles sont : dans S3, EBS, Azure Storage ou Azure SQL. Mais chaque fois que le cloud doit chiffrer ou déchiffrer une clé de données (sur AWS), ou l'envelopper ou la désenvelopper (sur Azure), il doit appeler votre gestionnaire de clés et lui demander. La clé elle-même n'entre jamais chez le fournisseur cloud.

Vous obtenez ainsi ce que le chiffrement par défaut ne peut pas offrir : un interrupteur hors du cloud. Si vous coupez l'accès, le cloud ne peut plus ouvrir ses clés de données, et vos données dans ce cloud deviennent illisibles. Ni supprimées, ni déplacées : verrouillées, jusqu'à ce que vous en décidiez autrement.

Ce qu'apporte QuantumAPI

QuantumAPI implémente les spécifications publiques de proxy AWS XKS et Azure EKM. Vous créez une clé externe dans QuantumAPI, vous y connectez votre magasin de clés AWS ou votre Managed HSM, et dès lors AWS ou Azure interroge QuantumAPI chaque fois qu'il a besoin de cette clé. Voici ce que vous obtenez de notre côté :

Une clé conservée dans l'UE. Le matériel de clé est généré et conservé par QuantumAPI, une entreprise européenne, sur une infrastructure située dans l'UE. AWS et Microsoft ne le reçoivent jamais.
Des clés issues de l'aléa quantique. Les clés externes sont générées à partir d'entropie quantique fournie par un service QRNG (actuellement l'ANU QRNG de l'Australian National University). Si la source quantique est indisponible, un générateur cryptographique standard (CSPRNG) prend le relais. Dans les deux cas, la source réellement utilisée est enregistrée sur chaque clé : un repli n'est jamais masqué.
Une protection post-quantique au repos. Votre clé est stockée chiffrée sous une chaîne de clés protégée par ML-KEM-768 (FIPS 203), le standard post-quantique du NIST.
Chaque appel audité. Chaque opération apparaît dans votre journal d'activité des clés : qui l'a demandée (le principal IAM sur AWS, le pool Managed HSM sur Azure), via quel service, le résultat et la latence.
Un coupe-circuit. Désactivez une clé ou déconnectez un magasin dans le portail, et QuantumAPI commence aussitôt à refuser les requêtes de ce cloud.
Une tarification à l'usage. Chaque opération de clé réussie du cloud compte comme un appel API de votre forfait. Les clés externes et les magasins sont gratuits et illimités, comme toutes les clés dans QuantumAPI.

Sur AWS, il y a un bonus. KMS utilise un double chiffrement : il chiffre d'abord dans AWS, puis avec votre clé externe. Ni AWS ni QuantumAPI ne peuvent déchiffrer vos données seuls. Le protocole d'Azure fonctionne autrement (QuantumAPI enveloppe directement la clé de données), nous ne faisons donc pas cette affirmation pour Azure.

Ce qu'il ne fait pas (et nous préférons le dire d'abord)

La sécurité post-quantique est toute notre marque ; il serait donc tentant de parler d'« AWS post-quantique ». Ce n'est pas le cas, et nous ne le vendrons pas ainsi.

Les protocoles du cloud sont classiques. Le trafic entre AWS ou Azure et notre proxy utilise ce que définissent les fournisseurs : TLS, AES-256 et, sur Azure, des certificats client basés sur RSA. Aucun ne négocie ML-KEM aujourd'hui. AES-256 résiste bien aux ordinateurs quantiques ; l'échange de clés classique de TLS, non, et cette partie dépend du client du fournisseur cloud, pas de nous. Votre bucket S3 ou votre compte Azure Storage ne devient pas résistant au quantique grâce à cette fonctionnalité. Ce qui est post-quantique, c'est la façon dont nous stockons votre clé.

Ce n'est pas un HSM. La version 1 est un gestionnaire de clés logiciel, sans certification FIPS 140-3. Si votre politique exige un HSM certifié, ce n'est pas encore le produit qu'il vous faut.

Le coupe-circuit bloque les nouvelles requêtes, pas les clés en cache. Certains services cloud gardent les clés de données en mémoire pendant un certain temps (S3 Bucket Keys, disques attachés, Azure Storage). Ceux-là continuent de fonctionner jusqu'à ce que le service redemande. La révocation atteint tout dans la durée de ce cache, pas dans la même seconde.

C'est une preview. Si le cloud ne peut pas joindre QuantumAPI, il ne peut pas utiliser votre clé, et les données qui en dépendent deviennent indisponibles. C'est tout le principe du HYOK, et c'est aussi pourquoi nous vous demandons de commencer avec des charges de test ou non critiques. Nous ne sommes pas partenaire certifié d'AWS ou de Microsoft, et Google Cloud n'est pas pris en charge.

Comment ça marche

Du point de vue du cloud, QuantumAPI est simplement un gestionnaire de clés externe. Une requête typique se déroule ainsi :

Une application lit un fichier dans S3, ou une base Azure SQL démarre. Le service cloud a besoin de sa clé de données.
AWS KMS ou Azure Managed HSM envoie une requête signée au proxy QuantumAPI : « déchiffre ceci avec la clé X » (AWS) ou « désenveloppe ceci avec la clé X » (Azure).
QuantumAPI vérifie qui appelle (la signature AWS ou le certificat client Azure), que la clé appartient bien à cette connexion, et que ni la clé ni la connexion n'ont été coupées.
Si tout est en ordre, QuantumAPI effectue l'opération AES-256 avec votre clé et renvoie le résultat. L'appel est inscrit dans votre journal d'activité des clés et compté comme un appel API.
Si vous avez actionné le coupe-circuit, QuantumAPI refuse, et le cloud ne peut pas ouvrir la clé de données.

À voir : Vos clés Azure, gardées en Europe

Durée: 2:46videos.languages.frOuvrir la page de la vidéo

À voir : Encrypt at rest with your own key, and erase it in one click

Durée: 2:32AnglaisOuvrir la page de la vidéo

Pour qui, et comment l'essayer

Les magasins de clés externes s'adressent aux entreprises européennes réglementées qui s'appuient sur AWS ou Azure et doivent démontrer qui contrôle l'accès à leurs données. Pensez à DORA et à ses règles sur le risque lié aux prestataires TIC pour les entités financières, à NIS2 pour les entités essentielles et importantes, ou au débat sur les transferts internationaux au titre du RGPD ouvert par l'arrêt Schrems II. Le HYOK ne vous rend pas conforme à lui seul, mais il apporte une réponse concrète et vérifiable à la question « notre fournisseur cloud peut-il lire nos données sans nous ? ».

Un exemple fictif : un assureur européen conserve ses contrats dans S3, à Francfort. Son équipe risques veut retirer les clés des mains du fournisseur et garder une trace de chaque accès. Avec un magasin de clés externe, le bucket utilise une clé KMS adossée à QuantumAPI. Chaque déchiffrement apparaît avec le rôle IAM et le service qui l'a demandé, et si l'assureur doit un jour couper l'accès, une seule action dans QuantumAPI arrête les nouveaux déchiffrements.

Vous voulez le contrôle complet ? Installez-le dans votre propre centre de données. Si la raison d'être du HYOK est que personne d'autre ne contrôle vos clés, la configuration la plus solide n'est pas notre SaaS : c'est QuantumAPI installé on-premises, dans votre propre centre de données. Le gestionnaire de clés, sa base de données, la génération d'aléa (la source quantique ou son repli), le journal d'audit et le coupe-circuit sont alors sous votre contrôle, et aucun tiers, nous compris, n'est sur le chemin. La prise en charge des magasins de clés externes arrive dans l'édition on-premises ; elle n'y est pas encore. La preview SaaS est le moyen le plus rapide d'essayer l'idée dès aujourd'hui. L'on-premises garde le même modèle à l'usage : facturé aux appels API et au stockage, jamais par utilisateur ni par clé.

Le compromis, sans détour : si vous l'exploitez vous-même, sa disponibilité vous appartient aussi. Si votre proxy tombe, le cloud ne peut plus déchiffrer vos données. Cela joue dans les deux sens, et c'est le prix du contrôle total.

Ce que nous avons mesuré. Le 24 octobre 2026, nous avons testé le parcours Azure de bout en bout avec un véritable Azure Key Vault Managed HSM en North Europe. Le ekm-connection check d'Azure a identifié QuantumAPI, les allers-retours wrap et unwrap ont fonctionné, la déconnexion dans QuantumAPI a fait échouer immédiatement l'unwrap Azure suivant avec « disconnected in QuantumAPI » (le Managed HSM ne met pas les unwrap en cache), et la reconnexion a rétabli l'accès. Dans QuantumAPI, chaque wrap ou unwrap a pris environ 2 à 14 ms une fois la clé en cache, et environ 100 ms au premier appel, celui qui charge la clé. Il s'agit uniquement du temps de traitement de notre côté : le trajet réseau jusqu'au cloud s'y ajoute, et le total doit tenir dans le budget de 250 ms du cloud, d'où la nécessité de faire tourner le service près des régions cloud qu'il dessert. Le proxy AWS XKS est implémenté mais n'a pas encore été testé en conditions réelles face à AWS ; nous publierons ces résultats dès que nous les aurons.

Portail QuantumAPI, tableau Key activity de la clé azure-demo-kek. Les appels wrap et unwrap du Managed HSM qapi-demo-ekm-hsm-dd12 réussissent en 4,9 à 14,5 ms ; après l'événement Disconnected, l'unwrap suivant est Denied avec connection_disconnected. — Le journal Key activity de notre test Azure du 24/10/2026 : appels wrap et unwrap du Managed HSM, puis Disconnect, puis l'unwrap suivant refusé. L'utilisateur du portail qui a cliqué sur Disconnect est masqué.

Les magasins de clés externes sont disponibles en preview dans QuantumAPI 0.25.0. La configuration pas à pas pour AWS et Azure se trouve sur docs.quantumapi.eu. Si vous souhaitez lancer un pilote ou discuter de votre cas, contactez-nous : nous préférons connaître vos exigences maintenant, pendant que la fonctionnalité prend forme.