JulesandClaude Fable 5.1
69809df5d1
Extraction du cœur autonomie de calculs.trans-former.fr (12 modules, sans singleton, couplages sans mutation, console derrière debug), découpage en trois moteurs d'axe + intégrateur (mode global = calculs, mode par_axe = plateforme), moteurs commun.contexte (Corse 2A/2B, DOM 97x corrigés) et commun.geometrie, table des coefficients harmonisés (docs/CONSTANTES.md pour Jules, R-7), validation structurelle des données (schemas/), tests hors ligne : 28 assertions d'origine + épingle générée depuis le code d'astro-pro + écarts d'harmonisation figés + contrat des moteurs. dist/ committé. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019UBHYPdeQYy2m1GVJp6b12
48 lines
6.8 KiB
Markdown
48 lines
6.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) ; le nord n'est plus pénalisé deux fois plus que la source |
|
||
| **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 |
|
||
|
||
## 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.
|