Spécialisation de la classe « Produit »
Les 14 grandes familles d'entités IFC du précédent schéma sont donc des « Objets » au sens des structures et langages informatiques, mais sont aussi des objets du projet, au sens de nos métiers de la construction (attention, les révisions ultérieures des IFC introduisent d'autres familles).
Le noyau des IFC comprend 9 entités, dont celle qui nous intéresse pour l'instant : le « produit[1] ». Ce qui la distingue des autres, c'est que le produit est considéré comme une entité physique, qui participe directement au bâti (au contraire des documents, process, informations sur le projet ... et autres concepts abstraits)
Le produit se spécialise à son tour en 5 classes d'entités qui méritent un commentaire pour la signification donnée par les IFC.
Les « éléments spatiaux[2] » sont les locaux du projet. Ce concept revêt une grande importance dans les pratiques anglo-saxones de la construction. En effet, le « local », c'est-à-dire le volume, constitue l'objet initial avec lequel les architectes anglo-saxons ont l'habitude de concevoir l'esquisse du projet. Ils appliquent un organigramme de fonctionnement en 3 dimensions aux espaces, qui détermine la forme initiale du bâtiment. Et c'est ensuite seulement qu'ils étudient l'enveloppe, dont les murs.
Au contraire les architectes de culture latine et française pratiquent en majorité une méthode inverse. Ils commencent leur esquisse en traçant des murs. Les volumes, leur organisation spatiale, et bien souvent fonctionnelle, n'en est qu'une conséquence.
Le concept d'espace, de volumes, devient important en Europe, pour les responsables de la gestion de locaux et de la GTP[3], car c'est le concept principal exploité durant toute la vie du bâtiment, auquel sont attachés un grand nombre d'informations. L'utilisateur devra s'attacher à renseigner convenablement les entités de ce sous-modèle.
« Le bâtiment[4] » est compris ici dans sa globalité. Peu d'informations y sont associées.
De la même façon, « l'étage[5] » regroupe peu d'informations, mais la liste de tous les étages est fréquemment consultée.
Le « site[6] » regroupe toutes les informations du terrain, des aménagements extérieurs, des VRD[7].
Enfin, « l'élément du bâtiment[8] » concerne le reste, c'est à dire l'essentiel de ce qui est contenu dans un bâtiment.
Ce concept intermédiaire du niveau « interopérable[9] » du modèle IFC donne naissance avec ses extensions à l'arborescence de classes d'entités la plus riche des IFC.
Curieusement, les IFC n'ont pas créé de concepts intermédiaires pour séparer les équipements des composants de structure ou associés, ceux qui nous intéressent.
L'arbre d'héritage complet en suivant la flèche de gauche devient :
Selon les définitions des IFC, les composants d'escalier font partie du domaine de l'architecture. Ils ne sont pas partagés avec les autres domaines.
L'utilisateur retiendra de cette arborescence d'entités IFC -une parmi la dizaine qui est actuellement décrite- deux conclusions :
Pour une famille donnée d'entités -ici les composants de structure et associés- il dispose d'une liste précise de classes normalisées. Selon son rôle, l'utilisateur est concerné par la totalité ou certaines d'entre elles. Pour un architecte, il est clair qu'il devra décrire la totalité de ces classes de composants, s'ils existent dans son projet. Son logiciel le lui permettra-t-il ?
Chaque classe de composant est décrite également par un ensemble d'informations normalisées. En supposant que le logiciel utilisé soit complétement conforme à la norme IFC, cette description pour celui qui transmet, ou son décodage, pour celui qui reçoit, constitue la tâche essentielle de l'utilisateur.
C'est l'objet de la deuxième partie de l'ouvrage d'en évoquer plus concrètement les méthodes.
Remarque :
Un utilisateur peut limiter sa connaissance des IFC à deux concepts :
les classes d'objets représentant les ouvrages[10] et composants[11] de son domaine d'intervention,
les classes de propriétés[12] associées.
Il appartient à l'utilisateur de renseigner ou d'interpréter ces informations normalisées pour chaque individu (occurrence) présent dans son projet.
Ce sont les logiciels applicatifs qui se chargent du reste. Du moins, on l'espère.