Le consentement n’est pas une case à cocher : l’article 71 de l’EHDS en a fait une loi. Nous l’avons rendu opérationnel.

Trois règlements ont été conclus au premier trimestre 2026. Ensemble, ils se chiffrent à USD 69 millions et à quelque chose de plus conséquent : une preuve structurelle d’échec.

Kaiser Permanente s’est réglée pour USD 47,5 millions. Sutter Health s’est réglée pour USD 21,5 millions. ING Bank Śląski s’est réglée pour EUR 4,375 millions. Entre la santé et la finance, dans trois juridictions différentes. Chaque organisation avait rédigé des politiques de confidentialité. Chacune disposait d’un tableau de bord de consentement opérationnel. Les utilisateurs pouvaient se connecter, modifier leurs préférences, mettre à jour leurs dossiers. L’infrastructure de consentement était, dans le sens conventionnel, présente et opérationnelle.

Et pourtant, chaque organisation a perdu la capacité à honorer le consentement au moment où les données ont traversé une limite organisationnelle.

L’affaire Kaiser documente précisément le processus : la non-autorisation de réutilisation secondaire d’un patient a été enregistrée dans le système de gestion du consentement, reconnue par le prestataire de soins primaires, puis silencieusement rejetée lorsque le dossier s’est déplacé en aval vers un agrégateur de recherche. La non-autorisation n’a pas été annulée. Elle n’a pas été ignorée. Elle était simplement invisible pour le contrôleur en aval — architecturalement inaccessible. Le même schéma se reproduit dans les dossiers Sutter et ING. Une préférence de consentement qui existe dans un système ne peut pas être lue par un autre système qui a déjà reçu les données.

Ce n’est pas une défaillance de politique. C’est une défaillance architecturale. Et cela explique pourquoi les règlements de 2026 se présentent de cette manière.

Le piège que l’article 71(8) a créé

L’article 71 de l’EHDS est entré en vigueur le 26 mars 2025, en vertu du Règlement (UE) 2025/327. Il fait de la non-autorisation de réutilisation secondaire un droit légal, non une fonction de courtoisie. Une personne peut retirer son consentement à l’utilisation de ses données de santé à des fins de recherche, de statistiques ou de formation — à tout moment, le retrait étant contraignant pour tous les contrôleurs qui détiennent ses données.

La réponse d’ingénierie évidente est une liste centralisée : maintenir un registre des identifiants non autorisés, vérifier chaque utilisation en aval par rapport à la liste, bloquer en cas de correspondance. Rapide, vérifiable, traçable.

L’article 71(8) ferme cette porte. Il interdit explicitement les registres de réidentification — le mécanisme même qui rend une liste de non-autorisation centralisée opérationnelle. La logique derrière l’interdiction est solide : une liste d’identifiants corrélés à des décisions de non-autorisation est elle-même un ensemble de données sensibles. Son existence crée un risque de réidentification. Le règlement a été rédigé pour prévenir exactement ce risque, il ne peut donc pas permettre le chemin d’implémentation le plus évident pour honorer le droit qu’il crée.

C’est le piège. Le contrôleur ne peut pas tenir une liste de qui s’est non-autorisé sans recréer le préjudice que le règlement a été écrit pour prévenir. L’article 71 crée une obligation légale d’honorer la non-autorisation à travers les limites organisationnelles. L’article 71(8) empêche l’approche architecturale qui rendrait cela faisable pour une infrastructure centralisée. Le considérant 54 ajoute que la non-autorisation doit être réversible et librement exercitable — sans friction, sans réenregistrement, sans période d’attente.

Le règlement est précis. L’implication architecturale est radicale.

Cinq invariants. Zéro architectures qui les satisfont tous — jusqu’à présent.

Dépouilles le langage juridique et lis ce que les régulateurs exigent réellement. Parmi l’article 71 de l’EHDS, les articles 7(3) et 17(2) du RGPD, et l’article 5a d’eIDAS 2.0, cinq invariants d’ingénierie émergent :

