Oui, l’accès “smartphone / desktop / navigateur / Android / iOS” est bien compatible avec une application web.
 
1. Accès et compatibilité (ce que tu peux raisonnablement attendre)
 
* Navigateur mobile et desktop : OK (Chrome/Edge/Firefox/Safari).
* Android 14/15/16 : OK en navigateur, et installable en “PWA” (icône sur l’écran d’accueil, plein écran, offline partiel).
* iOS (Safari) : OK en navigateur, et installable en “PWA” via “Ajouter à l’écran d’accueil”.
* Limites à connaître (important pour ton timer et l’expérience “app”) :
 
  * iOS et parfois Android peuvent “throttler” (ralentir) JavaScript en arrière-plan, ce qui peut affecter un chrono si l’écran s’éteint ou si l’utilisateur change d’app.
  * Les capacités PWA iOS sont plus contraintes que sur Android (certaines APIs, stockage, tâches en arrière-plan, comportement des notifications/push selon versions iOS).
    Conclusion : oui, c’est possible et pertinent. Il faut juste concevoir le timer et l’offline “de façon robuste” en tenant compte des limites mobile.
 
2. Périmètre produit (vision)
   Objectif : une Progressive Web App de musculation (extensible à d’autres sports), auto-hébergeable sur ton NAS Synology via Docker, avec :
 
* Tracking des séances (exercices, séries, charges, RPE, notes, chronos, progression).
* Gestion des programmes (templates, cycles, progression).
* Suivi alimentaire (journal, macros, objectifs) avec conseils IA.
* Expérience “rapide, sans friction” et fiable (timer qui ne freeze pas, mode offline, sync).
 
3. Requirements fonctionnels (Workout / entraînement)
   3.1 Gestion des comptes et des profils
 
* Mode “local-only” possible (sans compte, données stockées localement sur l’appareil).
* Mode “sync multi-devices” (compte + stockage serveur sur NAS), pour retrouver ses données sur smartphone et desktop.
* Gestion multi-profils (utile si tu veux suivre 2 personnes sur le même NAS).
 
3.2 Bibliothèque d’exercices
 
* Catalogue d’exercices (nom, groupe musculaire, variantes, équipement, niveau, consignes).
* Exercices personnalisés (création, duplication, tags).
* Médias : images/vidéos associées (upload depuis mobile), stockage sur NAS.
* Paramètres par exercice : unité (kg/lbs), incréments, tempo, rest par défaut, notes “technique”.
 
3.3 Templates de séances et programmes
 
* Création de séances (liste d’exercices, ordre, supersets/giant sets, échauffement/finisher).
* Regroupements : dossiers/collections (ex : “Split 4 jours”, “Dos”, “Jambes”).
* Programmes multi-semaines :
 
  * Planning (calendrier indicatif).
  * Règles de progression (voir 3.6).
  * Déload et cycles.
 
3.4 Exécution d’une séance (le cœur de l’app)
 
* Démarrer une séance depuis un template (snapshot de la séance du jour).
* Pour chaque exercice : séries planifiées + saisie des séries réalisées.
* Saisie rapide :
 
  * reps, charge, RPE/RIR, notes, tempo, type (warm-up / working set / drop set).
  * boutons +/− pour ajuster charge/reps.
* Affichage du “dernier résultat” et du “meilleur récent” (référence immédiate).
* Possibilité de modifier l’exercice “à la volée” (remplacer par variante, changer l’ordre, supprimer/ajouter).
* Annulation/édition post-séance (comme ton appli actuelle) avec historique des modifications.
 
3.5 Timer / chrono (point critique vu ton besoin)
 
* Chrono de repos par série, démarrage automatique après validation de série.
* Paramétrage : repos par exercice, par série, ou global.
* Fiabilité :
 
  * doit continuer si l’écran reste allumé.
  * si l’utilisateur change d’onglet/app : comportement “dégradé” mais sûr (par exemple : recalcul basé sur l’heure système au retour, plutôt que compter des ticks JS).
* Alertes : son + vibration si dispo, et un mode “discret”.
* Option “Keep awake” (empêcher l’écran de se verrouiller pendant la séance, quand possible).
* Zéro freeze : objectifs non fonctionnels (voir section 5).
 
3.6 Suivi de progression / progressive overload
 
* Métriques :
 
  * progression charge/reps par exercice, e1RM estimée, volume (tonnage), séries dures.
  * PR (records) : rep PR, weight PR, e1RM PR.
* Règles de progression configurables par programme, par exercice ou par catégorie :
 
  * Double progression (ex : 3x8-12 puis +2,5 kg).
  * Top set + back-off.
  * Progression linéaire, ondulée, RPE-based.
  * Auto-régulation : si RPE trop haut, réduire charge cible ; si RPE bas, augmenter.
* Recommandations automatiques de charges “cibles” sur la prochaine séance, avec justification (basée sur historique).
 
3.7 Historique et analytics
 
* Calendrier d’entraînement (séances réalisées, durée, volume).
* Graphs (par exercice et global). Exemples : e1RM, volume hebdo, fréquence par groupe musculaire.
* Export/import :
 
  * export CSV/JSON (important pour la pérennité).
  * import depuis ton app actuelle si tu as des exports (sinon on peut prévoir un import manuel progressif).
 
3.8 Multi-sports (optionnel mais prévu)
 
* Modèle d’activité générique : “session” avec types (musculation, running, HIIT, mobilité).
* Pour musculation : structure séries/réps/charge.
* Pour cardio : durée, distance, FC, zones.
* Pour mobilité : routine + temps.
 
