DOC
Accueil/ Projets/ MJY Task Platform/ Sprint Backlog - Sprint 04 (SPRINT D'URGENCE) - [STATUT : CLOS]

Sprint Backlog - Sprint 04 (SPRINT D'URGENCE) - [STATUT : CLOS]

Période : Du 07/07/2026 au 11/07/2026 (5 jours - sprint court de stabilisation) Type : 🚨 Sprint correctif d'urgence (Hotfix / Dette technique) Déclencheur : Audit technique complet du 07/07/2026 + Audit synchronisation Supabase

🎯 Objectif Principal (Sprint Goal)

Corriger en priorité les anomalies critiques (plantages React, corruption d'affichage des notes, failles d'authentification) et la dette d'architecture majeure (logique métier non extraite, backend dupliqué, workflow de dev cassé) identifiées par l'audit, puis réaligner la documentation sur l'état réel du code.

⚠️ Contexte : la revue du Sprint 03 déclarait la story US-Auth-02 « supprimer les PIN codés en dur » comme terminée à 100 %. L'audit démontre que les PIN restent en dur dans src/utils/taskHelpers.js et affichés dans l'UI (Auth.jsx), et stockés en clair en base. Cette régression/incomplétude est reprise en priorité 1 dans ce sprint.

🧭 Portée & priorisation

Les items sont classés selon la gravité issue de l'audit : 🔴 Critique, 🟠 Majeur, 🟡 Hygiène. Chaque story référence les identifiants de l'audit (C1–C4, M1–M6).

📋 Stories Sélectionnées pour le Sprint

🔴 Bloc 1 - Correctifs critiques (à livrer en premier)

  1. US-FIX-01 : Stabilité du rendu React (Error #310) - 3 SP

    • Réf. audit : C1
    • Description : Supprimer tous les appels setState effectués pendant le rendu de App.jsx (setEmployeeMode(false) L166, onLogout() L181). Déplacer la logique de garde de rôle dans des useEffect.
    • Critère d'acceptation : aucun avertissement React « Cannot update a component while rendering », plus aucune boucle de re-rendu au changement de rôle.

  2. US-FIX-02 : Intégrité de l'horodatage des notes - 1 SP

    • Réf. audit : C2
    • Description : Uniformiser le champ de date des notes de tâche sur date (création + affichage dans TaskDetail.jsx), aligné sur storage.js et la table task_notes.
    • Critère d'acceptation : une note affiche une date valide après un aller-retour cloud / rafraîchissement Realtime (plus de « Invalid Date »).

  3. US-SEC-03 : Durcissement de l'authentification - 5 SP

    • Réf. audit : C3, C4, M2
    • Description :
      • Retirer ADMIN_PIN, EMPLOYEE_PIN, SUPER_MANAGER_PIN et les PIN affichés de taskHelpers.js / Auth.jsx.
      • Hacher les PIN en base (pin_hash, bcrypt) et vérifier le hash côté serveur.
      • Faire échouer le démarrage backend si SUPABASE_JWT_SECRET est absent (supprimer le fallback 'secret').
      • Unifier une source unique de la liste des administrateurs (base de données) - supprimer la divergence client (@gmail/@hotmail) vs serveur (@myj.com).
    • Critère d'acceptation : aucun secret d'authentification présent dans le bundle client ; impossible de forger un JWT sans le vrai secret ; rôle admin cohérent entre UI et token.

🟠 Bloc 2 - Architecture & dette majeure

  1. US-ARCH-04 : Extraction des hooks et du contexte applicatif - 8 SP

    • Réf. audit : M3 + « code au mauvais endroit » (§2.3)
    • Description : Créer src/hooks/ (useAuth, useTasks, useProjects, useMembers, useRealtime) et src/context/AppContext.jsx. Déplacer la logique métier hors des pages ; dédupliquer saveMember/deleteMember/saveProject/deleteProject entre AdminDashboard et SuperManagerDashboard. Remplacer le hack window.__forceAppRerender par le contexte.
    • Critère d'acceptation : hooks/ et context/ peuplés ; zéro duplication de CRUD entre les deux dashboards ; window.__forceAppRerender supprimé.

  2. US-BE-05 : Factorisation du backend dupliqué - 3 SP

    • Réf. audit : M1
    • Description : Extraire la logique commune (signJWT, requêtes members, calcul du rôle) dans un module partagé importé à la fois par server.js et netlify/functions/*.
    • Critère d'acceptation : une seule implémentation de l'authentification, plus de copier-coller entre les deux cibles d'hébergement.

  3. US-DX-06 : Réparation du workflow de développement - 2 SP

    • Réf. audit : M4
    • Description : Ajouter un server.proxy /api dans vite.config.js (ou documenter netlify dev) pour que npm run dev serve les endpoints d'auth et public_data.
    • Critère d'acceptation : la connexion par PIN fonctionne en npm run dev.

  4. US-PERF-07 : Optimisation de la synchronisation Supabase - 3 SP

    • Réf. audit : M5 + audit Supabase
    • Description : Remplacer les upsert unitaires en boucle par des upsert par lot (batch) dans writeToSupabase ; cibler le pullFromSupabase déclenché par Realtime sur la table/le projet concerné plutôt qu'un pull global.
    • Critère d'acceptation : une sauvegarde de projet de 50 tâches génère un nombre de requêtes constant (≤ quelques appels), pas 50+.

🟡 Bloc 3 - Imports & hygiène

  1. US-IMP-08 : Imports statiques & outillage qualité - 2 SP

    • Réf. audit : §3 (imports), MI2
    • Description : Convertir les import() dynamiques redondants d'App.jsx / Auth.jsx en imports statiques en tête de fichier. Ajouter ESLint + eslint-plugin-react-hooks (qui aurait détecté C1) et Prettier.
    • Critère d'acceptation : plus aucun import() dynamique inutile ; npm run lint passe sans erreur.

  2. US-DOC-09 : Réalignement documentaire - 2 SP

    • Réf. audit : M6, MI1, MI7, MI8
    • Description : Mettre à jour README.md (retirer « KOBIKE », polling « 4 s »), le schéma dans audit/audit_refactoring.md, les textes obsolètes de SyncMenu.jsx (Netlify Blobs / polling), nettoyer cloudClient/pollCloud/console.*, renommer VITE_ANTHROPIC_API_KEY → ANTHROPIC_API_KEY.
    • Critère d'acceptation : la documentation décrit l'architecture réellement en place.

📊 Capacité & Engagement

Bloc Stories Effort
🔴 Critiques US-FIX-01, US-FIX-02, US-SEC-03 9 SP
🟠 Majeurs US-ARCH-04, US-BE-05, US-DX-06, US-PERF-07 16 SP
🟡 Hygiène US-IMP-08, US-DOC-09 4 SP
Total 9 stories 29 SP

⚖️ Engagement de sprint : le Bloc 1 (9 SP) est un engagement ferme (must). Les blocs 2 et 3 sont stretch goals : en cas de manque de capacité sur un sprint court de 5 jours, US-ARCH-04 (8 SP) peut être scindé et reporté au Sprint 05, les critiques restant prioritaires.

✅ Definition of Done du sprint

Conforme à definition_of_done.md, et en particulier pour ce sprint :

  • Les 3 stories critiques (Bloc 1) sont livrées, testées et vérifiées manuellement.
  • La suite npm run test passe ; le build npm run build réussit.
  • Aucun secret d'authentification dans le bundle client.
  • La documentation impactée est à jour.

🔗 Références