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.
Akeneo permet de configurer des règles de devoirs en mode Hard qui bloquent
totalement la création. Or certains cas légitimes (sorties scolaires, événements
exceptionnels) nécessitent de passer outre ces règles. Sans mécanisme d'exception,
l'enseignant est bloqué et doit contacter manuellement la direction.
Cette implémentation ajoute un flux complet d'exception : l'enseignant justifie
sa demande (min 20 caractères), le devoir est créé immédiatement, et la direction
est notifiée par email. Le handler vérifie côté serveur que les règles sont
réellement bloquantes avant d'accepter l'exception, empêchant toute fabrication
de fausses exceptions via l'API. La direction dispose d'un rapport filtrable
par période, enseignant et type de règle.
Quand un établissement configure des règles de devoirs en mode "soft",
l'enseignant est maintenant averti avant la création si la date d'échéance
ne respecte pas les contraintes (délai minimum, pas de lundi après un
certain créneau). Il peut alors choisir de continuer (avec traçabilité)
ou de modifier la date vers une date conforme.
Le mode "hard" (blocage) reste protégé : acknowledgeWarning ne permet
pas de contourner les règles bloquantes, préparant la story 5.5.
