Suivi académique pour étudiants et enseignants
Équipe de trois, que j'ai dirigée · 2026 · React, TypeScript, Supabase
EduTrack donne à un étudiant un seul endroit pour toute sa scolarité : notes par module, absences, tâches et échéances, sessions de travail, journal de réflexion, et des analyses sur l'ensemble. Les enseignants suivent les étudiants de leurs groupes et font l'appel.
J'ai dirigé une équipe de trois et construit l'essentiel — le schéma de base de données et ses migrations, la couche d'accès aux données et l'interface. C'est une application monopage React et TypeScript sur Supabase : PostgreSQL y fait plus de travail que derrière un front classique.
Les étudiants suivent leurs études entre un tableur, une application de notes et leur mémoire. Les chiffres qui comptent — une moyenne qui glisse, des absences qui s'accumulent — restent éparpillés jusqu'à ce qu'il soit tard pour réagir. EduTrack les réunit, à jour dès qu'une note ou une absence est saisie.
Il y a un second public, et il façonne le modèle de données : les enseignants doivent suivre un groupe sans voir les étudiants qui n'en font pas partie, tandis que certaines choses — les réflexions d'un étudiant, ses sessions de travail — ne regardent que lui. Qui voit quoi fait donc partie du produit, ce n'est pas un détail ajouté après coup.
Un utilisateur sans ligne de profil, c'est un bug en attente dans chaque requête qui fait une jointure dessus. Créer le profil par un trigger à l'inscription — dans la même transaction que le compte — rend cet état impossible, au lieu de compter sur le client pour s'en souvenir.
Un enseignant a plusieurs groupes ; un étudiant peut appartenir à plus d'un. Modéliser cela avec des groupes et deux tables d'appartenance, et poser la question « cet enseignant a-t-il cet étudiant ? » à travers une seule fonction partagée, fait que chaque règle d'accès pose la même question de la même façon — un seul endroit à comprendre, un seul endroit à modifier.
La sécurité au niveau des lignes ne pardonne rien, dans les deux sens. Une règle trop large laisse fuir des données en silence ; une règle trop stricte renvoie une liste vide, qui ressemble exactement à une absence de données. Ajouter enseignants et groupes a demandé de remplacer entièrement les premières règles dans une deuxième migration, et de décider, table par table, ce qu'un enseignant devait atteindre et ce qui devait rester privé.
Le reste, c'était la coordination : trois personnes sur un même schéma, où une migration écrite par l'un change ce que renvoient les requêtes des autres.
Déployée et utilisable de bout en bout : s'inscrire comme étudiant ou enseignant, rejoindre un groupe et suivre un semestre — notes sur 20 par module et par type, appel fait par l'enseignant pour tout le groupe, tâches avec sous-tâches, et les analyses par-dessus.
Tester directement les règles d'accès. Chacune est un petit programme, et pour l'instant la seule preuve qu'elle se comporte bien, c'est d'utiliser l'application.
Puis construire les deux fonctionnalités que la page d'accueil promet et que l'application n'a pas encore : une moyenne semestrielle projetée, et une alerte avant qu'un étudiant n'atteigne la limite d'absences d'un module.