Files
moteurs/docs/CONSTANTES.md
T
JulesandClaude Fable 5.1 69809df5d1 LOT P1.0 : paquet @transformer/moteurs v0.1.0
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
2026-09-28 17:06:49 +02:00

6.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) ; 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.