Skip to content

Plan-backend-et-deploiement.md

Latest commit

 

History

History
327 lines (215 loc) · 19.9 KB

Plan-backend-et-deploiement.md

File metadata and controls

327 lines (215 loc) · 19.9 KB

Plan backend Node.js, MySQL et déploiement

Ce document décrit comment mettre en place l’évolution du projet : backend Node, base MySQL, auth fiable et déploiement. Il corrige les pièges d’une simple « copie » de l’auth actuelle (tout client) vers un service public.

1. Objectif

  • Permettre à plusieurs personnes d’utiliser TaskHub en ligne.
  • Centraliser les tâches et les comptes dans MySQL.
  • Ne jamais faire confiance au navigateur pour l’identité ni pour le stockage des mots de passe.

2. Prérequis locaux (ex. Laragon)

  • Node.js LTS installé.
  • MySQL disponible (Laragon inclut souvent MySQL/MariaDB).
  • Créer une base dédiée, par exemple taskhub, et un utilisateur SQL avec droits limités à cette base.

3. Organisation du dépôt (recommandation)

Deux approches courantes :

Option Description
A. Monorepo client/ (React actuel) + server/ (Node). Racine avec scripts dev qui lance les deux.
B. Dépôt séparé API dans un autre repo ; le front consomme une URL d’API en variable d’environnement.

Pour démarrer vite tout en gardant un seul clone : option A avec dossier server/ à la racine du projet TaskHub.

