genome : quatre miroirs vivants, et le gabarit remis en phase

Les deux depots prives sont miroites via un jeton de lecture seule
(vault_miroir_amont). Ils restent lisibles sur la forge de patient 0 : c'est
ainsi que son poste les clone, en anonyme, sans detenir de justificatif.

Le gabarit de voute reclamait encore proxmox_api_token_id/secret d'un tenant qui
ne doit pas les detenir : depuis la separation des voutes, le jeton du cluster
appartient a l'hebergeur, et proxmox_api.voute() lui donne raison quand les deux
portent la cle. Un jeton pose dans le tenant serait ignore.

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

README.md

@@ -72,13 +72,17 @@ Les dépôts vivent sous l'organisation `genome` :
 |---|---|
 | `set-ops-public` | **oui** — toutes les 8 h |
 | `ops-patient0` | **oui** — toutes les 8 h |
-| `site-chezlepro` | non — figé au poussage |
-| `set-ops-modeles` | non — figé au poussage |
+| `site-chezlepro` | **oui** — toutes les 8 h, authentifié |
+| `set-ops-modeles` | **oui** — toutes les 8 h, authentifié |
 | `ops-chezlepro` | non, et privé — le plan d'un tenant voisin, sans usage ici |
 
-Les deux miroirs suivent `forge.alliance-boreale.ca`. Les trois autres attendent un jeton
-amont en **lecture seule** : un jeton capable d'écrire chez le parent inverserait le sens
-de la filiation, et ne sera pas posé ici.
+Les quatre miroirs suivent `forge.alliance-boreale.ca`. Les deux dépôts privés sont lus
+par un jeton de **lecture seule** (`vault_miroir_amont`, portée unique
+`read:repository`) : un jeton capable d'écrire chez le parent inverserait le sens de la
+filiation — l'enfant pourrait réécrire le génome dont il est issu.
+
+Les quatre restent **lisibles** sur la forge de patient 0, et c'est ainsi que son poste
+d'exploitation les clone : en anonyme, sans détenir aucun justificatif.
 
 L'étiquette signée `v2026.08.21` a traversé le miroir intacte — la provenance reste
 vérifiable depuis l'enfant.
@@ -139,7 +143,6 @@ ses VLAN n'auraient existé nulle part.
 
 ## Ce qui reste devant
 
-- [ ] **Les trois miroirs privés**, dès qu'un jeton amont en lecture seule existe.
 - [ ] **Décider où il vit.** Sur `asgard`, la perte du cluster emporte patient 0 *et*
       Chezlepro d'un coup. Ailleurs, la famille survit à la perte du cluster. Le
       déménagement tient en quatre valeurs (`group_vars/proxmox.yml`) et un symlink.

inventories/production/group_vars/all/vault.yml.example

@@ -43,9 +43,16 @@ vault_sysadmin_amorcage: ""                     # role amorcage_acces (playbook
 # Ces deux-la ne commencent pas par `vault_` et echappent donc au reperage automatique :
 # c'est P18 qui les exige nommement. Ils ouvrent l'API Proxmox pour cloner les VM.
 #
-# A CREER DANS PROXMOX, propre a patient 0 : Datacenter > Permissions > API Tokens.
-# Un jeton PAR TENANT, revocable seul — recopier celui d'un autre tenant reviendrait a
-# leur donner la meme clef, et a ne plus pouvoir en retirer un sans retirer l'autre.
-# Les poser ensuite : ansible-vault edit inventories/production/group_vars/all/vault.yml
-proxmox_api_token_id: ""
-proxmox_api_token_secret: ""
+# LES JETONS PROXMOX NE SONT PLUS ICI (separation des voutes, 2026-08-22).
+#
+# Le jeton d'API du cluster appartient a l'HEBERGEUR, pas a l'organisation hebergee. Il
+# vit desormais dans la voute du site — `SITE-Chezlepro/underlay.vault.yml` — avec la cle
+# de la frontiere. Recopie dans la voute de chaque tenant, il ne pouvait plus etre revoque
+# isolement : retirer l'acces d'un locataire revenait a le retirer a tous.
+#
+# `proxmox_api.voute()` lit la voute du tenant PUIS celle de l'underlay, et c'est celle de
+# l'hebergeur qui fait foi quand les deux portent la cle. Un jeton pose ici serait donc
+# ignore — mieux vaut ne pas le poser du tout que croire qu'il sert.
+#
+# Constate le 2026-08-23 : ce gabarit reclamait encore `proxmox_api_token_id` et
+# `proxmox_api_token_secret` d'un tenant qui ne doit pas les detenir.