DOC
Accueil/ Projets/ MJY Task Platform/ Sprint Backlog - Sprint 05 (Refonte de l'authentification par utilisateur) - [STATUT : CLOS avec résidus, voir sprint_review.md]

Sprint Backlog - Sprint 05 (Refonte de l'authentification par utilisateur) - [STATUT : CLOS avec résidus, voir sprint_review.md]

Période : Du 15/07/2026 au 25/07/2026 (2 semaines) Type : 🔐 Refonte d'architecture d'authentification (Supabase Auth natif) Sources : Handoff migration Supabase · BRIEF PLATEFORME MJY · Audit synchronisation Supabase

🎯 Objectif Principal (Sprint Goal)

Donner à chaque utilisateur son propre compte d'authentification et livrer les trois parcours d'identité de bout en bout - se connecter, être inscrit/créé, changer son code PIN - en migrant de la couche JWT « maison » actuelle vers Supabase Auth natif (auth.users + bcrypt), avec les rôles réels du brief (super_manager / manager / employee) et une relation membre ↔ projet multi-projets (table pivot project_members).

⚠️ Contexte / dette à corriger. L'implémentation actuelle est la « dérive » identifiée dans le handoff :

  • netlify/functions/auth.js signe un JWT custom (HS256, claim user_role) au lieu d'utiliser la session Supabase native, et émet les rôles admin/employee - admin n'existe pas dans le brief (super_manager/manager/employee).
  • La table members (pluriel) porte un project_id unique → un membre = un seul projet, alors que le brief impose le multi-projets via pivot.
  • Le PIN Super Manager 9999 est codé en dur dans auth.js, et la liste GLOBAL_ADMIN_EMAILS duplique SUPER_ADMIN_EMAILS côté client.
  • Aucun parcours d'inscription ni de changement de PIN self-service n'existe. Ce sprint abandonne cette dérive et repart sur la cible validée au §2 du handoff.

🧭 Portée & priorisation

Les items sont classés : 🔴 Fondation (bloquant les autres), 🟠 Parcours utilisateur, 🟡 Sécurité & alignement. Chaque story référence les décisions du handoff (H§n).

📋 Stories Sélectionnées pour le Sprint

🔴 Bloc 1 - Fondation base de données & schéma cible

  1. US-AUTH-01 : Nettoyage de la base et schéma cible auth.users - 5 SP
    • Réf. : H§3, H§4, H§6, 01_cleanup.sql, 02_schema.sql
    • Description :
      • Sauvegarder l'état Supabase de test (Dashboard → Backups ou pg_dump) avant tout DROP.
      • Exécuter 01_cleanup.sql : supprime à la fois les objets du plan validé et tous ceux de la dérive (tables au pluriel, pin_hash, triggers hash_member_pin, fonctions verify_member_pin/jwt_user_role/jwt_user_email/is_project_manager/is_project_member, policies orphelines).
      • Recréer le schéma cible : member (id = auth.users.id), project, project_members (pivot N-N), phase, task, task_notes - avec les CHECK sur member.role, task.status, task.priority et les trois FK distinctes created_by/manager/owner.
      • Trigger touch_updated_at() sur task.
    • Critère d'acceptation : les requêtes de contrôle en fin de 01_cleanup.sql renvoient vide/zéro ; member.role n'accepte que super_manager/manager/employee ; un membre peut être rattaché à plusieurs projets via project_members.

🟠 Bloc 2 - Les trois parcours d'identité (le cœur du sprint)

  1. US-AUTH-02 : Connexion de chaque utilisateur via Supabase Auth natif - 5 SP

    • Réf. : H§2, H§8 (session PIN locale)
    • Description :
      • Remplacer l'appel /api/auth + signJWT custom par supabase.auth.signInWithPassword({ email, password: pin }).
      • Le Super Manager devient un compte réel (admin@mjyholding.fr ou équivalent), PIN 9999 = mot de passe - plus de branche super@manager codée en dur.
      • La session repose sur le JWT Supabase natif ; persistSession conserve la session localement au navigateur (exigence brief : jamais synchronisée).
      • Supprimer setSessionToken / la reconstruction manuelle du client dans supabaseClient.js : un seul client, la session est portée nativement.
    • Critère d'acceptation : un manager, un collaborateur et le super manager se connectent chacun avec leur propre PIN individuel ; aucun secret d'authentification ni PIN codé en dur dans le bundle client ; la session survit à un rechargement mais reste locale.

  2. US-INSCR-03 : Inscription / création de membre par un administrateur - 5 SP

    • Réf. : H§2 (PIN par défaut), H§6 (create-member), 03_seed-members.js
    • Description :
      • Edge Function create-member : vérifie que l'appelant authentifié est super_manager/manager, crée le compte via Admin API (auth.admin.createUser, PIN par défaut selon le rôle : employee→4011, manager→1052, super_manager→9999), puis insère dans member + project_members.
      • Script 03_seed-members.js (service_role) pour recréer le super admin et les premiers membres connus avec leurs PIN par défaut. La liste réelle des membres/emails doit être confirmée avec Marco avant exécution (placeholders prenom@mjyholding.fr).
      • Brancher le MemberModal existant sur create-member à la place de l'écriture directe localStorage/members.
    • Critère d'acceptation : un manager peut créer un membre, choisir son rôle et le rattacher à un ou plusieurs projets ; le nouveau membre peut se connecter avec le PIN par défaut de son rôle ; un appelant non-manager reçoit 403.

  3. US-PIN-04 : Modification du code PIN en self-service - 3 SP

    • Réf. : H§2 (changement de PIN)
    • Description :
      • Écran/modale « Changer mon code PIN » accessible à tout utilisateur connecté, appelant supabase.auth.updateUser({ password: newPin }).
      • Validation : PIN à 4 chiffres, confirmation, refus si identique au PIN par défaut du rôle (incitation à personnaliser).
      • Indicateur 🔒 « code personnalisé » là où l'UI l'affiche déjà, dérivé d'un flag serveur et non du PIN en clair (qui n'existe plus côté client).
    • Critère d'acceptation : un utilisateur change son PIN, se déconnecte, se reconnecte avec le nouveau PIN ; l'ancien PIN (y compris le PIN par défaut partagé) est refusé après changement.

🟡 Bloc 3 - Sécurité, temps réel & alignement

  1. US-RLS-05 : RLS par rôles réels + Realtime - 3 SP

    • Réf. : H§5, brief §5-6
    • Description :
      • Appliquer les policies RLS basées sur auth.uid() (pas de claim custom) : super_manager voit tout ; manager voit created_by = auth.uid() OR manager = auth.uid() OR owner = auth.uid() ; employee voit owner = auth.uid().
      • Étendre aux écritures et à task_notes/project_members de façon cohérente.
      • Activer Realtime sur task et task_notes ; déléguer la visibilité isMine à la RLS plutôt qu'au filtre client.
    • Critère d'acceptation : un collaborateur ne reçoit via l'API/Realtime que les tâches dont il est owner ; un manager ne voit que son périmètre ; le super manager voit tout - vérifié avec trois sessions distinctes.

  2. US-AUTH-06 : Refonte front-end de la couche session - 5 SP

    • Réf. : H§8 (remplacement localStorage), Auth.jsx, App.jsx, storage.js
    • Description :
      • Réécrire Auth.jsx : listes de membres alimentées par une lecture member/project_members (ou public_data refondu) au lieu de INIT_MEMBERS/localStorage ; sélection du nom → saisie PIN → signInWithPassword.
      • Remplacer saveS("session_token") / session_created_at par supabase.auth.getSession() ; retirer window.__forceAppRerender.
      • Retirer SUPER_ADMIN_EMAILS/GLOBAL_ADMIN_EMAILS (le rôle vient désormais de member.role, source unique).
      • Adapter EmployeeDashboard/AdminDashboard/SuperManagerDashboard au rôle issu de la session Supabase.
    • Critère d'acceptation : plus aucune référence à signJWT/user_role custom/super@manager dans le code ; le routage par rôle fonctionne à partir de la session Supabase native ; npm run build réussit et npm run test passe.

  3. US-DOC-07 : Réalignement documentaire & backlog - 2 SP

    • Réf. : H§7
    • Description : Mettre à jour product_backlog.md (US1.1/US1.2 : rôles réels, comptes individuels, RLS auth.uid()), README.md, le schéma docs/supabase_schema.sql, et documenter la procédure d'inscription + changement de PIN. Marquer comme superseded les tâches du Sprint 04 bis fondées sur la dérive (pin_hash/verify_member_pin, cf. §Références).
    • Critère d'acceptation : la documentation décrit l'architecture auth.users réellement en place ; aucune mention résiduelle des rôles admin ou du JWT custom.

📊 Capacité & Engagement

Bloc Stories Effort
🔴 Fondation US-AUTH-01 5 SP
🟠 Parcours utilisateur US-AUTH-02, US-INSCR-03, US-PIN-04 13 SP
🟡 Sécurité & alignement US-RLS-05, US-AUTH-06, US-DOC-07 10 SP
Total 7 stories 28 SP

⚖️ Engagement de sprint : US-AUTH-01 (fondation) + le bloc 2 (les trois parcours connexion / inscription / changement de PIN, 13 SP) forment l'engagement ferme - c'est la demande explicite du sprint. US-RLS-05 et US-AUTH-06 sont prioritaires juste derrière (la refonte front est nécessaire pour exercer les parcours). US-DOC-07 peut déborder sur le début du Sprint 06 si nécessaire.

🚧 Dépendances & décisions à trancher (bloquantes)

Issues du H§8, à confirmer avec Marco/Julien avant exécution :

  1. Liste réelle des membres et leurs emails (pré-requis de US-INSCR-03 / seed). Les emails actuels (sanceymarco@hotmail.com, j.gros1052@gmail.com, @miyan.fr, @engwefrance.fr) doivent être confirmés comme boîtes réelles ou remplacés par le pattern prenom@mjyholding.fr.
  2. RLS stricte dès le départ vs version permissive temporaire (brief §6 tolère les deux). Défaut retenu ici : stricte (US-RLS-05).
  3. Sort des données existantes (localStorage/Netlify Blobs) : migration ou repart-à-zéro depuis le seed. Défaut retenu : repart du seed (non bloquant pour l'auth).
  4. Articulation avec le Sprint 04 bis : US-MIG-03 (migration pin_hash en prod) et US-TEST-04 (login super@manager) reposent sur la dérive abandonnée ici. Recommandation : ne pas déployer la couche auth actuelle en production ; faire atterrir le Sprint 05 avant tout déploiement d'authentification.

✅ Definition of Done du sprint

Conforme à definition_of_done.md, et en particulier :

  • Les trois parcours (connexion, inscription, changement de PIN) sont livrés, testés manuellement avec trois rôles distincts et vérifiés de bout en bout.
  • Aucun secret d'authentification, PIN codé en dur, ni JWT custom dans le bundle client.
  • Les rôles sont exclusivement super_manager/manager/employee (plus aucun admin).
  • La RLS restreint effectivement la visibilité par rôle (vérifié avec 3 sessions).
  • npm run build réussit ; npm run test passe ; la documentation impactée est à jour.

🔗 Références