Identifiants limités à la personne. La non-autorisation doit être attribuable à une personne spécifique, non à une session, un appareil ou un compte. L’identifiant doit survivre à travers les limites organisationnelles.

Non-autorisation horodatée vérifiable. Un contrôleur doit pouvoir prouver quand la non-autorisation a été enregistrée et qu’elle n’a pas été altérée. Les journaux auto-déclarés sont insuffisants ; les preuves cryptographiques sont requises.

Réversibilité sans réidentification. L’article 71(8) de l’EHDS le nomme explicitement. La personne peut annuler sa non-autorisation sans que l’annulation ne nécessite la création d’un enregistrement d’identité liable.

Propagation inter-contrôleurs. L’article 17(2) du RGPD exige qu’un retrait de consentement atteigne tous les processeurs en aval. L’obligation ne s’arrête pas au contrôleur qui a reçu le consentement initial.

Non-traçabilité. L’article 5a(16)(b) d’eIDAS 2.0 exige que les interactions d’identité soient non traçables à travers les contextes, de sorte que la non-autorisation ne puisse pas être exploitée pour construire un profil inter-organisationnel.

Ces cinq invariants sont nommés dans le droit primaire. Ce ne sont pas des positions interprétatives. Et ils créent un test précis pour toute architecture de consentement : satisfait-elle les cinq ?

La PKI X.509 en satisfait zéro. Une chaîne de certificats peut confirmer l’identité d’un serveur, mais elle ne fournit aucun mécanisme pour les identifiants limités à la personne qui survivent aux limites organisationnelles, aucun enregistrement de non-autorisation cryptographique indépendant des journaux propres du contrôleur, et aucune non-traçabilité — par conception, X.509 s’appuie sur le fait que l’AC sait qui vous êtes.

L’identité fédérée satisfait la propagation — quand un prestataire fédéré reçoit une non-autorisation, il peut la propager aux parties dépendantes. Mais elle satisfait la propagation uniquement en violant la non-traçabilité. Le prestataire de fédération a une vue complète de la personne qui a interagi avec quelle institution. Cette traçabilité est ce qui rend la propagation opérationnelle. C’est aussi ce que l’article 5a(16)(b) interdit.

DKMS satisfait les cinq.

Pourquoi DKMS est la réponse — et ce que cela signifie en pratique

La gestion décentralisée des clés est la première base structurellement solide pour honorer la non-autorisation de bout en bout dans des conditions multi-organisationnelles, post-divulgation, sous surveillance réglementaire. La phrase qualifiante importe. Dans les charges de travail à un seul locataire, à l’intérieur du périmètre d’une seule institution, les approches plus simples sont adéquates. Le problème structurel n’apparaît que lorsque les données ont traversé une limite — quand la personne qui exerce sa non-autorisation n’interagit plus avec le premier contrôleur.

Le mécanisme fonctionne comme suit. Chaque personne détient un identifiant auto-certifiant — un identifiant autonome, ou AID — qui sert de racine cryptographique à ses autorisations de consentement. Cet AID n’est enregistré auprès d’aucune autorité centrale. Il est auto-généré et contrôlé entièrement par la personne qui le détient. DKMS est construit sur KERI, une spécification ouverte de la Trust over IP Foundation, qui définit comment ces identifiants fonctionnent et comment les modifications à leur égard se propagent.

Aux côtés de l’AID se trouve un Journal d’événements clés — un enregistrement inviolable, chaîné cryptographiquement, de chaque autorisation et retrait. Quand une personne se non-autorise pour une utilisation secondaire, ce retrait est enregistré comme un événement clé : horodaté, signé et ajouté au journal. Tout contrôleur en aval qui détient les données de la personne peut vérifier l’état actuel de l’autorisation en lisant le journal directement — aucun registre central, aucun appel à une base de données partagée, aucune réidentification.

Quand une personne annule sa non-autorisation, cette annulation est aussi un événement clé. Le sujet entraîne la rotation. L’obligation du contrôleur est de vérifier, non de maintenir sa propre interprétation de l’état.

