Format IFC : Comment le schéma de données structure les échanges BIM

Il existe plusieurs formats IFC !

IFC (Industry Foundation Classes) désigne un modèle conceptuel de données associé à plusieurs formats de fichiers. Ce standard normalisé assure l’interopérabilité des logiciels BIM et fluidifie les échanges d’informations sur tout projet de construction, bâtiment ou infrastructure.

Depuis 2013, l’IFC est enregistré comme norme internationale. La norme ISO 16739-1:2024 définit la version actuelle, l’IFC 4.3 : « Industry Foundation Classes pour le partage de données dans la construction et la gestion des installations ». buildingSMART International publie cette spécification sous la référence IFC 4.3.2.0, complétée d’exemples et de clarifications pour en faciliter l’implémentation par les éditeurs de logiciels.

Si les standards s’imposent par l’usage, les normes émanent d’organismes officiels après consensus d’experts. Elles offrent donc une sécurité et une autorité supérieures.

Interopérabilité : définition et enjeux pour le secteur de la construction

L’interopérabilité désigne la capacité d’échanger des données entre systèmes différents sans avoir à connaître leur fonctionnement interne (ISO/IEC 2382). Concrètement, nous pouvons transmettre un modèle Archicad à un ingénieur structure travaillant sous Tekla structures : chacun reste dans son environnement natif, les données transitent sans perte.

L’interopérabilité exige un standard ouvert ou une norme que les logiciels doivent strictement respecter.

⚠️ Compatibilité et interopérabilité diffèrent. La compatibilité repose sur des interfaces spécifiques, sans nécessiter de standard ouvert.

Schéma IFC et format de fichier : la distinction fondamentale

L'ISO 16739 décrit deux aspects complémentaires des IFC, à bien distinguer :

⚠️ Attention à ne pas confondre le format IFC (ex. : IFC-SPF) et la version du MCD (ex. : IFC 2×3 TC1). Pour bien comprendre les IFC, nous conseillons de les aborder comme un schéma qui structure toute la donnée d’un modèle, et non comme un simple format de fichier.

Le modèle conceptuel de données IFC : structure et langage EXPRESS

Un MCD offre une représentation formelle et univoque des concepts d’une base de données, définissant précisément la sémantique de chaque donnée. Toute base de données ou format d’échange l’exige en amont.

La description du MCD recourt à un langage de spécification formelle accompagné d’une convention de représentation graphique. Le langage retenu pour l’IFC est EXPRESS, associé à la méthode de représentation graphique EXPRESS-G. La norme ISO 10303-11 décrit le langage EXPRESS.

Le MCD IFC est développé de manière transparente : bSI publie tous les fichiers sources sur son dépôt GitHub officiel. Chacun peut consulter, vérifier ou contribuer à l’évolution du standard.

⚠️ Il s’agit d’un MCD orienté objet, à ne pas confondre avec les MCD relationnels, encore majoritaires dans d’autres domaines.

Les différents formats IFC

Le modèle conceptuel peut être sérialisé dans plusieurs formats IFC standardisés : SPF (.ifc), XML (.ifcXML), ZIP (.ifcZIP) et plus récemment JSON (.json)

L’encodage en texte clair permet d’ouvrir tout fichier IFC (.ifc ou .ifcXML) avec un simple éditeur de texte. Voici un court extrait d’un fichier IFC-SPF. Chaque ligne correspond à un objet IFC : sa classe d’appartenance est mentionnée, puis les valeurs de chaque attribut.

⚠️ Concernant le format IFC-XML, buildingSMART annonce +13 % par rapport au SPF, mais ce chiffre est un minimum théorique, atteignable uniquement avec une sérialisation optimisée. En production réelle, les ratios sont bien supérieurs. Pour la planification des infrastructures de stockage et de bande passante, les professionnels doivent retenir le ratio de 300 à 400 %.

Malgré sa taille, l’ifcXML conserve des avantages stratégiques :

Interopérabilité hors AEC : Il permet d’extraire des données partielles (par exemple, les coûts ou les quantités) et les injecter dans des systèmes financiers ou logistiques qui « parlent » XML, pas STEP.
Lisibilité sémantique : une balise XML se lit immédiatement, contrairement à une ligne SPF. Cela facilite le développement d’outils de data management.

