Politique de protection des données (RGPD)

Cette section a été réécrite parce que la précédente était fausse. Elle annonçait que nous ne collections pas vos documents médicaux : c'est inexact. Ils passent par notre infrastructure et leur disponibilité dépend de nous — nous ne pouvons simplement pas les lire. La distinction compte, et elle est faite ici.

Ce que nous hébergeons sans pouvoir le lire

• •Vos documents médicaux, sous forme chiffrée. Chiffrés dans votre navigateur, ils transitent par notre serveur et sont épinglés sur IPFS sous le compte de HealthGuard. Nous ne pouvons pas les lire. Nous pouvons en revanche les dépingler et en dresser la liste : c'est ce que permet le jeton de ce compte.
• •Les métadonnées de vos documents — nom de fichier, note, date clinique : elles sont chiffrées côté client avant tout envoi.
• •Votre bloc d'identité — nom, prénom, date de naissance, groupe sanguin, coordonnées, allergies, antécédents, personne de confiance. Il est chiffré sur votre appareil en un blob unique, puis inscrit sur la blockchain.
• •Les enveloppes de clés publiées pour vous ou par vous : ce sont des chiffrés, dont l'ouverture suppose une clé privée que nous n'avons pas.

Ce que nous voyons en clair

• •L'adresse de votre compte blockchain. C'est un pseudonyme, pas un anonyme : elle est permanente, publique et corrélable, et c'est une donnée personnelle au sens du RGPD.
• •Des métadonnées de connexion et des journaux techniques : date, heure, type de navigateur, erreurs.
• •La taille d'un blob chiffré, sa date de dépôt et le rythme de votre activité. Ces éléments-là, l'hébergeur les détient en clair : le travail de minimisation les réduit, il ne les supprime pas.
• •L'existence d'événements sur la chaîne — une relation de soin a été ouverte, un accès a été accordé, un accès d'urgence a été déclenché quelque part, un document a été ouvert depuis l'application par un professionnel — sous forme d'identifiants opaques, sans nom, sans catégorie et sans motif lisible.
• •Si vous utilisez le formulaire de contact : le nom, l'adresse e-mail et le message que vous y saisissez.

Nous ne prétendons pas que ces traces soient anodines. Une adresse de compte et un rythme de dépôts suffisent, dans certains contextes, à inférer beaucoup. Nous préférons les énumérer que les passer sous silence.

Ce que nous ne voyons jamais

• •Le contenu de vos fichiers.
• •Les noms de fichiers, vos notes et les dates cliniques que vous saisissez.
• •Vos clés de chiffrement, sous aucune forme, à aucun moment.

Un traitement de données de santé doit satisfaire deux exigences distinctes, et la version précédente de cette page n'en traitait qu'une.

Premier étage — la licéité générale (article 6)

