Aller au contenu

Z7 — Routine de soirée & Orchestration

EveningPlan · Dashboard soirée · Séquencement multi-matières · Budget temps · Complétion · Guidage capture · Onboarding routine · Notions & hiérarchie contenu · Périmètre exam par notion · Angles morts · Prédiction interro surprise · S'avancer le weekend · Fiches PDF hors-téléphone · Report papier

Z7-AC01 — Calcul automatique du plan de soirée (EveningPlan)

Lot 0
GIVEN L'élève a un emploi du temps renseigné. Aujourd'hui (mardi), il a eu Physique-Chimie (créneau 10h-11h) et Histoire-Géo (créneau 14h-15h). Le chapitre « Mouvement et vitesse » (Physique) existe avec des items FRAGILE/OK dues. Le chapitre « Les inégalités » (Histoire) n'existe pas encore (cours non capturé). Un chapitre de Maths « Pythagore » a des items FRAGILE dues depuis 2 jours. Demain (mercredi), l'élève a SVT (un chapitre actif avec items UNKNOWN).
WHEN L'élève ouvre l'app entre 17h et 22h (fenêtre configurable dans user.evening_window_start / user.evening_window_end, défaut 17h-22h).
THEN Le système calcule un EveningPlan pour ce soir, composé d'étapes ordonnées : (1) Capture : « Saisis ton cours d'Histoire-Géo » (matière détectée comme non capturée via schedule + absence de chapitre actif récent). (2) evening_first : session premier contact pour Histoire-Géo si la capture est faite (~5 min). (3) daily : session de révision quotidienne couvrant Physique (items FRAGILE/OK dues) + Maths (items FRAGILE dues) (~10 min). Les items pre_class pour SVT de demain sont fusionnés dans le daily (Z6-AC08). Chaque étape a un type (capture / evening_first / daily), un estimated_duration_min calculé (nombre de questions × durée moyenne par type de gabarit : MCQ ~30s, SHORT ~60s, NUMERIC ~90s, RUBRIC ~180s), un status (pending / in_progress / completed / skipped), et un subject_label pour l'affichage. L'EveningPlan est recalculé si un événement survient en cours de soirée (nouvelle capture, session terminée). Le plan est éphémère (TTL = fin de la fenêtre de soirée ou 6h après calcul).

NOTE : L'EveningPlan est la pièce manquante qui transforme un ensemble d'outils en assistant de soirée. Les sessions (evening_first, daily, pre_class) existent déjà et sont bien spécifiées — ce qui manque est l'orchestrateur qui les assemble en une checklist ordonnée avec estimation de durée et suivi de progression. L'EveningPlan ne modifie pas le moteur de composition des sessions ; il séquence et présente les sessions que le moteur produit déjà.

Z7-AC02 — Dashboard soirée contextuel (écran d'accueil du soir)

Lot 0
GIVEN L'élève ouvre l'app à 19h30. L'EveningPlan a été calculé (Z7-AC01) avec 3 étapes : capture Histoire, evening_first Histoire (~5 min), daily Physique+Maths (~10 min).
WHEN L'heure actuelle est dans la fenêtre de soirée (evening_window_start ≤ now ≤ evening_window_end).
THEN L'écran d'accueil affiche le dashboard soirée (distinct du dashboard progression global Z6-AC30, accessible via un toggle). Le dashboard soirée contient : (1) Un en-tête contextuel : « Bonsoir [prénom] ! Ce soir : 3 activités, ~15 min. » (2) La liste des étapes du plan, chaque étape affichant : icône matière + libellé (« Capture tes notes d'Histoire », « Première révision Histoire », « Révision quotidienne ») + durée estimée + statut visuel (à faire / en cours / fait ✓). (3) Un bouton « C'est parti ! » sur la première étape non complétée. (4) Si l'élève revient après avoir complété une étape, le dashboard est mis à jour (étape cochée, bouton sur l'étape suivante). En dehors de la fenêtre de soirée, le dashboard par défaut reste le dashboard progression (Z6-AC30). L'élève peut basculer manuellement entre les deux vues à tout moment.

NOTE : Le dashboard soirée EST l'assistant. Un élève de 12 ans qui ouvre l'app a besoin de voir UNE chose : « voilà ce que tu dois faire ce soir ». Le dashboard progression (Z6-AC30) répond à la question « où en suis-je globalement ? » ; le dashboard soirée répond à « qu'est-ce que je fais maintenant ? ». Les deux sont complémentaires mais le dashboard soirée est l'écran primaire pendant la fenêtre du soir.

Z7-AC03 — Séquencement multi-matières dans le plan de soirée

Lot 0
GIVEN L'élève a eu Physique et Histoire aujourd'hui. Il capture les deux cours (2 chapitres créés). Il a aussi des items Maths dues (daily). Et demain il a SVT (pre_class). L'EveningPlan contient potentiellement : 2 captures + 2 evening_firsts + 1 daily (avec pre_class SVT fusionné).
WHEN L'EveningPlan est calculé (Z7-AC01).
THEN L'ordre des étapes suit la priorité pédagogique : (1) Captures en premier (sans capture, pas de contenu frais). Si plusieurs captures, l'ordre est : matière avec exam le plus proche d'abord, puis par ordre chronologique du créneau de la journée. (2) evening_first pour chaque chapitre fraîchement capturé (premier contact le soir même = encodage optimal). Si deux evening_firsts, ils sont fusionnés en une seule session multi-chapitres : les items UNKNOWN des deux chapitres sont mélangés, alternant entre matières pour éviter la monotonie. Durée cible de la session fusionnée : min(somme des durées individuelles, 10 min). (3) daily en dernier : révision des items dues (70/20/10) avec items pre_class SVT intégrés (Z6-AC08). Le nombre total d'étapes affichées à l'élève est ≤ 4 (captures groupées si > 2 matières). La durée totale estimée du plan ne dépasse pas 25 min ; si elle dépasse, le daily est raccourci (moins de questions, items les plus urgents d'abord).

NOTE : La fusion des evening_firsts évite le problème du « 3 sessions de 5 min = 3 démarrages, 3 débriefs, friction x3 ». Un seul flux continu avec alternance de matières est plus engageant et fidèle au modèle du « coach qui fait réviser ». L'ordre capture → evening_first → daily suit la logique pédagogique : encoder le neuf d'abord (mémoire de travail fraîche), puis consolider l'ancien (récupération espacée).

Z7-AC04 — Estimation de durée visible avant le début

