Dit artikel is ook beschikbaar in het Nederlands.

Les données personnelles numériques constituent une source d’informations qui favorise l’innovation, le bien-être et la formulation de politiques. Ces données personnelles se trouvent dispersées dans de nombreuses organisations : l’une détient des données sur le cancer, une autre sur la consommation de médicaments et une autre encore sur les revenus. Dans la pratique, les données personnelles provenant de différentes organisations sont régulièrement regroupées afin de répondre à des questions spécifiques posées par des chercheurs et des décideurs politiques.

Les processus actuels garantissent que le respect de la vie privée dans ce contexte. Il s’agit malheureusement trop souvent d’une opération complexe, coûteuse et chronophage. En collaboration avec des universités de renommée internationale, Smals Research a donc travaillé à l’élaboration d’un prototype visant à simplifier considérablement ces processus à l’aide d’une cryptographie avancée.

Problématique basée sur un cas concret

Nous sommes partis d’une question de recherche concrète :

Les patients atteints de SEP (sclérose en plaques) sous traitement à base de molécules de tériflunomide ou d’alemtuzumab courent-ils un risque accru de cancer par rapport aux patients atteints de SEP traités avec d’autres médicaments ?

Pour répondre à cette question, simple en soi, il est nécessaire de croiser les données médicales relatives aux patients atteints de SEP provenant de deux organisations, à savoir le Registre belge du cancer (BCR) et l’Agence InterMutualiste (AIM).

Les deux organisations gèrent les données sous des pseudonymes distincts pour plus de confidentialité ; des codes uniques remplacent les numéros de registre national.

• Le BCR gère les données relatives au cancer concernant les personnes qui ont reçu un diagnostic de cancer. Le BCR ne sait pas quels enregistrements concernent des patients atteints de SEP.
• L’AIM dispose de données relatives aux médicaments prescrits et peut sélectionner les enregistrements des patients atteints de SEP.

Les chercheurs doivent avoir accès, dans un environnement sécurisé (SPE = Secure Processing Environment), aux données provenant du BCR et de l’AIM concernant tous les patients atteints de SEP. Les données relatives à un même patient mais issues de sources différentes doivent pouvoir être reliées entre elles sur la base d’un pseudonyme unique utilisé uniquement dans le cadre de cette question de recherche spécifique. Ceci est représenté dans l’illustration 1.

La question centrale est la suivante :

Comment le BCR peut-il fournir uniquement des enregistrements sur les patients atteints de SEP à l’environnement sécurisé sans savoir qui est atteint de SEP ou quels enregistrements qu’il gère concernent des patients atteints de SEP ?

Dans une approche classique, soit le BCR enverra trop d’informations à l’environnement sécurisé – notamment des données sur chaque patient atteint d’un cancer –, soit des informations seront divulguées au BCR – qui découvrira alors quels enregistrements concernent des patients atteints de SEP. Une dernière possibilité consiste à faire appel à une entité centrale de confiance qui, certes, aura connaissance des données à caractère personnel, mais à qui l’on peut faire confiance pour ne pas en faire un usage illicite.

Aucune de ces approches n’est idéale. Aujourd’hui, tant au niveau national qu’international, on fait appel à des intermédiaires centraux fortement réglementés ou on opte pour des solutions sur mesure coûteuses et lentes, dans lesquelles un nouveau flux est défini, validé et mis en œuvre pour chaque question de recherche afin de protéger au maximum la vie privée.

De plus, le chercheur a généralement besoin d’accéder aux données brutes, ce qui rend les solutions basées sur le secure multi-party computation inadaptées. 

Notre proposition de solution

Partons d’un scénario fictif dans lequel nous travaillons avec un intermédiaire de confiance et où, pour simplifier, l’AIM et le BCR ne gèrent pas les données à caractère personnel sous des pseudonymes, mais sous des numéros de registre national. L’AIM et le BCR envoient tous deux toutes les données potentiellement pertinentes à l’intermédiaire de confiance.

Le BCR envoie à l’intermédiaire les données identifiées relatives au cancer de tous les citoyens qui ont reçu un diagnostic de cancer, ce qui est bien sûr beaucoup plus que ce dont le chercheur a besoin. L’intermédiaire reçoit également toutes les données identifiées relatives aux médicaments prescrits aux patients atteints de SEP de l’AIM et sait ainsi, sur cette base.

