Chantier etapes 5b et 5c : recalcul quotidien des profils et fenetre de deficit suivante

5c — BALANCE ne repondait qu'a "combien jusqu'a ce que le solaire prenne le
relais". A 15 h la reponse est zero : exacte mais inutile, le deficit qui
approche etant celui de la nuit. Ajout de la prochaine traversee deficitaire
(heure de debut, energie, SOC a atteindre avant). Ce SOC n'est PAS ecrete a
100 % : au-dela, meme une batterie pleine ne passe pas, et le manque est
publie comme storage_shortfall_kwh — c'est le chiffre du dimensionnement.

5b — Workflow "EVCS Energy Profiles Daily V1" (N6UaB4ZozsbRPrFb), actif,
03:30 : lit /api/history/period sur 30 jours glissants et republie les quatre
CSV (conso p50 et p80, enveloppe de production, taux de censure).
CONSUMPTION_PROFILE devient DAILY_PROFILES et sait desormais decoder la
reponse brute de l'API en plus des series deja pretes.

Piege trouve : sans end_time, /api/history/period ne renvoie qu'UNE journee,
silencieusement. Mes premieres mesures "sur 3 jours" n'en couvraient qu'une.

Validation croisee : profils calcules depuis l'API REST (etats bruts, 11 j)
contre profils calcules depuis les statistiques long terme (28 j) — 0,20 kWh/h
d'ecart absolu moyen, par deux chemins de donnees independants.

BUILD_HA_CALLS_PROFILES refuse d'ecraser les profils en place si l'historique
ne couvre pas les 24 heures. Meme garantie de perimetre que le bilan.
Suite a 27 scenarios.

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

docs/CHANTIER_BILAN_ENERGETIQUE.md

@@ -188,7 +188,30 @@ calcul en saison basse.
 
   Suite portée à **21 scénarios**.
 
-- [ ] Étape 5 — publication dans n8n (workflow + helpers), puis dashboard.
+- [x] **Étape 5 — publication en mode ombre** (24/08). Workflow n8n
+  **EVCS Energy Balance V1** (`QoSfPeyGq35orF1K`), actif, cycle 5 min.
+  Périmètre d'écriture garanti par test de mutation : l'injection d'un
+  `turn_on` sur `switch.edf_general_ok_switch` fait rougir la suite.
+  Kill-switch `input_boolean.evcs_balance_enabled`.
+- [x] **Étape 5b — recalcul quotidien des profils** (24/08). Workflow
+  **EVCS Energy Profiles Daily V1** (`N6UaB4ZozsbRPrFb`), actif, 03:30.
+  Lit `/api/history/period` et republie les quatre CSV.
+  ⚠️ Piège trouvé : **sans `end_time`, l'API ne renvoie qu'UNE journée**, en
+  silence. Mes trois premières mesures « sur 3 jours » n'en couvraient qu'une.
+  Refus explicite d'écraser les profils si l'historique ne couvre pas les 24 h.
+  **Validation croisée** : profils calculés depuis l'API REST (états bruts,
+  11 jours) contre profils calculés depuis les statistiques long terme
+  (28 jours) → **0,20 kWh/h d'écart absolu moyen**, deux chemins de données
+  totalement indépendants.
+- [x] **Étape 5c — prochaine fenêtre de déficit** (24/08). Le bilan ne
+  répondait qu'à « combien jusqu'à ce que le solaire prenne le relais » : à
+  15 h la réponse est zéro, exacte mais inutile, car le déficit qui approche
+  est celui de la nuit. Ajout de la prochaine traversée déficitaire — heure de
+  début, énergie, SOC à atteindre avant. **Ce SOC n'est volontairement pas
+  écrêté à 100 %** : au-delà, même une batterie pleine ne passe pas, et l'écart
+  est publié comme `storage_shortfall_kwh`. C'est le chiffre du dimensionnement
+  du stockage.
+- [ ] Étape 6 — dashboard, après quelques jours d'observation.
 
 ## Backlog