[{"data":1,"prerenderedAt":729},["ShallowReactive",2],{"home-/fr":3,"whitepapers-fr":176},{"id":4,"title":5,"body":6,"brand":12,"compliance":13,"description":5,"docs":17,"extension":29,"faq":30,"footer":53,"hero":59,"locale":67,"meta":68,"navigation":69,"path":70,"pocPage":71,"seo":72,"services":73,"servicesDetail":96,"stem":146,"switchPage":71,"trustPage":71,"trustTeaser":147,"useCases":152,"__hash__":175},"content/fr/index.md","",{"type":7,"value":8,"toc":9},"minimark",[],{"title":5,"searchDepth":10,"depth":10,"links":11},2,[],"Alcazarix",{"eyebrow":14,"title":15,"body":16},"Conformité","Conçu pour le contrôle juridictionnel, au-delà du chiffrement","Alcazarix permet une véritable propriété externe des clés en séparant leur génération, leur stockage et leur gouvernance de l’infrastructure des hyperscalers – de sorte qu’aucune entreprise unique, et aucune juridiction unique, ne contrôle à la fois vos données et les clés qui les déverrouillent. Cette séparation architecturale aide les organisations à répondre aux enjeux de Schrems II, de souveraineté des données au sens du RGPD et d’accès transfrontalier, sans renoncer aux services cloud-native.",{"eyebrow":18,"title":19,"body":20,"links":21},"Documentation","Tout ce dont votre équipe a besoin pour se lancer","Des guides structurés, une documentation de référence et des procédures de migration accompagnent vos développeurs, de la première clé au déploiement complet.",[22,25,27],{"label":23,"href":24},"Référence API","#",{"label":26,"href":24},"Guides SDK",{"label":28,"href":24},"Procédures de migration","md",{"eyebrow":31,"title":32,"subtitle":33,"items":34},"FAQ","Les questions que nous posent les équipes sécurité","Les questions qui reviennent à chaque revue d’architecture, avec des réponses claires.",[35,38,41,44,47,50],{"question":36,"answer":37},"Alcazarix peut-il lire mes données ?","Non. Alcazarix conserve des clés de chiffrement et exécute des opérations sur les clés, mais vos données ne transitent jamais par notre infrastructure. Votre fournisseur cloud détient vos données chiffrées, mais jamais vos clés. Aucune des deux parties ne peut rien déchiffrer seule.",{"question":39,"answer":40},"Alcazarix est-il certifié FIPS 140 ?","Non, et c’est un choix délibéré plutôt qu’un oubli. Notre plateforme adossée à des HSM se concentre sur les contrôles qui déterminent les résultats concrets d’une gestion externe des clés – propriété des clés, gouvernance des accès, auditabilité et résilience – sans les coûts ni la rigidité qu’impose une certification FIPS. Si votre processus d’achat exige strictement une conservation certifiée FIPS, nous ne sommes peut-être pas le bon choix – et nous vous le dirons très tôt.",{"question":42,"answer":43},"Comment votre structure se situe-t-elle vis-à-vis de lois comme le CLOUD Act américain ?","Nous décrivons notre structure juridique et opérationnelle avec précision et de manière factuelle – quelles entités existent, qui les détient et ce que chacune contrôle – sur notre page Confiance & conservation, et nous mettons notre dossier de conservation à disposition de vos juristes sous NDA. Nous ne formulons pas d’affirmations juridiques catégoriques à votre place ; nous donnons à votre équipe juridique les faits nécessaires pour tirer ses propres conclusions.",{"question":45,"answer":46},"Qu’advient-il de mes clés si Alcazarix cesse ses activités ?","La conservation des clés repose sur une infrastructure redondante adossée à des HSM, opérée par des entités distinctes dans des juridictions distinctes, et vous conservez à tout moment la capacité de faire tourner ou de révoquer vos clés. Des procédures documentées de continuité et de sortie font partie de notre onboarding – demandez la documentation de continuité lors de votre évaluation.",{"question":48,"answer":49},"Nous utilisons Thales DPoD ou Fortanix DSM aujourd’hui. La migration est-elle difficile ?","Plusieurs de nos clients ont fait exactement ce choix. Nous fournissons une revue d’architecture, un plan de migration pour ré-encapsuler ou faire tourner les clés vers la conservation Alcazarix, et une preuve de concept gratuite de 30 jours pour valider l’intégration avant tout engagement.",{"question":51,"answer":52},"Combien cela coûte-t-il ?","La tarification est fondée sur l’usage et transparente – pas de décompte d’appliances, pas de paliers de capacité, pas de suite imposée. Contactez l’équipe commerciale pour un devis, ou commencez par la preuve de concept gratuite de 30 jours.",{"copyright":54,"email":55,"address":56},"Droits d’auteur 2026 Alcazarix, Inc","hello@alcazarix.com",[57,58],"Alcazarix B.V.","Coolsingel 65, Floor 5, 3012 AC Rotterdam, Netherlands",{"eyebrow":60,"title":61,"subtitle":62,"ctaPrimary":63,"ctaSecondary":64,"metaPrimary":65,"metaSecondary":66},"Conservation indépendante des clés","Conservation de clés indépendante pour le cloud.","Alcazarix conserve les clés de chiffrement qui protègent vos données hors de portée de votre fournisseur cloud. Une conservation de clés adossée à des HSM, juridiquement séparée et intégrée nativement à AWS KMS, Azure Key Vault et Google Cloud KMS.","Contacter l’équipe commerciale","Échanger avec un architecte","Indépendant de tout fournisseur cloud","AWS · Azure · Google Cloud","fr",{},true,"/fr",null,{"description":5},{"eyebrow":74,"title":75,"subtitle":76,"items":77},"Pourquoi Alcazarix","Votre cloud ne devrait pas détenir vos données et vos clés","Alcazarix est un courtier de clés indépendant. Nous conservons et gouvernons des clés de chiffrement – sans activité cloud, sans activité d’appliances, sans suite de sécurité tentaculaire. Uniquement une conservation que vous pouvez vérifier.",[78,81,84,87,90,93],{"title":79,"body":80},"Indépendant par conception","Votre fournisseur cloud stocke des données chiffrées, mais jamais vos clés. Alcazarix conserve vos clés, mais jamais vos données. Aucune des deux parties ne peut rien lire seule.",{"title":82,"body":83},"Natif pour AWS, Azure et Google Cloud","Intégration directe avec AWS KMS External Key Store (XKS), Azure Key Vault Managed HSM BYOK et Google Cloud KMS EKM. Aucune modification applicative, aucune gestion de clés dans votre code.",{"title":85,"body":86},"Une séparation juridictionnelle, noir sur blanc","La conservation des clés est opérée par des entités juridiques distinctes – Alcazarix, Inc. depuis des datacenters au Canada pour l’Amérique du Nord, et Alcazarix Europe B.V., détenue séparément, depuis des datacenters en Allemagne pour l’Europe. Notre page Confiance & conservation montre précisément qui possède et contrôle quoi.",{"title":88,"body":89},"Une alternative ciblée aux fournisseurs historiques","Des équipes quittent Thales DPoD et Fortanix DSM pour Alcazarix – pour une tarification transparente fondée sur l’usage et un produit qui fait une chose et la fait bien, sans payer très cher une suite de fonctionnalités dont elles n’ont pas besoin.",{"title":91,"body":92},"Conçu pour les équipes réglementées","Plateformes de santé et d’essais cliniques, services financiers soumis à DORA, et tout SaaS servant des clients européens. Répondez aux attentes des régulateurs et des grands comptes sans ralentir l’ingénierie.",{"title":94,"body":95},"Des contrôles de niveau entreprise","Contrôles de sécurité alignés sur SOC 2 Type II et ISO 27001, génération de clés adossée à des HSM, pistes d’audit détaillées, contrôle d’accès fondé sur les rôles et disponibilité garantie par SLA.",{"eyebrow":97,"title":98,"intro":99,"items":100},"Services","Une conservation de clés managée, avec des clés que vous possédez","Alcazarix fournit une conservation de clés indépendante en service managé, permettant aux clients de conserver la pleine propriété et la maîtrise des clés de chiffrement utilisées dans les environnements cloud.",[101,109,116,124,132,140],{"title":102,"description":103,"features":104},"Gestion des clés sous le contrôle du client","Alcazarix exploite un service de gestion des clés à haute disponibilité, adossé à des HSM et directement intégré aux plateformes KMS des fournisseurs cloud, afin que vos clés restent entièrement sous votre contrôle.",[105,106,107,108],"Clés maîtresses générées et protégées par HSM","Stockage sécurisé et gestion du cycle de vie des clés","Activation, rotation, suspension et révocation des clés","Contrôles d’accès et de gouvernance définis par le client",{"title":110,"description":111,"features":112},"Intégrations KMS cloud","Prise en charge native du BYOK pour les principaux fournisseurs cloud, avec des opérations sur les clés isolées sur le plan juridictionnel.",[113,114,115],"Compatibilité avec AWS KMS External Key Store (XKS)","Azure Key Vault Managed HSM BYOK","Intégration Google Cloud KMS EKM",{"title":117,"description":118,"features":119},"Gouvernance & auditabilité","Alcazarix fournit la visibilité et les contrôles nécessaires aux environnements réglementés.",[120,121,122,123],"Journaux détaillés d’utilisation des clés","Audit des actions administratives","Contrôle d’accès fondé sur les rôles","Données d’audit exportables pour les contrôles de conformité",{"title":125,"description":126,"features":127},"Haute disponibilité & résilience","Notre service est conçu pour répondre aux exigences de disponibilité des charges de travail cloud-native.",[128,129,130,131],"Infrastructure redondante adossée à des HSM","Options de séparation géographique","Architecture d’accès aux clés tolérante aux pannes","Disponibilité garantie par SLA",{"title":133,"description":134,"features":135},"Intégration & accompagnement","Nous travaillons directement avec les équipes sécurité et plateforme de nos clients afin d’assurer un déploiement fluide.",[136,137,138,139],"Revue d’architecture et conseils d’intégration","Assistance à la configuration BYOK","Accompagnement à la migration depuis Thales DPoD et Fortanix DSM","Accès direct à des experts techniques",{"title":141,"description":142,"features":143},"Conservation des clés","Infrastructure de gestion des clés et API dédiée aux opérations sur les clés détenues par des entités distinctes.",[144,145],"Conservation des clés en Amérique du Nord dans les datacenters Alcazarix au Canada, sous le contrôle d’Alcazarix, Inc.","Conservation des clés en Europe dans les datacenters Alcazarix en Allemagne, sous le contrôle d’Alcazarix Europe B.V., détenue séparément.","fr/index",{"eyebrow":148,"title":149,"body":150,"cta":151},"Confiance & conservation","Qui détient réellement vos clés ?","Chez Alcazarix, la conservation est une architecture de propriété, pas une promesse – des entités juridiques distinctes, des juridictions distinctes et des frontières de contrôle que vous pouvez présenter à vos juristes.","Découvrir le fonctionnement de la conservation",{"eyebrow":153,"title":154,"subtitle":155,"items":156},"Cas d’usage","Un conservateur, de nombreuses raisons de détenir vos clés","Où que vivent vos données dans AWS, Azure ou Google Cloud, la conservation indépendante des clés transforme le chiffrement d’une simple case à cocher en contrôle réel.",[157,160,163,166,169,172],{"title":158,"body":159},"Offrez la propriété des clés à vos clients","Vos clients grands comptes exigent CMEK ou BYOK avant de signer. Proposez-le via Alcazarix au lieu de bâtir vous-même une pratique de gestion de clés – vos clients possèdent leurs clés, votre équipe continue de livrer du produit.",{"title":161,"body":162},"Souveraineté européenne des données","Rendez défendables les données personnelles européennes hébergées sur des clouds américains. Des clés conservées en Allemagne par une entité européenne détenue séparément donnent à votre argumentaire Schrems II et RGPD un ancrage technique et juridique concret.",{"title":164,"body":165},"Sortie du cloud & risque de concentration","Les régulateurs attendent de plus en plus des plans de sortie du cloud crédibles. Des clés conservées à l’extérieur sont un contrôle que vous pouvez présenter en audit – et un levier discret à chaque renouvellement de contrat.",{"title":167,"body":168},"Réponse à incident & crypto-destruction","Révoquez l’accès aux clés en quelques minutes pour rendre les données cloud illisibles lors d’une compromission ou d’un litige avec un fournisseur. Retirez définitivement des données par effacement cryptographique, à l’appui de vos obligations de suppression RGPD.",{"title":170,"body":171},"L’IA sans abandonner vos données","Corpus d’entraînement, bases vectorielles et journaux d’inférence restent vos données. Gardez-les chiffrés sous des clés que vos fournisseurs d’IA et de cloud ne détiennent jamais.",{"title":173,"body":174},"Une autorité de clés unique sur tous les clouds","Remplacez trois configurations KMS natives divergentes par un conservateur unique, un modèle de politiques unique et une piste d’audit unique sur AWS, Azure et Google Cloud.","J5wGQ_EOelnPxsSOmG7qkrAC3pmP53SsjgY5ktMEWPw",[177,350,541],{"id":178,"title":179,"body":180,"category":339,"description":340,"extension":29,"locale":67,"meta":341,"navigation":69,"path":342,"pdf":343,"preview":344,"rank":345,"seo":346,"slug":347,"stem":348,"__hash__":349},"whitepapers/fr/livreblanc/schrems-ii-byok.md","Schrems II et BYOK : guide d’architecture de sécurité pour les plateformes d’essais cliniques",{"type":7,"value":181,"toc":329},[182,187,191,194,198,201,204,207,210,214,217,220,223,226,230,233,236,239,242,245,248,251,255,258,261,264,267,270,274,277,280,283,286,289,292,295,299,302,305,308,311,315,318,321],[183,184,186],"h2",{"id":185},"synthèse","Synthèse",[188,189,190],"p",{},"L’arrêt Schrems II a durablement modifié les conditions de transfert des données à caractère personnel européennes vers les États-Unis. Pour les plateformes d’essais cliniques, qui traitent des données de patients parmi les plus sensibles, les conséquences sont majeures. Les clauses contractuelles types (SCC) restent un mécanisme de transfert valable, mais uniquement lorsqu’elles sont associées à une analyse d’impact du transfert (TIA) démontrant un niveau de protection des données véritablement équivalent. Lorsque les données sont hébergées chez des hyperscalers américains, cette démonstration devient de plus en plus difficile sans contrôles techniques empêchant totalement le fournisseur cloud d’accéder aux données.",[188,192,193],{},"Bring Your Own Key (BYOK) constitue aujourd’hui la mesure technique complémentaire la plus pratique pour les plateformes d’essais cliniques. Correctement mis en œuvre, avec des clés adossées à des HSM et conservées hors du périmètre de confiance de l’hyperscaler, le BYOK garantit que même une demande légale d’accès adressée au fournisseur cloud par les autorités américaines ne produira aucune donnée exploitable. Ce livre blanc présente les risques liés à Schrems II pour les plateformes d’essais cliniques, les exigences techniques d’un BYOK défendable et les caractéristiques concrètes d’une architecture conforme.",[183,195,197],{"id":196},"_1-larrêt-schrems-ii-et-ses-exigences-concrètes","1. L’arrêt Schrems II et ses exigences concrètes",[188,199,200],{},"En juillet 2020, la Cour de justice de l’Union européenne (CJUE) a invalidé le cadre du Privacy Shield UE–États-Unis dans l’affaire Data Protection Commissioner contre Facebook Ireland Limited et Maximillian Schrems (C-311/18). La Cour a estimé que le droit américain de la surveillance, notamment la section 702 de la FISA et l’Executive Order 12333, permet aux services de renseignement américains d’accéder aux données à caractère personnel traitées par des entreprises américaines dans des conditions incompatibles avec le droit au recours juridictionnel des personnes concernées dans l’UE.",[188,202,203],{},"Les clauses contractuelles types n’ont pas été invalidées. La Cour a toutefois été explicite : les SCC ne constituent un mécanisme de transfert valable que si l’importateur de données peut effectivement respecter les garanties contractuelles qu’elles prévoient. Lorsque le droit du pays de destination l’en empêche, comme le droit américain de la surveillance pour les données détenues par des fournisseurs cloud américains, les SCC seules ne suffisent pas.",[188,205,206],{},"En novembre 2020, le Comité européen de la protection des données (CEPD) a publié les recommandations 01/2020, qui ont formalisé l’exigence d’une analyse d’impact du transfert et recensé les mesures supplémentaires susceptibles de rendre défendable un transfert fondé sur les SCC. Point essentiel, le CEPD a identifié une catégorie de mesures techniques — notamment le chiffrement lorsque l’exportateur de données conserve seul le contrôle des clés — pouvant rendre les données « inaccessibles » à l’importateur et donc effectivement protégées, y compris au regard du droit américain de la surveillance.",[188,208,209],{},"En pratique, les plateformes d’essais cliniques qui traitent des données de patients de l’EEE sur des hyperscalers américains doivent pouvoir démontrer que le fournisseur cloud ne peut pas accéder aux données en clair, même s’il y est légalement contraint. Un BYOK correctement mis en œuvre permet d’apporter cette démonstration.",[183,211,213],{"id":212},"_2-pourquoi-les-données-dessais-cliniques-présentent-un-risque-particulièrement-élevé","2. Pourquoi les données d’essais cliniques présentent un risque particulièrement élevé",[188,215,216],{},"Toutes les données à caractère personnel ne présentent pas le même profil de risque au regard de Schrems II. Les données d’essais cliniques se situent au niveau d’exposition le plus élevé pour deux raisons qui se cumulent.",[188,218,219],{},"Premièrement, les données d’essais cliniques relèvent des catégories particulières de données visées à l’article 9 du RGPD. Les données de santé, génétiques et biométriques appartiennent toutes à cette catégorie soumise à des conditions de traitement plus strictes et à des sanctions potentielles plus lourdes en cas de violation. Une violation de Schrems II portant sur des données d’essais cliniques n’est pas un incident RGPD ordinaire : elle expose l’exploitant de la plateforme aux sanctions prévues à l’article 83, paragraphe 5, pouvant atteindre 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial.",[188,221,222],{},"Deuxièmement, les données d’essais cliniques sont irremplaçables sur le plan opérationnel. Contrairement à une base de données clients compromise, elles ne peuvent pas simplement être régénérées : elles constituent le dossier principal de l’essai. Les autorités de réglementation, l’EMA, la FDA et les autorités nationales compétentes imposent des exigences d’archivage et d’accès qui s’étendent sur plusieurs décennies. Toute décision d’architecture compromettant l’intégrité ou la disponibilité des données entraîne donc des conséquences à la fois réglementaires et cliniques.",[188,224,225],{},"La combinaison d’une forte sensibilité réglementaire, de longues durées de conservation et de flux de données transfrontaliers — le traitement de données de patients européens sur des plateformes américaines étant l’architecture par défaut de la plupart des fournisseurs SaaS eClinical — soumet les plateformes d’essais cliniques à un examen au regard de Schrems II plus approfondi que presque toute autre catégorie de SaaS.",[183,227,229],{"id":228},"_3-les-limites-du-couple-scc-tia-et-la-réponse-apportée-par-le-byok","3. Les limites du couple SCC + TIA et la réponse apportée par le BYOK",[188,231,232],{},"Lorsque des plateformes d’essais cliniques s’appuient sur les SCC pour leurs transferts UE–États-Unis, elles doivent réaliser une TIA évaluant objectivement si le destinataire américain peut assurer les protections promises par ces clauses. Pour les données traitées sur les principaux hyperscalers américains (AWS, Azure, Google Cloud), la conclusion est délicate : le droit américain de la surveillance peut contraindre le fournisseur cloud à communiquer les données et, en tant que détenteur des clés de chiffrement dans une configuration KMS cloud standard, celui-ci en a techniquement la capacité.",[188,234,235],{},"Le BYOK comble précisément cette lacune. Si les clés de chiffrement sont conservées hors du contrôle de l’hyperscaler — dans un HSM exploité par une entité européenne, avec des accès gouvernés par le client européen — l’hyperscaler ne peut fournir aucune donnée exploitable, même s’il y est contraint. Il ne peut produire que du texte chiffré. La protection est alors réelle et technique, et non simplement contractuelle.",[188,237,238],{},"Trois conditions doivent être réunies pour que le BYOK constitue une mesure complémentaire efficace au regard de Schrems II :",[188,240,241],{},"La génération des clés doit avoir lieu hors de l’hyperscaler. Les clés générées dans AWS KMS ou Azure Key Vault se trouvent, par définition, dans son périmètre de confiance. Un BYOK défendable exige que les clés soient générées dans un HSM que l’hyperscaler n’exploite pas et auquel il n’a pas accès.",[188,243,244],{},"Le stockage et la gouvernance des clés doivent être isolés sur le plan juridictionnel. L’entité qui contrôle le HSM et le cycle de vie des clés doit être une personne morale européenne soumise au droit européen, sans société mère américaine susceptible d’être contrainte en vertu du droit américain. Cette exigence est aussi bien juridique que technique.",[188,246,247],{},"Les accès aux clés doivent être journalisés et contrôlés par le client. Pour qu’une TIA puisse établir que tout accès par le fournisseur cloud est empêché, une piste d’audit doit démontrer que chaque utilisation d’une clé est autorisée par le client, et non par le fournisseur cloud. La révocation des accès — c’est-à-dire la capacité à suspendre ou supprimer l’accès à une clé et à rendre les données inaccessibles — doit réellement relever du contrôle du client.",[188,249,250],{},"La gestion des clés native standard des hyperscalers ne satisfait pas à ces exigences. Une infrastructure externe de gestion des clés est nécessaire.",[183,252,254],{"id":253},"_4-architecture-dintégration-aux-kms-cloud","4. Architecture d’intégration aux KMS cloud",[188,256,257],{},"Les principaux hyperscalers ont chacun développé des interfaces d’intégration pour les clés gérées en externe, précisément pour répondre à ce besoin du marché :",[188,259,260],{},"AWS KMS External Key Store (XKS) permet à AWS d’utiliser, pour les opérations KMS, des clés de chiffrement provenant d’un gestionnaire de clés externe. Celui-ci exécute les opérations cryptographiques sans jamais exporter le matériel de clé vers AWS. AWS KMS lui envoie des requêtes de wrap/unwrap ; le gestionnaire les exécute et renvoie le résultat. La clé ne quitte jamais le HSM.",[188,262,263],{},"Azure Key Vault Managed HSM BYOK permet aux clients d’importer dans Azure Key Vault Managed HSM du matériel de clé généré dans leur propre HSM, au moyen d’un protocole d’échange qui protège ce matériel pendant le transit. Pour les cas d’usage Schrems II les plus exigeants, l’architecture privilégiée conserve le matériel de clé dans un HSM contrôlé par le client et utilise les mécanismes de clés externes d’Azure plutôt que de l’importer dans une infrastructure contrôlée par Azure.",[188,265,266],{},"Google Cloud KMS External Key Manager (EKM) s’intègre à un service externe de gestion des clés par l’intermédiaire d’une API REST. GCP envoie les demandes d’accès aux clés au KMS externe, qui les autorise ou les refuse selon une politique définie par le client, puis exécute localement l’opération cryptographique.",[188,268,269],{},"Dans chaque cas, le modèle d’intégration est identique : l’hyperscaler demande au gestionnaire de clés externe d’exécuter les opérations cryptographiques au lieu de les réaliser avec des clés qu’il contrôle. Le fournisseur cloud n’a jamais accès au matériel de clé en clair.",[183,271,273],{"id":272},"_5-caractéristiques-dune-architecture-conforme","5. Caractéristiques d’une architecture conforme",[188,275,276],{},"Pour une plateforme d’essais cliniques traitant des données de patients de l’EEE sur des hyperscalers américains, une architecture défendable au regard de Schrems II présente les caractéristiques suivantes :",[188,278,279],{},"Les données de patients au repos sont chiffrées à l’aide de clés gérées par un KMS externe auquel le fournisseur cloud ne peut pas accéder. Ce KMS externe est exploité par une personne morale européenne, sur une infrastructure européenne et sous juridiction européenne.",[188,281,282],{},"Les opérations sur les clés — génération, rotation, suspension et révocation — sont exécutées par l’équipe sécurité de la plateforme ou déléguées à un fournisseur de services managés dans le cadre d’un accord de traitement des données conforme aux exigences de l’article 28 du RGPD.",[188,284,285],{},"Chaque accès à une clé est journalisé avec suffisamment de détails pour déterminer qui a accédé à quelles données, à quel moment et au moyen de quelle clé. Les journaux sont exportables et disponibles pour les contrôles réglementaires.",[188,287,288],{},"La révocation des accès est testée en conditions opérationnelles et documentée. La plateforme peut démontrer que la suspension d’une clé rend les données associées inaccessibles dans le délai défini par le SLA et que cette capacité a été effectivement éprouvée.",[188,290,291],{},"La TIA s’appuie sur l’architecture technique, en particulier sur la séparation juridictionnelle entre la gestion des clés et le traitement cloud, comme principal fondement permettant de conclure que le transfert est défendable.",[188,293,294],{},"Cette architecture ne supprime pas la nécessité des SCC ni d’une TIA. Elle rend la TIA défendable.",[183,296,298],{"id":297},"_6-comment-alcazarix-prend-en-charge-un-byok-conforme-à-schrems-ii","6. Comment Alcazarix prend en charge un BYOK conforme à Schrems II",[188,300,301],{},"Alcazarix fournit un service BYOK managé spécifiquement conçu pour les cas d’usage liés à Schrems II. Notre infrastructure de gestion des clés s’appuie sur Alcazarix Canada pour les charges de travail nord-américaines et Alcazarix Germany pour les charges de travail européennes, dans des datacenters dédiés et sous l’exploitation d’entités juridiques distinctes aux frontières juridictionnelles clairement définies.",[188,303,304],{},"Nous nous intégrons nativement à AWS KMS XKS, Azure Key Vault Managed HSM BYOK et Google Cloud KMS EKM. Les plateformes d’essais cliniques peuvent ainsi déployer le BYOK avec leur KMS cloud existant sans modifier la couche applicative. Les clés sont générées dans des HSM sous le contrôle d’Alcazarix, avec des politiques d’accès et de gouvernance définies par le client, une gestion complète du cycle de vie et des journaux d’audit exportables.",[188,306,307],{},"Pour les fournisseurs SaaS eClinical, nous prenons en charge des architectures multitenant dans lesquelles chaque promoteur d’essai peut détenir ses propres clés. L’isolation entre les jeux de données des promoteurs est ainsi maintenue au niveau de la gestion des clés, conformément aux attentes de l’ICH E6(R3) GCP en matière de contrôle des données par le promoteur.",[188,309,310],{},"Alcazarix a délibérément choisi de ne pas être certifié FIPS. Nous nous concentrons sur les contrôles essentiels pour Schrems II : maîtrise des clés, isolation juridictionnelle, gouvernance des accès et auditabilité. Cette approche permet de maintenir des coûts nettement inférieurs à ceux des fournisseurs HSM historiques tels que Thales ou Utimaco, sans compromettre les protections techniques qui rendent une TIA défendable.",[183,312,314],{"id":313},"_7-conclusion","7. Conclusion",[188,316,317],{},"Schrems II n’est pas une simple case à cocher en matière de conformité : il impose une évolution durable de l’architecture des transferts de données entre l’UE et les États-Unis. Pour les plateformes d’essais cliniques, qui traitent des données extrêmement sensibles dans un contexte réglementaire exigeant, l’approche SCC + TIA nécessite de véritables mesures techniques complémentaires. Le BYOK, mis en œuvre au moyen d’une gestion externe des clés adossée à des HSM et placée sous contrôle juridictionnel européen, est le moyen le plus direct de concrétiser ces mesures.",[188,319,320],{},"Pour les architectes sécurité qui évaluent la posture Schrems II de leur plateforme, la question essentielle n’est pas de savoir si des SCC sont en place — elles le sont dans la plupart des cas. Il s’agit de déterminer si leur TIA résisterait à l’examen d’une autorité européenne de protection des données. Si vos clés de chiffrement résident dans AWS KMS ou Azure Key Vault et sont gérées par le fournisseur cloud, la réponse objective est probablement négative.",[188,322,323,324,328],{},"Pour en savoir plus sur la manière dont Alcazarix accompagne les plateformes d’essais cliniques avec un BYOK conforme à Schrems II, contactez-nous à ",[325,326,55],"a",{"href":327},"mailto:hello@alcazarix.com"," ou consultez alcazarix.com.",{"title":5,"searchDepth":10,"depth":10,"links":330},[331,332,333,334,335,336,337,338],{"id":185,"depth":10,"text":186},{"id":196,"depth":10,"text":197},{"id":212,"depth":10,"text":213},{"id":228,"depth":10,"text":229},{"id":253,"depth":10,"text":254},{"id":272,"depth":10,"text":273},{"id":297,"depth":10,"text":298},{"id":313,"depth":10,"text":314},"RGPD & souveraineté des données","Comment les plateformes d’essais cliniques peuvent satisfaire aux analyses d’impact des transferts (TIA) imposées par Schrems II grâce à un BYOK adossé à des HSM et à une gestion des clés isolée sur le plan juridictionnel.",{},"/fr/livreblanc/schrems-ii-byok","/whitepapers/Alcazarix_Whitepaper_Schrems_II_BYOK_Clinical_Trials.pdf","/whitepapers/preview_Schrems_II_BYOK_Clinical_Trials.png",10,{"title":179,"description":340},"schrems-ii-byok","fr/livreblanc/schrems-ii-byok","94-inwwj70TrGXiCwk5ZHvRWX3L6X_xfeV4xqZHUkFE",{"id":351,"title":352,"body":353,"category":530,"description":531,"extension":29,"locale":67,"meta":532,"navigation":69,"path":533,"pdf":534,"preview":535,"rank":536,"seo":537,"slug":538,"stem":539,"__hash__":540},"whitepapers/fr/livreblanc/eu-ctr.md","Règlement européen sur les essais cliniques et souveraineté des données : ce que les entreprises SaaS eClinical doivent mettre en place dès maintenant",{"type":7,"value":354,"toc":520},[355,357,360,363,366,370,373,376,379,382,385,388,391,395,398,401,404,407,410,414,417,420,423,426,429,432,435,439,442,445,448,451,454,457,461,464,467,470,473,476,479,482,486,489,492,495,498,501,504,506,509,512,515],[183,356,186],{"id":185},[188,358,359],{},"Le règlement européen sur les essais cliniques (CTR, règlement 536/2014) est désormais pleinement applicable. Depuis janvier 2025, tous les essais cliniques menés dans l’Union européenne doivent être soumis et gérés au moyen du Clinical Trials Information System (CTIS), le portail centralisé de l’EMA qui a remplacé 27 procédures nationales distinctes. Pour les fournisseurs SaaS eClinical — systèmes EDC, plateformes electronic Trial Master File (eTMF), CTMS et solutions IRT/RTSM — la conformité au CTR est obligatoire et comporte une dimension d’architecture des données que nombre d’entre eux ont sous-estimée.",[188,361,362],{},"Le CTR ne prescrit aucune norme de chiffrement particulière. Il s’inscrit toutefois dans le cadre du RGPD, qui impose des mesures techniques adaptées aux risques. Les exigences de souveraineté des données intégrées au règlement — notamment l’obligation de permettre aux autorités nationales compétentes d’accéder sur demande aux données des essais — ont des conséquences directes sur la manière dont les données de patients sont stockées, chiffrées et contrôlées. Ajoutées à la tension non résolue entre les exigences du RGPD relatives aux transferts et le CLOUD Act américain, elles placent les entreprises SaaS eClinical qui s’appuient sur des hyperscalers américains face à un problème structurel : leur architecture peut être juridiquement incompatible avec les obligations d’accès aux données créées par le CTR.",[188,364,365],{},"Le chiffrement contrôlé par le client — plus précisément un BYOK avec une gestion des clés adossée à des HSM et isolée sur le plan juridictionnel — constitue la réponse architecturale à cette tension. Ce livre blanc explique pourquoi et en présente les implications pour votre plateforme.",[183,367,369],{"id":368},"_1-entrée-en-pleine-application-du-ctr-ce-qui-a-changé-en-2025","1. Entrée en pleine application du CTR : ce qui a changé en 2025",[188,371,372],{},"Le règlement (UE) no 536/2014 a remplacé la directive 2001/20/CE, cadre antérieur qui obligeait les promoteurs à suivre des procédures d’autorisation distinctes auprès de l’autorité compétente et du comité d’éthique de chaque État membre où l’essai devait être mené. Le CTR a instauré une procédure de demande unique au moyen du CTIS, avec une évaluation coordonnée entre les États membres et un calendrier d’autorisation défini.",[188,374,375],{},"Le règlement est entré en application en janvier 2022, avec une période de transition de trois ans. Depuis janvier 2025, tous les nouveaux essais doivent suivre la procédure CTIS, tandis que les essais précédemment autorisés sous l’ancienne directive ont été migrés ou clôturés.",[188,377,378],{},"Pour les entreprises SaaS eClinical, la pleine application du CTR entraîne notamment les conséquences pratiques suivantes :",[188,380,381],{},"Les données soumises au moyen du CTIS sont accessibles à toutes les autorités nationales compétentes concernées ainsi qu’à l’EMA. Il en résulte un modèle fédéré d’accès aux données, fondamentalement différent des relations bilatérales entre promoteur et autorité qui prévalaient sous la directive.",[188,383,384],{},"Les données d’essai doivent être archivées pendant au moins 25 ans après la fin de l’essai (article 58). Cette obligation de conservation s’applique au dossier complet du médicament expérimental, et non uniquement aux résultats publiés. Les plateformes eClinical qui constituent les systèmes de référence pour les données d’essai héritent de cette obligation d’archivage.",[188,386,387],{},"Les exigences de transparence et de publication prévues aux articles 37 et 38 du CTR imposent que les résultats des essais, y compris les données récapitulatives au niveau des patients, soient soumis au CTIS dans des délais définis. Ces données doivent être fournies dans des formats accessibles et lisibles par machine.",[188,389,390],{},"Aucune de ces exigences n’est purement technique. Chacune a toutefois des implications pour l’architecture des données : qui peut accéder à quelles données, dans quelles conditions et avec quelle piste d’audit.",[183,392,394],{"id":393},"_2-le-problème-de-souveraineté-des-données-posé-par-les-plateformes-cloud-américaines","2. Le problème de souveraineté des données posé par les plateformes cloud américaines",[188,396,397],{},"La plupart des entreprises SaaS eClinical, y compris de nombreuses sociétés fondées en Europe, exploitent leur infrastructure sur AWS, Azure ou Google Cloud, souvent dans des régions situées hors de l’UE. Cette situation n’est pas intrinsèquement problématique au regard du RGPD, sous réserve de mettre en place des mécanismes de transfert appropriés (SCC, TIA). L’articulation entre le CTR et le RGPD crée toutefois une tension particulière en matière de souveraineté que le seul choix d’une région cloud ne suffit pas à résoudre.",[188,399,400],{},"Le CLOUD Act américain (Clarifying Lawful Overseas Use of Data Act, 2018) permet aux autorités américaines de contraindre les fournisseurs cloud dont le siège se trouve aux États-Unis à communiquer des données stockées partout dans le monde, y compris dans des régions de l’UE. Les données d’essais cliniques hébergées dans une région européenne d’AWS, Azure ou Google Cloud sont donc potentiellement accessibles aux autorités américaines en vertu du droit américain, indépendamment des protections du RGPD.",[188,402,403],{},"Le Comité européen de la protection des données a clairement indiqué que le stockage des données dans des régions de l’UE ne résout pas cette tension lorsque le fournisseur cloud est soumis au droit américain. L’arrêt Schrems II a confirmé que l’évaluation des risques liés au transfert doit tenir compte du cadre juridique applicable à l’importateur de données, et non uniquement de la localisation physique de celles-ci.",[188,405,406],{},"Pour les fournisseurs SaaS eClinical, cela crée un risque spécifique : les promoteurs clients, responsables du traitement des données de patients au sens du RGPD, exigent de plus en plus des garanties contractuelles attestant que leurs données ne peuvent pas être consultées par des entités non européennes en vertu d’un droit non européen. Si votre plateforme ne peut pas apporter cette garantie par son architecture, vous perdez des contrats avec de grands groupes pharmaceutiques européens au profit de concurrents qui le peuvent.",[188,408,409],{},"La solution architecturale ne consiste pas à abandonner les hyperscalers, ce qui serait peu réaliste sur le plan opérationnel et peu compétitif commercialement. Elle consiste à retirer l’hyperscaler de la chaîne de gestion des clés de chiffrement.",[183,411,413],{"id":412},"_3-le-contrôle-des-clés-de-chiffrement-comme-mécanisme-de-souveraineté","3. Le contrôle des clés de chiffrement comme mécanisme de souveraineté",[188,415,416],{},"Dans une configuration KMS cloud standard, le fournisseur cloud gère les clés de chiffrement. Les données au repos dans S3, Azure Blob Storage ou Google Cloud Storage sont chiffrées, mais les clés sont détenues et gérées par ce fournisseur. Une demande formulée au titre du CLOUD Act peut donc aboutir à la communication de données en clair.",[188,418,419],{},"Dans une configuration BYOK avec des clés gérées en externe, le fournisseur cloud ne détient que du texte chiffré. Les clés de chiffrement sont conservées dans un HSM exploité hors de son infrastructure par une entité juridique non soumise au droit américain. Une demande adressée au fournisseur cloud au titre du CLOUD Act ne produit alors que du texte chiffré, impossible à déchiffrer sans la clé que celui-ci ne possède pas.",[188,421,422],{},"Cette évolution architecturale produit un effet juridique : elle retire le fournisseur cloud de la chaîne d’accès aux données. Au regard du RGPD, même si ce fournisseur est contraint de communiquer les données, celles-ci ne sont pas intelligibles et se présentent uniquement sous forme de texte chiffré. La garantie de souveraineté des données est donc technique et concrète, et non simplement contractuelle.",[188,424,425],{},"Pour les fournisseurs SaaS eClinical, la mise en œuvre du BYOK avec des clés gérées en externe répond simultanément aux besoins de trois parties prenantes :",[188,427,428],{},"Les promoteurs clients, responsables du traitement, obtiennent une garantie technique démontrable que leurs données de patients ne peuvent être consultées ni par le fournisseur cloud ni par les autorités américaines agissant auprès de celui-ci. Ils peuvent ainsi satisfaire à leurs propres obligations envers les personnes concernées au titre de leur accord de traitement des données.",[188,430,431],{},"Les autorités nationales compétentes bénéficient d’une architecture qui maintient les données d’essais cliniques sous contrôle juridictionnel européen, conformément aux attentes de souveraineté intégrées au CTR.",[188,433,434],{},"Le fournisseur eClinical peut répondre de manière défendable à la question « où se trouvent mes données et qui peut y accéder ? », de plus en plus souvent posée par les équipes achats des grands groupes pharmaceutiques avant la signature d’un contrat.",[183,436,438],{"id":437},"_4-conséquences-pour-les-fournisseurs-edc-etmf-ctms-et-irt","4. Conséquences pour les fournisseurs EDC, eTMF, CTMS et IRT",[188,440,441],{},"L’enjeu de souveraineté des données au titre du CTR varie selon les catégories de plateformes eClinical, en fonction de la sensibilité et de la portée réglementaire des données détenues par chaque système.",[188,443,444],{},"Les systèmes Electronic Data Capture (EDC) détiennent les données cliniques primaires, c’est-à-dire des données d’essai au niveau des patients relevant des catégories particulières visées à l’article 9 du RGPD. Il s’agit du niveau de sensibilité le plus élevé. Les fournisseurs EDC sont soumis aux obligations de souveraineté les plus strictes et à l’examen réglementaire le plus approfondi. Le BYOK est pratiquement indispensable pour tout fournisseur EDC ciblant les marchés réglementés de l’UE.",[188,446,447],{},"Les systèmes electronic Trial Master File (eTMF) contiennent les documents essentiels constituant le dossier réglementaire de l’essai. En vertu de l’article 58 du CTR, ce dossier doit être archivé pendant 25 ans. Cette longue durée de conservation, associée à la portée réglementaire de chaque document, rend la souveraineté des données eTMF particulièrement importante sur le plan architectural, notamment pour l’archivage à long terme.",[188,449,450],{},"Les Clinical Trial Management Systems (CTMS) contiennent des données opérationnelles et relatives aux sites, moins susceptibles d’inclure des informations permettant d’identifier les patients, mais souvent composées d’informations commercialement sensibles sur les protocoles et les sites. La souveraineté des données constitue ici un enjeu aussi bien commercial que réglementaire.",[188,452,453],{},"Les systèmes IRT/RTSM (Interactive Response Technology / Randomization and Trial Supply Management) détiennent les codes de randomisation et les affectations de traitement essentiels à l’intégrité de l’essai. Un accès non autorisé à des données de randomisation non aveugles peut compromettre la validité scientifique de l’essai. Pour les systèmes IRT, la gestion des clés revêt donc une dimension d’intégrité scientifique qui va au-delà de la seule conformité en matière de protection des données.",[188,455,456],{},"Dans chaque cas, l’exigence pratique est identique : le fournisseur eClinical doit pouvoir garantir en toute transparence au promoteur client que le fournisseur cloud ne peut pas accéder aux données en clair et que l’équipe sécurité du client peut contrôler et, si nécessaire, révoquer l’accès aux clés.",[183,458,460],{"id":459},"_5-mise-en-œuvre-du-byok-pour-les-plateformes-eclinical-considérations-darchitecture","5. Mise en œuvre du BYOK pour les plateformes eClinical : considérations d’architecture",[188,462,463],{},"La mise en œuvre du BYOK pour une plateforme SaaS eClinical implique des décisions à plusieurs niveaux de la stack.",[188,465,466],{},"Périmètre des clés. La première décision porte sur les données protégées par des clés contrôlées par le client. Pour les systèmes EDC, toutes les données de patients devraient être concernées et, au minimum, toutes celles relevant des catégories particulières visées à l’article 9 du RGPD. Pour les systèmes eTMF et CTMS, le périmètre doit être défini en fonction des exigences contractuelles du promoteur et de la politique de classification des données de la plateforme.",[188,468,469],{},"Modèle de tenancy des clés. La plupart des plateformes eClinical accueillent plusieurs promoteurs clients sur une infrastructure partagée. L’architecture de gestion des clés doit permettre leur isolation par promoteur : les données de chacun sont chiffrées au moyen de clés contrôlées exclusivement par sa propre équipe sécurité. Il s’agit d’une exigence de multitenancy au niveau du chiffrement, et pas uniquement de la couche applicative.",[188,471,472],{},"Intégration aux KMS cloud. L’intégration BYOK native à AWS KMS External Key Store (XKS), Azure Key Vault Managed HSM BYOK et Google Cloud KMS External Key Manager permet à la plateforme d’utiliser des clés contrôlées par le client pour toutes les opérations de chiffrement cloud-native — notamment le stockage, le chiffrement des bases de données et la mise en file d’attente de messages — sans modification de la couche applicative. Le KMS cloud exécute les opérations de chiffrement à l’aide de la clé externe, qui ne quitte jamais le HSM externe.",[188,474,475],{},"Gouvernance et cycle de vie des clés. Les clés contrôlées par le client nécessitent des mécanismes de gouvernance qui lui sont accessibles : rotation, suspension et révocation. Le service externe de gestion des clés doit mettre ces contrôles à la disposition de l’équipe sécurité du promoteur client sous une forme réellement exploitable, au moyen d’une API, d’une console de gestion ou d’un service managé délégué.",[188,477,478],{},"Journalisation d’audit. Chaque accès à une clé doit être journalisé avec l’identité du demandeur — le service cloud —, la clé utilisée, l’actif de données consulté lorsqu’il est identifiable et l’horodatage. Les journaux doivent être exportables à des fins de contrôle réglementaire. Au regard des exigences du CTR relatives aux pistes d’audit et des normes d’intégrité des données GCP (ICH E6(R3)), cette journalisation est obligatoire.",[188,480,481],{},"Disponibilité des clés à long terme. L’obligation d’archivage de 25 ans prévue par le CTR crée un défi de gestion des clés ignoré par la plupart des implémentations BYOK : les clés utilisées pour chiffrer les données archivées doivent rester disponibles — ou les données doivent être rechiffrées de manière sécurisée avec de nouvelles clés — pendant toute la durée de conservation. Toute architecture BYOK destinée aux plateformes eClinical doit donc prévoir la conservation des clés sur le long terme.",[183,483,485],{"id":484},"_6-comment-alcazarix-accompagne-la-souveraineté-des-données-eclinical","6. Comment Alcazarix accompagne la souveraineté des données eClinical",[188,487,488],{},"Alcazarix fournit un service BYOK managé présentant les caractéristiques architecturales et juridictionnelles nécessaires à la conformité des plateformes eClinical au CTR.",[188,490,491],{},"Notre infrastructure de gestion des clés fonctionne dans deux environnements juridictionnellement isolés : Alcazarix Canada pour les déploiements nord-américains et Alcazarix Germany pour les déploiements européens, exploités respectivement par les entités juridiques distinctes Alcazarix, Inc. et Alcazarix Europe B.V. Les données d’essais cliniques de l’UE chiffrées au moyen de clés gérées par Alcazarix Europe B.V. sont ainsi exclusivement soumises au droit européen, sans société mère américaine susceptible d’être contrainte en vertu des lois américaines de surveillance ou d’application de la loi.",[188,493,494],{},"Nous prenons nativement en charge l’isolation des clés par promoteur. Les fournisseurs SaaS eClinical peuvent ainsi mettre en œuvre une gestion multitenant dans laquelle chaque promoteur contrôle son propre espace de clés, conformément aux attentes GCP qui imposent aux promoteurs de conserver le contrôle de leurs données d’essai.",[188,496,497],{},"Nos intégrations à AWS KMS XKS, Azure Key Vault Managed HSM BYOK et Google Cloud KMS EKM couvrent les plateformes cloud sur lesquelles la majorité des solutions SaaS eClinical sont déployées, sans nécessiter de modification de leur couche applicative. Les opérations sur les clés sont exécutées par l’infrastructure Alcazarix ; les clés ne quittent jamais nos HSM en clair.",[188,499,500],{},"Pour répondre aux exigences d’archivage à long terme, nous proposons des accords de conservation des clés couvrant l’obligation de 25 ans, avec notamment des procédures documentées de rechiffrement et de transfert de conservation à long terme.",[188,502,503],{},"Alcazarix est une alternative spécifiquement conçue aux fournisseurs HSM historiques. Notre solution n’impose ni matériel HSM sur site, ni coûts liés à la certification FIPS, ni tarification fondée sur le nombre d’appliances, qui rendent Thales et Utimaco prohibitifs pour les modèles de déploiement SaaS.",[183,505,314],{"id":313},[188,507,508],{},"La pleine application du CTR européen en 2025 a fait de la souveraineté des données non plus une préoccupation future, mais une obligation immédiate pour les fournisseurs SaaS eClinical. La combinaison des exigences du RGPD relatives aux transferts, de la portée du CLOUD Act américain sur le stockage cloud dans les régions de l’UE et du modèle fédéré d’accès aux données du CTR crée un problème structurel que les seuls contrats ne peuvent résoudre. Une réponse architecturale est nécessaire.",[188,510,511],{},"Cette réponse est le chiffrement contrôlé par le client : un BYOK avec une gestion externe des clés adossée à des HSM et isolée sur le plan juridictionnel. Il retire le fournisseur cloud de la chaîne d’accès aux données, apporte une garantie technique démontrable de contrôle juridictionnel européen et permet aux fournisseurs SaaS eClinical de répondre aux questions de souveraineté des données que les grands groupes pharmaceutiques européens posent de plus en plus souvent avant de signer.",[188,513,514],{},"Il ne faut pas attendre qu’un promoteur client exige cette architecture dans un questionnaire d’achat pour la mettre en place. Il faut la concevoir dès maintenant, pendant que les programmes de conformité au CTR sont encore en cours de finalisation et qu’elle peut être intégrée dès la conception plutôt qu’ajoutée a posteriori.",[188,516,517,518,328],{},"Pour en savoir plus sur la manière dont Alcazarix accompagne la souveraineté des données eClinical, contactez-nous à ",[325,519,55],{"href":327},{"title":5,"searchDepth":10,"depth":10,"links":521},[522,523,524,525,526,527,528,529],{"id":185,"depth":10,"text":186},{"id":368,"depth":10,"text":369},{"id":393,"depth":10,"text":394},{"id":412,"depth":10,"text":413},{"id":437,"depth":10,"text":438},{"id":459,"depth":10,"text":460},{"id":484,"depth":10,"text":485},{"id":313,"depth":10,"text":314},"Règlement européen sur les essais cliniques","Comment les fournisseurs SaaS eClinical peuvent répondre aux tensions entre le CLOUD Act et la souveraineté des données imposée par le RGPD dans le cadre du CTR, grâce à une gestion des clés de chiffrement contrôlée par le client.",{},"/fr/livreblanc/eu-ctr","/whitepapers/Alcazarix_Whitepaper_EU_CTR_Data_Sovereignty_eClinical_SaaS.pdf","/whitepapers/preview_EU_CTR_Data_Sovereignty_eClinical_SaaS.png",20,{"title":352,"description":531},"eu-ctr","fr/livreblanc/eu-ctr","fFaYs4Duow4e-1YpnN2m7FMk9cK4bp_BosbafL0TOdM",{"id":542,"title":543,"body":544,"category":718,"description":719,"extension":29,"locale":67,"meta":720,"navigation":69,"path":721,"pdf":722,"preview":723,"rank":724,"seo":725,"slug":726,"stem":727,"__hash__":728},"whitepapers/fr/livreblanc/dora.md","DORA et gouvernance des clés de chiffrement : guide pratique pour les équipes sécurité des fintech européennes",{"type":7,"value":545,"toc":708},[546,548,551,554,557,561,564,567,570,573,576,579,582,585,589,592,595,598,601,604,607,611,614,617,620,623,626,630,633,636,639,642,645,648,651,655,658,661,664,667,671,674,677,680,683,686,689,692,694,697,700,703],[183,547,186],{"id":185},[188,549,550],{},"Le Digital Operational Resilience Act (DORA, règlement (UE) 2022/2554) est devenu obligatoire pour les entités financières de l’UE et leurs prestataires tiers de services ICT le 17 janvier 2025. DORA constitue la réglementation ICT la plus importante pour le secteur financier européen depuis une génération. Il regroupe et renforce considérablement les exigences de gestion des risques ICT auparavant réparties entre différents cadres sectoriels — orientations de l’EBA, de l’EIOPA et de l’ESMA — au sein d’un règlement unique, contraignant et directement applicable dans tous les États membres de l’UE.",[188,552,553],{},"La gouvernance des clés de chiffrement se situe à l’intersection de deux des cinq piliers de DORA : la gestion des risques ICT et la gestion des risques liés aux tiers ICT. La manière dont une entité financière gère ses clés — qui les contrôle, comment elles sont générées et renouvelées, ce qui se passe lorsqu’elles doivent être révoquées et quels tiers interviennent dans la chaîne d’accès — détermine directement sa capacité à satisfaire aux exigences de DORA en matière de protection des données, de résilience opérationnelle et de maîtrise des risques liés aux tiers.",[188,555,556],{},"Ce livre blanc présente les implications de DORA pour la gouvernance des clés de chiffrement des fintech européennes, les caractéristiques d’une architecture de gestion des clés conforme et les raisons pour lesquelles le BYOK managé s’impose comme la voie la plus pragmatique vers la conformité pour les entreprises de services financiers cloud-native.",[183,558,560],{"id":559},"_1-dora-champ-dapplication-structure-et-exigences-concrètes","1. DORA : champ d’application, structure et exigences concrètes",[188,562,563],{},"DORA s’applique à un large éventail d’entités financières : établissements de crédit, établissements de paiement, établissements de monnaie électronique, entreprises d’investissement, prestataires de services sur crypto-actifs, entreprises d’assurance et de nombreuses autres catégories réglementées. Il s’applique également directement aux prestataires tiers de services ICT, notamment aux fournisseurs cloud considérés comme « critiques » dans le cadre de supervision de DORA.",[188,565,566],{},"Pour les fintech, les exigences de DORA les plus importantes sur le plan opérationnel se répartissent en cinq domaines :",[188,568,569],{},"Cadre de gestion des risques ICT (chapitre II). Les entités financières doivent maintenir un cadre complet et documenté de gestion des risques ICT couvrant l’identification, la protection, la détection, la réponse et la reprise pour l’ensemble de leurs systèmes ICT. L’article 9 exige spécifiquement qu’elles mettent en place des « mécanismes et politiques appropriés » afin de protéger la disponibilité, l’authenticité, l’intégrité et la confidentialité des données, en transit comme au repos. Le chiffrement est expressément identifié comme un mécanisme de protection requis.",[188,571,572],{},"Gestion et notification des incidents ICT (chapitre III). Les entités financières doivent classifier les incidents ICT majeurs et les notifier aux autorités compétentes dans des délais stricts : notification initiale sous 4 heures, rapport intermédiaire sous 72 heures et rapport final sous un mois. Les critères de classification incluent les atteintes à la confidentialité des données ; une défaillance du chiffrement peut donc constituer un incident à notifier.",[188,574,575],{},"Tests de résilience opérationnelle numérique (chapitre IV). Les entités financières doivent réaliser des tests de résilience, notamment des tests de pénétration fondés sur la menace (TLPT) pour les entités importantes. Les contrôles cryptographiques et la gestion des clés font couramment partie des surfaces d’attaque testées.",[188,577,578],{},"Gestion des risques liés aux tiers ICT (chapitre V). Les entités financières doivent tenir un registre d’informations recensant tous les prestataires tiers de services ICT, les classer selon leur criticité et veiller à ce que les accords contractuels respectent les exigences minimales de DORA. Les fournisseurs de KMS cloud et les services externes de gestion des clés entrent dans ce périmètre.",[188,580,581],{},"Partage d’informations (chapitre VI). Les entités financières sont encouragées à partager des renseignements sur les cybermenaces. Les compromissions de clés, lorsqu’elles surviennent, constituent des informations pertinentes au regard de cette obligation.",[188,583,584],{},"Pour la gouvernance des clés de chiffrement, les articles 9 et 10 du cadre de gestion des risques ICT constituent les principaux fondements, complétés par les normes techniques de réglementation (RTS) relatives à la gestion des risques ICT publiées par les autorités européennes de surveillance.",[183,586,588],{"id":587},"_2-les-exigences-concrètes-de-dora-pour-la-gestion-des-clés-de-chiffrement","2. Les exigences concrètes de DORA pour la gestion des clés de chiffrement",[188,590,591],{},"Le texte de DORA et les RTS qui l’accompagnent précisent les contrôles cryptographiques dans plusieurs domaines directement liés aux pratiques de gestion des clés.",[188,593,594],{},"Protection des données par le chiffrement. L’article 9, paragraphe 2, de DORA impose aux entités financières de mettre en œuvre des politiques de protection des données reposant sur un chiffrement « à l’état de l’art ». Il ne s’agit pas d’une simple formalité : les autorités évalueront si la mise en œuvre du chiffrement est réellement adaptée au profil de risque des données. Pour les fintech qui traitent des données de paiement, de compte et d’identité client, « à l’état de l’art » signifie un chiffrement au repos et en transit avec des clés correctement protégées.",[188,596,597],{},"Gestion des clés comme contrôle des risques. Les orientations de l’EBA sur la gestion des risques liés aux ICT et à la sécurité — que DORA remplace et renforce pour les entités bancaires — prévoyaient des exigences explicites pour la gestion des clés cryptographiques, couvrant leur génération, leur stockage, leur distribution, leur rotation et leur destruction. Les RTS de DORA sur la gestion des risques ICT reprennent ces exigences dans un instrument réglementaire contraignant. Les entités financières doivent pouvoir démontrer l’existence de politiques documentées et de procédures opérationnelles pour chaque étape du cycle de vie des clés.",[188,599,600],{},"Résilience et reprise. DORA exige des entités financières qu’elles maintiennent des capacités de reprise comprenant des « procédures de sauvegarde et des procédures et méthodes de restauration et de rétablissement ». Pour les données chiffrées au repos, la conséquence est directe : si les clés de chiffrement sont perdues, les données sont irrécupérables. La résilience de la gestion des clés — redondance des HSM, sauvegarde des clés et séparation géographique — ne constitue donc pas seulement un contrôle de sécurité au titre de DORA, mais également une exigence de continuité d’activité.",[188,602,603],{},"Accès aux clés par un tiers comme risque de concentration. Le chapitre V de DORA consacré aux risques liés aux tiers impose aux entités financières d’évaluer le risque de concentration, c’est-à-dire la dépendance excessive à un seul prestataire tiers de services ICT. Si le fournisseur cloud d’une entité financière gère également ses clés de chiffrement, il devient un point de défaillance unique et crée un risque de concentration au niveau le plus critique de l’architecture de protection des données. En cas d’interruption du fournisseur cloud ou de rupture de la relation contractuelle, l’accès aux données et la capacité de déchiffrement sont simultanément compromis.",[188,605,606],{},"Piste d’audit et responsabilité. DORA exige que les activités de gestion des risques ICT soient documentées et auditables. Pour la gestion des clés, cela implique de conserver, pendant une durée suffisante pour les contrôles réglementaires, des journaux complets des accès aux clés, des actions administratives — rotation, suspension et révocation — et des changements d’état des clés.",[183,608,610],{"id":609},"_3-le-problème-de-concentration-des-kms-cloud-pour-les-fintech","3. Le problème de concentration des KMS cloud pour les fintech",[188,612,613],{},"L’architecture de chiffrement la plus courante pour les fintech sur le cloud public repose sur la gestion native des clés par le fournisseur cloud : AWS KMS, Azure Key Vault ou Google Cloud KMS. Ces services sont matures, bien intégrés aux services cloud-native de stockage et de calcul, et simples à exploiter. Ils créent toutefois un problème de conformité à DORA à deux niveaux.",[188,615,616],{},"Risque de concentration lié aux tiers. Lorsqu’une fintech utilise AWS KMS pour gérer ses clés, AWS fournit simultanément le calcul, le stockage et la gestion des clés. Dans le cadre de DORA relatif au risque de concentration, cela crée une dépendance à un fournisseur unique pour le stockage et le déchiffrement des données, qui constituent les couches les plus critiques de la stack ICT. Si AWS est à la fois le fournisseur cloud et, au moyen d’AWS KMS, le gestionnaire de clés, un incident affectant AWS ou une interruption du service compromet simultanément la disponibilité des données et la capacité de déchiffrement.",[188,618,619],{},"Lacunes de contrôle et de gouvernance. DORA exige des entités financières qu’elles conservent la maîtrise de leur gestion des risques ICT. Lorsque les clés de chiffrement sont gérées par le fournisseur cloud, une part importante de leur gouvernance — politiques d’accès, calendriers de rotation et journaux d’audit — relève du fournisseur plutôt que de l’entité financière. En tant qu’exploitant du KMS, le fournisseur cloud peut accéder aux clés. L’entité financière dépend donc de sa posture de sécurité pour assurer sa propre conformité en matière de protection des données.",[188,621,622],{},"Droits d’accès et de contrôle des autorités. En vertu de l’article 65 de DORA, les autorités compétentes disposent du droit d’inspecter et de contrôler les prestataires tiers de services ICT. Il appartient toutefois à l’entité financière, et non à l’autorité, de démontrer ses contrôles de gestion des clés. Lorsque cette gestion est intégrée au service propriétaire d’un fournisseur cloud, l’entité financière peut ne disposer que d’une visibilité limitée sur les contrôles opérationnels qu’elle est tenue de démontrer.",[188,624,625],{},"Ces trois problèmes appellent la même solution : soustraire la gestion des clés au contrôle du fournisseur cloud et la confier à un service distinct, gouverné de manière indépendante, sur lequel l’entité financière — ou son prestataire spécialisé de gestion managée des clés — conserve le contrôle opérationnel.",[183,627,629],{"id":628},"_4-concevoir-une-architecture-de-gestion-des-clés-conforme-à-dora","4. Concevoir une architecture de gestion des clés conforme à DORA",[188,631,632],{},"Une architecture de gestion des clés conforme à DORA pour une fintech européenne opérant sur le cloud public présente les caractéristiques suivantes :",[188,634,635],{},"La gestion des clés est structurellement séparée du calcul et du stockage cloud. Les clés utilisées pour chiffrer les données dans AWS, Azure ou Google Cloud sont gérées par un service indépendant du fournisseur cloud sur les plans organisationnel et technique. Cette séparation réduit le risque de concentration et retire le fournisseur cloud de la chaîne de gouvernance des clés.",[188,637,638],{},"Les clés sont générées dans des HSM que le fournisseur cloud ne contrôle pas. La génération de clés adossée à des HSM apporte une garantie de sécurité cryptographique que ne permet pas une gestion exclusivement logicielle. Pour les données financières hautement sensibles, l’exigence de chiffrement « à l’état de l’art » de DORA justifie l’emploi de matériel de clé protégé par HSM.",[188,640,641],{},"La gestion du cycle de vie des clés est pilotée par des politiques et auditable. La rotation, la suspension et la révocation sont exécutées conformément à des politiques documentées, et chaque action est journalisée. Le journal appartient à l’entité financière, et non au fournisseur cloud, et reste disponible pour les contrôles réglementaires.",[188,643,644],{},"La séparation géographique assure la résilience. L’infrastructure HSM doit être répartie géographiquement afin d’éviter que la défaillance d’un site n’affecte à la fois les chemins principal et secondaire d’accès aux clés. Pour les entités financières européennes, une séparation géographique au sein de l’UE répond à la fois aux exigences de résilience et aux impératifs de souveraineté des données.",[188,646,647],{},"La responsabilité de la conservation des clés est clairement attribuée. Les exigences de DORA relatives aux risques liés aux tiers imposent que la relation contractuelle avec le fournisseur de gestion des clés respecte le contenu minimal prévu par DORA, notamment les dispositions de sortie, les droits d’audit et les SLA. L’entité financière doit pouvoir mettre fin à cette relation et migrer ses clés — ou accéder aux données archivées — sans dépendance captive.",[188,649,650],{},"L’intégration aux KMS cloud préserve les opérations cloud-native. L’intégration native à AWS KMS XKS, Azure Key Vault Managed HSM BYOK et Google Cloud KMS EKM permet d’utiliser des clés gérées en externe pour toutes les opérations de chiffrement cloud-native — chiffrement des bases de données et du stockage, gestion des secrets — sans modifier les applications. Le KMS cloud exécute les opérations cryptographiques à l’aide de la clé externe, qui ne quitte jamais le HSM externe.",[183,652,654],{"id":653},"_5-la-révocation-des-clés-comme-contrôle-de-résilience-opérationnelle","5. La révocation des clés comme contrôle de résilience opérationnelle",[188,656,657],{},"L’une des implications de DORA les moins souvent évoquées en matière de gestion des clés est la valeur réglementaire de la capacité de révocation. DORA exige des entités financières qu’elles maintiennent des capacités de réponse aux incidents comprenant des mesures de confinement, afin de limiter la propagation ou les conséquences d’un incident de sécurité ICT.",[188,659,660],{},"Lors d’une violation portant sur des données chiffrées, la révocation des clés constitue le contrôle de confinement le plus puissant. Si un attaquant accède au stockage cloud, mais pas au service externe de gestion des clés, il n’obtient qu’un texte chiffré inexploitable. Si une attaque est détectée et qu’un accès au service externe de gestion des clés est suspecté, la suspension des clés — qui rend temporairement les données inaccessibles — permet de contenir l’incident sans mettre l’environnement cloud hors ligne.",[188,662,663],{},"Cette capacité diffère fondamentalement de celle offerte par les KMS cloud-native : la révocation et la suspension y sont disponibles, mais leur mise en œuvre nécessite la coopération du fournisseur cloud. Avec une gestion externe des clés, leur suspension relève entièrement du contrôle de l’entité financière ; elle ne nécessite aucune intervention du fournisseur cloud et ne peut être contournée par celui-ci.",[188,665,666],{},"Aux fins de la notification des incidents prévue par DORA, un incident de protection des données impliquant des clés gérées en externe, au cours duquel l’entité financière a pu révoquer leur accès et empêcher l’exposition de données en clair, diffère substantiellement d’un incident impliquant des clés gérées par le fournisseur cloud, où l’attaquant a accédé à des données chiffrées détenues par la même entité que les clés.",[183,668,670],{"id":669},"_6-comment-alcazarix-accompagne-la-conformité-à-dora","6. Comment Alcazarix accompagne la conformité à DORA",[188,672,673],{},"Alcazarix fournit un service BYOK managé dont l’architecture répond aux exigences de DORA les plus importantes pour la gouvernance des clés des fintech.",[188,675,676],{},"Séparation structurelle avec les fournisseurs cloud. Alcazarix exploite une infrastructure HSM dans des datacenters contrôlés par Alcazarix, situés au Canada pour les charges de travail nord-américaines, en Allemagne pour celles de l’UE et à Hong Kong pour celles de la région APAC, entièrement indépendants d’AWS, d’Azure et de Google Cloud. Les clés gérées par Alcazarix sont conservées dans les HSM Alcazarix ; le fournisseur cloud n’accède jamais au matériel de clé. Cette architecture répond directement au risque de concentration identifié par DORA.",[188,678,679],{},"Structure contractuelle alignée sur DORA. Les contrats clients d’Alcazarix sont conçus pour répondre aux exigences du chapitre V de DORA applicables aux contrats avec des tiers ICT, notamment les engagements de SLA, les droits d’audit, les dispositions de sortie et la transparence sur les sous-traitants ultérieurs. Les entités financières utilisant Alcazarix peuvent inscrire notre service dans leur registre d’informations avec la documentation requise par DORA.",[188,681,682],{},"Journaux d’audit complets des clés. Chaque demande d’accès à une clé, qu’elle provienne d’AWS KMS XKS, d’Azure Key Vault BYOK ou de Google Cloud KMS EKM, est journalisée par Alcazarix avec le service demandeur, l’identifiant de la clé et l’horodatage. Les clients peuvent exporter ces journaux par API et les transmettre à des plateformes SIEM pour une surveillance en temps réel. Ils répondent ainsi aux exigences de DORA relatives aux pistes d’audit sans avoir à développer une infrastructure de journalisation sur mesure.",[188,684,685],{},"Révocation des clés comme opération de premier plan. Alcazarix permet aux équipes sécurité des entités financières de suspendre et de révoquer directement les clés, de manière indépendante et sans intervention du fournisseur cloud. Cette capacité répond aux exigences de DORA en matière de confinement des incidents.",[188,687,688],{},"Infrastructure résiliente et géographiquement séparée. Alcazarix exploite une infrastructure HSM redondante avec des options de séparation géographique au sein de l’UE, afin de répondre aux exigences de DORA en matière de continuité d’activité et de reprise des systèmes ICT critiques.",[188,690,691],{},"Tarification transparente sans coûts liés aux appliances. La tarification d’Alcazarix est spécifiquement adaptée à l’échelle des déploiements SaaS et fintech : elle est fondée sur l’usage, sans les coûts liés au nombre d’appliances et à la maintenance des fournisseurs HSM historiques tels que Thales, Utimaco ou Fortanix. La gestion des clés conforme à DORA devient ainsi économiquement accessible aux fintech à tous les stades de leur développement.",[183,693,314],{"id":313},[188,695,696],{},"DORA a renforcé les exigences de gestion des risques ICT dans l’ensemble des services financiers de l’UE. Or la gouvernance des clés de chiffrement constitue l’un des principaux points d’exposition des architectures existantes de nombreuses fintech. La combinaison des exigences de DORA relatives à la protection des données, de son cadre sur le risque de concentration et de ses obligations de gestion des risques liés aux tiers plaide fortement, sur le plan réglementaire, en faveur d’une séparation entre la gestion des clés et l’infrastructure du fournisseur cloud.",[188,698,699],{},"Pour les architectes sécurité des fintech, l’action concrète consiste à déterminer si leur architecture actuelle de gestion des clés résisterait à un contrôle réglementaire sur trois points : pouvez-vous démontrer que votre fournisseur cloud ne peut pas accéder unilatéralement à vos données ? Pouvez-vous démontrer que vous ne dépendez pas excessivement d’un seul fournisseur ICT pour le stockage et la gestion des clés ? Pouvez-vous démontrer une capacité de révocation des clés testée, documentée et indépendante de votre fournisseur cloud ?",[188,701,702],{},"Si la réponse à l’une de ces questions est négative, le BYOK managé avec des clés externes adossées à des HSM constitue l’évolution architecturale qui permet d’y remédier.",[188,704,705,706,328],{},"Pour en savoir plus sur la manière dont Alcazarix accompagne les fintech européennes dans une gouvernance des clés de chiffrement conforme à DORA, contactez-nous à ",[325,707,55],{"href":327},{"title":5,"searchDepth":10,"depth":10,"links":709},[710,711,712,713,714,715,716,717],{"id":185,"depth":10,"text":186},{"id":559,"depth":10,"text":560},{"id":587,"depth":10,"text":588},{"id":609,"depth":10,"text":610},{"id":628,"depth":10,"text":629},{"id":653,"depth":10,"text":654},{"id":669,"depth":10,"text":670},{"id":313,"depth":10,"text":314},"Digital Operational Resilience Act (règlement sur la résilience opérationnelle numérique)","Les exigences de DORA en matière de gouvernance des clés de chiffrement, le risque de concentration créé par les KMS cloud-native et la manière dont un BYOK managé répond aux obligations de gestion des risques ICT de DORA.",{},"/fr/livreblanc/dora","/whitepapers/Alcazarix_Whitepaper_DORA_Encryption_Key_Governance_Fintech.pdf","/whitepapers/preview_DORA_Encryption_Key_Governance_Fintech.png",30,{"title":543,"description":719},"dora","fr/livreblanc/dora","1PwzEHJpeIiNtG-vSLgIW03sesKrgUBwk5XfF9gCVXE",1787677010773]