Corpus « autotests État » (CSTB/Tribu) — mesurer la conformité stricte et les bugs résiduels

[elliot-redfroggy]

Contexte

Le CSTB/DHUP fournit une suite d'autotests officiels qui sert à l'État pour valider un moteur de calcul DPE (au sens de l'agrément). Ces cas de test couvrent les trois typologies de logement avec, pour chacun, des données d'entrée et les sorties de référence en pleine précision produites par le moteur officiel Tribu.

Les intégrer comme corpus dédié dans Open3CL permettrait de mesurer un taux de conformité stricte (et non plus seulement statistique à 5 % comme le corpus des DPE réels) et d'isoler les bugs résiduels par grandeur de calcul.

Contenu de la suite d'autotests (source CSTB/Tribu)

Typologie	Nb de cas
MI — maison individuelle	29
APP — appartement	33
IC — immeuble collectif	25
(+ variantes IC_Echantillonnage, IC_vers_APP)	—

Chaque cas = <CODE>_Entree.xml + sorties/<CODE>_Sortie.xml (valeurs attendues pleine précision : GV, DR, Bch, Becs, Bfr, besoins mensuels, consommations, coûts…). Le moteur de référence est Moteur_DPE.dll v2025.11.1.0.

Deux verrous techniques identifiés

1. Format d'entrée différent. Les entrées des autotests sont au format propre au moteur Tribu (racine <batiment> : <zone_climatique>, <altitude>, <SH>, <enveloppe>…), qui n'est pas le format XML ADEME/observatoire (<dpe><logement>) consommé par calcul_3cl_xml. Il faut un adaptateur <batiment> (Tribu) → entrée Open3CL.

2. Grandeurs de sortie nommées différemment. La sortie Tribu (<Projet><Sortie_Batiment>) utilise d'autres noms que logement.sortie d'Open3CL. Une table de correspondance est nécessaire, par ex. :

Sortie Tribu	Chemin Open3CL
Sortie_Batiment/Enveloppe/GV	sortie.deperdition.deperdition_enveloppe
Sortie_Batiment/Enveloppe/DR	sortie.deperdition.deperdition_renouvellement_air
Besoins/Bch, Becs, Bfr	sortie.apport_et_besoin.besoin_ch / besoin_ecs / besoin_fr
Besoins_mensuels_Ch/*	besoins mensuels de chauffage
conso Cch/Cecs/Cfr, coûts	chemins sortie.ef_conso.* / sortie.cout.*

(La table complète sera fournie par l'expert métier / thermicien.)

Proposition d'implémentation

• Nouveau corpus test/corpus/autotests_etat/ avec les entrées + sorties de référence.
• Un runner qui, pour chaque cas :
  1. convertit _Entree.xml (format Tribu) → entrée Open3CL ;
  2. exécute calcul_3cl ;
  3. compare les grandeurs calculées aux valeurs de _Sortie.xml via la table de correspondance ;
  4. publie un taux de conformité + le détail des écarts par grandeur et par cas.
• Tolérance : à discuter, mais les autotests d'État sont des tests exacts (pas 5 %). Prévoir un epsilon numérique fin (ex. toBeCloseTo) plutôt qu'une tolérance relative large.

Répartition des rôles suggérée

• Expert métier / thermicien : table de correspondance complète des grandeurs, interprétation normative des écarts constatés (distinguer écart involontaire vs bug_for_bug_compat assumé).
• Développeurs Open3CL : adaptateur de format d'entrée, runner de corpus, intégration CI/reporting (à l'image du corpus existant).

Question ouverte

• Où héberger les fichiers de test (dépôt vs. stockage externe type S3 comme le corpus actuel) compte tenu de leur provenance CSTB ? À trancher côté projet.

---

Issue ouverte par l'ingénieur thermicien (analyse métier). Les décisions techniques d'implémentation reviennent aux développeurs.