Le consentement n’est pas qu’une case à cocher.

Les cinq exigences non négociables

Sans le langage juridique, les cinq régimes se résument à cinq exigences techniques que l’infrastructure doit satisfaire. Aucune n’est optionnelle, aucune ne s’écarte par contrat, chacune est nommée par clause en droit primaire.

1. 01 Identifiants rattachés à la personne

   L’identifiant que contrôle la personne concernée doit être la racine de confiance, et non un identifiant émis par une partie utilisatrice. Le considérant 54 de l’EHDS et l’article 5a d’eIDAS 2.0 le disent tous deux expressément : la personne doit pouvoir agir sans que le responsable du traitement ait à la rechercher dans un registre séparé. Toute architecture qui dépend du responsable pour créer et stocker l’identifiant échoue ici dès le premier jour.

2. 02 Opt-out vérifiable et horodaté

   Le retrait doit être un événement signé cryptographiquement et horodaté, que le régulateur (et un tribunal futur) peut vérifier sans se fier aux journaux du responsable du traitement. L’article 7(3) du RGPD le dit explicitement : la charge de la preuve incombe au responsable. Une ligne dans une base de données interne ne vaut pas preuve devant une instance où le responsable est la partie défenderesse.

3. 03 Réversibilité sans ré-identification

   Le considérant 54 de l’EHDS exige que l’opt-out reste réversible (la personne peut revenir sur son choix) sans que quiconque ait à ré-identifier les enregistrements sous-jacents. Cela suppose que l’opt-out s’exerce au moyen d’un justificatif que la personne contrôle, et non d’une table de correspondance côté serveur. Les registres de consentement centralisés échouent ici structurellement.

4. 04 Propagation entre responsables de traitement

   L’article 17(2) du RGPD et l’article 71 de l’EHDS exigent tous deux que le retrait se propage à chaque destinataire en aval. En pratique, le responsable initial ne peut pas se contenter de mettre à jour sa ligne locale : chaque partie ayant un jour reçu les données doit ré-authentifier l’autorisation et découvrir qu’elle a été révoquée. La fédération n’y parvient qu’en partageant des identifiants, ce qui viole l’exigence suivante.

5. 05 Non-chaînabilité

   L’article 5a d’eIDAS 2.0 exige que les parties utilisatrices soient incapables de corréler la même personne entre des transactions distinctes sans consentement. L’article 71(8) de l’EHDS exclut l’identifiant inter-organisationnel centralisé qui rendrait la propagation fédérée triviale. C’est la combinaison des deux exigences (propager, mais sans corréler) qui condamne les architectures conventionnelles.

X.509 n’en satisfait aucun. La fédération satisfait la propagation en violant la non-chaînabilité. DKMS satisfait les cinq.

Éprouvé en production

HIN (Health Info Net) est l’épine dorsale de l’information de santé en Suisse : elle relie hôpitaux, cliniques et prestataires spécialisés par-delà les frontières cantonales. SEAL, la couche de remise d’e-mails vérifiable que Vereign fournit au sein de HIN, est en production aujourd’hui et achemine plus de 800 000 messages vérifiés par mois : la preuve que Vereign exploite déjà une infrastructure de classe production au cœur de la santé suisse.

Verimesh (anciennement le projet Stargate), l’environnement d’exécution de gestion décentralisée des clés qui met en exploitation le mécanisme d’opt-out en quatre étapes décrit ci-dessus, est en production dans le système de santé suisse.

La couche FHIR de Verimesh (les mêmes garanties appliquées à l’échange de dossiers cliniques, et plus seulement aux messages) relève aujourd’hui de l’architecture. Sa mise en production dépend de l’intégration du côté des hôpitaux ; la date réaliste la plus proche se situe fin 2026.

Questions fréquentes

Qu’exige l’article 71 de l’EHDS ?

L’article 71 de l’EHDS (en vigueur depuis le 26 mars 2025) donne à chaque citoyenne et citoyen de l’UE le droit de s’opposer à l’usage secondaire de ses données de santé identifiables. L’article 71(8) interdit aux détenteurs de données d’acquérir des données d’identification supplémentaires dans le seul but d’honorer l’opt-out, ce qui exclut les implémentations centralisées de type « liste des identifiants en opt-out » : la liste elle-même constitue un registre de ré-identification prohibé. Le considérant 54 impose que l’opt-out soit réversible et sans condition de forme.

Pourquoi un registre de consentement centralisé ne peut-il pas fonctionner ?

L’article 71(8) l’interdit explicitement. Le registre devient lui-même un enregistrement de ré-identification : précisément ce que le règlement devait prévenir. La réponse structurelle exige des identifiants contrôlés par la personne, et non une liste tenue par un opérateur central.

DKMS garantit-il l’application du consentement ?

Non. DKMS est le premier fondement structurellement solide pour honorer l’opt-out de bout en bout dans des conditions inter-organisationnelles, post-divulgation et sous surveillance réglementaire. En dehors de ces conditions (charges de travail mono-locataire, dérivés comme les poids de modèles ML, sauvegardes déjà réalisées, contrepartie malhonnête agissant seule), DKMS offre une détection forensique, mais pas de prévention.

Comment DKMS interopère-t-il avec des contreparties X.509 / S/MIME ?

Par des ponts S/MIME ancrés dans KERI, qui permettent au retrait de se propager jusqu’aux parties qui utilisent X.509. Le pont ancre le certificat X.509 à un AID KERI ; le retrait du consentement déclenche une rotation de clés de l’AID ; les vérificateurs X.509 en aval doivent récupérer à nouveau le justificatif et le ré-authentifier.