La propagation inter-contrôleurs découle de la structure du journal. L’institution B, qui a reçu des données de l’institution A, n’a pas besoin de recevoir une notification de l’institution A. Elle peut lire le journal elle-même. La propagation est basée sur l’extraction et prête pour l’audit.

Où DKMS ne livre pas

L’honnêteté sur la portée est ce qui rend la thèse défendable.

Les données qui ont été utilisées pour entraîner un modèle ne peuvent pas être désapprises par une rotation de clé. Un ensemble de données dérivées — un agrégat, un sous-ensemble anonymisé, un artefact statistique — ne conserve aucune connexion à l’AID de la personne originale. La non-autorisation ne peut pas atteindre ces dérivées. DKMS peut fournir une détection médico-légale du moment où les données ont été utilisées avant que la non-autorisation ne soit enregistrée ; elle ne peut pas annuler l’utilisation.

Les sauvegardes prises avant la non-autorisation sont soumises aux mêmes limites. La sauvegarde existe en dehors de la chaîne d’autorisation. La rejoindre nécessite une décision politique séparée, que DKMS peut informer mais non appliquer de manière autonome.

Un seul homologue malhonnête peut ignorer le journal. DKMS n’est pas une fonction de forçage de conformité pour les acteurs qui choisissent de violer leurs obligations légales. Ce qu’il fournit est un enregistrement vérifiable qui rend la violation visible et prouvable — ce qui est exactement ce dont les régulateurs et les tribunaux ont besoin pour assigner la responsabilité. Les règlements de 2026 ont été difficiles à résoudre précisément parce que l’état du consentement était ambigu à chaque limite organisationnelle. DKMS supprime cette ambiguïté.

Les charges de travail à un seul locataire au sein du périmètre d’une seule institution n’ont pas besoin de DKMS pour l’application du consentement. Les systèmes de gestion du consentement existants fonctionnent adéquatement quand les données ne traversent jamais une limite. L’exigence structurale apparaît à la limite.

Dire cela d’emblée n’est pas une faiblesse. C’est ce qui distingue un argument architectural d’une affirmation de produit.

En production

Le déploiement de Vereign avec Health Info Net AG en Suisse traite 800 000+ messages vérifiés par mois. Ce chiffre représente les communications traitées par SEAL — le système de livraison en essaim chiffré qui sert de canal sécurisé pour HIN vers les destinataires en dehors du réseau professionnel. C’est la preuve de production que l’architecture sous-jacente s’adapte aux charges de travail institutionnelles dans le domaine de la santé.

Stargate — l’infrastructure de confiance complète qui ajoute l’identité décentralisée, les couches d’autorisation et les pistes d’audit cryptographiques au-dessus de ce canal sécurisé — est entrée en production précoce à partir de juin 2026. Le récit de déploiement en masse sera disponible après l’été 2026 à mesure que le déploiement s’élargit.

FHIR-sur-Stargate est architectural — le déploiement en production dépend de l’intégration des hôpitaux ; le plus tôt plausible septembre 2026. L’échange de données cliniques via FHIR avec la couche d’application du consentement de Stargate intégrée est l’architecture cible pour la conformité à l’article 71 de l’EHDS. Les pièces sont en place. Le calendrier dépend de l’intégration institution par institution, non de l’ingénierie supplémentaire.

C’est l’image honnête. L’architecture est solide. La base de production existe. Le chemin de la production actuelle vers la conformité complète à l’article 71 de l’EHDS est défini et en cours.

L’examen de l’architecture de consentement

La thèse technique complète — cinq invariants, détail du mécanisme, citations réglementaires, réserves sur les limites de l’honnêteté, tableau de comparaison parmi X.509 / IAM fédérée / DKMS — est à /consent/.

Si votre organisation travaille sur la mise en œuvre de l’article 71 de l’EHDS, les obligations de propagation de l’article 17(2) du RGPD, ou les décisions d’architecture de consentement qui accompagnent l’échange de données basé sur FHIR, un examen de l’architecture de consentement de 30 minutes cartographie votre situation spécifique par rapport à ces invariants. Réservez un examen ici.