Registre national des cancers : ce que la centralisation des données de santé impose aux responsables IT

Registre national des cancers : ce que la centralisation des données de santé impose aux responsables IT

Un médecin oncologue transmet des données sur ses patients vers une base nationale. Un hôpital connecte son système d'information à une infrastructure centralisée. Un laboratoire privé alimente un référentiel commun. Derrière ces flux apparemment anodins, une question se pose avec une acuité nouvelle pour les DSI et CTO du secteur santé : qui contrôle réellement ces données, où résident-elles, et que se passe-t-il en cas de faille ?

Ce qui s'est passé, et pourquoi maintenant

La France a franchi un cap décisif avec la montée en charge du registre national des cancers, dispositif qui vise à centraliser les données épidémiologiques et cliniques sur l'ensemble du territoire. L'objectif affiché est louable : améliorer la recherche, affiner les politiques de santé publique, réduire les inégalités de prise en charge. Le projet s'inscrit dans la continuité de la stratégie nationale de santé et de l'ambition portée par le Health Data Hub, désormais rebaptisé Plateforme des Données de Santé, après les turbulences réglementaires qui avaient marqué ses premières années d'existence.

Mais voilà : centraliser des données de santé à cette échelle, c'est aussi créer une cible. Une cible d'autant plus attractive pour des acteurs malveillants que les données oncologiques sont parmi les plus sensibles qui soient. Elles mêlent identité, antécédents familiaux, données génomiques dans certains cas, traitements suivis, pronostics. Ce sont des données que des assureurs, des employeurs peu scrupuleux, ou des États étrangers pourraient vouloir exploiter.

Pour les responsables IT des établissements de santé, des laboratoires, des cabinets de radiologie ou des éditeurs de logiciels médicaux, ce contexte crée des obligations nouvelles — et des risques que beaucoup sous-estiment encore.

La tension fondamentale entre utilité collective et maîtrise individuelle

Il faut d'abord nommer la tension clairement, sans l'esquiver. La centralisation des données de santé a une vraie valeur épidémiologique. Sans masse critique de données interconnectées, il est impossible de détecter des clusters géographiques de pathologies, d'évaluer l'efficacité comparative de protocoles thérapeutiques, ou d'anticiper des besoins en équipements. Le registre des cancers, dans sa vocation première, est un outil de santé publique sérieux.

Mais cette utilité collective se construit sur des flux de données qui traversent des systèmes hétérogènes, des réseaux que les DSI d'établissements ne maîtrisent pas de bout en bout. Et c'est là que le problème se pose en termes opérationnels.

Dans un modèle décentralisé, une faille chez un acteur reste en principe contenue. Dans un modèle centralisé, la même faille peut exposer des millions de dossiers simultanément. Ce n'est pas une hypothèse théorique : les incidents de sécurité dans le secteur de la santé se sont multipliés en Europe ces dernières années, touchant des hôpitaux en France, en Irlande, en Allemagne. Les ransomwares ont prouvé leur capacité à paralyser des systèmes critiques.

Ce que ça change concrètement pour les DSI

Première conséquence directe : l'extension du périmètre de responsabilité. Si votre établissement ou votre organisation alimente le registre national, vous devenez coresponsable de traitement au sens du RGPD. Cela ne signifie pas que vous portez seul la charge de la sécurité du registre central, mais que vous avez une obligation de diligence sur la qualité, la pseudonymisation et la sécurisation des données que vous transmettez.

Concrètement, cela se traduit par des questions très pratiques : vos flux de transmission sont-ils chiffrés de bout en bout ? Les données sont-elles pseudonymisées avant envoi, et selon quel algorithme ? Qui, dans votre organisation, a accès aux données brutes avant pseudonymisation ? Avez-vous documenté ces traitements dans votre registre RGPD ?

Deuxième conséquence : la question de l'hébergement des données en transit. Les données de santé en France doivent être hébergées chez un Hébergeur de Données de Santé certifié HDS. Cette certification existe, elle est exigeante, et elle constitue un filtre pertinent. Mais la certification HDS ne dit rien de la localisation géographique des données, ni de la juridiction applicable en cas de litige ou de réquisition étrangère.

C'est ici que la question de la souveraineté redevient concrète, non pas comme slogan marketing, mais comme risque juridique réel. Le Cloud Act américain, rappelons-le, permet théoriquement aux autorités américaines de réclamer des données hébergées par des entreprises soumises au droit américain, y compris hors du territoire américain. Si votre infrastructure de transmission repose sur un acteur soumis à cette juridiction, vous avez un angle mort dans votre analyse de risque.