Lot 0
GIVEN L'EveningPlan contient 3 étapes : capture (~2 min estimée sur la base du nombre moyen de pages), evening_first 8 questions (~5 min), daily 12 questions (~8 min).
WHEN Le dashboard soirée s'affiche (Z7-AC02).
THEN Chaque étape affiche sa durée estimée (« ~5 min »). L'en-tête affiche la durée totale (« ~15 min au total »). Les estimations sont calculées à partir du nombre et type de questions composées : MCQ/CLOZE ~30s, SHORT_ANSWER/DEF_SHORT ~60s, NUMERIC ~90s, RUBRIC ~180s, plus 15s de transition entre questions. Le temps de capture est estimé à 1 min par page (basé sur la médiane historique de l'élève, ou 1 min/page par défaut). Si l'élève a un historique de sessions, les estimations sont calibrées sur son rythme réel (médiane des 10 dernières sessions). L'estimation est affichée avec un arrondi à 5 min près au-dessus de 10 min (« ~15 min ») et à la minute près en dessous (« ~7 min »).

NOTE : La prévisibilité du temps est le facteur #1 de démarrage pour un adolescent. « Ce soir ~15 min » est la différence entre « j'y vais » et « je procrastine ». Sans estimation, l'engagement est perçu comme ouvert et indéfini — un frein psychologique majeur. Le calibrage sur le rythme réel de l'élève améliore la précision au fil du temps.

Z7-AC05 — État « fini pour ce soir » et écran de clôture

Lot 0
GIVEN L'élève a complété toutes les étapes de son EveningPlan : capture Histoire (✓), evening_first Histoire+Physique (✓), daily Maths+SVT (✓).
WHEN La dernière session du plan se termine (débrief Z1-AC15 affiché puis fermé).
THEN L'écran de clôture de soirée s'affiche (distinct du débrief par session Z1-AC15). Il contient : (1) Message de félicitations : « Bravo [prénom] ! Soirée terminée en [durée réelle] min. » (2) Résumé de la soirée : nombre de matières couvertes, nombre d'items révisés, progressions de maîtrise (items passés FRAGILE→OK, OK→SOLID). (3) Aperçu de demain : « Demain tu as SVT et Français. À demain soir ! » (ou « Demain c'est mercredi, pas de cours — profite ! »). (4) Un seul bouton « Fermer » qui ramène au dashboard progression (Z6-AC30). L'EveningPlan.completed_at est horodaté. L'événement routine_completed est émis (consommé par Z7-AC13 pour la notification parent). Si l'élève rouvre l'app dans la fenêtre de soirée après clôture, le dashboard soirée affiche « Tout est fait pour ce soir ! 🎉 » avec le résumé, et un lien optionnel vers une session de consolidation (Z4-AC13) sans risque de régression.

NOTE : L'écran de clôture est le « payoff émotionnel » de toute la routine. Il donne à l'élève la permission explicite de fermer l'app sans culpabilité. Sans ce signal, l'élève ne sait jamais s'il devrait en faire plus — anxiété incompatible avec un usage durable. Le résumé de soirée (et non de session) valorise l'effort global et pas seulement le dernier exercice.

Z7-AC06 — Guidage capture in-app (matières du jour non capturées)

Lot 0
GIVEN L'élève a eu Physique et Histoire aujourd'hui (schedule). Le chapitre « Mouvement et vitesse » (Physique) existe déjà (capturé la semaine dernière, pages 1-3). L'élève n'a pas de chapitre actif lié à l'Histoire-Géo de ce créneau.
WHEN L'élève ouvre l'app dans la fenêtre de soirée. L'EveningPlan est calculé.
THEN Le plan de soirée affiche en première position : « 📸 Saisis ton cours d'Histoire-Géo » avec un bouton « Capturer » qui ouvre directement le flux de création de chapitre (ou d'ajout de pages si un chapitre HG existe). Pour la Physique, le plan détecte que le chapitre existe mais vérifie si de nouvelles pages sont attendues (cours aujourd'hui + dernière capture antérieure à aujourd'hui). Si oui : « 📸 Ajoute les nouvelles pages de Physique à ton chapitre » avec bouton « Ajouter des pages » (Z5-AC11). Si l'élève a déjà capturé/ajouté les pages aujourd'hui, l'étape de capture est marquée ✓ automatiquement. L'étape de capture indique la matière, le créneau horaire (« cours de 14h »), et un rappel du nombre de pages moyen pour ce type de cours (basé sur l'historique de l'élève ou « ~3-5 pages » par défaut). Si aucune matière n'a de capture en attente, l'étape de capture n'apparaît pas dans le plan.

