diff --git a/docs/BRIEF_plugin_depuis_maquettes.md b/docs/BRIEF_plugin_depuis_maquettes.md
index e2c9159..6747445 100644
--- a/docs/BRIEF_plugin_depuis_maquettes.md
+++ b/docs/BRIEF_plugin_depuis_maquettes.md
@@ -2,6 +2,62 @@
 
 ---
 
+## 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
+
+Lue dans `energyarbitrator.cpp` : la base se prend **à l'instant où la charge devient mesurable**
+(`if (!m_ecoBaseWh.contains(id)) insert(sessionWh)`), et `ecotarget.cpp` calcule
+`remainingWh = targetWh − deliveredWh` — donc **`targetWh` n'est pas rebasée**. `deliveredWh` ne
+compte bien que depuis la bascule. J'avais énoncé ça comme un fait ; ça n'en était un qu'après
+lecture.
+
+### Et votre réponse tranche mieux que ma question
+
+J'offrais deux sorties comme équivalentes — rebaser `targetWh`, ou publier depuis quand on
+mesure. `measuredSince` est déjà écrit, et le commentaire donne l'argument qui départage, que je
+n'avais pas : **rebaser ferait perdre l'obligation réelle, et l'écran ne pourrait plus dire ce qui
+reste dû.** Retenu tel quel. `purchasedWh` est là aussi, dans tous les régimes, avec exactement la
+distinction proposée — l'acheté est la commande du moteur, le livré une observation qu'il ne peut
+pas faire.
+
+### Mais aucun des deux n'est SUR LA BOX
+
+`strings` sur le binaire déployé (`libnymea_energypluginnymea.so`, `+etm43`), dans les deux
+encodages — merci pour `-el`, le mélange est bien réel :
+
+| symbole | UTF-16 | ASCII |
+|---|---|---|
+| `ECO_FLOOR_GRID` · `ECO_FLOOR_MISSED` · `remainingWh` | 0 | **1** |
+| `atMaximum` | **1** | 1 |
+| **`purchasedWh`** | **0** | **0** |
+| **`measuredSince`** | **0** | **0** |
+
+Ils sont au HEAD (`770cef1`), pas dans `+etm43`. **Rien n'est donc à câbler dessus aujourd'hui** —
+et sans ce contrôle j'aurais bâti l'avertissement de saisie sur deux champs muets, pour la
+troisième fois de la semaine.
+
+### Une perte que la lecture montre, et que la bascule rend probable
+
+Sur `measured → unmeasurable → measured` **dans la même période** : au passage en `unmeasurable`,
+`m_ecoBaseWh` et `m_ecoMesureDepuis` sont retirés ; au retour, la base est reprise à la valeur
+**courante** de `sessionWh`. Donc `deliveredWh` **repart de zéro**, et l'énergie livrée pendant les
+tronçons mesurés antérieurs est perdue de l'avancement.
+
+Deux conséquences, et la seconde coûte de l'argent : l'écran **sous-estime** l'avancement, et la
+passe éco **rachète ce qui a déjà été livré**. Ce n'est pas théorique — c'est exactement le motif
+de la V2C dont le lien Modbus bat : `connected` bascule, le régime suit.
+
+Piste, si elle vous va : accumuler par **période** plutôt que par tronçon — ajouter
+`sessionWh − base` à un cumul de période au moment de quitter `measured`, au lieu de le jeter. Le
+`measuredSince` garde alors son sens (« mesuré depuis », avec des trous), et `deliveredWh` cesse de
+mentir par défaut.
+
+*(Lu dans le code, non mesuré : la bascule n'est pas provocable sur le banc tant que `sessionWh`
+n'est pas rempli hors borne.)*
+
+---
+
 ## 2026-09-01 (soir) — trois champs pour que l'écran puisse tenir la nuance
 
 Vos deux règles sont prises. Il leur manque trois choses pour être **affichables**, et chacune