Qu'est-ce que le format IFC ? Interopérabilité des logiciels BIM

IFC (Industry Foundation Classes) est un modèle conceptuel de données et un format de fichier qui permet l'interopérabilité des logiciels BIM. L'IFC facilite la gestion et l'échange d'informations dans un projet de construction (bâtiment ou infrastructure) utilisant la maquette numérique.

Si l’on se réfère à la norme ISO/IEC 2382 relative aux technologies de l’information : « l’interopérabilité se définit par la capacité de communiquer, d’exécuter des programmes ou de transférer des données entre divers systèmes, sans pour autant que l’utilisateur ait besoin de connaissances approfondies sur les caractéristiques uniques de chaque système ». De façon pratique, cela implique l’élaboration d’un standard ouvert (ou mieux encore : une norme) que les interfaces de logiciels doivent respecter.

BuildingSMART (anciennement nommée IAI : International Alliance for Interoperability) est l’organisation en charge de promouvoir l’OpenBIM dans l’industrie du bâtiment. Afin d’atteindre son objectif, celle-ci a collaboré avec le groupe STEP-ISO (STEP pour : « STandard for the Exchange of Product data model »). En fin de compte, l’Industry Foundation Classes est né de cette collaboration. D’autre part, BuildingSMART gère et développe deux standards ouverts (ceux-ci ne sont pas des normes ISO) : le BCF-BIM Collaboration Format et l’IDS (Information Delivery Specification).

La norme et le standard se distinguent par leur degré d'autorité respectif.

Alors qu’un standard s’impose naturellement par l’usage du plus grand nombre, c’est toujours un organisme de normalisation officiel qui édite une norme. De plus, cette édition résulte systématiquement d’un enchainement formel d’études que des spécialistes réalisent, puis du consensus qui s’en dégage. Par conséquent, une norme aura toujours un degré d’autorité plus élevé et sécurisera bien plus une activité ou un matériel qu’un standard. Il est donc préférable que l’interopérabilité se fasse à travers l’établissement d’une norme plutôt qu’un standard ouvert ; c’est pourquoi nous avons exprimé cette préférence dans le paragraphe précédent.

L'OpenBIM a donc fait une grande avancée lorsque le modèle conceptuel de données IFC est devenu la norme ISO 16739 !

L’AFNOR édite cette norme, avec pour intitulé : «IFC Industry Foundation Classes pour le partage de données dans les industries de la construction et de la gestion des installations ». La norme ISO 16739-1:2024 définit l’IFC version 4.3. La documentation technique buildingSMART publie cette même spécification sous la référence IFC 4.3.2.0, enrichie d’exemples pratiques et de clarifications pour faciliter l’implémentation par les éditeurs de logiciels.

⚠️ Contrairement à l’interopérabilité, la compatibilité entre deux logiciels BIM n’implique pas l’existence d’un standard ouvert. Effectivement, cette dernière nécessite seulement que les éditeurs de softwares s’accordent pour créer des interfaces spécifiques ; ceci afin qu’ils puissent communiquer entre eux.

Quelles sont les différences entre Open-BIM et Closed-BIM ?

L'OpenBIM

Cette expression décrit l’application de nos cas d’usage en recourant à l’interopérabilité des différents softwares que nous utilisons et donc à l’usage d’un format IFC. Tout d’abord, l’OpenBIM permet d’avoir une liberté optimum pour le partage des informations, ce qui permet aux différents métiers de la construction de réaliser facilement des processus collaboratifs autour de la maquette numérique. En effet, sans l’Industry Foundation Classes : nous devrions créer, pour chaque logiciel, un nombre considérable d’interfaces en écriture et lecture ; ceci afin de permettre aux divers acteurs du BTP de communiquer malgré tout. Alors qu’avec l’Open-BIM, les logiciels doivent uniquement se doter d’une interface double (import et export). Enfin, cette méthode permet aux acteurs de la construction d’obtenir une certaine indépendance vis-à-vis des éditeurs de logiciels métiers !

Le Closed-BIM

