# TECHNIFORM — Cahier des charges ## Plateforme de gestion multi-centres de formation ### TECHNIDEV et ses partenaires — Version 1.2 --- ## 1. Contexte et objectifs TECHNIDEV souhaite doter ses différents centres de formation, nouvellement installés dans plusieurs villes (dont Goz Beida), d'une plateforme web centralisée de gestion et de suivi. Le projet doit être livré dans un délai très court. Chaque centre de formation gère son fonctionnement quotidien (formateurs, apprenants, sessions) de manière autonome, tout en restant supervisé par une administration centrale et suivi à distance, en temps quasi réel, par les partenaires de TECHNIDEV. ### 1.1 Objectifs du projet - Permettre à chaque centre d'inscrire ses apprenants et de les rattacher à la formation de leur choix. - Organiser les apprenants d'une formation en **groupes**, chacun avec son propre créneau horaire et ses jours de la semaine. - Suivre la progression individuelle de chaque apprenant tout au long de sa formation. - Générer des rapports listant les apprenants, catégorisés par formation, groupe et statut, à l'issue de chaque session. - Offrir aux partenaires TECHNIDEV un tableau de bord de suivi multi-centres : statut d'activité des centres et avancement des sessions de formation. ### 1.2 Stack technique | Composant | Technologie | |---|---| | Backend | Laravel | | Frontend | React | | Liaison front / back | Inertia.js | | Design / UI | Tailwind CSS | | Base de données | MySQL | --- ## 2. Périmètre fonctionnel ### 2.1 Modules de l'application | # | Module | Description | |---|---|---| | 1 | Authentification & Rôles | Connexion, gestion des droits par rôle | | 2 | Centres | CRUD centre : nom, ville, statut actif/inactif | | 3 | Utilisateurs | Admin crée les responsables ; responsables créent les formateurs | | 4 | Formations | Catalogue global des formations, géré par l'admin | | 5 | Vagues / Sessions | Planification d'une formation dans un centre, dates début/fin | | 6 | **Groupes** | Sous-ensemble d'apprenants au sein d'une vague, avec son propre créneau horaire et ses jours | | 7 | Apprenants | Fiche apprenant, rattachement à un centre — **géré par le formateur, pas de compte propre** | | 8 | Inscriptions & Progression | Rattachement apprenant ↔ vague ↔ groupe, suivi (%) ou jalons validés | | 9 | Rapports | Génération et export PDF, filtrage par formation / centre / vague / groupe | | 10 | Dashboard partenaire | Vue de suivi multi-centres, actualisée par rafraîchissement | ### 2.2 Catalogue de formations (référence) Sur la base des données réelles du centre de Goz Beida, le catalogue démarre avec 3 formations : | Formation | Particularités observées | |---|---| | **SOUTIEN SCOLAIRE INTEGRE (SSI)** | Organisée en plusieurs groupes (ex : Groupe A, Groupe B), chacun avec un créneau horaire de 2 à 3h et des jours fixes propres (ex : Lundi/Mercredi pour un groupe, Mardi/Jeudi pour un autre) — *reformulé, à confirmer.* | | **INFORMATIQUE** | Apprenants suivis avec statut et, selon le centre, niveau et créneau. | | **ALPHABETISATION** | Liste plus simple : nom, sexe, statut. | Le catalogue reste **extensible par l'admin** — ces 3 formations sont le point de départ, pas une limite figée en dur dans le code. ### 2.3 Fonctionnement pédagogique - **L'apprenant n'a pas de compte utilisateur dans l'application.** Il est entièrement géré par le formateur : le formateur crée sa fiche, l'inscrit à une formation, l'affecte à un groupe et met à jour sa progression. L'apprenant ne se connecte jamais à la plateforme. - Un apprenant suit une seule formation à la fois. - Les formations se déroulent par **vagues** (sessions successives), et non en continu. - **Au sein d'une vague, les apprenants sont répartis en groupes** (ex : Groupe A, Groupe B...). Chaque groupe a son propre créneau horaire (ex : 8h-10h) et ses jours de la semaine (ex : Lundi et Mercredi). C'est ce découpage qui permet à un même formateur/centre de gérer plusieurs cohortes en parallèle sur une même formation. - La progression d'un apprenant est mesurée par un pourcentage manuel ou par des jalons/étapes validés par le formateur. - L'historique des inscriptions est conservé (aucune suppression), y compris après la fin d'une formation, afin d'alimenter les rapports et l'historique par apprenant. ### 2.4 Informations suivies sur l'apprenant D'après les données réelles observées, la fiche apprenant doit couvrir, en plus des champs déjà prévus : - Sexe - Statut : Réfugié / Autochtone (local) — champ à valeur contrôlée, extensible - Classe / niveau scolaire (pertinent notamment pour la formation SSI) - École d'origine (le cas échéant) - Âge (champ souvent non renseigné dans les données existantes → à garder optionnel) --- ## 3. Rôles et permissions La hiérarchie applicative est la suivante : **Admin → Responsable de centre → Formateur**, avec un rôle **Partenaire** en lecture transversale. L'**apprenant n'est pas un rôle applicatif** — c'est une donnée gérée par le formateur, sans accès ni compte. | Rôle | Portée | Actions principales | |---|---|---| | **Admin (TECHNIDEV)** | Globale, tous les centres | Crée / désactive les centres, crée les responsables de centre, gère les comptes partenaires, gère le catalogue de formations, vue d'ensemble | | **Responsable de centre** | Son centre uniquement | Gère les formateurs de son centre, planifie les vagues et les groupes de son centre | | **Formateur** | Ses apprenants | Crée/gère les fiches apprenants, les inscrit, les affecte à un groupe, met à jour la progression, génère les rapports de ses vagues | | **Partenaire** | Lecture globale, tous centres | Consulte le tableau de bord de suivi : statut des centres, avancement des vagues et des groupes | | *(Apprenant)* | — | *Pas de rôle applicatif — géré uniquement en tant que donnée par le formateur* | **Point de sécurité critique** : chaque ressource sensible (vagues, groupes, apprenants, inscriptions, utilisateurs) doit être filtrée par centre au niveau applicatif (policies et scope systématiques). Un responsable ou un formateur ne doit jamais pouvoir accéder à une ressource d'un autre centre, y compris en modifiant un identifiant dans l'URL. Cette règle doit être posée dès le début du développement, et non ajoutée a posteriori. --- ## 4. Modèle de données Schéma relationnel proposé pour les migrations Laravel / base MySQL : ``` centres id, nom, ville, statut (actif/inactif), derniere_activite_at, timestamps users id, nom, email, password, role, centre_id (nullable), timestamps -- rôles : admin | responsable | formateur | partenaire (PAS d'apprenant ici) formations id, titre, categorie, description, duree_heures, certification, timestamps -- catalogue de départ : SOUTIEN SCOLAIRE INTEGRE, INFORMATIQUE, ALPHABETISATION vagues id, formation_id (FK), centre_id (FK), date_debut, date_fin, statut (planifiee/en_cours/terminee/annulee), capacite_max, timestamps groupes id, vague_id (FK), nom (ex: "Groupe A"), horaire_debut, horaire_fin, jours (ex: ["lundi","mercredi"] — stocké en JSON), capacite_max, timestamps apprenants id, nom_prenom, sexe, statut (refugie/autochtone/local), classe_niveau (nullable), ecole_origine (nullable), age (nullable), centre_id (FK), timestamps -- table de données uniquement : pas de password, pas de compte de connexion inscriptions id, apprenant_id (FK), vague_id (FK), groupe_id (FK, nullable), formateur_id (FK users), progression (0-100), statut (en_cours/termine/abandonne/echec), updated_by (FK users), timestamps ``` - **Ajout de la table `groupes`** : reflète l'usage réel observé (ex. Groupe A 8h-10h Lundi/Mercredi, Groupe B 8h-10h Mardi/Jeudi). Un groupe appartient à une vague ; une inscription peut référencer un groupe. - **Table `apprenants` distincte de `users`** : confirme que l'apprenant n'est qu'une fiche de données, sans identifiants de connexion ni rôle. - Historisation : les enregistrements ne sont pas supprimés physiquement, afin de préserver l'historique utilisé par les rapports. - Contraintes de cohérence : la date de fin d'une vague doit être postérieure à sa date de début ; la progression d'une inscription est bornée entre 0 et 100. - Le champ `statut` de l'apprenant (réfugié / autochtone / local) est une donnée sensible mais nécessaire au reporting TECHNIDEV/partenaires (statistiques par statut, déjà utilisées dans les fichiers existants) — à traiter avec les bonnes pratiques de confidentialité (accès restreint aux rôles autorisés). --- ## 5. Points de décision structurants | # | Question | Décision proposée | |---|---|---| | 1 | Catalogue de formations | Catalogue commun et global, géré par l'admin, initialisé avec SSI / Informatique / Alphabétisation. Chaque centre programme des vagues sur ce catalogue. | | 2 | Statut de responsable de centre | Rôle distinct dans le système, et non un formateur avec des droits élargis. | | 3 | Portée de l'accès partenaire | Accès en lecture globale à tous les centres, sans filtrage par centre. | | 4 | Format d'export des rapports | Export PDF pour la première version. Export Excel envisageable dans une version ultérieure. | | 5 | Critère de centre actif | Statut activé/désactivé manuellement par l'admin, complété par un indicateur de dernière activité mis à jour automatiquement. | | 6 | Nature du suivi temps réel | Rafraîchissement à la visite / actualisation périodique du tableau de bord partenaire, sans WebSockets dans cette version. | | 7 | Structure des groupes | Un groupe est propre à une vague (pas de groupe partagé entre vagues). Ses jours et son créneau horaire sont saisis librement par le formateur/responsable, sans contrainte figée en dur dans le code. | --- ## 6. Plan de mise en œuvre | Phase | Contenu | |---|---| | **1. Fondations** | Installation Laravel + Inertia + React + Tailwind, migrations, jeux de données de démonstration, mise en place des rôles et des permissions de base. | | **2. Modules cœur** | Centres, Utilisateurs (admin → responsable → formateur), Formations, Vagues, Groupes — avec les règles de sécurité par centre posées dès cette phase. | | **3. Modules métier** | Apprenants (fiches gérées par le formateur, sans compte), Inscriptions (apprenant ↔ vague ↔ groupe) et suivi de la progression, génération des rapports (PDF). | | **4. Dashboard partenaire** | Vue de suivi multi-centres, actualisation périodique, statut d'activité automatique des centres. | | **5. Finition** | Tests d'accès par rôle (isolation stricte entre centres), ajustements d'interface, jeu de données final pour la recette (à partir des données réelles type Goz Beida). | *Remarque : l'établissement d'un planning jour par jour nécessite de connaître la durée totale allouée au projet, à préciser pour caler les phases ci-dessus sur un calendrier concret.* --- ## 7. Recommandations complémentaires - Utiliser un package de gestion des rôles et permissions (`spatie/laravel-permission`) plutôt que de coder ce mécanisme manuellement. - Prévoir des notifications ou alertes lorsqu'un centre est inactif depuis plusieurs jours, ou qu'une vague accuse du retard. - Clarifier si plusieurs formateurs peuvent co-animer un même groupe/vague, ce qui impacterait la table des inscriptions. - Prévoir un import initial des données existantes (type fichiers Excel par centre) vers les tables `apprenants` / `inscriptions`. - Préparer des jeux de données de démonstration (seeders) réalistes, en s'inspirant de la structure du fichier Goz Beida. --- ## 8. Vérification et recette - Recette fonctionnelle manuelle pour chaque rôle (admin, responsable, formateur, partenaire) à l'aide des données de démonstration. - Tests ciblés sur l'isolation des données par centre : vérifier qu'un responsable ou un formateur d'un centre ne peut ni lire ni modifier une ressource appartenant à un autre centre, y compris par accès direct à un identifiant. - Vérification des contraintes de données : cohérence des dates de vague, progression bornée entre 0 et 100, cohérence groupe ↔ vague. - Vérifier explicitement qu'aucune route de connexion/inscription n'existe pour un "apprenant" — seuls admin, responsable, formateur et partenaire disposent d'un compte.