Secrecy Care Blog
Find the latest news from Secrecy Care, new products, events, and articles from our experts here.
Find the latest news from Secrecy Care, new products, events, and articles from our experts here.
« Vos données sont chiffrées » : la formule figure dans presque tous les contrats d'hébergement de santé, et elle recouvre des réalités très différentes. Entre un flux protégé pendant son transport et un dossier que personne d'autre que vous ne peut ouvrir, l'écart est considérable. Ce guide distingue les quatre niveaux du chiffrement des données de santé et précise ce que chacun garantit réellement.
Le chiffrement des données de santé se décline en quatre niveaux cumulables. Le chiffrement en transit protège l'acheminement entre un poste et un serveur. Le chiffrement au repos protège le stockage contre un vol de support ou un accès direct à la base. Le chiffrement côté client déplace l'opération sur l'appareil de l'utilisateur, avant tout envoi. Le chiffrement de bout en bout va plus loin encore : le prestataire ne détient aucune clé et ne peut techniquement pas lire ce qu'il héberge. Un point mérite d'être clarifié, car il est source de malentendus fréquents : la certification HDS impose un niveau de sécurité audité, incluant le chiffrement au repos et en transit, mais elle n'exige pas que l'hébergeur soit dans l'incapacité de lire les données. Un prestataire parfaitement certifié conserve donc, dans la plupart des architectures, une capacité technique d'accès. Le choix du niveau pertinent dépend des fonctionnalités attendues : un dossier partagé entre soignants suppose que ceux-ci puissent le lire, ce qu'un chiffrement de bout en bout strict interdirait.
Le chiffrement en transit sécurise la circulation des informations entre le navigateur d'un professionnel, l'application métier et les serveurs. Il empêche l'interception sur un réseau, notamment depuis un point d'accès partagé. Sa limite est nette : la protection s'arrête à l'arrivée sur le serveur, où l'information redevient lisible.
Le chiffrement au repos protège les données stockées. Si un disque est dérobé, si une sauvegarde fuite ou si un attaquant accède directement au stockage sans passer par l'application, le contenu demeure inexploitable. C'est le niveau que la certification HDS impose et audite. Sa limite tient à la détention des clés : l'hébergeur les possède, donc il peut lire, qu'il le fasse ou non.
Le chiffrement côté client déplace l'opération sur l'appareil de l'utilisateur. L'information arrive déjà protégée sur l'infrastructure. Selon l'architecture retenue, le fournisseur peut toutefois conserver un mécanisme de récupération de clé, ce qui préserve une capacité d'accès exceptionnelle.
Le chiffrement de bout en bout supprime cette possibilité. Les clés sont générées et conservées exclusivement par les parties légitimes ; le prestataire achemine et stocke des blocs qu'il lui est techniquement impossible de déchiffrer. C'est le seul niveau qui retire l'hébergeur du périmètre de confiance.
Nous détaillons ce mécanisme dans notre guide du chiffrement de bout en bout appliqué aux données médicales, et son application au stockage dans notre article sur le chiffrement cloud côté client des dossiers médicaux.
C'est le point où la confusion coûte le plus cher aux acheteurs.
L'article L. 1111-8 du Code de la santé publique impose que tout hébergement de données de santé pour le compte d'un tiers soit assuré par un prestataire certifié. Cette certification, délivrée par des organismes accrédités, audite la sécurité physique et logique de l'hébergement, la gestion des accès, la traçabilité et la continuité de service. Elle inclut des exigences de chiffrement.
Ce qu'elle ne fait pas, en revanche, c'est exiger que l'hébergeur soit incapable de lire les informations qu'il conserve. Un prestataire certifié peut parfaitement détenir les clés de déchiffrement — c'est même le cas de la grande majorité des architectures en production, y compris celles des dispositifs nationaux.
La conséquence pratique pour un acheteur est simple : la mention « certifié HDS » ne répond pas à la question « mon hébergeur peut-il lire nos dossiers ». Ce sont deux garanties distinctes, et seule la seconde relève d'un choix d'architecture. Notre guide de sélection d'un cloud santé conforme HDS détaille les questions à poser pour lever cette ambiguïté, et notre guide de l'hébergement de données de santé précise le périmètre exact de la certification.
Le cas du dossier médical partagé illustre bien l'arbitrage en jeu. Les documents y sont protégés par un chiffrement en transit et au repos, hébergés chez un prestataire certifié, avec traçabilité de chaque consultation. Ils ne sont pas pour autant chiffrés de bout en bout — et cette conception est délibérée.
La raison tient à la finalité du dispositif. Un dossier partagé n'a de sens que si plusieurs professionnels de santé peuvent le consulter, chacun dans les limites de sa profession. Un chiffrement de bout en bout strict, où seul le patient détiendrait les clés, rendrait le dossier inaccessible dès lors que ce dernier serait inconscient aux urgences, ou simplement indisponible.
La protection repose donc sur une combinaison différente : chiffrement, contrôle d'accès fin défini par une matrice d'habilitation, et journalisation exploitable par le patient. Nous détaillons ce fonctionnement dans notre article sur le dossier médical chiffré et dans celui consacré à l'accès des professionnels au dossier médical.
Trois niveaux se superposent. L'article 32 du RGPD impose des mesures techniques appropriées au risque et cite explicitement le chiffrement parmi elles, sans prescrire ni algorithme ni architecture. Cette formulation ouverte confie l'arbitrage au responsable de traitement, qui doit pouvoir le documenter.
L'article 9 du RGPD classe par ailleurs les données de santé parmi les catégories particulières, dont le traitement est interdit par principe sauf exceptions précises. Ce statut renforce l'exigence de proportionnalité des mesures de sécurité, sans pour autant imposer un niveau technique déterminé.
Sur les aspects proprement cryptographiques, l'ANSSI a publié le 20 mars 2026 la version 3.00 de son guide des mécanismes cryptographiques, qui fixe des repères directement exploitables : une taille minimale de 128 bits pour les clés symétriques, avec 192 ou 256 bits pour disposer d'une marge substantielle face aux attaques quantiques, et l'usage de modes de chiffrement authentifiés assurant simultanément confidentialité et intégrité (source : ANSSI, guide des mécanismes cryptographiques v3.00, cyber.gouv.fr).
Deux évolutions structurent la période. La première tient au renforcement continu des exigences d'hébergement, avec des révisions régulières du référentiel de certification portant notamment sur la transparence des transferts et la soumission éventuelle du prestataire à un droit extra-européen — nous suivons ce point dans notre article sur la certification HDS v2.1.
La seconde concerne la transition post-quantique. Les données de santé se conservent longtemps, parfois plusieurs décennies, ce qui les place pleinement dans la fenêtre de risque d'une capacité de calcul quantique future. L'ANSSI préconise une approche progressive fondée sur l'hybridation, combinant un mécanisme éprouvé et un algorithme post-quantique. Pour un établissement comme pour un éditeur, l'inventaire cryptographique — savoir où intervient la cryptographie, avec quels algorithmes, pour des données de quelle durée de vie — constitue le préalable à toute migration.
Message clé : le chiffrement des données de santé n'est pas une case à cocher mais un choix à quatre niveaux, et la certification HDS n'en garantit que les deux premiers — savoir qui détient les clés reste une question distincte, qu'il faut poser explicitement.
Pour un DPO ou une direction informatique, la démarche utile consiste donc à déterminer d'abord quelles fonctionnalités le service doit offrir, puis à en déduire le niveau de chiffrement compatible, plutôt qu'à viser le niveau maximal sans arbitrage.
Les données de santé doivent-elles être chiffrées obligatoirement ? L'article 32 du RGPD impose des mesures appropriées au risque et cite le chiffrement, sans le rendre formellement obligatoire dans tous les cas ; pour des données de santé, il est en pratique attendu.
La certification HDS impose-t-elle le chiffrement de bout en bout ? Non, elle impose un niveau de sécurité audité incluant le chiffrement au repos et en transit, mais n'exige pas que l'hébergeur soit dans l'incapacité technique de lire les données.
Quelle différence entre chiffrement au repos et en transit ? Le chiffrement en transit protège l'acheminement des informations sur le réseau, le chiffrement au repos protège leur stockage : les deux sont complémentaires et ne se substituent pas l'un à l'autre.
Qui détient les clés de chiffrement de mes données de santé ? Cela dépend de l'architecture : dans la plupart des services, l'hébergeur ou l'éditeur les détient ; seul un chiffrement de bout en bout garantit qu'elles restent exclusivement entre les mains des parties légitimes.
Le chiffrement suffit-il à protéger un dossier médical ? Non, il doit être combiné à un contrôle d'accès fin déterminant qui peut consulter quoi, et à une traçabilité permettant de vérifier a posteriori qui a effectivement accédé aux informations.
Quel algorithme de chiffrement pour des données de santé ? L'ANSSI recommande des clés symétriques d'au moins 128 bits, 192 ou 256 bits offrant une marge substantielle, avec des modes de chiffrement authentifiés garantissant à la fois confidentialité et intégrité.
Un hébergeur situé en France peut-il lire mes données ? La localisation ne dit rien de la capacité d'accès : seule l'architecture de gestion des clés détermine si un prestataire peut ou non déchiffrer ce qu'il héberge.
Le chiffrement des données de santé se décline en quatre niveaux : en transit, au repos, côté client et de bout en bout. La certification HDS, obligatoire pour tout hébergement de données de santé pour compte de tiers, impose et audite les deux premiers niveaux mais n'exige pas que l'hébergeur soit incapable de lire les données. Le niveau pertinent dépend des fonctionnalités attendues : un dossier partagé entre soignants suppose une capacité de lecture que le chiffrement de bout en bout strict interdirait. L'ANSSI fixe les repères algorithmiques dans son guide des mécanismes cryptographiques, actualisé en mars 2026.
Trois questions à poser par écrit à tout prestataire, avant signature : quel niveau de chiffrement s'applique à quels flux exactement ; qui détient les clés de déchiffrement, y compris dans les cas exceptionnels de support ou de conformité ; et comment les sauvegardes ainsi que les environnements de test sont protégés. Les réponses, ou leur absence, en disent plus long que toute mention commerciale de conformité.
La certification HDS garantit un hébergement audité, pas un hébergeur incapable de lire vos dossiers.
Le chiffrement de bout en bout n'est pas toujours le bon niveau : un dossier partagé entre soignants suppose qu'ils puissent le lire.
La localisation d'un serveur ne dit rien de la capacité d'accès : seule la gestion des clés le détermine.
Imaginez quatre façons de confier un dossier à un service d'archivage. Dans la première, un coursier blindé l'apporte, mais le dossier reste lisible une fois arrivé. Dans la deuxième, il est rangé dans un coffre dont l'archiviste possède la clé. Dans la troisième, vous le scellez vous-même avant de le remettre, mais l'archiviste conserve un double du sceau pour les cas d'urgence. Dans la quatrième, vous le scellez avec une clé dont aucun double n'existe : l'archiviste stocke un objet qu'il ne pourra jamais ouvrir. Les quatre sont légitimes ; elles ne répondent simplement pas aux mêmes besoins.
Sur le plan de l'implémentation, quelques repères permettent de traduire ces niveaux en décisions concrètes. Pour le transit, retenir une version récente de TLS avec des suites cryptographiques conformes aux recommandations de l'ANSSI, en désactivant explicitement les versions et suites obsolètes. Pour le repos, privilégier un mode de chiffrement authentifié — AES-256-GCM ou ChaCha20-Poly1305 — plutôt qu'un mode dépourvu de protection en intégrité, aucun des modes classiques comme CBC ou CTR n'apportant de garantie contre la modification des données. Pour le stockage, adopter une enveloppe autodescriptive comportant un numéro de version de format, l'identifiant de la clé et le nonce : cette structure conditionne la possibilité de faire tourner les clés sans migration massive et de préparer une future transition post-quantique. Sur la gestion des clés, appliquer le principe « une clé, un usage » et séparer strictement le lieu de stockage des clés de celui des données qu'elles protègent ; dans une architecture mutualisée, dériver une clé par établissement client permet à la fois le cloisonnement et la suppression cryptographique en fin de contrat. Enfin, sur la traçabilité, journaliser chaque opération de déchiffrement avec l'identité de l'appelant, et surtout exploiter effectivement ces enregistrements : un journal conservé mais jamais analysé n'apporte aucune capacité de détection.