L’intermédiaire reçoit également toutes les données identifiées relatives aux médicaments prescrits aux patients atteints de SEP de l’AIM. Il sait ainsi quels enregistrements fournis par le BCR concernent des patients atteints de SEP et donc quels enregistrements sont pertinents dans le cadre de la question de recherche. L’intermédiaire entreprend alors les étapes suivantes :

1. Il supprime les enregistrements non pertinents, c’est-à-dire les enregistrements concernant tous les citoyens qui ont reçu un diagnostic de cancer mais qui ne sont pas atteints de SEP.
2. Il fusionne les enregistrements concernant les mêmes citoyens et remplace les numéros de registre national par des pseudonymes uniques dans les enregistrements fusionnés.
3. Il envoie le résultat – uniquement les enregistrements fusionnés – vers l’environnement sécurisé.
4. Il supprime toutes les données reçues et dérivées.

Dans ce scénario, il n’y a pas de fuite involontaire de données vers les sources de données et l’environnement sécurisé ne reçoit que les données personnelles pseudonymisées minimales nécessaires.

Notre prototype fait exactement cela, mais sans l’intermédiaire de confiance. Le rôle de l’intermédiaire de confiance est distribué : les détenteurs de données – dans ce cas, l’AIM et le BCR – et un collecteur de données – dans ce cas, l’environnement sécurisé – interagissent pour assumer ensemble le rôle de l’intermédiaire de confiance. Les caractéristiques de sécurité mentionnées dans le paragraphe précédent sont conservées ; aucune information n’est donc divulguée involontairement aux détenteurs de données et le collecteur de données ne prend connaissance que des données pseudonymisées strictement nécessaires. La solution reste néanmoins pratique et efficace. Tout cela est possible grâce à une cryptographie avancée.

Comme nous l’avons mentionné précédemment, l’AIM et le BCR conservent les données sous des pseudonymes. Il existe des procédures permettant de les convertir de manière contrôlée en numéros de registre national. L’entité qui gère les données n’a jamais connaissance des registres nationaux et l’entité qui peut associer les pseudonymes aux numéros de registre national n’a à aucun moment accès aux données à caractère personnel proprement dites. Par souci de simplicité et pour la suite de cet article, nous partons du principe que les détenteurs de données connaissent les données identifiées par les numéros de registre national plutôt que par les pseudonymes. Notre concept peut également s’appliquer de manière sécurisée à des situations plus réalistes où ce n’est pas le cas.

Dans la pratique

Smals Research a développé ce concept en collaboration avec des partenaires universitaires. Initialement baptisé Oblivious Join, il a été renommé LetheLink dans le contexte universitaire. Lethe (Λήθη) est, dans la mythologie grecque, la déesse de l’oubli et l’un des cinq fleuves des enfers, au bord duquel les morts s’abreuvent pour oublier leur vie terrestre. Malgré cet oubli – ou plutôt ce manque de connaissance –, les entités en interaction parviennent à relier entre elles les données nécessaires. La convivialité et l’efficacité ont été au cœur du développement de ce concept.

Smals Research a développé un prototype démontrable qui donne déjà un aperçu du fonctionnement d’une solution entreprise-ready. L’utilisation du prototype est présentée dans l’illustration 2 et comprend les étapes suivantes :

