diff --git a/.gitea/workflows/vault.yaml b/.gitea/workflows/vault.yaml
index 3d0ba45..51fb1e1 100644
--- a/.gitea/workflows/vault.yaml
+++ b/.gitea/workflows/vault.yaml
@@ -2,12 +2,23 @@
 # template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
 name: Hashicorp Vault
 
-on: #[push,pull_request]
+# ⚠ Triggers écrits EN TOUTES LETTRES, sans ancre YAML (`&`/`*`) : une ancre
+# dans un trigger Gitea Actions fait taire push ET pull_request, en silence
+# (vécu sur arcodange/kadans, issues 113 → 117) — c'est probablement pourquoi
+# ce workflow ne partait qu'à la main.
+# Et `*.tfvars` compte AUTANT que `*.tf` : la liste des applications (donc les
+# rôles gitea_cicd_<app>) vit dans terraform.tfvars — l'oublier, c'est ajouter
+# une app sans jamais créer son rôle.
+on:
   workflow_dispatch: {}
-  push: &vaultPaths
+  push:
     paths:
       - 'hashicorp-vault/**/*.tf'
-  pull_request: *vaultPaths
+      - 'hashicorp-vault/**/*.tfvars'
+  pull_request:
+    paths:
+      - 'hashicorp-vault/**/*.tf'
+      - 'hashicorp-vault/**/*.tfvars'
 
 # cancel any previously-started, yet still active runs of this workflow on the same branch
 concurrency:
diff --git a/hashicorp-vault/iac/terraform.tfvars b/hashicorp-vault/iac/terraform.tfvars
index 80ea3f5..b0921e7 100644
--- a/hashicorp-vault/iac/terraform.tfvars
+++ b/hashicorp-vault/iac/terraform.tfvars
@@ -19,6 +19,10 @@ applications = [
     name                       = "plausible"
     service_account_namespaces = ["tools"]
   },
+  {
+    name                       = "minio"
+    service_account_namespaces = ["tools"]
+  },
   { name = "prospection" },
   { name = "kadans" },
 ]
diff --git a/minio/README.md b/minio/README.md
index 7b80ae0..d237c14 100644
--- a/minio/README.md
+++ b/minio/README.md
@@ -34,13 +34,21 @@ SA portant le nom de l'app : un seul SA, rien à réconcilier.
 
 ## Première mise en service
 
-1. **Appliquer l'IaC** — crée le rôle Vault et génère le mot de passe root :
-   workflow `MinIO` (déclenchable à la main), ou `tofu apply` dans `minio/iac`.
-2. **ArgoCD** synchronise l'application (déclarée dans `chart/values.yaml`).
-3. Vérifier : `kubectl -n tools get vaultstaticsecret minio` (secret matérialisé)
-   puis `kubectl -n tools get pods -l app=minio`.
+L'ordre compte, et il compte **deux fois** :
+
+1. **Workflow `Hashicorp Vault`** — MinIO doit d'abord figurer dans
+   `hashicorp-vault/iac/terraform.tfvars` (c'est fait) : c'est **là** que naît
+   le rôle CI `gitea_cicd_minio`, et non dans `minio/iac`. Sans cette étape,
+   le workflow MinIO échoue sur
+   `role "gitea_cicd_minio" could not be found` — il essaie de s'authentifier
+   avec un rôle que personne n'a encore créé.
+2. **Workflow `MinIO`** — applique `minio/iac` : rôle Kubernetes pour le Vault
+   Secrets Operator, et **génération** du mot de passe root dans
+   `kvv2/minio/config`.
+3. **ArgoCD** synchronise l'application (déclarée dans `chart/values.yaml`).
+4. Vérifier : `kubectl -n tools get vaultstaticsecret minio` (secret
+   matérialisé) puis `kubectl -n tools get pods -l app=minio`.
 
 > [!NOTE]
-> L'ordre compte : sans le secret `minio-config`, le pod ne démarre pas. C'est
-> voulu — mieux vaut un pod en attente qu'un MinIO ouvert avec des identifiants
-> par défaut.
+> Sans le secret `minio-config`, le pod ne démarre pas. C'est voulu — mieux
+> vaut un pod en attente qu'un MinIO ouvert avec des identifiants par défaut.