Échange Architecte vers Ingénieur de structure
Autrement dit les échanges d'un fichier IFC depuis la CAO vers le calcul de structure.
Les progiciels du marché, lors des études de projets, élaborent des « vues » métiers restrictives par rapport à l'étendue des vues réunies de l'ensemble des métiers.
Certains échanges ne fonctionnent pas d'une manière fluide. L'utilisateur doit investir du temps et des efforts non négligeables pour corriger et compléter un fichier qu'il reçoit, afin d'alimenter son propre logiciel métier. Ce qui interdit la rapidité de réaction nécessaire dans une organisation interopérable, introduit des erreurs. Et suppose un investissement non négligeable. Donc met en péril l'émergence de l'interopérabilité.
Pourquoi cette discontinuité ?
Il ne faut surtout pas l'imputer à la norme IFC !
La réponse a été donnée dans l'unité de cours N°8 « Peut-on extraire toutes les vues métiers d'une seule maquette numérique ? » et notamment dans le paragraphe 8.2 « La nature des incompatibilités des échanges ».
Nous reproduisons ci-dessous le schéma de principe du paragraphe 8.4.2 en remplaçant le concept « Système de représentation graphique » par « Vue graphique », ce qui est équivalent, la vue graphique étant spécifique à une « vue métier ».
La vue « Composants » est celle adoptée par la quasi-totalité des logiciels de CAO 3D du marché. La vue « Axes de structure » est celle adoptée par la quasi-totalité des logiciels de calcul de structure. Un échange de données fluide d'un logiciel de CAO vers un logiciel de calcul de structure est donc selon ce schéma source de problèmes de traduction d'une vue métier en une autre (le parking).
Les IFC ne sont pas en cause. C'est un problème de logique, plus exactement topologique.
L'explication en est aussi donnée dans l'unité 8 : la plupart des logiciels de CAO n'obligent pas l'utilisateur, qui saisit les composants du bâtiment et les empile l'un au dessus de l'autre, et côte à côte, à respecter une coordination topologique des axes de ces composants dans l'espace.
Il en résulte qu'un logiciel de calcul de structure ne peut d'une manière automatique retrouver facilement, c'est-à-dire automatiquement, la « vue » dont il a besoin dans le fichier IFC fourni.
Il existe bien des classes d'objets « axes » dans le modèle IFC, mais le logiciel de CAO est incapable de les remplir correctement, en réalisant un graphe de lignes, facettes et nappes topologiques, c'est-à-dire que chaque barre doit être connectée aux autres par l'intermédiaire de « nœuds ». Les nœuds permettant la mise en place du réseau relationnel entre les objets
(ce n'est pas encore un redécoupage du bâtiment en éléments finis, mais il le prépare).
D'ailleurs, obliger l'architecte à saisir en plus les objets de la vue « structure » est utopique. Ce n'est pas « son métier ». Que faire ?
Ou bien, le logiciel de CAO se charge d'automatiser cette opération. Mais alors il n'est peut être pas assez « intelligent », car le problème est difficile.
Ou bien cette opération est mise à la charge du logiciel de calcul de structure. Mais il doit alors devenir aussi plus intelligent sur une prestation qui déborde de son domaine de compétence. Autre problème : cette prestation peut remettre en cause l'organisation des composants telle que saisie par l'architecte, avant tout calcul.
Ou bien il faut imaginer un contournement. C'est possible. Ce problème a déjà été examiné et en partie résolu il y a une vingtaine d'années. Puis oublié, car le marché de l'interopérabilité et des échanges de données n'existait pas encore.