Modèles IFC BIM : structure de la data d'une construction

La représentation traditionnelle d’un bâtiment repose sur une succession de plans (calques) précis, mais cloisonnés. L’IFC transforme cette approche en une logique de « LEGO » avec des briques intelligentes.

Ces éléments « intelligents » établissent des relations entre eux et embarquent des données structurées. Le Building Information Modeling inscrit chaque élément dans un réseau de relations explicites : un mur appartient à un étage, borde un local, reçoit une porte. Ces liens formalisés remplacent la juxtaposition muette des calques traditionnels.

La notion d'objet dans l'Industry Foundation Classes

L’IFC reprend la définition ISO 12006-2 de l’objet : « toute partie du monde perceptible ou concevable ». Les éléments physiques, les relations logiques et les jeux de propriétés sont des objets et reçoivent chacun un identifiant unique (GlobalId). En revanche, les propriétés individuelles ne sont pas des objets : ce sont des ressources sans identité propre, référencées depuis une entité identifiable. Un objet unique au sein d’une classe IFC se nomme occurrence. En programmation orientée objet (POO), nous parlons aussi « d’instance de classe ».

Un triptyque définit tout objet IFC :

Son appartenance à une entité IFC
Ses propriétés
Ses relations avec d’autres objets IFC

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

La classification et les entités IFC

Classer revient à regrouper des entités partageant les mêmes caractéristiques, ce que l’ISO 16739 nomme « catégorisation ». Une entité IFC (ou « classe IFC ») s’apparente à une classe en POO, à ceci près qu’elle ne renferme aucune méthode : elle rassemble uniquement les objets selon un comportement et des attributs communs.

⚠️ En POO, « entité » désigne souvent une instance de classe. En BIM, ce terme renvoie strictement à une classe IFC (IfcWall, IfcSlab…). Cette précision terminologique évite les malentendus lors des échanges entre développeurs et BIM Managers.

Relation d'héritage dans le modèle IFC : spécialisation et généralisation des classes

L’héritage établit une relation de similarité entre classes. Une classe fille hérite des caractéristiques de sa classe parente et ajoute ses propres spécificités.

Exemple IFC 4.3 : IfcWall est une classe fille de IfcBuildingElement, elle-même fille de IfcElement. Un mur (IfcWall) hérite donc de toutes les caractéristiques d’un élément de construction (IfcBuildingElement), qui lui-même hérite des caractéristiques générales de tout élément IFC (IfcElement).

Cette hiérarchie forme un « arbre d’héritage » inversé : la racine (IfcRoot) en haut, les spécialisations (feuilles) en bas. Descendre vers les feuilles, c’est spécialiser ; remonter vers le tronc, c’est généraliser.

L'entité IFC racine du MCD : IfcRoot

