Le format IFC permet-il de stocker les données produits des industriels ?

Ce serait un euphémisme de dire qu’il règne une certaine confusion autour de la façon dont les industriels devraient intégrer leurs produits et systèmes dans des fichiers IFC. C’est dû en partie au fait que des termes tels que IFC, COBie, IDF, IDM, couramment utilisés dans la communauté BIM, restent très obscurs pour le grand public.

Les industriels sont de plus en plus conscients qu’ils doivent communiquer les caractéristiques de leurs produits en utilisant des données normalisées. C’est ici que commence la confusion, car les IFC, parfois assimilés au « format BIM », traitent un certain nombre de propriétés selon une logique propre. Les industriels en déduisent que la fourniture des leurs produits au format IFC répond à tous les besoins. Cette incompréhension est la raison pour laquelle cet article ambitionne fournir une aide à la compréhension des IFC.

Les IFC (Industry Foundation Classes) sont un format de données neutre et ouvert supportant l’échange et le partage de l’information. Les IFC ont été développées pour permettre l’interopérabilité mais ne la garantissent pas : toutes sortes de données peuvent être transportées en utilisant les IFC, cela n’implique pas que ces données sont structurées, de qualité, ou adaptées à l’usage que l’on veut en faire. Les IFC sont un format d’échange, ils ne doivent donc pas être utilisés pour organiser et définir la structuration des données. Pour être plus clair :

Les IFC sont en mesure de transporter les données fabricants mais pas de définir la structure de ces données en utilisant le schéma avec ses entités, property sets et propriétés actuels. Il est nécessaire de pouvoir réaliser un lien entre le modèle IFC et les données des industriels en développant une méthodologie dans laquelle les IFC utilisent des données stockées dans des dictionnaires basés sur la norme EN ISO 12006-3 (IFD) et comportant des propriétés et data templates basés sur les futures normes prEN ISO 23386 et prEN ISO 23387.

Il est vrai que les IFC proposent déjà un certain nombre de propriétés ; on peut par exemple y trouver des propriétés attachées à une fenêtre (IfcWindow) mais on n’y retrouve pas le jeu complet de propriétés nécessaire à la définition complète d’une fenêtre. Les IFC ne fournissent pas non plus d’information sur la provenance de ces propriétés (par exemple une norme), la méthode d’essai associée à la propriété (par exemple pour le U d’une paroi) ou tout autre information. Cela implique que si un architecte utilise une fenêtre comportant 20 propriétés et que seulement 4 de ces propriétés sont présentes dans le modèle IFC, les 16 autres seront échangées dans un Property Set propriétaire ; les propriétés contenues dans ce Property Set ne pourront pas être exploitées dans un autre outil automatiquement. Cela ne garantit également pas que ces propriétés sont définies de la bonne manière. C’est dans ce cadre là que les IFC ne permettent pas une interopérabilité totale.

Quelle est l’alternative ?

Les commissions de normalisation BIM, CEN/TC442 et ISO/TC59/SC13 travaillent, en relation avec buildingSMART International, sur des normes permettant de structurer et définir les données produits :

EN ISO 12006-3 : définit un modèle permettant de stocker les informations d’un dictionnaire.
prEN ISO 23386 : définit une méthodologie de description, gestion et maintenance de propriétés dans un réseau de dictionnaires.
prEN ISO 23387 : définit la structure d’un data template représentant un ouvrage.

Toutes ces normes réunies permettent que tous les termes et définitions des propriétés métiers du secteur de la construction soient décrites, structurées, traduites et mises à disposition pour tout le secteur. Cette méthodologie permet que les bonnes informations soient mises à disposition et échangées via l’utilisation des IFC. Il est important de noter que les industriels stockent leurs informations dans des bases de données différentes (type PIM, ERP, CRM) et que ces données sont à destination d’usages différents. Toutes ces données doivent pouvoir être échangées en IFC. Les rôles des IFC et des dictionnaires doivent être clarifiés afin de permettre aux différents outils d’échanger des données de qualité.

