Le “ménage” à faire dans le schéma IFC pour le rendre plus compréhensible

Peux-tu te décrire en quelques mots, ainsi que ton équipe ?
Après mes études d’ingénieur civil à l’INSA, j’ai intégré le groupe de recherche “Méthodes Innovantes pour la Construction” dirigé par Bernd Domer (Dr. Pr.) en tant que collaborateur scientifique, motivé à l’idée de travailler sur des sujets très orientés computer science/data science car cela correspond à mes centres d’intérêt et à mes compétences.

Notre équipe, basée à l’HEPIA à Genève, nourrit de grandes ambitions : la première est de soutenir la transition numérique du secteur de la construction en Suisse (par la réalisation de projets de recherche complexes et une offre de formation de qualité), l’autre est de montrer que la Suisse possède un certain savoir-faire dans ce domaine (par des publications et plusieurs participations à des conférences réputées à l’international).

Au niveau de l’enseignement, nous co-dirigeons le CAS en Coordination BIM avec la HEIA-FR (j’en profite pour indiquer que les inscriptions pour l’édition 2024, qui débutera au mois de janvier prochain, sont ouvertes) et enseignons le BIM aux étudiants de Master à la HES-SO ainsi qu’à l’EPFL.

Notre thème de prédilection est l’interopérabilité et l’openBIM. À ce sujet, je vous invite à vous procurer l’ouvrage que nous avons co-écrit avec nos collègues chercheurs du LIM.lab de l’Université de Padoue (Italie) intitulé “Interoperability : an introduction to IFC and buildingSMART standards, integrating infrastructure modeling“, et qui paraîtra ce mois-ci aux éditions EPFL Press.

Peux-tu me donner une définition simple des IFC ?
Les IFC sont aux logiciels BIM ce que l’anglais est pour nous : un outil permettant un échange d’informations entre deux entités qui communiquent différemment. Mais contrairement à l’anglais, les IFC ne correspondent pas à un langage, mais à un modèle de données et à un format d’échange.

Qu’entendons-nous exactement par “format d’échange” ? Pour commencer, il faut tout d’abord rappeler que la méthode principalement utilisée par les logiciels BIM pour “communiquer” de l’information est de stocker le flux d’information (c.-à-d., les données de la maquette numérique) dans un fichier. Lorsqu’un logiciel à une façon de représenter (coder) les données qui lui est propre, on parle de format de données “natif”.

Il existe de nombreux logiciels BIM travaillant chacun avec leur propre format de données. Si leur utilisation est avantageuse dans le cas où l’échange d’information se fait entre les mêmes logiciels, les premières difficultés apparaissent lorsqu’il s’agit de logiciels différents, car, bien souvent, ils ne sont pas en mesure d’interpréter le format de données de l’autre.

Pour résoudre ce problème, la solution est toute trouvée : un format de données “universel”, permettant la communication entre tous les logiciels ! C’est précisément la définition d’un format d’échange. Le format IFC a été développé dans le but de permettre à tous les logiciels BIM d’échanger des informations. Il s’agit d’un format de données interopérable et ouvert, indissociable au flux de travail openBIM.

Celui-ci est bâti sur un modèle de données appelé “schéma IFC”, qui décrit un ensemble de concepts relatifs au domaine de la construction et à ses différentes disciplines. Ces concepts sont ce que l’on nomme dans le jargon informatique des “classes”, d’où l’origine du nom “IFC” (abréviation de Industry Foundation Classes).

Les IFC 4.3 et les IFC 5 sont souvent confondus, pourquoi ?
Cela fait déjà quelques années que la mise à jour du modèle de données IFC dans le but d’y intégrer certains concepts spécifiques aux infrastructures a été initiée. buildingSMART a d’ailleurs beaucoup communiqué à ce sujet, et cela a naturellement créé beaucoup d’attentes. Au moment de l’annonce de cette mise à jour, la dernière version officielle du schéma IFC (c.-à-d., certifiée ISO) était la version 4. La communauté d’utilisateurs s’attendait donc à ce que cette prochaine version soit baptisée “IFC 5”, or ce n’est pas le cas ! Il s’agit de la version IFC 4.3, buildingSMART ayant réservé le nom IFC 5 pour les IFC “de prochaine génération”.

Quels sont les avantages de la nouvelle version IFC 4.3 (et bientôt 4.4) par rapport à la version 4 ?
Cela se résume en un mot : infrastructures. La version IFC 4.3 permet aux utilisateurs d’échanger des informations concernant les infrastructures routières et ferroviaires (y compris les ponts), alors que les version 2×3 et 4 ne peuvent être utilisées que pour des cas d’usage dans le domaine du bâtiment. Il s’agit là d’une petite révolution, car désormais la mise en place d’un flux de travail openBIM devient envisageable pour des projets de travaux publics. Les tunnels ne sont pas couverts par les IFC 4.3, ils le seront dans la prochaine version (IFC 4.4) prévue pour la fin de l’année.

