permet aux élèves de rejoindre leur classe avec son code, et les fiches en lot

L'élève saisit le code de classe et son prénom, le prof accepte, l'élève
voit une seule fois son identifiant et son code. Aucun e-mail. Le prof
peut aussi régénérer les fiches de plusieurs élèves d'un coup. Procédure
pour prouver la copie de la clé des sauvegardes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/journal.md

@@ -612,3 +612,16 @@ Adam a ouvert `/ide` et transmis la console du navigateur, plus sa fiche INPI.
 - **Mentions légales complétées** d'après la fiche INPI : Adam Belkacemi, entrepreneur individuel (EI), nom commercial Esquisse Formation, SIREN 838 093 268, SIRET 838 093 268 00087, 30 rue Lorenzaccio, 38100 Grenoble. La date de naissance de la fiche n'est pas reprise. Restent à compléter : l'article « Disponibilité et responsabilité » des CGU, et un éventuel délégué à la protection des données.
 
 Vérifié en production : `/ide` 1 script en ligne, 0 erreur de syntaxe, `sandbox="allow-scripts"` ; Mulish déclarée par le portail ; aucun `@import` vers Google ; `/vendor/xterm/xterm.js` et `/vendor/codemirror/codemirror.js` en 200. 35 tests Pest.
+
+## 2026-10-09 — Accès des élèves : rejoindre la classe avec son code, fiches en lot
+
+**Question d'Adam** : comment l'élève obtient-il un accès après sa création ? Faut-il un e-mail automatique pour créer un mot de passe ?
+
+**Réponse et décision** : pas d'e-mail. Le CLAUDE.md l'interdit pour les mineurs (minimisation) et range l'invitation par e-mail en V2 (pour les majeurs) ; le serveur n'a pas non plus de service d'envoi (il faudrait un compte chez un prestataire, ouvert par Adam). Le parcours existant (identifiant + code secret + QR à usage unique, sur une fiche imprimable) restait valable, avec deux défauts : la fiche ne s'affichait qu'une fois, et le code de classe affiché ne servait à rien. Adam n'ayant pas répondu au choix proposé, j'ai construit les deux options sans dépendance extérieure :
+
+- **Rejoindre avec le code de classe** (façon n°1 du CLAUDE.md) : `/rejoindre` (code + prénom + nom facultatif, limité à 10 envois par minute) → demande visible sur la page de la classe (rafraîchie toute seule quand une demande arrive) → le prof accepte → le navigateur de l'élève affiche **une seule fois** son identifiant et son code, et le connecte. Le code en clair n'existe que dans la demande (chiffré par `APP_KEY`), supprimée à l'affichage ; une demande non traitée est supprimée au bout d'une heure (`model:prune`, tous les quarts d'heure). Seul le navigateur qui a envoyé la demande peut la suivre (jeton en session, empreinte SHA-256 en base). Classe archivée ou code faux : refus. Le prof projette le code ou un QR qui pré-remplit le code.
+- **Fiches en lot** : cases à cocher dans la liste des élèves, « Nouvelles fiches pour la sélection » (nouveaux codes et QR, anciens codes invalidés).
+- Lien « Rejoins ta classe avec son code » sur la page de connexion ; politique de confidentialité mise à jour (nouvelle donnée : la demande, au plus une heure).
+- 6 tests Pest (41 au total) ; vérifié en production : `/rejoindre` 200 avec CSP stricte, code faux refusé avec message, table créée, nettoyage planifié.
+
+**Clé des sauvegardes** : je ne peux ni ne dois voir la copie d'Adam. Procédure de preuve ajoutée au runbook des sauvegardes : un message chiffré sur le serveur avec la clé publique, que la copie doit déchiffrer sur le Mac. Fichier de test déposé sur le Bureau d'Adam. Corrigé aussi la commande de copie du runbook (un `scp` d'un fichier de root échouait).