Python react django - outil saisie de temps

**cahier des charges succinct et complet** en **3 étapes** (V1–V2–V3) pour chiffrage rapide d’implémentation ; les besoins, périmètre et livrables. Stack cible : **Django (API/DB)** + **React (UI)**.

---

# Étape 1 — V1 : Saisie simple + dictionnaires de base

## Objectif

Permettre la **saisie fiable** de temps dans une **vue calendrier** et l’**enregistrement en base**, avec gestion des **listes Client/Mission/Branche** (et option **« Autre »**).

## Fonctionnalités clés

* **Calendrier React** (vue Semaine/Jour/Mois) : création, modification, suppression de créneaux (drag, resize, click).
* **Formulaire de créneau** : date, début, fin, client, mission, branche, notes, « Autre » (texte libre si non listé).
* **Dictionnaires** (Admin) : gestion des listes **Clients**, **Missions**, **Branches** (activer/désactiver, ajouter).
* **Traçabilité « Autre »** : tableau admin listant les valeurs « Autre » saisies par les utilisateurs pour correction/aiguillage.
* **Règles V1** : fin > début (bloquant) ; **overlaps tolérés** ; pas de plafond horaire.
* **Sécurité** : l’utilisateur ne voit et n’édite que **ses** créneaux ; admin gère les dictionnaires.
* **Fuseau** : Europe/Paris (stockage UTC recommandé, conversion UI).

## Données (tables à créer)

* **TimesheetEntry** : user, start\_datetime, end\_datetime, client\_id (nullable), mission\_id (nullable), branche\_id (nullable), other\_text (nullable), notes, created\_at/updated\_at.
* **ClientDictionary / MissionDictionary / BrancheDictionary** : id, name, is\_active, created\_at/updated\_at.
* (Option ultérieure) **Audit** minimal des CRUD.

## UX attendue (syntétique)

* Créneau par glisser-déposer → ouverture d’un panneau latéral / modal.
* Selects alimentés par dictionnaires actifs + option « Autre ».
* Toasts succès/erreur ; marqueur visuel si chevauchement (non bloquant).

## Livrables V1

* Schéma DB + migrations.
* API REST (CRUD créneaux, lecture dictionnaires, CRUD dictionnaires côté admin).
* Page Calendrier + formulaire créneau.
* Page Admin Dictionnaires + rapport « Autre ».
* Courte doc d’usage + README technique.

## Critères d’acceptation (exemples)

* Création/édition/suppression d’un créneau reflétée en base et visible au rechargement.
* Sélection « Autre » impossible sans texte justificatif.
* Un **admin** voit les « Autre » et peut corriger (ajout d’un item de liste).

---

# Étape 2 — V2 : Accélérateurs de saisie (copie & créneaux prédéfinis)

## Objectif

**Réduire la ressaisie** grâce à la duplication et aux **créneaux par défaut**.

## Fonctionnalités clés

* **Duplication rapide** d’un créneau existant :

* Période cible simple (prochains N jours / semaine courante / mois courant ou suivant).
* Choix des jours (Lun–Dim).
* Options : ignorer week-ends / jours fériés, stratégie de conflit (**sauter / écraser / autoriser overlap**).
* **Créneaux par défaut (modèles)** :

* Chaque utilisateur définit ses **horaires types** par jour de semaine (avec client/mission/branche/notes facultatifs).
* Application d’un modèle sur une période (semaine/mois) avec la même stratégie de conflit.
* **Raccourcis UI** : boutons « Dupliquer sur la semaine », « Remplir ma semaine avec mes défauts ».
* **Administration (optionnel)** : modèles organisationnels proposés par l’admin.

## Données (tables à créer/compléter)

* **DefaultSlotTemplate** : owner\_user (nullable si modèle global), weekday, start\_time, end\_time, client\_id/mission\_id/branche\_id (nullable), notes, is\_active, timestamps.
* **HolidayFR** : date, name (semence annuelle).

## Livrables V2

* Endpoints « duplication en masse » et « application de modèles ».
* UI : assistant de duplication + page « Mes créneaux par défaut ».
* Semence jours fériés FR (année en cours + N+1).

## Critères d’acceptation

* Duplication d’un créneau sur une semaine crée les entrées attendues selon la stratégie de conflit.
* Application d’un modèle personnel **préremplit** correctement une semaine ou un mois.
* Les jours fériés cochés en « ignorer » ne génèrent pas de créneau.

---

# Étape 3 — V3 : Reporting très simple (tableaux & exports)

## Objectif

Offrir une **lecture rapide** des heures déclarées, par période et par client, et un **export** basique pour partage/contrôle.

## Fonctionnalités clés

* **Vue utilisateur** :

* Tableaux **par année** et **par mois** : totaux d’heures **par client** (et, si utile, par mission).
* Sélection de période (année/mois).
* **Vue admin** :

* Les mêmes agrégations sur un **périmètre filtrable** (utilisateur, client, mission, période).
* **Exports** : **CSV / Excel** conformes à la table affichée (mêmes colonnes, mêmes filtres).
* **Pas de graphiques** ni KPI avancés (volontairement minimal).

## Données / calculs

* Agrégations simples sur **TimesheetEntry** (durée = end − start).
* Aucune dépendance à une hiérarchie d’équipe dans V3 (extension possible plus tard).

## Livrables V3

* Endpoints de listing agrégé (user/admin).
* Pages tables (utilisateur, admin) + export CSV/Excel.
* Documentation courte sur filtres et export.

## Critères d’acceptation

* Totaux mensuels/annuels par client exacts à ±1 minute (arrondi affichage défini).
* Export identique à la vue filtrée.
* Un admin peut filtrer par utilisateur et obtenir un total par client cohérent.

---

## Hypothèses & contraintes communes

* **Auth** : réutilisation de l’auth existante (sessions/JWT). Droits basiques (user vs admin).
* **Perfs** : chargement par fenêtre de dates côté calendrier ; index DB sur (user, start\_datetime).
* **Qualité** : messages d’erreur clairs ; i18n FR prêt ; accessibilité minimale (labels/ARIA).
* **Sécurité & RGPD** : HTTPS, logs d’accès, données minimales (FK user), sauvegardes régulières.
* **Environnement** : Django + Django REST Framework, Postgres recommandé ; React (calendrier type FullCalendar ou équivalent).

---

## Périmètre hors V1–V3 (pour chiffrage séparé ultérieur)

* Validation workflow (soumettre/approbation), règles anti-overlap strictes, plafonds horaires.
* Imports calendriers externes (Google/Microsoft), hiérarchie d’équipe et reporting par équipe.
* Dashboards graphiques, KPI avancés, budgets/projets, centres de coûts.