Oura Ring → InfluxDB & Grafana : Libérez vos données de santé

Le problème : Reprendre un contrôle partiel de mes données de santé

Les données de mon Oura Ring (et de celui de ma copine) étaient précieusement collectées, mais restaient cantonnées à l'application officielle. Bien que l'application offre une vue d'ensemble, elle limite considérablement les possibilités d'analyse approfondie, de corrélations personnalisées, et d'intégration avec d'autres sources de données ou des systèmes d'IA locaux.

Il est important de souligner que "reprendre le contrôle" est ici un contrôle partiel. Oura continue de collecter mes données brutes sur ses serveurs, et surtout, l'utilisation de l'application mobile reste indispensable pour synchroniser les données de la bague vers les serveurs Oura, avant de pouvoir les récupérer via l'API. Malgré des recherches, il n'existe à ce jour aucune méthode officielle ou "hack" permettant de flasher la bague ou d'accéder directement aux données sans passer par l'écosystème Oura et son application.

De plus, le récent partenariat d'Oura avec Palantir pour des projets liés au Département de la Défense américain a soulevé des inquiétudes légitimes concernant la confidentialité et l'utilisation future des données, même si Oura affirme que les données des consommateurs ne sont pas directement affectées par cette collaboration. Cette situation renforce ma motivation à extraire et à analyser mes propres données dans un environnement que je maîtrise.

L'objectif est clair : récupérer ces données, les posséder réellement (dans ma base locale), et construire ma propre plateforme d'analyse pour une compréhension plus granulaire et libre. Il s'agit de se libérer des contraintes d'une application propriétaire pour explorer des pistes d'analyse qui ne sont pas prévues par le fournisseur, et potentiellement jeter les bases pour entraîner une IA locale avec mes propres données de santé.

Update mai 2026 : le pipeline tourne en production sur mon homelab depuis fin 2025. InfluxDB (CT 105) ingère les données quotidiennement, Grafana (CT 102) sert de tableau de bord principal, et la stack IA locale (Ollama avec 6 modèles, CT 101) est en place. Ce qui reste TODO côté ML est documenté en fin d'article.

Architecture du pipeline : De la donnée brute à la visualisation intelligente

Mon pipeline ETL (Extract, Transform, Load) est conçu pour être robuste et flexible.

+----------------+       +------------+       +---------------+       +----------+       +----------+
| API Oura v2    | ----> | Extraction | ----> | Transformation| ----> | InfluxDB | ----> | Grafana  |
| (OAuth)        |       | (Python)   |       | (Python)      |       | (Stockage)|       | (Viz.)   |
+----------------+       +------------+       +---------------+       +----------+       +----------+

1. Extraction : La double synchronisation sécurisée

Pour garantir la récupération des données pour ma copine et moi, j'ai mis en place une double synchronisation. Chaque utilisateur est authentifié via le protocole OAuth de l'API Oura v2. Cela garantit un accès sécurisé et révocable aux données de chaque anneau. Le pipeline gère l'authentification et le rafraîchissement des tokens de manière indépendante pour chaque compte, assurant l'isolement et la confidentialité des données personnelles.

2. Transformation : Naviguer dans le JSON complexe

L'API Oura renvoie des structures JSON profondément imbriquées. Cette étape Python est cruciale pour "aplatir" ces données, les nettoyer, gérer les incohérences (champs manquants, types invalides), et les préparer pour un stockage optimisé en séries temporelles. Les défis incluent :

• JSON imbriqué complexe : L'API Oura renvoie des structures profondes avec beaucoup de nesting.
• Mapping de champs dynamique : Certains champs ou la granularité des données peuvent varier selon les jours ou les mises à jour de l'API.
• Gestion des erreurs : Implémentation robuste face aux timeouts, données manquantes, et à la gestion du rate limiting de l'API.

3. Stockage : InfluxDB pour des séries temporelles optimisées

Toutes les données transformées sont ensuite stockées dans InfluxDB 2, une base de données optimisée pour les séries temporelles. Ce choix technique permet une ingestion rapide et des requêtes analytiques extrêmement performantes sur des volumes importants de données temporelles. Chaque point de donnée est horodaté, facilitant les analyses basées sur le temps et les corrélations entre différents métriques.

4. Visualisation et Analyse : Grafana en production, dashboard custom en backlog

Grafana est l'interface de visualisation actuelle (CT 102 sur le homelab Proxmox, 512 MB de RAM, branché sur le datasource InfluxDB du même hyperviseur). Dashboards déjà en place : score de sommeil, HRV, readiness, pas, heatmap d'activité par heure. Suffisant pour 90% de l'usage exploratoire.

Reste TODO côté visualisation : un dashboard interactif custom qui interroge directement l'API d'InfluxDB pour des usages que Grafana couvre mal — corrélations multi-sources (humeur, alimentation, activité), vues comparatives entre les deux utilisateurs, drill-down personnalisé sur les anomalies de sommeil. Pas une urgence tant que Grafana fait le job pour l'exploration courante.

Données traitées

Actuellement, le pipeline ingère et analyse :

• Sommeil : phases de sommeil (léger, profond, paradoxal), durée, efficacité, latence, scores de qualité.
• Activité : nombre de pas, calories brûlées, durée d'activité modérée/intense, temps d'inactivité.
• Readiness : score quotidien de préparation, variabilité de la fréquence cardiaque (HRV), température corporelle.

Ce que j'ai appris

Ce projet a été une excellente opportunité pour approfondir mes compétences en :

• La manipulation de JSON complexe en Python et les techniques d'ETL.
• L'utilisation et l'optimisation des bases de données time-series (InfluxDB 2 et le langage Flux), y compris l'interaction directe via son API.
• La gestion sécurisée des authentifications OAuth pour des APIs externes.
• La robustesse d'un pipeline ETL (retry, logging, validation).
• La gestion du rate limiting API.

Ce qui reste TODO

L'infrastructure pour passer à l'analyse prédictive est en place côté homelab : 6 modèles Ollama (Cogito 8B, Qwen3 8B, Mistral 7B, Gemma3 4B, Qwen3 1.7B) tournent en local sur la GTX 1070 Ti, avec Open WebUI comme interface. Le corpus de données InfluxDB s'enrichit quotidiennement depuis fin 2025, donc le dataset d'entraînement existe.

Ce qui manque concrètement :

• Étape feature engineering : extraire les fenêtres temporelles pertinentes (J-1 sommeil → J activité, cycles 28 jours, etc.) en features tabulaires exploitables
• Choix de l'approche ML : fine-tuner un LLM sur les données (overkill pour de la prédiction tabulaire ?) vs un modèle classique type XGBoost en local, puis pousser les résultats vers Open WebUI pour interrogation conversationnelle
• Boucle d'évaluation : comment mesurer qu'une "prédiction de fatigue" est correcte sans biais a posteriori

C'est l'étape qui demande le plus de temps et qui justifie le moins de complexité — beaucoup de ce que je voudrais "prédire" est déjà visible à l'œil sur les graphes Grafana. La vraie valeur attendue est dans les patterns de corrélation peu intuitifs qu'un humain ne repère pas à 4 mois de recul.

---

Ce pipeline tourne sur mon homelab Proxmox (CT 105 InfluxDB + CT 102 Grafana + CT 101 Ollama). Retrouvez tous mes projets sur mon parcours technique.