---
id: "6bbb4a4d-7c42-4658-9212-e86f3ff65684"
number: 183
title: "[Produit][UX] Permettre le choix de types d'exercice métier mappés vers les types Health Services"
status: "closed"
priority: "medium"
sprint: "d5c18b44-0eec-46db-b8ab-506cfee0bfea"
links: [{"target":"#179","kind":"relatesTo"}]
agentRefs: []
attachments: []
createdBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
updatedBy: {"kind":"user"}
createdAt: 1785407800593
updatedAt: 1785497678018
version: 12
---
Contexte au 30 juillet 2026 : sur certaines montres Wear OS, les métriques `distance` et `calories` ne semblent pas remonter selon le type d'exercice Health Services utilisé. Aujourd'hui, GameTime choisit en interne parmi `RUNNING`, `WALKING`, `HIGH_INTENSITY_INTERVAL_TRAINING`, `WORKOUT` sans que ce choix soit exposé à l'utilisateur métier. Or ce choix influence les métriques réellement fournies par la montre.

Idée produit à étudier : lors de la création/configuration d'un exercice dans GameTime, permettre à l'utilisateur de choisir un ou plusieurs types d'exercice métier (exemples évoqués : `shoot`, `haute intensité`, `dribble`, etc.). Ces types métier seraient ensuite mappés en interne vers un ou plusieurs types `Health Services` (`RUNNING`, `WALKING`, `HIGH_INTENSITY_INTERVAL_TRAINING`, `WORKOUT`, ...).

Objectifs :
- ne plus laisser ce choix uniquement implicite côté technique ;
- mieux refléter l'intention réelle de l'exercice côté utilisateur ;
- améliorer les chances d'obtenir les bonnes métriques montre (`distance`, `calories`, `FC`) selon le contexte ;
- préparer une architecture extensible si plusieurs types métier doivent se combiner.

Questions de cadrage attendues dans ce ticket :
- UX : comment exposer ce choix dans la création/édition d'exercice sans alourdir le flux ?
- Produit : faut-il autoriser un seul type métier ou plusieurs tags combinables ?
- Architecture : comment modéliser un mapping stable `type(s) métier -> stratégie Health Services` ?
- Technique : faut-il choisir un seul type Health Services final, ou une stratégie de fallback ordonnée selon les capacités de la montre ?
- Compatibilité : comment gérer les exercices existants qui n'ont encore aucun type métier explicite ?

Hors périmètre immédiat :
- ce ticket ne corrige pas directement le bug courant de distance/calories indisponibles ;
- il sert à cadrer une évolution produit/UX/architecture qui pourrait améliorer durablement la sélection du type d'exercice côté montre.

Proposition de premier périmètre :
- cadrage UX + architecture ;
- définition d'un premier vocabulaire métier ;
- définition du mapping initial vers Health Services ;
- stratégie par défaut pour les exercices existants.