1. Création d’un fichier JSON. Une organisation pouvant servir de point de contact (par exemple, la HDA ou la BCSS) reçoit une demande d’un chercheur. Lorsque la base juridique pour ce traitement de données existe, cette organisation établit un fichier JSON signé numériquement. Ce fichier JSON contient, sous une forme structurée, toutes les informations nécessaires à l’exécution correcte du protocole pour le croisement sécurisé des données des détenteurs de données : les données de connexion des clients des détenteurs de données et du collecteur de données, les paramètres cryptographiques, les clés publiques, les informations sur les données que chaque détenteur de données doit fournir, etc. Dans la pratique, on partira de templates à partir desquels on pourra dériver des fichiers JSON avec un minimum d’effort.
2. Distribution du fichier JSON. Ce fichier JSON est envoyé à la fois au collecteur de données et aux détenteurs de données. Tous vérifient la signature numérique. Toutes les entités concernées savent désormais comment exécuter le protocole et comment contacter les autres entités concernées en toute sécurité.
3. Téléchargement du client. Si ce n’est pas déjà fait, le collecteur de données et les détenteurs de données téléchargent le client LetheLink.
4. Création de fichiers CSV. Sur la base du fichier JSON, chaque détenteur de données génère un fichier CSV contenant toutes les données identifiées potentiellement pertinentes. Dans le scénario décrit précédemment, cela inclurait, pour le BCR, toutes les informations identifiées demandées concernant tous les citoyens ayant reçu un diagnostic de cancer. La création de ce fichier ne relève pas du champ d’application de LetheLink. Notre prototype ne prend en charge que les fichiers CSV, mais cette fonctionnalité peut être étendue.
5. Importation du client. Chaque participant fournit le fichier JSON à son client LetheLink local. Les détenteurs de données fournissent également leur fichier CSV généré localement à leur client. Les données sont livrées en clair et le client se charge du chiffrement.
6. Exécution du protocole. Le protocole est exécuté. Du côté du collecteur (SPE) des données, cela donne un fichier CSV qui ne contient que les données pseudonymisées et minimales nécessaires.

L’avantage de cette approche réside dans sa flexibilité d’utilisation. Certains détenteurs de données ne sont impliqués que très occasionnellement dans de tels projets croisés et tous les détenteurs de données ne disposent pas des mêmes ressources. Grâce à l’approche LetheLink, nul besoin de réaliser d’importants investissements ou préparatifs. Il suffit d’installer le client et de créer le fichier CSV.

L’illustration 3 présente un exemple fictif de tels fichiers CSV. En haut figurent des extraits de fichiers CSV que les détenteurs de données (trois dans le cas présent) fournissent chacun en entrée à leur client LetheLink. Au bas de l’illustration, un extrait du fichier CSV généré en sortie par le client du collecteur de données à la suite de l’exécution du protocole est présenté. Dans notre exemple fictif, le chercheur s’intéresse uniquement aux données transversales, c’est-à-dire aux données relatives aux 50 000 patients atteints de SEP qui ont reçu un diagnostic de cancer et présentent un profil de risque élevé. La personne dont le numéro de registre national est 60.01.05-045.05 appartient à ce groupe. Le collecteur de données voit les informations combinées sur ce citoyen, non pas sous ce numéro de registre national, mais sous le pseudonyme “153807…”.

Performance

Dans le cadre de la collaboration académique, la performance a été considérablement améliorée au cours de plusieurs itérations, tant au niveau de l’algorithme qu’au niveau de la mise en œuvre. Les principaux résultats des tests sont présentés dans le tableau 1. Quelques précisions :

• Les tests ont été effectués sur des machines virtuelles AWS EC2 r7i.8xlarge, avec 32 vCPU (Intel Xeon Platinum 8588C @ 3,2 GHz) et 256 Go de RAM.
• Une distinction est opérée entre une exécution sur un LAN à une vitesse de 1 Gbps et sur un WAN à une vitesse de 150 Mbps.
• La variable m représente le nombre d’enregistrements fournis par chacune des sources de données. Dans nos tests, elle est comprise entre un minimum de 2¹⁶= 65.536 et maximum de 2²⁴= 16.777.216. En réalité, le nombre d’enregistrements varie bien sûr selon la source de données, mais ces résultats fournissent déjà une limite supérieure.
• La variable κ (kappa) représente le niveau de sécurité computationnel. Une sécurité de 128 bits est suffisante aujourd’hui, mais une sécurité de 192 ou même de 256 bits est recommandée pour les données qui restent sensibles pendant une longue période. La variable λ (lambda) représente le paramètre de sécurité statique correspondant. 
• La variable n représente le nombre de détenteurs de données. Nous avons effectué des tests avec 3, 5 et 7 détenteurs de données, mais il n’y a aucune limitation technique pour un nombre beaucoup plus important.

Maintenant que nous savons comment interpréter ce tableau, nous constatons par exemple qu’il faut 25 secondes pour exécuter le protocole lorsque trois sources de données fournissent chacune 1 million (2²⁰) d’enregistrements sur un WAN. La quantité de données fournies a également un impact sur le temps d’exécution, mais pour cela, nous vous renvoyons au tableau 3 de notre publication commune. En résumé, tant le protocole que sa mise en œuvre sont particulièrement efficaces. Pour conclure, l’illustration 4 donne une idée générale de la réalisation des tests.

