doc : l'effet du rasage sur le jeton — et la sauvegarde vide qu'il a revelee

Consigner une consequence connue (raser l'hote openldap detruit l'annuaire, donc
le compte sysadmin est recree depuis la voute et le changement force est rearme —
mesure : pwdReset TRUE) a fait apparaitre la perte reelle : par le §2 les
appartenances ne sont JAMAIS reconciliees, donc tout ce que l'exploitant a
construit est detruit et ne sera pas recree.

En cherchant ou pointer pour la restauration, mesure sur les 14 hotes :
  - 11 hotes : setops-sauvegarde.service en echec chaque nuit, nothing to backup
  - infra-pki-01, obs-01, backup-01 : aucune sauvegarde deployee
    (et infra-pki-01 porte les cles de l'AC)

client_backup_jobs vaut [] par defaut et rien ne le surcharge dans l'instance.
Aucune donnee de cet ecosysteme n'est sauvegardee.

Le defaut n'est PAS corrige ici : il est rendu visible, avec la sortie manuelle
de l'annuaire en attendant. Une unite en echec qui n'alerte personne est le
second defaut a traiter.

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

CHANGELOG.md

@@ -1,5 +1,35 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-11 — En consignant l'effet du rasage, la sauvegarde s'est révélée vide
+
+Il s'agissait d'écrire une conséquence connue : raser l'hôte qui porte `openldap` détruit
+l'annuaire, donc le compte `sysadmin` est recréé depuis le jeton de la voûte et le
+changement forcé est réarmé. Mesuré après le rasage de `idm-01` : `pwdReset: TRUE`, et le
+mot de passe choisi par l'exploitant n'existe plus.
+
+La perte réelle est ailleurs, et le §2 la rendait prévisible : les appartenances ne sont
+**jamais réconciliées**. Set-OPS crée *un* compte. Tout ce que l'exploitant a construit
+depuis est détruit et ne sera pas recréé — contrepartie exacte du régime qui protège ces
+décisions du prochain `make deployer`.
+
+### Le contrôle qui devait rattraper ça ne fonctionne pas
+
+En cherchant où pointer pour la restauration, mesure sur les 14 hôtes :
+
+| Hôtes | État |
+|---|---|
+| 11 (dont `idm-01`, `data-sql-01`, `forge-01`, `collab-01`) | `setops-sauvegarde.service` **en échec chaque nuit** — `Fatal: nothing to backup` |
+| `infra-pki-01`, `obs-01`, `backup-01` | **aucune sauvegarde déployée** — et `infra-pki-01` porte les clés de l'AC |
+
+`client_backup_jobs` vaut `[]` par défaut et **rien ne le surcharge** dans l'instance : le
+timer tourne, restic initialise son dépôt, puis échoue faute de source. **Aucune donnée de
+cet écosystème n'est sauvegardée.** Vraisemblablement une victime de la reconstruction
+from-zero — les déclarations par nœud n'ont pas été redéclarées dans l'instance régénérée.
+
+Consigné tel que mesuré dans `autorisation.md` §3.1, avec la sortie manuelle de l'annuaire
+en attendant la correction. **Le défaut n'est pas corrigé par ce commit** : il est rendu
+visible, et une unité en échec qui n'alerte personne est le second défaut à traiter.
+
 ## 2026-08-11 — L'ancre Keycloak existe (et la commande que j'avais donnée ne prouvait rien)
 
 La vérification de signature était en place, mais elle ne prouvait que « la même clé

docs/autorisation.md

@@ -60,6 +60,43 @@ voûte, **changement forcé à la première ouverture** : c'est un jeton d'amor
 unique. Sans ce changement, l'auteur du déploiement connaîtrait le mot de passe du
 sysadmin — ce qui contredit « une identité, une personne ».
 
+### 3.1 Raser un hôte d'identité réarme le jeton — et détruit tout le reste
+
+Le « one-shot » tient **tant que l'annuaire vit**. `make raser` sur l'hôte qui porte
+`openldap` (dérivé : `applications.openldap.hote`) détruit `ou=people` et `ou=groups` avec
+la VM.
+
+La condition étant l'**existence** et non la conformité, le redéploiement retrouve un compte
+absent et le recrée. Mesuré le 2026-08-11, après rasage de `idm-01` :
+
+```
+dn: uid=sysadmin,ou=people,dc=chezlepro,dc=internal
+pwdReset: TRUE
+```
+
+Le jeton d'amorçage de la voûte redevient donc la valeur en vigueur, et le changement forcé
+est réarmé. **Le mot de passe que l'exploitant avait choisi n'existe plus.**
+
+**Ce n'est pas la perte principale.** Par le §2, les appartenances ne sont *jamais*
+réconciliées : Set-OPS crée **un** compte, et rien d'autre. Tout compte créé depuis, toute
+appartenance à un groupe, toute promotion décidée en exploitation sont détruits — et **ne
+seront pas recréés**. Le code ne peut pas reconstruire ce qu'il a délibérément choisi de ne
+pas posséder. C'est la contrepartie exacte du régime qui protège ces décisions du prochain
+`make deployer`.
+
+> **Mesure du 2026-08-11 — il n'y a rien à restaurer.** `client_backup_jobs` vaut `[]` par
+> défaut et rien ne le surcharge dans l'instance. Sur 11 hôtes, `setops-sauvegarde.service`
+> échoue chaque nuit (`Fatal: nothing to backup`) ; sur `infra-pki-01`, `obs-01` et
+> `backup-01`, aucune sauvegarde n'est déployée — et `infra-pki-01` porte les clés de l'AC.
+> **Tant que ce défaut n'est pas corrigé, raser un hôte d'identité est irréversible.**
+
+Avant de raser un hôte d'identité, sortir l'annuaire à la main :
+
+```
+ansible <hote_openldap> -m shell -a "slapcat -b dc=<domaine> > /tmp/annuaire.ldif" -b
+ansible <hote_openldap> -m fetch -a "src=/tmp/annuaire.ldif dest=./ flat=yes" -b
+```
+
 ## 4. Où vivent les habilitations : LDAP, pas Keycloak
 
 **Les groupes LDAP sont la source unique.** Keycloak les *projette* en rôles pour le web ;