Rapport de journée - 08/07/2026 · Sprint 05 (Refonte de l'authentification)

But de ce document : consigner tout ce qui a été fait le 08/07/2026, pourquoi, avec des résumés en langage simple (pour non-informaticiens) et un guide de reprise permettant à une nouvelle session de développement (ou une autre personne) de continuer sans perte de contexte.

Sujet du sprint : donner à chaque utilisateur son propre compte et livrer les 3 parcours d'identité - se connecter, être inscrit/créé, changer son code PIN - en migrant vers Supabase Auth natif.

Projet Supabase concerné : instance de test (ref libnvrwelffpqysesiwb).

1. Résumé express (pour tout le monde)

Aujourd'hui, on a reconstruit les fondations de la connexion de l'application MJY Holding.

Avant, la sécurité était bricolée (codes PIN comparés en clair, « jetons » de connexion fabriqués maison, un membre ne pouvait appartenir qu'à un seul projet, et des rôles incohérents). On a tout remis à zéro proprement et rebâti sur l'outil d'authentification standard et sécurisé de Supabase (le fournisseur de base de données), qui gère le chiffrement des codes tout seul.

Résultat concret, testé et fonctionnel :

• 13 comptes recréés (1 super-administrateur + 12 membres), chacun avec son propre compte et son code PIN.
• Chaque personne ne voit que ce qu'elle a le droit de voir (règles automatiques dans la base).
• Les tâches suivent un circuit de validation clair entre collaborateurs et managers.
• La connexion fonctionne sans jamais exposer les adresses e-mail dans le navigateur.

Ce qui reste : l'écran de connexion et les tableaux de bord doivent être ré-adaptés à ces nouvelles fondations (travail en cours, décrit en §6).

2. Le problème de départ (pourquoi ce chantier)

Un audit et un « handoff » (../../features/handoff_migration_supabase.md) avaient identifié une « dérive » : du code avait été écrit en dehors du plan validé, avec une architecture incompatible et moins sûre :

Pourquoi c'est important : la version « maison » permettait, en théorie, de forger un accès et mélangeait les responsabilités. La version Supabase native est plus sûre, plus simple à maintenir, et respecte le cahier des charges (brief officiel de Marco).

3. Décisions prises aujourd'hui (et pourquoi)

Chaque décision a été validée explicitement par l'utilisateur (consigne : signaler tout conflit et laisser choisir).

4. Ce qui a été fait, étape par étape

4.1 Nettoyage complet de la base (« repartir de zéro »)

• Quoi : suppression de toutes les tables, fonctions, policies et comptes de connexion.
• Comment : script ../../features/sql/01_cleanup.sql exécuté dans l'éditeur SQL Supabase.
• Détail : un résidu rls_auto_enable a été repéré et supprimé ; les 6 « event triggers » restants (pgrst_*, pg_graphql, pg_cron, pg_net) sont des éléments système de Supabase - à ne pas toucher.
• Vérifié : plus aucune table ni fonction dans public, auth.users vide.

4.2 Création du schéma cible

• Quoi : recréation des tables member, project (+ key), project_members (pivot), phase, task, task_notes.
• Comment : ../../features/sql/02_schema.sql.
• Points clés : task a trois liens distincts vers member (created_by, manager, owner) ; trigger updated_at automatique ; Realtime activé sur task et task_notes (mises à jour en direct) ; contrôles de cohérence (status, priority, role).

4.3 Sécurité par ligne (RLS - qui voit quoi)

• Quoi : chaque rôle ne voit/modifie que ce qu'il doit.
• Comment : ../../features/sql/05_rls_policies.sql.
• Règles : super_manager voit tout ; manager voit les tâches des projets dont il est membre ; employee voit uniquement les tâches qui lui sont assignées (tous projets confondus).
• Incident résolu : une récursion infinie (les règles s'auto-appelaient) faisait échouer les lectures. Corrigée en déportant les vérifications d'appartenance dans des fonctions dédiées (auth_role, my_project_ids, my_comembers) qui contournent proprement la récursion.

4.4 Circuit de validation des tâches (workflow)

• Quoi : imposer les règles de passage de statut dans la base (pas seulement dans l'écran).
• Comment : ../../features/sql/07_task_workflow.sql (un « trigger »).
• Règles (voir scénario §5.4) : tâche créée par un collaborateur → démarre « en attente de validation » ; seul un manager/admin du projet peut la valider ; quand un collaborateur veut passer une tâche « finie », elle repasse en validation.

4.5 Recréation des comptes (seed)

• Quoi : recréer le super-admin + les 12 membres, avec leur code PIN par défaut selon le rôle (collaborateur 4011, manager 1052, super 9999), et leurs rattachements aux projets.
• Comment : script ../../../scripts/seed-members.js (npm run seed:members), qui lit les données locales non versionnées (data/seed/members.json, projects.json).
• Vérifié : 13 comptes créés, mots de passe chiffrés en bcrypt natif, correspondance parfaite entre la table member et les comptes de connexion.

4.6 Données « éparpillées » regroupées et sorties de Git

• Quoi : les e-mails/membres étaient dispersés dans le code versionné. On les a centralisés dans data/seed/*.json, non poussés sur GitHub (.gitignore), avec des modèles *.example.json committés.
• Pourquoi : ne plus exposer d'e-mails personnels dans le dépôt, et avoir une source unique.

4.7 Connexion : « proxy de connexion » (sans exposer les e-mails)

• Quoi : deux points d'entrée serveur :
  • GET /api/roster → liste des prénoms + rôle + projets (jamais d'e-mail) pour l'écran de login.
  • POST /api/login → reçoit { memberId, PIN }, retrouve l'e-mail côté serveur, ouvre la session, et renvoie les jetons de session.
• Comment : logique partagée ../../../lib/authBackend.js, branchée dans server.js (dev) et netlify/functions/{roster,login}.js (prod) - pour ne pas dupliquer le code.
• Vérifié : le roster ne contient aucun e-mail ; bon PIN → session, mauvais PIN → refus.

4.8 Couche client (application React)

• Quoi : brancher l'app sur la session Supabase native.
• Comment :
  • src/services/supabaseClient.js → un seul client, session locale au navigateur (jamais synchronisée).
  • src/services/authService.js → getRoster, loginWithPin, changePin, defaultPinForRole.
  • src/hooks/useAuth.js → hook réutilisable (session + rôle + login/logout/changePin).
• Vérifié : npm run build réussit.

5. Scénarios en langage simple (non-IT)

5.1 Se connecter

1. J'ouvre l'application : je vois la liste des prénoms regroupés (Managers, Collaborateurs, Super Manager).
2. Je clique sur mon prénom, je saisis mon code à 4 chiffres.
3. J'arrive dans mon espace. Mon adresse e-mail n'est jamais affichée ni exposée.

En coulisses : c'est le serveur qui retrouve mon e-mail et ouvre la session ; le navigateur ne voit que mon prénom.

5.2 Être inscrit / créé (par un manager ou le super-admin)

1. Un responsable crée une nouvelle personne (prénom, rôle, projet(s)).
2. La personne reçoit un code par défaut selon son rôle (collaborateur 4011, manager 1052, super 9999).
3. Elle peut se connecter immédiatement, puis personnaliser son code.

(La création « depuis l'application » - bouton dans l'écran des membres - reste à brancher, cf. §6.)

5.3 Changer son code PIN

1. Une fois connecté, j'ouvre « Changer mon code ».
2. Je saisis un nouveau code à 4 chiffres (différent du code par défaut).
3. Mon ancien code ne fonctionne plus ; le nouveau est actif immédiatement.

(Le bouton/écran est à ajouter côté front ; la mécanique changePin est déjà prête.)

5.4 Le circuit d'une tâche (validation)

• Tâche créée par un manager : À faire → En cours → Fini. Simple.
• Tâche créée par un collaborateur :
  1. Elle démarre en « En attente de validation ».
  2. Un manager/admin du projet la valide → elle passe « À faire ». (Le collaborateur ne peut pas se valider lui-même.)
  3. Le collaborateur la démarre (En cours), puis demande « Fini ».
  4. Elle repasse en validation ; le manager approuve (→ Fini) ou rejette (→ En cours).

Objectif : le travail des collaborateurs est contrôlé à l'entrée et à la sortie.

5.5 Qui voit quoi

• Super Manager : tout, tous projets.
• Manager : tout ce qui concerne ses projets.
• Collaborateur : uniquement ses tâches à lui, quels que soient les projets.

6. État d'avancement & ce qu'il reste à faire

✅ Terminé et vérifié (backend + connexion)

• Nettoyage, schéma, RLS, trigger de workflow : joués en base et testés.
• Seed : 13 comptes, bcrypt natif, rattachements projets.
• Proxy de connexion (/api/roster, /api/login) : testé (sans e-mail).
• Couche client (supabaseClient, authService, useAuth) : build vert.

✅ Fait à la reprise (08/07, session 2 - couche session front)

1. src/pages/Auth.jsx - ✅ réécrit sur /api/roster (prénoms + rôle + projets, sans email) + loginWithPin(memberId, pin). Plus de super@manager codé en dur, plus de PIN 9999 en dur, plus de JWT custom. Indicateur 🔒 piloté par member.pin_customized (exposé via le roster, jamais le PIN).
2. src/App.jsx - ✅ session native via useAuth() (getSession/onAuthStateChange) ; supprimés : session_token, session_created_at, l'expiration 1h maison, setSessionToken, window.__forceAppRerender. Routage par rôles réels super_manager/manager/employee (fini admin).
3. Nettoyage - ✅ netlify/functions/{auth,public_data}.js supprimés.

Vérifié à la reprise : npm run build vert · npm run test vert (3/3) · npm run test:login vert (super=13/2, manager=12/2, employee=8/1, mauvais PIN refusé) · contrat HTTP /api/roster (0 email fuité, 13 membres, 3 rôles) et /api/login (super/manager/employee → access_token+refresh_token+member, mauvais PIN → 401) testés contre server.js réel.

🔜 Reste à faire (front - prochain gros bloc : la couche DONNÉES)

3. Couche données - remplacer src/services/storage.js (qui parle encore aux anciennes tables supprimées : projects/members/tasks au pluriel) par des hooks (useTasks/useProjects/useMembers/ useRealtime) sur le nouveau schéma. ⚠️ Différences de colonnes repérées à mapper : task.title/description (≠ label/note), owner/manager/created_by = UUID de member (≠ noms), pas de colonnes pillar/due_end/done/created_by_name, phase.position/date_start/date_end (≠ order/day_*), task_notes.body/author(uuid)/created_at, et member n'a PAS d'email.
4. Dashboards - adapter les 3 vues à member.id (l'identité n'est plus l'email) ; vue collaborateur multi-projets unifiée (brief §3). Toucher aussi TaskCard/TaskForm/TaskDetail/GroupedListView/ StatsBar/PhaseGroupView (ils lisent label/pillar/dueEnd/done/notes.role).
5. Modale « changer mon PIN » (mécanique déjà prête dans authService.changePin + flag pin_customized).
6. Inscription in-app - Edge/endpoint create-member + branchement du MemberModal. 7bis. Tests - réécrire l'e2e Playwright e2e/auth.spec.js sur le flux roster//api/login.

⚠️ État transitoire connu : la connexion et le routage par rôle fonctionnent (session native), mais les dashboards restent vides tant que la couche données (point 3) n'est pas re-branchée sur le nouveau schéma - storage.js interroge encore les tables supprimées. C'est le prochain bloc.

ℹ️ Dev local : server.js ne charge pas .env de lui-même (en prod, Netlify injecte l'env). Pour tester /api/* en local hors netlify dev, exporter l'env avant : set -a; . ./.env; set +a; node server.js.

7. Guide de reprise pour une nouvelle session

À lire d'abord (dans l'ordre) :

1. Ce rapport.
2. ../../features/handoff_migration_supabase.md (décisions d'architecture).
3. sprint_backlog.md et tasks.md (périmètre & suivi du Sprint 05).

État de la base : schéma cible en place, RLS + workflow actifs, 13 comptes seedés (instance test libnvrwelffpqysesiwb). Scripts SQL rejouables dans docs/features/sql/ (ordre : 01 → 02 → 05 → 07).

Prochaine action recommandée : réécrire Auth.jsx puis App.jsx (points 1-2 du §6), vérifier une connexion réelle avec les 3 rôles, puis migrer la couche données/dashboards.

Commandes utiles :

npm run dev            # front (Vite) - nécessite npm start en parallèle pour /api
npm start              # serveur local (endpoints /api/roster, /api/login, /api/import)
npm run build          # build de production
npm run seed:members   # (re)créer comptes + membres + rattachements (Admin API)
npm run test:login     # vérifie connexion + RLS (super=13/2, manager=12/2, employee=8/1)
npm run test:workflow  # vérifie le circuit de validation des tâches

Prérequis d'environnement (.env, jamais committé) : VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY, ANTHROPIC_API_KEY. Codes PIN par défaut : 9999/1052/4011.

Points ouverts (à confirmer avec Marco/Julien le moment venu) :

• E-mails réels des membres (aujourd'hui : adresses connues + admin@engwe-france.fr pour le super).
• Édition des e-mails par le super-admin → US1.3, sprint ultérieur.
• Articulation avec le Sprint 04 bis (déploiement) : ne pas déployer l'ancienne couche auth ; le Sprint 05 la remplace.

8. Fichiers créés / modifiés aujourd'hui

Base de données (SQL) : docs/features/sql/01_cleanup.sql, 02_schema.sql, 05_rls_policies.sql, 07_task_workflow.sql Backend / connexion : lib/authBackend.js, netlify/functions/roster.js, netlify/functions/login.js, server.js (réécrit) Client : src/services/supabaseClient.js, src/services/authService.js, src/hooks/useAuth.js Données : .gitignore, data/README.md, data/seed/{members,projects}.example.json (+ .json réels, non versionnés) Scripts : scripts/seed-members.js, scripts/test-login.js, scripts/test-workflow.js Docs : docs/features/handoff_migration_supabase.md, docs/sprints/sprint_05/{sprint_backlog,tasks}.md, docs/sprints/product_backlog.md (US1.3, US2.3), ce rapport

(Un commit ciblé « feat(auth): refonte de l'authentification vers Supabase Auth natif (Sprint 05) » regroupe ce travail.)