Dans ce cas-ci : les échanges d’informations entre acteurs du projet se font avec le format de fichier « natif » (un standard définissant un format natif appartient à l’éditeur du logiciel). Avec ce flux de travail, basé sur la compatibilité des standards, a l’avantage de s’affranchir de tout problème possible d’export, mais le désavantage de fonctionner « dans un circuit fermé », où les éditeurs décident de tout. Par ailleurs, quand nous parlons de Closed-BIM, nous pensons rapidement au logiciel Revit de l’éditeur Autodesk. En effet, celui-ci est le principal logiciel de modélisation BIM permettant de travailler facilement et efficacement dans les trois disciplines principales : Architecture, Structure et MEP. Cependant, le logiciel Revit Autodesk a ses limites ! Par exemple, pour des réalisations de structures métalliques complexes, il serait peut-être préférable d’utiliser Tekla Structure, ou encore cadwork pour des structures bois. Enfin, beaucoup d’architectes préfèrent le logiciel Archicad à Revit pour sa souplesse et sa simplicité d’utilisation.

Par ailleurs, le format IFC donne une meilleure confiance que tout format natif, quant à l'accessibilité de la data dans le temps.

En effet, par définition, un format natif se rattache à un logiciel spécifique et donc à une société qui peut disparaître assez facilement (selon une appréciation du temps que nous basons sur la durée d’un cycle de vie pour un bâtiment).

Schéma et format IFC pour l'industrie du bâtiment :

L'ISO 16739 décrit clairement deux aspects différents, mais complémentaires pour l'Industry Foundation Classes :

Attention ! Il ne faut pas confondre le format de fichier IFC, tel que IFC-SPF par exemple ; avec la version du MCD (spécification du schéma). Ainsi, nous pouvons citer pour exemple de spécification : l’IFC 2x Edition 3 Technical Corrigendum 1 (IFC 2×3 TC1).

Qu'est-ce qu'un Modèle Conceptuel de Données ?

Un modèle conceptuel de données ou MCD propose une description formelle des concepts présents dans une base de données et cela sans ambiguïté sur l’interprétation des dits concepts. Ainsi, ce modèle s’attache à une description sémantique très précise de la data ; son élaboration est une condition « sine qua non » pour la construction de toute base de données ou tout format d’échange. En outre, afin de décrire le MCD, nous utilisons un langage de spécification formelle qui s’accompagne d’une convention de représentation graphique. Par exemple, pour notre sujet, le langage choisi est : « l’EXPRESS », avec pour méthode de représentation graphique « l’EXPRESS-G » ; la norme ISO 10303-11 décrit le langage EXPRESS.

Nous parlons ici d’un MCD réalisé avec une orientation objet. Par conséquent, il ne faut pas assimiler sa conception à celle des MCD prévus pour les bases de données relationnelles ; qui au demeurant sont les plus répandus encore actuellement.

Les trois principaux formats :

IFC-SPF (IFC-STEP-File) : c'est le format de fichier IFC que nous utilisons majoritairement en Open-BIM ; l'extension de fichier sera : ".ifc". Ce format IFC permet d'obtenir des fichiers avec une taille relativement réduite. Par ailleurs et comme son nom l'indique, il utilise le STEP-File, qui est une forme "d'encodage en texte clair"; autrement dit : le STEP-File est une méthode normée (ISO 10303-21) de transcription des données sous la forme d'un texte lisible par un humain. Au final, le texte est encodé en une suite de "bits"qui sera stockée dans un fichier IFC.

Du fait de l’encodage en texte clair, vous pouvez ouvrir un fichier IFC (.ifc et .ifcXML) avec votre éditeur de texte préféré. Par exemple, voici un court extrait d’un fichier IFC-SPF. Ainsi, chaque ligne correspond à un objet IFC : sa classe d’appartenance est mentionnée, puis les valeurs de chaque attribut.

IFC-XML : L'extension de ce format de fichier IFC sera : ".ifcXML". Ainsi, nous utilisons ici "l'Extensible Markup Language" pour encoder les données. L'XML donne des textes plus facilement lisibles qu'avec le STEP-File. Cependant, l'utilisation du format IFC-XML donne des fichiers 3 à 4 fois plus volumineux qu'avec le format IFC-SPF.
IFC-ZIP : c'est un fichier au format IFC-SPF ou XML auquel nous avons appliqué l'algorithme de compression PKZIP. L'extension de ce format IFC sera : ".ifczip".

