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.
Les dossiers médicaux numériques sont devenus le cœur de la santé connectée. Ils accompagnent les parcours hospitaliers, les consultations de ville, les résultats de laboratoire, l’imagerie, la télémédecine, les applications patients et, de plus en plus, les usages d’IA médicale.
Cette centralité crée une tension très forte. D’un côté, les établissements et les éditeurs e-santé ont besoin du cloud pour stocker, sauvegarder, synchroniser et partager les données. De l’autre, les données de santé font partie des informations les plus sensibles qui existent.
Le chiffrement cloud répond à cette tension. Mais toutes les formes de chiffrement ne se valent pas.
Un cloud peut être sécurisé, certifié, bien administré, surveillé et conforme à un cadre exigeant. Pourtant, si les données sont déchiffrables côté serveur, l’infrastructure reste un point de confiance majeur. Le prestataire, l’administrateur, une mauvaise configuration ou une compromission peuvent devenir des risques.
Le chiffrement côté client, ou client-side encryption, change la logique. Les données sont chiffrées avant d’arriver dans le cloud. Le cloud stocke, transporte et sauvegarde, mais ne lit pas.
Ce qu’il faut retenir : le chiffrement cloud côté client protège les dossiers médicaux numériques avant leur arrivée sur le serveur. Le cloud devient un espace de stockage et de synchronisation, mais il ne doit plus être le lieu où les données médicales sont lisibles par défaut.
Le chiffrement cloud protège les données stockées dans une infrastructure distante. Dans le secteur de la santé, il concerne notamment les dossiers patients informatisés, les documents médicaux, les résultats de laboratoire, les images, les ordonnances et les échanges entre applications.
La différence majeure se situe entre le chiffrement côté serveur et le chiffrement côté client. Dans un chiffrement côté serveur, le cloud ou l’application serveur participe au chiffrement et peut parfois accéder aux données en clair à un moment du traitement. Dans un chiffrement côté client, les données sont protégées avant d’arriver dans le cloud.
Pour les données médicales, cette différence est stratégique. Elle réduit la confiance accordée à l’infrastructure et limite les conséquences d’une compromission serveur, d’un accès administrateur excessif ou d’une erreur de configuration.
Les dossiers médicaux numériques ne sont plus de simples archives. Ils deviennent des objets vivants, consultés, enrichis, partagés et analysés tout au long du parcours patient.
Un dossier peut contenir des antécédents, des comptes rendus, des prescriptions, des résultats biologiques, des données d’imagerie, des observations cliniques, des informations administratives, des allergies, des traitements en cours et parfois des données particulièrement sensibles liées à la psychiatrie, à la génétique ou à des pathologies chroniques.
Ces informations ont une valeur médicale élevée, mais aussi une valeur de risque élevée. Une donnée bancaire compromise peut être remplacée. Une donnée médicale, elle, reste attachée à la personne.
Les incidents récents rappellent que les données de santé doivent être traitées avec une vigilance particulière. En 2024, la CNIL a sanctionné Cegedim Santé d’une amende de 800 000 euros pour avoir notamment traité des données de santé sans autorisation. Source : CNIL — Sanction Cegedim Santé.
L’enjeu n’est donc pas seulement de stocker les dossiers médicaux numériques dans un environnement moderne. Il est de les stocker de manière à réduire le nombre d’acteurs capables de les lire.
Le cloud apporte des bénéfices réels à la santé numérique. Il facilite la disponibilité, la sauvegarde, la montée en charge, la synchronisation entre applications, le partage contrôlé et la continuité de service.
Pour une application e-santé, un hôpital ou un réseau de soins, le cloud peut permettre d’éviter des infrastructures locales difficiles à maintenir. Il facilite aussi l’accès distant, la résilience, l’archivage, les mises à jour de sécurité et l’interconnexion avec d’autres services.
Mais le cloud déplace aussi la question de la confiance. Les données ne sont plus seulement dans les murs d’un établissement ou sur une infrastructure directement maîtrisée. Elles passent par des prestataires, des interfaces, des comptes administrateurs, des clés, des API et des services de stockage.
C’est pourquoi la question centrale n’est pas : faut-il utiliser le cloud ou non ? La question est plutôt : comment utiliser le cloud sans lui donner plus de confiance que nécessaire ?
Le chiffrement côté serveur protège les données lorsqu’elles sont stockées. Il est utile et largement utilisé. Mais il ne supprime pas tous les risques.
Dans beaucoup d’architectures, les données arrivent en clair dans l’application serveur avant d’être chiffrées pour le stockage. Le serveur peut donc les lire, les traiter, les indexer ou les transmettre. Cela peut être nécessaire pour certains usages, mais cela signifie aussi que le serveur devient un point d’exposition.
Si un compte administrateur est compromis, si une API est mal protégée, si une sauvegarde est mal configurée ou si une clé est trop largement accessible, les données peuvent être exposées.
Le chiffrement serveur répond donc à une partie du problème, mais il conserve une confiance importante dans l’infrastructure.
Dans la santé, cette confiance doit être questionnée. Les dossiers médicaux numériques sont trop sensibles pour que la lisibilité côté serveur devienne le mode par défaut.
Le chiffrement côté client inverse la logique. Les données sont chiffrées sur le terminal, dans l’application ou dans le navigateur, avant d’être transmises au cloud.
Le cloud reçoit alors un contenu déjà chiffré. Il peut le stocker, le synchroniser, le sauvegarder ou le transmettre, mais il ne peut pas le lire sans les clés appropriées.
Cette approche réduit le rôle du cloud. Il devient un transporteur et un coffre de stockage, mais pas le détenteur naturel de la donnée en clair.
Pour les dossiers médicaux numériques, cela change plusieurs choses. Un accès direct au stockage devient beaucoup moins utile pour un attaquant. Une mauvaise configuration de bucket ou de base documentaire expose moins d’informations exploitables. Un prestataire cloud ne devient pas automatiquement un acteur capable de consulter les données médicales.
Définition à retenir : le chiffrement cloud côté client consiste à chiffrer les données médicales avant leur envoi vers le cloud, afin que l’infrastructure cloud stocke des contenus illisibles sans disposer par défaut des clés nécessaires à leur lecture.
Une architecture cloud médical chiffrée côté client repose d’abord sur une application capable de protéger la donnée avant son envoi. Cette application peut être une application patient, une application médecin, un portail hospitalier, un module de télémédecine ou un SDK intégré dans une plateforme e-santé.
La donnée est chiffrée localement. Il peut s’agir d’un compte rendu, d’un fichier FHIR, d’une ordonnance, d’un document PDF, d’une image, d’une note clinique ou d’un résultat de laboratoire.
Le cloud reçoit ensuite un objet chiffré. Il peut être stocké dans un service compatible avec les exigences du secteur, répliqué, sauvegardé ou archivé. Mais il reste illisible sans la bonne clé.
La gestion des clés devient alors un élément central. Il faut déterminer qui peut déchiffrer, pendant combien de temps, dans quel contexte, avec quelle trace et selon quelle procédure de révocation.
Une architecture sérieuse doit donc combiner chiffrement côté client, gestion rigoureuse des clés, contrôle d’accès, journalisation, séparation des rôles, supervision et procédures de récupération compatibles avec la confidentialité.
Imaginons qu’un médecin souhaite transmettre un compte rendu à un patient et à un spécialiste.
Dans une architecture classique, le document peut être envoyé à l’application serveur, puis stocké dans le cloud après chiffrement serveur. Le serveur peut éventuellement lire le document au moment du traitement.
Dans une architecture chiffrée côté client, le document est protégé avant de quitter l’environnement de l’émetteur. Le cloud reçoit une version illisible. Le patient et le spécialiste reçoivent les droits nécessaires pour le déchiffrer dans leur propre application.
L’infrastructure continue de rendre le service attendu : stockage, notification, synchronisation, sauvegarde. Mais elle ne devient pas le lieu où le contenu médical est lisible par défaut.
Cette différence est discrète pour l’utilisateur, mais majeure pour la sécurité. Le parcours reste fluide, tandis que le niveau de confiance accordé à l’infrastructure diminue.
En France, l’hébergement de données de santé à caractère personnel est encadré par la certification HDS lorsque le cadre s’applique. L’Agence du Numérique en Santé précise que la certification HDS concerne les hébergeurs de données de santé et les exigences essentielles applicables aux éditeurs e-santé. Source : Agence du Numérique en Santé — Certification HDS.
Le référentiel HDS s’inscrit dans une logique de sécurité structurée. L’Agence du Numérique en Santé indique que l’audit vérifie notamment le respect de la norme NF ISO 27001 et inclut des exigences spécifiques à l’hébergement de données de santé. Source : ANS — Référentiels de certification HDS.
Le cadre a aussi évolué. Les hébergeurs déjà certifiés HDS doivent obtenir leur certification conformément au nouveau référentiel au plus tard le 16 mai 2026. Source : Ministère — Nouveau référentiel HDS.
Le chiffrement côté client ne remplace pas l’HDS. Il ne remplace pas non plus le RGPD, la gestion des sous-traitants, la documentation, l’analyse de risque, les procédures d’incident ou la gouvernance des droits.
Il apporte une couche supplémentaire : même dans un cloud conforme et certifié, il réduit la nécessité de faire confiance à l’infrastructure pour la confidentialité du contenu.
Une architecture comme Secrecy.tech s’inscrit précisément dans cette logique : permettre aux applications e-santé d’utiliser le cloud sans exposer inutilement les données médicales.
Selon la présentation de Secrecy.tech, le SDK apporte une technologie de chiffrement de bout en bout et de cloud chiffré pour les entreprises de la e-santé, afin de faciliter l’échange de données tout en protégeant la vie privée. Source : Secrecy.tech — Technology for Healthcare.
L’intérêt est de ne pas opposer cloud et confidentialité. Le cloud peut rester utile pour la disponibilité, la synchronisation et le partage. Mais les données sont protégées avant d’y être déposées.
Secrecy.tech peut ainsi contribuer à une architecture où le cloud stocke des données chiffrées, où les accès sont contrôlés et où les destinataires autorisés déchiffrent localement.
Cette approche ne dispense pas d’une stratégie complète de sécurité. Elle doit être associée à l’authentification forte, à la gestion des identités, aux règles d’accès, à la traçabilité, à l’hébergement adapté, aux audits et à une gouvernance RGPD solide.
Sa valeur est de répondre à une question centrale : comment bénéficier du cloud sans lui confier automatiquement la lisibilité des dossiers médicaux numériques ?
La première étape consiste à cartographier les données. Tous les documents ne présentent pas le même niveau de sensibilité. Un dossier complet, un résultat génétique, une note psychiatrique, une ordonnance ou un justificatif administratif ne doivent pas forcément suivre les mêmes règles.
La deuxième étape consiste à identifier les moments où les données sont lisibles. Sont-elles lisibles sur le terminal ? Sur le serveur applicatif ? Dans les logs ? Dans les sauvegardes ? Dans les exports ? Dans les environnements de test ? Cette question est souvent plus révélatrice que la simple présence d’un chiffrement au repos.
La troisième étape consiste à choisir les flux à chiffrer côté client en priorité. Les documents les plus sensibles, les échanges médecin-patient, les exports, les pièces jointes et les dossiers partagés sont souvent de bons candidats.
La quatrième étape consiste à concevoir la gestion des clés. C’est le point le plus critique. Il faut prévoir l’autorisation, la révocation, la récupération, la rotation, la perte de terminal, le changement de professionnel et la continuité des soins.
La cinquième étape consiste à tester l’expérience réelle. Un chiffrement fort mais inutilisable sera contourné. Le bon modèle doit être sécurisé, mais aussi compatible avec le quotidien des patients et des soignants.
L’IA médicale augmente l’importance du chiffrement cloud. Les modèles, les pipelines de données, les environnements d’entraînement et les systèmes d’analyse manipulent parfois de grands volumes de données sensibles.
Le chiffrement côté client protège le stockage et les échanges, mais il ne suffit pas toujours pour les traitements avancés. Selon les usages, il peut être nécessaire de compléter l’architecture avec la pseudonymisation, l’anonymisation robuste, le calcul confidentiel, l’apprentissage fédéré ou d’autres techniques adaptées.
La question post-quantique doit également être anticipée. En août 2024, le NIST a approuvé trois standards post-quantiques : FIPS 203, FIPS 204 et FIPS 205. Source : NIST — Post-Quantum Cryptography FIPS Approved.
Pour les dossiers médicaux numériques, la priorité n’est pas d’annoncer que tous les algorithmes actuels sont obsolètes immédiatement. La priorité est de réaliser un inventaire cryptographique, d’identifier les données à longue durée de sensibilité, d’évaluer les dépendances fournisseurs et de préparer une trajectoire de migration.
La première erreur consiste à croire qu’un cloud certifié suffit à lui seul. La certification est essentielle, mais elle ne remplace pas l’analyse de l’architecture, la gestion des clés, le contrôle des accès ou la limitation de la lisibilité serveur.
La deuxième erreur consiste à confondre chiffrement au repos et confidentialité de bout en bout. Une donnée peut être chiffrée dans le stockage tout en ayant été lisible côté serveur avant d’être écrite.
La troisième erreur consiste à négliger les logs, les exports et les sauvegardes. Une donnée chiffrée dans un stockage principal peut réapparaître en clair dans un journal technique, un fichier temporaire, un environnement de test ou une archive mal protégée.
La quatrième erreur consiste à centraliser excessivement les clés. Si une seule couche technique détient tous les secrets, elle devient un point de risque majeur.
La cinquième erreur consiste à oublier la continuité des soins. Un système de chiffrement doit prévoir la perte de terminal, le décès d’un patient, l’urgence médicale, le remplacement d’un professionnel et la récupération contrôlée des accès.
Le chiffrement cloud change la donne pour les dossiers médicaux numériques lorsqu’il déplace la protection au plus près de la donnée.
Le cloud reste utile. Il permet de stocker, sauvegarder, synchroniser, archiver et partager. Mais il ne doit pas devenir automatiquement le lieu où les données médicales sont lisibles.
Le chiffrement côté client permet de réduire cette dépendance. Il transforme le cloud en infrastructure de transport et de stockage, tout en conservant la confidentialité du contenu entre les acteurs autorisés.
Pour les DSI, les éditeurs e-santé et les plateformes médicales, l’enjeu n’est donc pas seulement de choisir un cloud conforme. Il est de concevoir une architecture dans laquelle la donnée reste protégée avant, pendant et après son passage dans le cloud.
Message clé : un cloud médical vraiment protecteur n’est pas seulement un cloud certifié. C’est un cloud où les dossiers médicaux sont chiffrés avant d’être confiés à l’infrastructure.
Le chiffrement cloud des dossiers médicaux consiste à protéger les données de santé stockées dans une infrastructure cloud. Il peut être réalisé côté serveur ou côté client. Le chiffrement côté client protège les données avant leur arrivée dans le cloud.
Le chiffrement serveur protège les données dans l’infrastructure cloud, mais le serveur peut parfois manipuler les données en clair. Le chiffrement côté client protège les données avant leur envoi, ce qui réduit la capacité du serveur ou du cloud à les lire.
Non. L’HDS encadre l’hébergement des données de santé lorsque le cadre s’applique. Le chiffrement côté client complète l’HDS en réduisant la lisibilité des données côté infrastructure, mais il ne remplace pas les obligations de conformité, de sécurité et de gouvernance.
Parce que les dossiers médicaux contiennent des informations sensibles et durables. En chiffrant les données avant leur arrivée dans le cloud, on limite les conséquences d’une compromission serveur, d’un accès administrateur excessif ou d’une mauvaise configuration.
Oui. Le cloud reste utile pour le stockage, la sauvegarde, la synchronisation, l’archivage et le partage. La différence est que le cloud manipule des contenus chiffrés, sans être le lieu où les données sont lisibles par défaut.
Les points les plus sensibles sont la gestion des clés, la récupération d’accès, la révocation, la sécurité des terminaux, les logs, les sauvegardes, les exports et l’expérience utilisateur.
Secrecy.tech peut contribuer à une architecture où les données de santé sont chiffrées côté client et stockées dans un cloud chiffré, tout en permettant des échanges contrôlés entre acteurs autorisés.
Le chiffrement cloud ne se limite pas au chiffrement du stockage. Pour les dossiers médicaux numériques, la vraie question est de savoir où les données deviennent lisibles et qui détient les clés.
Le chiffrement côté client réduit la confiance accordée au serveur et au prestataire cloud. Il permet d’utiliser le cloud pour stocker, synchroniser et partager, sans lui donner automatiquement accès au contenu médical.
Cette approche complète l’HDS, le RGPD, le Zero Trust et l’interopérabilité. Elle ne remplace pas une stratégie de sécurité complète, mais elle renforce fortement la confidentialité des dossiers médicaux numériques.
Une donnée médicale chiffrée au repos n’est pas nécessairement protégée de bout en bout. Si elle est lisible côté serveur, l’infrastructure reste un point de confiance important.
Le chiffrement côté client protège la donnée avant son arrivée dans le cloud. C’est ce déplacement du chiffrement qui change la donne.
Pour les applications e-santé, l’objectif n’est pas de refuser le cloud. Il est de l’utiliser sans exposer inutilement les dossiers médicaux numériques.
Le chiffrement côté client transforme le cloud médical en espace de stockage et de synchronisation, sans en faire le lieu où les dossiers médicaux sont lisibles par défaut.
Un cloud HDS peut être conforme et utile, mais la confidentialité des dossiers médicaux dépend aussi de l’endroit où les données sont chiffrées et de la manière dont les clés sont gérées.
Pour les dossiers médicaux numériques, la question centrale n’est pas seulement “où sont stockées les données ?”, mais “qui peut réellement les lire ?”
Le cloud peut être comparé à un coffre externalisé. Le chiffrement serveur revient à confier le coffre et parfois la clé au même environnement. Le chiffrement côté client consiste à fermer l’enveloppe avant de la déposer dans le coffre.
Le cloud peut transporter et conserver l’enveloppe, mais il ne peut pas lire son contenu sans les clés des personnes autorisées.
Une architecture cloud santé chiffrée côté client combine chiffrement local des documents, gestion fine des clés, enveloppes cryptographiques par destinataire, contrôle d’accès contextuel, journalisation sans données sensibles, stockage cloud HDS, séparation des environnements, procédures de récupération et trajectoire post-quantique.
L’objectif est de réduire la surface d’exposition du serveur applicatif et du stockage cloud, tout en conservant les bénéfices opérationnels du cloud : disponibilité, sauvegarde, synchronisation, partage et archivage.
Agence du Numérique en Santé — Certification HDS
Agence du Numérique en Santé — Référentiels de certification HDS
Ministère de l’Économie — Nouveau référentiel HDS
ANSSI / CERT-FR — État de la menace informatique dans le secteur de la santé