Relation avec le service de pseudonymisation à l’aveugle d’eHealth

Smals Research a développé le service de pseudonymisation à l’aveugle pour eHealth au cours de la période 2021-2022. Ce service permet de convertir les numéros de registre national en pseudonymes (codes uniques) et vice versa. Cette conversion est effectuée par un service de pseudonymisation qui est toutefois aveugle : il ne voit ni les numéros de registre national ni les pseudonymes. Ce service peut également être utilisé pour pseudonymiser et croiser des données. Quelles sont les différences ?

• Statut. Le service de pseudonymisation à l’aveugle est déjà en production, tandis que LetheLink n’est qu’un prototype.
• Fuite de données. Pour les projets de recoupement plus complexes, tels que ceux évoqués dans cet article, le service de pseudonymisation à l’aveugle ne pourra pas toujours empêcher les fuites de données. Il y aura notamment des fuites de données lorsqu’une source de données ne peut pas déterminer de manière autonome quels enregistrements sont pertinents pour répondre à la question de recherche. Selon le use case, il peut s’agir d’une fuite de données résiduelle acceptable ou de fuites de données plus substantielles, qui portent effectivement atteinte à la vie privée des personnes concernées. D’autre part, LetheLink présente des risques lorsqu’une seule entité est à la fois détentrice et collectrice de données.
• Rapidité. Le service de pseudonymisation à l’aveugle d’eHealth est certes très rapide – il peut effectuer des milliers de conversions par seconde -, mais LetheLink est ultra-rapide – il effectue des dizaines de milliers de conversions par seconde et, dans certaines circonstances, peut dépasser les cent mille. Tout dépendra bien sûr de l’infrastructure utilisée.
• Infrastructure. Le service de pseudonymisation à l’aveugle d’eHealth est dans tous les cas une entité centrale qui doit disposer d’une capacité suffisante. LetheLink, en revanche, est distribué, ce qui rend inutile une telle entité centrale : il suffit que chaque entité exécute le client LetheLink sur ses machines existantes. Il peut même s’agir d’ordinateurs portables classiques.
• Intégration. Afin d’utiliser le service de pseudonymisation à l’aveugle, une organisation doit intégrer une logique dans son application client. Nous savons par expérience que cela est relativement simple, mais cela reste néanmoins un investissement. LetheLink est un client autonome et ne nécessite donc aucun processus d’intégration.
• Types de demandes. Le service de pseudonymisation à l’aveugle d’eHealth peut traiter tant les demandes en batch que les demandes qui doivent être traitées en temps réel. LetheLink ne prend en charge que les traitements en batch.

Ce positionnement respectif de LetheLink et du service de pseudonymisation à l’aveugle d’eHealth devrait aider les organisations à déterminer la technologie la plus adaptée à leurs use cases.

Extensions

Un certain nombre d’extensions de LetheLink seront nécessaires pour pouvoir l’utiliser dans la pratique. Toutes les extensions proposées sont déjà conceptuellement possibles, mais ne sont pas toujours intégrées dans le prototype. Cela ne se fera que si une demande concrète est formulée.

