« IFC Object Reference Manual »
Ce chapitre exploite la description des données du modèle conceptuel[1] IFC (la révision 2).
Le manuel de référence des entités IFC fourni par BuildingSmart n'étant pas pratique pour un professionnel (à l'usage des informaticiens), nous avons réorganisé l'arborescence des entités IFC pour qu'elle se présente sous la forme d'une classification « naturelle » des composants et ouvrages du bâtiment, telle que les architectes, ingénieurs et techniciens ont l'habitude de la pratiquer.
Un professionnel partenaire des échanges doit savoir trier les objets dont il est responsable, d'abord pour constater s'ils sont présents dans son logiciel métier, ensuite pour les renseigner.
Il est donc indispensable de constituer un guide facile à consulter, qui liste les objets à échanger.
Nous avons choisi de la constituer selon une relation structurante du modèle IFC : la relation d'héritage[2]. La méthode utilisée se décompose en deux parties :
1 : On reconstitue une arborescence des objets autour des concepts « composants » et « ouvrages ».
Ces arbres sont inclus dans les différents schémas exprimés en « EXPRESS-G[3] », visibles dans une version interactive (pages HTML[4]) du document de référence du modèle IFC, qui permet de consulter en ligne à la fois les schémas et les références.
Pour faciliter la réorganisation, nous avons séparé l'arborescence générale des objets IFC en quatre parties : les objets relatifs aux espaces (locaux), les objets identifiés aux composants du bâtiment, les objets appartenant aux procédures, et les objets utilisés pour le contrôle des prix et de l'organisation du projet.
Enfin, nous listons également les objets relatifs au renseignement graphique des plans, comme les trames...
2 : Nous laissons de côté les objets relations[5], et écartons volontairement les informations seulement utiles aux informaticiens.
Le plus souvent, ces relations[5] se mettront en place à l'insu de l'utilisateur, par le logiciel métier. Par exemple, quand un objet graphique est « calé » contre un autre par l'opérateur, la relation qui découle de ce contact est interprétée automatiquement par le logiciel.
Il va de soi que si un logiciel métier ne gère pas automatiquement une relation, on attend de lui qu'une commande explicite invite l'utilisateur à compléter l'information.
En procédant ainsi, on simplifie énormément l'utilisation du modèle IFC, qui devient facile pour un utilisateur seulement préoccupé de son métier, avec une période de formation très courte.
Remarque :
L'utilisation de la norme IFC n'est pas difficile.
C'est surtout la rigueur nécessaire dans le dessin et le renseignement du projet qui peut poser un problème à un opérateur, habitué aux approximations et aux impasses dans la pratique traditionnelle des logiciels graphiques.
Nous avons également écarté de la liste d'objets à renseigner du modèle IFC la plus grande partie des entités du niveau des ressources (voir "L'émergence d'une normalisation internationale : les IFC").
En effet, les entités de
géométrie (une très importante partie du modèle IFC)
unités (définies une fois pour toute dans un projet)
sont également prises en compte automatiquement par le logiciel d'application.
Le résultat ? Une organisation d'objets regroupés par analogie, et seulement trois types d'information associée à chaque objet[6] de l'arborescence :
ses types définis[9].
Ces listes ne sont pas triées selon les activités des utilisateurs, ou du logiciel utilisé. Cet aspect est abordé plus loin.
D'une révision à l'autre du modèle d'échange, les données du modèle IFC peuvent varier, chaque fois plus complètes.
Pour les révisions ultérieures, il suffira au lecteur de compléter les listes de cet ouvrage, en respectant la méthodologie utilisée.
