Tes données d'entraînement t'appartiennent — pourquoi ce n'est pas évident

En 2018, une fuite de données a touché 150 millions de comptes MyFitnessPal. La même année, la carte thermique mondiale de Strava a rendu visibles des schémas de déplacement autour de sites militaires. Plus tard, la FTC, l’autorité américaine de protection des consommateurs, a reproché à Flo Health d’avoir transmis des informations de santé sensibles à des fournisseurs d’analyses comme Facebook et Google malgré des promesses contraires.

Ces trois affaires sont très différentes. Elles mettent pourtant en évidence un point facilement oublié lorsque tu compares des applications d’entraînement :

Les fonctions d’une application ne sont pas les seules à compter. Il importe aussi de savoir de quelles données elle a besoin, où elles sont stockées et de quoi dépend ton accès.

Ce que les applications de fitness peuvent réellement recueillir à ton sujet

En janvier 2026, Surfshark a analysé les déclarations de confidentialité de 16 applications de fitness populaires dans l’App Store d’Apple.

En moyenne, ces applications déclaraient 12 des 35 types de données possibles. La plus gourmande en indiquait 24.

La formulation relative au partage compte davantage encore. Surfshark rapporte que 75 % des applications étudiées utilisent au moins un type de données à des fins de « suivi ». Apple entend notamment par là l’association de données issues de l’application avec celles d’autres entreprises à propos d’une personne ou d’un appareil, par exemple pour la publicité personnalisée, la mesure publicitaire ou les courtiers en données.

C’est plus précis que l’affirmation simplifiée « 75 % vendent tes données d’entraînement ».

L’analyse ne dit pas que toutes ces applications recueillent les mêmes données ni que chaque transmission poursuit le même but. Elle montre plutôt à quel point la minimisation des données varie au sein d’une même catégorie d’applications.

Selon le produit, les données traitées peuvent notamment comprendre :

• l’adresse e-mail et l’identifiant utilisateur ;
• l’identifiant de l’appareil ou publicitaire ;
• la position approximative ou précise ;
• les données d’entraînement et d’activité ;
• les mensurations ;
• la fréquence cardiaque ou d’autres données de capteurs ;
• les photos ;
• les achats et informations d’abonnement ;
• les données d’utilisation et de diagnostic.

Un simple carnet de musculation n’a nul besoin de toutes ces informations.

Trois affaires illustrent trois risques différents

Les problèmes de confidentialité deviennent vite abstraits. Les exemples suivants montrent que tous les risques ne se ressemblent pas.

MyFitnessPal : ce qui se trouve sur un serveur peut faire partie d’une fuite

En mars 2018, Under Armour a annoncé qu’une personne non autorisée avait obtenu les données d’environ 150 millions de comptes MyFitnessPal.

Selon l’entreprise, les informations concernées comprenaient notamment :

• les noms d’utilisateur ;
• les adresses e-mail ;
• les mots de passe hachés.

D’après Under Armour, les données de paiement et les numéros d’identification officiels n’étaient pas concernés.

L’idée n’est pas que tout stockage cloud serait automatiquement dangereux. Des serveurs exploités de manière professionnelle peuvent être très bien protégés.

La différence structurelle est ailleurs : les données centralisées constituent une cible commune.

Strava : même des données agrégées peuvent en révéler plus que prévu

La carte thermique mondiale de Strava visualisait les déplacements de nombreux utilisateurs. En 2018, il est devenu public qu’elle permettait également d’identifier des parcours de course et des schémas de déplacement autour d’installations militaires.

Le ministère américain de la Défense a ensuite restreint l’utilisation des fonctions de géolocalisation dans les zones d’opération.

Il ne s’agissait pas principalement d’un piratage.

Les données avaient été recueillies pour une fonction légitime. Le problème venait de ce qu’il était possible de déduire en combinant une multitude de points de localisation apparemment anodins.

Flo Health : les promesses de confidentialité doivent correspondre aux flux réels

La FTC a reproché à Flo Health d’avoir transmis des informations sensibles provenant de son application de suivi du cycle et de la fertilité à des fournisseurs d’analyses externes, alors que les utilisateurs avaient reçu une autre impression.

L’affaire a abouti en 2021 à une ordonnance contraignante de la FTC.

Cet exemple illustre un troisième type de risque : le vol de données n’est pas le seul problème. Des SDK légitimes d’analyse et de marketing peuvent eux aussi devenir problématiques si des informations particulièrement sensibles leur parviennent ou si la politique de confidentialité ne décrit pas correctement le flux réel des données.

Les données d’entraînement sont-elles automatiquement des données de santé selon le RGPD ?

Cette question mérite une réponse plus précise qu’un simple oui ou non.

L’article 4, paragraphe 15 du RGPD définit les données concernant la santé comme des données à caractère personnel relatives à la santé physique ou mentale qui révèlent des informations sur l’état de santé.