• Taille minimale de l’ensemble de résultats. Si l’ensemble de résultats pseudonymisés pour le collecteur de données ne contient pas suffisamment d’enregistrements, il existe un risque pour la vie privée des personnes concernées et il est impossible de mener des recherches statistiquement pertinentes. C’est pourquoi le prototype prend déjà en charge la possibilité d’indiquer une taille minimale dans le fichier JSON.
• Réidentification contrôlée. Si les chercheurs constatent qu’un citoyen donné présente un risque élevé de développer une certaine maladie, il doit être possible d’en informer ce citoyen. De même, lorsqu’une enquête sur une fraude révèle une forte suspicion de fraude de la part de certains citoyens, il doit être possible d’en informer l’autorité compétente. Il doit donc être possible, dans des situations exceptionnelles, de vérifier l’identité d’un citoyen de manière contrôlée.
• Pseudonymes des détenteurs de données. Comme indiqué précédemment dans cet article, les détenteurs de données n’ont souvent pas eux-mêmes accès au numéro de registre national des citoyens dont ils gèrent les données. Dans de tels cas également, le protocole doit pouvoir être mis en œuvre efficacement.
• Divulgation sélective. Actuellement, le prototype se concentre sur des moyennes ; ce n’est que si tous les détenteurs de données fournissent des enregistrements sur un même citoyen que l’enregistrement composite devient visible pour le collecteur de données. Dans la pratique, une plus grande flexibilité est requise, comme l’indique l’illustration 5. Dans le cas d’utilisation présenté en introduction de cet article, le chercheur avait besoin de données pseudonymisées sur tous les patients atteints de SEP, alors que notre prototype ne fournit actuellement que des données pseudonymisées sur tous les patients atteints de SEP ayant également reçu un diagnostic de cancer.
• Transfert multi-batch. Dans certains cas, les détenteurs de données doivent fournir des données à plusieurs reprises au collecteur de données, par exemple dans le cadre d’une étude longitudinale. Le collecteur de données doit être capable de relier entre elles les données relatives à un même citoyen au fil du temps.
• Communication simplifiée. Dans le prototype, tous les détenteurs de données concernés communiquent entre eux, puis envoient individuellement des données cryptées au collecteur de données. Dans un protocole adapté, les détenteurs de données n’échangeraient des données qu’avec et via le collecteur de données, par exemple via une interface REST. Dans la pratique, cette approche est plus souhaitable.

Veuillez nous faire part de toute autre extension utile que vous pourriez envisager.

Références

Le concept initial ainsi que le prototype et les tests de performance ont été réalisés par Smals Research. Les partenaires universitaires, notamment le groupe COSIC et le groupe DistriNet de la KU Leuven, ainsi que le groupe CrySP de l’université de Waterloo au Canada, se sont concentrés sur l’élaboration théorique. Cela a donné lieu à deux publications en 2025 :

• Publication de Springer :Privacy-By-Design in the Belgian Public Sector Ce document accessible traite de deux solutions innovantes conçues par Smals Research pour la pseudonymisation et le croisement des données à caractère personnel : Lethelink et le service de pseudonymisation à l’aveugle d’eHealth.
• Publication de Springer :Privacy-By-Design in the Belgian Public Sector Ce document accessible traite de deux solutions innovantes conçues par Smals Research pour la pseudonymisation et le croisement des données à caractère personnel : Lethelink et le service de pseudonymisation à l’aveugle d’eHealth.

Je vous invite également à consulter ma contribution à la conférence Devoxx et mon webinaire de 2024 intitulé “Privacy in Practice with Smart Pseudonymisation”. LetheLink/Oblivious Join est l’une des trois techniques de pseudonymisation que j’y aborde.

Enfin, des slides sont disponibles pour ceux qui souhaitent se faire rapidement une idée intuitive des principes de base de l’Oblivious Join. Les notes correspondantes fournissent des explications supplémentaires.

Conclusion

L’utilisation secondaire des données à caractère personnel peut nous fournir de nombreuses informations qui soutiennent l’élaboration des politiques et stimulent la recherche scientifique. Pour exploiter ces informations, les données provenant de différentes sources doivent pouvoir être collectées de manière efficace, dans le respect de la vie privée. Cela signifie que seules les données à caractère personnel nécessaires sont pseudonymisées et croisées et que les autres entités participant à ce processus n’ont pas accès aux données à caractère personnel. Dans la pratique, cela était loin d’être évident.

En collaboration avec des universités de renommée internationale, Smals Research a donc élaboré un concept qui, grâce à une cryptographie avancée, permet de le faire de manière efficace. Un prototype démontrable a également été construit, ce qui constitue une première étape vers une mise en œuvre effective dans la pratique.

Au cours des dernières années, nous avons rencontré de nombreuses entités. Tout le monde considère qu’il s’agit d’un outil très utile, mais nous ne disposons pour l’instant pas de l’engagement de nos partenaires pour le mettre en pratique.

Le défi principal aujourd’hui est donc de rendre cette solution prête à la production. N’hésitez pas à nous contacter si cette solution vous intéresse et si vous souhaitez éventuellement y contribuer.