4. Backend Node — périmètre minimal

  1. Serveur HTTP (Express, Fastify ou Nest) écoutant un port (ex. 3000).
  2. Connexion MySQL via un pool (mysql2 en promesses, ou ORM type Prisma / Drizzle si vous préférez).
  3. Migrations : scripts SQL versionnés ou outil de migration pour créer users et tasks.
  4. Variables d’environnement (fichier .env non commité) :
    • DATABASE_URL ou DB_HOST, DB_USER, DB_PASSWORD, DB_NAME, DB_PORT
    • JWT_SECRET (si JWT) ou secret de session
    • CLIENT_ORIGIN pour CORS (ex. http://localhost:5173 en dev)

5. Authentification (à faire correctement)

Mauvaise pratique (à éviter) Bonne pratique
Accepter n’importe quel login sans vérification serveur POST /auth/login vérifie email + hash en base
Stocker le mot de passe en clair dans localStorage Seul le serveur stocke un hash (bcrypt ou Argon2)
Cookie côté client avec seulement "1" Jeton signé (JWT) dans header Authorization, ou cookie httpOnly + Secure en HTTPS
Réutiliser le même stockage tâches pour tous Chaque ligne tasks a un user_id ; l’API refuse l’accès aux lignes d’un autre utilisateur

Inscription : POST /auth/register — valider email, longueur du mot de passe, insérer users avec hash.

Connexion : retourner un token (ou créer une session serveur) ; le front l’envoie sur chaque requête protégée.

Déconnexion : invalider session côté serveur, ou côté client supprimer le token + vider le cache React Query.

6. API REST suggérée (première version)

Préfixe exemple : /api.

Méthode Route Description
POST /api/auth/register Créer un compte
POST /api/auth/login Obtenir un token / session
POST /api/auth/logout Optionnel selon stratégie
GET /api/tasks Liste des tâches de l’utilisateur connecté
POST /api/tasks Créer une tâche
PATCH /api/tasks/:id Mettre à jour (statut, titre, etc.)
DELETE /api/tasks/:id Supprimer

Champs alignés sur le front actuel : title, description, completed, category, dueDate (mapper en due_date en SQL si besoin).

7. Côté React (adaptations)

  1. VITE_API_URL dans .env du client (ex. http://localhost:3000).
  2. Remplacer les appels dans tasksApi.js par fetch avec credentials: 'include' (sessions cookie) ou header Authorization: Bearer <token>.
  3. Intercepter les réponses 401 pour rediriger vers /login.
  4. Retirer la persistance du mot de passe dans le store utilisateur ; ne garder en mémoire que ce qui est nécessaire à l’UI (nom, email).

8. Déploiement (vue d’ensemble)

  1. MySQL : instance managée ou serveur avec sauvegardes.
  2. API Node : variables d’environnement de prod, HTTPS (reverse proxy nginx ou hébergeur).
  3. Front : npm run build ; configurer base Vite selon l’URL réelle (racine du domaine vs sous-chemin).
  4. CORS : n’autoriser que l’origine du site front en production.

9. Ordre de travail suggéré

  1. Schéma SQL + script de création des tables.
  2. Serveur minimal + healthcheck GET /api/health.
  3. Auth register/login + protection des routes tâches.
  4. CRUD tâches branché sur MySQL.
  5. Brancher le React existant sur l’API.
  6. Durcissement (rate limiting basique, validation des entrées, logs d’erreur).

10. Idée de fonctionnalité — Export intelligent des tâches

Fonctionnalité cible : depuis le dashboard (ou un module « Rapports »), chaque utilisateur authentifié peut exporter uniquement ses tâches, après un filtrage intelligent, vers des formats utilisables en entreprise (réunion, suivi de projet, reporting).

10.1 Filtres par période

L’utilisateur choisit une fenêtre temporelle prédéfinie ou personnalisable :

Période Usage typique
Journalier Bilan du jour, stand-up
Hebdomadaire Revue de sprint, planning
Mensuel Reporting RH / management
Annuel bilan annuel, archives

Le backend calcule les bornes de dates (from / to) à partir du fuseau horaire de l’utilisateur (à stocker ou déduire plus tard si besoin).

10.2 Filtres fins sur les tâches à exporter

En complément de la période, sélection précise des enregistrements à inclure dans l’export :

  • Statut : actives, terminées, toutes (aligné sur le modèle actuel completed).
  • Priorité : à modéliser si vous ajoutez un champ priority (sinon mapper Urgent / catégories existantes en « priorité visuelle »).
  • Projet : prévoir une entité projects (ou un champ project_id sur tasks) si le produit évolue au-delà des seules catégories.
  • Date : par date de création, date d’échéance (due_date), ou date de complétion (nécessite un champ completed_at en base pour des stats fiables).

Toutes les requêtes d’export doivent être scopées par user_id (comme le CRUD des tâches).

10.3 Formats d’export professionnels

Après prévisualisation (liste + compteurs), génération côté serveur (recommandé pour la cohérence, la sécurité et les gros volumes) :

Format Piste technique (Node)
PDF pdfkit, puppeteer (HTML → PDF), ou service externe
Excel exceljs / xlsx
Word docx
PowerPoint pptxgenjs

Note : PowerPoint et Word sont utiles pour des diapositives / comptes rendus ; Excel et PDF couvrent souvent 80 % des besoins de reporting — prioriser par phase (ex. CSV + PDF d’abord, puis Excel, puis Word/PPTX).

10.4 Objectif produit

  • Gestion et analyse de productivité sur ses propres données.
  • Partage de rapports (fichier exporté, ou lien temporaire sécurisé si vous l’ajoutez plus tard).
  • Usage professionnel : réunions, suivi de projet, reporting managérial.

10.5 Améliorations intelligentes à intégrer

  1. Graphiques automatiques dans les exports (ou en annexe PDF) : évolution des tâches créées / terminées sur la période, répartition par catégorie, charge en retard. Les données agrégées peuvent être calculées en SQL ou en couche service avant rendu (PNG embarqué via lib de charts côté serveur, ou SVG dans PDF).
  2. Statistiques systématiques : nombre de tâches terminées, en cours, en retard ; temps moyen avant complétion si completed_at existe ; taux de complétion sur la période.
  3. Résumé automatique généré par l’IA : après agrégation des métriques, appeler un fournisseur LLM (API) avec un prompt strict (données chiffrées uniquement, pas de données personnelles inutiles) pour produire un court paragraphe « exécutif » en français. Prévoir AI_EXPORT_SUMMARY_ENABLED, quotas, opt-in utilisateur, journalisation et conformité (RGPD : base légale, durée de conservation des prompts/réponses si vous les stockez).

10.6 API et ordre d’implémentation (suggestion)

  • POST /api/exports/preview — corps JSON : période, filtres ; réponse : sous-ensemble de tâches + stats + métadonnées pour le front.
  • POST /api/exports — même filtre + format (pdf | xlsx | docx | pptx) ; réponse : fichier en stream ou URL signée courte durée.

À placer après le CRUD tâches stable et les champs nécessaires (completed_at, éventuellement project_id, priority).

11. Système de catégories enrichi (produit + données)

Objectif : faire évoluer TaskHub d’une simple todo list vers un outil d’organisation et de productivité, avec des catégories structurées, personnalisables et exploitables dans filtres, dashboard et exports (section 10).

11.1 État actuel (référence)

Aujourd’hui le front propose un select à valeurs fixes : Général, Travail, Personnel, Shopping, Santé, Urgent (chaînes type general, work, etc.). La cible décrite ci-dessous suppose une table (ou équivalent) côté MySQL plutôt qu’une liste codée en dur seule.

11.2 Arborescence de catégories proposées (catalogue initial)

Chaque groupe ci-dessous peut devenir un niveau « parent » ; les lignes en retrait sont des sous-catégories (enfants) à créer en base avec parent_id nullable sur la table categories.

Productivité

  • Études
  • Formation / apprentissage
  • Objectifs
  • Projets

Travail

  • Réunions
  • Administration
  • Clients
  • Freelance

Vie personnelle

  • Famille
  • Loisirs
  • Voyage
  • Maison

Finance

  • Budget
  • Factures
  • Investissements
  • Dépenses

Organisation

  • Rendez-vous
  • Planification
  • Routine

Santé et bien-être

  • Sport
  • Méditation
  • Sommeil
  • Alimentation

(Les anciennes étiquettes « Shopping », « Urgent », etc., peuvent être migrées : mapping vers un enfant du catalogue, ou conservation comme catégories système si vous gardez la rétrocompatibilité.)

11.3 Catégories personnalisées utilisateur

  • Chaque utilisateur peut créer ses propres catégories (en plus du catalogue global ou en remplacement progressif selon règle produit).
  • Modèle suggéré : table categories avec au minimum : id, user_id (NULL = catégorie système / catalogue partagé), parent_id, name, slug ou clé stable, color (ex. hex), icon (nom d’icône type Lucide / emoji / clé de sprite), sort_order, created_at.
  • Table tasks : category_id (FK) remplace ou complète l’enum textuel actuel ; migration des tâches existantes vers des category_id par défaut.

11.4 Couleur et icône (UX sans surcharge)

  • Couleur : palette limitée (préréglages + une couleur custom optionnelle) pour éviter le « arc-en-ciel » illisible.
  • Icône : jeu restreint (bibliothèque d’icônes + recherche courte) ou emoji optionnel — l’UI reste simple : une ligne compacte dans le formulaire tâche, affichage badge sur TaskCard comme aujourd’hui.
  • Prévoir un aperçu en temps réel (nom + couleur + icône) avant enregistrement.

11.5 Filtres et statistiques

  • Les filtres de la liste des tâches et du dashboard doivent permettre de filtrer par catégorie (parent, enfant, ou « toutes »).
  • Statistiques : comptage par catégorie / par groupe, tendances dans le temps (après backend + champs dates utiles), cohérent avec les exports intelligents (section 10).

11.6 API (esquisse)

Méthode Route Description
GET /api/categories Arbre ou liste plate + métadonnées (système + propres à l’utilisateur)
POST /api/categories Créer une catégorie personnalisée
PATCH /api/categories/:id Renommer, couleur, icône, ordre (uniquement si user_id = connecté)
DELETE /api/categories/:id Soft-delete ou interdiction si des tâches y sont rattachées (règle produit à trancher)

Les endpoints tasks acceptent category_id (et rejettent les IDs d’autres utilisateurs).

11.7 Ordre d’implémentation (par rapport au reste du plan)

À traiter après le modèle users + tasks stable et l’auth ; avant ou en parallèle des exports riches (section 10), car les exports et stats s’appuient sur une taxonomie claire.

12. Intelligence productivité et organisation (feuille de route)

Objectif commun : faire de TaskHub un outil de gestion du temps et de la productivité, pas seulement une liste. Les points déjà détaillés ailleurs dans ce document ne sont pas répétés (export multi-formats et périodes : section 10 ; catégories riches : section 11).

12.1 Priorité intelligente des tâches

  • Introduire un champ priority explicite (low | medium | high) en base, distinct de la catégorie.
  • Suggestion côté serveur ou client : combiner échéance (proche / en retard), indicateur d’importance (champ utilisateur ou règles métier), et charge (nombre de tâches actives / en retard). La suggestion reste modifiable par l’utilisateur pour garder le contrôle.
  • Prévoir une route optionnelle PATCH /api/tasks/:id/suggest-priority ou calcul à la création / mise à jour.

12.2 Planification automatique (« meilleur moment »)

  • Fonctionnalité avancée : nécessite un modèle de disponibilités (créneaux récurrents, calendrier) et des règles de conflit avec les autres tâches. À traiter après les stats de base et les champs due_date / completed_at fiables.
  • Première étape possible : proposer un créneau suggéré textuel (ex. « demain matin ») sans optimisation globale, puis itérer vers un vrai moteur de placement.

12.3 Statistiques de productivité (tableau de bord)

  • Métriques cibles : tâches terminées, tâches en retard, taux de complétion sur une période, délai moyen entre création et complétion (exige completed_at et idéalement created_at en base).
  • Exposer GET /api/stats/summary?from=&to= pour alimenter le dashboard React ; aligner les définitions avec les exports (section 10.5) pour une seule source de vérité.

12.4 Graphiques d’analyse (dans l’app)

  • Complément aux graphiques dans les exports (§10.5) : vues hebdomadaires et mensuelles dans l’UI (bibliothèque charts côté client ou image générée côté serveur).
  • Axes utiles : tâches créées / terminées par jour ou semaine, backlog, répartition par catégorie ou tag.

12.5 Rappels intelligents

  • Notifications avant échéance (tâches importantes / priorité haute / catégorie Urgent si conservée).
  • Implémentation typique : jobs planifiés (cron + file) côté Node, préférences utilisateur (délai avant échéance, canal web push / email si ajouté), respect du consentement et fréquence plafonnée pour éviter la spam.

12.6 Sous-tâches (subtasks)

  • Modèle : tasks.parent_id (NULL = tâche racine) ou table subtasks liée à task_id ; ordre sort_order.
  • Progression agrégée possible pour le mode projet (§12.7). L’UI reste simple : liste repliable sous la tâche parente.

12.7 Mode projet (regroupement + % d’avancement)

  • Entité projects (ou champ project_id sur tasks, déjà évoqué en §10.2) avec libellé, dates optionnelles.
  • Avancement : ex. ratio des sous-tâches terminées, ou des tâches du projet marquées terminées ; affichage d’un pourcentage sur le dashboard et dans la liste projet.

12.8 Exportation avancée

  • Déjà couverte (filtres journalier → annuel, PDF / Excel / Word / PowerPoint, preview, stats) : voir section 10. Ne pas dupliquer la spécification ici.

12.9 Système de tags

  • Modèle relationnel : tables tags (id, user_id, name, couleur optionnelle) et task_tags (task_id, tag_id) pour mots-clés multiples.
  • Enrichit recherche et filtres (combinable avec catégories §11). Index sur les noms pour la perf.

12.10 Score de productivité

  • Indicateur composite (ex. 0–100) combinant : volume de tâches terminées, respect des délais (échéance vs completed_at), régularité (jours actifs sur N — à partir des connexions ou des actions en base, sans être intrusif).
  • Affichage dans le dashboard ; documenter la formule pour la transparence ; rester prudent sur la charge cognitive et l’aspect « gamification » (optionnel / désactivable).

12.11 Ordre de mise en œuvre suggéré (hors §9–11)

  1. Champs priority, completed_at, created_at sur les tâches.
  2. Stats dashboard + API stats (§12.3), puis graphiques in-app (§12.4).
  3. Sous-tâches (§12.6), puis projets + % (§12.7).
  4. Tags (§12.9) et priorité suggérée (§12.1).
  5. Rappels (§12.5) ; planification auto avancée (§12.2) en dernier.

13. Analyse, prédictions et optimisation (périmètre prioritaire vs plus tard)

Objectif global (vision) : faire de TaskHub une plateforme d’aide à la gestion du temps et des objectifs. Ce paragraphe ne spécifie en détail que ce qui vaut la peine d’être attaqué en premier ; le reste est volontairement laissé de côté pour l’instant (à rouvrir quand le socle données + stats + §12 sera stable).

13.1 À prioriser maintenant (règles + données, peu ou pas de ML)

  1. Détection de surcharge de travail — Agréger par jour / semaine le nombre de tâches actives, une estimation de charge (durée ou simple comptage), et des seuils configurables. Alerter l’utilisateur dans l’UI (et éventuellement email plus tard) sans analyse comportementale fine.
  2. Réorganisation « intelligente » après retard — Si une tâche n’est pas terminée à l’échéance : proposer explicitement (l’utilisateur valide) un nouveau créneau ou une nouvelle date, avec impact visible sur les tâches suivantes (glissement simple). Éviter la réécriture automatique silencieuse du planning au début.
  3. Tâches répétitives → récurrence — Détecter ou laisser l’utilisateur marquer une tâche comme récurrente (rrule simplifié ou fréquence hebdo/mensuel). Les « patterns » répétitifs peuvent commencer par une création manuelle de modèle récurrent sans data mining.
  4. Objectifs intelligents (liaison tâches ↔ objectifs) — Entité goals (mensuel / annuel) + lien task.goal_id ou table de liaison. Tableaux de bord : progression vers l’objectif à partir des tâches terminées / points. Cela structure le produit sans IA obligatoire.

Rapports périodiques riches (stats + graphiques + recommandations) : s’appuyer sur la section 10 (exports) et la §12.3–12.4 (stats et graphiques in-app) plutôt que de dupliquer une nouvelle pile « rapports » ici.

13.2 Laissé pour plus tard (hors périmètre immédiat)

Ne pas implémenter tout de suite ; à rouvrir avec opt-in juridique, budget API et données suffisantes :

  • Moteur complet d’analyse de comportement (heures de travail, inactivité, moments de pic) au-delà de simples agrégats.
  • Planification prédictive (durée estimée + créneau optimal par modèle prédictif).
  • Assistant IA large (suggestion de nouvelles tâches, coaching permanent) — préférer plus tard des assistants ciblés (ex. résumé d’export déjà évoqué §10.5).
  • Score avancé discipline / constance séparé : fusionner avec le score de productivité (§12.10) en un seul bloc évolutif et transparent plutôt que multiplier les scores.

14. Liens utiles dans le repo

Une fois le backend présent dans le dépôt, mettre à jour ce fichier avec les noms exacts des dossiers, scripts npm et l’URL de production.