NOTE : La notification push capture_reminder (Z6-AC02) est le premier signal, mais elle est éphémère (taux d'ouverture ~40%). Le guidage in-app est le deuxième filet : quand l'élève ouvre l'app (de lui-même ou après relance parentale), il voit immédiatement quoi capturer. Sans ce guidage, l'élève qui a ignoré la notification ouvre l'app et voit… le dashboard progression, sans aucune indication qu'il a eu cours aujourd'hui.

Z7-AC07 — Règles de séquencement des types de session

Lot 0
GIVEN L'élève a capturé un nouveau chapitre ce soir (evening_first disponible). Il a aussi 15 items FRAGILE/OK dues dans d'autres chapitres (daily disponible). Et il a SVT demain avec un chapitre actif (pre_class pertinent).
WHEN L'EveningPlan compose les sessions de la soirée.
THEN L'ordre déterministe est : (1) evening_first (si applicable) — le contenu frais bénéficie de l'encodage initial le soir même (effet de récence + sommeil consolidateur). (2) daily — révision espacée des items dues, avec items pre_class fusionnés dans le bucket 20% (Z6-AC08). La session evening_first d'un chapitre complet (premier upload, pas incrémental) n'est pas fusionnée dans le daily — elle reste une session distincte avec ses propres règles (100% UNKNOWN, difficulté 1, Z6-AC06). La session evening_first incrémentale (ajout de pages, Z6-AC43) est fusionnée dans le daily si un daily existe (comportement existant). Si l'élève ne fait que l'evening_first et quitte l'app, le daily reste disponible pendant 72h (TTL session standard). Le plan marque l'evening_first comme « prioritaire » et le daily comme « recommandé ». Le plan ne propose jamais plus de 2 sessions distinctes par soirée (hors capture). Si un pre_class ne peut pas être fusionné dans le daily (pas de daily dû ce soir), il est proposé comme session distincte de 5 min maximum.

NOTE : La distinction « evening_first reste séparé, evening_first_incremental fusionne » s'explique par la nature du contenu. Un chapitre entièrement nouveau mérite un premier contact dédié (100% UNKNOWN, gabarits simples, contexte « découverte »). Des pages ajoutées à un chapitre existant s'insèrent naturellement dans le flux daily car l'élève connaît déjà le contexte du chapitre. Limiter à 2 sessions max par soirée évite l'effet « encore une session ? » qui tue l'engagement.

Z7-AC08 — Mode express pour soirée courte (budget temps réduit)

Lot 0
GIVEN L'EveningPlan estime 20 min pour la soirée complète (capture + evening_first + daily). L'élève a beaucoup de devoirs ce soir.
WHEN L'élève tape sur « Je n'ai pas beaucoup de temps ce soir » (bouton visible sur le dashboard soirée, sous l'estimation de durée). Ce bouton est accessible à tout moment tant que le plan n'est pas terminé — y compris après avoir complété une ou plusieurs étapes.
THEN Le plan bascule en mode express (EveningPlan.mode = 'express'). La durée cible des étapes restantes passe à ≤ 10 min. Les étapes déjà complétées ne sont pas affectées (elles restent marquées ✓). Les étapes restantes sont re-priorisées : (1) Capture : conservée si non faite (l'élève peut toujours photographier ses notes rapidement, ~2 min). (2) Révision express : une session unique fusionnant les items les plus urgents — items FRAGILE dues en premier (risque de régression si pas revus), puis items UNKNOWN du chapitre frais (si capture faite) avec gabarits difficulté 1 uniquement. Nombre de questions réduit à 6-8 max. Les items OK dues sont reportés à demain sans pénalité (Z6-AC15). Si l'élève a déjà fait l'evening_first et active express, seul le daily est raccourci. Le débrief express mentionne : « Soirée express terminée en [X] min. Les points restants seront intégrés demain. » L'élève peut aussi saisir une durée libre (« Combien de temps ? ») via un slider 5-15 min, et le plan s'adapte. Le mode express n'affecte pas le calcul des next_due_at : les items non revus ce soir restent dues et seront reproposés demain (pas de pénalité).

NOTE : Un adolescent qui a 45 min de devoirs plus la révision va choisir les devoirs (conséquence immédiate : le prof vérifie demain). Si l'app ne propose pas de mode court, l'élève saute entièrement la révision. 5 minutes de révision ciblée valent infiniment mieux que 0 minute. Le mode express maintient l'habitude vivante les soirs chargés — c'est un anti-churn majeur.

Z7-AC09 — Complétion partielle et reprise le lendemain

Lot 0
GIVEN L'EveningPlan de mardi avait 3 étapes. L'élève a complété la capture et l'evening_first (2/3 étapes) mais n'a pas fait le daily. Il ferme l'app à 21h.
WHEN Le lendemain matin (mercredi), l'EveningPlan de mardi est expiré (fin de fenêtre de soirée). Le daily non fait contenait 12 questions.
THEN Les items dues du daily de mardi restent dues (pas de pénalité, Z6-AC13). Ils sont intégrés dans l'EveningPlan de mercredi avec priorité haute (bucket 70% du daily, items en retard). Le dashboard soirée de mardi soir, si l'élève revient avant la fin de la fenêtre, affiche les étapes complétées (✓) et le daily restant avec « Continue ta révision quand tu veux ». L'écran de clôture partielle (si l'élève ferme après 2/3 étapes) affiche : « 2 activités sur 3 terminées — bien joué ! Ta révision quotidienne sera intégrée demain. » Le ton est positif, jamais culpabilisant. Le parent reçoit un signal de complétion partielle (variante de Z7-AC13, adaptée au cas partiel) : « [Prénom] a capturé son cours et fait sa première révision (2/3 activités). » La complétion partielle est comptabilisée comme « routine partielle » dans les métriques (ni « complète » ni « manquée »).

NOTE : La complétion partielle est la norme, pas l'exception. Un collégien ne fera pas systématiquement 100% de son plan. Le design doit valoriser l'effort fait (2/3 = bien joué !) plutôt que culpabiliser le manque (1/3 pas fait). Les items non revus ne sont pas perdus — ils passent dans le daily du lendemain. Cette approche est cohérente avec Z6-AC13 (pas de pénalité mastery pour items en retard) et Z6-AC15 (pas de streak).

Z7-AC10 — Rien à réviser ce soir / week-end

Lot 0
GIVEN L'élève ouvre l'app dans la fenêtre de soirée. Aucun item n'est dû pour ce soir (tous les next_due_at > aujourd'hui, aucune session evening_first ou pre_class à composer). Ou bien c'est le week-end (samedi/dimanche).
WHEN Le calcul de l'EveningPlan retourne 0 sessions.
THEN En semaine : le dashboard affiche un message positif : « Rien à réviser ce soir — tu es à jour ! Prochaine session : [date du prochain next_due_at]. » Pas de culpabilisation, pas de « tu pourrais quand même… ». Le guidage capture reste visible si des cours non capturés existent. Le week-end : le plan est relaxé. Si des items sont dus (next_due_at ≤ aujourd'hui), une session optionnelle courte est proposée (« Petite session de rattrapage ? ~5 min »). Si aucun item n'est dû, le message est : « Bon week-end ! On reprend [lundi/après les vacances]. » Pas de session proactive le week-end sauf items en retard. L'estimation de durée affiche « 0 min » pour le week-end dans le dashboard parent.

Z7-AC11 — Guidage de capture lié au cours de demain

Lot 0
GIVEN L'élève a SVT demain (mercredi). Il a eu SVT lundi mais n'a jamais capturé ce cours (pas de chapitre SVT actif, ou chapitre SVT existant sans pages récentes).
WHEN L'EveningPlan de mardi soir est calculé.
THEN Le plan inclut une étape de capture contextualisée par le cours de demain : « Tu as SVT demain — saisis ton cours de lundi pour pouvoir le réviser avant ! » Cette étape est positionnée avant les étapes de capture des matières du jour (priorité = cours de demain non capturé > cours d'aujourd'hui non capturé, car le pre_class de demain a besoin du contenu). Si l'élève capture le cours SVT, un pre_class est immédiatement composable pour ce soir (intégré dans le daily ou proposé en session courte). Si l'élève ignore l'étape, elle passe en « skippée » sans conséquence. La notification pre_class (Z6-AC07) mentionne aussi le cours non capturé : « Tu as SVT demain — tu n'as pas encore saisi ton cours de lundi. Saisis-le pour réviser ce soir ! »

NOTE : Aujourd'hui la notification pre_class (Z6-AC07) se contente de proposer une session de révision sur les items existants. Mais si le cours de lundi n'a jamais été capturé, le pre_class n'a rien à proposer. Le guidage de capture lié au cours de demain connecte deux moments qui sont actuellement déconnectés : « tu as SVT demain » + « tu n'as pas capturé lundi ». C'est exactement le comportement d'un coach qui dit « tu as un cours demain, prépare-toi ».

Z7-AC12 — Arc émotionnel de la soirée (accueil, transitions, clôture)

Lot 0
GIVEN L'élève ouvre l'app un mardi soir. Il a 3 étapes dans son plan.
WHEN L'élève progresse dans les étapes de son EveningPlan.
THEN Chaque moment-clé de la soirée a un message personnalisé et contextuel : (1) Accueil (ouverture de l'app) : « Bonsoir [prénom] ! Ce soir : [N] activités, ~[X] min. » Variantes contextuelles : « Grosse journée — 3 matières ! On s'y met ? » (si ≥ 3 matières), « Soirée tranquille — juste une petite révision ! » (si ≤ 1 session, < 10 min), « Dernière ligne droite avant ton contrôle de [matière] ! » (si exam ≤ 3 jours). (2) Transitions (entre étapes) : après la capture → « Super, tes notes sont enregistrées ! Maintenant, un premier contact rapide avec ce que tu as appris. » Après evening_first → « Bien joué, premier contact fait ! Encore [X] min de révision et c'est fini. » (3) Clôture : gérée par Z7-AC05. Les messages utilisent le prénom de l'élève et varient (pas de répétition exacte deux soirs de suite — rotation d'au moins 5 variantes par moment). Le ton est encourageant, jamais culpabilisant, et adapté à l'âge (tutoiement, phrases courtes, langage courant).

NOTE : L'arc émotionnel accueil → progression → clôture est le fil narratif de l'assistant. Les micro-célébrations (Z1-AC16) et le débrief session (Z1-AC15) couvrent le niveau « question » et « session » — mais le niveau « soirée » est le niveau auquel l'élève s'identifie. « J'ai fait ma routine de ce soir » est plus significatif que « j'ai répondu à 12 questions ». Les transitions entre étapes sont les moments où l'élève risque de décrocher (« est-ce que j'ai fini ? ») — les messages de transition éliminent cette incertitude.

Z7-AC13 — Notification parent « routine terminée » (signal positif)

Lot 0
GIVEN L'élève a complété son EveningPlan (toutes les étapes en statut « completed »). L'événement routine_completed est émis (Z7-AC05). Le parent a activé les notifications (routine_completed_enabled = true, activé par défaut).
WHEN L'événement routine_completed est traité par le service de notification.
THEN Le parent reçoit une notification push : « ✅ [Prénom] a terminé sa révision du soir : [N] matières, [X] min. [résumé court : ex. "3 points progressent en Physique"]. » En cas de complétion partielle (Z7-AC09, ≥ 50% des étapes) : « [Prénom] a fait une partie de sa révision ce soir ([N]/[M] activités, [X] min). » En cas de complétion < 50% ou routine non commencée : pas de notification positive — la notification « session manquée » existante (Z6-AC18) prend le relais le lendemain matin. La notification routine_completed est envoyée maximum 1 fois par soir. Elle n'est pas envoyée les soirs où l'EveningPlan est vide (Z7-AC10 — rien à faire). Le parent peut désactiver cette notification dans ses préférences (Z6-AC20 étendu avec routine_completed_enabled). Le digest hebdomadaire (Z6-AC27) inclut un compteur de routines complétées : « Cette semaine : [N]/[M] routines de soirée complétées. »

NOTE : Les parents ne reçoivent actuellement des signaux que quand ça se passe mal (session manquée Z6-AC18, inactivité Z6-AC19). Un parent qui ne reçoit que des alertes négatives développe une association anxieuse avec l'app. La notification « routine terminée » est le signal positif symétrique — elle répond à la question que chaque parent se pose le soir : « Est-ce qu'il a révisé ? » Sans cette notification, le parent doit soit demander à l'enfant (conflit), soit ouvrir l'app parent pour vérifier (friction). C'est aussi un moteur de rétention pour l'abonnement : la valeur perçue augmente quand le parent « voit » l'effort de l'enfant.

Z7-AC14 — Onboarding de la première soirée

Lot 0
GIVEN L'élève vient de terminer l'onboarding initial (création de compte + saisie emploi du temps). Le chapitre démo (Z8-AC01) est présent mais l'élève n'a uploadé aucun vrai chapitre. C'est sa première soirée avec l'app.
WHEN L'élève ouvre l'app dans la fenêtre de soirée pour la première fois. Si l'élève a déjà complété une capture + evening_first avant la première fenêtre de soirée (ex : compte créé à 10h le samedi), le tutoriel saute les étapes déjà faites et reprend à l'étape suivante du tutoriel progressif (jour 2+).
THEN Le dashboard soirée affiche un mode tutoriel première soirée (overlay guidé) : (1) « Bienvenue dans ta routine du soir ! Chaque soir, l'app te dit quoi faire en ~10-15 min. » (2) « Maintenant, capture ton vrai cours. Prends en photo les pages de ton cours de [matière du jour si schedule renseigné / "ta matière préférée" sinon]. » → bouton « Capturer mon premier chapitre ». (3) Après la capture + pipeline terminé : « Parfait ! Maintenant, un premier contact rapide avec ce que tu as noté. ~5 min. » → lancement de l'evening_first. (4) Après l'evening_first : écran de clôture spécial première soirée : « Bravo, ta première routine est terminée ! 🎉 Demain soir, l'app te proposera une nouvelle session pour renforcer ce que tu as appris. Chaque soir, ça prend 10-15 min — moins qu'un épisode de ta série. » (5) Le lendemain soir (jour 2) : le dashboard affiche un message de « jour 2 » : « Tu reviens ! Aujourd'hui, on révise ce que tu as appris hier. Tu vas voir, c'est rapide. » La session daily est proposée. (6) Le tutoriel progressif s'étend sur 5 jours : jour 1 = capture + evening_first, jour 2 = daily expliqué, jour 3 = pre_class expliqué (si applicable), jour 4 = mode express mentionné, jour 5 = « Tu as pris le rythme ! À partir de maintenant, l'app te guide automatiquement. » Chaque message tutoriel est affiché une seule fois et ne réapparaît plus après.

NOTE : La première soirée est le moment de conversion critique. L'élève qui comprend le concept de « routine du soir » et qui vit une première expérience guidée et gratifiante reviendra demain. L'élève qui ouvre l'app et voit un dashboard vide ou un pipeline en cours sans contexte ne reviendra pas. Le tutoriel progressif sur 5 jours correspond au temps moyen de formation d'une micro-habitude chez les adolescents. L'analogie avec « un épisode de série » est intentionnelle : c'est le référentiel temporel naturel d'un collégien.

Z7-AC15 — Notions : regroupement des items par concept_tag

Lot 0 P1
GIVEN Le chapitre « Densité et masse volumique » contient 14 items. Le pipeline a attribué les concept_tags suivants : masse (3 items), volume (2 items), rho (4 items), deplacement_eau (3 items), materiaux (2 items).
WHEN L'élève consulte la vue détaillée du chapitre.
THEN Les items sont regroupés en Notions — une Notion = un cluster de concept_tags sémantiquement proches (le pipeline LLM regroupe les tags en Notions nommées lors de la génération du pack). Affichage en accordéon : Notion « Masse volumique (ρ) » (items taggés rho + masse + volume = 9 items) avec barre de maîtrise (ex: 4/9 = 44%), Notion « Mesure par déplacement d'eau » (items taggés deplacement_eau = 3 items) avec barre de maîtrise (3/3 = 100%), Notion « Matériaux et densité » (items taggés materiaux = 2 items) avec barre de maîtrise (0/2 = 0%). Le regroupement est déterministe et stable (même contenu = mêmes Notions). Le nombre de Notions par chapitre est typiquement 3–7 (le pipeline cible ce range ; si < 3, pas de regroupement affiché ; si > 7, les Notions les plus petites sont fusionnées). Chaque Notion affiche : nom lisible (généré par le LLM, ex: « Les propriétés de l'eau »), nombre d'items, barre de maîtrise (% items OK+SOLID), et un indicateur de dernière révision (« révisé il y a 2 jours »). L'entité Notion est définie dans le data model : id · chapter_id · name · concept_tags[] · item_ids[] · order (int).

NOTE : Les concept_tags existent déjà dans le pipeline (PRD §6.1) mais ne sont pas exposés à l'élève. Le passage de tags plats à des Notions nommées et regroupées est la clé de voûte de la hiérarchisation : l'élève pense en « notions de cours » (masse volumique, déplacement d'eau), pas en tags atomiques (rho, deplacement_eau). Le LLM qui génère le pack est le mieux placé pour nommer ces regroupements car il a le contexte pédagogique du cours. Le coût est quasi nul (une instruction supplémentaire dans le prompt de génération).

Z7-AC16 — Notions dans la vue chapitre : accordéon et maîtrise par notion

Lot 0 P2
GIVEN Le chapitre « Photosynthèse » a 4 Notions : « Chloroplastes et chlorophylle » (6 items, 5 OK/SOLID), « Équation de la photosynthèse » (4 items, 1 FRAGILE, 2 UNKNOWN), « Facteurs limitants » (3 items, 3 SOLID), « Rôle du CO₂ et de la lumière » (5 items, 3 OK).
WHEN L'élève ouvre la vue chapitre « Photosynthèse ».
THEN La vue chapitre affiche la barre de maîtrise globale du chapitre (11/18 = 61%) ET en dessous, les 4 Notions en accordéon, chacune avec : (1) Nom de la notion (« Équation de la photosynthèse »). (2) Mini-barre de maîtrise par notion (1/4 = 25%, couleur rouge/orange). (3) Indicateur d'état dominant (FRAGILE si ≥ 1 item FRAGILE, UNKNOWN si ≥ 1 UNKNOWN et 0 FRAGILE, OK sinon). (4) Au clic/tap sur une Notion → déplier pour voir la liste des items avec leur état individuel (UNKNOWN/FRAGILE/OK/SOLID). Les Notions sont triées par « besoin de révision » : FRAGILE d'abord, puis UNKNOWN, puis OK, puis SOLID. Cette vue permet à l'élève de comprendre il est faible dans un chapitre, pas juste « combien » il maîtrise globalement.

NOTE : Sans la granularité par Notion, la barre de maîtrise d'un chapitre à 61% ne dit rien d'actionnable. Avec les Notions, l'élève voit que « Facteurs limitants » est à 100% mais « Équation de la photosynthèse » est à 25% — il sait exactement quoi réviser. C'est aussi la base nécessaire pour la sélection du périmètre d'exam (Z7-AC17) : si l'élève ne peut pas voir les notions, il ne peut pas les sélectionner.

Z7-AC17 — Sélection du périmètre d'exam : auto-scope + ajustement par notion

Lot 0
GIVEN L'élève crée un Exam « Contrôle Physique — Séquence 2 » avec exam_date = 2026-04-10. Il sélectionne 2 chapitres : « Mouvement et vitesse » (5 Notions, 14 items) et « Forces » (4 Notions, 11 items).
WHEN L'écran de sélection du périmètre s'affiche après le choix des chapitres.
THEN Le système affiche un écran de sélection par Notion : pour chaque chapitre, la liste des Notions est affichée avec des toggles (activé/désactivé). Auto-scope par défaut : toutes les Notions sont cochées. L'élève peut décocher des Notions spécifiques (ex: « Forces de frottement » si le prof n'a pas encore fait ce cours). Chaque Notion affiche : nom, nombre d'items, mini-barre de maîtrise. Un compteur en bas indique le périmètre résultant : « 22 points de révision sur 25 sélectionnés ». Les items des Notions décochées sont exclus du resserrement Z1-AC08 (pas d'accélération inutile), du mock_exam (Z6-AC10), et du plan d'étude exam. L'Exam enregistre notion_ids[] en plus de chapter_ids[] pour tracer le périmètre exact. Si l'élève ne touche à rien (accepte l'auto-scope), le comportement est identique à l'existant (100% du chapitre). Un bouton « Tout sélectionner / Tout désélectionner » est disponible par chapitre.

