documente la capacité, la restauration et le redémarrage (étape 13)

Capacité mesurée sur 20 VM (docs/capacite.md), restauration complète du
portail réussie, retour automatique de tous les services après redémarrage.
Retire l'unité systemd orpheline de ProxySQL, rend fidèle au navigateur la
mesure du temps d'ouverture d'un lab (2,8 s), et regroupe la dette révélée.

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

docs/journal.md

@@ -525,3 +525,44 @@ HTTPS ne se résume pas au cadenas : le certificat prouve l'identité du site, H
 - Vérifié depuis le Mac : `/` → 302 vers `/status/syllabus` ; `/dashboard`, `/manage-status-page`, `/settings/general`, `/metrics`, `/socket.io/…`, `/api/push/…` → 404 ; `POST /api/status-page/syllabus` → 403 ; HTTP → 301 vers HTTPS. `/status/syllabus` → 404 renvoyé par Kuma lui-même (page pas encore créée), pas par le filtre.
 - Reste (Adam) : créer la page de statut `syllabus` dans Kuma, supprimer la sonde en double « syllabus ».
 - Page de statut créée par Adam (slug `syllabus`, publiée). Vérifié depuis le Mac par `https://status.syllabuslab.fr` : page, API, pulsations, scripts, CSS et icône en 200. Seul `/docker-latest-warning.js` est bloqué (404) : script que Kuma injecte dans ses images « historiques » `latest`/`1`, actif seulement sur `/setup`, inutile au public — et argument de plus pour figer l'image (dette).
