DOC
Accueil/ Projets/ MJY Task Platform/ Product Backlog - Plateforme MJY Holding

Product Backlog - Plateforme MJY Holding

Ce backlog contient les fonctionnalités (User Stories) issues du brief technique et fonctionnel de la Plateforme MJY Holding, estimées et classées par priorité.

🔒 Epic 1 : Gestion des Rôles et de l'Authentification

US1.1 : Authentification par code PIN

  • En tant que membre de l'équipe (Super Admin, Manager ou Collaborateur)
  • Je veux me connecter rapidement en cliquant sur mon nom et en saisissant un code PIN à 4 chiffres
  • **Afin d'**accéder à mon espace de travail sécurisé sur n'importe quel appareil
  • Critères d'acceptation :
    • Authentification Supabase native (auth.users + bcrypt géré par Supabase) : le PIN à 4 chiffres est le mot de passe du compte - aucun hashage manuel, aucun JWT custom (ADR 0002). Rôles réels en base : super_manager / manager / employee.
    • Connexion par roster : GET /api/roster liste les prénoms + rôle + projets (jamais d'email) ; le clic sur un nom + PIN déclenche POST /api/login (résolution email + signInWithPassword côté serveur).
    • PIN par défaut selon le rôle : super_manager 9999, manager 1052, employee 4011. Le compte principal admin@engwe-france.fr (un super_manager) obtient un rôle admin virtuel côté client (jamais stocké en base) ouvrant la vue globale.
    • Changement de PIN self-service : supabase.auth.updateUser ; le nouveau PIN doit différer du défaut ; flag member.pin_customized (indicateur 🔒).
    • La session de connexion doit rester strictement locale au navigateur (jamais synchronisée).

US1.3 : Gestion des emails des membres par le super-admin (sprint ultérieur)

  • En tant que super-admin (super_manager)
  • Je veux pouvoir modifier l'adresse email de n'importe quel membre ainsi que la mienne
  • Afin de corriger/mettre à jour les identifiants de connexion sans repasser par un seed
  • Critères d'acceptation :
    • Le super-admin peut éditer l'email de tout membre (via Admin API auth.admin.updateUserById, côté serveur/Edge Function).
    • Le super-admin peut modifier son propre email.
    • Non prioritaire pour le Sprint 05 (le seed suffit à l'initialisation) - planifié dans un sprint dédié.

US1.2 : Row Level Security (RLS) et permissions

  • En tant que commanditaire du système
  • Je veux que la base de données restreigne l'accès aux données selon le profil connecté
  • **Afin d'**éviter toute fuite d'information ou modification non autorisée
  • Critères d'acceptation :
    • RLS basée sur auth.uid() (JWT natif, pas de claim custom) via des fonctions SECURITY DEFINER (auth_role, my_project_ids) - voir docs/supabase_schema.sql et docs/features/sql/05_rls_policies.sql.
    • Le super_manager (et le compte admin virtuel) peut tout voir et tout modifier.
    • Chaque manager voit et modifie les tâches des projets dont il est membre (périmètre projet, décision Sprint 05).
    • Les collaborateurs voient uniquement les tâches dont ils sont owner (owner = auth.uid()), sans visibilité sur le reste.

📋 Epic 2 : Gestion Collaborative des Tâches et Projets (Temps Réel)

US2.1 : Synchronisation Temps Réel (Supabase Realtime)

  • En tant que collaborateur travaillant en équipe
  • Je veux que les modifications de tâches (création, changement de statut, notes) faites par mes collègues s'affichent instantanément sans recharger la page
  • **Afin d'**éviter de travailler sur des informations obsolètes
  • Critères d'acceptation :
    • Toute tâche créée sur le navigateur A apparaît sur le navigateur B en moins de 5 secondes.
    • Les données survivent au vidage de cache et à la navigation privée.

US2.2 : Cycle de vie et statuts des tâches

  • En tant que responsable d'une tâche
  • Je veux pouvoir changer rapidement le statut d'une tâche (À faire / En cours / Terminé) et sa priorité (Bloquant / Haute / Normale)
  • Afin de tenir mon équipe informée de mon avancement
  • Critères d'acceptation :
    • Changement rapide possible via des boutons ou des clics directs.
    • Indication visuelle claire des priorités (badges colorés) et des dates d'échéance (badges de retard/urgence).

US2.3 : Workflow de validation des tâches collaborateurs

  • En tant que collaborateur effectuant mes tâches assignées
  • Je veux que lorsque je marque comme "Terminée" une tâche que j'ai créée moi-même, elle passe par une étape de validation par mon manager
  • **Afin d'**assurer un contrôle qualité sur mes livrables
  • Critères d'acceptation (double validation : à la création ET à la complétion) :
    • Validation à la création : une tâche créée par un collaborateur démarre au statut pending_validation. Elle doit être validée par un manager ou super-admin du projet avant de passer à todo (à faire). Le collaborateur ne peut pas la sortir de pending_validation lui-même (ni vers todo, ni vers in_progress).
    • Cycle après validation : todo → in_progress (quand le collaborateur commence) → demande de done.
    • Validation à la complétion : quand un collaborateur passe sa tâche à "fini", elle rebascule en pending_validation. Un manager/super-admin du projet peut alors approuver (→ done) ou rejeter (→ in_progress).
    • Une tâche créée par un manager/super-admin suit directement todo → in_progress → done (pas de pending_validation).
    • Périmètre : « manager du projet » = tout manager membre du projet via project_members (périmètre projet, pas seulement le manager explicitement assigné).
    • Ces règles de transition sont imposées côté base par un trigger enforce_task_workflow (voir docs/features/sql/07_task_workflow.sql), pas seulement par l'UI.

US2.4 : Journal de notes collaboratif par tâche

  • En tant que membre assigné à une tâche
  • Je veux pouvoir ajouter des notes/commentaires dans le journal interactif de la tâche
  • Afin de documenter les blocages, poser des questions et collaborer
  • Critères d'acceptation :
    • Chaque note est enregistrée avec son auteur, son rôle et la date.
    • Le journal est trié du plus récent au plus ancien.
    • La modification concurrente de deux notes de tâches différentes ne doit générer aucun conflit d'écriture.

🗂️ Epic 3 : Structuration par Projets et Phases

US3.1 : Espaces de travail multi-projets

  • En tant que Super Admin ou Manager
  • Je veux pouvoir configurer des projets distincts avec un nom, une couleur et un emoji personnalisables
  • Afin de séparer proprement les activités des différentes filiales (Miyan Noodles, ENGWE France, etc.)
  • Critères d'acceptation :
    • Filtre global par projet disponible dans le bandeau supérieur.
    • Initialisation des projets par défaut (Miyan Noodles et ENGWE France).

US3.2 : Planification par phases (timeline J→J)

  • En tant que manager planifiant un projet
  • Je veux organiser les tâches sous forme de phases chronologiques avec des plages de dates relatives (J1 → Jn)
  • **Afin d'**avoir un suivi d'avancement par étape et une estimation visuelle de la progression
  • Critères d'acceptation :
    • Chaque phase a un nom, un ordre et un range optionnel (J-début → J-fin).
    • Calcul dynamique du pourcentage d'avancement par phase (tâches faites / tâches totales).
    • Interface pour basculer facilement entre la vue Liste et la vue Phases.
    • Modal PhasesManagerModal pour éditer manuellement les phases.

🤖 Epic 4 : Saisie Assistée et Intelligente

US4.1 : Création de tâche par commande vocale

  • En tant que manager sur le terrain (ex: en restaurant chez Miyan Noodles)
  • Je veux dicter une tâche oralement à l'application
  • Afin de la créer instantanément sans avoir à la saisir au clavier
  • Critères d'acceptation :
    • Flux : Choix de la personne -> Enregistrement micro -> Transcription en direct -> Analyse locale des mots clés (ex : "demain", "cette semaine") pour pré-remplir l'échéance -> Relecture et validation finale.

US4.2 : Import de projet structuré par IA

  • En tant que Super Admin
  • Je veux coller un texte en vrac (compte-rendu de réunion, email, plan d'action) pour que l'IA en extrait automatiquement les projets, les phases, les tâches, les priorités et les responsables
  • Afin de générer un projet complet en un clic
  • Critères d'acceptation :
    • Intégration avec n8n pour orchestrer l'agent IA (LangChain) et le modèle LLM (OpenRouter).
    • Validation des permissions d'accès via requête Supabase effectuée depuis n8n.
    • Aperçu structuré avant création définitive (ImportTemplateModal) avec édition des priorités, échéances et responsables.
    • Support du mode "déterministe" (CSV, Markdown) comme alternative ou en cas de panne de l'API.

💾 Epic 5 : Sauvegarde et Métriques

US5.1 : Export / Sauvegarde des tâches (CSV + JSON, portée par rôle) - refondue Sprint 06

  • En tant que dirigeant / manager / collaborateur
  • Je veux exporter mes tâches en CSV (ré-importable, format template ADR 0008) et en JSON exhaustif
  • Afin de conserver des sauvegardes et échanger des listes de tâches hors ligne
  • Critères d'acceptation :
    • Boutons ⬇️ CSV / ⬇️ JSON (ExportButtons) dans les 3 dashboards.
    • CSV aligné sur le template d'import (;, UTF-8 BOM) + colonnes de contexte ; aller-retour vérifié (un export CSV est ré-importable).
    • JSON exhaustif (champs + notes + relations résolues) ; exclusion stricte des jetons de session et clés API.
    • Portée par rôle (filterTasksByRole, cohérente RLS) : admin/super_manager → tout ; manager → siennes + créées/à valider ; employee → siennes uniquement.
    • (La sauvegarde/restauration JSON globale historique reste disponible via BackupButtons.)

US5.2 : Tableau de bord de statistiques

  • En tant que Super Admin ou Manager
  • Je veux voir des indicateurs clés (Total, À faire, En cours, Terminées, En retard) sous forme de KPI interactifs servant de filtres
  • **Afin d'**analyser instantanément la santé opérationnelle des projets