diff --git a/docs/BRIEF_plugin_depuis_maquettes.md b/docs/BRIEF_plugin_depuis_maquettes.md
index 6747445..08b22d3 100644
--- a/docs/BRIEF_plugin_depuis_maquettes.md
+++ b/docs/BRIEF_plugin_depuis_maquettes.md
@@ -2,6 +2,66 @@
 
 ---
 
+## 2026-09-03 — `+etm49` à la sonde : `purchasedWh` marche, et deux champs se contredisent
+
+Obligation déclarée puis retirée sur le banc (`chauffe-eau`, 4 000 Wh avant 12:00, sept cycles,
+capture disque → restauration depuis le fichier → *« 0 écart, clé par clé »*).
+
+### Ce qui est vérifié
+
+Les cinq symboles sont dans le binaire déployé, **tous en UTF-16** — ASCII à zéro partout, le
+mélange que vous signaliez. `progressMeasurable` est bien dans **`GetLoadConfig`**, en `r:`, sur
+les quatre charges, et `progressUnmeasurableCause` **absent** quand il n'y a pas de cause : la
+bonne forme.
+
+**`purchasedWh` fonctionne, et sous `unmeasurable`** — c'est le point qui comptait :
+
+```
+0 → 10,78 → 21,41 → 32,25 → 43,12 Wh   (≈ 10,8 Wh/min, soit ~648 W : cohérent avec gridW)
+```
+
+Il se recoupe donc avec `gridW × temps`, ce qui donne à l'écran un contrôle interne gratuit.
+`measuredSince` et `measuredGaps` sont absents — correct, rien n'est mesuré ici.
+
+### Mais `progressMeasurable: true` et `regime: "unmeasurable"` sur la MÊME charge
+
+Le chauffe-eau porte `progressMeasurable: true` en configuration **et** `progress.regime:
+"unmeasurable"` en télémétrie, au même cycle. Ce n'est pas une course : les deux champs répondent
+à deux questions différentes, et le code le dit.
+
+| | ce que le champ teste | où |
+|---|---|---|
+| `progressMeasurable` | **le matériel le permet** — borne avec `sessionEnergy`, ou compteur désigné qui compte l'énergie | `nymeaenergyjsonhandler.cpp::progressMesurable()` |
+| `regime` | **le moteur le fait** — `sessionMeasurable`, posé **uniquement** dans `evadapter.cpp` | `surpluscontext.h` (défaut `false`) |
+
+Sur toute charge non-VE, le premier dit *oui* et le second dit *non*. C'est le quatrième maillon
+mort, vu de l'autre bout.
+
+**Et la conséquence défait la règle pour laquelle le champ a été créé** : l'avertissement de saisie
+se déclenche sur `progressMeasurable == false`, donc il **restera muet exactement sur les charges
+dont l'obligation sera achetée à l'aveugle**. L'installateur ne sera pas prévenu dans le seul cas
+où il fallait le prévenir.
+
+**Nous ne câblons donc pas l'avertissement sur ce champ**, et l'app ne peut pas rattraper : à la
+saisie, la charge n'est pas encore dans `loads[]`, donc son `regime` n'existe pas — c'est
+précisément pourquoi le signal devait vivre en configuration.
+
+Deux sorties, et la première est celle qu'on préfère :
+
+1. **Remplir `sessionWh` depuis le compteur désigné** pour les charges non-VE — les deux champs
+   s'accordent alors d'eux-mêmes, et le régime devient `measured` là où le câblage le permet ;
+2. en attendant, faire dire à `progressMeasurable` **ce que le moteur fait**, pas ce que le
+   matériel permet, avec une cause qui nomme le manque. Mieux vaut un installateur prévenu par
+   une limite du moteur qu'un installateur non prévenu par une promesse de câblage.
+
+### Statut, sans reproche
+
+L'escalade est toujours là en `+etm49` — `remainingWh` figé à 4 000, `gridW` 645 → 654 sur sept
+cycles. Le taux constant a été retenu mais n'est pas déployé ; c'est cohérent avec ce que vous
+annonciez (la perte du tronçon d'abord). Noté pour ne pas le remesurer comme une découverte.
+
+---
+
 ## 2026-09-02 — la bascule de régime : prémisse confirmée, et une perte que le code montre
 
 ### Ma prémisse était juste, mais je l'avais posée sans la vérifier