+
+## 2026-10-09 — Étape 13 : tests de capacité et de résistance
+
+**Fait**
+
+- **Constats avant de tester** (valeurs par défaut de Nova lues dans son code installé, pas de mémoire) : `reserved_host_memory_mb = 512` (Nova se croyait libre de distribuer 31,5 Go alors que Kolla en occupe 15,5 : il aurait accepté ~41 VM et l'hôte aurait manqué de mémoire avant tout refus), `resume_guests_state_on_host_boot = false` (après un redémarrage, toutes les VM — dont le stock chaud — seraient restées éteintes), quota du projet à 10 instances (défaut OpenStack : une classe aurait été bloquée bien avant la capacité réelle).
+- **Surcharge Nova** versionnée (`kolla/config/nova/nova-compute.conf`, déposée par le rôle `kolla`) : reprise des VM au démarrage, réserve mémoire. **Rôle `openstack-projet`** : gabarit `eleve.petit` et quota (40/40/30 Go) rejouables.
+- **Test de capacité** (`openstack/tests/capacite.py`, en service systemd) : 20 VM lancées en même temps, puis repos, CPU à 100 %, mémoire chargée. Résultats et décisions : `docs/capacite.md`. **Capacité retenue par Adam : 22 VM** (Nova et portail alignés ; Placement confirme 16 993 Mo distribuables = 22 VM).
+- **Sauvegarde complétée** : la base du portail (`mariadb-dump --single-transaction`), son `.env` (APP_KEY) et `storage/app` n'étaient **pas sauvegardés** (la sauvegarde date de l'étape 3, le portail de l'étape 8). Le mot de passe MariaDB est lu dans le conteneur, jamais sur la ligne de commande de l'hôte.
+- **Test de restauration** (`/usr/local/sbin/syllabus-test-restauration`, chaque lundi 04:30, alerte `RestaurationNonTestee` au-delà de 8 jours) : télécharge, déchiffre, restaure la base dans un conteneur jetable, fait tourner le code du portail contre la copie, compare avec la production.
+- **Redémarrage du serveur** (accord d'Adam) avec relevé d'état avant/après (`/root/etat-serveur.sh`).
+- Unité systemd `kolla-proxysql-container` en échec depuis le 7 octobre (ProxySQL désactivé à l'étape 5, unité restée activée) : retirée par le rôle `kolla` (accord d'Adam), rangée dans `/root/unites-retirees/`. `systemctl --failed` : 0.
+
+**Problèmes rencontrés et solution**
+
+1. Le playbook `kolla` a perdu sa connexion SSH pendant une tâche longue (« Shared connection closed ») : ni bannissement fail2ban ni panne ; relancé, il est allé au bout. Les `kolla-ansible reconfigure` sont désormais lancés en service systemd (`systemd-run`), insensibles à une coupure SSH.
+2. **Mesure du temps d'ouverture trompeuse** : après le redémarrage, le parcours a donné 5,51 s (critère < 5 s). Décomposition : le script demandait les 3 jetons de console l'un après l'autre (≈ 1,1 s chacun) alors que le navigateur les demande en parallèle. Script corrigé ; 3 mesures réelles fidèles au navigateur : 2,80 s, 2,85 s, 2,85 s. Les 4,06 et 4,35 s des étapes 11 et 12 étaient donc pessimistes aussi.
+3. Ma boucle d'attente du retour des services ne sortait jamais (sous zsh, `set -- $s` ne découpe pas la chaîne) : les valeurs affichées montraient pourtant le retour complet ; boucle arrêtée, relevé fait à la main. Mon premier `diff` avant/après a échoué sur des droits (`sudo` ne s'applique pas aux substitutions de processus) : comparaison faite ligne à ligne.
+4. Premier « retour SSH » après la demande de redémarrage : faux positif (connexion établie juste avant l'arrêt effectif, uptime de 2 jours). Attente refaite sur l'uptime (< 10 min).
+5. Le projet `paillasse`, le compte de service et le gabarit avaient été créés à la main à l'étape 6 sans être codifiés (règle « tout est du code ») : gabarit et quota codifiés ; projet et compte notés en dette. La base d'OpenStack elle-même n'est pas sauvegardée : dette prioritaire.
+
+**Critère vérifié**
+
+- **Chiffres de capacité écrits** : `docs/capacite.md`. 20/20 VM démarrées sans erreur (prêtes en 53 s médiane, 75 s p95) ; ≈ 250 Mo par VM au repos, ≈ 600 Mo active ; 20 vCPU à 100 % → hôte à 89 %, commande de correction en 0,6 s.
+- **Restauration réussie** :
+  ```
+  quotidienne-20261009.tar.zst.age (108M)
+  APP_KEY restaurée identique à la production (valeur non affichée)
+  migrations dans la copie : 14 appliquées, 0 en attente
+  17 tables : copie = production pour chacune
+  == RESTAURATION RÉUSSIE
+  ```
+- **Tout est revenu seul après le redémarrage** (19:50 → SSH 19:53 → services Kolla et VM avant 20:01) : services, 46 unités Kolla, 49 conteneurs (0 en mauvaise santé), pare-feu, écoutes, réseau OpenStack, Nova/Neutron, 3 VM du stock relancées et dont l'agent invité répond, correcteur, Horizon, HTTPS, page de statut — identiques à l'état d'avant. Seule différence attendue : `f2b-table` (créée au premier bannissement). Parcours complet rejoué ensuite : « Pas encore réussi » 6/10 puis « Réussi » 10/10.
+
+**Comprendre**
+
+Un serveur qui « marche » n'est pas un serveur qui *revient* : trois valeurs par défaut raisonnables pour un cloud générique (VM éteintes après redémarrage, réserve mémoire minime, quota de 10 instances) auraient fait échouer une vraie classe, et aucune ne se voyait en usage normal. On ne les trouve qu'en provoquant la situation : charger le serveur, le redémarrer, restaurer une sauvegarde. C'est aussi vrai des sauvegardes : celle-ci « marchait » depuis l'étape 3, mais ne contenait pas la base du portail — seule une vraie restauration l'a montré. Enfin, une mesure dépend de la manière de mesurer : le même chemin a donné 5,5 s ou 2,8 s selon que le script imitait ou non le navigateur.
+
+**Suite**
+
+Étape 14 : pages légales et RGPD.