Plusieurs montres connectées sans données dupliquées : le guide de déduplication multi-wearable

Si vous portez plusieurs appareils connectés, votre compteur de pas est presque certainement gonflé. Pas à cause d'un bug : c'est le comportement attendu d'un écosystème conçu pour des appareils uniques, utilisé par quelqu'un qui a compris que des outils différents font mieux des choses différentes. Une Galaxy Watch pour le quotidien, une bague connectée pour le sommeil, une Garmin pour les longues courses, une Suunto pour les sorties en mer ou en montagne : chaque appareil excelle dans son contexte. Mais le tableau de bord doit savoir que les 8 000 pas du matin ne doivent pas être additionnés aux 8 000 pas enregistrés par Garmin lors de la course de l'après-midi sur les mêmes trottoirs.

Pourquoi les données se dupliquent : la cause technique du problème

Health Connect est une base de données locale sur Android. Toute application avec les bonnes autorisations peut écrire des enregistrements de n'importe quel type : pas, fréquence cardiaque, séances de sommeil, entraînements. Health Connect ne sait pas si deux enregistrements représentent la même chose mesurée deux fois : il n'y a pas de champ "source principale" et pas de déduplication automatique. C'est un choix de conception délibéré, pas une limitation technique : le système est neutre vis-à-vis des sources pour ne favoriser aucun fabricant.

Le problème concret : quand vous portez à la fois une Galaxy Watch et une Garmin pendant une course de 10 km, les deux écrivent dans Health Connect. La Galaxy Watch enregistre ses 9 847 pas, la Garmin enregistre ses 10 124 pas (les chiffres divergent parce que les calibrations des capteurs diffèrent). Une application qui lit Health Connect sans logique de déduplication les additionne : résultat, 19 971 pas pour une course de 10 km. C'est le double. Et pour la fréquence cardiaque c'est encore pire : les moyennes sont contaminées par des mesures prises dans des contextes physiques différents.

Trois schémas de duplication les plus fréquents

1. Enregistrements cumulatifs additionnés: pour les pas, certaines applications écrivent des enregistrements cumulatifs ("total des pas jusqu'à maintenant") plutôt que des enregistrements intraday. Si Galaxy Watch et Garmin Connect utilisent tous les deux des enregistrements cumulatifs, le total en fin de journée est la somme de deux totaux, pas un total dédupliqué.
2. Séances de sommeil qui se chevauchent: Galaxy Ring ou Oura écrit une séance de sommeil de 22h30 à 06h45. Galaxy Watch écrit de 22h35 à 06h40 (même nuit, fenêtres légèrement différentes). Un agrégateur qui ne regroupe pas les séances par cluster temporel affiche deux nuits de sommeil, doublant les heures totales et faussant les moyennes du score de sommeil.
3. Fréquence cardiaque moyenne quotidienne de sources mixtes: votre ceinture Polar H10 enregistre 147 bpm comme moyenne d'entraînement. La Galaxy Watch a enregistré 72 bpm comme moyenne au repos l'après-midi. Sans étiqueter les fenêtres temporelles, la moyenne quotidienne devient un nombre physiquement sans signification.

La configuration décrite : quatre appareils connectés, quatre rôles

Pour être concret, je travaille avec cette configuration spécifique : montre connectée quotidienne (Galaxy Watch 7) qui enregistre tout en arrière-plan, bague connectée (Galaxy Ring ou Oura Ring) optimisée pour le suivi du sommeil avec des capteurs supérieurs aux montres connectées, montre GPS de course (Garmin Forerunner) pour les séances de running avec un GPS précis et une analyse avancée du VO2max, montre outdoor/voile (Suunto Race ou Suunto Ocean) pour les sorties en bateau et le trekking où le journal GPS et l'altimètre barométrique sont essentiels. Quatre appareils, quatre contextes d'utilisation, quatre applications qui écrivent dans Health Connect.

Comment fonctionne la déduplication : trois stratégies concrètes

1. Winner-takes-all par source et fenêtre temporelle

Pour la fréquence cardiaque intraday et les données d'entraînement, la méthode la plus fiable consiste à définir une priorité de source pour chaque fenêtre temporelle. Si Garmin a enregistré des données de fréquence cardiaque entre 17h30 et 18h45 (durée de la course), tout tableau de bord sérieux utilise ces données et ignore celles enregistrées par la Galaxy Watch dans la même fenêtre. La Galaxy Watch redevient "gagnante" à partir de 18h46, quand Garmin n'enregistre plus de données actives.