NOTE : L'auto-scope avec opt-out (tout coché par défaut, l'élève décoche ce qui n'est pas au programme) est le bon pattern UX pour un collégien. Le pattern inverse (opt-in, rien coché, l'élève doit tout cocher) serait trop fastidieux. La granularité par Notion est le juste milieu entre « tout le chapitre » (trop grossier) et « item par item » (trop fin, 25 checkboxes). 3-7 Notions par chapitre = 6-14 toggles pour 2 chapitres = décision en 30 secondes.

Z7-AC18 — Auto-suggestion des chapitres et notions lors de la création d'exam

Lot 0
GIVEN L'élève crée un nouvel Exam. Il sélectionne la matière « Histoire-Géo » et la date « 2026-03-20 ». Il a 4 chapitres actifs en Histoire-Géo : « Inégalités » (créé le 15/02), « Mondialisation » (créé le 01/03), « Urbanisation » (créé le 08/03), « Développement durable » (créé le 14/03).
WHEN L'écran de sélection des chapitres s'affiche.
THEN Le système propose un auto-scope intelligent basé sur : (1) Chapitres récents de la matière : les 4 chapitres actifs d'Histoire-Géo sont listés, triés du plus récent au plus ancien. (2) Pré-sélection heuristique : les chapitres créés dans les 6 dernières semaines avant la date d'exam sont pré-cochés (ici : « Urbanisation » et « Développement durable »). Les chapitres plus anciens sont affichés mais non cochés, avec mention « Créé il y a [N] semaines ». (3) Si un chapitre a déjà été couvert par un exam passé, il est marqué « Déjà au contrôle du [date] » pour éviter les doublons involontaires. (4) Si un chapitre a des pages ajoutées récemment (upload incrémental), il est signalé « Mis à jour le [date] — nouvelles pages ajoutées ». L'élève confirme ou ajuste la sélection. Après la sélection des chapitres, l'écran de sélection par Notion (Z7-AC17) s'affiche. Le parcours complet (matière → date → chapitres → notions → confirmer) prend < 90 secondes.

