Sécurité & Confidentialité

Un document déposé dans HealthGuard est chiffré dans votre navigateur, avant le moindre envoi réseau. Ce qui quitte votre appareil est du chiffré : ni le serveur, ni l'hébergeur, ni un observateur du réseau ne voit le fichier d'origine.

Les octets chiffrés sont ensuite épinglés sur IPFS, un réseau de stockage décentralisé, via le service de pin Pinata. C'est aujourd'hui notre seul hébergeur de contenu — et il ne détient aucune clé.

Ce que le service de stockage reçoit

Volontairement : le strict minimum, et rien qui permette de vous profiler. Les octets partent bruts, et le nom de dépôt comme les étiquettes envoyées au service de pin sont construits par notre serveur, identiques pour tous les dépôts de tous les utilisateurs. Un nom de fichier comme « ordonnance-cardiologie » dirait la nature des soins sans qu'aucun chiffrement soit cassé : le client n'a donc aucun champ où l'écrire.

Ce que la blockchain porte

Aucun contenu médical n'est écrit sur la blockchain : ni diagnostic, ni compte rendu, ni nom de document. La chaîne ne porte que des identifiants opaques, des états (une relation est active, un accès est accordé), et des références vers des blobs chiffrés. Les métadonnées d'un document — nom de fichier, note, date clinique — sont elles-mêmes chiffrées côté client avant d'être stockées.

Votre clé maître et vos clés privées : personne d'autre que vous, jamais. Ce n'est pas une promesse contractuelle, c'est une conséquence de la façon dont elles sont fabriquées.

Les clés que vous partagez obéissent à une autre règle, et il faut la dire ici plutôt que de la laisser découvrir : une clé de catégorie transmise à un professionnel est détenue par lui, et le reste. Ce qu'il en fait ne dépend plus de vous. C'est l'objet du §6.

Vos clés ne sont pas stockées : elles sont re-dérivées à chaque session, à partir d'une signature de votre compte, par une fonction de dérivation (HKDF-SHA256). Elles n'existent qu'en mémoire vive, le temps de votre session.

Il n'existe chez nous aucun coffre de clés — donc rien à voler, rien à saisir, rien à perdre lors d'une intrusion sur nos serveurs. La contrepartie honnête est au §10 : tout dérive d'une signature de votre compte, et ce compte est tenu par votre fournisseur d'identité.

Trois niveaux, pas un seul

• •Une clé maître, propre à votre compte, jamais stockée.
• •Sept clés de catégorie, une par type de document, chacune dérivée de la clé maître.
• •Une clé unique par document, chiffrée sous la clé de sa catégorie.

Cette séparation n'est pas décorative : c'est elle qui permet de partager une catégorie sans ouvrir les six autres, et de renouveler la clé d'une catégorie sans toucher au reste du dossier.

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.

Les fichiers

AES-256-GCM, avec un vecteur d'initialisation unique à chaque opération de chiffrement. Le mode GCM authentifie ce qu'il chiffre : un fichier chiffré modifié en transit ou en stockage ne se déchiffre pas du tout — il n'existe pas de version « abîmée mais lisible ».

S'y ajoute une empreinte SHA-256 du fichier d'origine, scellée avec le document et recalculée à chaque ouverture. Elle couvre ce que le tag GCM ne couvre pas — un contenu correctement chiffré mais qui n'est pas celui déposé. Nous la présentons pour ce qu'elle est : un avertissement affiché à côté du document. Elle vous informe d'une discordance, elle ne vous empêche pas d'ouvrir ni d'enregistrer le fichier.

Le partage entre deux personnes

Une clé n'est jamais transmise en clair. Elle est scellée dans une enveloppe asymétrique hybride — l'échange de clés combine X25519 et ML-KEM-768 (NIST FIPS 203), de sorte qu'il faudrait casser les deux pour l'ouvrir — destinée à la clé publique du destinataire, et lui seul peut l'ouvrir, avec une clé privée qu'il re-dérive lui aussi de son propre compte. Le serveur transporte l'enveloppe ; il ne peut pas l'ouvrir.

Les identifiants sont opaques

