SchoolManager Pro

partie utlisateur
tableau de bord
logo de l'etablissement

SchoolManager Pro SchoolManager Pro — Inspiration, apprentissages, construction et défis

Inspiration

De nombreux établissements scolaires en Afrique (et à Yaoundé en particulier) gèrent encore notes, inscriptions et paiements sur papier ou via des tableurs Excel dispersés. L'idée de SchoolManager Pro est née du besoin concret de proposer aux petites écoles et lycées une solution de gestion scolaire complète, mais surtout gratuite à déployer et à faire tourner, sans serveur dédié coûteux ni licence logicielle. Le choix de Render.com comme cible de déploiement vient directement de cette contrainte : offrir à une école un système professionnel sans frais d'infrastructure.

Ce que j'ai appris

La migration d'une base SQLite vers PostgreSQL : passer d'un accès synchrone (better-sqlite3) à un modèle asynchrone avec pg et des requêtes async/await, adapter la syntaxe SQL (placeholders $1, $2, SERIAL PRIMARY KEY, ON CONFLICT DO NOTHING, STRING_AGG, to_char()...).
La gestion de l'authentification par JWT avec expiration et middleware de contrôle des rôles (admin, intendant, enseignant), pour sécuriser chaque route sensible.
Les bonnes pratiques de sécurité en production : hachage bcrypt, rate limiting sur le login, SSL PostgreSQL automatique, validation stricte des types de fichiers uploadés.
Les contraintes réelles d'un déploiement gratuit (mise en veille après inactivité, stockage éphémère) et comment les anticiper dans l'architecture, par exemple en documentant clairement que les uploads doivent migrer vers un service externe (Cloudinary/S3) pour la production.

Comment j'ai construit le projet

Le projet repose sur une stack simple et robuste : Node.js + Express côté serveur, PostgreSQL comme base de données, et du JavaScript vanilla côté client pour rester léger et facile à maintenir. L'architecture sépare clairement les responsabilités : db/database.js centralise le pool de connexions et le schéma, routes/auth.js et auth.middleware.js gèrent l'authentification, routes/api.js regroupe la logique métier. Un fichier render.yaml automatise la configuration du déploiement, pour qu'une personne non technique puisse mettre le projet en ligne en connectant simplement son dépôt GitHub et en renseignant trois variables (email admin, mot de passe, nom de l'école).

Défis rencontrés

Réécrire l'intégralité de la couche d'accès aux données pour passer d'un modèle synchrone à asynchrone sans casser la logique métier existante.
Garantir que l'initialisation automatique de la base (création des tables + données de démonstration) fonctionne de façon fiable au premier démarrage sur Render, sans intervention manuelle.
Trouver le bon équilibre entre simplicité de déploiement (plan gratuit) et sécurité réelle (JWT, bcrypt, rate limiting), pour qu'un projet "gratuit" reste utilisable en conditions réelles.
Documenter clairement les limites du plan gratuit (mise en veille, stockage des uploads non persistant) pour éviter les mauvaises surprises aux utilisateurs finaux.