Files

T

JulesandClaude Fable 5.1 4f593d2edf Épingles : écarts correctifs face à l'épingle d'origine, écarts d'harmonisation refigés (05/10)

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 par 91c755f (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 dans 8465bf7, 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

2026-10-05 16:39:51 +02:00

7.8 KiB

Raw Permalink Blame History

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.

7.8 KiB Raw Permalink Blame History Unescape Escape