Un logiciel de gestion que j’ai conçu et développé seul pour une école d’anglais, en seize mois et 419 commits. Il a fait tourner l’école pendant plus d’un an ; j’ai arrêté d’y travailler en août 2026 et j’y reviens pendant les vacances. L’inscription remplit le PDF du contrat directement dans le navigateur, les contrats partent en signature électronique avec un statut suivi par webhook, l’école joint les familles par notifications web push, et l’emploi du temps est un tableau en glisser-déposer. La marque et les données de l’école restent privées : la démo ci-dessous est donc le même tableau de bord, refait avec une marque générique et des données fictives, navigable de bout en bout.
01 / LE PROBLÈME
Les inscriptions vivaient entre une imprimante et un fil WhatsApp.
Une école d’anglais gérait les inscriptions comme la plupart des petites écoles : un contrat rempli à la main, imprimé, signé quand un parent passait par là, et relancé sur WhatsApp quand il ne passait pas. L’emploi du temps vivait dans un tableur, les annonces partaient une conversation à la fois, et personne n’avait une vue unique de qui était inscrit, qui avait signé et qui devait encore signer.
J’ai construit le système qui a remplacé cette routine, et je l’ai fait évoluer pendant seize mois.
02 / LA RÉALISATION
Une inscription qui remplit son propre contrat.
Le PDF du contrat se remplit dans le navigateur. Les données du formulaire d’inscription arrivent sur le vrai contrat via pdf-lib : pas de ressaisie, pas de copie qui devient obsolète. Le document part ensuite en signature électronique, et un webhook met à jour son statut dans le panneau quand il revient signé.
Web push pour joindre les familles. Les annonces partent en notifications push au lieu d’un message WhatsApp de plus, perdu dans un fil.
Un emploi du temps en glisser-déposer. Les cours changent de salle et de créneau d’un glissement, et le planning s’imprime et s’exporte pour le mur à côté de l’accueil.
En dessous : React avec TypeScript, Postgres avec Drizzle ORM et des migrations numérotées, et une suite de régression Playwright qui tourne sur une base de test préremplie.
03 / SEIZE MOIS
419 commits, d’avril 2025 à août 2026.
C’est la partie qu’une démo ne peut pas simuler. Le dépôt compte 419 commits sur seize mois, environ 50 000 lignes à la fin, et l’historique se lit comme celui d’un vrai produit : d’abord l’inscription, puis les contrats et la signature, puis le planning, puis les notifications push. Les changements de schéma sont passés par des migrations ; les parcours importants sont couverts par des tests de bout en bout.
Un système n’accumule seize mois de commits que s’il est utilisé, et celui-ci l’était : de vraies inscriptions, de vrais contrats signés, un vrai emploi du temps sur un vrai mur.
04 / LA DÉMO
Le même tableau de bord, sous une marque générique.
La marque et les données appartiennent à l’école ; la version que vous pouvez ouvrir ici est donc le tableau de bord refait avec une marque générique, sur des données fictives. Mêmes écrans, même densité : trois profils d’accès (direction, coordination, accueil), cinq graphiques en direct, import de tableur et un thème clair/sombre animé avec la View Transitions API.
Toute la démo tient dans un seul fichier HTML. Elle s’ouvre sur un téléphone, sans connexion ni installation, et c’est tout l’intérêt : le vrai système existe, et voici la partie que je peux vous envoyer en lien.
Lignes de code
~50k
Commits
419
Mois de développement
16
Démo
1 HTML