Un point qu'un lecteur technique cherchera : les identifiants de catégorie écrits sur la chaîne sont dérivés de votre clé maître. Deux utilisateurs produisent donc des identifiants différents pour la même catégorie, et un observateur ne peut ni retrouver de quelle catégorie il s'agit, ni relier deux comptes par ces identifiants. Ils sont en outre écrits dans un ordre tiré au hasard à chaque écriture, précisément pour qu'une position dans une liste ne trahisse pas une catégorie.

Cette opacité vaut face à un tiers. Une personne à qui vous avez déjà partagé cette catégorie sait à quoi cet identifiant correspond — et le saura encore après une révocation.

Le détail de la migration post-quantique de ces couches fait l'objet de la section suivante.

La question honnête n'est pas « voyons-nous vos données ? » mais « que voyons-nous quand même ? ». Voici les deux listes.

Ce que nous ne voyons jamais

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

Ce que nous — ou n'importe quel observateur de la chaîne — voyons

• •Votre adresse de 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.
• •L'existence d'événements : 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.
• •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.
• •Des métadonnées de connexion et des journaux techniques (date, heure, type de navigateur, erreurs).

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

Un partage s'accorde professionnel par professionnel et catégorie par catégorie, avec, si vous le souhaitez, une date de fin pour ce soignant. La maille du partage est donc la catégorie de documents, pas le document isolé : vos ordonnances sans votre imagerie, si c'est ce que vous voulez. La date de fin, elle, vaut pour la personne — elle couvre tout ce que vous lui avez ouvert.

Les sept catégories

• •Ordonnances
• •Comptes rendus d'examen
• •Résultats biologiques
• •Imagerie médicale
• •Certificats
• •Documents administratifs
• •Autres

La révocation

Elle se fait à la même maille, et elle est immédiate : elle ferme tout nouveau partage.

Une date de fin ne fait pas le même travail, et nous préférons le dire : elle clôt la relation à sa date, mais elle ne retire pas d'elle-même les clés déjà publiées pour ce professionnel. Pour cela, il faut le geste de révocation — depuis l'écran « Mes partages ».

Le cas d'un document rédigé par un professionnel

Quand un professionnel produit un document pour vous, il en conserve sa propre copie et la clé qui l'ouvre : retirer votre copie ne les lui reprend pas, et renouveler vos clés de catégorie n'y change rien — cette clé-là n'en dépend pas. Le produit propose donc d'intégrer ce document à votre dossier : votre copie est alors re-chiffrée sous une clé tirée sur votre appareil, qui n'en sort jamais. Après ce geste, l'auteur ne peut plus ouvrir votre copie. Il garde la sienne, et le contenu qu'il a rédigé.

C'est une exception au principe de consentement, et nous la décrivons ici parce qu'une page de sécurité qui cache sa propre exception ne vaut rien.

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. 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.

Cette section 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 §8.

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. Ce que la chaîne porte, ce sont deux empreintes d'appartenance — le résultat d'un calcul à sens unique sur l'adresse de chaque partie. Elles ne se lisent pas, mais elles se VÉRIFIENT : qui soupçonne déjà une adresse précise peut refaire le calcul et confirmer son soupçon. C'est une protection contre la lecture en masse du graphe de soin, pas contre un observateur qui a déjà un nom en tête — d'autant que l'ouverture est réservée aux professionnels enregistrés, un ensemble restreint et énumérable.

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.

La section précédente 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.

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 nos conditions d'utilisation, article 2, vous informent séparément, hors de l'interface — cette page-ci et l'écran lui-même sont, à ce jour, votre seule information sur ce point précis.

Retirer un document de votre dossier révoque son accès et le fait disparaître de votre coffre. Ce geste ne supprime pas les octets chiffrés déjà déposés sur IPFS : sur un réseau décentralisé, personne ne peut garantir la disparition d'une copie déjà répliquée. Nous ne l'écrirons donc pas.

Ce qui protège la donnée entre-temps est qu'elle n'est que du chiffré. Le geste qui s'en approche le plus est le retrait d'un document : la clé propre à ce document est tirée au hasard, et les enveloppes qui la contiennent — la seule façon d'y accéder en interrogeant le système — sont effacées de la chaîne. Après quoi le fichier reste sur IPFS sans qu'aucune requête au produit ne permette de le retrouver ni de l'ouvrir.

