Interopérabilité BIM : pourquoi les données se perdent entre logiciels

Quand un échange BIM échoue, le premier réflexe consiste souvent à incriminer le format IFC ou le logiciel qui importe le fichier. Sur le terrain, le problème est rarement aussi simple. Une information traverse plusieurs couches : le modèle natif, la configuration d’export, le schéma IFC choisi, les règles de mapping, la sérialisation du fichier, puis l’interprétation par le logiciel destinataire. Une perte peut apparaître à chacune de ces étapes.

L’interopérabilité ne signifie donc pas « réussir à ouvrir le fichier ». Elle signifie que l’information nécessaire à un usage donné est transmise avec suffisamment de fidélité pour être comprise, contrôlée et réutilisée par le destinataire.

L’interopérabilité BIM n’est pas une conversion de fichier

Deux logiciels BIM n’utilisent pas nécessairement le même modèle de données interne. Revit organise par exemple les informations autour de catégories, familles, types, occurrences et paramètres. D’autres outils structurent leurs objets différemment. Lors d’un échange, il faut donc établir une correspondance entre deux représentations qui ne sont pas identiques.

C’est le rôle d’un standard d’échange comme l’IFC — Industry Foundation Classes. buildingSMART définit IFC comme une description numérique standardisée de l’environnement construit, neutre vis-à-vis des éditeurs. L’IFC décrit notamment l’identité et la sémantique des objets, leurs caractéristiques et leurs relations. La version officielle actuelle est IFC 4.3.2.0, également publiée comme ISO 16739-1:2024.

Mais un schéma commun ne supprime pas les différences entre les logiciels. Chaque application doit implémenter une partie du standard et traduire ses objets internes vers les concepts IFC qu’elle prend en charge. C’est pour cette raison que deux exports provenant du même modèle peuvent donner des résultats différents selon la configuration utilisée.

Les six couches à contrôler dans un échange BIM

Pour analyser une perte d’information, je préfère ne pas parler d’un fichier IFC comme d’un bloc unique. Je le décompose en plusieurs couches dont chacune peut être correcte ou défaillante.

Cette décomposition est utile pour le diagnostic. Si un objet manque dans le viewer, la cause peut être géométrique. S’il est présent mais classé comme objet générique, le problème est sémantique. S’il est bien classé mais sans les propriétés attendues, il faut examiner le mapping des données et la configuration des Property Sets.

IFC : schéma, version et Model View Definition

Un IFC n’est pas simplement un fichier portant l’extension .ifc. Le standard comprend un schéma de données, des définitions de Property Sets et Quantity Sets, une documentation et des mécanismes de sérialisation. La structure du fichier dépend aussi de la version du schéma utilisée.

IFC2x3 reste encore très présent dans les chaînes historiques. IFC4 apporte un modèle plus récent, tandis qu’IFC4.3 étend fortement le périmètre des infrastructures avec les routes, voies ferrées, ponts, voies navigables et installations portuaires. Choisir « IFC4 » ou « IFC4.3 » n’est pourtant pas suffisant : les logiciels peuvent implémenter une Model View Definition — MVD, c’est-à-dire un sous-ensemble du schéma adapté à un ou plusieurs scénarios d’échange.

Cette notion explique pourquoi deux logiciels annonçant une compatibilité IFC peuvent ne pas supporter exactement les mêmes usages. La compatibilité doit être regardée par version et par vue d’échange, et non uniquement par l’existence d’un bouton Import/Export IFC.

Le mapping des classes : première source de perte sémantique

Dans IFC, une classe indique ce qu’un objet représente. Une porte peut être IfcDoor, un mur IfcWall, une gaine IfcDuctSegment, un équipement de ventilation une classe plus spécialisée, etc. Cette classe permet aux logiciels et aux contrôleurs de comprendre la fonction de l’objet sans dépendre du nom utilisé dans le logiciel source.

Le problème est que la catégorie native et la classe IFC ne sont pas toujours équivalentes. Dans Revit, l’export IFC repose notamment sur des règles de mapping de catégories et peut être complété par des informations spécifiques sur les familles ou éléments. Autodesk documente explicitement la possibilité de définir la classe IFC et le PredefinedType utilisés lors de l’export.

Si le mapping est incorrect ou trop générique, l’objet peut arriver en IfcBuildingElementProxy. Visuellement, rien ne saute forcément aux yeux : la géométrie est toujours là. Pourtant, pour un logiciel de contrôle, une règle ciblant les IfcDoor ne verra plus la porte. La perte est sémantique, pas graphique.

Le PredefinedType apporte une précision supplémentaire à certaines classes. Il permet par exemple de distinguer plusieurs fonctions au sein d’une même entité. Là encore, une valeur mal renseignée peut ne rien changer dans le viewer tout en dégradant l’exploitation de la donnée.

Property Sets : pourquoi un paramètre Revit n’est pas automatiquement un Pset IFC