En pratique, cela s'implémente en lisant les enregistrements de type ExerciseSession depuis Health Connect : chaque séance d'entraînement a un startTime et un endTime. La logique de dédup utilise ces fenêtres pour décider quelle source a la priorité pour les métriques dans cette fenêtre temporelle.

2. Fusion au niveau des champs pour les métriques quotidiennes agrégées

Pour le total de pas quotidiens, le winner-takes-all n'est pas la bonne solution : la Galaxy Watch collecte des pas de 07h00 à 17h29, la Garmin collecte des pas de 17h30 à 18h45. Les additionner est correct, ce n'est pas une duplication. Le problème se pose quand les deux ont enregistré des pas dans la même fenêtre temporelle.

La fusion au niveau des champs fonctionne ainsi : divisez la journée en créneaux de 15 minutes. Pour chaque créneau, conservez uniquement l'enregistrement avec la valeur la plus élevée parmi toutes les sources (approche conservatrice : suppose que la valeur la plus haute est la plus précise). Additionnez les maximums par créneau : vous obtenez un total quotidien dédupliqué. Cette approche fonctionne parce que deux appareils enregistrant les mêmes pas produisent des valeurs similaires (la plus haute est une estimation de la vérité), tandis que deux appareils dans des contextes différents produisent des valeurs additives.

3. Regroupement temporel pour les séances de sommeil

Pour le sommeil, le problème est différent : les séances d'Oura Ring et de Galaxy Watch pour la même nuit se chevauchent presque entièrement, mais aucune n'est fausse. Elles mesurent simplement la même chose avec des capteurs différents. La stratégie est le clustering : si deux séances de sommeil se chevauchent à plus de 80 % de leur durée, elles sont considérées comme la même nuit. La priorité de source est ensuite appliquée : la bague connectée gagne parce que les capteurs optiques au doigt sont statistiquement plus précis pour les phases du sommeil que les capteurs au poignet.

Ce que vous devez configurer : les trois paramètres critiques

Tout ne peut pas être automatisé. Il y a trois configurations qui nécessitent une saisie de l'utilisateur parce qu'elles dépendent d'habitudes personnelles qu'aucun algorithme ne peut inférer.

1. Définissez quel appareil est votre source principale pour le sommeil. Si vous avez à la fois une Galaxy Watch et une bague connectée, vous devez le préciser explicitement. FitMesh Sync vous le demande lors de l'onboarding ("Quel appareil portez-vous la nuit ?"). Si vous ne le précisez pas, la Galaxy Watch est utilisée par défaut comme choix le plus courant, mais c'est un choix arbitraire.
2. Désactivez Google Fit comme source d'écriture s'il est encore actif. Allez dans Health Connect > Gestion des autorisations > Google Fit et vérifiez qu'il n'a QUE la permission de lecture, pas d'écriture. Google Fit obsolète qui écrit encore dans Health Connect est la première cause de pas triplés dans les configurations multi-wearable.
3. Précisez les périodes d'activité pour les appareils spécifiques. Si vous portez la Garmin uniquement pendant les courses (jamais au repos), le système peut ignorer ses données de fréquence cardiaque en dehors des fenêtres d'entraînement. Sans cette information, la fréquence cardiaque au repos mesurée par Garmin pendant une activité lente peut contaminer la moyenne au repos.

Le cas Suunto : des données qui ne passent pas par Health Connect

Suunto est l'exception dans ce scénario. Contrairement à Garmin (qui écrit nativement dans Health Connect depuis Garmin Connect Android), l'application Suunto sur Android n'a pas d'intégration native avec Health Connect pour tous les types de données. Les traces GPS et les données d'entraînement de Suunto sont accessibles via l'API Suunto Sport Engine, pas via Health Connect.

Cela signifie qu'intégrer Suunto dans un tableau de bord multi-source nécessite un connecteur séparé qui lit depuis l'API Suunto Sport Engine avec authentification OAuth. FitMesh Sync prend en charge cette intégration séparément : allez dans Paramètres, section Appareils, et ajoutez Suunto comme source OAuth. Une fois connectées, les données Suunto sont fusionnées dans le flux Health Connect avec la même logique de déduplication.

Fréquence cardiaque moyenne "contaminée" : un exemple réel

