# CLAUDE.md Ce fichier fournit des repères à Claude Code (claude.ai/code) pour travailler dans ce dépôt. ## Vue d'ensemble du projet TECHNIFORM : une plateforme de gestion multi-centres de formation pour TECHNIDEV et ses partenaires (3 centres multimédia actuellement, dont Goz Beida — extensible, le nombre de centres n'est jamais figé en dur). Le cahier des charges complet (v2.5) se trouve dans [docs/cahier-des-charges.md](docs/cahier-des-charges.md) — à lire avant toute décision d'architecture ; ce fichier ne fait que résumer ce qui est utile au quotidien. **Statut : les 6 phases du plan d'implémentation sont terminées.** Application fonctionnelle de bout en bout (staff + espace apprenant + dashboard partenaire + rapports/assiduité), avec une suite de tests automatisés (325 tests, 1773 assertions) couvrant l'isolation par centre, la portée de l'espace apprenant, et les règles métier de la section 8 du cahier des charges. Le projet est passé en revue de recette (voir « Recette » ci-dessous) et un audit de sécurité complet (voir « Audit de sécurité du 2026-08-10 » ci-dessous) ; il reste des corrections/ajustements à faire au fil de l'eau — ce fichier doit continuer à être tenu à jour à cette occasion. **Base de données vidée à nouveau le 2026-08-13** (voir section dédiée plus bas) pour repartir propre, seul le compte admin conservé. **Simplification majeure du 2026-08-07 : Groupe, Période et Répartition ont été entièrement supprimés** (voir la section dédiée plus bas, juste avant « Organisation du code »). Un apprenant est désormais lié directement à sa Formation + son Centre, sans étape intermédiaire de répartition en groupe ni notion de session datée. **Toute mention de `Groupe`/`Periode`/répartition dans les sections historiques ci-dessous (chantiers datés du 2026-08-05/06) documente une architecture qui n'existe plus** — conservée telle quelle pour comprendre le raisonnement de l'époque, mais à ne plus utiliser comme référence du code actuel. Les sections « Modèle métier », « Décisions structurantes » et « Organisation du code » ont, elles, été mises à jour pour refléter l'état présent. **Revirement du 2026-08-29 : le fichier `Techniform designer skill.MD` (racine du dépôt) n'est plus la référence de design.** Ce skill a guidé toute la refonte visuelle documentée dans ce fichier depuis le 2026-08-05 (palette, typographie, budget d'animation quasi nul, interdiction des librairies d'animation JS, sobriété pour l'espace apprenant) — le porteur de projet a explicitement demandé de ne plus en tenir compte à partir de maintenant, sans le supprimer du dépôt (conservé tel quel comme trace historique, mais à ne plus consulter pour une décision de design). Seule dérogation précisée explicitement à ce moment : les micro-animations sont désormais autorisées largement (au-delà des quelques transitions listées par l'ancien skill), y compris là où il les interdisait (badges/compteurs qui se rafraîchissent, etc.) — reste à trancher au cas par cas si une librairie d'animation JS (Framer Motion, GSAP...) devient nécessaire, l'ancien interdit de principe ne tient plus mais aucune n'a encore été ajoutée. Toute décision de design prise avant cette date reste documentée ci-dessous pour comprendre le raisonnement de l'époque, mais n'est plus une contrainte contraignante pour la suite — seul le jugement au cas par cas (cohérence avec l'existant, lisibilité, performance) fait foi désormais. **Base de données vidée le 2026-08-05** pour démarrer la saisie de vraies données (`php artisan migrate:fresh` puis `php artisan db:seed --class=RoleSeeder` uniquement — les données de démo, comptes de démo listés ci-dessous inclus, n'existent donc plus). Seule la table `roles` (spatie/laravel-permission) est réensemencée : indispensable au fonctionnement de l'app dès la première inscription (`UserObserver::syncRoles()` échoue avec `RoleDoesNotExist` sinon), ce n'est pas une donnée de démo. Premier compte à créer : un admin, via `php artisan tinker` (pas de route d'auto-inscription pour l'admin, voir plus haut) ; les autres rôles staff peuvent ensuite s'auto-inscrire via `/register`. Pour retrouver un jeu de données de démo complet à des fins de test, `php artisan migrate:fresh --seed` (tous les seeders) reste disponible mais n'a plus été rejoué depuis ce vidage. ### Stack (installée) Laravel 12 (backend) + Inertia.js + React 18 (frontend) + Tailwind CSS v3 + MySQL (XAMPP, base `techniform`). Rôles/permissions staff via `spatie/laravel-permission` (table `users.role` = source de vérité pour les Policies, synchronisée vers spatie par `UserObserver`). Guard Laravel dédié `apprenant` (voir `config/auth.php`), distinct du guard `web` du staff — modèle `Apprenant` avec mot de passe stocké réversible (pas de hash), comparaison manuelle dans `ApprenantAuth\AuthenticatedSessionController` avec rate limiting dédié. **Écart volontaire par rapport au cahier des charges** : la colonne `users.name` (convention Breeze) a été conservée telle quelle plutôt que renommée en `nom`, pour éviter de modifier tout le scaffold Breeze généré (ProfileController, formulaires React, etc.) sans bénéfice fonctionnel — c'est un nom de colonne technique, couvert par la règle CLAUDE.md « noms techniques en anglais ». ### Modèle métier — points clés à connaître - Hiérarchie staff : **Admin (TECHNIDEV, portée globale)** → **Gestionnaire (portée limitée à son centre, ex-"Responsable de centre")** → **Formateur / Secrétaire (portée limitée à leurs apprenants/inscriptions)**. **Partenaire** dispose d'un accès en lecture globale. - **L'apprenant a désormais un compte propre** (identifiant `prenom.nom` normalisé + mot de passe 4 chiffres, générés automatiquement), avec une portée strictement limitée à sa propre fiche — ce n'est pas un rôle staff, mais ce n'est plus une simple donnée passive non plus. - Entités principales : `centres`, `users` (staff : admin/gestionnaire/formateur/secretaire/partenaire), `formations` (catalogue global) + `chapitres` (propres à chaque centre) + `modules_formation` (leçons, rattachées à un chapitre), `apprenant_statuts` (table de référence extensible, pas un enum figé), `apprenants` (compte dédié, guard séparé, lié directement à sa `formation_id`+`centre_id`), `inscriptions` (une par épisode d'inscription, garde sa propre `formation_id` en instantané — voir §Groupe/Période/Répartition supprimés), `lecons_du_jour` (planification par le formateur, par formation+centre), `progression_modules` (une ligne **uniquement** quand une leçon est cochée — pas de pré-création), `presences` (présent/absent par jour, écrit en temps réel à la coche). - Pas de suppression physique — l'historique est conservé pour les rapports. - **Mot de passe apprenant stocké de façon réversible** (`Crypt::encryptString()`, pas un hash irréversible) — décision assumée pour permettre au staff du centre de dépanner un apprenant qui a oublié ses identifiants. Accès à journaliser (qui consulte le mot de passe de qui, quand). - **Invariant critique de sécurité** : chaque ressource propre à un centre (apprenants, inscriptions, chapitres, utilisateurs staff) doit être filtrée par `centre_id` via des Policies et scopes Laravel — ne jamais faire confiance à un identifiant de ressource venant de l'URL seul. Un gestionnaire/formateur/secrétaire du centre A ne doit jamais pouvoir lire ou modifier les données du centre B ; un apprenant ne doit jamais sortir de sa propre fiche. À construire dès la Phase 1, pas en rattrapage. ### Décisions structurantes déjà actées (voir section 5 du cahier des charges pour le détail complet) - Le catalogue de formations est global/partagé, pas propre à chaque centre. - Le gestionnaire (ex-responsable de centre) est un rôle distinct, pas "formateur + permissions supplémentaires". - L'accès partenaire est global (tous les centres), sans filtrage par partenaire. - Les rapports s'exportent en PDF (`barryvdh/laravel-dompdf`) pour la v1 ; l'export Excel est reporté. - Le dashboard partenaire utilise du rafraîchissement/polling (Inertia), pas de WebSockets, pour la v1. - Espace apprenant : cocher les leçons du jour prédéfinies par le formateur (validation immédiate, correction possible par le formateur), saisie libre uniquement si `formations.saisie_libre_autorisee` est activé. - `progression_modules` : création à la coche uniquement (pas de fan-out) ; leçons restantes calculées par différence. - Durée totale du projet jugée non nécessaire à préciser par le porteur du projet — pas de planning jour par jour, les phases du cahier des charges (§6) suffisent. - **Revirement du 2026-08-05** : auto-inscription staff **ouverte** (gestionnaire/formateur/secrétaire/partenaire — admin exclu) via `/register`, chacun choisit son propre rôle **sans validation d'un admin**. Ceci **annule** la décision initiale du cahier des charges §3.1 ("Admin crée les gestionnaires, gestionnaires créent formateurs/secrétaires", aucune auto-inscription). Le porteur du projet a été explicitement informé du risque (n'importe qui peut s'auto-attribuer un accès gestionnaire ou partenaire) et a choisi cette option en connaissance de cause plutôt que l'alternative avec validation admin proposée. ~~À ne pas re-proposer de "corriger" sans qu'il le redemande.~~ **Re-demandé et corrigé le 2026-08-29** : voir la section dédiée plus bas — l'auto-inscription reste ouverte (rôle/centre toujours choisis librement), mais un admin doit désormais valider le compte avant qu'il puisse se connecter. **Supprimée entièrement le 2026-09-24** (voir la section dédiée) : `/register` n'existe plus, seuls les comptes créés par l'admin dans `/utilisateurs` existent. - **Revirement du 2026-08-05 (suite)** : la gestion des comptes staff (`/utilisateurs` — liste, création, modification) est désormais **réservée à l'admin**. Avant ce correctif, le gestionnaire pouvait créer/modifier des formateurs/secrétaires de son centre (`UserPolicy`) — cohérent avec l'auto-inscription désormais ouverte, qui a remplacé ce besoin. **Bug de sécurité corrigé au passage** : `UserController::index()` n'appelait jamais `$this->authorize()`, donc n'importe quel staff connecté (formateur, secrétaire, y compris partenaire en portée globale) pouvait consulter `/utilisateurs` directement par URL, pas seulement le gestionnaire — la Policy `viewAny()` existait mais n'était simplement jamais invoquée. Verrouillé par `Tests\Feature\Security\CentreIsolationTest` (`gestionnaire/formateur cannot view the users list`, `admin can view the users list`). ### Chantier « simplification du parcours admin » (2026-08-06) Retour d'usage du porteur de projet : la notion de "groupe" mélangeait plusieurs choses et se retrouvait dispersée dans toute l'app. Traité en 6 blocs validés un par un (voir le plan complet, conservé pour référence, dans les plans Claude Code de la session), puis implémentés dans l'ordre ci-dessous — chaque étape vérifiée par `php artisan test` + `npm run build` avant de passer à la suivante. - **Bloc 1 — Groupe/Période inchangés.** La proposition initiale de fusionner Groupe+Période en une entité "Session" a été étudiée puis **rejetée** : `Groupe` porte déjà `periode_id` → `Periode` porte déjà `formation_id`+`centre_id`, la fusion conceptuelle existait déjà dans les données. Décision : garder les noms "Groupe"/"Période" tels quels (pas de renommage), garder Période comme écran séparé, garder la répartition "répartir seulement" (distribue dans des groupes déjà créés, ne les crée pas à la volée). **Risque de nommage évité** : `SESSION_DRIVER=database` — Laravel a sa propre table `sessions` (stockage des sessions HTTP, créée dans la migration `users`) ; renommer l'entité métier "Session" aurait collisionné avec cette table système. - **Bloc 2 — Page d'accueil avec sélection de rôle** (`Pages/Auth/SelectionRole.jsx`, nouvelle) : `/` affiche désormais, pour un visiteur non connecté, 6 tuiles avec icône (Admin/Partenaire/Gestionnaire/Formateur/Secrétaire/Apprenant) au lieu de rediriger aveuglément vers `/login`. Les 5 tuiles staff mènent à `route('login')` (formulaire déjà existant, inchangé — le rôle est déterminé par le compte en base, pas saisi à la connexion), la tuile Apprenant mène à `route('apprenant.login')`. `routes/web.php` : le fallback `redirect()->route('login')` est remplacé par `Inertia::render('Auth/SelectionRole')`, la redirection des utilisateurs déjà connectés vers leur dashboard reste inchangée. - **Bloc 3 — Toutes les ressources admin en modale, plus de pages Create/Edit dédiées.** `Components/Modal.jsx` (Headless UI, déjà présent mais utilisé nulle part sauf la suppression de compte) généralisé à Centres, Utilisateurs, Formations, Statuts apprenant, Périodes, Groupes, Apprenants, Inscriptions, Répartition — plus `backdrop-blur-sm` sur l'overlay ("overlay flouté"). Chaque page `Index.jsx` gère désormais un état local (`useState(null | 'create' | enregistrement)`) ; le contenu de chaque `Form.jsx` a été "dénudé" (plus de `AuthenticatedLayout`/`Head`, un `onClose`/`onSuccess` en props) pour vivre dans la modale. **Les routes/méthodes `create`/`edit` ont été supprimées** (`Route::resource(...)->except([..., 'create', 'edit'])`, méthodes de contrôleur retirées) — `/centres/create`, `/groupes/{id}/edit`, etc. n'existent plus du tout, seul le clic sur "Nouveau"/"Modifier" depuis la liste ouvre la modale. Conséquence en cascade : le lien nav "Inscriptions" (`LIENS_PAR_ROLE`, `Layouts/AuthenticatedLayout.jsx`) et le bouton "Placer dans un groupe" ne peuvent plus pointer vers une page `.../create` dédiée — ils pointent maintenant vers `apprenants.index`/`inscriptions.index` avec `?action=create` en query string, que la page cible lit au montage (`new URLSearchParams(window.location.search)`) pour ouvrir la modale directement, sans liste intermédiaire. La répartition automatique (Bloc 1, inchangée dans son comportement) est devenue `Pages/Staff/Repartition/Modale.jsx`, un composant partagé ouvert soit depuis `Periodes/Index.jsx` soit depuis `Apprenants/Index.jsx` : comme les données dépendent de la période choisie (pas connues à l'avance par la page appelante), `RepartitionController::create()` renvoie désormais du JSON (`response()->json()`, plus `Inertia::render()`) récupéré via `axios` à l'ouverture de la modale — `store()` inchangé. - **Bloc 4 — Filtre centre sur le dashboard partenaire/admin.** Constat : Rapports (écran + export PDF) et Répartition avaient déjà un filtre/scope par centre correct — seul `Partenaire\DashboardController` affichait systématiquement *tous* les centres sans possibilité d'en isoler un seul. Ajout d'un `` que Rapports/Emploi du temps/Dashboard partenaire) — un acteur d'un centre continue de ne voir que le sien via `visibleTo()`, sans filtre affiché (inutile pour lui). La liste reste organisée par formation (`grouperParFormation`, déjà en place) — pas de mélange, conforme à la demande explicite du porteur de projet. - **Nouveau : barre de recherche client-side** (`Components/SearchInput.jsx`, nouveau composant partagé) sur les 5 pages de liste les plus consultées : Apprenants (nom, identifiant), Groupes (nom, formateur), Utilisateurs (nom, email), Périodes (centre), Inscriptions (apprenant). Filtrage en mémoire sur les données déjà chargées (pas de requête serveur) — cohérent avec l'absence de pagination sur ces listes (gap déjà documenté, volume de données encore faible). - **Nouveaux tests** : `Tests\Feature\Metier\ApprenantShowEtFiltreTest` (filtre centre, fiche détail avec bonnes données, 403 croisé centre A/B sur la fiche). Le tri alphabétique et les barres de recherche (logique 100% côté client) ne sont pas couverts par `php artisan test` — à vérifier visuellement. - **Correctif du 2026-08-06 (suite) — le premier jet du filtre ne correspondait pas à la demande.** Après la passe ci-dessus, `Staff/Apprenants/Index.jsx` groupait toujours les apprenants en sections empilées par formation (`grouperParFormation`, une `DataTable` par formation) avec seulement un filtre centre en plus — pas de vrai filtre formation, et un rendu jugé "trop compliqué à manipuler" pour ce qui devait être une liste simple. Remplacé par : **un filtre "Formation" en `` centre sur `centres.length > 0` (ou `> 1`) — un raccourci qui marche tant qu'il existe déjà plusieurs centres en base, mais qui masque le filtre pour un admin/partenaire tant que la liste des centres n'est pas encore étoffée, alors que c'est précisément quand la base vient d'être vidée que ce filtre est censé exister pour l'avenir. Corrigé en se fiant au **rôle** de l'acteur (`['admin', 'partenaire'].includes(auth.user.role)`) plutôt qu'au nombre de centres actuellement en base — le filtre s'affiche désormais dès qu'un acteur a la portée globale, même avec 0 ou 1 centre. Seul le `` de création) à `$user->formations()` pour un acteur Formateur ; `GroupeController::formOptions()` utilise désormais `Periode::visibleTo($user)` (formation comprise) pour les périodes proposées, et enrichit chaque formateur listé d'un `formation_ids` (pour le filtrage côté React) ; `EmploiDuTempsController`/`InscriptionController` remplacés en `visibleTo()` là où c'était auparavant un `when(!$global, whereHas(centre))` manuel — factorise centre + formation d'un coup. `RegisteredUserController`/`UserController` (`/utilisateurs`, admin-only) synchronisent `formation_ids` (`sync()`) à la création/modification d'un compte Formateur. - React : `Auth/Register.jsx` et `Staff/Utilisateurs/Form.jsx` affichent des cases à cocher "Formations enseignées" quand `role === 'formateur'` (`formation_ids`, requis min. 1) ; `Staff/Utilisateurs/Index.jsx` affiche les formations d'un formateur en colonne ; `Staff/Groupes/Form.jsx` filtre en plus la liste des formateurs proposés par `formation_ids.includes(periodeSelectionnee.formation_id)` (confort client, la vraie garde est côté serveur). - Historique (`/historique`) **non retouché** : reste centre-large pour tous les rôles y ayant accès (gap connu, accepté — `RapportGenere.formation_id` peut être `null` selon le filtre choisi à l'export, un filtrage naïf par formation y aurait exclu à tort des rapports légitimes du formateur ; à refaire proprement si le besoin se confirme). - Tests existants ajustés (formateurs de test créés sans formation attachée = accès nul avec le nouveau scope, comportement voulu mais qui cassait des tests écrits avant ce chantier) : `ChapitreProgrammeTest`, `GroupeHoraireTest`, `IdentifiantsExportTest`, `ProgressionTest`, `RepartitionTest`, `RegistrationTest` — chacun attache désormais explicitement la formation pertinente au formateur de test via `$formateur->formations()->attach($formation->id)`. Nouveau : `Tests\Feature\Security\FormationScopeTest` (matrice formateur × formation, même centre — apprenants/groupes/inscriptions/chapitres invisibles ou 403 hors formation, assignation formateur↔groupe incohérente rejetée, inscription formateur avec/sans `formation_ids`). - **Suite directe (même jour) — un formateur gère lui-même ses formations depuis son profil.** Retour du porteur de projet après ce chantier : « chaque utilisateur doit pouvoir éditer son profil » — creusé jusqu'à confirmer que le vrai manque concernait spécifiquement le formateur : nom/email/mot de passe se modifiaient déjà pour tous les rôles via la page Profil (scaffold Breeze, `ProfileController`), mais les formations enseignées restaient strictement admin-only (`/utilisateurs`), sans aucune vue ni action pour le formateur lui-même sur sa propre donnée la plus structurante (elle conditionne tout ce qu'il voit désormais). `ProfileController::edit()` transmet `formations` (catalogue complet) + `formationIds` (siennes) uniquement pour un acteur Formateur ; `ProfileUpdateRequest` valide `formation_ids` (requis, min 1) dans ce cas ; `ProfileController::update()` fait `$user->formations()->sync(...)` après la sauvegarde du reste. `Profile/Partials/UpdateProfileInformationForm.jsx` affiche les mêmes cases à cocher que `Register.jsx`/`Staff/Utilisateurs/Form.jsx` quand `auth.user.role === 'formateur'`. **Risque accepté en connaissance de cause, cohérent avec le précédent déjà posé pour l'auto-inscription** (rôle/centre choisis librement sans validation admin) : un formateur peut ainsi s'auto-attribuer l'accès à n'importe quelle formation du catalogue, pas seulement celles qui lui ont été confiées — le porteur de projet a explicitement demandé cette autonomie plutôt qu'un circuit de validation admin. Le rôle et le centre, eux, restent exclusivement modifiables par l'admin via `/utilisateurs`. **Piège de test découvert au passage** : `UserFactory` a `RoleStaff::Formateur` comme rôle par défaut — tout `User::factory()->create()` sans rôle explicite crée donc un formateur, et `PATCH /profile` sans `formation_ids` échoue désormais la validation ; `Tests\Feature\ProfileTest` ajusté en conséquence (formation créée + attachée avant chaque test de mise à jour de profil), plus deux tests dédiés (gestion des formations depuis le profil, erreur si aucune formation soumise). ### Groupe, Période et Répartition supprimés — inscription directe à la formation (2026-08-07) Retour explicite du porteur de projet, dans la continuité du chantier de restriction du formateur par formation (ci-dessus) : l'app doit rester simple. Le double niveau **Formation → Période → Groupe** (une période datée contenant des groupes avec formateur/horaire/jours/capacité, dans lesquels un apprenant devait être placé après une étape de répartition manuelle ou automatique) a été jugé inutilement complexe. **Groupe, Période et Répartition n'existent plus du tout** — ni tables, ni modèles, ni contrôleurs, ni pages. Un apprenant inscrit atterrit **immédiatement** dans la liste de sa formation, plus d'état intermédiaire « en attente de répartition ». **Modèle de données** : - `inscriptions` perd `groupe_id`, gagne `formation_id` — un **instantané** de la formation suivie à ce moment précis (distinct de `apprenants.formation_id`, qui peut changer plus tard : préserve l'exactitude de l'historique des inscriptions passées même après un changement de formation). - `lecons_du_jour` perd `groupe_id` — ne garde que `module_formation_id` + `date_prevue` ; formation et centre se déduisent via `module_formation → chapitre` (déjà propre à chaque centre depuis le bloc 5 du chantier précédent). - `presences` inchangée dans sa forme, mais **écrite en temps réel** : `Actions\Progression\CocherLecon` fait désormais aussi `$inscription->presences()->updateOrCreate(['date_session' => today()], ['present' => true])` juste après avoir enregistré la coche. Plus de job nocturne (`presences:generer-du-jour` supprimé, ainsi que `CalculerPresenceJournaliere`), plus de notion de « jours prévus » par un horaire de groupe — un apprenant est présent un jour donné s'il a réellement coché quelque chose ce jour-là, point. - `rapports_generes` perd `periode_id`/`groupe_id` (garde `centre_id`/`formation_id`). **Inscription automatique** : `Actions\Apprenants\CreateApprenantAccount` crée désormais l'`Inscription` (`statut = en_cours`) dans la foulée de l'`Apprenant`, plus d'étape séparée de placement. Si `formation_id` change à l'édition (`ApprenantController::update()`), l'inscription active est close (`statut → abandonne`) et une nouvelle est ouverte pour la nouvelle formation. « Marquer abandonnée » (ex-`InscriptionController::destroy`) est désormais une action sur la fiche apprenant : `PATCH apprenants/{apprenant}/abandonner`. **Ce qui a disparu** : modèles `Groupe`/`Periode`/`RepartitionEffectuee` ; contrôleurs `GroupeController`/`PeriodeController`/`RepartitionController`/`EmploiDuTempsController`/`InscriptionController` ; leurs Requests/Policies ; Actions `RepartirApprenantsEnGroupes`/`DetectHoraireConflict`/`CalculerPresenceJournaliere` + règle `NoHoraireOverlapRule` ; commande `presences:generer-du-jour` ; pages React `Staff/{Groupes,Periodes,Repartition,EmploiDuTemps,Inscriptions}/*` ; vue PDF `identifiants-groupe.blade.php` ; seeders `PeriodeSeeder`/`GroupeSeeder`/`InscriptionSeeder` (ce dernier redondant : `ApprenantSeeder` crée déjà l'inscription via `CreateApprenantAccount`) ; utilitaire `Utils/grouperParFormation.js` (plus aucun appelant) ; enum `StatutPeriode` ; tableau « Répartitions effectuées » de l'Historique ; entrées de nav Périodes/Groupes/Emploi du temps. **Ce qui a été ajouté ou étendu** : - **Planification de la leçon du jour** déplacée sur `Staff/Formations/Programme.jsx` (bouton « Planifier une leçon », `` de chapitre existant **ou** bascule « + Nouveau chapitre » (titre libre, + `` de leçon existante de ce chapitre **ou** bascule « + Nouvelle leçon » (titre libre) ; toujours forcé sur « nouvelle leçon » si le chapitre est neuf ou n'a encore aucune leçon. `StoreLeconDuJourRequest`/`LeconDuJourController::store()` acceptent désormais `chapitre_id`|`nouveau_chapitre_titre` et `module_formation_id`|`nouveau_module_titre` en plus de `date_prevue` — création du chapitre et/ou du module dans une transaction DB si besoin (`ordre` auto-calculé via `max('ordre')+1`), puis création de la `LeconDuJour`, avant de vérifier au passage (`withValidator`) que tout chapitre/module choisi existant appartient bien à la formation et au centre de l'acteur — même garde que l'ancien flux, désormais aussi appliquée au chapitre. `chapitres.store`/`ChapitreController::store()` restent en place (testés, potentiellement réutilisables) mais ne sont plus atteignables depuis cette UI. - **Bug critique corrigé le 2026-08-07 — « Planifier un cours » ne créait silencieusement rien de nouveau, dès qu'au moins un chapitre existait déjà.** Signalé par le porteur de projet : le chaînon formateur planifie → apprenant voit/coche n'était « pas fonctionnel ». Cause : dans `PlanifierCoursForm` (`Staff/Formations/Programme.jsx`), `useForm()` initialise `chapitre_id`/`module_formation_id` avec le premier chapitre/module existant (`chapitres[0]?.id`) — en cliquant « + Nouveau chapitre »/« + Nouvelle leçon », l'UI bascule bien sur les champs texte, mais **ces deux ids restaient dans `data`** (jamais vidés) et partaient donc dans la requête **en plus de** `nouveau_chapitre_titre`/`nouveau_module_titre`. Côté serveur, `LeconDuJourController::store()` et `StoreLeconDuJourRequest` donnaient la priorité à `chapitre_id`/`module_formation_id` dès qu'ils étaient renseignés (`if ($data['chapitre_id'] ?? null)`) — le nouveau titre saisi par le formateur était donc silencieusement ignoré, et la leçon replanifiée sur le **premier chapitre/leçon existant**, sans aucune erreur visible. Les tests HTTP existants ne l'avaient jamais détecté car ils postaient directement `nouveau_chapitre_titre` seul, sans jamais simuler l'état réel du formulaire React (ids résiduels inclus) — piège classique « le contrat serveur est testé, pas le payload réel envoyé par le client ». Corrigé à deux niveaux : (1) `Programme.jsx` — `toggleNouveauChapitre()`/`toggleNouveauModule()` vident désormais explicitement `chapitre_id`/`module_formation_id` (et réciproquement `nouveau_*_titre`) à chaque bascule, et `choisirChapitre()` resynchronise `module_formation_id` sur le premier module du nouveau chapitre choisi (même bug latent si on changeait de chapitre après avoir sélectionné une leçon) ; (2) `StoreLeconDuJourRequest::withValidator()` — défense en profondeur, rejette désormais explicitement (422) tout payload où `chapitre_id`+`nouveau_chapitre_titre` (ou `module_formation_id`+`nouveau_module_titre`) sont renseignés ensemble, pour qu'un futur bug similaire échoue bruyamment plutôt que de replanifier silencieusement au mauvais endroit. Verrouillé par `Tests\Feature\Metier\ChapitreProgrammeTest::test_cannot_plan_a_cours_with_both_an_existing_and_a_new_chapitre`/`..._module`. - **Retour d'usage du 2026-08-07 (suite) — ordre des chapitres/leçons toujours auto-incrémenté, jamais saisi à la main.** `StoreChapitreRequest`/`StoreModuleFormationRequest` n'acceptent plus du tout de champ `ordre` en entrée (retiré des règles de validation — une valeur envoyée quand même est silencieusement ignorée par `validated()`) ; `ChapitreController::store()`/`ModuleFormationController::store()` calculent systématiquement `(max('ordre') sur le même périmètre ?? 0) + 1` avant l'insertion — même logique que celle déjà en place dans `LeconDuJourController::store()` pour la création à la volée. Le champ "Ordre" a été retiré du formulaire `ModuleForm` en mode création (`Staff/Formations/Programme.jsx`) ; il reste affiché en mode édition sur `ChapitreForm`/`ModuleForm` pour permettre de réordonner manuellement un chapitre/une leçon existant. Verrouillé par `Tests\Feature\Metier\ChapitreProgrammeTest::test_chapitre_and_module_ordre_auto_increment_and_ignore_client_input`. - **Retour d'usage du 2026-08-07 (suite) — colonne de numérotation par défaut sur toutes les listes.** `Components/DataTable.jsx` affiche désormais une colonne `#` (numéro de ligne, `rowIndex + 1`) en première position par défaut (prop `numerote`, `true` sauf désactivation explicite) — s'applique automatiquement aux 7 pages qui utilisent ce composant partagé (Apprenants, Utilisateurs, Formations, Statuts apprenant, Centres, Rapports, Présences), sans avoir à toucher chacune. **Volontairement pas de `sticky`** sur cette colonne : au défilement horizontal mobile, c'est la colonne suivante (nom, généralement) qui doit rester visible pour savoir "quelle ligne c'est" — un numéro seul ne suffit pas, elle garde donc son propre traitement `sticky` déjà en place. Décision de ne **pas** numéroter les tableaux construits à la main hors `DataTable` (dashboards par rôle, Historique, Partenaire/Dashboard) : ce sont des aperçus courts/chronologiques (activité récente, audit par date), pas des listes de référence à interroger par position — jugé non nécessaire par le porteur de projet lui-même (« les cas où ce n'est pas nécessaire... ne le fait pas »). - **Nouvelle page « Présence du jour »** (`Staff/Presences/Index.jsx` + `Staff\PresenceController`, route `presences.index`) : filtrable par formation (+ centre pour les rôles à portée globale) et par date, liste tous les apprenants à inscription active avec un badge présent/absent lu directement dans `presences`. - **Colonne « Activité »** sur `Staff/Apprenants/Index.jsx` (remplace l'ancienne colonne « Groupe ») : `"{coché}/{total} leçons"` par apprenant, calculé en une requête groupée (`ApprenantController::attacherActivite()`) plutôt qu'une par ligne — répond à la demande explicite du porteur de projet sur l'utilité réelle des identifiants apprenant côté formateur (« voir ce qu'il a travaillé »). - **Export CSV**, en plus du PDF déjà en place, sans nouvelle dépendance (`fputcsv` en flux via `response()->streamDownload()`) : `apprenants.export-identifiants-csv` (liste d'une formation) et `rapports.export-csv` (rapport filtré). - **Nouveau (2026-08-07) — export de la liste générale des apprenants** (`apprenants.export-liste`/`apprenants.export-liste-csv`, boutons « Exporter les apprenants (PDF/CSV) » toujours visibles sur `Staff/Apprenants/Index.jsx`, plus besoin de sélectionner une formation au préalable) : nom/identifiant/formation/statut/activité — **sans mot de passe** et sans journalisation de consultation, volontairement distinct de l'export « identifiants » (renommé « Exporter les identifiants (PDF/CSV) » sur cette même page pour éviter la confusion entre les deux exports désormais présents) qui, lui, reste réservé aux apprenants déjà inscrits à UNE formation choisie et journalise chaque mot de passe consulté (§2.6). Respecte les mêmes filtres que l'écran (centre pour un acteur à portée globale, formation si sélectionnée) via `ApprenantController::lignesPourListe()`, factorisé pour les deux formats. Vue PDF `pdf/liste-apprenants.blade.php` (numérotée). Verrouillé par `Tests\Feature\Metier\IdentifiantsExportTest::test_export_liste_includes_all_visible_apprenants_without_password_and_respects_centre_isolation`. - **Correctif du 2026-08-07 — colonne « Statut inscription » du rapport incompréhensible + export PDF sans numéro.** Retour du porteur de projet : la colonne affichait la valeur technique brute (`en_cours`) au lieu d'un libellé, et se confondait avec la colonne « Statut » (statut administratif général de l'apprenant, `apprenant_statuts`) déjà présente juste avant — deux notions de « statut » différentes, l'une pour l'apprenant, l'autre pour l'épisode d'inscription en cours. `StatutInscription` gagne une méthode `label()` (même convention que `RoleStaff::label()`) utilisée par `RapportController::lignesFiltrees()` ; `Staff/Rapports/Index.jsx` renomme la colonne écran ambiguë « Statut » en « Statut inscription » pour cohérence avec le PDF/CSV. Numérotation ajoutée à l'export PDF (`pdf/rapport-apprenants.blade.php`, `$loop->iteration`) — l'écran l'avait déjà via la colonne `#` par défaut de `DataTable` (point ci-dessus), le CSV aussi (déjà fait au même moment), seul le PDF manquait. - Dashboards (3 rôles staff + partenaire) : « Groupes actifs »/« Mes groupes » → « Formations actives »/« Mes formations » (effectif par formation, plus de notion de capacité/horaire/session du jour) ; `Partenaire\DashboardController` : `periodes_en_cours_count` → `formations_actives_count` (formations distinctes à inscription active par centre). - `Inscription::scopeVisibleTo()` simplifié : centre via `whereHas('apprenant', ...)`, formation via `whereIn('formation_id', ...)` direct — plus de traversée `groupe.periode`. `ChecksCentreScope`/`ChecksFormationScope` (Policies) simplifiés en cascade : `resolveCentreId()` perd ses branches `periode`/`groupe`, gagne une branche `apprenant` (pour `Inscription`) ; `resolveFormationId()` se réduit à `$model->formation_id` (tous les modèles concernés le portent désormais directement). - Tests : fichiers entièrement supprimés (`GroupeHoraireTest`, `GroupeShowProgrammeTest`, `CalculerPresenceJournaliereTest`, `RepartitionTest`) ; réécrits en profondeur (`CentreIsolationTest`, `FormationScopeTest`, `ProgressionTest`, `ApprenantScopeTest`, `RapportTest`, `ApprenantShowEtFiltreTest`, `IdentifiantsExportTest`, `InscriptionTest`, `PartenaireDashboardFiltreTest`, `DashboardRedirectTest`) ; nouveaux (`PresenceScreenTest`, présence temps réel dans `ProgressionTest`). - **Correctif de sécurité du 2026-08-07 — page mise en cache par le navigateur donnant l'impression trompeuse que « le même compte reste connecté ».** Signalé par le porteur de projet, capture à l'appui, sur la page d'accueil (`Auth/SelectionRole.jsx`, sélection de rôle) : sur un poste partagé (centre multimédia), après déconnexion, le bouton « Précédent » du navigateur pouvait resservir une page encore authentifiée depuis son cache local (bfcache) — cliquer une tuile de rôle sur cette page redonnait alors accès au compte précédent sans repasser par le formulaire de connexion, comme si "le même compte prenait toujours la main". Ce n'était pas un bug de routing (`/` redirige déjà correctement un utilisateur authentifié vers son tableau de bord, cette redirection n'a pas changé) mais un problème de mise en cache navigateur. Corrigé une fois pour toutes par un nouveau middleware **`App\Http\Middleware\PreventStaleAuthenticatedPages`**, ajouté au groupe `web` global (`bootstrap/app.php`) — donc sur toute l'app (staff, apprenant, pages publiques) — qui force `Cache-Control: no-store, no-cache, must-revalidate` + `Pragma: no-cache` sur chaque réponse ; le navigateur ne peut alors plus mettre une page en cache local, et « Précédent » déclenche toujours une vraie requête serveur qui reflète l'état réel de la session. Vérifié par requête HTTP directe (`curl -I`), pas par un test PHPUnit dédié (comportement de cache navigateur, pas de logique métier). **Au même moment** : le lien « Créer un compte » retiré de `Auth/SelectionRole.jsx` (demande explicite du porteur de projet) — l'auto-inscription staff reste possible via `/register` (lien encore présent sur `Login.jsx`), simplement plus mis en avant sur cette page d'accueil. - **Nouveau (2026-08-07) — raccourci flottant vers l'espace apprenant sur les pages d'authentification staff.** `Layouts/GuestLayout.jsx` (connexion, inscription, mot de passe oublié, etc. — toute page staff non connectée) affiche désormais un bouton rond flottant en bas à droite (icône `IconUserCircle`, déjà présente dans `Components/Icons.jsx`, même style que l'icône fournie par le porteur de projet) menant directement à `route('apprenant.login')` — évite d'obliger un apprenant à repasser par `/` (`Auth/SelectionRole.jsx`) pour trouver son espace. Placé au niveau du layout partagé plutôt que sur `Login.jsx` seul : apparaît sur toutes les pages d'auth staff, coût nul à maintenir. **Devenu redondant, retiré au même moment** : le lien texte « Vous êtes apprenant ? Accéder à l'espace apprenant » qui vivait spécifiquement en bas de `Login.jsx` — le bouton flottant du layout couvre désormais ce besoin partout, pas seulement sur cette page. - **Bug critique corrigé le 2026-08-07 — pourcentage de progression pouvant dépasser 100% (signalé à 200% par le porteur de projet).** Cause : `Chapitre`/`ModuleFormation` utilisent `SoftDeletes` (« pas de suppression physique », historique conservé) — mais soft-supprimer un chapitre/module n'est qu'un `UPDATE` (`deleted_at`), donc la cascade DB `cascadeOnDelete()` posée sur `modules_formation.chapitre_id`/`lecons_du_jour.module_formation_id`/`progression_modules.lecon_du_jour_id` ne se déclenche **jamais** dans ce cas (elle ne réagit qu'à un vrai `DELETE`). Résultat : les lignes `ProgressionModule` (les coches) d'un chapitre/module supprimé restaient physiquement en base et continuaient d'être comptées au numérateur (`$inscription->progressionModules->count()`), alors que le dénominateur (`LeconDuJour::whereHas('moduleFormation.chapitre', ...)`) les excluait déjà correctement grâce au scope automatique d'Eloquent sur les relations soft-deletables — d'où un ratio qui pouvait dépasser 100%. Corrigé par une nouvelle relation **`Inscription::progressionModulesActives()`** (`progressionModules()->whereHas('leconDuJour.moduleFormation.chapitre')`) à utiliser **systématiquement** à la place de `progressionModules()` brute pour tout calcul de progression — remplacée dans les 4 endroits concernés : `Apprenant\DashboardController` (tableau de bord + coche), `Staff\ApprenantController` (`pourcentageProgression()`, `attacherActivite()` — dont la jointure SQL brute de `totalLeconsParFormationCentre` gagne aussi `whereNull('modules_formation.deleted_at')`/`whereNull('chapitres.deleted_at')`, une jointure manuelle ne bénéficiant pas du scope automatique d'Eloquent), `Staff\RapportController`. Verrouillé par `Tests\Feature\Metier\ProgressionTest::test_progression_percentage_never_exceeds_100_after_a_chapitre_is_deleted`. **Règle à retenir** : toute nouvelle requête comptant des `ProgressionModule` doit passer par `progressionModulesActives()`, jamais par `progressionModules()` directement. - **Bug critique corrigé le 2026-08-07 (suite, même cause racine) — 500 sur le tableau de bord formateur/gestionnaire dès qu'une leçon cochée pointait vers un module supprimé.** Conséquence directe du même trou (soft delete ne déclenche pas la cascade DB, voir ci-dessus) : `DashboardController::activiteRecente()` (fil « Activité récente ») accédait à `$pm->leconDuJour->moduleFormation->titre` sans jamais vérifier que `moduleFormation` existait encore — `ErrorException: Tentative de lire la propriété « titre » sur null` dès qu'un chapitre/module contenant une leçon déjà cochée était supprimé (page Whoops complète en capture d'écran, `app\Http\Controllers\Staff\DashboardController.php:171`). Corrigé en deux temps : (1) l'eager load de `moduleFormation` gagne `->withTrashed()` pour continuer à afficher le **vrai** titre historique (« pas de suppression physique », cohérent avec le reste de l'app) plutôt qu'un texte générique ou un crash ; (2) chaînage défensif (`?->`, avec fallback `'Leçon supprimée'`/`'—'`) sur toute la chaîne `leconDuJour→moduleFormation`/`inscription→apprenant`/`inscription→formation` pour ne plus jamais planter, y compris dans l'hypothèse (normalement impossible via l'app, mais pas à exclure) d'une relation totalement introuvable. **Même durcissement appliqué par prévention aux 3 autres endroits qui déréférençaient `moduleFormation->chapitre`/`->formation` sans garde** (le même `ErrorException` aurait pu s'y produire dès qu'une action était tentée sur une donnée dont le chapitre/module a depuis été supprimé) : `Apprenant\ProgressionController::store()` (coche), `Staff\ProgressionController::destroy()` (décoche — route existante mais actuellement sans bouton dans l'UI, gap déjà noté, pas traité ici), `Staff\LeconDuJourController::destroy()` (retirer une leçon planifiée) — les trois lèvent désormais un 404 propre (`abort_if(! $chapitre, 404)`) plutôt que de risquer un 500 si le chapitre/module a disparu entre le chargement de la page et le clic. Verrouillé par `Tests\Feature\DashboardRedirectTest::test_formateur_dashboard_does_not_crash_when_a_recently_checked_lecon_module_was_deleted`. - **Nouveau (2026-08-07) — leçons déjà validées repliées par défaut côté apprenant.** `Apprenant/Dashboard.jsx` (`ChapitreCard`) sépare désormais les modules d'un chapitre en « restants » (affichés directement, y compris les leçons pas encore programmées) et « déjà validés » (repliés sous un bouton « Voir les N leçon(s) déjà validée(s) ») — évite que l'historique s'accumule visuellement au fil du temps (demande du porteur de projet). Purement un changement d'affichage React : le calcul du pourcentage de progression (côté serveur, `progressionModulesActives()` ci-dessus) n'y est pas sensible, aucun test backend à adapter. - **Nouveau (2026-08-07) — modale « Planifier un cours » élargie.** `Components/Modal.jsx` gagne une taille `3xl` (`sm:max-w-3xl`, au-delà du `2xl` qui était jusque-là le maximum disponible) ; `Staff/Formations/Programme.jsx` l'utilise pour la modale de planification (demande du porteur de projet — le formulaire choisi/tapé « leçon » restait à discuter mais le fonctionnement actuel — liste déroulante existante OU bouton « + Nouvelle leçon » séparé — est conservé tel quel, seul l'espace disponible a changé). ### Organisation du code (repères de navigation) - **Refonte design du 2026-08-05, sur inspiration de 3 captures fournies par l'utilisateur** (FlowMail, Nucleus, meetmind.ai) — direction commune retenue : sidebar gauche avec icônes (pas de nav horizontale), cartes arrondies à ombre douce, avatar en cercle (initiales, pas de vraie photo) plutôt qu'un simple nom en texte, boutons pleins sans majuscules ("Se connecter" pas "SE CONNECTER" — l'ancien style venait tel quel du scaffold Breeze par défaut, jamais personnalisé). - `Components/Icons.jsx` : petite bibliothèque d'icônes SVG maison (traits fins, 24×24) — pas de dépendance ajoutée (`@heroicons/react` etc.), juste pour éviter d'alourdir `package.json` pour une douzaine de pictos simples. - `Components/Avatar.jsx` : cercle coloré avec initiales, couleur dérivée d'un hash du nom (pas de vraie photo de profil dans l'app). - `Layouts/AuthenticatedLayout.jsx` : entièrement réécrit en sidebar fixe (desktop, `lg:flex`) + tiroir coulissant avec overlay (mobile, remplace l'ancien dropdown sous le header). Chaque lien de `LIENS_PAR_ROLE` porte désormais une icône (3ᵉ élément du tableau). Bloc utilisateur en bas de sidebar : `Avatar` + nom + libellé de rôle (lien direct vers `Profil`) + bouton déconnexion séparé — **volontairement pas un `Dropdown`** ici : le composant `Dropdown` partagé ouvre toujours vers le bas (`mt-2`), ce qui aurait pu sortir de l'écran pour un déclencheur tout en bas de la sidebar. `NavLink.jsx`/`ResponsiveNavLink.jsx` (scaffold Breeze, plus utilisés après la réécriture) supprimés. - `Layouts/GuestLayout.jsx` : écran scindé (panneau de marque + formulaire), inspiré de Nucleus — **pas de vraie photo** (on ne met pas en scène une personne réelle/fictive sur une plateforme TECHNIDEV). - `Components/{PrimaryButton,SecondaryButton,DangerButton}.jsx` : `bg-gray-800`/majuscules/`tracking-widest` (scaffold Breeze non retouché jusqu'ici) remplacés par des boutons pleins couleur d'accent/texte normal/`rounded-lg` — seul `DangerButton` garde le rouge. `TextInput.jsx` et tous les `