Pour bien comprendre le fonctionnement des IFC-Industry Foundation Classes, nous vous conseillons de les aborder sous l'angle d'un schéma qui permet de classer et donc structurer toute la data d'un modèle ; plutôt que sous l'angle d'un format.

Notions d’objet et de classe.

La notion d'objet dans les IFC :

Selon la norme ISO 16739, un objet est défini de la façon suivante : « toute chose perceptible ou concevable qui a une existence distincte, même si cette existence n’est pas matérielle ». Un objet unique au sein d’une classe IFC se nomme : occurrence. Néanmoins, en programmation orientée objet, nous parlons également : d’instance d’une classe. Enfin, nous pouvons préciser que selon le MCD IFC, les acteurs (personnes morales ou physiques) du projet sont des objets !

⚠️ Tous les objets IFC ne sont pas instances de l’entité « ifcObject ». Par exemple, les relations entre objets sont également des objets IFC !

Classification et entité IFC :

La norme ISO 16739 définit la classification ainsi : «catégorisation, action consistant à répartir des choses dans des classes ou des catégories du même type». De plus, une entité IFC (nous parlons également de « classe IFC ») est similaire à une classe en programmation orientée objet, avec un point de différence cependant : tout comme une classe en POO, une entité IFC regroupe les objets selon un comportement et des attributs communs ; néanmoins, celle-ci ne s’occupe pas des méthodes (informatiques) de traitement de la data.

Un triptyque définit tout objet IFC :

Très souvent, les développeurs qui utilisent un langage de programmation orientée objet parlent « d’entité » pour désigner une instance de classe. Cependant, il ne faut pas confondre avec notre vocabulaire à nous (utilisateurs BIM de l’Industry Foundation classes) où une entité IFC est une classe IFC et n’est pas une occurrence (objet unique). Désolé, nous insistons afin d’éviter toute confusion !

Les principales notions de l'Industry Foundation classes viennent du paradigme de la Programmation Orientée Objet (POO).

Dans ce paradigme, un objet est une entité autonome possédant un ID unique. De plus, un objet se compose à la fois d’une base de données et de méthodes pour traiter ces données. En conséquence, une classe décrit ici : un regroupement d’objets selon des types de données et des méthodes de traitements identiques.

La notion d'héritage en programmation orientée objet : " je suis ton père !"

Le concept d’héritage permet d’établir une relation de similarité entre des classes d’objets. Ainsi donc, avec deux classes A et B : si « B est une classe fille de A », cela veut dire que B est un sous-ensemble (sous-classe) de A. Par conséquent, tout objet instance de B sera, de facto, instance de A. Autrement dit : les objets de la classe B « hériteront » de l’ensemble des caractéristiques de la classe A. De plus, les objets de la classe B auront tous, au moins une caractéristique supplémentaire qui leur sera commune. Prenons un exemple simple et plus concret, avec « la classe » des mammifères pour A et la « classe fille » des cétacés pour B. Nous pouvons observer que tous les cétacés héritent des caractéristiques propres aux mammifères : allaitement des juvéniles, etc. Mais ils possèdent en plus des caractéristiques communes aux cétacés : une nageoire caudale par exemple.

Une application orientée objet est un ensemble d'objets qui communiquent entre eux.

Pour conclure, le fait de s’intéresser (un minimum) au fonctionnement du paradigme de programmation orientée objet vous permettra de mieux appréhender le fonctionnement de tous vos outils.

maquette IFC BIM : comment la DATA d'une construction est-elle structurée ?

La représentation d’une construction se fait habituellement par une succession de plans (de calques) pouvant être très précis, mais incapables d’interagir. L’un des enjeux avec l’utilisation des softwares BIM et de faire passer les études de conception et exécution : d’un ensemble de dessins, à une logique de LEGO avec des briques intelligentes. Nous qualifions ces briques (objets IFC) « d’intelligentes », car elles établissent des relations et contiennent de nombreuses informations. Ainsi, avec le Building Information Modeling : nous associons des composants et des ouvrages, ces objets forment les espaces de nos bâtiments et infrastructures et ont de multiples relations dynamiques.