Le Comité européen de la protection des données indique qu’il convient d’interpréter largement cette notion.

Cela ne signifie pourtant pas automatiquement :

Toute information contenue dans une application de fitness est toujours une donnée de santé au sens de l’article 9 du RGPD.

L’élément déterminant est ce que les données permettent de déduire sur l’état de santé d’une personne identifiable.

Voici des exemples évidents :

• les données de fréquence cardiaque et d’ECG ;
• les informations sur des maladies, blessures ou médicaments ;
• les données corporelles permettant de déduire des informations de santé précises ;
• les données d’activité lorsqu’elles permettent, dans leur contexte, de tirer des conclusions sur un état de santé.

Un enregistrement isolé comme « développé couché 80 kg × 8 » peut, selon le contexte, révéler beaucoup moins d’informations sur la santé.

Cette distinction compte pour les développeurs : plus les données sont sensibles et permettent de déduire des informations de santé, plus les exigences de base juridique, de transparence, de limitation des finalités et de protection augmentent.

Un compte n’est pas automatiquement un problème de confidentialité

De nombreuses applications d’entraînement utilisent des comptes afin de proposer la synchronisation entre appareils, des fonctions sociales, du coaching ou un accès web.

Une inscription peut donc avoir une justification technique.

La situation devient plus problématique lorsque l’inscription n’est pas nécessaire à la fonction essentielle, mais que l’utilisateur ne peut tout de même pas poursuivre sans compte. Dans la littérature sur l’expérience utilisateur, ce mécanisme est décrit comme une inscription forcée, ou dark pattern.

Pour un carnet d’entraînement local, une question simple est donc utile :

Quelle fonction concrète a besoin de mon identité ?

Si la réponse est « aucune », un modèle local sans compte peut minimiser davantage les données.

Si tu veux en revanche un fil communautaire, un accès pour ton entraîneur ou une synchronisation automatique entre plusieurs appareils, l’application aura besoin d’une forme d’identité et d’un état conservé sur un serveur.

La confidentialité ne se résume donc pas à « le cloud est mauvais, le stockage local est bon ».

C’est une question de minimisation des données et de finalité.

Que se passe-t-il si le fournisseur disparaît ?

Outre la confidentialité, les logiciels cloud soulèvent une deuxième question : la dépendance au service.

Jawbone constitue un exemple parlant.

L’entreprise a été liquidée en 2017. Les bracelets UP dépendaient fortement de l’application associée et du service serveur. En 2018, l’application est devenue inutilisable, et les appareils existants ont ainsi perdu l’essentiel de leur fonction. Des commerçants vendaient parfois encore les derniers stocks alors que le service central avait déjà cessé de fonctionner.

C’est un cas extrême, mais le principe est plus général.

Si tu ne peux accéder à ton historique d’entraînement que par un serveur propriétaire, cet accès dépend du fait que :

• le service continue d’être exploité ;
• ton compte continue de fonctionner ;
• l’application reste prise en charge ;
• un export demeure disponible.

Un bon service cloud peut réduire fortement ces risques grâce à des exports, des sauvegardes et des procédures de migration claires.

Une architecture conçue d’abord pour le hors-ligne suit une autre voie : la fonction essentielle ne doit pas dépendre de l’existence d’un serveur actif.

Le principe offline-first va au-delà du simple « fonctionne en mode avion »

Martin Kleppmann, Adam Wiggins, Peter van Hardenberg et Mark McGranaghan ont décrit en 2019 le concept de logiciel local-first.

L’idée centrale est que la copie locale n’est pas seulement un cache temporaire d’un serveur. Elle constitue la copie de travail principale. Des services cloud peuvent compléter le système par la synchronisation et la sauvegarde, sans que le logiciel en dépende entièrement.

Pour une application d’entraînement, ce principe a plusieurs conséquences pratiques.

La séance n’attend pas le serveur

Dans une salle où la réception est mauvaise, la disponibilité d’une API ne devrait avoir aucune importance.

Valider une série, modifier une charge, démarrer le minuteur ou enregistrer un record personnel : tout cela peut se faire localement.

Moins de données doivent quitter l’appareil

Si l’analyse et le stockage fonctionnent localement, chaque série n’a pas besoin d’être envoyée vers un serveur central pour assurer la fonction de base.

La quantité de données traitées à l’extérieur diminue donc.

Une panne de serveur ne rend pas automatiquement l’historique inaccessible

Lorsque la base locale constitue la copie principale, les séances antérieures restent disponibles sur l’appareil.

Le mode de défaillance diffère alors d’un logiciel dont toute l’interface ne fait qu’afficher des données distantes.

Le local-first ne garantit pourtant pas automatiquement la confidentialité

Une application fonctionnant hors ligne peut malgré tout contenir des SDK de suivi ou transmettre des données dès qu’Internet est disponible.