Les Property Sets, ou Psets, regroupent les propriétés associées aux objets IFC. buildingSMART précise qu’un IfcPropertySet est un conteneur de propriétés et réserve la convention de nommage Pset_Xxx aux ensembles définis dans la spécification IFC. Des ensembles personnalisés peuvent être créés, mais ils ne devraient pas utiliser ce préfixe réservé.

C’est un point important dans les workflows Revit. Un paramètre présent dans une famille ou dans le projet ne devient pas magiquement une propriété IFC standard. Il faut décider comment il sera exposé : propriété IFC commune, Property Set utilisateur, paramètre spécifique au logiciel ou donnée volontairement non exportée.

Revit permet notamment d’exporter des Property Sets Revit, les Psets IFC communs, des quantités de base, des nomenclatures en tant que Psets et des Property Sets définis par l’utilisateur. Selon les options cochées, le même modèle source peut donc produire des fichiers très différents.

Il faut également distinguer type et occurrence. Dans IFC, un Property Set peut être attaché à un objet individuel ou à un type. Les propriétés du type s’appliquent aux occurrences associées, sauf mécanisme d’écrasement prévu. Si le destinataire cherche systématiquement une propriété sur l’occurrence alors que l’exporteur l’a placée sur le type, il peut donner l’impression que la donnée a disparu alors qu’elle existe ailleurs dans la structure IFC.

GUID : l’identité de l’objet entre deux versions

Les objets IFC héritant d’IfcRoot possèdent un identifiant global. Le type IfcGloballyUniqueId correspond à un GUID encodé sur 22 caractères dans le fichier IFC. Cette identité est fondamentale pour comparer deux versions d’un modèle, suivre une issue ou rattacher une donnée externe à un objet.

La présence d’un GUID ne garantit pourtant pas sa stabilité. Si un élément est supprimé puis recréé dans le logiciel source, ou si le mécanisme d’export produit une nouvelle identité, le système destinataire peut considérer qu’il s’agit d’un nouvel objet. Pour un viewer, ce n’est pas grave. Pour du versioning, du BCF, du suivi de réserves ou une base de données connectée, cela peut casser la continuité.

Lorsqu’un workflow repose sur le suivi des objets dans le temps, la stabilité des GUID doit donc être testée explicitement sur plusieurs exports successifs.

Géoréférencement : quand deux modèles corrects ne se superposent pas

Une autre famille de problèmes concerne les coordonnées. Chaque logiciel dispose de ses propres notions d’origine interne, point de projet, coordonnées partagées ou systèmes locaux. À l’échelle d’un bâtiment isolé, une approximation peut rester invisible. Sur un projet d’infrastructure ou une fédération de plusieurs emprises, elle devient rapidement critique.

IFC4 et IFC4.3 disposent de mécanismes dédiés au référencement cartographique. IfcProjectedCRS décrit le système de coordonnées projetées, tandis qu’IfcMapConversion décrit la transformation entre le système local d’ingénierie et le système de coordonnées cartographique, notamment au travers des Eastings, Northings, hauteur, orientation et échelle.

Un échange fiable doit donc préciser ce que le projet attend : origine locale, coordonnées du site, système projeté, altitude de référence, orientation et unités. Tester uniquement la position du fichier dans son logiciel d’origine ne suffit pas. Il faut le fédérer avec au moins un autre modèle de référence.

La géométrie peut être correcte sans rester éditable

Les logiciels natifs disposent souvent de primitives et de comportements paramétriques qui n’ont pas d’équivalent direct dans l’application destinataire. Lors de l’export, la géométrie peut être représentée sous différentes formes IFC : extrusions, solides balayés, BRep, tessellations ou autres représentations prises en charge par le schéma et le MVD.

Le destinataire peut parfaitement afficher cette géométrie tout en perdant l’intelligence de création du logiciel source. Une famille paramétrique Revit complexe n’est pas censée redevenir une famille Revit éditable après un aller-retour IFC. L’IFC est avant tout un standard d’échange de données et de représentation, pas un format universel destiné à reproduire tous les mécanismes natifs de chaque auteur logiciel.

C’est une limite importante : interopérabilité ne signifie pas réversibilité parfaite. Il faut définir ce qui doit être conservé pour l’usage attendu plutôt que d’exiger une reproduction intégrale de l’environnement natif.

Cas concret : pourquoi un export Revit vers IFC peut changer selon le réglage

Prenons une maquette Revit contenant murs, portes, équipements MEP et paramètres projet. Avant même l’export, plusieurs décisions modifient le résultat : version IFC, MVD, mapping des catégories, classe et PredefinedType spécifiques, export des Psets IFC communs, Psets Revit, quantités de base, nomenclatures, propriétés utilisateur, géoréférencement et filtrage des éléments.

