Produit sensible · Offline-first · Permissions

    Moodday

    Rendre un suivi personnel fiable sans se faire passer pour un outil clinique.

    Moodday est un compagnon non clinique de suivi de l’humeur et des traitements. La refonte s’est concentrée sur la continuité hors ligne, les rappels multi-horaires, la confidentialité et un partage aidant révocable.

    Role
    Conception produit, UX, architecture et développement full-stack en solo
    Period
    Refonte 2026
    Status
    Release candidate technique · bêta utilisateur à mener
    Moodday — interface principale

    Preuves vérifiables

    122/122

    tests actifs

    Baseline locale vérifiée le 16 juillet 2026

    7 jours

    hors ligne

    Check-ins rejoués jusqu’à Postgres sans doublon

    2 sessions

    parcours aidant

    Invitation, observation, révocation et blocage immédiat

    59

    pages au build

    Build de production de référence

    Lecture des chiffres : Les chiffres décrivent la baseline locale auditée ; ils ne constituent ni une mesure clinique ni une métrique d’adoption.

    Contexte et rôle

    Le produit mélange des actions très courtes — humeur, énergie, prise — et des données que l’utilisateur peut considérer comme intimes.

    La difficulté principale n’était pas d’ajouter des graphiques, mais de garantir qu’une action reste cohérente entre mobile, hors ligne, synchronisation serveur et historique.

    Le périmètre a donc été explicitement limité à un compagnon personnel : aucune formulation diagnostique, aucune recommandation de traitement et aucune promesse médicale.

    Contraintes retenues

    • Ne jamais perdre ni dupliquer un check-in ou une prise après une coupure réseau.
    • Gérer plusieurs horaires, snooze, prises ponctuelles, fuseaux et changement d’heure.
    • Autoriser un aidant uniquement sur une relation active et révocable, pas seulement sur un rôle global.
    • Exporter et supprimer les données sans conserver de résidu hors cascade.
    • Écarter toute donnée médicale, note ou identité d’aidant des analytics.

    Décisions et options rejetées

    DECISION 01

    Une file d’opérations structurée

    Une simple liste locale ne permettait pas d’expliquer les conflits ni de rejouer proprement les actions.

    Choix
    IndexedDB stocke chaque opération avec identifiant, statut, retry borné et résolution explicite des conflits ; le serveur applique une idempotence correspondante.
    Rejeté
    Une queue localStorage opaque et un retry infini en arrière-plan.
    Compromis
    Davantage d’états à tester, mais un diagnostic possible sans exposer le contenu sensible.
    DECISION 02

    Des permissions relationnelles

    Le rôle “aidant” ne suffit pas à savoir quelle personne peut consulter quel suivi.

    Choix
    Les contrôles serveur vérifient invitation, relation, statut et révocation pour chaque route concernée.
    Rejeté
    Masquer les écrans côté client ou autoriser par rôle générique.
    Compromis
    Plus de contrôles et de scénarios E2E, en échange d’une révocation immédiate et explicable.
    DECISION 03

    Un résumé facultatif, jamais un conseil

    Une synthèse peut aider à relire une période, mais une formulation causale serait trompeuse.

    Choix
    Les tendances séparent faits observés et corrélations, avec une synthèse optionnelle non clinique.
    Rejeté
    Un coach IA qui conseille un diagnostic ou une modification de traitement.
    Compromis
    Une promesse marketing plus sobre, cohérente avec la responsabilité réelle du produit.

    Architecture du parcours

    1. 01

      Interface PWA

      Check-in rapide, traitements, tendances et rôle aidant dans cinq destinations principales.

    2. 02

      IndexedDB

      Données locales et opérations rejouables avec statuts, quotas et conflits visibles.

    3. 03

      Actions idempotentes

      Validation, autorisation relationnelle et déduplication côté serveur.

    4. 04

      PostgreSQL / Neon

      Historique durable, exports transactionnels et journal de notifications.

    5. 05

      VAPID + cron

      Planification multi-horaires, claim concurrent et retry borné.

    Qualité et vérifications

    • E2E d’un check-in hors ligne puis d’une semaine complète avec fermeture et réouverture de page.
    • Exports JSON, CSV et PDF téléchargés puis contrôlés automatiquement.
    • Suppression de compte vérifiée jusque dans les tables sans cascade.
    • Matrice de permissions aidant couverte par tests positifs, négatifs, refus et expiration.
    • Migration du journal de notification validée sur branche isolée puis promue sur Neon principal avec diff vide.
    Moodday — vue produit

    Ce qui est réellement livré

    • Un parcours quotidien court et utilisable sans réseau.
    • Une synchronisation observable qui sépare conflit permanent et panne transitoire.
    • Des rappels multi-horaires idempotents, y compris autour des changements d’heure.
    • Un partage aidant limité, explicite et révocable.
    • Un export complet et une suppression sans résidu sur le périmètre actuel.

    Limites assumées

    • Le produit n’est ni un dispositif médical ni un outil diagnostique.
    • La validation d’usage — cinq personnes pendant sept jours sans assistance — n’a pas encore été menée.
    • Le changement de fuseau et le compactage de file demandent encore un durcissement dédié.
    • VAPID et cron doivent être observés en preview puis en production avant une ouverture large.

    Prochaine étape

    • Mener une bêta fermée de sept jours avec cinq personnes et observer uniquement activation, action cœur et erreurs techniques.
    • Tester gros volumes, stockage de fichiers et changement de fuseau.
    • Ajouter un journal d’accès aidant lisible par l’utilisateur.

    Socle technique

    • Next.js 16
    • React 19
    • TypeScript
    • Prisma
    • PostgreSQL / Neon
    • IndexedDB
    • Playwright
    • Web Push