Synthèse
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.
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.
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.
1. Entrée en pleine application du CTR : ce qui a changé en 2025
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.
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.
Pour les entreprises SaaS eClinical, la pleine application du CTR entraîne notamment les conséquences pratiques suivantes :
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.
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.
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.
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.
2. Le problème de souveraineté des données posé par les plateformes cloud américaines
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.
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.
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.
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.
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.
3. Le contrôle des clés de chiffrement comme mécanisme de souveraineté
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.
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.
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.
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 :
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.
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.
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.
4. Conséquences pour les fournisseurs EDC, eTMF, CTMS et IRT
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.
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.
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.
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.
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.
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.
5. Mise en œuvre du BYOK pour les plateformes eClinical : considérations d’architecture
La mise en œuvre du BYOK pour une plateforme SaaS eClinical implique des décisions à plusieurs niveaux de la stack.
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.
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.
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.
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é.
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.
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.
6. Comment Alcazarix accompagne la souveraineté des données eClinical
Alcazarix fournit un service BYOK managé présentant les caractéristiques architecturales et juridictionnelles nécessaires à la conformité des plateformes eClinical au CTR.
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.
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.
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.
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.
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.
7. Conclusion
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.
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.
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.
Pour en savoir plus sur la manière dont Alcazarix accompagne la souveraineté des données eClinical, contactez-nous à hello@alcazarix.com ou consultez alcazarix.com.