GrowTrack est une plateforme web de suivi des compétences des étudiants. Elle centralise les évaluations (par les professeurs, entre pairs et en auto-évaluation), le signalement de problèmes de comportement ou de performance et leur suivi, la gestion des projets d'équipe et la production de rapports individuels en PDF.
Chaque utilisateur se connecte avec un rôle (administrateur, professeur ou étudiant) et accède à un espace qui lui est propre.
- Contexte et objectifs
- Rôles et permissions
- Fonctionnalités par rôle
- Concepts métier
- Architecture technique
- Structure du dépôt
- Sécurité
- Base de données
- Installation et lancement
- Variables d'environnement
- Référence de l'API
- Tests et intégration continue
- Conventions de code
Dans les établissements d'enseignement, le suivi des compétences est souvent manuel et dispersé : évaluations sur papier ou dans des tableurs, problèmes de comportement signalés oralement et rarement suivis, aucune vision d'ensemble de la progression d'un étudiant.
GrowTrack répond à ces problèmes :
- Évaluer de façon structurée : chaque évaluation porte sur des compétences définies par l'administration, avec des questions et une note de 0 à 5.
- Croiser les points de vue : l'étudiant est évalué par ses professeurs, par ses coéquipiers de projet et par lui-même.
- Signaler et suivre : un problème signalé est examiné par l'administration, qui peut y associer une action de suivi confiée à un coach.
- Mesurer la progression : tableaux de bord et graphiques par compétence, par classe, par projet et dans le temps.
- Produire des rapports : un rapport complet par étudiant, exportable en PDF.
| Rôle | Valeur en base | Espace | Résumé |
|---|---|---|---|
| Administrateur | admin |
/dashboard |
Gère les utilisateurs, les classes, les compétences et traite les signalements. Vision globale de l'établissement. |
| Professeur | Professor / professeur |
/DashboardProf |
Évalue ses étudiants, gère ses projets et équipes, signale des problèmes et consulte les rapports. |
| Étudiant | student / etudiant |
/dashstud |
Consulte sa progression, évalue ses coéquipiers, s'auto-évalue et signale des problèmes. |
| Superviseur | superviseur |
aucun | Tuteur d'entreprise (stages). Fiche gérée par l'administrateur, sans espace de connexion. |
| Coach | coach |
aucun | Accompagne un étudiant après un signalement. Fiche gérée par l'administrateur, sans espace de connexion. |
Le même rôle est parfois écrit différemment en base (Professor, professeur…). Le
backend (src/constants/roles.js) et le frontend (src/stores/auth.js) normalisent toutes
ces variantes.
Règles d'accès appliquées par le serveur :
- Toutes les routes, sauf l'espace public et l'authentification, exigent une session valide.
- Chaque groupe de routes est réservé à un rôle (
authorize("admin"),authorize("Professor"),authorize("student")). - Un étudiant n'accède qu'à ses propres données : l'identifiant présent dans l'URL doit être le sien, sinon la requête est refusée (403).
- Un professeur n'accède qu'à ses propres projets et équipes. Il ne peut ni lire, ni modifier, ni supprimer ceux d'un collègue (404).
| Page | URL | Description |
|---|---|---|
| Accueil | / |
Présentation de la plateforme |
| Étudiants / Professeurs | /Students, /Teachers |
Présentation des bénéfices pour chaque public |
| L'équipe | /OurTeam |
Équipe du projet |
| Contact | /ContactUs |
Formulaire de contact, envoyé par e-mail à l'administration |
| Connexion | /Login |
Connexion avec l'option « se souvenir de moi » |
| Mot de passe oublié | /forgotpass |
Envoi d'un lien de réinitialisation par e-mail (valable 15 min) |
| Réinitialisation | /resetpass?token=… |
Choix d'un nouveau mot de passe |
Après connexion, l'utilisateur est redirigé automatiquement vers l'espace de son rôle.
Une page à laquelle son rôle n'a pas accès le renvoie vers /Error.
Tableau de bord (/dashboard)
- Nombre total d'utilisateurs et d'évaluations, avec l'évolution par rapport au mois précédent.
- Taux d'implication (évaluations réalisées par rapport à l'objectif).
- Évaluations signalées, origine des évaluations dans le temps.
- Répartition des utilisateurs par rôle.
- Fil d'actualités : activité récente des administrateurs et des professeurs.
Gestion des utilisateurs
- Étudiants (
/Student) : création avec photo, modification, suppression, recherche par CIN, filtres par classe et par filière, statistiques. - Professeurs (
/Professor) : mêmes opérations, avec filtres par classe et par filière. - Superviseurs (
/Supervisor) : tuteurs d'entreprise, avec filtres par poste et par entreprise. - Coachs (
/Coach) : création, modification, suppression et recherche.
Structure pédagogique
- Filières et classes (
/Group) : création, modification, suppression, statistiques par classe. - Compétences (
/Skills) : création des compétences évaluées. Chacune a une description et trois questions posées lors de l'évaluation. Statistiques d'utilisation dans les évaluations et les signalements.
Évaluations et signalements
- Vue globale (
/GlobalOverview) : liste de toutes les évaluations, recherche par identifiant, filtre par type (professeur, pair, auto-évaluation, superviseur). - Signalements (
/Signals) : examen de chaque signalement, puis l'une de ces actions :- proposer une solution : action de suivi confiée à un coach, avec dates de début et de fin. Le signalement est approuvé et l'étudiant concerné est notifié ;
- envoyer une alerte à l'étudiant concerné ;
- rejeter le signalement.
Autres
- Calendrier (
/Calendar) : planning des événements. - Profil (
/UserProfile) : informations personnelles de l'administrateur.
Tableau de bord (/DashboardProf)
- Nombre de classes et d'étudiants suivis, total des évaluations réalisées.
- Classement des meilleurs étudiants par classe.
- Évaluations quotidiennes et évaluations signalées par mois.
Évaluation en classe (/ClassesEval)
- Navigation par filière, puis classe, puis étudiant.
- Recherche d'un étudiant par CNE, filtre selon que l'étudiant a déjà été évalué ou non.
- Nouvelle évaluation : choix des compétences, réponse aux trois questions de chacune (note de 0 à 5) et commentaire.
- Consultation du rapport de l'étudiant.
Historique des évaluations (/HistoriqueEval)
- Toutes les évaluations réalisées par le professeur.
- Filtres par filière, classe et type, recherche par identifiant, détail d'une évaluation.
Gestion des projets (/ProjectMang, /ProjectDetails)
- Création d'un projet : nom, description, classe, filière, mois de début et durée.
- Modification des dates, suppression.
- Création et suppression d'équipes dans un projet.
- Ajout de membres à une équipe par leur CNE, liste des membres avec leur dernière évaluation.
Signalements (/ClassesSignal, /HistoriqueSignal)
- Signalement d'un étudiant : titre, description, catégorie, option d'anonymat.
- Historique des signalements émis, filtrable par état (nouveau ou approuvé) et par état de la solution (en attente, résolu, bloqué, rejeté).
- Consultation de la solution décidée par l'administration.
Rapports (/Rapport)
- Rapport complet d'un étudiant : profil, évaluations par compétence, historique des signalements et commentaires.
- Export PDF généré côté serveur.
Notifications (/Notification).
Tableau de bord (/dashstud)
- Nombre de projets, de signalements reçus et d'évaluations soumises et attendues.
- Moyenne de l'étudiant dans sa classe.
- Graphiques radar des compétences, par classe et par projet.
- Évaluations reçues par type d'évaluateur et par mois.
- Évolution de la note d'une compétence choisie, mois par mois.
Mes évaluations (/StudEvals)
- Toutes les évaluations reçues : évaluateur, cours, projet et date.
- Recherche par nom de l'évaluateur, par cours ou par projet.
Mes projets (/StudProject)
- Liste des projets et membres de chaque équipe.
- Évaluation par les pairs : chaque coéquipier est noté sur les compétences, avec un message.
- Signalement d'un coéquipier.
Auto-évaluation (/selfEval)
- Six compétences, trois questions chacune, notes de 0 à 5 et commentaire de synthèse.
- Le serveur vérifie toutes les notes avant d'enregistrer l'évaluation.
Mes signalements (/StudSignals)
- Signalements émis par l'étudiant et leur avancement, avec recherche par identifiant, nom ou catégorie et filtres par état.
Rapports (/StudRapport) et notifications (/StudNotif) : décisions prises sur
les signalements, alertes et messages de l'administration.
Définies par l'administrateur (competence). Chaque compétence a un nom unique, une
description et trois questions. Une évaluation attribue une note de 0 à 5 à chaque question ;
la note de la compétence est la moyenne des trois.
Une évaluation (skill_evaluation) est faite par un évaluateur sur un étudiant. Le détail des
notes par compétence est stocké dans evaluations.
| Type | Évaluateur |
|---|---|
Professor |
un professeur |
Pair |
un coéquipier de projet |
Self |
l'étudiant lui-même |
Supervisor |
le tuteur d'entreprise |
Contexte de l'évaluation : class (en cours), project (dans une équipe) ou internship (en stage).
Cycle de vie d'un signalement (signal) :
Professeur ou étudiant Administrateur Suivi
────────────────────── ────────────── ─────
crée un signalement ──► examine ──► propose une solution ──► coach assigné (follow_up)
(état : new) │ (approved = true) étudiant notifié
├─► envoie une alerte ───────► étudiant notifié
└─► rejette le signalement
État de la solution : pending, resolved, blocked ou rejected.
Un professeur crée un projet (projet) pour une classe, y crée des équipes (team) et y
ajoute des étudiants (team_student). Les membres d'une équipe s'évaluent entre eux.
notifications: messages personnels envoyés à un utilisateur (décisions sur les signalements, alertes).news: fil d'activité du tableau de bord administrateur (projets créés, signalements émis…).
┌──────────────────────┐ HTTPS + cookies ┌──────────────────────┐ SQL ┌──────────────┐
│ Frontend (Vue 3) │ ───────────────────► │ Backend (Express 5) │ ───────► │ PostgreSQL │
│ Vite, Pinia, Router │ ◄─────────────────── │ API REST │ ◄─────── │ (local/Neon) │
└──────────────────────┘ JSON └──────────┬───────────┘ └──────────────┘
│
Nodemailer (Gmail) · Puppeteer (PDF)
| Couche | Technologies |
|---|---|
| Frontend | Vue 3.5, Vite, Vue Router 4, Pinia 3, Tailwind CSS 4, Axios |
| Graphiques et interface | ApexCharts, Chart.js, FullCalendar, GSAP, Heroicons |
| Formulaires | Yup (validation côté client) |
| Backend | Node.js, Express 5, pg (PostgreSQL) |
| Sécurité | jsonwebtoken, bcrypt, csrf-csrf, helmet, express-rate-limit, express-validator |
| Services | Nodemailer (e-mails), Puppeteer + EJS (PDF), Multer (photos) |
| Tests | Jest + Supertest (backend), Vitest + Vue Test Utils (frontend), Cypress (bout en bout) |
| Déploiement | Docker, Docker Compose, GitHub Actions, Docker Hub |
Le backend suit une organisation en couches : une route déclare l'URL et les contrôles d'accès, un contrôleur lit la requête et formate la réponse, un modèle exécute les requêtes SQL. Toutes les requêtes SQL sont paramétrées.
Growtrack/
├── backend/
│ ├── server.js point d'entrée (démarre le serveur HTTP)
│ ├── src/
│ │ ├── app.js configuration Express et montage des routes
│ │ ├── config/ pool PostgreSQL, CORS, cookies, CSRF, e-mail, variables d'env.
│ │ ├── constants/ rôles et normalisation de leurs variantes
│ │ ├── routes/
│ │ │ ├── admin/ dashboard, students, professors, supervisors, coaches,
│ │ │ │ classes, skills, signals, profile, globalOverview
│ │ │ ├── professor/ dashboard, classEvaluation, evaluationHistory, project,
│ │ │ │ classSignal, signalHistory, studentReport
│ │ │ ├── student/ dashboard, project, notification, signalHistory,
│ │ │ │ evaluationHistory, selfEvaluation
│ │ │ ├── authRoutes.js
│ │ │ └── contactRoutes.js
│ │ ├── controllers/ même découpage que routes/
│ │ ├── models/ même découpage que routes/ (requêtes SQL)
│ │ ├── middlewares/
│ │ │ ├── authenticate.js vérifie le jeton JWT (cookie ou en-tête)
│ │ │ ├── authorize.js vérifie le rôle
│ │ │ ├── verifyOwnership.js l'ID de l'URL doit être celui de l'utilisateur
│ │ │ ├── professorOwnership.js le projet ou l'équipe doit appartenir au professeur
│ │ │ ├── upload.js envoi de photos (images uniquement, 2 Mo maximum)
│ │ │ ├── rateLimiter.js limitation du nombre de requêtes
│ │ │ ├── validate.js exécute les règles express-validator
│ │ │ └── errorHandler.js gestion centralisée des erreurs
│ │ ├── validators/ règles de validation des entrées
│ │ ├── utils/ hachage des mots de passe, jetons, AppError
│ │ └── templates/ modèle EJS du rapport PDF
│ ├── database/
│ │ ├── schema.sql schéma complet de la base
│ │ ├── migrations/ scripts de migration
│ │ └── seeds/ jeux de données (SQL et scripts Node)
│ ├── scripts/sync-db.js copie la base distante en local (avant les tests)
│ ├── __tests__/
│ │ ├── unit/ même découpage que src/ (controllers, models, middlewares, validators)
│ │ └── integration/ tests HTTP de bout en bout de l'API
│ ├── Dockerfile
│ └── .env.example
│
├── frontend/
│ ├── src/
│ │ ├── main.js point d'entrée Vue
│ │ ├── App.vue
│ │ ├── features/ une section par rôle
│ │ │ ├── admin/ pages/ + components/ (modales, graphiques, profil)
│ │ │ ├── professor/ pages/ + components/ (évaluation, projets, graphiques)
│ │ │ ├── student/ pages/ + components/ (auto-évaluation, graphiques)
│ │ │ ├── auth/pages/ connexion, mot de passe oublié, réinitialisation
│ │ │ └── public/pages/ accueil, équipe, contact, erreur
│ │ ├── components/ composants partagés
│ │ │ ├── layout/ mises en page par rôle, barres latérales, en-têtes
│ │ │ ├── ui/ boutons, tableaux, modales, pagination…
│ │ │ └── icons/
│ │ ├── router/ routes par rôle et garde de navigation
│ │ ├── stores/ stores Pinia (auth, formulaires, étudiants)
│ │ ├── services/api.js client Axios (cookies, CSRF, renouvellement de session)
│ │ ├── composables/ logique réutilisable (pagination, export, toasts…)
│ │ ├── schemas/ schémas de validation Yup
│ │ └── assets/ images et CSS
│ ├── __tests__/ même découpage que src/ (features, components, stores)
│ ├── cypress/e2e/ scénarios de bout en bout
│ └── Dockerfile
│
├── .github/workflows/ci.yml tests, puis construction et publication des images Docker
├── docker-compose.yml environnement de développement
├── docker-compose.prod.yml déploiement à partir des images publiées
└── package.json lance frontend et backend ensemble (`npm run dev`)
| Mesure | Mise en œuvre |
|---|---|
| Mots de passe | Hachés avec bcrypt (10 tours) |
| Session | Jeton d'accès JWT (15 min) et jeton de rafraîchissement (7 j) stockés dans des cookies httpOnly, inaccessibles au JavaScript de la page |
| Renouvellement | Quand le jeton d'accès expire, le client appelle /api/auth/refresh automatiquement puis rejoue la requête |
| CSRF | Protection « double submit » (csrf-csrf) sur toutes les requêtes POST, PUT, PATCH et DELETE |
| Contrôle d'accès | Vérification du rôle sur chaque groupe de routes, plus un contrôle de propriété des données (étudiant, professeur) |
| Comptes désactivés | Un compte inactif ou suspendu ne peut ni se connecter ni renouveler sa session |
| Réinitialisation | Lien signé par un secret dédié (RESET_SECRET) et valable 15 minutes |
| Limitation de débit | 20 tentatives de connexion par 30 min, 500 requêtes par heure et par IP, 20 PDF par 15 min |
| Fichiers envoyés | Images uniquement (JPEG, PNG, WebP, GIF), 2 Mo maximum, renommées aléatoirement |
| En-têtes HTTP | helmet |
| SQL | Requêtes paramétrées uniquement |
| Secrets | Fichier .env local (jamais versionné) et secrets GitHub Actions en CI |
PostgreSQL. Le schéma complet est dans backend/database/schema.sql.
| Table | Rôle |
|---|---|
utilisateur |
Tous les comptes : identité, e-mail, mot de passe haché, rôle (my_role), statut |
admin, etudiant, professeur, superviseur, coach |
Données spécifiques à chaque rôle |
sector, class |
Filières et classes |
enseigne |
Affectation des professeurs aux classes |
competence |
Compétences évaluées et leurs trois questions |
skill_evaluation |
En-tête d'une évaluation (type, contexte, évaluateur, étudiant, note globale) |
evaluations |
Note par compétence pour chaque évaluation |
projet, team, team_student |
Projets, équipes et membres |
stage, supervise |
Stages et tutorat en entreprise |
signal, solution, follow_up |
Signalements, solutions décidées et suivi par un coach |
notifications, news |
Notifications personnelles et fil d'activité |
- Node.js 18 ou plus récent
- PostgreSQL 14 ou plus récent (ou une base distante, par exemple Neon)
- Un compte Gmail avec un mot de passe d'application pour l'envoi des e-mails
# 1. Créer la base et le schéma
psql -U postgres -c "CREATE DATABASE GrowTrack;"
psql -U postgres -d GrowTrack -f backend/database/schema.sql
# 2. Configurer le backend
cp backend/.env.example backend/.env
# puis renseigner les valeurs (voir section 10)
# 3. Installer les dépendances
npm install
npm install --prefix backend
npm install --prefix frontend
# 4. Lancer frontend et backend ensemble
npm run dev- Frontend : http://localhost:5173
- API : http://localhost:3000 (santé :
GET /health)
Le schéma crée un compte administrateur admin@growtrack.com. Définissez son mot de passe
avec « Mot de passe oublié » sur la page de connexion.
Pour lancer les applications séparément : npm run dev dans backend/ (nodemon) et dans
frontend/ (Vite).
docker compose up --build # développement
docker compose -f docker-compose.prod.yml up -d # à partir des images publiéesFichier backend/.env (modèle : backend/.env.example) :
| Variable | Obligatoire | Description |
|---|---|---|
NODE_ENV |
oui | development ou production (cookies secure en production) |
PORT |
oui | Port de l'API (3000 par défaut) |
ACCESS_SECRET |
oui | Secret de signature des jetons d'accès |
REFRESH_SECRET |
oui | Secret de signature des jetons de rafraîchissement |
RESET_SECRET |
oui | Secret de signature des liens de réinitialisation |
CSRF_SECRET |
non | Secret CSRF (par défaut : ACCESS_SECRET) |
MODE |
oui | local (variables DB_*) ou cloud (DATABASE_URL) |
DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME |
si MODE=local |
Connexion PostgreSQL locale |
DATABASE_URL |
si MODE=cloud |
Chaîne de connexion complète |
EMAIL_USER, EMAIL_PASS |
oui | Compte Gmail et mot de passe d'application |
FRONTEND_URL |
oui | URL du frontend, utilisée dans les liens envoyés par e-mail |
Générez les secrets avec, par exemple :
node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"
Toutes les routes, sauf mention contraire, exigent une session valide et le rôle indiqué.
| Préfixe | Rôle | Contenu |
|---|---|---|
GET /api/csrf-token |
public | Jeton CSRF à envoyer dans l'en-tête x-csrf-token |
/api/auth |
public | login, logout, refresh, reset-password, check |
/api/validate-reset-token, /api/resetpass |
lien e-mail | Réinitialisation du mot de passe |
/api/contactus |
public | Formulaire de contact |
/api/DashAdmin |
admin | Indicateurs du tableau de bord |
/api/GlobalOverView |
admin | Vue globale des évaluations |
/admin/students, /admin/professors, /admin/supervisors, /admin/coachs |
admin | Gestion des utilisateurs |
/admin/class, /admin/skills |
admin | Classes, filières et compétences |
/admin/signals |
admin | Traitement des signalements |
/admin/profile |
admin | Profil administrateur |
/prof/dashboard |
professeur | Indicateurs du tableau de bord |
/api/prof_evaluation_classes |
professeur | Évaluation en classe |
/api/prof_evaluation_history |
professeur | Historique des évaluations |
/api/prof_project_management |
professeur | Projets, équipes et membres |
/api/signal_classes, /api/signal_history |
professeur | Signalements |
/api/report |
professeur | Rapport d'un étudiant |
POST /api/generate-pdf |
professeur | Génération du rapport PDF |
/student/dashboard, /student/projects, /student/notifications |
étudiant | Tableau de bord, projets, notifications |
/api/student_evaluation_history |
étudiant | Évaluations reçues |
/api/student_signal_history |
étudiant | Signalements émis |
/api/student_evaluation_byself |
étudiant | Auto-évaluation |
GET /health |
public | État du serveur |
Codes de réponse : 401 (pas de session ou session expirée), 403 (rôle insuffisant,
données d'un autre utilisateur ou jeton CSRF manquant), 404 (ressource inexistante ou
appartenant à un autre professeur), 400 (entrée invalide).
# Backend
cd backend
npm run test:unit # tests unitaires (base de données simulée)
npm run test:integration # tests d'intégration (base de données requise)
# Frontend
cd frontend
npx vitest run # tests unitaires des composants et des stores
npm run test:e2e # Cypress (nécessite frontend et backend démarrés)npm test dans backend/ exécute d'abord scripts/sync-db.js, qui copie la base désignée
par DATABASE_URL dans une base PostgreSQL locale.
Intégration continue (.github/workflows/ci.yml), sur la branche dev :
- installation et tests unitaires du backend et du frontend ;
- si tous les tests passent et qu'il s'agit d'un push : construction et publication des images Docker du backend et du frontend sur Docker Hub.
Secrets à définir dans GitHub (Settings → Secrets and variables → Actions) : ACCESS_SECRET,
REFRESH_SECRET, RESET_SECRET, EMAIL_USER, EMAIL_PASS, DATABASE_URL,
DOCKERHUB_USERNAME, DOCKERHUB_TOKEN.
Backend
- Un fichier par ressource et par rôle :
src/{routes,controllers,models}/<rôle>/<ressource>{Routes,Controller,Model}.js. - Contrôles d'accès déclarés dans les routes :
authenticate, puisauthorize("<rôle>"), puis les contrôles de propriété. - SQL uniquement dans les modèles, toujours avec des paramètres (
$1,$2…). - Les tests reprennent la structure de
src/:__tests__/unit/<couche>/<rôle>/<fichier>.test.js.
Frontend
- Une page par route dans
features/<rôle>/pages/(suffixePage.vue). - Un composant utilisé par un seul rôle va dans
features/<rôle>/components/. Un composant partagé va danscomponents/. - Composants nommés en PascalCase. Appels HTTP via
services/api.jsuniquement, qui gère les cookies, le CSRF et le renouvellement de session. - Formatage : ESLint et Prettier (
npm run lint,npm run format).