Nous n'écrirons pas pour autant « définitivement indéchiffrable », parce que ce serait faux : une écriture sur une chaîne publique laisse une trace dans l'historique des transactions, et cet historique se consulte. Ce que le retrait enlève, c'est l'état courant et la découvrabilité — c'est beaucoup, ce n'est pas une destruction.

Nous n'étendons pas cette promesse au renouvellement des clés d'une catégorie, parce qu'elle serait fausse : renouveler ferme la catégorie pour l'avenir — ce que vous y déposerez ensuite échappe à ceux qui détenaient l'ancienne clé. Cela ne rend indéchiffrable aucun fichier déjà déposé : ils gardent le même identifiant de contenu, et qui a déjà obtenu leurs clés continue de les ouvrir. Une révocation ferme l'avenir ; elle ne réécrit pas le passé.

Certains blobs remplacés — index, pointeurs, enveloppes de clé — sont bien dépinglés du service de pin une fois la nouvelle version confirmée : le dépinglage existe et fonctionne. Le fichier chiffré lui-même en est délibérément exclu, et c'est un choix de conception, non une limite technique : sur un réseau adressé par contenu, dépingler chez notre prestataire ne reprend aucune copie déjà répliquée ailleurs, et nous préférons ne pas donner à ce geste l'apparence d'une suppression. Ce qu'un retrait retire, c'est la possibilité de déchiffrer, pas des octets déjà publiés.

Quant à ce qui est écrit sur la blockchain : rien ne peut en être retiré. Une chaîne publique ne se corrige pas, elle cesse d'être alimentée. L'exercice de vos droits RGPD est détaillé sur la page dédiée.

Le scénario que cette architecture prend au sérieux est celui d'une intrusion réussie chez nous. Ce qu'un attaquant y trouverait : des fichiers chiffrés, des adresses pseudonymes et des journaux techniques. Ce qu'il n'y trouverait pas : une clé de déchiffrement, car il n'en existe aucune copie côté serveur. C'est ce qui distingue une fuite de données de santé d'une fuite d'octets illisibles.

Il y a une pièce de plus à déclarer ici, et elle nous concerne : nous détenons une clé d'administration sur les registres où sont publiées les clés publiques de chiffrement. Elle ne déchiffre rien et ne donne accès à aucun document passé. Ce qu'elle permet, c'est de remplacer la clé publique inscrite pour un compte — donc de détourner les enveloppes futures qui lui seraient adressées.

Ce qui l'encadre, dans l'ordre décroissant de solidité : chaque usage laisse une trace publique et permanente sur la chaîne, opposable et consultable par n'importe qui ; le contrat n'autorise cette opération qu'une fois par semaine et par compte — ce qui borne un abus, ne l'empêche pas, et le contrat le dit ainsi lui-même. Nous visons le déplacement de cette clé vers une signature multiple, qui ne reposerait plus sur une seule partie ; les contrats ont été écrits pour le permettre sans redéploiement. Ce n'est pas fait à ce jour.

Le scénario symétrique, et nous ne le minimisons pas : si votre compte d'authentification est compromis, la personne qui peut signer à votre place peut re-dériver vos clés. La dérivation déterministe qui vous évite une phrase secrète de douze mots a ce revers. Protéger l'accès à votre messagerie et activer une double authentification chez votre fournisseur d'identité est, dans ce modèle, la mesure de sécurité qui vous revient.

Un incident de sécurité peut nous être signalé à l'adresse contact@healthguard-project.com. Nous n'avons pas, à ce jour, de procédure de réponse à incident publiée ni éprouvée : l'écrire serait plus rassurant que vrai.

Cette section existe parce qu'un lecteur professionnel la cherchera, et parce qu'une limite énoncée vaut mieux qu'une limite découverte.

Nous ne pouvons pas reprendre ce qui a déjà été déchiffré

Une révocation, une échéance ou un retrait ferment l'avenir. Ce qu'un professionnel a déjà déchiffré, il a pu le conserver — aucun système ne peut le reprendre.

Nous ne pouvons pas vous dire tout ce qui a été ouvert

