Le modèle des IF C

Le modèle des IF C

Pourquoi les IFC

Pendant une opération de construction, une grande quantité de documents est échangée entre les intervenants : plans, notes de calcul, spécifications, compte-rendu de chantier… La plupart de ces documents sont disponibles sous forme de fichiers et l’on a vu se développer de nombreux modes de transmission (CD, pièces jointes dans les mails…). Chaque acteur utilise son traitement de texte, son tableur, son outil de CAO, son fax, le courrier et le mail pour atteindre ces objectifs. Apportant un confort non négligeable, ces outils ne permettent malheureusement pas une gestion coordonnée du projet : chacun possède son propre format de fichiers pour les plans et autres documents et chacun passe souvent plus de temps à convertir, retrouver, parfois même recréer les informations du projet, qu’au projet lui-même (Cruz, 2004b)(Vanlande 2007). Ces problématiques sont d’autant plus d’actualité que l’on parle davantage de développement durable depuis ces cinq dernières années et que des contrôles sont nécessaires de plus en plus tôt dans le cycle de conception du bâtiment (Bazjanac et al., 2011). Par exemple, c’est le cas du thermicien qui doit intervenir au plus tôt et faire des simulations dès que possible sur le futur bâtiment. En conséquence, l’interopérabilité entre les outils de l’architecte et ceux du thermicien est essentielle. Pendant longtemps, le format DWG, standard de fait9 pour les plans numériques, a été le principal support de ces échanges, mais il reste fermé (car propriétaire) et une seule entreprise (Autodesk®10) décide de son évolution. L’IAI s’est fixée pour but d’améliorer l’interopérabilité des logiciels utilisés dans le secteur de la construction. Elle réunit aujourd’hui plus de 500 membres qui sont regroupés en chapitres en fonction de la langue ou de la proximité : Amérique du Nord, Australie, Corée du Sud, chapitre francophone, chapitre Germanophone, Benelux, Chine… L’IAI ne produit pas de logiciels, mais des spécifications destinées à faciliter l’échange et le partage d’informations entre logiciels. Le principal résultat des travaux de l’Alliance est un langage qui rassemble aujourd’hui plus de 700 classes d’objets et a pour nom IFC. Plusieurs versions des IFC ont été publiées, du fait de l’accroissement progressif du domaine couvert. Depuis octobre 2000 et à la demande des éditeurs de logiciels, le cœur du modèle a été stabilisé pour plusieurs années. Cette partie des IFC, appelée plateforme, a obtenu l’homologation de l’ISO sous la référence ISO/PAS 16739 :200511 (Liebich, 2010). La prochaine version des IFC, nommée IFC4, devrait voir sa version finale publiée en même temps que la norme internationale ISO/IS16739 (le nom ISO de la norme pour les IFC4). Les IFC définissent un nouveau standard international, pour échanger des informations techniques entre logiciels dédiés à la construction et au génie civil. Disponible en import/export avec la plupart des nouveaux outils de CAO pour architectes, ce format apparaît également dans d’autres outils du bureau d’étude (calcul de structure, analyses thermiques, économie du bâtiment…) et des applications de gestion du patrimoine. Avec les IFC, on n’échange plus uniquement des informations géométriques, comme avec le format propriétaire DWG (Autodesk), mais de vrais objets de construction (murs, poteau, poutre, portes, fenêtres, étage, escalier…), le but étant d’obtenir un langage qui contient des informations sur la forme, les attributs des composants ainsi que les liens entre ces composants. Les IFC basent leur logique sur l’utilisation du BIM (appelé aussi « maquette numérique »). Le BIM est un outil de structuration et d’échange de données techniques, reconnu par tous comme un atout indéniable en termes de performances économiques comme énergétiques. Le terme « maquette numérique » est couramment utilisé en France, mais reste ambigu sur le fait que sa portée dépasse le simple aspect de maquette physique ou maquette 3D. Un BIM à la norme IFC produit par l’architecte peut être exploité par de nombreux logiciels et constituer la base d’évaluations du projet : consommations, impacts, coûts…

Présentation de la norme IFC

Actuellement, la version stable utilisée est issue des spécifications IFC2x3 TC1 et comporte 653 classes ainsi que 327 Property Sets15 (Pset). La prochaine version, actuellement en release candidate 2, contient 759 classes et 393 Pset. La Figure 2 présente l’architecture générale de la spécification IFC 2×4 RC2. La base de cette architecture est une simplification de celle des IFC en version 2×3 (plus facile à lire). Cette architecture est destinée aux développeurs de logiciels qui veulent travailler avec les IFC (CAO par exemple) et est transparente pour l’utilisateur final. On peut distinguer quatre couches dans celle-ci : les cercles supérieurs regroupent les différents domaines, la ligne des rectangles juste en dessous forme la couche d’interopérabilité, les deux lignes en dessous (carrés + triangles) forment le cœur de l’architecture (avec le noyau et les extensions du cœur du schéma), et enfin les octogones forment la couche des ressources. Ces ressources sont organisées sous forme de graphes hiérarchiques comme l’illustre la Figure 3. Chaque couche de la plateforme ainsi définie comprend plusieurs catégories dans lesquelles sont définies les différentes classes. Les classes IFC sont entièrement décrites sur le site officiel de l’IAI Le modèle de données IFC ne représente pas seulement les éléments tangibles d’un immeuble comme les murs, les portes, les plafonds, le mobilier… mais aussi des concepts plus abstraits comme des plannings, des activités, des espaces, organisations, coût de construction… sous forme d’entités (classes). Chacune de ces classes possède un certain nombre de propriétés comme le nom, la géométrie, les matériaux, les finitions, les relations… (cf. Figure 3). Le modèle IFC définit également, en plus des classes et des Pset, des types de données définit (comme IfcAreaMeasure qui définit l’aire mesurée d’une surface), des types d’énumérations (comme IfcRoleEnum pour définir les rôles qui peuvent être joués par un acteur), des types de sélection (comme IfcColour qui définit l’apparence basique des éléments à afficher), des fonctions (IfcVectorSum), des règles (IfcSingleProjectInstance qui vérifient qu’une seule instance de IfcProject existe). Pour le format de fichier, l’IAI a retenu pour les IFC la norme internationale ISO 10303-21 (format STEP). Chaque ligne du fichier est composée de valeurs d’attributs dédiés ou hérités et commence par un identifiant de ligne et le nom de la classe IFC décrite. Le Script 1 est un extrait de fichier IFC, avec l’entête du fichier et les premières informations sur le propriétaire et l’application qui a servi à générer le fichier.