La relation d'héritage est l'une des familles de relations qui structurent le plus l'IFC !

La notion d’héritage pour l’Industry Foundation classes est identique à celle que nous avons décrite dans le paradigme de la programmation orientée objet. D’autre part, afin de décrire la vue d’ensemble des relations d’héritage selon le modèle conceptuel IFC, nous parlons d’un « arbre d’héritage » ; tout comme un arbre généalogique, celui-ci est inversé : le tronc est en haut et les feuilles sont en bas ! Ainsi, lorsque nous descendons vers les feuilles, nous allons vers une « spécialisation » des classes. Inversement, quand nous allons vers le tronc (et donc vers « ifcRoot ») c’est une « généralisation ».

La classe "racine" du modèle conceptuel IFC : IfcRoot

Tout objet issu de IfcRoot se voit attribuer un identifiant (unique dans tout le monde numérique) que l’on appelle : « GUID » pour Globally Unique IDentifier ; le concept de GUID n’est pas spécifique aux IFC, mais au monde logiciel dans son ensemble. De plus, cet identifiant est un nombre de 128 bits (non égal à 0) ; la génération d’un GUID offre donc un nombre énorme de combinaisons possibles (2¹²⁸ – 1). C’est pourquoi la probabilité que nous générions 2 GUID identiques est infiniment proche de zéro ! Enfin, concernant les Industry Foundation Classes, chaque GUID est encodé sous la forme d’une chaine de 22 caractères que l’on peut qualifier d’ « IFC-GUID ».

⚠️ Le GUID permet la traçabilité de chaque objet IFC issu de IfcRoot. Par conséquent, il est impératif de le conserver lors de chaque export.

Une représentation simple du schéma IFC à partir de IfcRoot :

IfcRoot se spécialise en trois entités majeures :

IfcObjectDefinition classe toutes les individualités, de type ou d’occurrence. Une individualité est à comprendre comme tout ce qui peut avoir un nom avec une signification propre : « toute chose ou processus qui peut être traité sémantiquement ».
IfcRelationship classe toutes les relations entre les objets.
IfcPropertyDefinition classe l’ensemble des propriétés

Les spécialisations de ifcObjectDefinition :

IfcObject se spécialise ensuite :

IfcProduct : objets qui se rapportent à un contexte géométrique ou spatial.
IfcActor : personne, organisation.
IfcControl : toutes les règles de contrainte.
IfcGroup : collections d'objets.
IfcProcess : tâches et processus.
IfcResource : matériaux, main-d'œuvre et équipements.

L’idée ici est de présenter rapidement une partie de l'arbre d'héritage ; cependant, le sujet est très vaste. Par exemple, il existe plus de 1300 entités pour IFC4.3 !

Deux relations fondamentales structurent le modèle IFC selon des logiques distinctes et complémentaires :

1. IfcRelAggregates (hérite d’IfcRelDecomposes) : Établit des relations de composition/décomposition « tout-partie » entre objets IFC. Cette relation s’applique principalement dans deux contextes :

Construction de la hiérarchie spatiale : connexion des éléments de structure spatiale entre eux (IfcProject → IfcSite → IfcBuilding → IfcBuildingStorey → IfcSpace)
Agrégation d’éléments physiques en assemblages : regroupement de composants en sous-assemblages (par exemple, plusieurs profilés métalliques agrégés en poutre composite)

Par exemple, un IfcBuilding agrège plusieurs IfcBuildingStorey via IfcRelAggregates. Cette relation établit une hiérarchie où le parent peut, dans certains cas, dériver ses propriétés géométriques de la somme de ses enfants. La relation est bi-directionnelle et implique une dépendance mutuelle : le tout dépend des parties, et les parties dépendent du tout.

