Croissance Technique et Guide EdTech pour Entreprises avec Educati

Isolation multi-tenant par établissement

Pour un groupe multi-campus, chaque établissement dispose de son propre espace logique — données, domaine, thème, administrateurs — sur une infrastructure mutualisée. Chaque requête est cantonnée à l'établissement de l'utilisateur : c'est la garantie qu'un enseignant d'un campus ne peut agir sur le dossier d'un étudiant d'un autre.

Rôles granulaires et journal d'audit

Les droits sont attribués par rôle et par périmètre, et les actions sensibles — changement de note, export, modification de dossier, attribution de droits — sont horodatées dans un journal d'audit exportable en CSV, les consultations ne l'étant pas. C'est ce journal, et non une capture d'écran, qui documente qui a fait quoi lors d'une contestation.

Ce que la plateforme expose réellement aujourd'hui

Les échanges avec le système d'information passent par des exports (AREF, MASSAR, étudiants, paiements, journaux) et par une API v1 dont les données sont en lecture seule, authentifiée soit par clé d'établissement à portées explicites, soit par jeton utilisateur, et limitée en débit. Deux points d'entrée écrivent : l'authentification, qui délivre et renouvelle les jetons, et le marquage d'une notification comme lue. Elle couvre les cours, les devoirs, les notes, l'emploi du temps, l'assiduité et les notifications de l'utilisateur authentifié ; elle ne couvre pas l'ensemble des fonctionnalités — ni le dépôt d'un devoir, ni la saisie d'une note — et il serait malhonnête de la présenter comme une API complète. Vérifiez la couverture réelle avant de bâtir une intégration dessus.

Montée en charge : tester, pas promettre

Avant une session critique, faites exécuter un test de charge reproduisant le pic attendu et demandez le rapport. Une capacité annoncée sans mesure ne vaut rien le jour de l'épreuve.