docs(minio) — le raisonnement part dans l'ADR, le code garde ce qui protège

Les décisions de conception (qui déclare, qui détient, pourquoi les octets ne
passent pas par l'API) vivent désormais dans
`factory/doc/adr/20260726-stockage-objet-minio.md`.

Le code ne garde que ce qu'un relecteur ne peut pas deviner et qui l'empêcherait
de casser quelque chose : l'absence VOLONTAIRE de s3:GetObject/PutObject dans la
politique du provisionneur, l'absence VOLONTAIRE de basic-auth sur l'ingress
S3, le caractère inconditionnel de la règle Vault, et l'avertissement sur les
noms d'actions MinIO non éprouvés. Chaque fichier pointe l'ADR.

283 → 230 lignes sur minio/iac. tofu fmt propre, tofu validate réussi sur les
deux racines.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA

hashicorp-vault/iac/modules/app_policy/main.tf

@@ -36,10 +36,8 @@ data "vault_policy_document" "ops" {
     path         = "kvv1/google/credentials"
     capabilities = ["read"]
   }
-  # Provisionneur MinIO : permet à l'app de créer SES buckets et SON compte de
-  # service depuis son propre dépôt (module tools//minio/iac/modules/minio_app),
-  # sans qu'on lui confie le root de MinIO. Ce compte ne peut QUE provisionner —
-  # aucun droit de lecture ni d'écriture sur les objets.
+  # Provisionneur MinIO — l'app crée ses buckets depuis son dépôt sans le root.
+  # ADR : factory/doc/adr/20260726-stockage-objet-minio.md
   rule {
     path         = "kvv2/data/minio/provisioner"
     capabilities = ["read"]
@@ -187,27 +185,16 @@ data "vault_policy_document" "app" {
     path         = "postgres/creds/${local.name}*"
     capabilities = ["read"]
   }
-  # Identifiants de SON compte de service MinIO, provisionné par le pipeline
-  # `minio` (tools/minio/iac/consumers.tf) dans l'espace Vault de MinIO.
-  #
-  # INCONDITIONNEL, et c'est voulu : le chemin porte le nom de l'app, donc cette
-  # règle ne peut jamais exposer que ses PROPRES clés. Une app qui ne stocke rien
-  # lit un chemin qui n'existe pas — une règle inerte, pas un privilège.
-  #
-  # Pourquoi ici plutôt que dans `kv_read_paths` de chaque app : savoir lire ses
-  # propres identifiants de stockage est une propriété de la PLATEFORME, pas une
-  # exception par application. `kv_read_paths` est la trappe pour un secret
-  # appartenant à une AUTRE app (les creds GCS de Longhorn pour l'ERP) ; y ranger
-  # un motif standard le rendrait invisible et obligerait à le redéclarer partout.
-  # Conséquence pratique : déclarer un consommateur MinIO se fait à UN seul
-  # endroit — `var.consumers` du pipeline minio. Aucune synchronisation à tenir.
+  # Ses identifiants MinIO. INCONDITIONNEL : le chemin porte le nom de l'app,
+  # donc la règle ne peut exposer que ses propres clés ; une app sans stockage
+  # lit un chemin qui n'existe pas.
+  # ADR : factory/doc/adr/20260726-stockage-objet-minio.md
   rule {
     path         = "kvv2/data/minio/${local.name}/*"
     capabilities = ["read", "list"]
   }
   rule {
-    # Le secret est écrit à `kvv2/minio/<app>` (sans sous-chemin) : la règle
-    # ci-dessus couvre les descendants, celle-ci le document lui-même.
+    # Le document lui-même (la règle ci-dessus ne couvre que ses descendants).
     path         = "kvv2/data/minio/${local.name}"
     capabilities = ["read", "list"]
   }
@@ -237,8 +224,7 @@ data "vault_policy_document" "app_non_prod" {
     path         = "postgres/creds/${each.key}*"
     capabilities = ["read"]
   }
-  # Même règle qu'en prod (voir le commentaire de vault_policy_document.app) :
-  # chaque instance lit les identifiants MinIO portant SON nom.
+  # Idem prod : chaque instance lit les identifiants MinIO portant SON nom.
   rule {
     path         = "kvv2/data/minio/${each.key}/*"
     capabilities = ["read", "list"]