KMS hébergé en France : il livre vos clés, il ne prouve pas votre conformité

Un KMS hébergé en France suffit-il à prouver votre conformité ?

Non. Un KMS chiffre vos données et garde vos clés sous juridiction européenne, hors CLOUD Act. Il ne produit pas la preuve documentée que votre auditeur réclame. Le chiffrement est une mesure attendue par le RGPD, pas une attestation. Entre la clé qui protège et le dossier qui démontre, il reste un travail que le fournisseur d'infrastructure ne fait pas à votre place.

C'est un contresens fréquent chez un éditeur SaaS pressé de débloquer un contrat. Choisir un fournisseur de clés hébergé en France répond à une question de localisation et de juridiction. Répondre à un questionnaire sécurité, monter un dossier HDS ou documenter l'article 28 de DORA répond à une autre : celle de la preuve. Les deux problèmes se ressemblent, ils ne se résolvent pas avec le même outil.

Que livrent réellement AWS, Scaleway et OVHcloud en 2026 ?

Une brique commune : des clés gérées, hébergées en Europe. AWS a ouvert son European Sovereign Cloud le 15 janvier 2026 avec KMS et External Key Store dès le lancement. Eviden (groupe Atos) y est devenu partenaire le 10 mars 2026 avec un système de clés externe adossé à un HSM. Scaleway propose son chiffrement côté serveur via Key Manager, OVHcloud teste son KMS on HSM en alpha.

Le détail confirme le mouvement. Selon le blog sécurité d'AWS du 15 janvier 2026, la première région du AWS European Sovereign Cloud (Brandebourg) inclut AWS KMS et AWS Private Certificate Authority parmi ses services initiaux. Eviden a annoncé le 10 mars 2026 que son external key management est disponible sur ce cloud, avec un HSM européen gardant la clé maître hors du cloud comme racine de confiance.

Chez Scaleway, la documentation Key Manager décrit un chiffrement côté serveur (SSE-KMS) fondé sur une hiérarchie de clés en AES-256-GCM : une clé de chiffrement de clés (KEK) protège les clés de chiffrement de données (DEK), avec un matériel de clé qui n'est jamais exporté en clair. OVHcloud, de son côté, indique sur son portail Labs que son offre KMS on HSM est en phase alpha, gratuite, avec une échéance fixée au 31 août 2026. Toutes ces offres partagent le même périmètre : gérer et protéger des clés. Aucune n'annonce la génération d'un dossier de conformité prêt pour un auditeur.

Pourquoi la clé protège-t-elle sans rien prouver ?

Parce que la preuve relève de votre responsabilité, pas de celle du fournisseur. Le modèle de responsabilité partagée le formalise : le fournisseur sécurise l'infrastructure, le client sécurise ce qu'il y dépose, active le chiffrement, gère ses politiques de clés et documente ses contrôles comme éléments de preuve. Un KMS met l'outil à disposition. Décider de l'activer, le configurer et le prouver reste au client.

AWS l'écrit noir sur blanc. Son livre blanc Risk and Compliance pose la distinction « sécurité du cloud » (fournisseur) contre « sécurité dans le cloud » (client), et range explicitement l'activation du chiffrement, la gestion des clés et la journalisation d'audit parmi les contrôles que le client doit tenir et documenter. Autrement dit, la certification de l'hyperscaler couvre la salle des machines, pas votre traitement de données. La preuve de votre conformité, elle, se construit au-dessus, et c'est précisément la partie qu'un attestation de conformité exige et qu'un KMS seul ne fournit pas.

Que réclame un auditeur RGPD, HDS ou DORA au-delà de la clé ?

Une démonstration, pas une case cochée. Le RGPD Article 32, en vigueur depuis mai 2018, cite le chiffrement comme mesure appropriée mais impose surtout de démontrer l'efficacité des mesures dans la durée. Le référentiel HDS de l'ANS et l'article 9 du règlement DORA vont dans le même sens : ils veulent voir des traces, un cycle de vie des clés et des preuves de rotation, pas la seule existence d'une clé.

Trois textes cadrent cette attente, et aucun ne se satisfait de la présence d'un KMS. Le règlement européen 2016/679 (RGPD), à son article 32, associe le chiffrement à une obligation de moyens éprouvés et régulièrement testés, adossée au principe de responsabilité de l'article 5.2. La CNIL, dans son dossier sur la sécurité des données personnelles, rappelle que l'organisme doit pouvoir prouver l'adéquation de ses mesures. Le référentiel de certification des hébergeurs de données de santé publié par l'ANS attend une gestion documentée des clés côté hébergeur, sachant que la certification HDS vise l'hébergeur, pas l'éditeur. Enfin, le règlement 2022/2554 (DORA), en application depuis le 17 janvier 2025, traite la gestion des clés à son article 9 et la chaîne de sous-traitance à son article 28. Dans les trois cas, l'auditeur veut un journal d'audit opposable, pas une capture d'écran de console.

Comment un éditeur comble-t-il l'écart entre la clé et la preuve ?

En raccordant le chiffrement à un journal d'audit opposable qui alimente directement le dossier. C'est la brique que MAFATE ajoute au-dessus de la gestion de clés : chaque opération est inscrite dans un journal chaîné par HMAC, dont l'altération est détectable, et les rapports de conformité RGPD sont générés à partir de ces traces réelles, pas d'un tableur de politiques rempli à la main.

La formulation honnête compte ici plus qu'ailleurs. MAFATE génère des rapports de conformité pour les presets RGPD Article 32 et Article 30(2), adossés au journal d'audit du tenant (algorithmes, cycle de vie des clés, preuves de rotation, contrôle d'accès), exportables en PDF, CSV ou JSON et vérifiables par leur intégrité. Ces rapports ne sont pas signés cryptographiquement : ils contribuent au dossier, ils ne constituent pas un certificat. Côté clés, le HSM est logiciel (PKCS#11) aujourd'hui, la migration vers un HSM matériel est planifiée. MAFATE ne détient à ce jour aucune certification ISO 27001, SOC 2 ni HDS : ces jalons sont en feuille de route, pas acquis, et l'hébergement HDS relève de l'hébergeur, pas de l'éditeur de la brique de chiffrement.

Le point à retenir tient en une phrase. Un KMS hébergé en France règle la question « où sont mes clés ». Il ne règle pas la question « comment je le prouve », qui est celle qui bloque la signature d'un client régulé. Les deux méritent une réponse, elles n'appellent pas le même produit.

Si vous perdez ou retardez un contrat parce qu'on vous réclame une preuve de conformité, la brique de chiffrement d'un éditeur SaaS régulé se cadre sur /solutions/saas, les mécanismes de preuve sur /compliance, et vous pouvez en discuter avec un ingénieur via /contact.