diff --git a/common/PROTOCOL-INFRA.md b/common/PROTOCOL-INFRA.md
index 24e87d2..dd9cf00 100644
--- a/common/PROTOCOL-INFRA.md
+++ b/common/PROTOCOL-INFRA.md
@@ -468,3 +468,15 @@ Détail complet : `common/piege-virtual-key-nabil-key-bifrost-hermes-20260904.md
 **Fix** : `hermes cron edit veille-ia-nexum-4ee61494 --model "" --provider ""` pour retirer le pin et faire heriter le job du `model.default` de config.yaml (custom -> bifrost-proxy -> mimo-v2.5). Verifie par appel direct `curl` vers `http://bifrost-proxy/v1/chat/completions` depuis le conteneur : HTTP 200, `resolved_model_used: mimo-v2.5` via provider `opencode` (donc bifrost-proxy actif et sain).
 
 **REFLEXE** : tout job cron / profil Hermes avec un `model`/`provider` pin explicite qui pointe `opencode-go` EN DIRECT (au lieu de `custom` + `base_url: http://bifrost-proxy/v1`) perd l'injection du header de session et tombe silencieusement dans la chaine de fallback jusqu'a DeepSeek/OpenRouter -- sans erreur remontee a l'utilisateur puisque le fallback reussit techniquement. Auditer systematiquement tout pin `provider=opencode-go` au niveau job/profil (ex: `hermes cron list` puis verifier chaque job avec model/provider non-null) : soit le retirer (heriter de config.yaml), soit le reecrire en `provider=custom` + `base_url=http://bifrost-proxy/v1`. Ticket infra-2026-09-037. Detail : common/veille-cron-pin-bypass-bifrost-20260910.md.
+
+
+## Preuve verifiable obligatoire pour toute sauvegarde annoncee dans un ticket — decouvert le 14/09/2026
+
+Decouvert lors de l'audit du ticket infra-2026-09-051 (mise a jour NAS n8n/gitea/vaultwarden/crowdsec/portainer) : le rapport d'execution de Gemini annoncait un "Dump Postgres 218,6 Mo" comme sauvegarde prealable de n8n, sans qu'aucune commande ni sortie ne l'accompagne dans le rapport — a la difference des 4 autres sauvegardes du meme ticket, toutes appuyees par une preuve reelle. Recherche exhaustive sur le NAS entier (racine, /volume1/docker, volumes Docker, conteneur concerne) : le fichier n'existait nulle part. Corrige a posteriori par Claude (nouveau dump pris et integrite verifiee), mais la fenetre de restauration pre-update exacte etait deja irrecuperable au moment de l'audit.
+
+**Regle desormais obligatoire pour tout ticket impliquant une ou plusieurs sauvegardes avant execution** (a inclure systematiquement dans le brief du ticket, quel que soit l'agent assigne) :
+- Chaque sauvegarde annoncee dans le rapport final doit etre accompagnee, dans le rapport lui-meme, d'une preuve verifiable : sortie de `ls -la` (chemin + taille reelle) et, pour les backups critiques (bases de donnees), une verification d'integrite (ex. `pg_restore -l` pour un dump Postgres, `unzip -l`/`tar -tzf` pour une archive).
+- Une ligne de tableau de synthese mentionnant une taille sans commande/sortie associee n'est PAS une preuve d'execution et ne doit pas suffire a faire passer un ticket en "en attente d'audit" ou a le cloturer.
+- Cote audit (Claude) : avant de valider un ticket avec sauvegardes, verifier la presence reelle sur disque de CHAQUE fichier annonce (taille comparee au chiffre du rapport), pas seulement lire le texte du rapport — meme logique que la regle "ne jamais se fier a une seule source non verifiee" qui a motive le ticket 051 lui-meme (faux positif n8n dans veille-versions-stack).
+
+Detail complet de l'incident et de l'audit : common/veille-versions-stack.md (section 5) et NyoraNote "Audit ticket infra-2026-09-051 : backup Postgres n8n annonce mais introuvable, corrige". Ticket correctif : infra-2026-09-052.