exportateur postgresql de chezlepro pose ; les voutes ne sont pas sur les forges

vault_pg_exportateur ajoute a la voute de Chezlepro (hors depot), role redeploye,
pg_up 1 : plus aucun critique. La voute a ete redeposee sur le runner. Deux
phrases qui disaient les voutes repliquees sur les forges sont corrigees.

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

CHANGELOG.md

@@ -1,5 +1,25 @@
 # CHANGELOG — Set-OPS
 
+## 2026-09-28 (5) — L'exportateur PostgreSQL de Chezlepro, et où vivent vraiment les voûtes
+
+**Le dernier critique de Chezlepro.** `obs-01!collecte` : Prometheus scrutait
+`data-sql-01:9187`, où rien n'écoutait. `serveur_postgresql` ne pose l'exportateur que si
+`vault_pg_exportateur` existe ; Technolibre l'avait, pas Chezlepro. Ajouté à sa voûte
+selon la procédure (copie, lecture par un tube et comptage : 32 clés, chiffrement vers un
+fichier neuf relu : 33 clés, les 32 d'origine identiques, puis remplacement). Rôle
+redéployé : exportateur actif, `pg_up 1`. Chezlepro n'a plus aucun critique.
+
+**Écart restant.** `vault.yml.example` promet « VIDE = … Prometheus ne dérive aucune
+cible » ; le gabarit de Prometheus dérive pourtant la cible de tout hôte du groupe, secret
+ou pas. Un écosystème sans exportateur verra donc sa collecte rouge — le signal est juste,
+la promesse ne l'est pas.
+
+**Où vivent les voûtes.** `sortir-les-cles-du-poste.md` et `exporter_cles.py` disaient les
+voûtes chiffrées répliquées sur les forges. Elles sont gitignorées : chacune vit sur le
+poste et sur le runner de son écosystème (copie chiffrée par `serveur_ops_tenant`). Le
+runner de Chezlepro portait donc la voûte d'avant ce changement ; redéposée, empreintes
+identiques. Les deux phrases sont corrigées.
+
 ## 2026-09-28 (4) — Une sonde posée sous condition n'est attendue que là où elle est posée
 
 **Ce que la fraîcheur a fait voir.** Chez les deux locataires, `obs-01!journaux-frontiere`

docs/sortir-les-cles-du-poste.md

@@ -6,7 +6,9 @@
 ## Ce qui est en jeu
 
 Le **code** de Set-OPS est répliqué **deux fois** : `eregion` et la forge du site. Les
-**voûtes chiffrées** y sont aussi.
+**voûtes chiffrées**, elles, n'y sont **pas** — elles sont gitignorées. Chacune vit sur
+ce poste et sur le runner de son écosystème, qui en reçoit une copie chiffrée par
+`serveur_ops_tenant`. *(Corrigé le 2026-09-28 : cette page les disait sur les forges.)*
 
 > **Ce chiffre était trois, et il a baissé sans que rien ne le signale.** Un coffre répliqué deux fois reste
 > solide — mais c'est la **redondance du génome** qui a diminué, pas le chiffrement, et

scripts/exporter_cles.py

@@ -3,8 +3,10 @@
 
 CE QUE CE SCRIPT PROTEGE, ET POURQUOI C'EST LE PLUS URGENT (mesure du 2026-09-05).
 
-Le CODE de Set-OPS est replique deux fois : `eregion` et la forge du site. Les
+Le CODE de Set-OPS est replique deux fois : `eregion` et la forge du site. Les VOUTES,
-voutes chiffrees y sont aussi — le coffre est solide.
+elles, n'y sont PAS : elles sont gitignorees. Chaque voute chiffree vit sur ce poste et
+sur le runner de son ecosysteme, qui en recoit une copie par `serveur_ops_tenant`
+(corrige le 2026-09-28 : cette ligne disait qu'elles etaient sur les forges).
 
 Les CLES qui ouvrent ce coffre, elles, vivent dans six fichiers de `~/.config`, 357
 octets au total, sans aucune copie ailleurs. S'y ajoutent les cles SSH par lesquelles on