L'ouverture d'un de vos documents depuis l'application HealthGuard inscrit sur la chaîne 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, sur « Voir les ouvertures de vos documents ».

Ce que cet enregistrement établit : le client officiel d'un professionnel a obtenu la clé de ce document et ouvert une séance d'accès à cet instant. Pas qu'un soignant a lu ce document, ni qu'il n'en a pas gardé de copie.

Côté professionnel, cet enregistrement porte l'adresse de son compte et l'heure de chacune de ses ouvertures, sur une chaîne publique et de façon permanente : il ne peut ni l'empêcher, ni l'effacer. Nous l'écrivons aussi à son intention dans nos conditions d'utilisation.

Le journal d'activité présent dans l'application est, lui, local et par appareil : il enregistre ce que cet appareil-là a fait avec la clé de ce compte-là. Une liste vide n'y signifie pas qu'il ne s'est rien passé, seulement qu'il ne s'est rien passé ici.

Nous ne pouvons pas effacer ce qui est publié

Ni une écriture sur une blockchain publique, ni un fichier déjà répliqué sur un réseau décentralisé. Ce que nous pouvons faire, c'est cesser d'alimenter, retirer l'état courant et la découvrabilité, et fermer l'avenir d'une catégorie. Pas revenir sur ce qui a déjà été délivré. Voir le §9.

Nous ne pouvons pas empêcher un accès d'urgence abusif

Seulement le borner à 24 heures, le réserver à des professionnels enregistrés, et vous le montrer pendant qu'il est ouvert — quand la recherche aboutit ; l'écran vous avertit lorsqu'elle n'a pas pu être menée à son terme. Voir le §7.

Cette borne de 24 heures ne vaut que pour l'accès du §7. La fiche d'urgence à deux facteurs du §8 n'en a aucune : une fois votre carte scannée, elle le reste tant que vous ne la réimprimez pas.

Nous ne pouvons pas garantir votre compte à votre place

Qui contrôle votre authentification peut re-dériver vos clés. Aucune propriété cryptographique du produit ne compense la compromission du compte dont tout dérive.

Une garantie repose sur notre discipline, pas sur le contrat

Le champ de métadonnées qu'un document écrit sur la chaîne est validé par le contrat sur sa taille, pas sur son contenu. Rien n'empêche structurellement un client mal écrit d'y inscrire du texte clair, de façon permanente. Notre code applique une liste blanche de champs avant chaque écriture — mais c'est une discipline de développement, pas une garantie opposable, et nous préférons le dire que le laisser deviner.

HealthGuard est en bêta. Les contrats sont déployés sur Base Sepolia, un réseau de test. Aucun déploiement en production n'a eu lieu à ce jour.

Hébergement et certification : ce que nous n'avons pas

Nous ne revendiquons aucune certification. HealthGuard n'est pas hébergeur de données de santé (HDS), n'est pas certifié ISO 27001, ne relève pas d'un cadre HIPAA, et n'a pas fait l'objet d'un audit de sécurité externe. Notre unique hébergeur de contenu aujourd'hui — le service de pin IPFS — n'est pas un hébergeur certifié HDS.

Nous écartons aussi explicitement le raisonnement qui nous arrangerait : « les données étant chiffrées de bout en bout, l'hébergeur n'héberge pas de données de santé, donc la question HDS est sans objet ». Elle ne l'est pas. La certification HDS porte sur l'activité d'hébergement — infogérance, sauvegarde, administration — et non sur la lisibilité du contenu ; certaines métadonnées restent en clair chez l'hébergeur ; et une mesure technique peut être contournée par une régression, là où une exigence contractuelle subsiste.

Ce qui déclenchera le passage à un hébergement certifié

Trois seuils sont posés, et la décision doit précéder le franchissement, pas le suivre.

• •Un professionnel de santé dépose pour un patient dans le cadre de son exercice : l'hébergement cesse d'être un choix personnel du patient.
• •Une institution entre dans la boucle — établissement, réseau de soins, laboratoire — et impose son propre cadre de stockage.
• •La sortie de la bêta sur des données réelles : un jeu de test contient des données fabriquées, le premier dossier réel change la nature de la question.

La suite est décrite dans la feuille de route, et vos droits sur la page RGPD.