rotation : vault_keycloak_admin, et la contrainte d'ordre

Ce compte est le moyen de se changer lui-meme : regenerer la voute d'abord
l'aurait rendu inapplicable — plus rien n'aurait pu s'authentifier pour poser la
nouvelle valeur. L'ordre est inverse : s'authentifier avec l'actuelle, poser la
nouvelle, verifier, PUIS ecrire la voute.

C'est une procedure, pas un redeploiement. Meme contrainte pour
`vault_openldap_admin`, qui reste a faire. Consigne au runbook §6.7, avec le
rappel qu'une verification n'est pas un message de succes.

Verifie : admin (voute) OK, groupe sysadmin et role grafana-admin intacts,
rejeu a changed=0.

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

CHANGELOG.md

@@ -2,6 +2,26 @@
 
 ## 2026-08-06 — le chemin nord-sud devient dérivable
 
+### `vault_keycloak_admin` : le secret qui est la clé de son propre changement
+
+Rotation faite, chaîne d'identité intacte (groupe, membre, rôle), rejeu à `changed=0`.
+
+**L'ordre n'est pas indifférent, et c'est le point à retenir.** Ce compte est le moyen de se
+changer lui-même : régénérer la voûte d'abord l'aurait rendu inapplicable — plus rien n'aurait
+pu s'authentifier pour poser la nouvelle valeur.
+
+```
+1. s'authentifier avec la valeur ACTUELLE
+2. poser la nouvelle dans Keycloak
+3. vérifier qu'elle fonctionne
+4. seulement alors, écrire la voûte
+```
+
+C'est une **procédure**, pas un redéploiement — et la même contrainte vaut pour
+`vault_openldap_admin`, qui reste à faire. Consigné au runbook (§6.7), avec le rappel qu'une
+vérification n'est pas un message de succès.
+
+
 ### La rotation des comptes de secours devient possible — elle ne l'était pas
 
 Le runbook §6.6 promettait de régénérer les comptes de secours ; **le code ne savait pas le

docs/autorisation.md

@@ -194,6 +194,31 @@ dépendent ni de Keycloak, ni de l'annuaire. C'est le sens de D-40.
    déploiement y a eu accès. Les régénérer transfère réellement le contrôle.
 3. **Le mot de passe de la voûte** elle-même, si le dépôt change de mains.
 
+### 6.7 Faire tourner un secret : l'ordre n'est pas indifférent
+
+**Les comptes de secours des services** (`vault_grafana_admin`, `vault_forgejo_admin`,
+`vault_nextcloud_admin`) se régénèrent en voûte, puis un redéploiement les applique. Les rôles
+savent désormais *changer* un mot de passe existant, pas seulement le créer.
+
+**Le compte d'administration de Keycloak est différent : il est le moyen de se changer
+lui-même.** Régénérer la voûte d'abord le rendrait inapplicable — plus rien ne pourrait
+s'authentifier pour poser la nouvelle valeur. L'ordre est donc inversé :
+
+```
+1. s'authentifier avec la valeur ACTUELLE
+2. poser la nouvelle valeur dans Keycloak
+3. vérifier que la nouvelle fonctionne
+4. seulement alors, écrire la voûte
+```
+
+C'est une **procédure**, pas un redéploiement. La même contrainte vaut pour tout secret qui
+est aussi la clé de son propre changement — `vault_openldap_admin` en est un.
+
+**Et une vérification n'est pas un message de succès.** `grafana-cli` annonçait
+« Admin password changed successfully » en écrivant dans une base qui n'était pas celle du
+serveur. Ce qui l'a démasqué est l'**état** — le champ `updated` du compte, inchangé. Après
+toute rotation, s'authentifier réellement avec la nouvelle valeur.
+
 ## 7. Ce que ce document ne couvre pas
 
 **La gestion courante des comptes.** Créer, suspendre, réaffecter : c'est le travail du