Lorsqu'un super-admin crée un établissement via l'interface, le système
doit automatiquement créer la base tenant, exécuter les migrations,
créer le premier utilisateur admin et envoyer l'invitation — le tout
de manière asynchrone pour ne pas bloquer la réponse HTTP.
Ce mécanisme rend chaque établissement opérationnel dès sa création
sans intervention manuelle sur l'infrastructure.
Les enseignants ont besoin de moyennes à jour immédiatement après la
publication ou modification des notes, sans attendre un batch nocturne.
Le système recalcule via Domain Events synchrones : statistiques
d'évaluation (min/max/moyenne/médiane), moyennes matières pondérées
(normalisation /20), et moyenne générale par élève. Les résultats sont
stockés dans des tables dénormalisées avec cache Redis (TTL 5 min).
Trois endpoints API exposent les données avec contrôle d'accès par rôle.
Une commande console permet le backfill des données historiques au
déploiement.
Les tests E2E échouaient pour trois raisons principales :
1. Initialisation asynchrone TipTap — L'éditeur rich-text s'initialise
via des imports dynamiques dans onMount(). Les tests interagissaient
avec .rich-text-content avant que l'élément n'existe dans le DOM.
Ajout d'attentes explicites avant chaque interaction avec l'éditeur.
2. Pollution inter-tests — Les fonctions de nettoyage (classes, subjects)
ne supprimaient pas les tables dépendantes (homework, evaluations,
schedule_slots), provoquant des erreurs FK silencieuses dans les
try/catch. De plus, homework_submissions n'a pas de ON DELETE CASCADE
sur homework_id, nécessitant une suppression explicite.
3. État partagé du tenant — Les règles de devoirs (homework_rules) et le
calendrier scolaire (school_calendar_entries avec Vacances de Printemps)
persistaient entre les fichiers de test, bloquant la création de devoirs
dans des tests non liés aux règles.
Les établissements ont besoin de protéger les élèves et familles des
devoirs de dernière minute. Cette configuration au niveau tenant permet
de définir des règles de timing (délai minimum, pas de devoir pour
lundi après une heure limite) et un mode d'application (avertissement,
blocage ou désactivé).
Le service de validation est prêt pour être branché dans le flux de
création de devoirs (Stories 5.4/5.5). L'historique des changements
assure la traçabilité des modifications de configuration.
