diff --git a/docs/CHANTIER_BILAN_ENERGETIQUE.md b/docs/CHANTIER_BILAN_ENERGETIQUE.md
index 9727192..2ec2e25 100644
--- a/docs/CHANTIER_BILAN_ENERGETIQUE.md
+++ b/docs/CHANTIER_BILAN_ENERGETIQUE.md
@@ -224,6 +224,49 @@ calcul en saison basse.
   Déclaré dans `configuration.yaml` (sauvegarde dans `SAVE_CONFIG/`),
   redémarrage HA effectué, aucune erreur au journal.
 
+## Modèle solaire local : tentative abandonnée (25/08)
+
+Objectif : produire la forme horaire à partir de la géométrie et des quatre
+orientations réelles, pour éviter un abonnement Forecast.Solar. **Abandonné**,
+pour trois raisons qui se cumulent.
+
+**Découverte utile au passage** : les entrées MPPT sont mesurées séparément et
+la correspondance est établie — `sensor.airtria_mppt1_yield_today` = les 10 PV
+sud-est (pic à 11 h), `sensor.v1_yield_today` = les 3 PV du suiveur (pic à 9 h),
+`tracker_solar_1/2/3` du RS 450/200 = les trois strings sud (pics 13-14 h),
+`tracker_solar_4` = le string ouest (longue traîne jusqu'à 19 h). Chaque plan
+peut donc être confronté à sa propre mesure — c'est ce qui a permis de trancher.
+
+1. **Seules 4 heures de la journée sont exploitables.** Taux de censure :
+   08 h 0 %, 09 h 0 %, 10 h 4 %, 11 h 4 %, puis **12 h 59 %, 13 h 77 %,
+   14 h 81 %**. Ajuster une forme journalière sur quatre heures propres n'est
+   pas sérieux.
+2. **L'enveloppe n'est pas une courbe de journée valide.** C'est le maximum
+   horaire pris indépendamment sur des jours différents : le pic de 8 h vient
+   d'un jour, celui de 11 h d'un autre. Le résultat est plus plat que n'importe
+   quelle journée réelle. Comparer un modèle de journée à cette référence n'a
+   pas de sens. *(Limitation qui vaut aussi, au second ordre, pour l'usage de
+   l'enveloppe comme forme dans `RESOURCE_ESTIMATE` — atténuée par le fait
+   qu'elle y est renormalisée sur la prévision du jour.)*
+3. **Le modèle a besoin de paramètres non ajustables sur ces données.** Un
+   modèle direct seul prédit zéro production le matin sur le plan ouest, alors
+   que la mesure donne 14 % à 9 h : il manquait le **rayonnement diffus**.
+   Ajouté, sa fraction part en butée de l'intervalle de recherche sans jamais
+   converger — le modèle reste trop piqué sur midi par rapport à la mesure, et
+   ce pour les quatre plans à la fois.
+
+**Conséquence** : l'abonnement Forecast.Solar Professional (souscrit le 24/08,
+70 €/an, 14 jours d'essai) est le bon choix, et pour une raison que je n'avais
+pas identifiée en le déconseillant. Avec la clé d'API, n8n interrogera
+directement `api.forecast.solar` et obtiendra la **courbe horaire complète**
+(`watt_hours_period`) pour les trois plans — ce que l'intégration HA n'expose
+pas, même abonnée, puisqu'elle ne publie que quatre capteurs résumés.
+
+Cette courbe remplacera **à la fois** la forme (enveloppe) et la magnitude
+(capteurs) dans `RESOURCE_ESTIMATE`, ce qui simplifiera le nœud au lieu de le
+compliquer. Les plans à déclarer : sud-est 135°/40°/4030 W (suiveur fusionné,
+930 W), sud 180°/35°/9300 W, ouest 270°/45°/2790 W.
+
 ## Backlog
 
 - [ ] **Doublon `unique_id: victron_vebus_dc_power`** — déclaré deux fois, avec