02 - Conventions & organisation du code

1. Réponse directe à la question posée

« Est-ce découpé dans le style des conventions de code, ou tout au même endroit ? »

Tout est au même endroit. L'intégralité de l'application - pages, composants, logique métier, constantes, helpers - vit dans un seul fichier : gestionrh-github/src/App.jsx (~2 800 lignes). Il n'y a ni dossier components/, ni pages/, ni hooks/, ni services/, ni lib/, ni utils/.

gestionrh-github/
├── index.html
├── package.json / package-lock.json
├── vite.config.js / tailwind.config.js / postcss.config.js
├── netlify.toml
├── README.md
├── supabase-schema.sql / -contracts.sql / -payroll.sql / -planning.sql
└── src/
    ├── main.jsx            (10 lignes - bootstrap React)
    ├── index.css           (directives Tailwind)
    ├── supabaseClient.js   (client Supabase)
    └── App.jsx             ⬅ 2 801 lignes : TOUTE l'application

2. Ce qui est plutôt bien fait

Primitives UI factorisées en haut du fichier : Badge, Btn, Input, Select, Textarea, Modal, Card, Stat, Empty. Cohérentes, réutilisées partout → bonne base pour un futur design system.
Helpers datés/format regroupés (fmt, isoToday, diffDays, getMonday, addDays, weekLabel, csvExport).
Constantes métier centralisées en tête (CONTRACT_TYPES, LEAVE_TYPES, DOC_CHECKLIST, SHIFT_PRESETS, CITY_CONFIG…).
Nommage clair et cohérent, commentaires en français utiles (ex. sur les pièges de dates, sur la logique transport).
Séparation lecture/écriture Supabase lisible (chaque mutation met à jour l'état local en miroir).

C'est un monolithe, mais un monolithe soigné et lisible. Le problème n'est pas la propreté locale, c'est l'absence de modularité et de garde-fous.

3. Ce qui manque (conventions & outillage)

Élément attendu sur un projet React	Présent ?
Découpage en modules/dossiers	❌
TypeScript (ou PropTypes)	❌ (types installés mais inutilisés)
ESLint	❌
Prettier / config de formatage	❌
Tests unitaires (Vitest/Jest)	❌
Tests d'intégration / E2E (Playwright)	❌
CI (GitHub Actions)	❌
`.env.example`	❌ (référencé dans le README mais absent)
`.gitignore`	❌ visible (à vérifier - `node_modules` semble non versionné, OK)
Convention de commits	❌ (tous « Update App.jsx »)
Convention de branches	❌ (tout sur `main`)
CHANGELOG / versioning sémantique	❌
Documentation développeur	🟡 README de déploiement uniquement

4. Découpage cible recommandé

Sans tout réécrire, on peut extraire progressivement (voir prompts/02-refactor-decoupage) :

src/
├── main.jsx
├── App.jsx                      (routing + layout + providers, < 200 lignes)
├── lib/
│   ├── supabaseClient.js
│   ├── dates.js                 (getMonday, addDays, diffDays, fmt…)
│   ├── csv.js                   (csvExport + futurs formats comptables)
│   └── constants.js             (CONTRACT_TYPES, LEAVE_TYPES, CITY_CONFIG…)
├── hooks/
│   ├── useAuth.js
│   └── useHrData.js             (loadData + états globaux)
├── domain/                      (logique métier PURE, testable)
│   ├── payroll.js               (computeHoursFromPlanning, heures sup, dimanche)
│   ├── alerts.js                (génération des alertes)
│   └── scope.js                 (visibleEmployees, isEmployeeInScope)
├── components/
│   └── ui/                      (Btn, Modal, Badge, Card, Input, Select…)
└── pages/
    ├── DashboardPage.jsx
    ├── PlanningPage.jsx
    ├── EmployeesPage.jsx
    ├── LeavePage.jsx
    ├── PayrollPage.jsx
    ├── TransportPage.jsx
    ├── RegisterPage.jsx
    ├── SettingsPage.jsx
    ├── UsersPage.jsx
    └── employee/                (EmployeeDashboard, MaFiche, MonPlanning…)

Priorité d'extraction (valeur / effort) :

domain/payroll.js et domain/alerts.js → permet d'écrire des tests sur la partie la plus risquée (la paie).
lib/dates.js → règle l'incohérence UTC/local en un seul endroit.
components/ui/ → réutilisable, faible risque.
pages/* → un écran à la fois, en validant par npm run build à chaque étape.

5. Dette technique - inventaire priorisé

Priorité	Dette	Effet	Remédiation
P0	Schéma non versionné (`transport_receipts`, `planning_notes`, `contract_history`, `scope_*`, rôle `employee`, bucket)	Repo non reproductible	Extraire le DDL réel de Supabase → migrations
P1	Monolithe `App.jsx`	Maintenabilité	Découpage progressif (§4)
P1	0 test sur la paie/alertes	Régressions financières	Extraire `domain/` + Vitest
P1	Pas de lint/format	Incohérences, bugs bêtes	ESLint + Prettier + hook
P1	Commits sur `main`, messages non signifiants	Pas de traçabilité	Flux branche → PR, Conventional Commits (voir `CLAUDE.md`)
P2	Incohérence dates UTC/local	Décalage d'un jour	Centraliser dans `lib/dates.js`
P2	`select("*")` global sans pagination	Perf à l'échelle	Requêtes ciblées, pagination
P2	Gestion d'erreurs minimale	UX dégradée en cas de panne	Error Boundary + toasts d'échec
P3	Pas de CI	Qualité non garantie	GitHub Actions (build + lint + test)

6. Convention de commits proposée (Conventional Commits)

Format : type(scope): résumé court à l'impératif

Types : feat, fix, refactor, docs, chore, test, perf, style, ci. Scopes suggérés : planning, paie, conges, transport, salaries, auth, registre, securite, db, ui, docs, governance.

Exemples :

feat(paie): ajoute l'export EVP normalisé par société
fix(planning): corrige le décalage UTC dans le calcul des heures
refactor(ui): extrait les primitives dans components/ui
docs(audit): ajoute l'audit du 10/07/2026
chore(db): versionne les tables transport_receipts et contract_history

Rappel gouvernance (CLAUDE.md) : Claude prépare ces messages regroupés par bloc mais ne commit pas sans autorisation, et jamais sur main.