Cas client · Éducation — vacations enseignantes
Écoles Internationales Maarif
Passer d'une fiche papier recopiée à la main chaque mois à un état de vacation produit, visé et verrouillé dans l'application.
6
sections gérées en parallèle
10
rôles utilisateurs
17
droits configurables rôle par rôle
2FA
double authentification des comptes
Le contexte
D'où l'on est parti
Les heures de vacation des enseignants étaient relevées sur une fiche physique : une ligne par séance, avec la date, la classe, l'heure d'arrivée, l'heure de départ, le nombre d'heures, le retard éventuel et le visa de l'administration.
Ces fiches étaient ensuite recopiées à la main dans un tableau mensuel par section, puis additionnées pour établir la paie. Sur six sections et plusieurs centaines de lignes, le circuit produisait trois problèmes récurrents : des erreurs de recopie et d'addition, l'absence de trace de qui avait modifié quoi, et un délai entre la fin du mois et l'état de paie définitif.
Avant et après
Ce qui a changé, point par point
La situation de départ
- Des centaines de lignes recopiées chaque mois, d'une fiche papier vers un tableau par section.
- Des erreurs d'addition qui ne se découvraient qu'au moment de la paie.
- Aucune trace de l'auteur d'une correction, ni de sa justification.
- Un état de paie définitif produit plusieurs jours après la fin du mois.
Ce qui a été mis en place
- L'enseignant saisit lui-même ses séances, avec exactement les colonnes de la fiche papier et la même règle de retard.
- Le directeur des études vise, corrige avec justification obligatoire, ou rejette — et une séance visée n'est plus modifiable par l'enseignant.
- La grille mensuelle s'agrège à partir des seules séances visées : plus aucune recopie entre la séance et l'état.
- Le comptable contrôle chaque section, la renvoie pour correction ou verrouille la période — un verrouillage que l'API elle-même fait respecter.
- L'état de vacation part en Excel et les bulletins en PDF, les coordonnées bancaires n'étant visibles que des rôles autorisés.
La mise en œuvre
Comment cela s'est passé
- 01
Reprise de la structure de la fiche
L'application reprend exactement les colonnes et le découpage par semaine de la fiche physique. C'est un choix délibéré : l'enseignant saisit comme il remplissait, et n'a rien à réapprendre.
- 02
Deux modes d'hébergement
Un serveur Ubuntu accessible depuis Internet, ou un poste Windows dédié dans l'établissement servant les autres postes du réseau local — l'application s'installe aussi sur les postes clients comme une application.
- 03
Sauvegardes et exploitation
Sauvegarde automatique de la base chaque nuit, conservée trente jours, avec une copie hebdomadaire préservée de la rotation et un journal d'exécution consultable.
- 04
Sécurité des comptes
Double authentification par code à six chiffres, session limitée à huit heures, et journal d'audit des opérations sensibles.
Socle technique
Ce qui fait tourner l'installation
L'établissement reste propriétaire de son code, de ses données et de ses accès.
- Application
- Next.js 14 sur Node 20
- Base de données
- PostgreSQL
- Supervision du service
- PM2
- Serveur web et HTTPS
- Nginx et Let's Encrypt