Troisième conséquence, souvent négligée : la gestion des habilitations dans un contexte multi-acteurs. Qui a le droit d'accéder aux données du registre, et avec quel niveau de granularité ? Dans un système centralisé, la gestion des identités et des accès devient critique. Une erreur de configuration, un compte compromis, un prestataire externe mal encadré — et c'est un volume de données considérable qui peut être exposé.

Des questions auxquelles peu d'organisations ont répondu

Voici une série de questions que je poserais à n'importe quel DSI d'établissement de santé ou d'organisation contributrice au registre. Non pas pour faire peur, mais parce que ce sont des questions qu'un auditeur ou la CNIL pourrait vous poser demain.

Avez-vous conduit une analyse d'impact relative à la protection des données (AIPD) spécifique aux flux vers le registre national ? Ce n'est pas optionnel : pour tout traitement de données de santé à grande échelle, l'AIPD est obligatoire.

Votre DPO a-t-il été associé à la mise en place des flux de transmission ? La réponse devrait être oui, mais dans de nombreuses organisations, le DPO est informé après coup.

Vos contrats avec les sous-traitants qui participent à la chaîne de traitement incluent-ils bien les clauses de responsabilité spécifiques aux données de santé ? Un prestataire qui héberge vos données temporairement pendant leur transmission est un sous-traitant au sens du RGPD.

Enfin : avez-vous un plan de réponse à incident spécifique à ce flux ? Si demain une faille est détectée dans la chaîne de transmission vers le registre, qui appelle qui, dans quel délai, avec quelle procédure de notification à la CNIL ?

Pistes de réflexion, pas de recettes miracles

Il n'existe pas de solution parfaite à la tension entre centralisation utile et maîtrise des données. Mais il y a des approches plus robustes que d'autres.

La pseudonymisation en amont, avant toute transmission, est un principe de base mais souvent mal implémenté. Le niveau de pseudonymisation doit être documenté et revu régulièrement : certaines combinaisons de données apparemment anonymes peuvent permettre une réidentification, surtout dans le cas de pathologies rares ou de profils démographiques spécifiques.

Sur la question de l'infrastructure, des acteurs comme Atos (via ses activités santé) ou Docaposte proposent des services HDS certifiés avec une infrastructure souveraine au sens juridique du terme. Ce n'est pas une garantie absolue, mais c'est un élément de réduction du risque sur la question de la juridiction applicable. Le choix d'un hébergeur n'est pas une décision IT pure : c'est une décision juridique et stratégique.

La segmentation réseau est une autre réponse opérationnelle : les systèmes qui alimentent le registre ne devraient pas être sur le même segment réseau que le reste de votre infrastructure clinique. Cela limite la propagation en cas d'incident.

Mais au-delà des mesures techniques, ce qui fait souvent défaut, c'est la gouvernance. Dans beaucoup d'établissements, personne ne sait précisément quelles données partent vers quels registres nationaux, selon quelle fréquence, avec quelle transformation en amont. Un audit de cartographie des flux de données de santé sortants est souvent la première mesure utile, avant d'acheter quelque solution que ce soit.

Ce débat ne fait que commencer

Le registre national des cancers est un cas d'usage, mais il préfigure un mouvement de fond. L'Espace Européen des Données de Santé (EHDS), dont les textes progressent au niveau européen, va accélérer la mise en commun des données de santé à une échelle encore plus large. Les États membres auront des obligations de partage. Les organisations productrices de données — hôpitaux, laboratoires, cliniques privées — seront au cœur de ces flux.

Pour les DSI et CTO, la question n'est donc pas de savoir si cette centralisation va se produire. Elle se produit déjà, et elle va s'accélérer. La vraie question est de savoir dans quelles conditions votre organisation y participe : avec une gouvernance claire, une documentation solide, une maîtrise technique des flux — ou par défaut, en subissant des intégrations faites dans l'urgence sans analyse de risque sérieuse.

Les données de santé sont peut-être les données les plus intimes qui existent. Elles méritent mieux que des décisions d'architecture prises dans la précipitation. Et les responsables IT qui soulèvent ces questions ne sont pas des freins à la santé publique — ils sont des garants de la confiance sans laquelle aucun système de santé numérique ne peut fonctionner durablement.