NOTE : L'heuristique « chapitres des 6 dernières semaines » reflète le rythme du collège français : une séquence dure typiquement 4-6 semaines, et un contrôle de fin de séquence couvre les chapitres de cette période. La mention « Déjà au contrôle du [date] » évite un piège courant : l'élève qui re-sélectionne un chapitre déjà testé et gaspille du temps de révision. Le signal « pages ajoutées récemment » aide l'élève à repérer les chapitres en cours qui ont du contenu frais.

Z7-AC19 — Vue « Angles morts » : contenu sans contrôle à venir

Lot 0
GIVEN L'élève a 8 chapitres actifs répartis sur 4 matières. 3 chapitres sont liés à des Exams à venir (dates futures). 5 chapitres n'ont aucun Exam à venir (dont 2 qui ont eu un exam passé, et 3 qui n'ont jamais été testés).
WHEN L'élève ouvre la vue « Angles morts » (accessible depuis le dashboard progression Z6-AC30, onglet ou filtre).
THEN La vue affiche les chapitres sans exam à venir, groupés par matière, chaque entrée montrant : (1) Nom du chapitre + matière. (2) Nombre de Notions et taux de maîtrise global. (3) Date du dernier contrôle lié (si existant) : « Dernier contrôle : 15/02 » ou « Jamais testé en contrôle ». (4) Temps écoulé depuis le dernier contrôle de la matière (pas juste du chapitre) : « Dernier contrôle d'Histoire-Géo : il y a 5 semaines ». (5) Un indicateur visuel de risque (vert/orange/rouge) basé sur : temps depuis dernier contrôle × volume de contenu non testé × taux de maîtrise faible. Les chapitres sont triés par risque décroissant. Un bouton « Créer un contrôle » est disponible pour chaque entrée, pré-rempli avec le chapitre. Un message contextuel en haut de la vue : « [N] chapitres n'ont pas de contrôle prévu. Vérifie avec ton prof si un contrôle est à venir ! » La vue est vide (avec message positif) si tous les chapitres ont un exam à venir.

NOTE : Les « angles morts » ne sont pas un bug — c'est souvent simplement que l'élève n'a pas encore reçu la date du prochain contrôle. Mais la vue sert deux objectifs : (1) rappeler à l'élève de demander au prof, et (2) permettre au système de maintenir un niveau de révision de fond sur ces chapitres (le daily les inclut via les items dues, mais le resserrement Z1-AC08 ne s'active pas sans date d'exam). La vue devient le point d'entrée naturel pour la prédiction d'interro surprise (Z7-AC20).

Z7-AC20 — Prédiction d'interro surprise : score de probabilité par matière

Lot 0
GIVEN L'élève a des cours de SVT le mardi et le vendredi. Historique des contrôles SVT : exam le 10/01, exam le 07/02, exam le 28/02. Nous sommes le 20/03 (3 semaines sans contrôle). L'élève a 2 chapitres SVT sans exam à venir, dont 1 avec des items FRAGILE.
WHEN L'EveningPlan du lundi soir est calculé (veille du cours de SVT mardi).
THEN Le système calcule un score d'interro surprise pour SVT, basé sur : (1) Fréquence historique des contrôles : 1 contrôle toutes les ~3.5 semaines en SVT (moyenne des intervalles 10/01→07/02 = 4 sem, 07/02→28/02 = 3 sem). (2) Temps écoulé depuis le dernier contrôle : 3 semaines (20/03 - 28/02). (3) Ratio temps/fréquence : 3/3.5 = 0.86 → probabilité croissante. (4) Volume non testé : 2 chapitres, ~15 items sans exam → facteur aggravant. Le score est affiché comme un signal qualitatif (pas un pourcentage, trop anxiogène) : 🟢 « Interro surprise peu probable » (ratio < 0.5), 🟡 « Interro surprise possible — reste prêt ! » (ratio 0.5–0.9), 🔴 « Attention, ça fait longtemps sans contrôle — interro surprise probable ! » (ratio > 0.9). Le signal est intégré dans : (a) le dashboard soirée la veille du cours (« Tu as SVT demain — 🟡 interro surprise possible »), (b) la notification pre_class (Z6-AC07) avec intensité adaptée, (c) la vue Angles morts (Z7-AC19) comme colonne supplémentaire. Le score n'est calculé que pour les matières avec ≥ 3 contrôles historiques (sinon données insuffisantes, pas de prédiction). Après un nouveau contrôle, le score se réinitialise. Le calcul ne nécessite aucun appel LLM — c'est une heuristique arithmétique sur les intervalles.

NOTE : La prédiction d'interro surprise est un « wow factor » qui positionne l'app comme un vrai coach et pas juste un outil de flashcards. L'élève qui reçoit « Attention, ça fait longtemps sans contrôle de SVT — prépare-toi ! » la veille d'un cours et qui a effectivement une interro le lendemain développe une confiance profonde dans l'app. Le choix du signal qualitatif (🟢🟡🔴) plutôt que « 73% de chances » est délibéré : un pourcentage serait soit ignoré soit source d'anxiété. Un signal en 3 niveaux est actionnable. L'heuristique est simple (intervalle moyen vs temps écoulé) mais étonnamment efficace car les profs ont des rythmes réguliers.

Z7-AC21 — Alerte croisée « notion fragile × jamais testée en contrôle »

Lot 0
GIVEN L'élève a le chapitre « Mondialisation » en Histoire-Géo avec 5 Notions. La Notion « Flux migratoires » (4 items) a 3 items FRAGILE et 1 UNKNOWN. Cette Notion n'a jamais été couverte par un Exam (aucun exam passé ou à venir ne référence les notion_ids correspondants). La Notion « Échanges commerciaux » (3 items) a 3 items SOLID — pas de risque.
WHEN Le système évalue les risques lors du calcul quotidien (même job que l'EveningPlan, Z7-AC01).
THEN Une alerte proactive est générée pour « Flux migratoires » car elle croise deux signaux de risque : (1) Maîtrise faible (≥ 50% items FRAGILE/UNKNOWN) ET (2) Jamais testée en contrôle (pas de lien avec un Exam passé ou futur). L'alerte est affichée : (a) Dans la vue chapitre, sous la Notion concernée : « ⚠️ Notion fragile et jamais au contrôle — entraîne-toi ! » avec bouton « Lancer un entraînement ciblé » → session ciblée sur les items de cette Notion uniquement (4 questions, gabarits difficulté 1-2). (b) Dans la vue Angles morts (Z7-AC19) : la Notion est mise en évidence en rouge. (c) Dans l'EveningPlan, si espace disponible (durée totale < 20 min) : suggestion optionnelle « +3 min : renforce "Flux migratoires" (notion fragile, jamais au contrôle) ». L'alerte disparaît quand la condition n'est plus remplie (maîtrise ≥ 50% OK/SOLID, ou Notion couverte par un exam). Le nombre max d'alertes actives simultanées est 3 (les plus critiques d'abord, par score de risque = % FRAGILE × ancienneté de la dernière révision). Pas de notification push pour ces alertes — elles sont in-app uniquement, pour éviter la surcharge.

NOTE : Le croisement « fragile × non testée » identifie le pire scénario pour l'élève : une notion qu'il maîtrise mal et qui pourrait tomber en interro surprise puisqu'elle n'a jamais été au contrôle. C'est le genre de signal qu'un bon répétiteur humain détecterait en feuilletant les copies et l'emploi du temps — l'app le fait automatiquement. La session ciblée par Notion (4 questions sur un sous-ensemble) est un nouveau mode de révision complémentaire au daily (qui pioche transversalement) : ici on attaque chirurgicalement le point faible.

Z7-AC22 — Bouton « S'avancer » : réviser les items des jours suivants

Lot 0
GIVEN L'élève ouvre l'app un samedi matin. Son daily du jour contient 8 items (10 min). Il sait que lundi et mardi soirs il aura entraînement (soirs indisponibles, Z6-AC46) ou beaucoup de devoirs.
WHEN L'élève tape sur « Je veux m'avancer » (bouton visible sur le dashboard sous le plan du jour, présent les weekends et jours sans contrainte horaire).
THEN Le système calcule les items qui seraient dues lundi et mardi (basé sur les next_due_at projetés + la composition 70/20/10). Ces items sont ajoutés au plan du jour comme bloc supplémentaire : « +12 items de lundi-mardi (~15 min) ». L'élève voit la durée totale avant de confirmer (ex : « Aujourd'hui : 25 min au lieu de 10 min »). Il peut choisir combien de jours d'avance il veut prendre (1, 2 ou 3 jours max — au-delà, l'espacement SRS perd son sens). Les items révisés en avance ont leur next_due_at recalculé normalement après la session (comme s'ils avaient été révisés le jour prévu). L'EveningPlan des jours suivants est automatiquement allégé : les items déjà vus ne sont pas reproposés. Si tous les items de lundi sont couverts, l'EveningPlan de lundi affiche « Rien à réviser ce soir — tu t'es avancé samedi ! ✓ ». Le bouton « S'avancer » n'est pas affiché si l'élève est en mode vacances (Z6-AC45 gère son propre rythme) ni les soirs de semaine classiques (pour éviter les sessions trop longues).

NOTE : S'avancer le weekend est un cas d'usage fréquent pour les collégiens sportifs ou ceux qui ont des semaines chargées. Le bouton explicite (vs « faire plus de sessions ») a deux avantages : (1) l'élève visualise l'impact sur sa semaine avant de commencer (« 25 min maintenant = 0 min lundi soir »), (2) le système sait que c'est de l'avance et ajuste les plans futurs en conséquence. La limite de 3 jours d'avance protège l'intégrité du SRS : réviser un item 5 jours trop tôt est pédagogiquement inutile (l'espacement est précisément calibré pour optimiser la rétention).

Z7-AC23 — Fiches de révision PDF pour heures d'étude (hors téléphone)

Lot 0
GIVEN L'élève a 2 chapitres actifs en Physique-Chimie avec 15 items dont 6 FRAGILE et 4 UNKNOWN. Il a une heure d'étude demain au collège où les téléphones sont interdits.
WHEN L'élève tape sur « Télécharger une fiche révision » (bouton disponible sur chaque chapitre et sur le dashboard, section « Outils »).
THEN Un PDF est généré contenant : (1) En-tête : matière, chapitre(s), date, nombre de questions. (2) Questions : les items les plus urgents (FRAGILE d'abord, puis UNKNOWN, puis OK dues), formatés en quiz papier. Chaque question a un numéro, un espace de réponse, et une indication de difficulté (★/★★/★★★). Les gabarits sont adaptés au papier : les MCQ conservent leurs options, les SHORT ont une ligne de réponse, les CLOZE ont des tirets, les NUMERIC ont un cadre « Valeur + Unité ». (3) Réponses : en dernière page (ou au verso si impression recto-verso), avec la réponse correcte + un indice mnémotechnique court pour chaque question. (4) Paramètres : nombre de questions configurable (défaut : 15, max : 30). Sélection par chapitre ou transversal (tous chapitres de la matière). Le PDF est généré côté serveur (pas de LLM — les questions sont déjà en cache, seul le formatage est nécessaire). Le téléchargement est loggé avec pdf_generated_at et item_ids[] inclus, pour le report ultérieur (Z7-AC24). Le PDF inclut un QR code en bas de page qui ouvre directement l'écran de report (Z7-AC24) dans l'app.

NOTE : L'heure d'étude est un créneau de révision perdu pour 100% des élèves qui utilisent une app mobile. En France, les téléphones sont interdits au collège (loi de 2018). La fiche PDF transforme ce temps mort en temps de révision actif. Le QR code pour le report des résultats réduit la friction du retour dans l'app. Le coût de génération est quasi nul (formatage de données existantes en PDF, pas d'appel LLM). C'est un différenciateur fort vs les apps concurrentes qui sont 100% mobile-dépendantes.

Z7-AC24 — Report des résultats papier (checklist post-étude)

Lot 0
GIVEN L'élève a utilisé une fiche PDF (Z7-AC23) pendant son heure d'étude. La fiche contenait 12 questions sur le chapitre Densité. Il rentre chez lui le soir.
WHEN L'élève ouvre l'app (notification proactive : « Tu as utilisé ta fiche Densité en étude ? Dis-moi comment ça s'est passé ! ») ou scanne le QR code de la fiche, ou tape sur « Reporter mes résultats » dans la section du chapitre.
THEN Un écran de checklist rapide s'affiche avec la liste des questions de la fiche (identifiées par item_ids[] du PDF loggé). Pour chaque question, l'élève coche ✓ (réussi) ou ✗ (raté). Pas de saisie de texte — uniquement des taps. Le temps de report est < 1 min pour 12 questions. À la validation : (1) Plafond de progression papier : les reports papier sont traités comme des réponses avec aide (même logique que Z1-AC21/Z1-AC24 hint_used = true). Les transitions UNKNOWN → FRAGILE et FRAGILE → OK sont autorisées. La transition OK → SOLID est bloquée — un report papier ne peut jamais faire passer un item en SOLID. Pour atteindre SOLID, l'élève doit répondre correctement en session interactive (vérification par le système). Le champ Attempt.source = 'paper_report' distingue ces résultats des sessions interactives. Raté → régression normale (Z1-AC05/06/07), sans atténuation. (2) Vérification croisée adaptative : après chaque report, 2-3 items reportés ✓ sont re-proposés en session interactive le soir même (pas optionnel). Si l'élève reporte ≥ 80% de réussite sur des items FRAGILE/UNKNOWN, le message non-culpabilisant s'affiche : « Super résultat ! On vérifiera quelques points ce soir pour consolider. » (3) Détection d'écart statistique : le système compare le taux de réussite papier et le taux de réussite interactif par matière, sur une fenêtre glissante de 30 jours. Si l'écart est significatif (taux papier − taux interactif > 30% ET ≥ 3 fiches reportées), le nombre d'items re-vérifiés en session augmente silencieusement : 2-3 → 5-6 items. Aucun message accusateur, aucune notification parent — juste plus de vérification interactive. Si l'écart se réduit sous 15% sur les 2 semaines suivantes, le cross-check revient à 2-3 items. (4) Statistiques : le report compte comme une session dans les stats (session_type = 'paper_report'). Le temps passé en étude est estimé (nombre de questions × 90s en moyenne) et affiché dans le débrief parent. Le dashboard parent distingue « temps en étude » et « temps en session » (les deux sont valorisés). (5) Expiration : le report est possible pendant 48h après la génération du PDF. Au-delà, les items sont re-proposés en session interactive normalement (le PDF est considéré comme non utilisé).

NOTE : Le plafond OK pour le papier applique le même principe que Z1-AC13 (plafond OK pour items non validés) et Z1-AC21/Z1-AC24 (demi-succès avec aide) : le canal papier est par nature non vérifiable, donc il mérite une confiance intermédiaire. L'élève progresse (UNKNOWN → OK) ce qui valorise son travail en étude, mais le dernier palier (SOLID) exige une preuve interactive. C'est un contrat implicite juste : « Je te fais confiance pour progresser, mais pour le diplôme final, montre-moi. » La détection d'écart statistique est le filet de sécurité contre le menteur systématique — elle n'accuse jamais (un écart peut avoir des causes légitimes : l'élève est plus concentré en étude qu'en session du soir), elle vérifie plus. Un élève honnête ne remarquera même pas la différence (2-3 vs 5-6 items vérifiés, c'est ~3 min de plus).

Z7-AC25 — Nudge bienveillant si session tardive (après 21h)

Lot 0
GIVEN L'élève ouvre l'app après 21h (user.late_threshold, défaut 21h, configurable). L'EveningPlan n'a pas encore été commencé (aucune étape en completed).
WHEN Le dashboard soirée s'affiche (Z7-AC02).
THEN Le message d'accueil est adapté : « Il est un peu tard — une session express pour l'essentiel, et au dodo ! » Le mode express (Z7-AC08) est pré-sélectionné (pas forcé — l'élève peut basculer en mode complet via un lien « Faire la session complète »). La durée cible express est réduite à 5-8 min. Si l'heure dépasse 22h (ou evening_window_end), le message change : « Il est tard ! Ton cerveau retient mieux quand tu dors bien. On reprend demain matin frais ? » Le plan propose uniquement les items FRAGILE les plus urgents (2-4 questions max, ~3 min). Après 22h30, si la session n'est pas commencée, le dashboard affiche : « Bonne nuit ! Tes révisions t'attendent demain. » Aucune session n'est proposée activement (l'élève peut quand même forcer le lancement via les paramètres). Le late_threshold est configurable par le parent dans les préférences (certains collégiens se couchent plus tôt ou plus tard). Les notifications push respectent le même seuil : aucune notification après late_threshold (déjà couvert implicitement par la fenêtre de soirée, mais ce AC rend le comportement explicite).

NOTE : Holz et al. (2012) montrent que la mémoire déclarative (vocabulaire, dates, définitions — le cœur du contenu collège) se consolide mieux quand l'étude a lieu en début de soirée plutôt que tard. Les adolescents ont un décalage circadien naturel qui les pousse à se coucher tard — l'app ne doit pas aggraver ce biais. 44-55% des collégiens rapportent une insuffisance de sommeil liée aux devoirs tardifs. Le nudge bienveillant (pas un blocage) respecte l'autonomie de l'élève tout en l'orientant vers le bon comportement. Le message « ton cerveau retient mieux quand tu dors bien » est factuel et éducatif — c'est du coaching, pas de la morale.

Z7-AC26 — Report des résultats papier : impact maîtrise et vérification croisée

Lot 0
GIVEN L'élève a utilisé une fiche PDF (Z7-AC23) pendant une heure d'étude (CDI, permanence, étude surveillée). Il rentre le soir et reporte ses résultats via la checklist (Z7-AC24). La fiche contenait 12 questions sur le chapitre « Densité ». L'élève reporte 10 ✓ et 2 ✗.
WHEN Le système traite le report et met à jour la maîtrise des items.
THEN (1) Plafond de progression papier : les reports ✓ sont traités comme des demi-succès (même mécanique que Z1-AC21/Z1-AC24 point B, hint_used = true). Les transitions UNKNOWN → FRAGILE et FRAGILE → OK sont autorisées. La transition OK → SOLID est bloquée — un report papier ne peut jamais faire passer un item en SOLID (canal non vérifiable). Le champ Attempt.source = 'paper_report' distingue ces résultats. Reports ✗ = régression standard (Z1-AC05/06/07), sans atténuation (l'élève a eu le courage d'admettre un échec — on respecte sa sincérité). (2) Session enregistrée : le report crée une Session de type paper_report avec les Attempt correspondants. Le temps estimé = nombre de questions × 90s. Affiché dans le débrief parent comme « temps en étude » (distingué de « temps en session interactive »). (3) Vérification croisée : après chaque report, 2-3 items reportés ✓ sont re-proposés en session interactive le soir même (intégrés dans le daily, pas une session séparée). Si l'élève reporte ≥ 80% ✓ sur des items FRAGILE/UNKNOWN, message non-culpabilisant : « Super résultat en étude ! On vérifie quelques points ce soir. » (4) Détection d'écart statistique : le système compare le taux de réussite papier vs interactif par matière, sur 30 jours glissants. Si l'écart est significatif (taux papier − taux interactif > 30% ET ≥ 3 fiches reportées), le nombre d'items re-vérifiés augmente silencieusement : 2-3 → 5-6 items. Aucun message accusateur. Si l'écart se réduit sous 15% en 2 semaines, retour à 2-3 items. (5) Expiration : le report est possible pendant 48h après génération du PDF. Au-delà, les items sont re-proposés en session interactive normalement. (6) Débrief : le débrief de session (Z1-AC15) affiche un variant adapté pour paper_report : « Tu as révisé 12 points en étude aujourd'hui — [10] réussis, [2] à revoir ce soir. » Le score ne contribue pas au score de session « classique » (les deux canaux sont reportés séparément).

NOTE : Le plafond OK pour le papier est le même principe que Z1-AC13 (plafond items non validés) : un canal non vérifiable mérite une confiance intermédiaire. L'élève progresse (UNKNOWN → OK, valorisation de l'effort en étude) mais le dernier palier (SOLID) exige une preuve interactive. La détection d'écart statistique est un filet de sécurité silencieux contre le menteur systématique — elle n'accuse jamais (un écart peut avoir des causes légitimes : l'élève est plus concentré en étude qu'en session du soir), elle vérifie plus. Un élève honnête ne remarquera même pas la différence.