Échange architecte vers ingénieur thermicien
A priori, toujours selon le même schéma, l'utilisateur ne devrait pas rencontrer de graves problèmes d'échange. La vue « Composants » produite par un logiciel de CAO peut être transformée facilement par un logiciel de calcul règlementaire thermique et climatique, lequel appartient à la catégorie de vue métier « Nus de locaux ». Il n'y a pas de « Parking ».
La seule condition est que le logiciel de CAO puisse modéliser les classes d'objets « locaux ou espaces », et puisse les mettre en relation avec les murs et planchers.
Ce n'était pas toujours le cas au début des années 2000. Sous la pression des utilisateurs, les éditeurs ont fait progresser cet aspect de la vue métier, soit dans le logiciel de CAO, soit dans le logiciel de calcul thermique (voir le chapitre 8.4 : Choisir un logiciel qui aime l'espace).
Malheureusement, l'évolution récente vers la maîtrise du développement durable, et l'apparition d'une réglementation sévère pour limiter la consommation d'énergie (réglementation RT-2012 par exemple) obligent les métiers du génie climatique à prendre en compte une nouvelle classe d'objets, matérialisée par une nouvelle sorte de composant physique ou virtuel : le « Pont thermique ».
Sa localisation dans le bâtiment résulte de la limite commune entre plusieurs types d'objets : un volume de local intérieur, l'espace extérieur, plusieurs parois (une combinaison de parois verticales et horizontales (Murs, planchers, toitures), et ou de composants linéiques (poteaux, poutres ...). Et en plus, cette réglementation implique une maîtrise des régimes thermiques nuit-jour-saison, avec prise en compte des apports d'énergie naturelle et effets de serre.
Cette complexité fait dire à Bruno SLAMA, éditeur des logiciels de calcul thermiques BBS, qu'il n'y a plus de distinction entre calcul règlementaire et calcul de simulation.
Nous ajoutons que produire la vue métier « Nus de locaux » n'est plus suffisante pour alimenter un logiciel de calcul thermique. En fait la vue à produire devient obligatoirement une synthèse des vues métiers « Calcul de structure et Nus de locaux ».
En effet, on peut toujours représenter la classe d'objets « Pont Thermique », objet linéique, par un axe, qui par définition est l'axe topologique d'un poteau ou d'un chainage, ou d'un joint, ou d'une poutre, même si ces derniers composants physiques n'existent pas à l'endroit du pont thermique.
Nous rencontrons alors à nouveau un « parking » dans l'échange CAO (vue architecte) vers une vue « génie climatique »
La période conditionnée par l'application de règlementations sévères de maîtrise de l'énergie apporte une complexité susceptible de modifier la définition des vues métiers concernés :
Complément :
Ces deux exemples montrent bien qu'un important travail de recherche reste à accomplir, non pas sur la norme IFC, qui a déjà prévu les classes d'objets nécessaires à la représentation des vues métiers, mais sur les correspondances graphiques entre les objets de chaque vue métier.
Autrement dit, sur les automatismes à mettre en jeux au niveau des logiciels métiers, afin d'éviter aux utilisateurs des saisies complémentaires qui annulent les performances de l'interopérabilité. Préalable qui concerne la modélisation dynamique des échanges.
Problème à résoudre à la charge, nous semble-t-il, soit des éditeurs de CAO, soit d'éditeurs d'une nouvelle génération de logiciels de saisie indépendante.
L'intelligence de cette nouvelle catégorie de logiciels serait suffisante pour produire des embryons de vues graphiques métiers normalisées IFC, capables d'être lues par les différents logiciels métiers.
Cette intelligence serait surtout utilisée pour alimenter une base de données unique BIM centralisée. Et surtout, devant la difficulté, ne pas décider deux BIM séparés, l'un pour les calculs thermiques, l'autre pour les calculs de structure, comme l'imaginent par exemple les membres des pays nordiques de BuildingSmart. Cette conclusion hâtive serait la négation de l'interopérabilité.
Remarque :
En conclusion, la France est confrontée à la résolution de deux problèmes prioritaires pour favoriser l'émergence des pratiques interopérables :
L'un du domaine de la recherche appliquée : comment rendre fluide la communication entre les différents systèmes de représentation graphiques utilisés par les métiers (la correspondance entre les « vues métiers »), problème situé dans l'environnement des IFC, mais ne relevant pas de la norme. Problème auquel s'ajoute la conception d'un modèle dynamique des échanges, peut être à normaliser lui aussi.
L'autre est le contournement d'un blocage apparent vers les pratiques du à un manque de formation aux compétences nécessaires qui doivent être nécessairement interprofessionnelles et utiliser les TIC et les TICE.
Deux actions urgentes à réaliser à court terme. Cinq ans paraissent raisonnables.
