Menu
Démarrer un projet

Produit

Plateforme de gestion scolaire multi-organisations

Un seul déploiement au service de plusieurs écoles et entreprises, chacune ne voyant que ses propres personnes et enregistrements. Le modèle de permissions est la partie qui mérite d'être expliquée, parce que c'est celle qui doit tenir.

Statut: En développement actif.

Dessin abstrait de rangées et de groupes de blocs de largeurs différentes, figurant les classes, les groupes et les matières qui leur sont affectées.

Le problème

Une école fonctionne par relations : quel élève est dans quel groupe, quel enseignant enseigne quelle matière à quel groupe, quel parent est rattaché à quel enfant. Ces relations changent chaque trimestre, et elles vivent le plus souvent dans un tableur tenu par une seule personne.

Un logiciel pour cela est facile à mal construire. Le piège est une base unique qui laisse discrètement une école lire les données d'une autre, ce qui se découvre exactement une fois et ne se pardonne jamais.

Comment cela fonctionne

La plateforme est multi-organisations. Chaque enregistrement porte l'organisation à laquelle il appartient, sous forme d'identifiant, et chaque opération d'API vérifie que l'appelant en fait partie avant de renvoyer ou d'écrire quoi que ce soit. Une requête incapable de nommer son organisation ne s'exécute pas.

Au-dessus viennent les entités dont la journée a besoin : écoles et entreprises, classes, groupes de classe, élèves, parents, enseignants, matières, l'affectation des enseignants aux matières et celle des matières aux groupes.

Ce que couvre l'API

Les listes sont paginées, parce qu'une école de deux mille parents ne doit pas tenir dans une seule réponse.

  • Listes paginées de parents, d'enseignants et d'élèves
  • Gestion des classes et des groupes de classe
  • Affectation des matières aux classes et aux groupes
  • Affectation des enseignants aux matières, y compris plusieurs enseignants sur une même matière
  • Les requêtes inverses : classes pas encore affectées à une matière, enseignants pas encore affectés à une matière

Pourquoi les requêtes inverses comptent

La question que pose une administratrice en septembre n'est pas « qui enseigne cette matière ». C'est « quelles matières n'ont encore personne ». Une plateforme qui ne répond qu'à la question positive renvoie ses utilisateurs au tableur pour trouver les manques, donc les requêtes inverses sont des points d'API à part entière plutôt qu'un rapport ajouté plus tard.

Quatre rôles en haut, un contrôle de permissions au milieu, et deux ensembles de données d'organisations séparés en bas, montrant que chaque rôle n'atteint les données qu'à travers le contrôle.

Administrateur
Enseignant
Parent
Élève
Contrôle des permissions dans l'API
Données de l'école A
Données de l'école B
Le modèle de permissions. Les rôles sont propres à une organisation, et chaque lecture part de l'organisation de l'appelant plutôt que de filtrer ensuite.

Architecture

L'organisation dans le chemin d'accès

L'identifiant d'organisation fait partie de la façon dont on atteint un enregistrement plutôt que d'être une colonne filtrée ensuite. Ajouter une école est une ligne ; ce n'est pas un déploiement.

Contrôles de permissions à la frontière de l'API

Chaque opération vérifie l'organisation et le rôle de l'appelant avant de toucher aux données. L'interface reflète cet état ; elle ne le décide jamais.

Cas négatifs en premier

Les tests qui comptent vérifient ce qui se passe quand un enregistrement appartient à une autre organisation. Une fuite casse le build plutôt que d'atteindre un utilisateur.

Technologies

PHP Laravel MySQL Redis React Next.js Docker

Dites-nous ce que vous construisez.

Écrivez en anglais, en français, en roumain ou en arabe. Chaque message reçoit une réponse écrite sous un jour ouvré.