Le titre complet est : "PACE : anomalie d'encodage entre certification et audit pour les briques, et autres considérations démocratiques sur les logiciels utilisés".
Un problème avec les valeurs lambdas des briques avait déjà été signalé avec la remarque n° 13 du 28.10.2019 mais elle n'était pas allée jusqu'au bout, faute de temps.
Cette remarque est déjà sur le forum mais je la replace ci-dessous pour faciliter les recherches.
De toute façon, rien n'a changé depuis, malgré le long délai.
C'est dire comme ça sert à quelque chose de révéler des problèmes à la DGO4.
Ils considèrent peut-être qu'il n'y a pas de problème mais alors... pourquoi ne pas le dire ?
La remarque n° 57 commence par signaler que les valeurs des lambdas des briques "apparentes"en certification sont transférées telles quelles dans la description de la couche en audit.
Mais sans une coche automatique de la case "lambda e ?" alors qu'elle sont apparentes.
Une fois que la valeur a été transférée, modifier les cases des descriptions de la couche ne modifie pas.
Il faut précisément pousser sur le bouton de la case qui contient la valeur lambda, pour la faire revenir à la valeur par défaut en audit.
Je fais aussi remarquer que les valeurs des lambdas des briques apparentes varient avec l'épaisseur de la paroi en certification mais pas en audit.
Ensuite, que la valeur par défaut des briques apparentes en audit est largement supérieure à la plus mauvaise des valeurs moyennes de ce cas en certification pour la plus mince des parois.
Ce n'est pas normal et ça conduit à des différences importantes entre les résultats "certification" et "audit". Et ce n'est pas rien quand on a des murs de surfaces importantes !
En certification, la variation des lambdas moyens en fonction des épaisseurs peut être identifiées mais on ne sait pas sur quoi c'est basé (voir ci-dessous).
On peut se demander pourquoi ce n'est pas la même chose en audit et pourquoi la valeur par défaut est franchement plus mauvaise.
On n'a même jamais aucune justification des paramètres qui apparaissent dans les méthodes PEB, certification et audits et les logiciels que nous sommes obligés d'utiliser sans savoir ce qu'ils calculent et comment.
Or les remarques successives montrent qu'il y a de sérieux doutes quant aux résultats produits.
Cette fin de non recevoir pour ne pas vouloir communiquer les origines "scientifiques" des valeurs utilisées, voire des équations des logiciels, est un réel problème de démocratie envers les utilisateurs de ces méthodes et logiciels qui sont en fait des black-boxes opaques dont on ne sait rien.
Pour ne pas qu'on puisse en prendre connaissance, les vérifier, en discuter et, le cas échéant, proposer des modifications.
Bref, un processus parfaitement anti-démocratique.
Et ça dure depuis des années, en fait depuis le début de la PEB.
Ci-dessous, le texte complet de la remarque n° 57.