4. Requirements fonctionnels (Nutrition / alimentation)
   4.1 Journal alimentaire
 
* Enregistrement par repas (petit-déj, déjeuner, dîner, snack) + horaires.
* Base aliments :
 
  * soit une base interne minimaliste + aliments personnalisés,
  * soit intégration à une base externe (à décider selon licences et disponibilité).
* Macro et calories :
 
  * objectifs journaliers (kcal, protéines, lipides, glucides, fibres).
  * suivi hebdo/mensuel, tendances.
* Recettes :
 
  * création de recettes et portionnage.
  * réutilisation rapide (“favoris”, “récent”).
* Scan code-barres : optionnel (souvent coûteux/licences, à cadrer).
 
4.2 Conseils IA (nutrition + entraînement)
 
* Cas d’usage IA nutrition :
 
  * proposer des ajustements pour atteindre protéines/kcal,
  * suggestions de repas selon contraintes (temps, budget, goûts, allergies),
  * analyse de cohérence (déficit/surplus, répartition protéines, fibres).
* Cas d’usage IA entraînement :
 
  * recommandations d’ajustement de charge/reps/RPE,
  * détection de stagnation, proposition de variations,
  * revue hebdo (volume, intensité, fréquence) + actions.
* Garde-fous :
 
  * disclaimers “non médical”,
  * règles de sécurité : pas de conseils dangereux, pas de promesses médicales,
  * traçabilité : expliquer sur quelles données l’IA s’appuie (historique, objectifs).
* Confidentialité :
 
  * si IA cloud (ex : API externe), permettre de désactiver et/ou anonymiser,
  * si IA local (sur NAS), préciser limites de performance et qualité.
 
5. Requirements non fonctionnels (qualité, sécurité, performance)
   5.1 Disponibilité et fiabilité
 
* Timer : tolérance au background limitée mais comportement prévisible (recalage sur horodatage).
* Pas de perte de données : chaque saisie de série doit être persistée immédiatement en local.
* Sync robuste : file d’attente offline, reprise automatique, gestion de conflits (ex : “last write wins” ou merge guidé).
 
5.2 Performance
 
* Démarrage rapide (objectif : interface utilisable en quelques secondes).
* Interactions séance : latence quasi nulle (saisie reps/charge fluide).
* Optimisation mobile (réseau variable).
 
5.3 Sécurité
 
* Si multi-utilisateurs : authentification + sessions sécurisées.
* Chiffrement en transit (HTTPS) recommandé même en LAN.
* Droits : un utilisateur ne voit pas les données d’un autre.
* Backups : stratégie simple (dump base + médias).
 
5.4 Portabilité et pérennité
 
* Application packagée en Docker, mise à jour simple.
* Données exportables (CSV/JSON).
* Pas de dépendance critique à un service tiers non maîtrisé (surtout si ton but est l’autonomie sur NAS).
 
6. Architecture cible (Docker sur Synology) – niveau requirements
   Composants typiques :
 
* Frontend PWA : application web (UI), offline-first (cache + stockage local).
* Backend API : gestion comptes, programmes, logs, nutrition, IA orchestration.
* Base de données : relationnelle ou document (à choisir), plus un stockage fichiers pour médias.
* Option IA :
 
  * Soit “connecteur” vers une API externe,
  * Soit service IA local sur NAS (si tu veux autonomie maximale), avec contraintes CPU/RAM.
* Reverse proxy : pour HTTPS, domaine, et accès externe si tu le souhaites.
 
Requirements d’exploitation :
 
* Déploiement via docker-compose.
* Variables d’environnement (URL, secrets, mode offline-only, options IA).
* Observabilité minimale : logs, métriques basiques (erreurs timer/sync), healthchecks.
 
7. MVP recommandé (pour livrer vite sans exploser le scope)
   MVP séance + progression (priorité la plus forte, remplace ton app actuelle) :
 
* Exercices custom + templates.
* Exécution séance + saisie séries + timer fiable (recalage horodatage).
* Historique + quelques graphes clés.
* Export JSON/CSV.
* Mode local-only + option sync simple.
 
Phase 2 :
 
* Programmes multi-semaines + règles de progression avancées.
* Nutrition logging simple (macros) sans grosse base externe.
* IA “coach” sur les données (revue hebdo, suggestions).
 
Phase 3 :
 
* Base alimentaire riche, scan, recettes avancées.
* IA plus poussée, personnalisation, multi-sports plus complet.
 
8. Critères d’acceptation (exemples concrets, orientés tests)
 
* Une séance peut être réalisée entièrement en mode avion ; à la reconnexion, tout est synchronisé.
* Le chrono ne “freeze” pas : si le navigateur est mis en arrière-plan, au retour le temps restant est recalculé correctement à partir de l’heure de départ (pas basé sur des ticks perdus).
* Après chaque série validée, la donnée est persistée (si crash/reload, on retrouve la séance).
* Sur mobile, la saisie reps/charge se fait en moins de 2 actions par champ (optimisation UX).
* Les données peuvent être exportées et réimportées sur une autre instance (pas de verrouillage).
 
Si tu veux, je peux ensuite te proposer un document de requirements “PRD” complet (contexte, objectifs, périmètre, user stories, critères d’acceptation, parcours UX, modèle de données haut niveau) en gardant un format très opérationnel pour que tu puisses le donner à un développeur ou t’en servir comme backlog.