Maya a 28 ans et cherche à savoir si ses épisodes de vertiges pourraient être liés à un POTS. Après un épisode, elle fait défiler le graphique de fréquence cardiaque de son Apple Watch et voit 142 bpm, puis 58 bpm, puis de nouveau 131 bpm. Les chiffres sont réels, mais ils ne répondent pas aux questions qu’elle doit aborder avec un cardiologue : la hausse était-elle liée au passage en position debout ? Combien de temps a-t-elle duré ? Faisait-elle de l’exercice, récupérait-elle, était-elle déshydratée ou dormait-elle juste avant ?
Ce décalage est au cœur de l’intégration avec Apple Santé. Les appareils Apple peuvent recueillir une grande quantité d’informations biométriques, mais les mesures brutes parlent rarement d’elles-mêmes. Un suivi utile nécessite une deuxième couche qui ajoute le moment, le contexte, la détection de tendances et un format qu’une autre personne peut examiner.
Ce que signifie vraiment l’intégration avec Apple Santé
L’intégration avec Apple Santé n’est ni un simple interrupteur ni une fonction isolée. Elle désigne les connexions techniques, soumises à autorisation, qui permettent aux applications approuvées de lire, et dans certains cas d’écrire, dans la base de données sous-jacente de l’app Santé. Cet écosystème comprend l’app Santé sur iPhone, le framework HealthKit, les capteurs de l’iPhone et de l’Apple Watch, ainsi que les applications tierces qui demandent un accès précis.
Apple a présenté HealthKit lors de la WWDC du 2 juin 2014, puis a lancé publiquement l’app Santé avec iOS 8 le 17 septembre 2014. Apple a ensuite décrit l’app Santé et l’Apple Watch, sortie en 2015, comme les éléments d’une plateforme plus large qui n’a cessé de s’étendre sur l’iPhone, l’iPad, l’Apple Watch et les applications compatibles, dans son Health Report. Cet historique compte, car les développeurs ne se connectent pas à une expérience toute neuve : ils s’appuient sur une couche de données de santé établie de longue date.
Pour Maya, la distinction importante est simple :
- L’Apple Watch enregistre ou fournit des mesures.
- HealthKit organise ces mesures de façon sécurisée sur l’appareil.
- L’app Santé lui offre un endroit où consulter les sources et gérer les autorisations.
- Une application spécialisée peut interpréter certains relevés et les transformer en épisodes, en tendances ou en rapports.
L’app Santé peut montrer que sa fréquence cardiaque a changé. Une application d’analyse peut se demander si ces changements forment une tendance significative.
Les mesures brutes ne sont qu’un point de départ
Une valeur de fréquence cardiaque n’a de sens qu’avec les détails qui l’entourent. L’heure de la mesure, le fait que la personne bougeait ou non, la valeur de référence précédente, la durée de l’élévation et les symptômes associés peuvent changer la façon de l’interpréter.
Cela ne signifie pas qu’une application peut diagnostiquer une maladie à partir d’un graphique. Cela signifie que l’intégration peut réduire le travail manuel nécessaire pour reconstituer un historique cohérent. Au lieu de demander à Maya de se souvenir de chaque épisode, une application en lecture seule peut examiner les mesures HealthKit autorisées, repérer des tendances et lui présenter les résultats.
Règle pratique : Apple Santé conserve les preuves. Une application responsable doit expliquer la tendance sans prétendre que cette tendance est un diagnostic.
Comment HealthKit et l’app Santé fonctionnent ensemble
Imaginez le système comme une bibliothèque. L’app Santé est l’accueil, où vous consultez votre compte, examinez les sources et décidez à quelles informations une application peut accéder. HealthKit, ce sont les rayonnages et le catalogue en coulisses : le framework qui stocke et structure les mesures de santé provenant des applications et appareils approuvés.
Cette analogie aide à séparer deux choses que l’on confond souvent. Ouvrir l’app Santé ne signifie pas que toutes les autres applications peuvent voir tout ce qui y est affiché. Chaque application doit demander des types de données précis, et iOS présente ces demandes à l’utilisateur, qui les accepte ou les refuse.
Le modèle de données derrière les graphiques
HealthKit ne traite pas la fréquence cardiaque comme une seule courbe indifférenciée. Il stocke des mesures typées, comme la fréquence cardiaque, le nombre de pas, l’analyse du sommeil ou les données d’entraînement. Une mesure peut comporter une heure de début, une heure de fin, un appareil source et des métadonnées supplémentaires.
Cette structure permet à une application de poser des questions ciblées. Elle peut demander les mesures de fréquence cardiaque sur une période donnée, identifier l’appareil qui les a enregistrées ou les comparer aux intervalles d’entraînement. L’application n’obtient pas le droit de fouiller tout le coffre simplement parce qu’elle a été autorisée à lire une catégorie.
L’autorisation fait partie de l’architecture
Apple indique que les données HealthKit sont stockées sur l’appareil et chiffrées, de sorte que seuls le code d’accès, Touch ID ou Face ID de l’utilisateur permettent d’y accéder. Apple précise aussi que les indicateurs de l’app Santé sont calculés entièrement sur l’appareil à partir des capteurs de l’Apple Watch et de l’iPhone, comme le détaille son livre blanc sur la confidentialité dans Santé.
Une application nécessite donc deux types de décisions d’autorisation. D’abord, elle doit déclarer les catégories de données qu’elle souhaite utiliser. Ensuite, l’utilisateur décide lesquelles autoriser parmi celles demandées. Ces décisions peuvent être revues ou retirées plus tard dans les réglages de Santé.
Lecture et écriture sont deux autorisations distinctes
L’accès en lecture permet à une application d’examiner certaines mesures existantes. L’accès en écriture lui permet d’ajouter des mesures autorisées dans HealthKit. Une application peut demander l’un, l’autre ou les deux.
Cette distinction devient importante quand on évalue la confiance à accorder. Une application de suivi qui a seulement besoin des relevés de fréquence cardiaque existants n’a pas besoin d’un accès en écriture pour les analyser. Plus la demande est restreinte, plus il est facile pour l’utilisateur de comprendre ce que l’application peut faire.
Quelles données les applications peuvent lire et pourquoi la lecture seule compte
HealthKit peut donner accès à de nombreuses catégories d’informations de santé, mais leur disponibilité dépend de l’appareil, de la source, des autorisations de l’utilisateur et de la façon dont l’application demande l’accès. Une application de suivi de la fréquence cardiaque peut demander la fréquence cardiaque, la variabilité de la fréquence cardiaque, la fréquence cardiaque au repos, les entraînements ou les ECG compatibles. Une autre peut se concentrer sur le sommeil, les pas, la fréquence respiratoire, l’oxygène sanguin ou les dossiers médicaux, lorsque ceux-ci sont disponibles.
Les autorisations sont granulaires. Vous pouvez autoriser une application à lire la fréquence cardiaque tout en lui refusant les données de sommeil, et elle ne peut pas consulter une catégorie que vous n’avez pas approuvée. Le même principe s’applique à l’écriture : une application qui peut écrire un type de relevé n’obtient pas automatiquement le droit d’écrire tous les autres.
| Type de données | Lecture | Écriture |
|---|---|---|
| Fréquence cardiaque | Oui | Possible avec autorisation |
| Variabilité de la fréquence cardiaque | Oui | Possible avec autorisation |
| Fréquence cardiaque au repos | Oui | Possible avec autorisation |
| Enregistrements ECG | Si pris en charge et autorisé | Limitée par le type de données et les capacités de l’application |
| Oxygène sanguin | Si pris en charge et autorisé | Possible uniquement si HealthKit autorise ce type |
| Analyse et phases du sommeil | Oui, si disponible | Possible avec autorisation |
| Pas | Oui | Possible avec autorisation |
| Entraînements | Oui | Possible avec autorisation |
| Fréquence respiratoire | Oui, si disponible | Possible avec autorisation |
| Dossiers médicaux | Si disponible et autorisé | Dépend du type de dossier et de la prise en charge par le framework |
Pourquoi un accès restreint renforce la confiance
La conception en lecture seule crée une limite claire. Une application en lecture seule peut analyser les relevés existants, mais elle ne peut pas ajouter de mesures pour qu’un tableau de bord paraisse plus complet, ni modifier un journal pour qu’il colle à une interprétation. Elle ne peut pas non plus enregistrer une affection que l’utilisateur n’a jamais saisie.
Cette limite compte pour le suivi du POTS et de la dysautonomie, car la qualité de la conclusion dépend de l’intégrité de la chronologie sous-jacente. Si une application modifie les données sources, un examen ultérieur devient moins fiable. Un fonctionnement en lecture seule conserve le relevé d’origine dans Apple Santé et place l’interprétation dans une couche séparée.
Une question utile : l’application a-t-elle besoin d’écrire quoi que ce soit, ou seulement de comprendre ce qu’Apple Santé contient déjà ?
La lecture seule ne rend pas une application automatiquement précise ou cliniquement adaptée. Elle rend en revanche le flux de données plus facile à expliquer. L’application lit les mesures approuvées, effectue l’analyse annoncée et laisse l’utilisateur décider de la suite.
Configurer l’intégration avec Apple Santé étape par étape
La configuration commence lorsqu’une application comme Cardiogram demande l’accès à Apple Santé. La fenêtre d’autorisation du système liste les catégories que l’application souhaite lire ou écrire. N’acceptez pas la demande machinalement : examinez chaque catégorie et n’accordez que ce qui correspond à la finalité de l’application.
Commencez par la fenêtre d’autorisation du système
Pour l’analyse des tendances de fréquence cardiaque, les demandes pertinentes peuvent inclure :
- La fréquence cardiaque, qui fournit les mesures enregistrées en battements par minute.
- La variabilité de la fréquence cardiaque, qui peut apporter un signal supplémentaire pour l’analyse des tendances.
- La fréquence cardiaque au repos, qui aide à établir une valeur de référence personnelle.
- Les entraînements, qui fournissent le contexte permettant de distinguer les élévations liées à l’exercice des autres événements.
L’application ne peut utiliser que les catégories que vous approuvez. Si vous refusez l’accès au sommeil ou aux entraînements, son analyse ne disposera pas de ces informations de contexte.
Vérifiez les accès après la configuration
Vous pouvez revoir les autorisations dans Réglages > Confidentialité et sécurité > Santé. L’écran de l’application et l’écran des réglages d’iOS n’ont pas le même rôle : la fenêtre système initiale accorde l’accès, tandis que les réglages vous permettent de vérifier ou de modifier cette décision par la suite.
Activez l’actualisation en arrière-plan si l’application dépend de mises à jour en arrière-plan, et autorisez les notifications si vous souhaitez être alerté lorsque l’application repère un événement pertinent. Ces réglages ne transforment pas HealthKit en flux continu en direct, mais ils peuvent aider l’application à traiter les nouvelles informations quand le système d’exploitation le permet.
Pour une démarche plus détaillée de préparation des relevés en vue d’un examen, consultez ce guide sur l’exportation des données d’Apple Santé.
Résoudre l’absence de relevés
Si aucune donnée n’apparaît, vérifiez la source avant de conclure que l’intégration a échoué :
- Confirmez la connexion de la montre. Assurez-vous que l’Apple Watch est jumelée avec le bon iPhone.
- Vérifiez la détection du poignet. La collecte des capteurs peut être perturbée si la montre n’est pas portée ou si la détection du poignet est désactivée.
- Examinez les sources dans Santé. Ouvrez l’indicateur concerné dans l’app Santé et vérifiez quelles sources fournissent des relevés.
- Revérifiez les autorisations. Une application peut avoir accès à la fréquence cardiaque, mais pas aux entraînements ni à la VFC.
- Laissez le temps au traitement. La transmission en arrière-plan peut être différée ; une application peut donc ne pas réagir immédiatement à une nouvelle mesure.
Un exemple concret pour le POTS et la dysautonomie
Prenons une application en lecture seule qui analyse les relevés de fréquence cardiaque d’une personne ayant des vertiges après s’être levée. Apple Santé fournit les mesures sous-jacentes. Le rôle de l’application est d’organiser ces mesures en une chronologie qui répond à des questions plus utiles que « Quelle était ma fréquence cardiaque ? ».
Un fonctionnement centré sur la pathologie peut examiner une valeur de référence, rechercher une hausse importante sur un court intervalle et enregistrer le pic et la durée de maintien. Cardiogram décrit une détection automatique des hausses de 30 bpm ou plus en 5 minutes, avec le moment de l’épisode, la valeur de référence, le pic et la durée enregistrés pour examen. Ce critère est une règle de repérage et de suivi, pas un diagnostic, et un médecin doit l’interpréter en tenant compte des symptômes et des autres informations médicales.
Le contexte distingue les tendances du bruit
Une valeur élevée pendant un entraînement ne doit pas être traitée comme une hausse survenue debout dans la cuisine. Les entraînements et les périodes de récupération peuvent donc être exclus du décompte des épisodes, ce qui réduit une source fréquente d’alertes trompeuses.
Le sommeil, les symptômes, l’hydratation, la consommation de sel, les médicaments et le contexte d’activité peuvent ajouter une couche supplémentaire. Une personne peut noter des vertiges ou des palpitations autour d’un épisode, puis vérifier si des événements similaires surviennent après une mauvaise nuit ou à certains moments de la journée. Le résultat n’est pas une conclusion médicale, mais un ensemble d’observations mieux organisé pour échanger avec un médecin.
Pour comprendre comment des relevés bruts peuvent devenir des tendances au long cours, consultez ce guide sur l’analyse des tendances de santé.
Le traitement sur l’appareil change la donne
Apple indique que les données HealthKit restent protégées sur l’appareil, et les applications peuvent être conçues pour lire des résumés locaux sans exiger d’accès côté serveur aux historiques de santé bruts. Dans un modèle sur l’appareil, l’application analyse localement les mesures autorisées et se synchronise via l’environnement iCloud de l’utilisateur, plutôt que d’envoyer les relevés bruts aux serveurs de l’éditeur.
Le résultat peut être un résumé hebdomadaire, une carte de chaleur des moments où surviennent les épisodes ou un PDF qui indique le critère de détection et résume les épisodes, les symptômes et les tendances. Ce format répond au problème concret de Maya au départ. Son médecin n’a pas besoin de faire défiler longuement des points de graphique sans lien entre eux. Il a besoin d’un relevé concis qui montre ce qui s’est passé, quand, et dans quel contexte selon la patiente.
Les limites actuelles de l’intégration avec Apple Santé
L’intégration avec Apple Santé peut relier des sources de données sans pour autant les mettre d’accord. Apple Santé est souvent considéré comme un dossier unifié, mais les relevés peuvent encore différer en termes de moment, de couverture, de métadonnées et de priorité des sources.
Des analyses indépendantes décrivent une limite importante : HealthKit n’harmonise pas les données entre les différentes marques d’objets connectés et ne fournit pas d’indicateurs intégrés de tendance ou de forme. Une personne qui utilise plusieurs appareils peut voir des relevés qui se chevauchent, des trous ou des mesures contradictoires. L’intégration peut techniquement fonctionner tout en laissant l’utilisateur décider quelle source doit guider une tendance.
Les données brutes ne deviennent pas des informations utiles par elles-mêmes
HealthKit fournit des mesures de santé structurées, pas une couche d’interprétation propre à une pathologie. Il n’identifie pas nativement un épisode orthostatique, n’explique pas pourquoi une hausse de fréquence cardiaque s’est produite et ne produit pas de résumé des symptômes du POTS prêt pour le médecin.
Ce travail revient à l’application qui lit les données. Si elle ne propose pas de filtrage adapté, de saisie du contexte ou de rapports, c’est à l’utilisateur de transformer un long historique en quelque chose que l’équipe soignante peut examiner.
Le téléphone reste la porte d’entrée concrète
Comme HealthKit repose sur un stockage local et une autorisation explicite, de nombreuses intégrations dépendent d’une application installée sur l’iPhone pour lire et mettre en forme les informations avant qu’un autre système puisse les utiliser. Cela protège le contrôle de l’utilisateur, mais peut rendre l’interopérabilité moins pratique.
La même tension apparaît lorsque l’on veut combiner des dossiers de santé entre écosystèmes. Des articles récents notent que la synchronisation entre écosystèmes progresse sur des marchés voisins, mais la disponibilité et les types de données pris en charge peuvent varier. La question utile n’est pas seulement de savoir si une application « s’intègre à Apple Santé ». Demandez-vous quels types de données elle lit, quelle part de l’historique elle importe, comment elle gère les doublons et quelle source est prioritaire.
Une confidentialité renforcée peut réduire le confort d’utilisation. Ce compromis n’est acceptable que si l’application rend l’exportation, l’examen et la gestion des autorisations clairs.
D’autres lacunes peuvent affecter l’interprétation. La VFC peut être indisponible ou irrégulière sur certains appareils, les phases de sommeil peuvent être fragmentées, et les informations sur les symptômes nécessitent souvent une saisie manuelle volontaire. Ces limites font perdre du temps au patient, surtout lorsqu’un médecin a besoin de contexte plutôt que d’un énième graphique sans annotation.
Bonnes pratiques pour les développeurs qui s’appuient sur HealthKit
Les développeurs HealthKit doivent considérer la transmission en arrière-plan comme un système de notification fondé sur des événements, et non comme un flux continu de fréquence cardiaque. Apple indique que la plupart des types de données watchOS ont une fréquence de transmission en arrière-plan limitée, tandis que certains types d’événements, notamment la fréquence cardiaque élevée, la fréquence cardiaque basse et le rythme irrégulier, peuvent être transmis immédiatement. Une conception fiable doit tenir compte du traitement par lots et des réveils intermittents de l’application.
Interrogez les changements, pas toute l’archive
Utilisez une requête d’observation avec enableBackgroundDelivery pour savoir que des données pertinentes ont peut-être changé, puis une requête ancrée pour ne récupérer que les mesures ajoutées depuis le dernier point de contrôle. Cela évite de retraiter sans cesse le même historique et rend l’état local de l’application plus facile à maîtriser.
Filtrez les entraînements et les périodes de récupération avant de calculer les tendances au repos. Sinon, les élévations liées à l’exercice peuvent fausser la valeur de référence dont dépend le détecteur d’épisodes.
Limitez le stockage et les autorisations au strict nécessaire
Regroupez les écritures via HKHealthStore.save lorsqu’une écriture est nécessaire. Si le produit se contente d’analyser des relevés existants, privilégiez une autorisation en lecture seule et évitez de demander des droits d’écriture qui ne répondent pas à un besoin clair de l’utilisateur.
Stockez les analyses dérivées sur l’appareil avec une couche de persistance locale appropriée, comme SwiftData ou Core Data. Avant d’afficher la demande d’autorisation du système, expliquez chaque catégorie demandée en termes simples. La justification des autorisations doit correspondre au code.
Enfin, faites en sorte que la déclaration de confidentialité corresponde à la réalité. Si l’application affirme que l’analyse se fait localement, l’implémentation et le flux de données doivent le confirmer. Une étiquette de confidentialité n’est pas un argument marketing : c’est un contrat avec l’utilisateur.
Choisir des intégrations dignes de confiance
Avant d’appuyer sur Autoriser, posez-vous quatre questions pratiques :
- Que peut lire et écrire l’application ? Un accès en lecture seule est plus restreint qu’un accès en lecture et écriture.
- Où le traitement est-il effectué ? L’analyse sur l’appareil limite les déplacements inutiles de données sensibles.
- L’explication sur la confidentialité correspond-elle à la fenêtre d’autorisation ? La description de l’application doit citer les mêmes catégories que celles qu’elle demande.
- Pouvez-vous exporter vos données et révoquer l’accès ? Vous devez pouvoir créer un rapport utile, modifier les autorisations et arrêter le partage sans difficulté.
Une intégration fiable avec Apple Santé demande le minimum d’autorisations, explique son objectif avant le consentement et sépare les relevés bruts de leur interprétation. Pour d’autres conseils sur l’évaluation des choix de stockage et d’autorisation, consultez ce guide sur la confidentialité des données de santé.
L’intégration la plus utile n’est pas celle qui recueille le plus d’informations. C’est celle qui transforme les données approuvées en un résultat transparent et vérifiable, tout en préservant le relevé d’origine et le contrôle de l’utilisateur.
Cardiogram lit les données de fréquence cardiaque autorisées d’Apple Santé en lecture seule, analyse les tendances sur l’appareil et organise les épisodes, les tendances, le contexte et des rapports prêts pour le médecin, pour les personnes qui suivent des symptômes de POTS ou de dysautonomie. Rendez-vous sur Cardiogram pour découvrir comment votre Apple Watch et Apple Santé peuvent devenir plus faciles à consulter et à partager.