Les IFC disposent d’ores et déjà de mécanismes permettant de référencer des dictionnaires et de supporter la structuration proposée par la norme prEN ISO 23387. Le fait d’externaliser les propriétés métiers dans des dictionnaires permettra de mettre à disposition des utilisateurs des données de confiance parfaitement définies.

Aujourd’hui, Le dictionnaire le plus important est le buildingSMART Data Dictionary (bSDD) opéré par buildingSMART International. C’est, pour beaucoup, le fournisseur principal d’identifiants uniques (GUID) pour les propriétés métiers et a pour objectif de devenir le dictionnaire de données international du secteur de la construction. Les Data Templates, associés à un dictionnaire de données, permettent d’adresser la problématique de quelle propriété, selon quelle méthode d’essai utiliser dans un contexte particulier.

En résumé, cela signifie que les industriels peuvent utiliser des Data Templates pour structurer leurs données en utilisant des propriétés comportant chacune un identifiant unique. Ils peuvent ensuite utiliser le format IFC pour les échanger. Dès lors que les Data Templates ont été définis, architectes, ingénieurs, entreprises, peuvent les utiliser pour stocker leurs exigences puis interroger un catalogue pour trouver les produits correspondants.

Un Data Template présente de nombreux avantages à l’utilisation du format IFC

Il utilise une terminologie interprétable et applicable par les acteurs locaux. Par exemple, en IFC une fenêtre a une propriété « security rating » mais selon la Norme Européenne Harmonisée EN 14351-1 cette propriété n’existe pas, elle définit à la place 3 propriétés pour la résistance aux explosions, à l’effraction et aux balles.  Cette différence qui peut sembler minime peut s’avérer vraiment problématique ; comment définir des exigences sur ces 3 propriétés alors qu’on ne peut pas les échanger en IFC.

Comment gérer cette problématique ?

De telles disparités obligent les utilisateurs à réaliser des choix subjectifs qui ne seront pas forcément partagés par tous. Tous les métiers utilisent des terminologies qui leurs sont propres, un Data Template leur permet d’utiliser les termes qu’ils souhaitent. De plus l’usage d’un dictionnaire rend le Data Template indépendant de la langue grâce à l’utilisation d’un identifiant unique permettant d’accéder à une propriété et la traduction souhaitée. En pratique un industriel Allemand peut définir un Data Template dans sa langue puis des exigences peuvent être associées aux propriétés dans n’importe quelle langue. Les IFC, bien que parfaitement définis pour répondre à la problématique de l’échange, ne permettent pas d’adresser cette problématique.

digital twin

Structures de données dans un contexte local

Un autre inconvénient des IFC est que les propriétés qui y sont présentes, le sont à un niveau très générique pour s’adapter aux besoins d’un grand nombre et ne représentent pas les besoins répondant à des contextes locaux. Des propriétés telles que l’élasticité pour le métal ou le U sont soit absentes soit mal définies pour un usage ce qui pose des problèmes de compréhension et d’utilisation majeurs pour les acteurs de la construction.

D’un autre côté, un certain nombre de propriétés contenues dans un modèle IFC sont pertinentes pour la maquette numérique (tels que le statut – nouveau, existant, rénovation) alors que les propriétés d’un Data Template proviennent de normes et réglementations locales et doivent être mises à disposition des utilisateurs.

On peut dire que l’IFC est le « comment » et le PDT est le « quoi »

En conclusion, les IFC sont indispensables à l’échange et la collaboration au cours d’un projet de construction. Les IFC permettent donc aux industriels d’intégrer leurs produits dans une maquette numérique ; on traite ici le « comment » mais pas le « quoi ». Pour que la magie opère, l’utilisation des IFC doit être associée à la structuration de Data Templates et l’usage de dictionnaires.

2018-11-23T14:21:33+00:00novembre 23rd, 2018|