DOC
Accueil/ Projets/ MJY Task Platform/ Plateforme de Gestion de Projet MJY Holding

Plateforme de Gestion de Projet MJY Holding

La Plateforme MJY Holding est une application moderne et collaborative de gestion de tâches multi-projets conçue pour centraliser et coordonner les activités des différentes entités du groupe (Miyan Noodles, ENGWE France, etc.).

L'application permet d'organiser les tâches par phase de projet (avec chronologie relative J→J), de gérer un cycle de validation strict entre collaborateurs et managers, d'importer/exporter des listes de tâches, d'interagir via des commandes vocales et de générer des projets complets à l'aide de l'IA. Elle embarque une observabilité de production (logger centralisé, ADR 0009) et une authentification Supabase native (roster + PIN, ADR 0002).

🎯 Architecture Technique & Persistance (Option B)

Pour garantir une collaboration durable sans conflits d'écrasement de données (limite historique du stockage clé-valeur ou localStorage), l'application s'appuie sur :

  • Frontend : React 18 & Vite pour une compilation rapide et une structure modulaire propre.
  • Base de Données : PostgreSQL hébergé sur Supabase pour un stockage relationnel structuré (projets, phases, tâches, commentaires), avec RLS basée sur auth.uid() (voir docs/supabase_schema.sql).
  • Authentification : Supabase Auth natif (auth.users + bcrypt géré par Supabase). Le PIN à 4 chiffres est le mot de passe du compte ; aucun hashage manuel. Rôles réels : super_manager / manager / employee (voir ADR 0002).
  • Backend (proxy /api) : deux implémentations iso-contrat du proxy d'authentification (/api/roster, /api/login, /api/member) et de l'import IA (/api/import) :
    • en production → Netlify Functions (netlify/functions/*.js), le netlify.toml redirigeant /api/* vers /.netlify/functions/:splat ;
    • en local / test → un serveur Express (server.js) qui monte les mêmes routes, avec le middleware de log Winston/Morgan (c'est ce serveur qui tourne aujourd'hui sur l'environnement de test).
  • Temps Réel : Activation de Supabase Realtime pour propager instantanément les modifications de tâches via WebSockets (< 5 secondes).
  • Observabilité : logger centralisé hiérarchique côté front (src/utils/logger.js) persistant dans app_logs, et logs structurés Winston côté serveur Express (voir ADR 0009).
  • Déploiement : production sur Netlify (dist statique + netlify/functions, pipeline .github/workflows/netlify.yml) - mise en production effective planifiée pour le sprint de déploiement dédié après le Sprint 06. Grâce à l'iso-contrat /api, un déploiement alternatif sur VPS (Nginx + node server.js) reste possible sans toucher au front.

📂 Organisation du Projet

Le dépôt est structuré de la manière suivante :

MYJ-Holding-Platform/
├── .github/workflows/
│   └── netlify.yml              # Pipeline CI/CD de déploiement automatique sur Netlify
├── docs/                        # Espace documentaire du projet
│   ├── ADR/                     # Architecture Decision Records (Suivi des choix d'architecture)
│   │   └── ADR_0001_initialisation_projet.md # Justification de la stack React/Vite + Supabase
│   ├── sprints/                 # Suivi Agile du projet
│   │   ├── product_vision_board.md  # Vision, public cible et objectifs du produit
│   │   ├── product_backlog.md       # Liste globale des User Stories à implémenter
│   │   ├── definition_of_done.md    # Critères de validation technique et fonctionnelle
│   │   ├── definition_of_ready.md   # Critères d'entrée d'une tâche dans le sprint
│   │   ├── sprint_01/ … sprint_03/  # Sprints clôturés (refactor, tests, migration Supabase)
│   │   └── sprint_04/               # Sprint 04 (urgence) : correctifs d'audit + stabilisation
│   │       ├── sprint_backlog.md    # Objectifs et Stories du Sprint 04
│   │       ├── tasks.md             # Tâches techniques détaillées du sprint
│   │       └── travaux_post_sprint_03.md # Journal des travaux du 06/07 après clôture Sprint 03
│   ├── deployment/              # Guides et procédures système
│   │   └── netlify_deployment_guide.md # Procédure de déploiement sur Netlify
│   └── audit/                   # Rapports d'audit technique
│       ├── audit_refactoring.md            # Audit du monolithe initial et plan de découpage
│       ├── audit_complet_2026-07-07.md     # Audit technique complet (structure, bugs, sécurité)
│       └── audit_supabase_sprints_07072026.md # Audit synchronisation Supabase & suivi sprints
├── logo/                        # Fichiers sources des logos de la plateforme
├── src/                         # Code source de l'application (en cours de migration)
│   ├── assets/                  # Images, icônes et logos de l'application
│   ├── components/              # Composants React réutilisables (Modales, Cartes, etc.)
│   ├── hooks/                   # Custom Hooks (gestion d'état, requêtes Supabase)
│   ├── pages/                   # Vues principales (Auth, Admin Dashboard, Employee View)
│   ├── services/                # Clients API et logique d'intégration (Supabase client)
│   └── utils/                   # Fonctions utilitaires (dates, formateurs, générateurs d'UID)
├── .env.example                 # Modèle de configuration des variables d'environnement
├── .gitignore                   # Fichiers et dossiers exclus de Git
├── index.html                   # Monolithe d'origine (servant de base de migration)
└── README.md                    # Présentation et documentation générale (ce fichier)

🚀 Démarrage Rapide en Local

Prérequis

  • Node.js (Version 20+ recommandée)
  • Un compte et un projet actif sur Supabase
  • Une clé d'API Anthropic (pour l'assistant d'import IA)

1. Installation

Clonez le projet et installez les dépendances :

npm install

2. Configuration d'environnement

Copiez le fichier d'exemple et renseignez vos clés réelles :

cp .env.example .env

Éditez le fichier .env pour y ajouter :

  • VITE_SUPABASE_URL : URL de votre instance Supabase (front).
  • VITE_SUPABASE_ANON_KEY : clé anonyme publique (front).
  • SUPABASE_SERVICE_ROLE_KEY : clé service_role, utilisée uniquement côté serveur (server.js) pour le proxy d'authentification et la création de comptes via l'Admin API.
  • ANTHROPIC_API_KEY : clé API Anthropic pour l'import IA (/api/import) - optionnelle (repli déterministe sinon).

3. Exécution locale

Le front (Vite) et le backend (Express) se lancent séparément :

npm run dev     # front Vite  → http://localhost:5173
npm start       # backend Express (proxy /api + statique) → http://localhost:3000

Le proxy /api (roster, login, membres, import) est servi par server.js. Sans lui, l'écran de connexion affiche « Le serveur /api est-il démarré ? ».

🔄 Workflow de Validation des Tâches

Un workflow spécifique régit la complétion des tâches créées par des collaborateurs :

  1. Création : Un collaborateur crée une tâche pour lui-même et doit lui associer un manager de suivi.
  2. Soumission : Lorsque le collaborateur marque la tâche comme terminée, celle-ci passe au statut intermédiaire pending_validation (En attente de validation).
  3. Décision : Le manager assigné reçoit une notification et peut :
    • Approuver la tâche (le statut devient done et la date de validation est enregistrée).
    • Rejeter la tâche (elle repasse au statut in_progress pour être retravaillée).

🔐 Authentification (roster + PIN)

L'authentification repose sur Supabase Auth natif (auth.users), pas de JWT custom (voir ADR 0002).

  • Connexion : l'écran de login charge un roster (GET /api/roster) - prénoms, rôle et projets, jamais d'email. L'utilisateur clique son nom puis saisit son PIN à 4 chiffres. POST /api/login résout l'email côté serveur, appelle signInWithPassword, et renvoie la session native installée côté client (supabase.auth.setSession).
  • Inscription / création de compte : réservée au serveur via l'Admin API (clé service_role). À la création d'un compte auth.users, un trigger handle_new_user crée automatiquement la fiche public.member (nom + rôle depuis raw_user_meta_data). PIN par défaut selon le rôle (super_manager 9999, manager 1052, employee 4011).
  • Changement de PIN (self-service) : chaque utilisateur peut changer son PIN via la modale 🔑 PIN → supabase.auth.updateUser({ password }). Le nouveau PIN doit différer du PIN par défaut ; le flag member.pin_customized pilote l'indicateur 🔒 sans jamais exposer le PIN.
  • Rôle admin virtuel : le compte admin@engwe-france.fr est distingué côté client (jamais stocké en base) pour ouvrir la vue globale ; en base il reste un super_manager.

💾 Export / Sauvegarde de données (Sprint 06)

Chaque dashboard propose l'export des tâches via deux boutons (⬇️ CSV / ⬇️ JSON, composant ExportButtons) :

  • CSV aligné sur le template d'import (ADR 0008) - colonnes Tâche;Notes;Assigné à;Responsable;Priorité;Pilier;Échéance + contexte (Projet;Statut;Phase;Créé par;Date de création), séparateur ;, UTF-8 BOM. Un export CSV est ré-importable (aller-retour testé).
  • JSON exhaustif (tous les champs + notes + relations projet/phase résolues), pour sauvegarde/restauration. Aucun secret (jeton de session, clé) n'est jamais sérialisé.
  • Portée par rôle (filterTasksByRole) - on n'exporte que ce que la RLS laisse voir : admin/super_manager → tout ; manager → ses tâches + celles qu'il a créées/à valider ; employee → ses tâches uniquement.