diff --git a/TEST_SCENARIOS.md b/TEST_SCENARIOS.md
index d098f6f..4ea2180 100644
--- a/TEST_SCENARIOS.md
+++ b/TEST_SCENARIOS.md
@@ -349,6 +349,17 @@ BuildAssets pour le JS.
 - **Historique** : `unlockMode` n'existait que dans `localStorage` — vidé à **chaque** lancement, le port éphémère changeant l'origine — et dans `settings_json`, illisible avant d'être connecté. Au démarrage à froid l'écran d'auth retombait donc toujours sur `'pw'`, alors que le blob PIN était bien présent. Écrit désormais aussi en pref DPAPI (`Bridge.setPref`) et relu par `showAuth`, comme `rememberedUsername`. **Le réglage est device-local par nature** (le blob PIN est lié à ce Windows) : il reste dans `settings_json` pour l'historique, mais c'est la copie DPAPI qui fait autorité au boot.
 - **Auto-correction** : si la pref dit `pin` alors que le blob n'existe plus, `applyAuthScreenMode` force `pw` — pas de verrouillage possible.
 
+### E9 · aucun secret au repos dans la mémoire du renderer ✅
+Contrôle par dump mémoire, à refaire après toute modification touchant les prefs
+ou le déchiffrement.
+- **Mise en scène** : rebuild complet → lancer → **Quick Unlock** → **ne rien ouvrir** (aucune entrée, aucun réglage) → dumper le processus.
+- **Quel processus** : le *renderer*, pas le plus gros. Le Gestionnaire des tâches le nomme d'après l'onglet — « **WebView2 : Vault** » ; dans Process Explorer, ajouter la colonne *Command Line* et chercher `--type=renderer`. Le processus GPU est souvent 10× plus volumineux et ne contient **aucun** JavaScript : un scan qui n'y trouve rien ne prouve rien.
+- **Témoin de validité** : `soState` doit apparaître (~120 en UTF-16). À 0, ce n'est pas le renderer et le test est nul.
+- **ATTENDU** : `this_is_password` (mot de passe d'entrée) à **0** — le déchiffrement est à la demande — et le mot de passe d'auto-backup à **0**. Le **nom** de la pref (`autoBackupPwd`) apparaît, c'est un littéral du code source, pas sa valeur.
+- **Historique** : le mot de passe d'auto-backup était présent en clair dans cette exact mise en scène, visible dans `Bridge.onPrefResult("autoBackupPwd","…")` **et** dans les tampons du protocole DevTools — donc deux processus — et il **survivait au verrouillage automatique** qui efface pourtant la clé du coffre. Cause : `loadAutoBackupConfig` / `loadSyncConfig` récupéraient les secrets alors que l'interface n'a besoin que de savoir s'ils existent. Voir `prefs/has`.
+- **Limite assumée** : après un backup ou un sync **réellement exécuté**, le secret est de nouveau en mémoire — il faut bien le passer à la fonction de chiffrement. Ce qui est supprimé, c'est sa présence permanente sans qu'aucune opération ne l'ait demandée.
+- **Après le test** : supprimer les dumps. Ils contiennent des secrets en clair, sans chiffrement.
+
 ### E5 · la clé du coffre n'est plus en clair dans le web storage
 - **ACTION** : coffre déverrouillé → console WebView2 :
   `sessionStorage.getItem('cryptoKey')`.