Le consentement n'est pas une case à cocher.

Les cinq invariants d'ingénierie

Lisez les cinq régimes comme le ferait un ingénieur. Retirez le langage juridique et ce qui demeure est une liste de cinq invariants techniques que l'infrastructure de mise en œuvre doit satisfaire. Aucun de ces invariants n'est optionnel. Aucun ne peut être négocié par un langage contractuel raisonnable. Chacun est nommé, par clause, dans le droit primaire.

1. 01 Identifiants à portée personnelle

   L'identifiant que la personne concernée contrôle doit être la racine de confiance, et non un identifiant émis par une partie utilisatrice. L'EHDS Considérant 54 et eIDAS 2.0 Article 5a le nomment tous deux explicitement : le citoyen doit pouvoir agir sans que le responsable du traitement doive le rechercher dans un registre séparé. Toute architecture qui dépend du responsable pour générer et stocker l'identifiant échoue à ce test dès le premier jour.

2. 02 Opt-out vérifiable avec horodatage

   Le retrait doit être un événement signé cryptographiquement et horodaté que le régulateur (et un futur tribunal) peut vérifier sans se fier aux journaux du responsable du traitement. L'article 7(3) du GDPR le rend explicite : le responsable supporte la charge de la preuve. Une ligne dans une base de données interne ne constitue pas une preuve devant un forum où le responsable est le défendeur.

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

   Le Considérant 54 de l'EHDS exige que l'opt-out reste réversible — le citoyen peut se réinscrire — sans que quiconque ait besoin de ré-identifier les données sous-jacentes. Cela requiert que l'opt-out opère contre un justificatif que la personne contrôle, et non contre une table de correspondance côté serveur. Les registres de consentement centralisés échouent ici structurellement.

4. 04 Propagation inter-responsables

   L'article 17(2) du GDPR et l'EHDS Article 71 exigent tous deux que le retrait se propage à chaque destinataire en aval. En pratique, cela signifie que le responsable initial ne peut pas simplement mettre à jour sa ligne locale — chaque partie ayant jamais reçu les données doit ré-authentifier l'autorisation et constater qu'elle a été révoquée. La fédération ne peut réaliser cela qu'en partageant des identifiants, ce qui viole l'invariant suivant.

5. 05 Non-corrélation

   eIDAS 2.0 Article 5a interdit aux parties utilisatrices de corréler le même citoyen 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. Les deux invariants ensemble — propager, mais ne pas corréler — sont ce qui met fin aux architectures conventionnelles.

X.509 satisfait zéro. La fédération satisfait la propagation en violant la non-corrélation. DKMS satisfait les cinq.

Preuve de production

HIN — Health Info Net — est l'épine dorsale suisse de l'information de santé, reliant hôpitaux, cliniques et prestataires spécialisés au-delà des 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 niveau production au cœur du système de santé suisse.

Stargate, le runtime de Decentralized Key Management qui amène en exploitation le mécanisme de retrait en quatre étapes décrit ci-dessus, entre en production anticipée en juin 2026.

La couche FHIR de Stargate — les mêmes garanties appliquées à l'échange de dossiers cliniques, et non plus seulement aux messages — relève aujourd'hui de l'architecture. Sa mise en production dépend de l'onboarding côté hôpital ; la date la plus réaliste est septembre 2026.

Questions fréquentes

Que requiert l'EHDS Article 71 ?

L'EHDS Article 71 (en vigueur depuis le 26 mars 2025) donne à chaque citoyen de l'UE le droit de s'opposer à l'utilisation secondaire de ses données de santé identifiables. L'Article 71(8) interdit aux responsables de données d'acquérir des données d'identification supplémentaires dans le seul but d'honorer l'opt-out — excluant les implémentations centralisées de « liste d'identifiants ayant opté pour le retrait » car la liste elle-même est un enregistrement 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\xC2\xA0?

L'Article 71(8) l'interdit explicitement. Le registre lui-même devient un enregistrement de ré-identification — précisément ce que la réglementation visait à prévenir. La réponse structurelle requiert des identifiants contrôlés par la personne, et non une liste contrôlée par un opérateur central.

DKMS garantit-il l'application du consentement\xC2\xA0?

Non. DKMS est le premier fondement structurellement solide pour honorer le retrait du consentement de bout en bout dans des conditions inter-organisationnelles, post-divulgation, sous surveillance réglementaire. En dehors de ces conditions — charges de travail mono-tenant, dérivés comme les poids de modèles ML, sauvegardes déjà effectuées, contreparties malhonnêtes agissant seules — DKMS offre une détection forensique mais non une prévention.

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

Via des passerelles S/MIME ancrées dans KERI qui permettent au retrait de se propager auprès des parties utilisant X.509. La passerelle ancre le certificat X.509 à un AID KERI ; le retrait du consentement déclenche la rotation de clé de l'AID ; les vérificateurs X.509 en aval doivent récupérer et ré-authentifier.