Chantier etape 4 : le bilan, et description materielle consignee

BALANCE.js ne pilote rien : il publie les faits qui remplacent les seuils fixes
— heure de croisement, energie a couvrir, SOC requis (remplacant de
grid_soc_off), energie reseau strictement necessaire, surplus disponible pour
le vehicule, indice de confiance. Sans une de ses entrees il se declare
inutilisable et les controleurs gardent leurs regles.

Deux niveaux de prudence. Le premier jet n'utilisait que le profil p80 et
exigeait 48 % de SOC pour franchir la matinee du 24/08, soit plus cher que le
seuil fixe de 30 % qu'il remplace. Corrige : la decision reseau, reevaluee a
chaque cycle et reversible, utilise le profil typique p50 ; le prudent p80 sert
a la planification. La marge de securite de 10 % ajoutee au depart etait une
constante arbitraire et un double comptage : mesure faite, p80(somme) egale
somme(p80) sur toutes les fenetres, les heures de consommation etant fortement
correlees. Marge supprimee.

Rejeu fige de la matinee du 24/08 (SOC 21 %, capacite 15 kWh, production
reellement mesuree) : croisement a 08 h, 0,82 kWh a couvrir contre 0,80 calcule
a la main, SOC requis 27,5 %, une session reseau de 0,97 kWh. Suite a 21
scenarios.

MANUEL_COMPLET section 0 : description materielle complete relevee dans VRM et
completee par le proprietaire — 2 MultiPlus-II 48/5000 en parallele, 53
panneaux sur trois orientations (10 est/sud-est, 30 sud, 10 ouest, 3 sur un
petit MPPT), parc Pylontech, borne 32 A. Explique pourquoi aucun modele
solaire mono-plan ne peut representer la production, et pourquoi Forecast.Solar
mal configure se trompe de repartition.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ

docs/CHANTIER_BILAN_ENERGETIQUE.md

@@ -150,7 +150,45 @@ calcul en saison basse.
   décisions fondées sur la prévision (EVCS, chauffe-eau, conseiller IA).
   À corriger dans la configuration de l'intégration (azimut et inclinaison par
   plan), puis refaire la comparaison.
-- [ ] Étape 4 — bilan et ses sorties.
+- [x] **Étape 4 — le bilan** (24/08). `src/energy-balance/BALANCE.js`. Ne pilote
+  rien : publie les faits qui remplacent les seuils fixes — heure de croisement,
+  énergie à couvrir, **SOC requis** (remplaçant de `grid_soc_off`), énergie
+  réseau strictement nécessaire, surplus disponible pour le véhicule, indice de
+  confiance. Sans une de ses entrées, il se déclare inutilisable et les
+  contrôleurs gardent leurs règles.
+
+  **Deux niveaux de prudence, et c'est un choix de conception, pas un détail.**
+  Le premier jet n'utilisait que le profil prudent (p80) et exigeait **48 % de
+  SOC** pour franchir la matinée du 24/08 — alors que le seuil fixe de 30 %
+  aurait été moins coûteux. Un bilan plus gourmand que le seuil bête qu'il
+  remplace n'a aucun intérêt. Corrigé : la décision réseau, réévaluée à chaque
+  cycle et réversible, utilise le profil **typique (p50)** ; le profil prudent
+  (p80) sert à la planification qui engage plusieurs heures (cible de nuit,
+  dimensionnement du stockage). Se tromper par optimisme ne coûte qu'un
+  démarrage réseau une heure plus tard, le plancher dur protégeant la batterie ;
+  se tromper par excès de prudence coûte un import réseau immédiat et réel.
+
+  Vérifié aussi : la marge de sécurité de 10 % que j'avais ajoutée était une
+  constante arbitraire de plus, et un double comptage. Mesure du 24/08 :
+  `p80(somme des heures)` égale `somme(p80 par heure)` sur toutes les fenêtres
+  testées — les heures de consommation sont fortement corrélées. La prudence est
+  donc entièrement portée par le percentile, qui est mesuré. Marge supprimée.
+
+  **Rejeu de la matinée du 24/08 (scénario figé)** — SOC réel 21 %, capacité
+  15 kWh, production horaire réellement mesurée :
+
+  | | |
+  |---|---|
+  | Croisement PV/consommation | **08 h** |
+  | Énergie à couvrir | **0,82 kWh** (calcul manuel sur les mesures : 0,80) |
+  | SOC requis (décision) | **27,5 %** au lieu du seuil fixe de 30 % |
+  | Réseau nécessaire | oui, **0,97 kWh** — une session, puis terminé |
+  | SOC requis (planification, p80) | 38,1 % |
+  | Déficit calculé sur forme fiable | oui |
+
+  Suite portée à **21 scénarios**.
+
+- [ ] Étape 5 — publication dans n8n (workflow + helpers), puis dashboard.
 
 ## Backlog
 

