Après une nuit agitée, vous téléchargez une app de suivi du sommeil, connectez votre objet connecté et touchez « Autoriser » sur une série d’écrans d’autorisation. Le lendemain matin, vous découvrez un tableau de bord soigné qui présente vos phases de sommeil, l’évolution de votre fréquence cardiaque et des indications sur votre récupération. Ce que vous ne voyez peut-être pas, c’est le chemin qui se cache derrière ce tableau de bord : quelles informations restent sur votre téléphone, quelles données parviennent aux serveurs de l’app et si des partenaires externes d’analyse ou de publicité peuvent les recevoir.
Cette incertitude est au cœur de la question de la confidentialité des données de santé. Un portail hospitalier et une app de bien-être autonome peuvent tous deux afficher la fréquence cardiaque ou des symptômes, mais ils peuvent relever de lois, de contrats, de systèmes techniques et de modèles économiques différents. Ce guide explique ces différents niveaux en termes simples, pour que vous sachiez distinguer une véritable protection de la vie privée d’une formule rassurante dans la fiche d’une app.
Pourquoi la confidentialité des données de santé compte plus que vous ne le pensez
Une app de sommeil peut transformer des mesures ordinaires en un profil intime. La variabilité de la fréquence cardiaque peut suggérer un état de stress ou de récupération. Des réveils nocturnes répétés peuvent révéler une insomnie. Des notes sur vos symptômes peuvent dévoiler une maladie chronique, un traitement régulier, une préoccupation liée à la santé reproductive ou des difficultés de santé mentale. Ces informations deviennent encore plus sensibles lorsqu’une app les combine avec votre localisation, les identifiants de votre appareil, votre âge, votre navigation ou vos habitudes d’achat.
Ce circuit peut être difficile à percevoir. Un objet connecté enregistre un signal, le téléphone l’importe, l’app l’analyse, et des kits de développement logiciel peuvent envoyer des données d’utilisation ou de mesure à des services distants. Ces services peuvent servir aux rapports de plantage, à l’analyse d’usage, à la personnalisation, à la publicité ou à d’autres fonctions décrites dans une politique de confidentialité. Vous avez peut-être approuvé la connexion initiale sans vous rendre compte que ce sont les partenaires commerciaux de l’app, et non l’interface de l’app elle-même, qui déterminent où vont certaines informations.
Pourquoi ces informations sont particulièrement difficiles à remplacer
Un mot de passe peut être changé après une fuite. Un historique du rythme cardiaque, une chronologie de symptômes ou un dossier de santé reproductive ne se remplacent pas aussi facilement. Même lorsqu’un jeu de données ne comporte pas votre nom, la combinaison d’horodatages, de lieux, de caractéristiques de l’appareil et de comportements peut permettre de reconnaître une personne.
L’ampleur de l’exposition explique pourquoi l’architecture compte. Une revue évaluée par des pairs a recensé 2 216 violations de données dans le secteur de la santé dans 65 pays en 2018 et indiqué que 249,09 millions de personnes avaient été touchées entre 2005 et 2019, dont 157,40 millions au cours des cinq dernières années de cette période. La même revue a relevé 3 912 incidents de violation de données dans le secteur de la santé dans son jeu de données plus large couvrant 2005 à 2019. Ces chiffres proviennent de la revue évaluée par des pairs sur les violations de données de santé.
Règle pratique : considérez un flux de fréquence cardiaque, un journal de symptômes ou un historique de sommeil comme sensibles, même lorsqu’une app se présente comme une app de « bien-être ».
La frontière de confidentialité que beaucoup d’utilisateurs ne voient pas
Les règles traditionnelles de confidentialité dans le domaine de la santé peuvent protéger les informations détenues par un hôpital, une clinique, un assureur ou leurs prestataires sous contrat. Elles ne suivent pas automatiquement les données lorsque vous les copiez dans une app grand public, connectez un objet connecté ou exportez un rapport vers un autre service.
Cette distinction ne signifie pas que toutes les apps grand public sont dangereuses. Elle signifie que vous devez poser des questions plus précises : Qui reçoit les données ? Où sont-elles traitées ? Les informations brutes sont-elles stockées ? Pouvez-vous les supprimer ? L’app utilise-t-elle des outils d’analyse tiers ? Une fois que vous pouvez répondre à ces questions, la confidentialité devient quelque chose que vous pouvez évaluer plutôt que supposer.
Comprendre les protections de la HIPAA et du RGPD
La HIPAA établit un socle important aux États-Unis, mais ce n’est pas une étiquette universelle apposée sur chaque produit lié à la santé. On fait souvent remonter l’ère moderne de la confidentialité à l’adoption de la HIPAA, le 21 août 1996. La Privacy Rule a été publiée en décembre 2000, est entrée en vigueur le 14 avril 2001, et la plupart des prestataires de soins et des régimes d’assurance santé concernés devaient s’y conformer en avril 2003, selon la chronologie de la HIPAA publiée par les CDC.
La HIPAA s’applique généralement aux entités couvertes, comme les hôpitaux, les cliniques, les régimes d’assurance santé et les chambres de compensation du secteur de la santé, ainsi qu’aux partenaires commerciaux (business associates) qui traitent des informations protégées pour leur compte. Un portail patient rattaché à un hôpital peut donc être soumis aux obligations de la HIPAA. Une app autonome de méditation, de forme physique ou de suivi des symptômes peut ne pas l’être, même si elle collecte des informations qui semblent indéniablement médicales.
Ce qu’il faut repérer dans le vocabulaire d’une app
La mention « conforme à la HIPAA » doit susciter une question concrète, et non clore la discussion. Si une app travaille pour un organisme de santé couvert, demandez si cette relation est encadrée par un Business Associate Agreement, un contrat qui fixe les responsabilités en matière de traitement des informations de santé protégées. Des expressions comme « alignée sur la HIPAA » ou « prête pour la HIPAA » peuvent décrire une démarche de conception, mais elles ne suffisent pas à établir une couverture juridique.
Le RGPD fonctionne différemment. Il peut s’appliquer lorsqu’un organisme traite des données personnelles liées à des personnes se trouvant dans l’Espace économique européen, selon les circonstances. Les informations de santé y sont considérées comme une catégorie particulière de données personnelles, qui bénéficie d’une protection renforcée et exige une base juridique et une condition de traitement applicables. Le RGPD peut aussi conférer des droits comme l’accès, l’effacement et la portabilité des données, même si ces droits peuvent avoir des limites.
| Aspect | HIPAA (États-Unis) | RGPD (UE/EEE) |
|---|---|---|
| Champ d’application principal | Entités de santé couvertes et leurs partenaires commerciaux | Organismes traitant les données personnelles des personnes concernées dans les situations prévues |
| Informations de santé | Informations de santé protégées détenues par les entités couvertes et les partenaires concernés | Les données de santé sont une catégorie particulière qui exige une protection supplémentaire |
| Consentement | Les règles de confidentialité encadrent les utilisations et divulgations autorisées, le consentement intervenant dans certaines situations | Le consentement peut être une base juridique, mais les organismes peuvent s’appuyer sur d’autres fondements licites lorsque c’est permis |
| Contrôle par l’utilisateur | Les droits d’accès et de rectification s’appliquent dans le cadre de la HIPAA | Les droits d’accès, d’effacement, de portabilité et d’autres droits peuvent s’appliquer, dans certaines limites |
| Apps grand public | Souvent hors du champ de la HIPAA, sauf si elles sont liées à une entité couverte | Peuvent relever du RGPD lorsque ses règles territoriales et de traitement s’appliquent |
Une politique de confidentialité peut vous aider à comprendre la position d’une app, mais la conformité juridique n’est qu’un minimum. La conception technique détermine si les données brutes se trouvent sur un serveur, si des employés peuvent y accéder et si du code externe les reçoit. Vous pouvez consulter la politique de confidentialité de Cardiogram comme exemple du niveau de détail sur l’architecture et le traitement des données que les utilisateurs devraient rechercher.
Comment fonctionnent les modèles techniques de confidentialité
L’architecture de confidentialité détermine la quantité d’informations qui doit quitter votre appareil. Prenons deux apps de santé qui calculent l’évolution de la fréquence cardiaque au repos. L’une envoie les mesures brutes à un serveur pour analyse. L’autre calcule la tendance sur le téléphone et conserve le résultat localement ou dans une sauvegarde personnelle protégée. Les écrans peuvent se ressembler, mais les données transitent par des systèmes différents et créent des risques d’exposition différents.
Le lieu du traitement change le risque
Le traitement sur l’appareil garde les données des capteurs dans le téléphone lui-même. Le téléphone lit le signal, effectue le calcul et affiche le résultat sans envoyer les données brutes au serveur d’une entreprise. Cela réduit le nombre de systèmes qui reçoivent et doivent protéger les données d’origine. Cela n’élimine pas tous les risques. Un appareil compromis, une capture d’écran, un export ou une intégration connectée peuvent toujours exposer les informations.
Apple indique que les données de Santé et de HealthKit sont chiffrées sur l’appareil et accessibles uniquement lorsque celui-ci est déverrouillé avec un code, Touch ID ou Face ID. Avec l’authentification à deux facteurs et une version d’iOS compatible, les données de Santé synchronisées via iCloud bénéficient d’un chiffrement de bout en bout, ce qui signifie qu’Apple ne peut pas les lire, comme l’explique la documentation d’Apple sur la sécurité des données de Santé.
Les autorisations constituent un autre filtre. Les frameworks de données de santé peuvent permettre à une app de demander des catégories précises, comme les pas ou la fréquence cardiaque, tout en distinguant l’accès en lecture de l’accès en écriture. Confrontez chaque demande à l’objectif annoncé de l’app. Un outil qui analyse la fréquence cardiaque peut avoir besoin des mesures, mais il ne devrait pas recevoir automatiquement vos contacts, un historique de localisation sans rapport ou l’autorisation de modifier votre dossier de santé.
Le chiffrement protège à différents moments
Le chiffrement en transit protège les informations pendant qu’elles circulent sur un réseau. Il peut empêcher des tiers de lire la transmission, mais le service destinataire peut toujours être en mesure d’ouvrir et de traiter les données. Le chiffrement au repos protège les informations stockées sur un appareil ou un serveur, un peu comme un coffre-fort protège son contenu une fois livré.
Le chiffrement de bout en bout va plus loin. L’expéditeur chiffre les informations, l’appareil de l’utilisateur prévu détient la capacité de les déchiffrer, et le fournisseur du service ne peut pas en examiner le contenu. Cela limite ce que le fournisseur peut faire des données. La conception de la récupération de compte et des sauvegardes reste importante, car elle peut influer sur qui y a finalement accès.
Apple précise également que certains indicateurs de Santé, notamment les Tendances, les Faits marquants, la fréquence cardiaque au repos et les prévisions du Suivi du cycle, sont calculés sur l’appareil. Son livre blanc sur la confidentialité de Santé illustre la différence entre garder les signaux bruts en local et les envoyer à un service cloud pour qu’il en tire des conclusions.
Test d’architecture : demandez-vous si le fournisseur a besoin de vos données brutes pour proposer la fonctionnalité. Si ce n’est pas le cas, le traitement local et une collecte minimale réduisent généralement la surface d’exposition.
La confidentialité différentielle peut ajouter une couche supplémentaire en introduisant un bruit contrôlé dans les résultats agrégés. Les organismes peuvent ainsi étudier des tendances générales sans publier de données individuelles. Ce n’est pas une gomme magique. La mise en œuvre, les paramètres, les contrôles d’accès et la durée de conservation déterminent toujours le résultat concret.
Cherchez des preuves plutôt que des adjectifs. Des audits de sécurité indépendants, des tests d’intrusion, une documentation technique claire et des composants open source vérifiables inspirent davantage confiance qu’une simple mention de sécurité « de niveau militaire ».
Traitement sur l’appareil ou synchronisation dans le cloud
Le traitement local garde les mesures dans le téléphone. La synchronisation dans le cloud les transmet à l’infrastructure d’un fournisseur. Les deux approches peuvent offrir des fonctionnalités de santé utiles, mais elles créent des risques différents pour la confidentialité des mesures de fréquence cardiaque, des notes sur les symptômes et des données des objets connectés.
Le trajet des données compte davantage que l’étiquette. Une app peut calculer un résultat sur l’appareil, copier des données via un service de sauvegarde personnel ou téléverser des informations brutes sur ses propres serveurs. Chaque trajet change qui peut stocker les données, les récupérer, les analyser ou répondre à une demande d’assistance.
Le modèle local
Le traitement local peut convenir aux informations que vous ne voulez pas confier à l’éditeur d’une app, comme la variabilité de la fréquence cardiaque, des données de sommeil détaillées ou des notes sur vos symptômes. Le téléphone peut calculer une tendance sans envoyer les mesures sous-jacentes à un système distant. Cela peut limiter les bases de données sur serveur, les chaînes d’analyse et l’accès des employés, et la fonctionnalité peut continuer à fonctionner sans connexion permanente.
La contrepartie, c’est la continuité. Si l’appareil tombe en panne et qu’aucune sauvegarde protégée n’existe, les informations stockées localement peuvent être difficiles, voire impossibles, à récupérer. Les apps locales peuvent aussi offrir un accès limité d’un appareil à l’autre. Vous devrez peut-être gérer vous-même un export avant de partager un rapport avec un médecin.
Un réglage d’autorisation ne prouve pas à lui seul que le traitement reste local. Vérifiez si l’app reçoit seulement un résultat, comme une tendance, ou si elle téléverse aussi les mesures brutes utilisées pour l’obtenir. La différence pour votre vie privée revient à remettre un calcul terminé plutôt que toutes vos feuilles de brouillon.
Le modèle cloud
La synchronisation dans le cloud facilite la récupération et l’accès. Vous pouvez restaurer un historique après avoir changé de téléphone, utiliser plusieurs appareils et conserver une sauvegarde sans exporter de fichiers manuellement. Ces commodités multiplient les endroits à protéger : serveurs d’application, systèmes de sauvegarde, journaux, outils d’assistance et intégrations.
La question pratique est de savoir à qui appartient le cloud qui stocke les informations. Vérifiez quel chiffrement s’applique, qui contrôle les clés et si le fournisseur peut lire le contenu. Une sauvegarde cloud personnelle chiffrée de bout en bout suit un chemin différent, du point de vue de la confidentialité, d’un stockage tiers où l’éditeur de l’app conserve des copies lisibles. Un objet connecté peut envoyer la fréquence cardiaque au téléphone, le téléphone peut synchroniser certaines données vers un compte personnel, et l’app peut, de son côté, téléverser les symptômes sur ses propres serveurs.
Les protections de confidentialité qui s’appliquent aux professionnels de santé ne suivent pas automatiquement les données des consommateurs dans chaque app. Un service rattaché à un hôpital peut traiter les données dans le cadre d’une relation réglementée, tandis qu’une app de bien-être indépendante peut fonctionner selon sa propre politique. Examinez le trajet des données et l’organisme responsable au lieu de supposer que toutes les données liées à la santé bénéficient de la même protection.
| Question | Conception sur l’appareil | Conception avec synchronisation cloud |
|---|---|---|
| Emplacement des données brutes | Restent principalement sur l’appareil | Peuvent être transmises à l’infrastructure du fournisseur |
| Récupération | Dépend de l’appareil et des sauvegardes disponibles | Permet généralement une restauration à partir du compte |
| Surface d’exposition | Empreinte réduite côté serveur | Davantage de systèmes et d’intégrations à protéger |
| Utilisation sur plusieurs appareils | Parfois limitée | Généralement plus pratique |
| Complexité de la suppression | Concerne l’appareil et les sauvegardes personnelles | Doit tenir compte des serveurs, des sauvegardes, des exports et des partenaires |
Aucun des deux modèles n’est sûr par défaut. Une app locale peut exposer des données par des autorisations excessives ou des exports non sécurisés. Une app cloud peut protéger les informations par des contrôles d’accès stricts et un chiffrement de bout en bout, tout en conservant davantage de copies et en créant plus de points d’accès. Adaptez l’architecture à la sensibilité des données et à l’objectif de la fonctionnalité. Cette présentation des solutions de santé numérique apporte un éclairage complémentaire sur la manière dont la conception logicielle influe sur les parcours de santé.
Évaluer les promesses de confidentialité des apps de santé
Lisez les promesses de confidentialité comme si vous inspectiez le trajet des données, et non comme un texte marketing. Avant de saisir des symptômes ou de connecter un objet connecté, passez en revue les questions ci-dessous.
Commencez par la relation juridique
Identifiez l’entité juridique du développeur et déterminez si l’app est liée à un hôpital, une clinique, un assureur ou un autre organisme de santé couvert. Si l’app affirme être couverte par la HIPAA, cherchez une explication de la relation couverte et des responsabilités de partenaire commercial correspondantes. Si elle ne le revendique pas, partez du principe que la HIPAA ne régit peut-être pas le service proposé au grand public, sauf si le développeur explique le contraire.
Il ne s’agit pas d’un jugement sur la qualité. Cela vous indique quelles protections vous pouvez attendre de la loi et lesquelles doivent venir de la politique et de l’architecture propres à l’app.
Lisez attentivement la section sur le partage
Recherchez des termes comme analyse, publicité, partenaires, courtiers en données, prestataires de services, recherche et données anonymisées. La formule « partenaires de confiance » est moins utile qu’une catégorie nommée, un objectif déclaré et une explication claire des champs qui quittent l’app.
Soyez attentif aux combinaisons. Une app peut affirmer ne pas vendre de données de santé tout en permettant à un tiers de recevoir des identifiants, des données d’événements ou des informations sur l’appareil à des fins publicitaires ou de mesure d’audience. Ces détails peuvent compter même lorsque la politique évite le mot « vendre ».
Comparez les autorisations à la fonctionnalité
Une demande d’autorisation doit avoir un lien clair avec la fonction de l’app. Une app de méditation qui demande l’accès à vos contacts mérite un examen attentif. Une app de suivi des règles qui demande un accès à la localisation sans rapport doit s’en expliquer. Un outil d’analyse de la fréquence cardiaque qui demande un accès en lecture seule à la fréquence cardiaque est plus facile à justifier qu’un outil qui demande un large accès en écriture à l’ensemble de votre dossier de santé.
Utilisez les réglages d’autorisation du système d’exploitation pour refuser les catégories dont la fonctionnalité n’a pas besoin. Revérifiez ces autorisations après les mises à jour, car les accès demandés par une app peuvent changer.
Vérifiez la promesse par vous-même
Avant de vous fier à une app, vérifiez si elle propose :
- L’export des données : pouvez-vous obtenir une copie exploitable de vos données sans contacter l’assistance ?
- La suppression du compte : la procédure explique-t-elle ce qu’il advient des données actives, des sauvegardes, des journaux et des informations conservées pour des raisons légales ?
- Le contrôle du consentement : pouvez-vous révoquer une autorisation sans perdre des fonctionnalités qui n’ont rien à voir ?
- Le détail du traitement : le centre d’aide indique-t-il si l’analyse a lieu sur l’appareil ou sur des serveurs distants ?
- Des preuves de sécurité : le développeur décrit-il les audits, les tests d’intrusion, le chiffrement et les contrôles d’accès avec suffisamment de détails pour que vous puissiez les évaluer ?
Un signal d’alerte utile : les références vagues à des « prestataires de services » ne sont pas forcément abusives, mais elles doivent vous amener à demander ce que reçoivent ces prestataires, pourquoi ils le reçoivent et combien de temps ils le conservent.
Une app conçue pour protéger la vie privée dès la conception limite généralement la collecte par défaut, sépare les autorisations, évite les logiciels tiers inutiles et explique le cycle de vie de ses données. Ces choix ne garantissent pas une protection parfaite, mais ils constituent une preuve plus solide qu’un badge ou un slogan.
Construire votre propre cadre de confidentialité
La confidentialité des données de santé n’est pas une question de tout ou rien. C’est une série de décisions fondées sur la sensibilité des informations, l’intérêt de la fonctionnalité et les conséquences si les données devenaient accessibles à quelqu’un d’autre.
Commencez par les données très sensibles, comme des notes détaillées sur votre santé mentale, des informations sur votre santé reproductive ou des données liées à une maladie chronique. Privilégiez l’analyse sur l’appareil, l’accès en lecture seule lorsque c’est possible, des exports limités et aucune copie cloud inutile. Si vous utilisez la synchronisation, vérifiez le modèle de chiffrement et sachez qui contrôle les clés de déchiffrement.
Les données moyennement sensibles peuvent inclure le suivi du sommeil, l’historique d’exercice et les indicateurs généraux de forme physique. Une synchronisation cloud chiffrée peut être un choix raisonnable lorsque la récupération et l’accès sur plusieurs appareils comptent, mais lisez la politique de partage du fournisseur et supprimez les anciennes intégrations que vous n’utilisez plus.
Pour les données de bien-être moins sensibles, la commodité peut raisonnablement peser davantage. Même dans ce cas, n’accordez que les autorisations nécessaires à la fonctionnalité, protégez votre téléphone par un code robuste et évitez de saisir des informations permettant de vous identifier lorsque l’app n’en a pas besoin.
Superposez les protections
Appuyez-vous sur trois niveaux plutôt que sur une seule étiquette :
- Niveau réglementaire : déterminez si une relation de soins couverte ou une loi applicable sur la protection des données encadre le traitement.
- Niveau technique : vérifiez le chiffrement de l’appareil, les autorisations de l’app, le traitement local, le chiffrement de bout en bout et la conservation sur les serveurs.
- Niveau comportemental : contrôlez les autorisations, suivez les modifications de la politique, exportez les données importantes et demandez leur suppression lorsque c’est opportun.
Un modèle de menace personnel rend ces niveaux concrets. Une personne qui gère un diagnostic sensible peut privilégier la réduction du nombre de copies plutôt que la fluidité de l’accès. Une personne qui suit son activité générale peut accepter une sauvegarde chez un fournisseur réputé en échange de la continuité. Aucun de ces choix n’est le bon pour tout le monde.
Principe de décision : partagez les informations les moins sensibles qui permettent encore d’obtenir la fonctionnalité dont vous avez besoin, et réexaminez ce choix lorsque l’app, l’appareil, votre situation de santé ou la politique changent.
Si vous avez besoin de rapports structurés ou de résumés configurables, voyez dans ce guide de personnalisation des rapports comment la personnalisation influe sur les données collectées et exportées. Le même cadre s’applique : comprenez les données d’entrée, le lieu du traitement, les destinataires et les copies qui en résultent.
Idées reçues sur le consentement en matière de données de santé
Toucher « J’accepte » ne vous donne pas un contrôle permanent sur toutes les utilisations futures de vos informations. Dans les apps grand public, le consentement peut autoriser la collecte initiale, tandis que d’autres passages de la politique encadrent l’analyse d’usage, les prestataires de services, la recherche, la publicité ou des modifications ultérieures. Considérez le consentement comme le début d’un examen, et non comme un bouclier pour votre vie privée.
Supprimer une app ne revient pas non plus à supprimer les données. Retirer l’interface de votre téléphone peut laisser des données sur des serveurs, des sauvegardes synchronisées, des exports, des journaux ou des informations déjà partagées avec un autre organisme. Demandez au développeur ce que couvre la suppression et si les informations agrégées ou conservées pour des raisons légales suivent une procédure différente.
Le terme « anonyme » appelle la même prudence. Des données sans votre nom peuvent tout de même contenir des dates, des lieux, des caractéristiques de l’appareil et des schémas distinctifs qui rendent une réidentification possible lorsqu’on les croise avec un autre jeu de données. La confidentialité des données de santé dépend de l’ensemble du contexte, et pas seulement de la suppression d’un identifiant direct.
Le consentement n’est pas non plus la seule base juridique possible au sens du RGPD. Dans certaines situations, un organisme peut traiter des informations sur un autre fondement licite, notamment l’intérêt légitime, lorsque les conditions requises sont remplies. C’est pourquoi un écran d’autorisation ne peut pas tout vous dire.
Une meilleure habitude consiste à contrôler régulièrement les autorisations, les réglages de partage, les services connectés et les engagements de conservation. Des données partagées aujourd’hui peuvent rester disponibles, être copiées ou être réutilisées selon des conditions que vous n’avez pas personnellement relues.
Cardiogram analyse les données de fréquence cardiaque d’Apple Santé sur l’appareil grâce à un accès HealthKit en lecture seule, puis synchronise les données de l’app via l’écosystème iCloud de l’utilisateur au lieu de gérer des comptes utilisateurs côté serveur. Si cette architecture vous convient, rendez-vous sur Cardiogram pour découvrir comment l’app transforme l’évolution de votre fréquence cardiaque, vos symptômes et vos tendances en résumés prêts à être remis à votre médecin, tout en gardant les questions de confidentialité bien visibles.
