DOC
Accueil/ Projets/ MJY Task Platform/ Rapport de Validation de la Démo Technique (Sprint 03)

Rapport de Validation de la Démo Technique (Sprint 03)

MJY Holding Platform

  • URL de Démo : https://mjyholding.maashrees.fr/
  • Environnement : Hébergement Hostinger (Serveur Node.js/Express)
  • Base de données : Supabase PostgreSQL (avec Realtime et RLS activés)
  • Date : 06 juillet 2026

🎯 Objectif du Déploiement temporaire

Ce déploiement a pour but de valider la nouvelle couche d'infrastructure, de sécurité et de persistance développée lors du Sprint 03 avant le basculement définitif vers l'infrastructure cible Netlify.

🛠️ Architecture Technique Validée

graph TD
    A[Navigateur Client React/Vite] -->|Requêtes HTTP /api/*| B[Serveur Node.js/Express]
    A -->|Abonnement WebSocket Temps Réel| C[Supabase Realtime]
    B -->|Check PIN & Sign JWT via Service Role| C
    A -->|REST API requêtes avec JWT| C
  1. Client Frontend : Le code React/Vite a été unifié pour requêter des routes relatives /api/*, garantissant une compatibilité totale sans modification entre l'architecture Node.js Express (Hostinger) et l'architecture Serverless (Netlify).
  2. Couche de Persistance PostgreSQL : Toutes les écritures et lectures interrogent désormais la base de données relationnelle Supabase en direct.
  3. Sécurité Row Level Security (RLS) : Les politiques restrictives sont configurées au niveau de PostgreSQL et s'appuient sur les claims d'un jeton JWT personnalisé (user_role et email).

📋 Scénarios de Validation Recommandés

Scénario 1 : Initialisation et Authentification Dynamique

  • Action : Se rendre sur la page de connexion, sélectionner un membre et saisir son code PIN (ex : 9999 pour le Super Manager).
  • Ce qui est vérifié :
    • Le chargement dynamique des collaborateurs et des projets depuis la base de données sans exposer les codes PIN.
    • La signature du token JWT par le backend et son stockage sécurisé dans le client pour maintenir la session active lors d'un rafraîchissement (F5).

Scénario 2 : Persistance des modifications

  • Action : Créer ou déplacer une tâche, changer un statut, ajouter un commentaire sur un projet. Rafraîchir la page ou rouvrir le site dans un autre onglet.
  • Ce qui est vérifié :
    • L'exécution des requêtes d'écriture (upserts/deletes) dans la base PostgreSQL Supabase.
    • La persistance réelle des données sur le long terme.

Scénario 3 : Synchronisation Temps Réel (WebSockets)

  • Action : Ouvrir l'application sur deux navigateurs ou deux appareils différents en même temps. Effectuer une action (création/déplacement) sur l'un d'eux.
  • Ce qui est vérifié :
    • La mise à jour instantanée et automatique de l'autre écran en moins de 100ms sans aucune action manuelle ni rechargement.

Scénario 4 : Respect des droits d'accès RLS

  • Action : Se connecter en tant que collaborateur (Employee). Tenter de modifier des jalons ou des tâches assignées à un autre utilisateur.
  • Ce qui est vérifié :
    • L'enforcement de la sécurité directement au niveau de la base de données (PostgreSQL bloque toute transaction non autorisée selon le rôle contenu dans le JWT).