C'est le problème que je trouve le moins évident mais le plus dommageable pour ceux qui utilisent les données pour suivre leur santé dans le temps. Scénario : vous courez pendant 45 minutes avec une ceinture Polar H10 connectée à Garmin (données d'entraînement fiables, moyenne 148 bpm). Pendant ce temps, la Galaxy Watch enregistre votre fréquence cardiaque toutes les 10 minutes en arrière-plan, voyant des valeurs entre 145 et 155 bpm (correct, vous courez). Après la course, vous vous asseyez pendant deux heures avec une fréquence cardiaque de 62-68 bpm. La Galaxy Watch enregistre toujours.

Un tableau de bord qui calcule la "fréquence cardiaque moyenne quotidienne" sans distinguer les sources prend toutes ces données, les additionne et divise. Le résultat est un nombre qui ne représente ni la fréquence cardiaque au repos ni la fréquence cardiaque d'entraînement : c'est la moyenne de choses qui ne devraient pas être moyennées ensemble. C'est pourquoi FitMesh Sync expose séparément la fréquence cardiaque au repos (calculée en excluant les fenêtres d'entraînement) et la fréquence cardiaque d'entraînement (calculée par type d'activité), plutôt que d'afficher une seule moyenne quotidienne.

Ce que FitMesh Sync gère automatiquement

• •Détection automatique des séances d'entraînement: lit les enregistrements ExerciseSession depuis Health Connect et construit la carte des fenêtres actives pour chaque source.
• •Slot-merge des pas en 15 minutes: prend le maximum par créneau sur toutes les sources, élimine les chevauchements sans perdre les données additives (Galaxy Watch le matin + Garmin pour la course de l'après-midi).
• •Regroupement des séances de sommeil: regroupe les séances se chevauchant à plus de 80 % et applique la priorité bague connectée > montre connectée pour les phases du sommeil.
• •Séparation fréquence cardiaque au repos vs entraînement: les fenêtres d'entraînement sont exclues du calcul de la fréquence cardiaque au repos.
• •Déduplication des enregistrements Samsung dupliqués: filtre les enregistrements avec le même horodatage et source_package répété (le bug Samsung connu d'écriture double).

Limites honnêtes : ce qui ne peut pas encore être automatisé

Je ne veux pas surestimer ce qu'un tableau de bord peut faire seul. Il y a des scénarios qui nécessitent encore une intervention manuelle ou qui produisent des résultats approximatifs :

• •Entraînements de natation avec Suunto et Galaxy Watch qui se chevauchent: Galaxy Watch reconnaît la natation comme une ExerciseSession (type SWIMMING), Suunto enregistre via l'API Sport Engine. Si les horodatages se chevauchent partiellement (ex : changement de couloir entre les longueurs), la fusion est conservatrice mais pas parfaite.
• •VO2max de sources différentes: Garmin calcule son VO2max avec un algorithme propriétaire (FirstBeat), Galaxy Watch utilise une autre méthode. Les estimations ne sont pas comparables : FitMesh Sync affiche actuellement les deux métriques séparément, sans les fusionner.
• •HRV de ceinture pectorale pendant la journée vs bague la nuit: si vous utilisez une ceinture Polar H10 pour la HRV matinale et la bague pour la HRV nocturne, les valeurs sont correctes dans leurs contextes respectifs mais pas directement comparables. C'est une limite de la biométrie, pas du logiciel : la HRV varie selon l'heure de la journée et la posture corporelle.

En résumé

• •Health Connect ne déduplique pas : c'est une base de données neutre par source et chaque application écrit de façon indépendante. La logique de déduplication doit se trouver dans l'application qui agrège les données.
• •Les trois principaux problèmes dans les configurations multi-wearable sont : des pas en double dus à des enregistrements cumulatifs qui se chevauchent, des séances de sommeil dupliquées provenant d'appareils mesurant la même nuit, et une fréquence cardiaque moyenne contaminée par des mesures dans des contextes physiques différents.
• •La bonne stratégie combine trois techniques complémentaires : winner-takes-all par fenêtre temporelle (fréquence cardiaque intraday), slot-merge de 15 minutes (pas) et clustering temporel avec priorité de source (sommeil).
• •Deux choses nécessitent une configuration manuelle : quel appareil vous portez la nuit et la désactivation de Google Fit comme source d'écriture s'il est encore actif.
• •Suunto ne passe pas par Health Connect : un connecteur OAuth séparé est nécessaire. Les données sont ensuite unifiées avec la même logique de dédup.
• •La fréquence cardiaque moyenne quotidienne sans distinction de contexte est un nombre physiquement sans signification : séparez toujours la fréquence cardiaque au repos de la fréquence cardiaque d'entraînement.