Et les données locales peuvent disparaître si l’appareil tombe en panne sans qu’aucune sauvegarde existe.

Le principe offline-first ne remplace donc ni une bonne politique de confidentialité ni une stratégie de sauvegarde.

Il modifie seulement le point de départ technique au profit du contrôle local.

Comment hitPR applique ce principe

Je développe hitPR. Son architecture est volontairement conçue pour que l’entraînement lui-même ne dépende pas d’un serveur hitPR.

Les détails figurent dans la politique de confidentialité. Les points suivants sont particulièrement importants au quotidien.

Les données d’entraînement restent locales

Les exercices, séries, charges, programmes et records personnels sont stockés localement sur l’appareil. L’application fonctionne sans compte hitPR et sans connexion Internet permanente.

Les rapports statistiques et de plantage sont facultatifs

Il n’y a ni SDK publicitaire ni profilage du contenu de tes entraînements. Les signaux statistiques et de plantage sont désactivés par défaut ; si tu les actives, seuls les signaux techniques ou d’utilisation anonymes prévus à cet effet sont traités.

Les séries et charges concrètes ne doivent donc pas alimenter un profil centralisé de l’utilisateur.

La sauvegarde cloud est facultative

Si tu actives une sauvegarde, elle utilise ton propre espace cloud : iCloud ou Google Drive.

La sauvegarde est chiffrée sur l’appareil avec AES-256-GCM. Tu conserves le code de récupération. hitPR n’exploite aucun serveur central de données d’entraînement sur lequel je pourrais lire ton historique.

La contrepartie doit elle aussi être transparente : perdre le code de récupération signifie perdre la possibilité de déchiffrer une sauvegarde chiffrée.

Les fonctions essentielles ne nécessitent aucun cloud

Le suivi, le minuteur, les 8 systèmes de progression, la Muscle Heatmap, la détection des records personnels, le calculateur de disques et les programmes d’entraînement fonctionnent localement. Pro ajoute notamment des analyses plus longues, la sauvegarde et l’application compagnon pour montre.

L’export fait partie de la maîtrise des données

Une sauvegarde assure la continuité dans la même application. Un export remplit une autre fonction : il doit permettre de sortir tes données de l’application.

Les deux sont importants.

Lorsqu’une application conserve ton historique pendant des années, la question ne devrait pas seulement être de savoir comment y entrer, mais aussi comment en sortir.

Cinq questions plus révélatrices qu’une étiquette de confidentialité

Avant d’accumuler plusieurs années d’entraînement dans une application, vérifie les points suivants :

1. Où se trouve la copie principale de mes données d’entraînement ? Sur l’appareil, dans le cloud ou aux deux endroits ?
2. Quelles fonctions exigent un compte, et pourquoi ?
3. Puis-je exporter tout mon historique ? Dans un format documenté et réutilisable ?
4. Quelles données sont envoyées à des services d’analyse, de publicité ou de rapport de plantage ? Ces fonctions sont-elles facultatives ?
5. Que se passe-t-il si le fournisseur ou le serveur disparaît demain ? Puis-je encore accéder à mes données ?

Une bonne politique de confidentialité doit répondre plus clairement à ces questions qu’un slogan marketing comme « respectueux de la vie privée ».

Conclusion

Une application d’entraînement n’a pas besoin d’être entièrement hors ligne pour traiter les données de manière responsable. La synchronisation cloud, les fonctions sociales et le coaching peuvent justifier l’utilisation de serveurs et de comptes.

L’essentiel est ailleurs :

Une application ne devrait traiter que les données réellement nécessaires à ses fonctions, tout en t’expliquant clairement où elles se trouvent et comment les récupérer.

Le principe offline-first n’est pas un label magique de confidentialité. Mais pour un carnet d’entraînement personnel, il constitue un principe d’architecture solide : la séance fonctionne localement, l’historique reste sur ton appareil et les fonctions cloud complètent l’ensemble au lieu d’en être une condition.

Pour aller plus loin :

• Mesurer ses progrès en musculation : 5 méthodes efficaces
• Application de musculation sans abonnement : est-ce encore possible ?
• Consigner son entraînement : pourquoi le carnet compte

Sources

• Surfshark (2026) : Fitbit tops fitness apps in user data collection
• Under Armour / SEC (2018) : MyFitnessPal data security issue
• Ministère américain de la Défense (2018) : objets connectés et carte thermique de Strava
• Ministère américain de la Défense (2018) : règles de géolocalisation dans les zones d’opération
• Federal Trade Commission (2021) : Flo Health
• EUR-Lex : règlement général sur la protection des données, article 4, paragraphe 15 et article 9
• EDPB (2020) : Guidelines 03/2020 on data concerning health
• Kleppmann M, Wiggins A, van Hardenberg P, McGranaghan M. (2019) : Local-First Software
• The Guardian / Which? (2018) : les bracelets Jawbone après la fermeture de l’application