2. IfcRelContainedInSpatialStructure (hérite d’IfcRelConnects) : Assigne les éléments de construction (IfcWall, IfcDoor, IfcColumn, IfcBeam) à leur conteneur spatial de référence. Cette relation permet de localiser les objets physiques dans la structure spatiale du projet. Un élément de construction ne peut être contenu que dans UN SEUL conteneur spatial à la fois (relation hiérarchique stricte), ce qui établit sa position principale dans le projet. À noter que les éléments peuvent être référencés par plusieurs structures spatiales via la relation complémentaire IfcRelReferencedInSpatialStructure.

Les MVD sont des sous-ensembles du modèle conceptuel IFC destinés à nos cas d'usage bim

MVD est l’acronyme de Model View Definition.

Un partage de data se fait toujours dans un contexte de cas d’usage qui détermine des besoins spécifiques en matière d’information. Par conséquent, un partage de data ne concerne systématiquement qu’une partie, plus ou moins grande, du modèle conceptuel IFC et donc de la maquette numérique.

La norme ISO 29481 sur les IDM donne la définition suivante pour les MVD : « Définition interprétable par ordinateur d’une exigence d’échange, spécifiquement associée à un ou plusieurs schémas d’informations normalisés particuliers ». Néanmoins, nous pouvons donner une seconde formulation, peut-être moins rigoureuse, mais plus facilement compréhensible :

Une MVD est un "filtre" qui permet d’expliquer à un ordinateur, quelle partie utile de la base de données nous voulons transférer dans un cadre précis d’usage BIM.

Pour la spécification IFC 2×3 TC1 (publiée en 2007), les deux MVD les plus utilisées étaient Coordination View 2.0 et Structural Analysis View. Bien que ces MVD conservent officiellement leur statut FINAL et restent valides techniquement (legacy) ; buildingSMART recommande désormais l’utilisation d’IFC4 avec Reference View ou Design Transfer View pour tous les nouveaux projets, qui offrent des capacités étendues et une meilleure stabilité d’implémentation

Les retours d'expérience de Coordination View 2.0 ont conduit buildingSMART à repenser complètement l'architecture des MVD pour IFC4 et IFC 4.3. La stratégie actuelle repose sur trois niveaux d'implémentation progressifs, chacun correspondant à des cas d'usage distincts :

Reference View : elle constitue le niveau de base obligatoire. Cette MVD forme un sous-ensemble restreint et très stable du schéma IFC, conçu pour les flux de travail unidirectionnels où le modèle sert de référence non modifiable. Elle privilégie la géométrie en représentation "tessellée" (triangulée) pour garantir une visualisation fidèle dans tous les logiciels, même ceux qui n'ont pas de moteur géométrique paramétrique. Reference View est particulièrement adaptée à la coordination spatiale, la détection de conflits, la visualisation 3D, et le partage de modèles de référence sur plateformes collaboratives. La plupart des exports IFC que vous réalisez aujourd'hui utilisent cette MVD.

Export avec la MVD « Reference View » dans le logiciel de modélisation Revit Autodesk :

Alignment Based Reference View : est une MVD spécifique introduite avec IFC 4.3 pour répondre aux besoins des projets d'infrastructure linéaire. Elle étend Reference View en ajoutant le support des définitions d'alignement (IfcAlignment), essentielles pour modéliser routes, ponts, voies ferrées, et réseaux linéaires. Cette MVD représente une avancée majeure pour l'extension d'IFC au-delà du bâtiment vers l'infrastructure, permettant de définir des géométries complexes le long de tracés en plan et profil en long.
IFC4Precast : spécialement conçue pour l'échange de données de fabrication détaillées entre systèmes CAO et MES (Manufacturing Execution Systems) dans l'industrie de la préfabrication béton. buildingSMART International Contrairement aux autres MVD IFC centrées sur la coordination de projet, IFC4Precast est intentionnellement incompatible avec l'IFC4 Reference View standard Buildingsmart et utilise l'extension de fichier .ifcprecast plutôt que .ifc, reflétant des principes de modélisation fondamentalement différents optimisés pour la production industrielle automatisée.
Design Transfer View : elle représente le niveau d'implémentation le plus avancé. Cette MVD supporte la géométrie paramétrique complète, incluant les opérations booléennes, les extrusions, et les représentations CSG (Constructive Solid Geometry). Elle permet également l'utilisation des "standard cases" (IfcWallStandardCase, IfcSlabStandardCase, etc.), qui sont des éléments avec des règles de modélisation standardisées. Design Transfer View est conçue pour les échanges où le modèle doit rester modifiable après import, typiquement lors d'un transfert de projet entre phases (conception vers exécution) ou entre équipes utilisant des logiciels différents. L'implémentation de cette MVD est nettement plus complexe et moins répandue que Reference View.

