Cette remarque a été envoyée suite au constat qu'il y avait encore des messages d'erreur (au moins un, en tout cas...) à cause d'arrondis mal maitrisés apparaissant dans les cases de "reste" net des parois du volume protégé.
Dans ce cas-ci, ce reste doit être positif ou nul, sinon ça bloque.
Mais ici, le reste négatif est tellement petit qu'il est bien en-dessous de la deuxième décimale de l'affichage.
C'est donc un test qui n'est pas bien calibré.
Ceux qui ont fait un peu de programmation savent qu'un test sur une valeur strictement nulle, est délicat si on teste des différences basées sur des opérations dont les résultats ne sont pas limités par des arrondis fixés (ici à la deuxième décimale).
Un problème du même genre avait déjà été signalé avec la remarque n° 35 du 17.07.2020, mais avec un autre type de paroi.
Elle est annexée ci-dessous.
Il faudrait corriger cela pour tous les types de parois.
Évidemment, on peut aussi introduire directement les valeurs dans les cases ad-hoc mais alors, on perd la possibilité de vérifier comment le résultat a été obtenu.
Déjà que dans PACE, le calcul des surfaces est fort élémentaire, pour ne pas dire plus (il permet de calculer seulement des surfaces rectangulaires, comme s'il n'y avait que ce genre de surfaces dans les bâtiments existants), alors que le logiciel PEB permet, après l'avoir demandé il y a longtemps et attendu patiemment pendant un an et demi, d'introduire des formules de calcul plus complexes que la simple multiplication d'une longueur par une largeur, ainsi que la possibilité de modifier ou de vérifier les données utilisées.
Par contre, le logiciel PEB ne permet pas d'inclure des baies dans des parois, comme dans PACE, ce qui permet de calculer directement les surfaces nettes des toitures, murs et planchers, baies déduites.
Ce n'est évidemment pas la première fois, ni depuis peu, qu'on demande à ce que des améliorations d'un logiciel soient introduits dans l'autre et vice-versa.
Mais jusqu'à présent, les convoyeurs attendent, hélas.
Une conception intégrée aurait pu éviter ça, depuis longtemps, sous la direction de l'administration qui est, en principe, chargée de valider les opérations.
Et couter moins cher que les corrections, ce qui en freine l'exécution a posteriori.
Qui est fondamentalement responsable de tout ça ?
Personne ne lève le doigt, évidemment !
From: Ir Architecte Meessen Sent: Monday, October 4, 2021 8:43 AM To: Benoit Fourez (DGO4) ; Carole Van Goethem (DGO4) Cc: Carol Pisula (Cabinet du ministre Henry) ; Olivier Biérin (Député wallon) ; contact@peeb.be Subject: 20211003 Remarque n° 73 : Encore un arrondi qui bloque
Vous avez ci-dessous la remarque n° 73.
Elle me fait penser à la remarque n° 35 du 17.07.2020 “Régler les arrondis” (en annexe).
Mais ça n’a peut-être rien à voir.
Un message d’erreur est apparu, signalant une différence minuscule jusqu’à la 14e décimale, sur le résultat de la surface nette d’une toiture.
Le message de la remarque n° 35 du 17.07.2020 concernait un mur. Ici, c’est une toiture. L’informaticien est-il intervenu uniquement sur les murs ? Si c’est le cas, on voit ici qu’il faudrait intervenir pour tout calcul de surface. En principe, tout informaticien sait qu’on ne fait pas un test par rapport à zéro, quand le résultat de la différence des montants testés ne peut pas être nulle. Il faut tester sur une valeur absolue inférieure à une tolérance qui se situe sous l’arrondi affiché. Et s’il n’y a pas encore eu de correction d’arrondi du tout, il serait temps de le faire, d’autant plus que ces erreurs sont bloquantes. Tout ce qui peut faire perdre moins de temps à l’auditeur, serait bienvenu pour rendre sa tâche moins lourde, au bénéfice des demandeurs et de l’objectif global recherché. Merci pour votre suivi, Alain MEESSEN, vice-président de l’asbl PEEB.