DOC
Accueil/ Projets/ MJY Task Platform/ Sprint Backlog - Sprint 06 (Observabilité & Export de données) - [STATUT : CLÔTURÉ le 09/07/2026]

Sprint Backlog - Sprint 06 (Observabilité & Export de données) - [STATUT : CLÔTURÉ le 09/07/2026]

✅ Clôturé - voir sprint_review.md. Résidu reporté au Sprint 07 : TS6.32 (validation import par Julien & Marco, planifiée après le vendredi soir).

Période : À planifier (post Sprint 05) Type : 🔭 Observabilité (logging) + 💾 Export/Sauvegarde de données + clôture des résidus Sources : ADR 0009 - Logging centralisé · [Plan d'implémentation Logger] · Sprint Review 05 · product_backlog.md (US5.1)

🎯 Objectif Principal (Sprint Goal)

Doter la plateforme d'une observabilité de production via un système de logging centralisé hiérarchique (façon Java/Winston) persistant dans Supabase, et livrer un système d'export/sauvegarde de données (CSV + JSON) à portée définie par rôle. Clôturer les résidus du Sprint 05 et faire valider la fonctionnalité d'import (ADR 0008) par les chefs afin de préparer le déploiement (qui interviendra après ce sprint).

🚫 Hors périmètre (décidé) : le déploiement en production est repoussé après le Sprint 06 (sprint dédié). La refonte de l'écran de connexion (proposition B « écran neutre sans annuaire ») est écartée : on conserve le roster (« clique ton nom + PIN », conforme au brief US1.1).

🧭 Portée & priorisation

Items classés : 🔴 Cœur de sprint (engagement ferme), 🟠 Valeur produit, 🟡 Clôture & qualité.

📋 Stories Sélectionnées pour le Sprint

🔴 Bloc 1 - Système de logging centralisé (ADR 0009)

  1. US-LOG-01 : Table public.app_logs + RLS - 3 SP

    • Réf. : ADR 0009 (§Schéma, §Sécurité), nouveau docs/features/sql/09_create_logs_table.sql
    • Description : créer la table app_logs (id, created_at, level, category, message, description, payload jsonb, user_id, browser_info jsonb). RLS : INSERT ouvert (anon + authentifié), SELECT réservé super_manager, UPDATE/DELETE bloqués (logs immuables).
    • Critère d'acceptation : un client anonyme peut insérer un log ; seul un super_manager peut les lire ; toute tentative d'UPDATE/DELETE échoue.

  2. US-LOG-02 : Cœur du logger front (src/utils/logger.js) - 5 SP

    • Réf. : ADR 0009 (Option B), Plan §4
    • Description : logger autonome, zéro dépendance. Niveaux TRACE→FATAL(+OFF) ; LoggerFactory.getLogger('services.auth') avec héritage hiérarchique par namespace ; transports Console (couleurs CSS), Buffer (500 derniers en mémoire), Supabase (INFO+ uniquement, debounce/batch). Utilitaires : downloadLogs() (fichier .log) et hook useLogger(name).
    • Critère d'acceptation : régler services.auth en DEBUG sans changer le reste ; les logs INFO+ arrivent dans app_logs ; TRACE/DEBUG restent en console/buffer ; export .log fonctionnel.

  3. US-LOG-03 : Interception automatique des appels API - 3 SP

    • Réf. : ADR 0009 (§Zéro boucle), Plan §4 + modif supabaseClient.js
    • Description : wrapper window.fetch pour journaliser méthode/URL/durée/statut ; injecter ce fetch dans l'init du client Supabase (auth + tables tracés). Anti-boucle : ignorer toute requête vers /rest/v1/app_logs.
    • Critère d'acceptation : [INFO] [network] FETCH GET /api/roster SUCCESS in 12ms visible ; l'écriture d'un log ne génère pas de log récursif ; aucun doublon.

  4. US-LOG-04 : Middleware backend Winston/Morgan - 3 SP

    • Réf. : ADR 0009, Plan §5, nouveau middlewares/logger.middleware.js
    • Description : instance Winston (console colorisée + fichiers logs/error.log et logs/combined.log), Morgan streamé dans Winston (ESM). Brancher app.use(morganMiddleware) tôt dans server.js et remplacer les console.* par le logger structuré. npm install winston morgan.
    • Critère d'acceptation : chaque requête Express apparaît dans les logs Winston ; les erreurs vont dans logs/error.log ; démarrage serveur OK.

🟣 Hors périmètre initial - Refonte des rôles (admin virtuel), livrée en cours de sprint

Non planifiée au découpage initial de ce backlog, mais menée en parallèle (outil « antigravity ») pendant la session Bloc 1. Conservée car elle sert de base technique à US-EXP-03 ci-dessous : la matrice admin/super_manager/manager/employee qu'exige l'export par rôle a besoin d'un rôle admin identifiable, or jusqu'ici seuls super_manager/manager/employee existaient réellement (l'ancien rôle admin avait été abandonné en base au Sprint 05). Détail des tâches : tasks.md.

  • Rôle admin virtuel : calculé côté client sur admin@engwe-france.fr, jamais stocké en DB - distingue le compte principal d'un super_manager générique.
  • Renommage AdminDashboard.jsx → ManagerDashboard.jsx (nom fidèle à son usage réel par les managers/super_managers).
  • Import de tâches en self-service pour les collaborateurs (owner forcé sur soi-même).
  • 2 bugs trouvés et corrigés en vérification preview réelle : prop session manquante sur 2 des 3 routes de rendu de SuperManagerDashboard (crash potentiel au changement de PIN, en-tête n'affichant pas le prénom réel de la personne connectée - ex. Julien/Marco voyaient "Super Manager" au lieu de leur nom).
  • ⚠️ Non commité au moment de la rédaction de ce backlog - voir le rapport de session pour le plan de commits proposé.

🟠 Bloc 2 - Export / Sauvegarde de données (refonte US5.1)

  1. US-EXP-01 : Export CSV des tâches (format import étendu) - 3 SP

    • Réf. : ADR 0008, template import_liste_taches
    • Description : exporter les tâches en CSV aligné sur le template d'import, mais plus complet (colonnes additionnelles : Projet, Statut, Phase, Créé par, Date de création, en plus de Tâche/Notes/Assigné à/Responsable/Priorité/Pilier/Échéance). Viser un aller-retour : un export ré-importable par la feature ADR 0008.
    • Critère d'acceptation : le CSV exporté s'ouvre proprement (Excel/Sheets, ;, UTF-8 BOM) ; les colonnes du template d'import y figurent ; ré-importer l'export recrée des tâches cohérentes.

  2. US-EXP-02 : Export JSON complet - 2 SP

    • Description : export JSON exhaustif des tâches (tous les champs + notes + relations projet/phase/membres résolus), pour sauvegarde/restauration. Exclusion stricte de tout secret (jetons de session, clés API).
    • Critère d'acceptation : le JSON contient l'intégralité des champs et des notes ; aucun secret n'y figure.

  3. US-EXP-03 : Portée d'export par rôle - 3 SP

    • Réf. : décision PO (matrice ci-dessous), RLS 05_rls_policies.sql

    • Description : le périmètre exportable dépend du rôle et respecte la RLS (on n'exporte que ce qu'on peut voir) :

      Rôle Périmètre exportable
      admin (compte principal admin@engwe-france.fr) Tout (toutes les tâches de toutes les entités)
      super_manager Ses tâches + les tâches des managers et collaborateurs + celles qu'il a assignées à quelqu'un
      manager Ses tâches + celles qu'il a assignées à d'autres personnes
      employee Ses tâches uniquement

    • Critère d'acceptation : vérifié avec 4 profils - chacun n'exporte que son périmètre ; un employee ne peut pas exporter les tâches d'autrui ; l'admin exporte tout.

🟡 Bloc 3 - Clôture des résidus Sprint 05 & recette import

  1. US-DOC-01 : Réalignement documentaire (fin US-DOC-07) - 2 SP

    • Réf. : Sprint Review 05 §Résidus
    • Description : finaliser product_backlog.md (US1.1/US1.2 : comptes individuels, rôles réels, RLS auth.uid()), README.md, docs/supabase_schema.sql ; documenter inscription + changement de PIN.
    • Critère d'acceptation : la doc décrit l'architecture auth.users réellement en place ; aucune mention résiduelle du JWT custom / rôle admin fantôme.

  2. US-TEST-01 : Réécriture des tests e2e Playwright (auth) - 2 SP

    • Réf. : Sprint Review 05 §Résidus, e2e/auth.spec.js
    • Description : réécrire l'e2e sur le flux réel (roster /api/roster + /api/login), retirer les références à /api/public_data / /api/auth / bouton « Super Manager · Vue globale ».
    • Critère d'acceptation : npm run test:e2e passe sur le parcours de connexion des 3 rôles.

  3. US-VAL-01 : Recette & validation de l'import par les chefs - 1 SP

    • Réf. : ADR 0008
    • Description : démo de l'import par template (CSV/Markdown, aperçu, scope projet) à Julien & Marco ; recueillir la validation formelle avant de préparer le déploiement.
    • Critère d'acceptation : validation formelle de Julien & Marco consignée ; ajustements éventuels notés pour un lot ultérieur.

📊 Capacité & Engagement

Bloc Stories Effort
🔴 Logger US-LOG-01, US-LOG-02, US-LOG-03, US-LOG-04 14 SP
🟠 Export US-EXP-01, US-EXP-02, US-EXP-03 8 SP
🟡 Clôture & recette US-DOC-01, US-TEST-01, US-VAL-01 5 SP
Total 10 stories 27 SP

⚖️ Engagement ferme : le Bloc 1 (Logger, 14 SP) et le Bloc 2 (Export, 8 SP) sont l'engagement du sprint. Le Bloc 3 (clôture/recette) peut déborder sur le sprint de déploiement si nécessaire.

🔭 Après le Sprint 06 (sprint de déploiement dédié - hors périmètre ici)

Repris de la clôture du Sprint 04 bis, recadré sur l'auth native :

  • Déploiement Netlify (dist + fonctions roster/login/import/member), variables d'env sans pin_hash.
    • Cible retenue : production = Netlify Functions ; server.js (Express) = local/test (Hostinger aujourd'hui). Contrat /api iso entre les deux ⇒ un bascule ultérieure sur VPS Nginx + node server.js reste possible sans toucher au front.
  • Seed/migration de la base de production via Admin API (seed:members / reset:pins).
  • Créer app_logs en production : jouer docs/features/sql/09_create_logs_table.sql sur l'instance de prod (= équivalent prod de TS6.3). Sans cette table, le SupabaseTransport du front échoue silencieusement et aucun log n'est persisté.
  • Observabilité backend en prod - décision à trancher : le logging en base (app_logs) est assuré par le front (navigateur → Supabase), donc indépendant du backend et fonctionnel sur Netlify. En revanche :
    • le log fichier Winston/Morgan (US-LOG-04) ne vit que dans server.js → absent sur Netlify (serverless, FS éphémère) ;
    • app_logs ne capte que les événements vus par le navigateur : une erreur interne à une Netlify Function n'y apparaît pas (seulement dans les logs Netlify).
    • ⇒ Si l'on veut un logging serveur→base en prod, prévoir un transport adapté au serverless (la fonction écrit dans app_logs via service_role) ou retenir le déploiement VPS où server.js (et Winston) tourne tel quel.
  • Smoke tests prod (3 rôles, Realtime, notes, RLS) + validation hiérarchique sur l'URL de prod.

🚧 Décisions déjà tranchées (PO)

  1. Déploiement : après le Sprint 06 (sprint dédié).
  2. Écran de connexion : on garde le roster (proposition B écartée).
  3. Export : CSV (aligné import, étendu) et JSON complet, avec portée par rôle (matrice US-EXP-03).
  4. Recette import : validation par Julien & Marco incluse dans ce sprint.

✅ Definition of Done du sprint

Conforme à definition_of_done.md, et en particulier :

  • Logger opérationnel des deux côtés (front + backend), logs INFO+ persistés dans app_logs, aucune boucle récursive, export .log fonctionnel.
  • Export CSV/JSON livré, portée par rôle vérifiée avec 4 profils, aucun secret dans les exports.
  • Résidus Sprint 05 traités (doc + e2e) ; import validé par les chefs.
  • npm run build réussit ; npm run test passe ; ADR 0009 passé de Proposé à Accepté.

🔗 Références