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.
Le noyau des IFC comprend 9 entités, dont celle qui nous intéresse pour l'instant : le « Produit ». 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 « Eléments spatiaux » sont les locaux du projet. Ce concept revêt une grande importance dans les pratiques anglo-saxones de la Construction. Il devient important en Europe, pour les responsables de la gestion de locaux et de la GTP, car c'est le concept principal exploité durant toute la vie du Bâtiment. L'utilisateur devra s'attacher à renseigner convenablement les entités de ce sous-modèle.
« Le bâtiment » est compris ici dans sa globalité. Peu d'informations y sont associées. De la même façon, « l'Etage » regroupe peu d'informations, mais la liste de tous les étages est fréquemment consultée.
Le « Site » regroupe toutes les informations du terrain, des aménagements extérieurs, des VRD.
Enfin, « l'Elément du bâtiment » 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 » du modèle IFC donne naissance avec ses extensions à l'arborescence de classes d'entités la plus riche des IFC. De structure ou Equipements ponctuels Associés à la Structure et d'innervation
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.
Un utilisateur peut limiter sa connaissance des IFC à deux concepts :
les classes d'objets représentant les ouvrages et composants de son domaine d'intervention,
les classes de propriétés 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.