• •Exécution du contrat (art. 6(1)(b)) : fournir le service que vous nous demandez — stocker, chiffrer, partager et retirer vos documents.
• •Intérêt légitime (art. 6(1)(f)) : assurer la sécurité et la disponibilité du service (journaux techniques, limitation du débit d'envoi, session authentifiée).
• •Obligation légale (art. 6(1)(c)) : pour ce que la loi nous imposerait de conserver ou de communiquer.

Nous ne déposons aucun cookie de mesure d'audience ni de publicité, et l'application n'embarque aucun traceur analytique. Le seul cookie déposé est un cookie de session strictement nécessaire au dépôt de documents, d'une durée de 12 heures. Il n'appelle donc pas de consentement à ce titre.

Second étage — la dérogation à l'interdiction (article 9)

L'article 9(1) interdit par principe le traitement des données concernant la santé. Une base de l'article 6 ne lève pas cette interdiction : il faut, en plus, une dérogation de l'article 9(2). Pour un service que la personne concernée utilise de sa propre initiative pour ses propres documents, la dérogation pertinente est en pratique le consentement explicite de l'article 9(2)(a). Les §7 et §7 bis décrivent, eux, les deux traitements effectués sans ce consentement au moment de la lecture — ils relèvent d'une autre dérogation, et c'est précisément pour cela qu'ils ont leur propre section chacun.

L'article 13.1(e) impose de vous dire à qui vos données sont communiquées. Cette page ne le faisait pas. Voici la liste, et ce que chacun voit.

• Pinata

  Service d'épinglage IPFS — notre unique hébergeur de contenu. Établi aux États-Unis.

  Ce qu'il voit : Les octets chiffrés de vos documents et de vos enveloppes de clés, leur date de dépôt, et leur taille — bornée par un bourrage, pas supprimée. Le nom de dépôt et les étiquettes sont construits par notre serveur et sont identiques pour tous les dépôts de tous les utilisateurs. Votre navigateur interrogeant directement sa passerelle pour télécharger un document, il voit aussi votre adresse IP, les identifiants de contenu demandés et l'heure de chaque demande. Il ne détient aucune clé.

• Privy

  Fournisseur d'identité et du compte de signature embarqué. Établi aux États-Unis.

  Ce qu'il voit : Votre identifiant de connexion — adresse e-mail, compte Google ou Apple, ou clé d'accès — et le compte de signature dont dérivent toutes vos clés. C'est le tiers le plus sensible du dispositif : qui peut signer à votre place peut re-dériver vos clés.

• Alchemy

  Infrastructure de compte intelligent (transactions parrainées) et nœud blockchain. Établi aux États-Unis.

  Ce qu'il voit : L'adresse de votre compte, les transactions que vous émettez et leur horodatage, ainsi que votre adresse IP. Aucun contenu médical, aucun identifiant nominatif.

• L'opérateur du RPC public de Base Sepolia (sepolia.base.org)

  Second fournisseur de nœud, utilisé pour la recherche d'historique que le premier ne peut pas servir.

  Ce qu'il voit : Les adresses des contrats HealthGuard, des identifiants opaques (relation, ressource), votre adresse IP — et, par la forme même de la requête, L'ENSEMBLE de vos identifiants de relation à chaque rafraîchissement. Il peut donc lier votre adresse IP, ce jeu de pseudonymes et vos heures de consultation. Aucune donnée de santé, aucun identifiant nominatif.

• Notre prestataire d'envoi de courrier électronique

  Uniquement si vous utilisez le formulaire de contact.

  Ce qu'il voit : Le nom, l'adresse e-mail et le message que vous y saisissez.

La version précédente de cette page affirmait n'effectuer « aucun transfert de données personnelles en clair vers des pays tiers ». Ce qualificatif n'a aucune portée en droit, et l'affirmation était trompeuse.

Il y a des transferts hors de l'Union européenne. L'adresse de votre compte est une donnée personnelle pseudonymisée — pas une donnée anonyme — et elle part chez plusieurs des destinataires du §4, dont la plupart sont établis aux États-Unis. Votre adresse IP également. Le fait que les fichiers soient chiffrés ne retire pas ces flux du champ des articles 44 à 49 du RGPD.

Ce qui ne part pas : le contenu de vos documents en clair, vos clés, et les métadonnées que vous saisissez — ils sont chiffrés sur votre appareil avant le moindre envoi.

Les métadonnées et les états écrits par HealthGuard le sont sur Base Sepolia, un réseau de test public. Ce n'est pas le réseau principal Ethereum, et la distinction n'est pas cosmétique : un réseau principal est une chaîne de production dont la permanence est l'objet même, un réseau de test ne l'est pas.

Ce qui n'y est jamais écrit : aucun contenu médical en clair, aucun diagnostic, aucun compte rendu, aucun nom de document.

Un professionnel de santé enregistré peut ouvrir un accès d'urgence sur un dossier sans l'accord préalable du patient. C'est un chemin du système où un tiers obtient un accès sans geste du patient, et donc un traitement de données de santé que nous opérons sans le consentement de la personne concernée. Il existe pour une raison précise : un patient inconscient ne peut accorder aucun accès, et un dispositif qui exigerait sa participation à cet instant ne délivrerait rien.

Ce paragraphe ne décrit qu'un des deux traitements sans consentement du système. Le second — la fiche d'urgence à deux facteurs, aux propriétés opposées — est au §7 bis.

Ce que le contrat impose

• •L'appelant doit détenir une identité professionnelle enregistrée. Ce n'est pas un contrôle de l'urgence elle-même, mais cela rend l'auteur d'un abus identifiable dans l'annuaire professionnel.
• •La durée est de 24 heures, fixée par le contrat. Ce n'est pas un paramètre : celui qui ouvre l'accès ne la choisit pas, et l'échéance survient sans que personne ait à intervenir.
• •Ouvrir la relation n'accorde aucune lecture par elle-même. Un document ne devient lisible que si une enveloppe est scellée vers la clé de ce professionnel.
• •Aucun nom n'est inscrit, et aucun motif. La chaîne ne porte que deux empreintes d'appartenance, qui ne se lisent pas mais qui se vérifient : qui soupçonne déjà une adresse précise peut refaire le calcul et confirmer son soupçon.

Ce que vous pouvez faire, et ce que nous ne pouvons pas

Un accès d'urgence ouvert apparaît sur l'écran qui liste les accès à votre dossier, quand la recherche aboutit : cette liste est reconstituée depuis l'historique de la chaîne, et l'écran vous avertit lui-même quand votre fournisseur réseau ne l'a pas remonté en entier. Vous pouvez mettre fin à un accès immédiatement, et le signaler si vous ne le reconnaissez pas.

Le détail technique de ce mécanisme est exposé au §7 de la page Sécurité & Confidentialité.

Le §7 ne décrit qu'un seul des deux traitements de données de santé que nous opérons sans votre consentement au moment de la lecture. En voici le second : la fiche d'urgence à deux facteurs, que vous pouvez sceller vous-même depuis votre espace (« Ma fiche d'urgence »). Ses propriétés sont à l'opposé de celles du §7, et doivent être dites séparément.

Vous y renseignez un résumé vital — groupe sanguin, allergies, traitements en cours, personnes à prévenir — chiffré sur votre appareil, puis scellé sous deux facteurs : un secret imprimé sur une carte que vous portez sur vous, et l'admission du lecteur dans un organisme reconnu par HealthGuard. Ni la carte seule, ni l'admission seule ne suffisent à l'ouvrir.

Ce traitement diffère du §7 sur un point qui compte : c'est vous qui scellez la fiche, à l'avance, et ce geste-là est volontaire. Ce qui reste sans votre consentement, c'est chacune de ses lectures futures — potentiellement par un compte que vous n'avez jamais choisi.

Ce qui l'oppose au §7

• •Aucune échéance. Le pack d'urgence ne porte aucun champ de validité : contrairement à l'accès par relation de soin, rien n'expire jamais.
• •Aucune révocation effective. Radier un professionnel de son organisme d'admission, ou re-sceller votre fiche avec des informations à jour, ne referme rien de ce qui a déjà été scellé pour lui : le déchiffrement se fait sur son appareil, hors de notre portée.
• •Le lecteur est identifié par une admission délivrée par un organisme (établissement, caserne, ordre professionnel), pas par l'annuaire des professionnels enregistrés dont dépend l'accès par relation de soin.
• •La donnée est scellée vers un porteur non authentifié au moment du scellement : vous ne savez pas, en scellant votre fiche, quel compte l'ouvrira.
• •Le pack chiffré (512 octets) et l'enveloppe scellée vers la clé de groupe (1 180 octets) sont publics et permanents — inscrits en storage, en calldata ou dans un event selon le chemin par lequel ils sont récupérés.

Ce que nous enregistrons, en meilleur effort

Une ligne prouve qu’un compte professionnel admis, connaissant le secret de votre carte, a publié ce reçu — pas qu’il a personnellement lu votre fiche : le déchiffrement se fait sur son appareil, rien ne peut l’y contraindre. Le nom affiché, quand il l’est, est une déclaration faite par ce professionnel à l’enregistrement de son identité, jamais vérifiée par HealthGuard. Un professionnel ayant scanné votre carte une seule fois peut publier des reçus indéfiniment sans jamais relire votre fiche : cette liste détecte, elle ne prévient rien.

Toute personne ayant scanné votre carte une seule fois peut recalculer, pour toujours, le canal sur lequel ces reçus sont publiés — même après une mise à jour de votre fiche. Seule la réimpression de la carte (un secret neuf) referme cette observation.

Comme pour vos documents, ces enregistrements sont publics, opaques et permanents : ils ne peuvent pas être effacés, même si vous demandez l’effacement de votre dossier.

Comme au §7, rien ne vérifie qu'une urgence a réellement lieu. Un abus est détectable après coup dans ce journal, il n'est jamais empêché d'avance.

Professionnels de santé : ce que l'ouverture inscrit vous concernant

Cette ouverture, elle, est inscrite dans le journal d'accès de cette personne (votre compte, la version de la fiche, un horodatage) — jamais le contenu que vous venez de lire.

Comme au §8, cet enregistrement est public, permanent, et attribuable à l'adresse de votre compte — jamais au contenu que vous venez de lire. Cette phrase est celle que l'écran d'ouverture vous affiche lui-même, à l'instant où vous ouvrez une fiche : contrairement à l'ouverture d'un document confié, dont l'article 2 de nos conditions d'utilisation vous informe séparément, cette page et l'écran lui-même sont, à ce jour, votre seule information sur ce point précis.

Le détail technique de ce mécanisme est exposé au §7 bis de la page Sécurité & Confidentialité.

L'ouverture d'un document qui vous a été confié, faite depuis l'application HealthGuard, inscrit sur la blockchain un enregistrement horodaté. Il ne porte ni votre nom, ni le titre du document, ni sa catégorie : seulement des identifiants opaques, que les clés restées sur votre appareil rattachent à une relation de soin et à un document. Vous les retrouvez dans votre espace.

Ce traitement existe pour servir un droit précis : savoir à qui vos données ont été communiquées (article 15(1)(c) du RGPD). Il établit qu'une séance d'accès a été ouverte depuis un compte professionnel — non qu'un document a été lu, ni qu'il n'en a pas été conservé de copie.

Professionnels de santé : ce que cela inscrit vous concernant

Cet enregistrement est émis depuis l'adresse de votre compte professionnel, avant tout déchiffrement, et il est public, opaque et permanent. L'information complète qui vous est due au titre de l'article 13 figure à l'article 2 de nos conditions d'utilisation — elle y est rédigée une seule fois, et nous n'en écrivons pas ici une seconde version.

Vous disposez des droits prévus par le RGPD. Cette section dit aussi, pour chacun, ce que le système peut effectivement faire — parce qu'un droit annoncé sans le geste qui le réalise est une promesse vide.

Droit d'accès (article 15)

Vous pouvez obtenir la liste des données que nous détenons à votre sujet. Vos documents et votre bloc d'identité vous sont déjà accessibles en clair depuis votre espace : ils s'ouvrent avec des clés qui se re-dérivent de votre compte et ne transitent par aucun de nos serveurs. L'écran des ouvertures (§8) sert le droit de savoir à qui vos données ont été communiquées, avec les réserves qui y sont écrites.

Droit de rectification (article 16)

Les champs de votre bloc d'identité sont modifiables depuis votre espace : la rectification re-chiffre le bloc entier et remplace la version publiée. Elle ne retire pas les versions antérieures de l'historique de la chaîne — elles y restent, chiffrées, comme tout ce qui y a été écrit.

Droit à l'effacement (article 17) — ce qui est réellement possible

C'est le point où cette page se contredisait : elle promettait « la suppression de vos données » d'un côté, et déclarait les données blockchain « permanentes » de l'autre, sans jamais réconcilier les deux. Voici la réconciliation.

Ce qui peut être retiré. Le retrait d'un document efface de la chaîne son état courant et les enveloppes de clé qui permettaient d'y accéder en interrogeant le système. Les blobs remplacés — index, pointeurs, enveloppes de clé — sont dépinglés de notre service de stockage. Et nous pouvons cesser d'alimenter : ne plus rien publier vous concernant.

Ce qui ne peut pas l'être. Une écriture sur une chaîne publique. Les données des transactions passées, qui contiennent identifiants de contenu, métadonnées et enveloppes. Les événements déjà émis, y compris les enregistrements d'ouverture du §8. Et un fichier chiffré déjà répliqué sur un réseau adressé par contenu : dépingler chez notre prestataire ne reprend aucune copie répliquée ailleurs.

Droit à la portabilité (article 20)

Vous pouvez télécharger vos documents un par un, déchiffrés, depuis votre dossier. Il n'existe pas à ce jour d'export groupé de l'ensemble de votre dossier dans un format structuré et lisible par machine. Nous ne l'annonçons donc pas comme disponible : nous l'écrirons ici le jour où il sera livré.

Retrait d'un accès, limitation, opposition (articles 7(3), 18 et 21)

Vous pouvez retirer à tout moment l'accès accordé à un professionnel, depuis l'écran « Mes partages ». Ce geste est immédiat pour la suite, et sa limite doit être dite dans les mêmes termes que dans l'application :

Comment exercer ces droits

Écrivez à contact@healthguard-project.com. Certains de ces droits s'exercent directement depuis votre espace, sans nous saisir : le téléchargement de vos documents et le retrait d'un accès en font partie.

• •Vos documents chiffrés : tant que vous les conservez dans votre dossier. Après retrait, voir le §9 — ce qui disparaît, et ce qui subsiste.
• •Votre bloc d'identité chiffré : tant que votre identité existe. Ses versions successives restent inscrites sur la chaîne.
• •Journaux techniques : 12 mois au maximum. C'est un engagement de notre part, pas une propriété du système.
• •Cookie de session : 12 heures, puis il expire. Il ne porte que l'adresse de votre compte et sa date d'expiration.
• •Données écrites sur la blockchain : permanentes. Elles ne peuvent être effacées par personne, y compris par nous — voir les §6 et §9.

• •Chiffrement AES-256-GCM dans votre navigateur, avec un vecteur d'initialisation unique à chaque opération, avant le moindre envoi réseau.
• •Vos clés ne sont jamais transmises ni stockées EN CLAIR : elles sont re-dérivées à chaque session à partir d'une signature de votre compte (HKDF-SHA256) et n'existent qu'en mémoire vive.
• •Les clés de catégorie qui vivent sur la blockchain y sont stockées DÉJÀ CHIFFRÉES sous votre clé maître. Ce qui est public, c'est l'enveloppe ; ce qui l'ouvre ne quitte jamais votre appareil.
• •Le partage d'une clé à un tiers passe par une enveloppe hybride, combinant X25519 et ML-KEM-768 : il faudrait casser les deux pour l'ouvrir.

Vous avez le droit d'introduire une réclamation auprès de la CNIL (Commission Nationale de l'Informatique et des Libertés) si vous estimez que le traitement de vos données n'est pas conforme au RGPD.

CNIL - 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07