Autodesk fournit plusieurs réglages d’export et permet d’enregistrer des configurations. Cette fonction est particulièrement importante sur un projet : l’export IFC devrait être traité comme une configuration projet versionnée, au même titre qu’un gabarit ou une règle de contrôle. Laisser chaque utilisateur exporter avec ses paramètres personnels produit des livrables impossibles à comparer.

La bonne méthode consiste à créer un petit fichier de test contenant les principales familles d’objets, exporter avec la configuration cible, puis contrôler le résultat dans un logiciel indépendant. Ce test doit être fait au démarrage du projet, pas la veille du premier livrable.

Les pertes les plus fréquentes que je rencontre

1. Objet visible mais mal classé

Le modèle semble correct dans le viewer mais les contrôles par classe échouent. Il faut vérifier le mapping de catégorie, les paramètres IFC spécifiques et le PredefinedType.

2. Paramètre présent dans Revit mais absent de l’IFC

Le paramètre n’a pas été mappé vers un Pset exporté, la configuration n’exporte pas le bon groupe de propriétés ou la donnée se trouve sur le type alors que le contrôle cherche l’occurrence.

3. Propriété présente mais inexploitable

Le nom varie entre disciplines, les unités sont incohérentes ou une valeur qui devrait être contrôlée est saisie en texte libre. Le fichier contient la donnée, mais pas sous une forme robuste pour l’automatisation.

4. GUID instable entre deux livraisons

Les objets ne peuvent plus être rapprochés automatiquement entre versions. Les issues, historiques ou analyses de différences deviennent moins fiables.

5. Modèle décalé ou tourné

Les coordonnées ont été exportées selon une base différente de celle attendue ou le CRS n’a pas été transmis de manière cohérente.

6. Fichier correct dans un logiciel, faux dans un autre

Le problème peut venir d’une prise en charge différente du schéma, du MVD ou d’une limite de l’importeur. Tester dans plusieurs outils aide à distinguer un défaut du fichier d’un défaut d’interprétation.

Comment contrôler un échange IFC avant livraison

Je recommande de traiter l’export IFC comme un livrable soumis à une recette, pas comme une simple opération de sauvegarde. Le contrôle doit répondre aux exigences du projet et être reproductible.

Un contrôle visuel est nécessaire mais insuffisant. Dès que les exigences deviennent nombreuses, les règles devraient être automatisées autant que possible. L’IDS — Information Delivery Specification — permet d’ailleurs de formaliser certaines exigences d’information sous une forme interprétable par machine. Nous y reviendrons dans un article dédié.

Les bonnes pratiques qui améliorent réellement l’interopérabilité

La première consiste à tester tôt. Un échange IFC pilote au démarrage permet de valider les classes, propriétés, coordonnées et outils avant que la production ne soit massive. La deuxième est de versionner la configuration d’export et de la partager à toutes les équipes concernées.

Il faut également éviter de multiplier les propriétés propriétaires sans nécessité. Quand une propriété IFC standard existe et correspond réellement au besoin, elle facilite l’échange. Quand le projet a besoin d’une donnée spécifique, un Pset projet bien défini peut être pertinent, à condition que son nom, ses propriétés, leurs types et leurs unités soient documentés.

Enfin, le destinataire doit participer à la définition de l’échange. On ne devrait pas définir un export sans vérifier comment les données seront lues. L’interopérabilité est un contrat d’information entre un producteur et un consommateur, pas une caractéristique abstraite du fichier.

Ce que l’IFC ne résout pas à lui seul

L’IFC fournit une base standardisée très puissante, mais il ne définit pas automatiquement les besoins de chaque projet. Il ne décide pas quelles propriétés le maître d’ouvrage attend, quelles valeurs sont obligatoires, quel niveau d’information est nécessaire à un jalon ni comment une équipe doit traiter une non-conformité.

Ces exigences doivent être définies par le projet, idéalement sous une forme contrôlable. C’est là que les autres briques openBIM prennent leur sens : IDS pour formaliser certaines exigences, BCF pour communiquer des issues liées aux modèles, bSDD pour partager des définitions et classifications, et les outils de contrôle pour vérifier les fichiers.

L’objectif n’est donc pas d’obtenir un « IFC parfait » dans l’absolu. Il est d’obtenir un IFC adapté à un usage, conforme aux exigences définies et suffisamment stable pour être utilisé par les autres acteurs.

Vers un contrôle IFC industrialisé

À partir du moment où les exigences sont clairement définies, une grande partie du contrôle peut être automatisée : présence d’un Property Set, valeur obligatoire, regex, liste de valeurs autorisées, seuil numérique, doublons ou cohérence d’identifiants. C’est précisément l’un des axes de la plateforme IFC de Pimp My BIM : transformer les exigences projet en règles de contrôle plutôt que de vérifier manuellement chaque fichier.

Le principe reste toutefois le même quel que soit l’outil : automatiser une règle mal définie ne produit qu’un mauvais contrôle plus rapide. La qualité de l’interopérabilité commence par la qualité des exigences.