docs/MANUEL_COMPLET.md

@@ -6,6 +6,74 @@
 
 ---
 
+## 0. Installation physique (matériel réel)
+
+> Relevé le 24/08/2026 depuis la console VRM (Paramètres → Appareils) et
+> complété par le propriétaire. **À tenir à jour** : cette section existe pour
+> qu'il n'ait jamais à redécrire son installation.
+
+### Onduleurs
+**2 × MultiPlus-II 48/5000/70-50**, *two units configured in parallel*
+(instance VRM 276, id produit 2623, micrologiciel 2623556).
+Numéros de série : `HQ2244WY9T6` (Phase 1 Maître) · `HQ23467ZN6F` (Phase 1
+Unité parallèle 1). Puissance nominale du couple : **9000 W**
+(`sensor.victron_ve_bus_nominal_inverter_power`).
+⚠️ Le VE.Bus en parallèle n'expose **qu'une seule instance D-Bus** couvrant les
+deux unités : `vebus/276/…` est déjà la grandeur système, pas celle d'un
+onduleur isolé. Les unités individuelles n'apparaissent que sous
+`vebus/276/Devices/N/…`.
+
+### Champ photovoltaïque — 53 panneaux, **trois orientations**
+
+| Chargeur solaire | Instance | Panneaux | Orientation |
+|---|---|---|---|
+| SmartSolar Charger **MPPT 250/70 rev2** (`AIRTRIA MPPT1`, s/n HQ2235HKX24) | 279 | **10** | **est / sud-est** |
+| SmartSolar **MPPT RS 450/200** (s/n HQ2449YR9PT) | 280 | **30** | **plein sud** |
+| ″ (second tracker du même RS 450/200) | 280 | **10** | **plein ouest** |
+| SmartSolar Charger **MPPT 150/35** (`V1`, s/n HQ2238U24HP) | 277 | **3** | un tracker |
+
+`V2` (instance 288) et `V3` (instance 278) apparaissent dans VRM avec
+« dernière vue il y a un an » : appareils obsolètes, à ignorer.
+
+**Conséquence majeure pour tout calcul de production** : avec de l'est, du sud
+et de l'ouest, la courbe de production journalière ne peut PAS être représentée
+par un modèle solaire à plan unique. Une tentative d'ajustement mono-plan
+(24/08) converge sur « plein est, 20° » et prédit 2,0 % de la journée à 18 h
+contre 5,8 % réellement mesurés. La forme doit venir de la mesure, ou d'un
+modèle à trois plans. Voir `docs/CHANTIER_BILAN_ENERGETIQUE.md`.
+
+⚠️ **Forecast.Solar est mal configuré** : il attend une journée orientée
+l'après-midi (15,1 % de l'énergie le matin 07-11 h) alors que l'installation
+produit le matin (39,3 % mesurés). Il faut y déclarer **un plan par
+orientation** — est/sud-est, sud, ouest.
+
+### Batterie
+**8 × Pylontech US2000C** (`AIRTRIA 8 US2000C`, Battery Monitor, instance VRM
+512, fabricant PYLON, interface CAN-bus), organisés en **deux packs de 4 reliés
+par un hub**. Le premier pack a deux ans de plus que le second et a vécu avant
+la climatisation du garage.
+**État au 24/08/2026 : un module en panne et isolé → 7 modules actifs**, un
+huitième commence à faiblir. Mélanger des packs d'âges différents est
+déconseillé (contrainte de budget, pas un choix technique).
+⚠️ `batteryUsableCapacityKwh: 17.5` est codé en dur dans `INPUT_PARSE.js` et
+utilisé trois fois dans `WINDOWS_SOURCEV2.js` : avec 7 modules, cette valeur
+surestime la réserve réelle de 15 à 20 %. Aucun capteur de capacité ou de santé
+batterie n'est publié côté HA — à corriger.
+
+### Borne de recharge
+**EV Charging Station 32A** (s/n HQ2239DNT7P, micrologiciel v2.08, instance VRM
+40), position « EV charger on output ».
+Deux véhicules alternent : **VW** (hybride, départ ~08:50) et **JEEP**
+(départ ~06:30) — cf. §11.5.
+
+### Réseau
+Victron **ESS sans injection** : la production est bridée en permanence à ce que
+le système peut absorber (consommation + charge batterie). Voir
+`docs/CHANTIER_BILAN_ENERGETIQUE.md` pour les conséquences sur toute mesure de
+production.
+
+---
+
 ## 1. Architecture Globale
 
 ```