# Spécifications Techniques Fonctionnelles **Application web personnelle de suivi statistique de vie** --- ## 1. Présentation du projet ### 1.1 Contexte Le projet consiste à concevoir une application web personnelle permettant de suivre, centraliser et analyser des données liées à la vie quotidienne. L'objectif n'est pas de créer un produit commercial dans un premier temps, mais un outil personnel utile, évolutif et suffisamment structuré pour : - suivre des habitudes ; - visualiser des tendances ; - comprendre les facteurs qui influencent la qualité des journées ; - aider à prendre de meilleures décisions au quotidien. ### 1.2 Finalité L'application doit permettre à l'utilisateur de : - saisir des données quotidiennes ; - enregistrer certaines activités sous forme de sessions horodatées ; - visualiser l'évolution de ses comportements et de son état ; - mesurer sa progression dans le temps ; - identifier, à terme, des associations entre certains comportements et la qualité globale de ses journées. ### 1.3 Positionnement fonctionnel L'application n'est pas seulement un tracker. Elle doit être pensée comme un outil d'analyse personnelle. Sa promesse centrale est la suivante : > Aider l'utilisateur à repérer les habitudes, horaires et décisions qui améliorent ou détériorent ses journées. --- ## 2. Objectifs du projet ### 2.1 Objectifs principaux L'application doit permettre de : - motiver l'utilisateur grâce aux statistiques ; - suivre sa progression dans le temps ; - comprendre les tendances générales de son quotidien ; - identifier les facteurs influençant le plus la qualité de ses journées ; - aider à ajuster ses décisions personnelles à partir de données concrètes. ### 2.2 Question centrale à laquelle l'application doit répondre L'application doit progressivement aider à répondre à la question suivante : > Quels sont les facteurs influençant le plus ma journée, et quelles décisions ont les conséquences les plus importantes sur mon équilibre quotidien ? ### 2.3 Exemples de problématiques visées - Le manque de sommeil dégrade-t-il l'état mental ? - Le sport améliore-t-il l'état physique ou émotionnel ? - Le temps d'écran est-il associé à de moins bonnes journées ? - Le fait de démarrer certaines activités tôt le matin entraîne-t-il une perte de contrôle sur le reste de la journée ? - La régularité de certaines habitudes améliore-t-elle la stabilité générale ? --- ## 3. Périmètre fonctionnel ### 3.1 Vue d'ensemble Le périmètre fonctionnel s'organise autour d'une **journée logique** servant d'ancre à plusieurs entités métier. L'application distingue : - une entrée journalière minimale (`daily_entry`) servant de pivot ; - des entités spécialisées rattachées à cette journée ; - des sessions horodatées pour les activités ; - des métriques associées aux sessions ; - des presets utilisateur pour accélérer certaines saisies. ### 3.2 Temporalité L'application doit permettre une lecture : - par jour ; - par semaine ; - par mois ; - puis, à terme, sur des périodes plus longues. La priorité fonctionnelle est : 1. jour ; 2. semaine ; 3. mois. ### 3.3 Mode de saisie La saisie doit pouvoir se faire : - au fil de la journée ; - par ajouts successifs ; - sans imposer un unique formulaire massif. L'utilisateur doit pouvoir compléter progressivement sa journée. --- ## 4. Utilisateur cible ### 4.1 Profil L'utilisateur cible est l'auteur du projet lui-même. L'application est donc conçue d'abord pour un usage personnel. Cependant, le système doit rester propre techniquement, avec authentification et structure par compte utilisateur. ### 4.2 Contexte d'usage - application web ; - usage sur ordinateur en priorité ; - usage mobile web possible ; - design simple et moderne ; - navigation rapide ; - consultation fréquente de la journée en cours. ### 4.3 Temps de saisie acceptable Le temps de saisie quotidien visé est de : - 5 à 15 minutes maximum ; - idéalement réparties dans la journée. Cela impose une attention particulière à l'ergonomie. --- ## 5. Données à suivre ### 5.1 Sommeil Le sommeil principal doit être géré dans une entité dédiée rattachée à la journée logique. Données suivies : - heure réelle de début ; - heure réelle de fin ; - durée calculée ; - source éventuelle de la donnée ; - score de qualité éventuel. **Remarques** - Le sommeil de la nuit précédente peut commencer la veille mais doit être rattaché à la journée analysée. - Le passage de minuit doit être correctement géré. - Une automatisation via montre ou service tiers pourra être envisagée plus tard. ### 5.2 Siestes Les siestes doivent être gérées comme des enregistrements séparés rattachés à la journée. Données suivies : - heure de début ; - heure de fin ; - durée calculée ; - preset éventuel utilisé pour une saisie rapide. ### 5.3 Sport L'application doit permettre d'enregistrer des sessions de sport avec : - date ; - heure de début ; - heure de fin ou durée ; - catégorie d'activité ; - type d'activité ; - titre et description optionnels. Les mesures spécifiques doivent être stockées séparément sous forme de métriques associées à la session. **Exemples de métriques** - distance = 10 km ; - allure = 10 km/h ; - calories = 500 kcal. **Remarques** - L'intégration avec Strava pourra être étudiée plus tard. - La structure doit rester suffisamment souple pour ajouter d'autres sports. ### 5.4 Lecture L'application doit permettre d'enregistrer des sessions de lecture avec : - date ; - heure de début ; - heure de fin ou durée ; - livre associé ; - titre ou description optionnels. Objectifs : - suivre la régularité ; - voir le temps de lecture dans le temps ; - savoir quels livres sont en cours. ### 5.5 Écriture L'application doit permettre d'enregistrer des sessions d'écriture. Deux logiques doivent être distinguées : - l'écriture quotidienne comme habitude ; - l'écriture de production orientée travail ou création. Données à suivre : - date ; - heure de début ; - heure de fin ou durée ; - type d'écriture ; - titre ou description optionnels. Exemples de types : - journal ; - travail ; - créatif ; - notes ; - autre. ### 5.6 Téléphone L'application doit permettre de suivre : - le temps d'écran total ; - le nombre de déverrouillages ou consultations. **Remarques** - En V1, la saisie peut être manuelle. - Une récupération automatisée pourra être étudiée plus tard si faisable. ### 5.7 Hydratation L'application doit permettre de suivre l'hydratation sous forme d'entrées historisées rattachées à la journée. Données suivies : - instant de consommation ; - volume consommé en ml ; - preset éventuel utilisé. L'application doit aussi permettre de configurer des presets réutilisables, par exemple : - bouteille 500 ml ; - verre 250 ml ; - gourde 750 ml. ### 5.8 État subjectif L'application doit intégrer une évaluation subjective de l'état du jour dans une entité dédiée. Variables suivies : - état émotionnel ; - état physique ; - état mental. Format : - note sur 10 pour chaque variable. Ces scores sont essentiels, car ils serviront plus tard de variables de comparaison pour les analyses. --- ## 6. Besoins fonctionnels détaillés ### 6.1 Authentification L'application doit inclure : - inscription ; - connexion ; - déconnexion ; - gestion sécurisée du mot de passe. ### 6.2 Gestion de la journée en cours L'utilisateur doit pouvoir : - voir la journée du jour ; - créer automatiquement une journée si elle n'existe pas ; - modifier les données déjà saisies ; - compléter la journée en plusieurs fois ; - ajouter rapidement des sessions ; - ajouter rapidement une hydratation via preset ; - enregistrer une sieste ; - consulter ses scores du jour. ### 6.3 Historique L'utilisateur doit pouvoir : - consulter les jours précédents ; - afficher le détail d'une journée ; - naviguer par période ; - repérer visuellement l'état de complétion d'une journée. ### 6.4 Gestion des sessions L'utilisateur doit pouvoir : - créer une session ; - modifier une session ; - supprimer une session ; - associer une session à une catégorie ; - associer une session à un type ; - associer des métriques à une session ; - lier une session de lecture à un livre. ### 6.5 Statistiques L'utilisateur doit pouvoir consulter : - des graphiques d'évolution ; - des moyennes ; - des records ; - des séries de jours ; - des comparaisons de périodes ; - la progression par rapport à des objectifs. ### 6.6 Objectifs L'utilisateur doit pouvoir définir des objectifs simples, par exemple : - dormir un certain minimum ; - limiter le temps d'écran ; - faire un certain volume de sport ; - maintenir une habitude de lecture ou d'écriture ; - atteindre un volume d'hydratation journalier. --- ## 7. Besoins d'analyse ### 7.1 V1 : statistiques descriptives La première version doit prioriser : - l'enregistrement fiable des données ; - la visualisation claire ; - la motivation par les graphiques. **Indicateurs attendus en V1** - évolution par jour ; - agrégation par semaine ; - agrégation par mois ; - moyennes ; - records ; - séries. ### 7.2 V2 : analyses croisées La deuxième version devra permettre : - des comparaisons entre facteurs ; - des associations entre comportements et scores subjectifs ; - des analyses simples sur les horaires ; - des premiers constats automatiques. **Exemples** - moyenne mentale les jours avec sport vs sans sport ; - moyenne émotionnelle selon le temps d'écran ; - impact apparent du coucher tardif ; - influence d'une activité démarrée tôt dans la journée. ### 7.3 Limite importante Les analyses ne devront pas être formulées comme des certitudes causales. Le système devra parler de : - corrélations ; - associations ; - patterns ; - tendances. Pas de : - diagnostic certain ; - preuve scientifique ; - causalité démontrée. --- ## 8. Découpage par versions ### 8.1 V1 — Collecte et visualisation La V1 doit inclure : - authentification ; - dashboard du jour ; - entrée journalière pivot ; - sommeil principal ; - siestes ; - scores journaliers ; - hydratation ; - presets ; - gestion des sessions ; - gestion des métriques de session ; - livres ; - historique ; - graphiques ; - moyennes ; - records ; - séries ; - objectifs simples. ### 8.2 V2 — Corrélations et analyse La V2 doit inclure : - analyses croisées ; - corrélations simples ; - constats automatiques ; - lecture des influences potentielles. ### 8.3 V3 — Automatisation et enrichissement La V3 pourra inclure : - Strava ; - imports automatiques de sommeil ; - exports CSV ou JSON ; - recommandations personnalisées ; - activités additionnelles ; - analyses plus avancées. --- ## 9. Écrans à prévoir ### 9.1 Écran de connexion / inscription Fonction : accès sécurisé à l'application. ### 9.2 Dashboard du jour Fonction : point d'entrée principal ; visualisation de la journée en cours ; ajout rapide d'informations ; accès rapide aux sessions. Contenu possible : - résumé sommeil ; - résumé téléphone ; - scores du jour ; - hydratation du jour ; - progression des objectifs ; - sessions du jour ; - niveau de complétion. ### 9.3 Écran de détail de journée Fonction : consulter et modifier les données rattachées à une journée. ### 9.4 Écran de gestion des sessions Fonction : ajouter, modifier, supprimer des sessions d'activité et leurs métriques. ### 9.5 Historique Fonction : consulter les journées passées ; naviguer dans le temps ; voir les résumés. ### 9.6 Écran statistiques Fonction : visualiser l'évolution des données ; comparer des périodes ; observer les records et séries. ### 9.7 Paramètres Fonction : gérer les objectifs ; gérer les presets ; préparer les futures intégrations. --- ## 10. Principes UX ### 10.1 Ergonomie générale L'application doit rester légère à utiliser. Elle ne doit pas reposer sur un formulaire unique trop lourd. ### 10.2 Saisie modulaire La saisie doit être divisée en blocs ou cartes indépendantes : - sommeil ; - siestes ; - téléphone ; - état subjectif ; - hydratation ; - sessions. ### 10.3 Complétion progressive Chaque bloc doit pouvoir être : - ouvert séparément ; - modifié rapidement ; - sauvegardé sans valider toute la journée. ### 10.4 Motivation visuelle Comme l'utilisateur aime les statistiques, l'interface doit valoriser : - la progression ; - les séries ; - les records ; - les écarts avec les objectifs ; - les tendances récentes. --- ## 11. Contraintes techniques ### 11.1 Type d'application - application web ; - responsive ; - usage mobile web possible ; - pas d'application iOS native en priorité. ### 11.2 Stack retenue Le projet est désormais cadré sur la stack suivante : - **Laravel** pour le backend applicatif ; - **Blade** pour le rendu serveur dans la V1 ; - **Laravel Breeze** pour l'authentification ; - **Eloquent ORM** pour la modélisation et les relations ; - **migrations Laravel** comme source de vérité du schéma ; - **MariaDB / MySQL** pour la base de données. ### 11.3 Architecture attendue L'architecture doit être : - propre ; - modulaire ; - maintenable ; - évolutive. Le projet doit être structuré autour de domaines clairs : - authentification ; - journées ; - sommeil ; - hydratation ; - sessions d'activité ; - statistiques ; - objectifs. ### 11.4 Évolutivité La structure doit permettre : - l'ajout de nouvelles catégories d'activité ; - l'ajout d'intégrations externes ; - l'ajout d'analyses plus avancées ; - l'ajout d'exports. --- ## 12. Règles métier principales ### 12.1 Journée - un utilisateur ne doit avoir qu'une seule entrée journalière par date ; - une journée peut être créée automatiquement à la première saisie ; - une journée peut rester incomplète ; - une journée doit rester modifiable ; - `daily_entry` sert d'ancre logique aux autres données du jour. ### 12.2 Sommeil - une journée peut posséder 0 ou 1 sommeil principal ; - le sommeil principal peut commencer la veille ; - la durée doit être calculée automatiquement ; - la journée de rattachement est explicite et ne doit pas être déduite uniquement à partir de la date de début. ### 12.3 Siestes - une journée peut posséder 0 à n siestes ; - chaque sieste appartient à une journée ; - la durée doit être calculée automatiquement si possible. ### 12.4 Sessions - une session appartient à une journée ; - une session appartient à une catégorie ; - une session peut appartenir à un type ; - une session doit avoir un début ; - une fin ou une durée est fortement recommandée ; - la durée doit être calculée automatiquement si possible ; - une session peut posséder 0 à n métriques. ### 12.5 Scores subjectifs - une journée peut posséder 0 ou 1 ensemble de scores ; - les notes doivent suivre une convention unique ; - la convention retenue en V1 est une note sur 10. ### 12.6 Hydratation - une journée peut posséder 0 à n entrées d'hydratation ; - une entrée peut être créée manuellement ou via preset ; - le volume réellement consommé doit être conservé indépendamment du preset. ### 12.7 Objectifs - un objectif peut être journalier ou hebdomadaire ; - l'état d'avancement doit pouvoir être calculé automatiquement. --- ## 13. Orientations de modélisation ### 13.1 Principe fondamental La base de données ne doit pas être conçue comme une seule table géante. `daily_entry` doit rester une entité pivot minimale, et les domaines métier doivent être séparés dans des entités dédiées. ### 13.2 Entités fonctionnelles retenues - utilisateur ; - entrée journalière ; - sommeil principal ; - siestes ; - scores journaliers ; - presets ; - entrées d'hydratation ; - catégories d'activité ; - types d'activité ; - sessions d'activité ; - métriques de session ; - livres ; - objectifs. ### 13.3 Importance des horaires Les horaires doivent être conservés pour permettre, plus tard : - l'étude de l'effet du matin ; - l'étude de la régularité ; - l'analyse de certains déclencheurs comportementaux. --- ## 14. Risques projet ### 14.1 Risques fonctionnels - vouloir suivre trop de choses trop tôt ; - rendre la saisie trop lourde ; - perdre l'intérêt quotidien à cause d'une UX trop lente. ### 14.2 Risques techniques - sur-généraliser certaines structures trop tôt ; - mal distinguer données journalières et sessions ; - sous-estimer les besoins futurs d'analyse ; - rendre les statistiques difficiles à calculer. ### 14.3 Risques analytiques - vouloir conclure trop vite ; - confondre corrélation et causalité ; - produire des diagnostics non fiables. --- ## 15. Critères de réussite L'application sera considérée comme réussie si : - elle est utilisée régulièrement ; - la saisie quotidienne reste acceptable ; - les graphiques sont réellement motivants ; - les statistiques sont lisibles ; - les données permettent de mieux orienter les décisions ; - les faiblesses récurrentes deviennent visibles ; - les bonnes habitudes ressortent clairement. --- ## 16. Conclusion Le projet doit être développé avec une progression claire : 1. bien collecter les données ; 2. bien les visualiser ; 3. ensuite seulement les analyser. La stack Laravel a été retenue pour fournir une base propre de développement, de migrations, d'authentification et de modélisation des relations. --- ## 17. Résumé exécutable du périmètre V1 ### V1 inclut - auth Laravel ; - journée du jour ; - sommeil principal ; - siestes ; - scores émotionnel / physique / mental ; - hydratation historisée ; - presets utilisateur ; - sessions sport ; - sessions lecture ; - sessions écriture ; - métriques de session ; - livres ; - historique ; - graphiques ; - moyennes ; - records ; - séries ; - objectifs simples. ### V1 n'inclut pas en priorité - corrélations avancées ; - diagnostics automatiques poussés ; - imports automatiques ; - export des données ; - recommandations intelligentes ; - nutrition détaillée.