Un logiciel bénéficie d’une certification pour un MVD précis : liste des outils BIM certifiés.

Nous utilisons Un IDM (Information Delivery Manual) pour définir un MVD.

Un IDM est une méthode pour décrire tout type de processus métier et le lier à un processus d’échange d’information. Le but est de connaître, avec exhaustivité et pour chaque tâche spécifique, les informations qu’un acteur doit fournir à un autre ; cette méthode est devenue la norme ISO 29481.

Un IDM contient :

Selon les cas : des cartes d’interactions, des cartes de transactions, ou plus couramment des cartes de processus établies selon la norme BPMN (Business Process Model and Notation)
Toutes les exigences d’échange déduites à partir de ces cartes ; il faut établir dans un langage compréhensible par les utilisateurs finaux (architectes ou ingénieurs), l’ensemble des informations devant être échangée à chaque étape des processus métiers.
Les procédures techniques d'implémentation du sous-ensemble IFC, en fonction des informations à échanger décrites précédemment.

Voici un exemple de carte de processus, pour un IDM lié à la préfabrication de composants en béton :

L’utilisation d’un IDM est plutôt réservée à des experts ou des développeurs informatiques. En effet, un IDM aide principalement à créer et implémenter une nouvelle MVD dans des logiciels. Ainsi, les BIM Managers et coordinateurs BIM utilisent généralement les MVD directement et ne se soucient pas de la méthode utilisée en arrière-plan pour les créer. Toutefois, dans certains cas complexes, un BIM Manager peut se servir d’un IDM comme modèle pour élaborer un processus et l’inclure dans une convention BIM. Enfin, la norme ISO 29481 suggère également que l’utilisation d’un IDM dans un projet de construction puisse être rendue contractuelle et donc être incluse dans un cahier des charges. Pour conclure, il existe actuellement une cinquantaine d’IDM qui ont été développés ou sont en cours de développement.

export de maquette BIM dans un format IFC

Lorsqu’à partir des logiciels métiers, nous exportons une maquette numérique au format IFC, il est important que chaque objet se voit classer dans la bonne entité IFC. De plus, ces objets doivent conserver les informations alphanumériques qu’un BIM modeleur lui aura associé de façon automatique ou manuellement. Finalement, ces informations alphanumériques pourront se retrouver dans des attributs directement rattachés à l’objet, ou plus majoritairement dans des jeux de propriétés (IfcPropertySet) ; un « PropertySet » est associé soit à un type d’objet, soit à une instance (objet unique). En fin de compte, quand nous parlons « d’objet BIM », nous pensons surtout à toutes les instances de la classe IfcElement. C’est-à-dire : à tous les éléments ayant une existence physique et qui interviennent dans la construction d’un bâtiment ou d’une infrastructure.

Qu'est-ce que le mappage de données ?

Le mappage de données consiste à dessiner une carte établissant une correspondance sémantique entre deux MCD ; nous pourrions également parler d’une carte ayant pour but de faire correspondre les champs d’une base de données source, aux champs d’une base de données réceptrice.

Pourquoi parlons-nous souvent d'un mappage de données ?

Nous avons vu que le mappage de données n’est pas un sujet propre au BIM et Industry Foundation Classes. Cependant, du fait que les logiciels métiers de Building Information Modeling possèdent tous leur propre MCD, il y a systématiquement un mappage lors de l’exportation des données du format natif au format IFC. Enfin, selon vos désirs et le contexte, ce mappage sera plus ou moins préconfiguré par l’interface d’export de votre software.