JulesandClaude Fable 5.1
4f593d2edf
L'épingle d'origine (fixtures/sorties-origine-2026-09-28.json, générée depuis le code d'astro-pro) porte les défauts corrigés par91c755f(eg_phytostation ×3 sur C/eau, basse_planche_bec ×2 sur B et C/alim, lignes forcées orphelines, FORCE ×4 dans le journal, A/eau par axe en INSUFFISANT). La regénérer depuis astro-pro reproduirait les défauts ; la regénérer depuis ce paquet en ferait une épingle sur soi-même. Elle reste donc telle quelle, et : - scripts/ecarts-correctifs.mjs + fixtures/ecarts-correctifs-2026-10-05.json : chaque cellule (profil × mode × axe × champ) qui s'écarte de l'origine est figée, avec le détail des lignes ; une cellule absente doit rester identique. - test/decoupage.test.mjs : test 1 compare aux écarts figés (et vérifie qu'un correctif n'introduit jamais un INSUFFISANT ni un total hors ±5 % en global ; budgets alloués et poids des axes inchangés) ; test 2 vérifie la propriété du découpage contre selectionner() de ce paquet ; test 3 inchangé dans l'esprit. - Écarts d'harmonisation REFIGÉS (npm run ecarts -- --ecrire 2026-10-05) après relecture de docs/CONSTANTES.md : neuf lignes au lieu de onze. Les deux lignes perdues (A énergie global 22 → 6 %, C énergie par axe 10 → 3 %) étaient des taux calculés sur des kWc fantômes hérités par une batterie ; la couverture y est null avec les deux tables. Aucun coefficient ne change. Note datée posée dans CONSTANTES.md §1. (La suppression du fichier du 28/09 est partie par erreur dans8465bf7, avec la version : même intention, deux commits.) - fixtures/README.md et AGENTS.md (règles 6 et 8) : l'épingle d'origine ne se regénère pas pour absorber un correctif ; invariants tenus depuis v0.1.1. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Tgtn7bJxTLiL2fRCkQMgtR
50 lines
7.8 KiB
Markdown
50 lines
7.8 KiB
Markdown
# CONSTANTES — table des coefficients harmonisés (v0.1.0, 28/09/2026)
|
||
|
||
> **Pour Jules, 20 minutes, veto ligne à ligne.** Règle appliquée : *le document de recherche l'emporte sur le code quand ils divergent* (SPEC phase 1 §4.1). Chaque ligne dit ce que le code portait, ce que le paquet retient, d'où ça vient, et ce que ça change. **Sans veto sous une semaine (le 5 octobre), cette table est la référence.** Un veto = la ligne, la valeur voulue, une source si tu en as une ; je corrige `src/commun/coefficients.ts`, je refige les écarts, nouvelle étiquette.
|
||
>
|
||
> Sources : `01-recherche-eau.md`, `02-recherche-energie.md`, `99-brief-atis-dev.md` (tous du 28/04/2026, dossier `Simulateur autonomie V2`) ; code de `calculs.trans-former.fr` au 28/09 ; simulateur autoconstruction V1 pour la géométrie.
|
||
|
||
## 1. Ce qui change vraiment (cinq lignes)
|
||
|
||
| Grandeur | Le code portait | Retenu | Source | Effet mesuré sur les trois profils de référence |
|
||
|---|---|---|---|---|
|
||
| **Rendement de captage** | trois valeurs : 0,7 (score de pluviométrie), 0,8 (taux de couverture), 0,85 (V1) | **0,80** (fourchette 0,75 zone sèche à 0,85 zone humide) | recherche eau §3 et §7 n°6 : NF EN 16941-1, recueil Nény p.16 | aucune typologie ne change ; couverture eau **+3 à +4 points** (A 23 → 27 %, B 24 → 27 %, C 20 → 23 %) |
|
||
| **Facteur d'orientation PV** | sud 1 · SE/SO 0,93 · E/O 0,78 · **nord 0,40** | sud 1 · SE/SO **0,95** · E/O **0,80** · nord **0,60** (bas de fourchette) | recherche énergie §3.2 (SE/SO 95 %, E/O 80-85 %, N 60-65 %). *Variante : le brief §7.2 prenait les milieux 0,82 et 0,62* | aucune typologie ne change (les trois profils sont sud ou sud-est) ; mesuré aussi sur B et C avec un toit **est** puis **nord** : aucun kit PV n'est retenu dans ces cas, avec l'une ou l'autre table, donc aucune sélection ne bouge non plus ; l'effet du facteur se verra sur le dimensionnement (kWc) d'un toit est/ouest quand un kit est retenu |
|
||
| **Taux d'autoconsommation** | **absent** : la couverture énergie comparait la production brute au besoin | **0,30 sans batterie, 0,70 avec 10 kWh**, linéaire entre les deux (l'interpolation est un choix MOE, non sourcé) | recherche énergie §3.2, brief §7.2 | c'est **le** changement visible : couverture énergie **A 22 → 6 %**, **B 100 → 80 %** (mode par axe, avec batterie), **C 100 → 63 %** (global) et 10 → 3 % (par axe). Le simulateur promettait trop |
|
||
| **Productible PV** (kWh/kWc/an) | table par zone **biogéographique**, 1 050 à **1 550** (zone 8, au-dessus du maximum de la source) | table par zone **RT** : H1a 1 000 · H1b 1 050 · H1c 1 200 · H2a 1 100 · H2b 1 200 · H2c 1 250 · **H2d 1 300** · H3 1 400 ; défaut 1 100 | recherche énergie §3.2 (PVGIS, sud 30°, pertes 14 %). H1a = moyenne Lille 950 / Paris 1 050. **H2d interpolé par la MOE** (04, 07, 26, 84 : pas de ville dans la source), déclaré en avertissement à chaque usage | inclus dans les écarts d'énergie ci-dessus (Paris 1 100 → 1 000, Bouches-du-Rhône 1 480 → 1 400) |
|
||
| **Contexte Corse et DOM** | `algo.js` prenait deux chiffres du code postal : 2A, 2B, 971-976 retombaient sur **H2a, 800 mm, 2 200 DJU** pendant que l'affichage utilisait la vraie ligne | une seule fonction, `departementDepuisCodePostal` (20000-20190 → 2A, 20200-20620 → 2B, 97xxx → trois caractères) | code de `data.js` (l'interface avait déjà la bonne logique) | Corse : H3 (700-750 mm, 1 500-1 600 DJU). DOM : la table `france_climat` n'a **ni pluviométrie ni DJU** pour 971-976 (« DOM tropical ») → défauts 800 mm / 2 200 DJU appliqués **et déclarés** ; à compléter dans NocoDB si un jour une adresse DOM arrive |
|
||
|
||
> **Correction du 05/10 (v0.1.1), sans changement de coefficient.** Deux des effets « mesurés » ci-dessus n'existaient pas : **A énergie 22 → 6 %** (mode global) et **C énergie 10 → 3 %** (mode par axe) étaient calculés sur des kWc fantômes — une batterie au plomb retenue comme ligne du poste PV **héritait de la dimension « 0,4 kWc »** de la ligne qu'elle remplaçait (défaut du réajustement, corrigé). Dans ces deux cas la sélection ne porte aucun kit PV : la couverture énergie est **null** (« non calculable »), avec l'une ou l'autre table. Les écarts refigés (`fixtures/ecarts-harmonisation-2026-10-05.json`) ne portent plus ces deux lignes ; les quatre autres effets du tableau (captage, autoconsommation A par axe 22 → 6 %, B 100 → 80 %, C global 100 → 63 %) sont inchangés. Le reste de cette table reste à relire tel quel.
|
||
|
||
## 2. Ce qui ne change pas, désormais sourcé et unique
|
||
|
||
| Grandeur | Valeur | Source | Note |
|
||
|---|---|---|---|
|
||
| Besoin d'eau domestique | 150 L/jour/personne (54 750 L/an) | recherche eau §3 (INSEE, Eau France 2024), brief §7.1 | le V1 comptait 46,5 m³/an |
|
||
| Part substituable par l'eau de pluie | 70 % | recherche eau §3 : WC 30 + douche 60 + lessive 30 + jardin 25 L/j sur 150 | le V1 comptait 32 % |
|
||
| Rendement par type de toiture | tuile 0,85 · ardoise 0,85 · gravillonnée 0,50 · végétalisée 0,30 | recherche eau §7 n°6 (ADEME, NF EN 16941-1) | **non utilisé** en v0.1 : à brancher quand le formulaire demande le type de toit |
|
||
| Besoin d'électricité spécifique | 1 000 kWh/personne/an (fourchette 900-1 200), hors chauffage, ECS et véhicule | recherche énergie §3.1 (ADEME 2023, RTE 2024) | |
|
||
| Haie fruitière | 25 ml/personne (50 ml pour un excédent transformable) | brief §7.3, correction Jules du 28/04 | |
|
||
| DJU par défaut | H1 2 800 · H2 2 200 · H3 1 500 | heuristique V2, **non sourcée** | repli seulement : `france_climat` porte un DJU par département |
|
||
| Contexte par défaut | H2a, zone 4, 800 mm, 2 200 DJU | heuristique V2, **non sourcée** | appliqué seulement si le département est inconnu, toujours déclaré en avertissement |
|
||
|
||
## 3. Géométrie (nouveau moteur `commun.geometrie`, reprend `calcSurfaces` du V1)
|
||
|
||
| Grandeur | Valeur | Source | Note |
|
||
|---|---|---|---|
|
||
| Périmètre estimé | 4 × √(emprise × 1,3) | V1 autoconstruction | rectangle allongé ; pour 73 m² : 38,97 m |
|
||
| Surface vitrée | SHAB / 6 (16,7 %) | V1 (`vit = S/6`) ; règle RT 2012 (baies ≥ 1/6 de la SHAB) | la SPEC écrit « 15 % » : j'ai gardé 1/6, dis-moi si tu veux 15 % |
|
||
| Majoration de toiture | emprise / cos(pente) × 1,05 | V1 | |
|
||
| **SHAB estimée** | emprise × niveaux × **0,80** | **heuristique MOE, non sourcée** (murs extérieurs ~0,3 m, refends, escalier) | **hypothèse porteuse du P1.2** : maison B de l'étude (73 m² × 2 niveaux) → 116,8 m² ; la surface DPE n'est pas dans l'étude, l'écart se mesure au premier appel de l'adaptateur DPE (P1.1), visé < 20 % |
|
||
| Hauteur d'étage par défaut | 2,5 m | heuristique MOE | si la hauteur du bâti est inconnue |
|
||
| Mitoyenneté | −25 % du périmètre par côté mitoyen | heuristique MOE | |
|
||
| Pente par défaut | 30° | heuristique MOE | si inconnue |
|
||
|
||
## 4. Heuristiques restées dans le code (non déplacées, pour que tu saches qu'elles existent)
|
||
|
||
Ce ne sont pas des grandeurs physiques mais des choix de conception du simulateur V2 (spec d'algo « heuristique déterministe, calibrable sur trois profils »). Elles vivent dans `algo-config.json` (poids d'axes 40/40/20, modulateurs, matrices d'adéquation, tolérances ±5 % / −15 %, bonus DIY 1,3, malus 0,5 et 0,6, poids des postes) ou dans le noyau : pose pro = 50 % du matériel quand `prix_pro` manque (`cout_typologie`) ; cible de cuve = 2 mois de récupération (`score_pluviometrie`) ; puissance cible = DJU / 500 (`score_climat_chauffage`) ; 100 m² retirés de la parcelle pour le bâti (`score_surface_parcelle`, `par_surface_parcelle`). Les changer relève du recalibrage, pas de l'harmonisation.
|
||
|
||
## 5. Pour mettre un veto
|
||
|
||
Réponds par le numéro de ligne et la valeur : « §1 orientation : nord 0,62 (milieu du brief) » suffit. Je corrige la table, je relance `npm run ecarts`, je refige les écarts avec la date, nouvelle étiquette `v0.1.1`, montée dans `reinnover` le même jour.
|