Les maquettes numériques circulent entre architectes, ingénieurs, économistes et exploitants, mais leurs outils ne décrivent pas toujours les objets selon les mêmes règles. Le standard ouvert IFC fournit un langage neutre pour transporter la géométrie, les propriétés et les relations, sans imposer une application unique ni remplacer les formats de travail natifs.
Cette promesse ne garantit pourtant pas qu’un fichier transmis soit exploitable sans réserve. La qualité d’un échange de données BIM dépend du schéma utilisé, du périmètre demandé, des paramètres d’export et de la lecture réalisée par le logiciel destinataire. Ainsi, un mur peut conserver sa classe, ses matériaux et ses quantités, ou devenir une simple forme muette. L’interopérabilité des logiciels se mesure donc moins à l’ouverture du fichier qu’à la fidélité des informations réellement restituées.
L’IFC occupe une fonction précise dans un environnement BIM
Le BIM organise les méthodes, les responsabilités et les informations mobilisées pendant le cycle de vie d’un ouvrage. L’IFC, publié par buildingSMART International et normalisé par l’ISO, constitue un schéma ouvert destiné aux échanges. Dans un environnement BIM collaboratif, il décrit les objets selon une structure partagée, sans se substituer aux logiciels de conception ni à leurs fonctions de création spécialisées.
- Le BIM encadre les processus et les informations du projet.
- Le fichier natif permet de créer et de modifier le modèle.
- L’IFC transmet des données structurées entre différentes applications.
Un logiciel auteur enregistre le modèle dans une structure conçue pour ses propres outils d’édition. Ces formats natifs propriétaires conservent les contraintes, paramètres et historiques nécessaires au travail quotidien. L’IFC privilégie plutôt la neutralité logicielle : il transporte une représentation structurée vers d’autres applications métiers. Architectes, ingénieurs et exploitants peuvent ainsi consulter, coordonner ou contrôler les données sans posséder le logiciel d’origine. Fichier natif et IFC remplissent donc des rôles complémentaires.
Quelles données un fichier IFC peut-il transmettre ?
Un fichier IFC ne se réduit pas à une maquette tridimensionnelle destinée à l’affichage. Sa géométrie des objets restitue formes, dimensions, orientations et positions, tandis que la sémantique distingue un mur, une porte ou une poutre. Les propriétés alphanumériques peuvent renseigner une référence, un matériau, une performance thermique, une résistance au feu ou le statut prévu pour chaque élément technique modélisé.
La richesse transmise varie selon le modèle source, les réglages d’export et le périmètre d’échange convenu. Les quantités du modèle regroupent longueurs, surfaces, volumes ou dénombrements exploitables pour les études. Les classifications rattachent chaque élément à un système de référence. Par leurs relations spatiales, les données indiquent aussi qu’un équipement appartient à un local, qu’un mur relève d’un étage ou qu’une porte occupe une ouverture. Cette structure soutient les contrôles interdisciplinaires.
Le schéma IFC donne un sens métier aux objets modélisés
Le schéma IFC ne se limite pas à décrire des formes en trois dimensions. Répartie en couches de ressources, de noyau, d’interopérabilité et de domaines, sa structure sémantique précise la nature de chaque composant. Les classes d’objets IFC relient alors un mur à IfcWall, une porte à IfcDoor et un étage à IfcBuildingStorey, afin que les logiciels interprètent leur fonction.
Au-delà de sa classe, un objet reçoit des attributs, des relations et, selon son usage, des matériaux. Les ensembles de propriétés nommés Pset_ renseignent des caractéristiques comme la résistance au feu, tandis que les jeux Qto_ portent les valeurs mesurables : longueur, surface ou volume. Deux objets visuellement identiques peuvent donc livrer une richesse métier très différente, exploitable pour le contrôle, le calcul ou la gestion de l’ouvrage par les équipes.
| Élément constructif | Classe IFC | Property Set courant | Ensemble de quantités |
|---|---|---|---|
| Mur | IfcWall | Pset_WallCommon | Qto_WallBaseQuantities |
| Porte | IfcDoor | Pset_DoorCommon | Qto_DoorBaseQuantities |
| Dalle | IfcSlab | Pset_SlabCommon | Qto_SlabBaseQuantities |
| Espace | IfcSpace | Pset_SpaceCommon | Qto_SpaceBaseQuantities |
Le fichier .ifc est-il l’unique forme d’échange disponible ?
L’IFC définit un modèle de données ; l’extension employée ne constitue que sa forme de transport. La sérialisation du modèle traduit donc le schéma conceptuel en contenu enregistrable et lisible par une application. Le format IFC-SPF, conforme à ISO 10303-21 et reconnaissable à l’extension .ifc, demeure la représentation textuelle la plus largement compatible entre outils BIM.
Plusieurs encodages coexistent pour répondre à des usages différents. L’encodage IFC XML, livré en .ifcXML, facilite les traitements reposant sur XML, au prix d’un volume généralement supérieur. Un fichier IFC compressé en .ifcZIP allège le stockage et le transfert : buildingSMART évalue sa taille relative à environ 17 %, contre 100 % pour IFC-SPF et 113 % pour IFC XML. Le choix dépend, dans chaque cas, des formats admis par l’outil destinataire.
À retenir : changer d’encodage ne corrige ni les objets mal classés ni les propriétés absentes.
Les versions IFC répondent à des périmètres métiers distincts
Publiée en 2005, IFC 2×3 demeure bien implantée dans les échanges de maquettes de bâtiments, car de nombreux logiciels la prennent en charge. Cette version IFC 2×3 offre un socle éprouvé, tandis qu’IFC4, paru en 2013, affine les géométries, les propriétés et les relations entre objets. Le format retenu dépend donc du livrable attendu et des capacités d’import-export disponibles.
IFC 4.3, et plus précisément IFC 4.3.2.0, étend ce langage aux ouvrages de génie civil. L’édition 2024 de la norme ISO 16739-1 encadre cette génération et couvre notamment les routes, voies ferrées, ponts, ports et voies navigables. Grâce aux alignements horizontaux et verticaux, elle décrit avec davantage de justesse les infrastructures linéaires, ainsi que le positionnement des équipements et composants le long d’un axe. Le BIM ouvert dépasse ainsi le périmètre du bâtiment.
Comment les MVD délimitent-ils le contenu réellement échangé ?
Un MVD encadre ce qu’un export doit contenir pour qu’un logiciel destinataire puisse l’exploiter sans ambiguïté. Cette vue de modèle constitue un sous-ensemble du schéma IFC, assorti de règles sur les entités, relations, propriétés et géométries autorisées. Elle adapte donc la richesse générale du standard à un usage métier ciblé, plutôt que d’imposer l’intégralité du modèle de données à chaque échange. Trois profils illustrent cette logique :
- Reference View privilégie la consultation, la coordination et l’analyse d’une maquette de référence.
- Alignment Based View organise les alignements et les géométries propres aux ouvrages linéaires.
- Design Transfer View conserve des données de conception plus riches pour leur reprise.
Les trois vues répondent à des intentions différentes, sans garantir la même capacité de modification dans l’application réceptrice. Reference View sert surtout à consulter, coordonner ou analyser une maquette figée. Alignment Based View structure les axes, placements et géométries des routes ou voies ferrées. Design Transfer View vise un transfert de conception plus riche, mais sa reprise dépend des fonctions d’import et d’export réellement prises en charge. Avant de fixer une MVD, confrontez donc le besoin documentaire aux capacités des logiciels impliqués.
Export et import traduisent les données entre modèles logiciels
Lors de l’export, l’application source ne reproduit pas mécaniquement son modèle natif. Elle établit un mapping des objets pour relier, par exemple, un mur interne à IfcWall, puis organise la conversion des propriétés vers les attributs, jeux de propriétés ou quantités IFC. La traduction géométrique transpose alors les formes paramétriques dans une représentation admise par la version et le MVD retenus.
À l’import, le logiciel destinataire reconstruit les données selon les fonctions qu’il prend en charge. Une classe sans équivalent peut devenir IfcBuildingElementProxy, tandis qu’une propriété native disparaît ou qu’une forme complexe se transforme en maillage. Les contraintes paramétriques, les règles de conception et l’historique des modifications restent parfois hors de portée. Ces écarts naissent aux extrémités du flux, selon l’exportateur, l’importateur, la version IFC et le MVD choisi.
| Élément traduit | Traitement effectué | Résultat possible |
|---|---|---|
| Objet métier | Association à une classe IFC | Classe précise ou objet générique IfcBuildingElementProxy |
| Propriété | Transfert vers un attribut, un jeu de propriétés ou une quantité | Valeur conservée, renommée, transformée ou perdue |
| Géométrie | Transposition dans une représentation IFC compatible | Forme paramétrique, volume simplifié ou maillage |
| Modèle importé | Reconstruction selon les capacités du logiciel cible | Objet natif, objet non paramétrique ou représentation générique |
Comment évaluer la qualité d’un échange IFC BIM ?
L’ouverture du fichier par un logiciel prouve seulement que son contenu peut être lu. La conformité au schéma porte sur la syntaxe, les entités admises et les règles formelles de la version IFC visée. Une validation du fichier, menée avec un outil adapté ou le service buildingSMART, révèle des anomalies techniques. Elle ne garantit ni la présence ni la justesse des données.
L’examen se poursuit en confrontant la qualité informationnelle aux besoins du projet et au cas d’usage annoncé. Pour la coordination, vérifiez les positions, les classes et les collisions ; pour le métré, contrôlez les quantités et les unités. L’exploitation réclame, quant à elle, des identifiants, équipements, espaces et propriétés exploitables. Des contrôles visuels, des règles automatisées et un IDS confirment alors l’aptitude des données à l’usage prévu.
À retenir : un fichier IFC syntaxiquement valide peut rester inexploitable si son contenu ne répond pas au cas d’usage défini.
IFC, IDS et BCF remplissent des rôles complémentaires
Chaque standard openBIM prend en charge une facette distincte de l’échange, ce qui évite de confondre modèle, règles de contrôle et fil de discussion. IFC achemine la géométrie, les propriétés et les relations entre objets, tandis que les exigences informationnelles IDS décrivent, dans un format interprétable par machine, les informations attendues. Publié par buildingSMART le 1er juin 2024, IDS 1.0 permet de vérifier la présence et la conformité des données. Leurs fonctions se résument donc ainsi.
- IFC structure et transporte les données de la maquette.
- IDS formalise les informations attendues et vérifie leur conformité, sans tester la géométrie.
- BCF documente, attribue et suit les sujets associés au modèle.
BCF intervient lorsqu’un écart demande une action concertée. Il structure la communication des problèmes grâce à des vues, commentaires, responsables, échéances et statuts, sans dupliquer la maquette IFC. La coordination au format BCF garde ainsi une trace exploitable des arbitrages et corrections. Une gaine traversant une poutre devient, par exemple, un sujet attribué au bureau d’études fluides, puis clôturé après vérification du nouvel export IFC corrigé.
À quoi ressemble un flux openBIM entre plusieurs disciplines ?
Le flux débute dans les logiciels auteurs, où l’architecte, l’ingénieur structure et les bureaux d’études produisent chacun une maquette adaptée à leur discipline. Après contrôle des unités, coordonnées, niveaux, classes et propriétés, leurs exports IFC forment des modèles métiers fédérés au sein d’un outil commun. Cette réunion conserve l’autonomie des fichiers natifs tout en donnant une lecture cohérente du projet aux équipes chargées de la coordination multidisciplinaire.
Le modèle fédéré devient le support des contrôles interdisciplinaires menés selon les règles définies ensemble. Une détection des collisions peut révéler une canalisation traversant un poteau, un réseau placé hors réservation ou un équipement inaccessible pour la maintenance. Chaque conflit est qualifié, illustré par un point de vue, attribué au métier concerné et transmis en BCF. Le suivi des réserves consigne alors les échanges, décisions, statuts et corrections jusqu’à la validation du nouvel export IFC.
La réussite de l’interopérabilité repose sur des exigences précises
Un échange IFC ne se juge pas à la simple ouverture du fichier dans une application tierce. Sa fiabilité tient à la qualité du modèle source, notamment au classement des objets, à la cohérence des relations, aux propriétés renseignées et à une géométrie proportionnée à l’usage visé. Sans cette rigueur, une maquette lisible peut transmettre des informations incomplètes, ambiguës ou inutilisables pour les métiers destinataires.
Le résultat dépend aussi de règles formulées avant tout export. Les exigences d’échange définissent alors la version IFC, la vue, les classes, les propriétés, les quantités et les contrôles correspondant aux usages attendus. Elles doivent rester compatibles avec les capacités des logiciels chargés de produire, vérifier puis relire les données, puisque chaque outil interprète un périmètre particulier du schéma. Des tests représentatifs révèlent les pertes géométriques ou sémantiques. L’IFC limite la dépendance à un éditeur, sans reproduire parfaitement le modèle natif.
