La promesse revient à chaque cycle d’engouement : mettre le dossier médical du patient « sur la blockchain » pour le rendre inviolable, portable et contrôlé par le patient lui-même. L’idée séduit les directions d’établissement, les start-up de la e-santé et les investisseurs. Elle se heurte pourtant à un mur réglementaire et technique que la plupart des présentations commerciales ignorent soigneusement.
La réponse courte est la suivante : en France, on ne stocke pas un dossier patient sur une blockchain publique, et ce n’est pas un problème de maturité technologique mais un impératif juridique. En revanche, la blockchain a un rôle réel et défendable dans la santé, à condition de comprendre exactement où elle intervient. Cet article décrit le cadre légal applicable (hébergement des données de santé, RGPD), les vrais enjeux d’interopérabilité, l’architecture qui fonctionne, et les cas d’usage qui tiennent la route face à ceux qui relèvent du mirage.
Ce que recouvre « dossier patient sur blockchain » (et ce que ce n’est pas)
Le premier réflexe d’ingénierie est de distinguer deux objets radicalement différents que le discours marketing confond en permanence : la donnée de santé et la preuve relative à cette donnée.
Une donnée de santé, c’est le contenu d’un compte rendu opératoire, un résultat de biologie, une imagerie, un historique de prescriptions. C’est volumineux, sensible, et soumis à un droit de rectification et d’effacement. Une preuve, c’est une information courte et non réversible qui atteste d’un fait : ce document existait à telle date, il n’a pas été modifié, tel professionnel y a accédé, tel patient a consenti à tel partage.
La blockchain est structurellement inadaptée au premier objet et pertinente pour le second. Un registre distribué est conçu pour être répliqué sur de nombreux noeuds, immuable et public (ou semi-public). Aucune de ces propriétés n’est souhaitable pour stocker un dossier médical : on ne veut ni réplication mondiale d’un cancer, ni immuabilité qui empêche l’effacement, ni consultation par des tiers non autorisés.
Quand un projet annonce « le dossier patient sur la blockchain », il faut donc immédiatement poser une question : qu’est-ce qui est réellement inscrit dans un bloc ? Si la réponse est « les données de santé, même chiffrées », le projet est non conforme et dangereux. Si la réponse est « uniquement des empreintes cryptographiques, des jetons de consentement et des journaux d’accès », alors la conversation peut commencer.
Le cadre légal incontournable : HDS, L.1111-8 et RGPD
Aucune architecture santé ne se conçoit en France sans partir du droit. Trois textes structurent le sujet.
L’hébergement des données de santé (HDS)
L’article L.1111-8 du code de la santé publique impose que toute personne hébergeant des données de santé à caractère personnel, recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte de tiers, soit certifiée HDS. Cette certification, gérée par l’Agence du Numérique en Santé (ANS), n’est pas une formalité : elle couvre six activités d’hébergement distinctes définies à l’article R.1111-9 du même code, allant de la mise à disposition d’infrastructures physiques à l’administration et à l’exploitation du système d’information contenant les données. Le détail du dispositif est public sur le site de l’ANS, page certification HDS.
La conséquence est directe et sans appel pour tout projet blockchain : une chaîne publique et décentralisée ne peut pas être certifiée HDS. Il n’existe aucune entité responsable identifiable, aucune localisation maîtrisée des données, aucun engagement contractuel opposable sur la sécurité de l’hébergement. Les données de santé ne peuvent donc jamais résider en clair, ni même chiffrées, dans les blocs d’une chaîne publique.
Le RGPD et les données sensibles
Les données de santé sont une catégorie particulière au sens de l’article 9 du RGPD (voir le texte de référence sur gdpr-info.eu, article 9). Leur traitement est en principe interdit, sauf exceptions strictement encadrées (consentement explicite, finalité de soins, intérêt public en matière de santé). Deux droits entrent frontalement en collision avec la nature d’une blockchain :
- Le droit de rectification (article 16) : une donnée immuable ne se corrige pas.
- Le droit à l’effacement (article 17) : une donnée répliquée sur des milliers de noeuds ne s’efface pas.
La sanction en cas de manquement n’est pas symbolique. L’article 83 du RGPD prévoit des amendes administratives pouvant atteindre 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. La Commission Nationale de l’Informatique et des Libertés (CNIL) rappelle sur sa page dédiée ce qu’est une donnée de santé la rigueur attendue sur ce périmètre.
Pourquoi ce cadre n’est pas une contrainte anecdotique
La santé est le secteur qui paie le plus cher ses failles. Selon le rapport annuel IBM Cost of a Data Breach, le coût moyen d’une violation de données dans la santé a atteint près de 9,8 millions de dollars en 2024, faisant de ce secteur le plus coûteux pour la quatorzième année consécutive. En France, les établissements de santé sont la cible régulière d’attaques par rançongiciel, au point que l’ANS opère un service dédié, le CERT Santé, qui accompagne les hôpitaux confrontés à un incident majeur. Concevoir une architecture qui multiplie les copies de données sensibles va exactement à l’opposé de cette réalité opérationnelle.
Interopérabilité : pourquoi FHIR et le CI-SIS priment sur la chaîne
Le second malentendu majeur concerne l’interopérabilité. Beaucoup de projets présentent la blockchain comme la solution au cloisonnement des systèmes d’information hospitaliers. C’est une confusion de couches.
L’interopérabilité en santé n’est pas un problème de stockage, c’est un problème de format et de sémantique. Deux logiciels métier doivent pouvoir échanger un résultat de laboratoire en s’accordant sur la structure du message, le vocabulaire médical utilisé et les identifiants du patient et du professionnel. Ce travail est porté par des standards spécialisés.
Le standard de référence international est HL7 FHIR (Fast Healthcare Interoperability Resources), qui définit des ressources structurées (Patient, Observation, MedicationRequest, etc.) échangeables via des API REST. La documentation officielle est publiée par HL7 sur hl7.org/fhir. En France, ce socle est décliné dans le Cadre d’Interopérabilité des Systèmes d’Information de Santé (CI-SIS), maintenu par l’ANS et documenté sur la page interopérabilité, qui précise les volets techniques et les terminologies de référence obligatoires.
Ce socle n’est pas théorique : il est activement financé et déployé. Le programme national Ségur du numérique en santé, documenté par l’ANS sur la page Ségur du numérique en santé, conditionne des financements publics à la mise en conformité des logiciels métier avec les référentiels d’interopérabilité et de sécurité. Autrement dit, l’écosystème français a déjà tranché la question de la couche d’échange : elle repose sur des référentiels ouverts et opposables, pas sur un registre distribué propriétaire. Un projet blockchain qui ignore le Ségur et le CI-SIS se condamne à rester en marge des flux réels du système de soins, quelle que soit la qualité de sa cryptographie.
La blockchain n’intervient à aucun moment dans ce travail de normalisation. Un dossier patient devient interopérable parce qu’il est exposé en FHIR conforme au CI-SIS, pas parce qu’un hash de ce dossier est ancré quelque part. Confondre les deux revient à croire qu’un cadenas résout un problème de langue. Une fois l’interopérabilité assurée au niveau applicatif, la blockchain peut, éventuellement, ajouter une couche de preuve : attester que la version échangée est bien celle qui a été validée, ou que le patient a consenti à ce partage précis.
Ce point de vigilance sur le couple donnée / preuve rejoint la logique d’ancrage documentée dans notre article sur la notarisation blockchain et la valeur juridique d’un horodatage on-chain.
L’architecture qui fonctionne : off-chain pour la donnée, on-chain pour la preuve
Il existe une architecture de référence, désormais consensuelle dans les déploiements sérieux, dite off-chain / on-chain. Elle se résume en une phrase : la donnée reste dehors, la preuve entre dedans.
Concrètement :
- Le dossier patient est stocké off-chain, dans le système d’information de l’établissement ou chez un hébergeur certifié HDS. C’est ce système, et lui seul, qui applique le chiffrement, la gestion fine des droits d’accès et l’effacement.
- Une empreinte cryptographique (hash SHA-256, par exemple) est calculée sur le document ou sur un événement (un accès, un consentement). Ce hash est une chaîne de caractères de longueur fixe, non réversible : il est mathématiquement impossible de reconstruire la donnée source à partir du hash.
- Seul ce hash, éventuellement accompagné d’un horodatage et d’un identifiant technique, est inscrit on-chain.
Cette conception résout élégamment le conflit avec le RGPD. Pour exercer le droit à l’effacement, il suffit de détruire la donnée source et, le cas échéant, la clé de chiffrement. Le hash restant sur la chaîne devient alors un objet inerte : il ne pointe plus vers rien et ne permet aucune ré-identification. La chaîne n’est jamais modifiée, mais l’effacement est bien réel et opposable. Ce mécanisme est exactement celui que nous décrivons pour les usages entreprise dans l’article NFT et cas d’usage en entreprise, où le hash on-chain sert de sceau et non de coffre-fort.
Sur cette base, trois briques applicatives ont un sens en santé :
- La preuve d’intégrité : ancrer le hash d’un compte rendu permet de démontrer, des années plus tard, qu’il n’a pas été altéré depuis sa validation. Utile en cas de contentieux médical ou d’expertise.
- La gestion du consentement : le patient accorde ou révoque l’accès à ses données pour tel professionnel ou telle finalité. Chaque décision est un événement horodaté et inviolable, ce qui rejoint les problématiques d’identité et de vérification traitées dans notre article sur la vérification d’identité réutilisable et le RGPD.
- La traçabilité inter-établissements : lorsqu’un patient passe d’un CHU à une clinique puis à un service de soins à domicile, un registre partagé des accès et des transferts, sans autorité centrale unique, apporte une auditabilité que les échanges point à point ne garantissent pas.
L’identité du patient et des professionnels est elle-même un chantier à part entière, où les standards d’identité décentralisée commencent à jouer un rôle. Nous détaillons ce cadre dans l’article identité décentralisée (DID), standards W3C et adoption en entreprise.
Blockchain publique, privée ou de consortium : le bon choix
Le type de chaîne détermine largement la conformité possible. Le tableau suivant synthétise les arbitrages.
| Type de chaîne | Localisation des noeuds | Compatible HDS pour l’hébergement | Usage réaliste en santé |
|---|---|---|---|
| Publique (Ethereum, Polygon) | Mondiale, non maîtrisée | Non | Ancrage de hash uniquement, aucune donnée |
| Privée (un opérateur) | Maîtrisée | Selon l’hébergeur sous-jacent | Preuve et traçabilité internes |
| Consortium (Hyperledger Fabric, Quorum) | Maîtrisée, acteurs identifiés | Possible si infrastructure certifiée HDS | Partage et consentement inter-établissements |
La règle pratique se lit ainsi. Si le besoin est une preuve publique et opposable (un hash horodaté que n’importe qui peut vérifier sans faire confiance à un opérateur), une chaîne publique convient, mais uniquement pour le hash. Si le besoin est un partage contrôlé entre acteurs connus du parcours de soins, une blockchain de consortium hébergée sur une infrastructure certifiée HDS est la seule voie défendable, et elle n’exonère jamais de l’analyse d’impact relative à la protection des données (AIPD) exigée par la CNIL pour tout traitement de données de santé à grande échelle.
Cette grille de lecture est la même que celle qui gouverne les projets B2B tracés dans notre article sur la supply chain et la blockchain : le registre distribué n’a de valeur que lorsque plusieurs organisations qui ne se font pas pleinement confiance doivent partager une vérité commune.
Cas d’usage réalistes contre mirages
Pour trancher rapidement un projet, il est utile d’opposer ce qui fonctionne à ce qui ne fonctionne pas.
Ce qui tient la route :
- Ancrer l’empreinte d’un consentement éclairé pour un essai clinique, afin de prouver qu’il a été recueilli avant l’inclusion.
- Sceller le hash d’un compte rendu d’imagerie pour garantir son intégrité en cas d’expertise ultérieure.
- Journaliser de façon inviolable les accès à un dossier partagé entre plusieurs établissements d’un groupement hospitalier de territoire.
- Tracer la chaîne du froid et l’authenticité d’un médicament ou d’un dispositif implantable, un sujet frontière entre santé et logistique.
Ce qui relève du mirage :
- « Le patient possède son dossier sur la blockchain et le porte partout. » Le dossier reste chez des hébergeurs HDS ; ce que le patient peut porter, ce sont des clés et des droits d’accès, pas les téraoctets d’imagerie.
- « La blockchain remplace le dossier médical partagé national. » Le dispositif national repose sur Mon espace santé et le CI-SIS, décrit sur monespacesante.fr, pas sur un registre décentralisé.
- « Les données sont chiffrées, donc les mettre dans un bloc est conforme. » Le chiffrement ne rend pas une donnée anonyme au sens du RGPD, et une clé finit toujours par être compromise ou perdue. L’immuabilité reste incompatible avec le droit à l’effacement.
La distinction est toujours la même : la blockchain ancre des preuves, elle n’héberge pas des dossiers.
Questions fréquentes
Peut-on légalement stocker un dossier patient complet sur une blockchain en France ?
Non, pas sur une blockchain publique. Les données de santé relèvent de l’hébergement HDS (article L.1111-8 du code de la santé publique) et doivent être confiées à un hébergeur certifié. Une chaîne publique ne peut ni être certifiée HDS, ni garantir le droit à l’effacement. L’architecture conforme conserve le dossier off-chain et n’ancre qu’un hash non réversible.
À quoi sert alors la blockchain si les données restent ailleurs ?
À prouver l’intégrité d’un document, à tracer les accès et les consentements de façon inviolable, et à permettre un partage inter-établissements sans autorité centrale unique. C’est un registre de preuves et de droits, jamais un lieu de stockage.
Comment concilier l’immuabilité de la blockchain avec le droit à l’effacement ?
Par l’architecture off-chain / on-chain. La donnée réelle reste sur un système effaçable, seul un hash est inscrit sur la chaîne. Détruire la donnée source et la clé rend le hash inexploitable, ce qui satisfait la logique de l’article 17 du RGPD sans jamais modifier la chaîne.
Une blockchain de consortium change-t-elle la donne pour l’hébergement HDS ?
Partiellement. Un consortium géré par des acteurs identifiés et hébergé sur une infrastructure certifiée HDS peut entrer dans un périmètre conforme selon l’usage, car les noeuds sont maîtrisés. Cela ne dispense ni de l’analyse d’impact, ni de la certification. Le gain se limite à la traçabilité et à la preuve d’intégrité.
Le « dossier patient sur la blockchain » est une formule commode qui masque une réalité plus exigeante. En France, les données de santé restent chez des hébergeurs certifiés HDS, protégées par le RGPD et exposées via des standards d’interopérabilité comme FHIR et le CI-SIS. La blockchain n’a de valeur que sur une couche précise : la preuve. Ancrer un hash, sceller un consentement, journaliser un accès entre organisations qui ne se font pas pleinement confiance, voilà des usages défendables. Stocker un dossier médical dans un bloc n’en est pas un, et ne le deviendra pas, parce que l’obstacle est juridique et non technologique.
Pour toute organisation qui évalue un projet, la bonne première question n’est jamais « quelle chaîne utiliser », mais « qu’est-ce qui est réellement inscrit on-chain, et où reste la donnée ». Si la réponse place une donnée de santé dans un bloc, le projet est à reprendre. Pour approfondir les usages professionnels du registre distribué, consultez la catégorie blockchain B2B et le glossaire blockchain.