doc/runbooks/new-web-app/09-service-compagnon.md

@@ -82,7 +82,7 @@ Le host DB reste **`pgbouncer.tools`**, base = celle du primaire ([étape 4](04-
 >   name: kadans               # ou « auth » ; l'important est spec.kubernetes.*
 >   namespace: {{ .Release.Namespace }}
 > spec:
->   vaultConnectionRef: default        # VaultConnection cluster-wide (VSO)
+>   # PAS de vaultConnectionRef → VSO retombe sur sa connexion globale (comme erp/webapp).
 >   method: kubernetes
 >   mount: kubernetes
 >   kubernetes:
@@ -93,6 +93,9 @@ Le host DB reste **`pgbouncer.tools`**, base = celle du primaire ([étape 4](04-
 >
 > C'est la seule raison pour laquelle le SA et le rôle du VaultAuth ne portent **pas** le nom du service qui le déploie. Ne crée **pas** un second SA `kadans-api` : le rôle K8s Vault `kadans` n'accepte que le SA `kadans`.
 
+> [!WARNING]
+> **N'écris PAS `vaultConnectionRef: default` dans un namespace applicatif.** VSO résout `vaultConnectionRef` **dans le namespace du CR** — or la VaultConnection `default` n'existe que dans le namespace **`tools`**. La nommer explicitement ailleurs fait chercher `<ns>/default` (inexistant) : le `VaultDynamicSecret` reste bloqué sur `VaultConnection "default" not found`, le Secret n'est jamais matérialisé, et le pod tourne en `CreateContainerConfigError`. Les apps hors `tools` (erp, webapp) **omettent** ce champ et laissent VSO utiliser sa `defaultVaultConnection`. (crowdsec/plausible peuvent l'écrire car ils vivent **dans** `tools`.)
+
 ## Carte
 
 ```mermaid