Selon toi quelle est la principale problématique du schéma IFC ?
Il ne s’agit pas d’une opinion personnelle, mais d’une analyse partagée par de nombreux spécialistes sur le sujet, que buildingSMART International a notamment développé de façon assez exhaustive dans sa feuille de route ¹.

Le principal défaut des IFC est qu’ils ont été pensés et optimisés pour l’échange de fichiers. C’est ce qui a motivé le choix d’utiliser EXPRESS (langage de modélisation des données, ISO 10303-11) pour construire le schéma IFC, raison pour laquelle les fichiers que l’on s’échange aujourd’hui sont des fichiers STEP (STandard for the Exchange of Product model data, ISO 10303-21).

Seulement, depuis la fin des années 90 (période pendant laquelle les IFC ont vu le jour), les technologies ont beaucoup évolué, de même que les besoins des utilisateurs. Le domaine de la construction n’y échappe pas, et aujourd’hui tous les regards sont se portent désormais vers la “Construction 4.0”, synonyme de “tout-connecté”. Il ne s’agira plus d’échanger des modèles entiers via des fichiers comme on le fait aujourd’hui, mais de mettre à jour certaines informations très précises d’un modèle en s’appuyant sur des échanges transactionnels.

Dans cette nouvelle révolution numérique, les IFC auront bien entendu un rôle important à jouer, mais pour cela de nombreuses contraintes techniques (en partie liées au niveau élevé de sophistication du schéma IFC) vont devoir être levées. Pour être plus concret : le schéma IFC doit être repensé.

Qu’entends-tu par “repenser le schéma IFC” ?
Le simplifier et l’adapter aux nouveaux besoins des acteurs de la construction ! Au fil du temps, le schéma s’est étoffé et s’est considérablement complexifié. Il a désormais atteint un niveau de maturité suffisant pour réaliser une immense variété de cas d’usage. Mais en pratique, de nombreux cas d’usage sont impossibles à réaliser (en particulier dans le domaine du BIM2SIM) en raison des limites rencontrées par les logiciels lorsque l’on travaille avec le format IFC.

Alors qu’ils devraient être LA solution pour l’interopérabilité, les IFC sont souvent perçus comme une source de problèmes. Cela les rend peu désirables et détourne certains utilisateurs vers d’autres solutions, comme par exemple Speckle (même si les deux ne sont pas comparables).

Pour gagner en intérêt, les données IFC devraient pouvoir être encodées dans des formats plus modernes comme JSON ou RDF, couramment utilisés lorsque l’on travaille avec des bases de données. Certes, il existe déjà des outils pour convertir un fichier IFC-STEP dans ces formats, mais leur maintenance n’est pas garantie. Par ailleurs, les résultats peuvent être insatisfaisants en raison des différences entre le schéma original (IfcEXPRESS) et ses équivalents en JSON (IfcJSON) et OWL (IfcOWL). Ainsi, désolidariser le schéma IFC du langage EXPRESS est un vrai sujet pour buildingSMART.

L’autre sujet important, c’est le “ménage” à faire dans le schéma IFC pour le rendre plus compréhensible et réduire les efforts d’implémentation. À cet effet, il est envisagé de modulariser le schéma IFC, c’est-à-dire de le séparer en plusieurs modules indépendants (chacun spécifique à un domaine «métier »). Ce changement impliquera naturellement la révision du processus de certification des logiciels.

Par ailleurs, le buildingSMART Data Dictionary (bSDD), un catalogue de classifications et de propriétés accessible en ligne, permettra à chaque utilisateur d’ajouter aux objets de son modèle de la sémantique spécifique au contexte réglementaire dans lequel son projet est réalisé (exemple : propriétés venant des normes SIA). Le contenu du bSDD correspond donc à la dernière “couche de spécification” des données de la maquette numérique.

Quels seront les changements pour nous ?
Dans la mesure où les contraintes techniques liées à l’exploitation des données IFC seront réduites, on peut s’attendre à une évolution significative des outils existants ainsi que l’apparition de nouvelles solutions pour la spécification et le traitement des données IFC. Grâce aux échanges de données transactionnels, le développement des jumeaux numériques va pouvoir être accéléré. Aussi, en adéquation avec notre époque, l’intelligence artificielle aura très probablement un impact significatif sur l’industrie de la construction, dans la mesure où les flux de données seront bien plus importants.

Pour les utilisateurs, tout cela se traduira par une multiplication des cas d’usage et de nouveaux besoins en compétences. Sur ce point, nous continuerons à les accompagner, avec le soutien de Bâtir Digital Suisse bien entendu !

Interview: Brigitte Manz-Brunner

¹ buildingSMART International (2020), buildingSMART Roadmap.