diff --git a/docs/PROCEDURE_ESS_PARALLELE.md b/docs/PROCEDURE_ESS_PARALLELE.md
index 0088a29..466d856 100644
--- a/docs/PROCEDURE_ESS_PARALLELE.md
+++ b/docs/PROCEDURE_ESS_PARALLELE.md
@@ -237,9 +237,50 @@ onduleurs**, jamais à distance, et après la sauvegarde du §1.3.
 
 | Date/heure | Action | Valeur avant | Valeur après | Résultat du test §0.4 |
 |---|---|---|---|---|
-| | Consigne réseau GX | 4200 W | | |
-| | SOC minimal ESS | 40 % | | |
-| | (VEConfigure, si nécessaire) | | | |
+| 30/08 21:46 | Consigne réseau GX | 4200 W | **50 W** | à faire (plein soleil) |
+| 30/08 ~21:55 | Limite de charge (% de CCL) — *paramètre obsolète* | 95 % | **100 %** | remis au défaut |
+| 30/08 ~21:55 | Limite de décharge (% de DCL) — *paramètre obsolète* | 20 % | **100 %** | remis au défaut |
+| 30/08 22:0x | SOC minimal ESS | 40 % | **20 %** | ⚠ limite *active* encore à 40 % (BatteryLife) |
+| | (VEConfigure, si nécessaire) | | | non entamé |
+
+### Note sur l'épisode « paramètres obsolètes » (30/08)
+
+Les lignes « Limite de charge/décharge de la batterie (% de CCL / % de DCL) »
+de l'écran ESS ne sont **pas des limites de SOC** : ce sont des pourcentages des
+courants que la batterie déclare accepter et fournir (*Charge/Discharge Current
+Limit*). Portées à 95 % / 20 %, elles auraient plafonné la décharge à 20 % de
+150 A = **30 A ≈ 1,5 kW**, là où la maison avait tiré 73,7 A le soir même et
+108 A dans l'après-midi. Réseau ouvert — le régime habituel ici — la batterie
+n'aurait plus pu servir la maison ; réseau fermé, l'écart serait revenu au
+réseau, soit exactement la substitution qu'on cherche à supprimer.
+Victron les range lui-même sous « Paramètres obsolètes » : DVCC (`forced_on`
+avec une batterie managée en CAN-bus) en est le vrai propriétaire.
+**Valeur correcte : 100 % / 100 %.**
+
+### Note sur le SOC minimal et BatteryLife (30/08)
+
+`MinimumSocLimit` a été ramené de 40 % à **20 %**, pour en faire un filet de
+sécurité bas cohérent avec les seuils du contrôleur (plancher dur 22 %,
+hystérésis réseau ON à 20 %) au lieu d'un concurrent de la cible du matin
+(35 % en été).
+
+⚠️ **La limite qui agit réellement n'a pas suivi immédiatement** :
+`sensor.gx_device_active_soc_limit` reste à 40 %. Avec BatteryLife actif, le GX
+maintient une limite *dynamique* propre, qui monte de 5 % quand la batterie
+passe sous elle et ne redescend que de 5 % par jour de charge complète.
+L'historique le montre sans ambiguïté : 40 → 45 chaque nuit, 45 → 40 chaque
+jour, jamais en dessous de 40, sept jours durant.
+
+Deux options :
+1. **attendre** : la limite descendra 40 → 35 → 30 → 25 → 20 au rythme d'un
+   palier par journée de charge complète, soit environ quatre jours ;
+2. **basculer le mode ESS** sur « Optimisé (sans BatteryLife) » depuis l'écran
+   GX (ligne *Mode*, au-dessus de *État BatteryLife*) : la limite active devient
+   alors immédiatement égale au minimum réglé.
+
+L'option 2 est la plus cohérente avec la direction du projet — une limite
+dynamique cachée que rien ne lit est précisément le type d'acteur non lu qu'on
+est en train d'éliminer.
 
 ---