Tout objet héritant d’IfcRoot reçoit un GUID (Globally Unique IDentifier). Ses 128 bits offrent 2^128 – 1 combinaisons. La probabilité de générer deux GUID identiques est donc quasi nulle. Dans les IFC, chaque GUID est encodé en une chaîne de 22 caractères (« 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 exportation.

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

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

IfcObjectDefinition : regroupe 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 : regroupe toutes les relations entre les objets.
IfcPropertyDefinition : 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.

Cette liste présente une partie de l'arbre d'héritage pour IFC 2x3 TC1.

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

1. IfcRelAggregates qui hérite d’IfcRelDecomposes et établit des relations de composition/décomposition entre objets, principalement pour :

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 (dans une charpente par exemple).

2. IfcRelContainedInSpatialStructure (hérite d’IfcRelConnects) : localise chaque élément de construction (IfcWall, IfcDoor, IfcColumn, IfcBeam) dans la structure spatiale en l’assignant à un conteneur spatial unique.

Note : les éléments peuvent être référencés par plusieurs structures spatiales via la relation IfcRelReferencedInSpatialStructure.

Les MVD sont des sous-ensembles du modèle conceptuel IFC

MVD est l’acronyme de Model View Definition.

Un partage de données se fait toujours selon un cas d’usage déterminant des besoins spécifiques. Par conséquent, un partage de data ne concerne systématiquement qu’une partie, plus ou moins grande, du modèle conceptuel et donc de la maquette numérique.

La norme ISO 29481-1:2025 définit la MVD comme une « définition interprétable par ordinateur d’une exigence d’échange, associée à un ou plusieurs schémas d’informations normalisés ».

Pour la spécification IFC 2×3 TC1, les deux MVD les plus utilisées sont Coordination View 2.0 et Structural Analysis View.

Pour IFC 4.3, bSI a repensé l'architecture des MVD autour de niveaux d'implémentation progressifs, chacun lié à un cas d'usage distinct :

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

Alignment based View : pour les échanges nécessitant la conservation de l'axe directeur, typique de la conception détaillée en infrastructure. Positionnée comme standard d'échange infra, elle porte le statut « Awaiting final approval » : signe de difficultés de consensus, voire d'impasse technique.
Design Transfer View : pour le transfert de modèles éditables (géométrie paramétrique, CSG, extrusions), modifiables après import. Pour l'IFC 4.3, buildingSMART n'a publié aucune spécification. Elle est donc non opérationnelle à ce jour.
IFC4Precast : pour l'échange de données de fabrication entre CAO et MES dans la préfabrication béton. Incompatible avec Reference View (extension .ifcprecast), elle répond à des principes de modélisation radicalement différents, optimisés pour la production industrielle automatisée.

Chaque certification logicielle porte sur une MVD précise (voir la liste des outils BIM certifiés).

L'IDM : le document qui spécifie une MVD

Pour définir une MVD, nous nous appuyons sur un IDM (Information Delivery Manual). Ce document, normé par l’ISO 29481, formalise un processus métier et identifie, à chaque étape, les informations à échanger entre acteurs. L’IDM traduit ainsi un besoin opérationnel en exigences techniques.

Un IDM contient :

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)
Déduites de ces cartes : les exigences d'échange par étape, formulées pour les utilisateurs finaux (architectes, ingénieurs)
Les procédures techniques d'implémentation du sous-ensemble IFC correspondant

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

L’IDM vise d’abord les experts et développeurs concevant de nouvelles MVD. Les BIM Managers exploitent généralement les MVD existantes. Toutefois, dans certains cas complexes, un IDM peut servir de modèle pour formaliser un processus dans une convention BIM.

Exportation des modèles BIM natifs dans un format IFC

Lors de l’export IFC, la classification rigoureuse de chaque objet est primordiale. Les objets doivent conserver leurs informations alphanumériques : soit dans des attributs directs, soit dans des jeux de propriétés (IfcPropertySet). Concrètement, un « objet BIM » désigne souvent une instance d’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 établit une correspondance sémantique entre deux MCD, alignant les champs source et récepteur. Chaque logiciel BIM ayant son propre MCD, un mappage s’impose à chaque exportation, plus ou moins préconfigurée selon le contexte.

OpenBIM et closed-BIM : avantages et limites de chaque méthode

L'openBIM

Fondée sur l’interopérabilité et l’IFC, cette méthode libère les échanges d’informations. Elle supprime les interfaces propriétaires et garantit l’indépendance vis-à-vis des éditeurs. Les logiciels intègrent simplement une interface d’import/export conforme au standard.

Le Closed-BIM

L’échange s’opère ici via des formats natifs propriétaires. Ce flux « fermé » élimine les aléas de l’export, mais reste sous le contrôle exclusif des éditeurs. Le Closed-BIM est souvent associé au logiciel Autodesk Revit. En effet, celui-ci est le principal logiciel de modélisation BIM permettant de travailler dans les trois disciplines : Architecture, Structure et MEP. Revit atteint toutefois ses limites sur certains cas : Tekla Structures excelle en charpente métallique complexe, Cadwork en structure bois. Enfin, de nombreux architectes préfèrent Graphisoft Archicad pour son interface « Architect-First » et son traitement prédictif, propice à la créativité.

buildingSMART International (bSI) promeut l’openBIM dans l’industrie du bâtiment. De sa collaboration avec le groupe STEP-ISO (STandard for the Exchange of Product data model) sont nées les IFC. bSI développe également deux standards ouverts : le BCF (BIM Collaboration Format) et l’IDS (Information Delivery Specification).