Problèmes courants lors de l’édition des fichiers IFC et solutions pour les résoudre

Recevoir un fichier IFC avec des géométries éclatées, des données manquantes ou des coordonnées incorrectes est une expérience frustrante mais courante pour ceux qui travaillent dans le BIM. Face à ces erreurs, l’instinct est de « ouvrir et corriger », mais l’IFC n’est pas un simple fichier CAD : c’est une base de données structurée et complexe.

Le traiter comme un dessin modifiable est risqué : un editing inapproprié peut corrompre les données et compromettre l’ensemble du flux de travail OpenBIM. Pourquoi est-il si difficile d’intervenir sur ces fichiers ? Et comment résoudre les erreurs sans aggraver la situation ? 

Dans cet article, nous analyserons les critiques techniques de l’édition IFC, les problèmes les plus fréquents rencontrés et les solutions opérationnelles pour gérer et corriger les modèles de manière sécurisée et professionnelle avec un éditeur IFC.

Pourquoi l’édition des fichiers IFC présente des criticités

Pourquoi l’édition des fichiers IFC présente des problèmes

Travailler avec le format IFC (Industry Foundation Classes) est désormais la norme pour ceux qui opèrent dans le domaine de l’OpenBIM. Cependant, de nombreux professionnels se heurtent quotidiennement à des frustrations et des obstacles lorsqu’ils tentent de modifier ces fichiers. Pour comprendre comment résoudre ces problèmes, il est fondamental de comprendre d’abord la nature même du format et pourquoi il n’a pas été conçu pour être « édité » au sens traditionnel du terme.

IFC comme format d’échange, pas de modélisation

L’erreur conceptuelle la plus répandue est de traiter un fichier IFC comme s’il s’agissait d’un fichier natif (comme un .rvt de Revit, un .pln d’Archicad ou un .edf d’Edificius). Ce n’est pas le cas.

L’IFC est, par définition, un format d’échange et d’archivage. Il a été conçu par buildingSMART International comme une « photographie » statique et figée d’un modèle à un moment donné de son cycle de vie. Imaginez-le comme un PDF dans le monde de la documentation textuelle : vous créez le document dans Word (le logiciel d’authoring), mais vous l’envoyez en PDF pour garantir que quiconque puisse le lire sans altérer sa mise en page ou son contenu.

Essayer de modéliser ou de modifier lourdement la géométrie à l’intérieur d’un fichier IFC est techniquement difficile car la structure des données n’est pas paramétrique de la manière dont le sont les logiciels d’authoring. Lorsque un logiciel exporte en IFC, il traduit ses règles internes (murs, fenêtres, relations paramétriques) en définitions standardisées (souvent des géométries explicites comme Brep ou ExtrudedAreaSolid). Briser ce « sceau » pour modifier la géométrie signifie souvent devoir reconstruire manuellement les relations logiques que le format a simplifiées pour favoriser la compatibilité.

Édition directe vs workflow correct OpenBIM

La problématique de l’édition naît souvent d’un flux de travail (workflow) non optimal. Il existe deux approches principales : 

1. l’approche « erronée » (Édition Destructive) : on reçoit un IFC, on remarque une erreur (par exemple, un mur déplacé de 10 cm), on ouvre le fichier avec un éditeur générique ou on tente de le réimporter dans le logiciel de modélisation, on effectue la modification et on réexporte. Ce cycle, connu sous le nom de Round-tripping, est fortement déconseillé. Chaque étape d’importation et d’exportation entraîne une « traduction » des données qui, presque inévitablement, conduit à une dégradation des informations (perte de propriétés, corruption des géométries, perte de classifications) ;
2. le workflow correct OpenBIM : dans un processus idéal, l’IFC ne devrait jamais être modifié géométriquement par le destinataire. S’il y a une erreur, le signalement doit revenir à l’auteur du modèle (via le format BCF – BIM Collaboration Format), qui corrigera le fichier natif et générera un nouvel IFC mis à jour.

Cependant, la réalité de chantier et de bureau impose souvent des exceptions. Parfois, l’auteur n’est pas disponible, ou il est nécessaire d’enrichir le fichier uniquement avec des données informatives (sans toucher à la géométrie) à des fins de gestion des installations ou de calcul. C’est ici que l’édition devient une opération chirurgicale et délicate, nécessitant des outils spécifiques et la conscience que nous forçons la nature « statique » du format pour des besoins opérationnels.

Problèmes courants lors de l’édition des fichiers IFC et solutions pour les résoudre

Une fois compris que l’IFC n’est pas né pour être modifié, il est facile de comprendre pourquoi, lorsque l’on essaie, les choses peuvent mal tourner. Quiconque a essayé de manipuler un fichier IFC s’est probablement heurté à au moins l’un des scénarios suivants, qui représentent les « goulets d’étranglement » les plus fréquents dans le flux de travail OpenBIM.

Perte de données et problèmes de géométrie

C’est le cauchemar classique du BIM Specialist : vous ouvrez un fichier IFC et le modèle semble « explosé » ou incomplet. Cela se produit souvent lors des tentatives de conversion ou de modification. Les géométries courbes (comme les murs courbes ou les tuyauteries complexes) peuvent être tessellées, se transformant en une série de faces planes polygonales difficiles à gérer.

Encore plus insidieuse est la perte de données non géométriques. Lors d’une édition inappropriée, les relations hiérarchiques (par exemple, IfcBuildingStorey contenant IfcWall) peuvent se briser. Le résultat est un modèle qui visuellement semble correct, mais qui au niveau des données est « plat » : les objets ne savent plus à quel étage ils appartiennent ou perdent les connexions logiques avec les autres éléments.

Difficultés dans la modification des propriétés et des données informatives

Souvent, le besoin d’édition n’est pas géométrique, mais informatif (le soi-disant « BIM Data Enrichment »). On souhaite ajouter un paramètre, comme une date d’installation ou un code de maintenance. Le problème survient car de nombreux visualisateurs IFC sont en lecture seule, et les logiciels d’authoring (lorsqu’ils importent l’IFC) ont tendance à mapper les propriétés IFC en paramètres propriétaires non modifiables ou difficiles à gérer.

Modifier un Pset (Property Set) standard ou en créer un personnalisé directement sur l’IFC nécessite des éditeurs spécifiques. Le faire « à la main » ou avec des outils inappropriés conduit souvent à la duplication des propriétés ou à la création de jeux de données non conformes à la norme buildingSMART, rendant le fichier inutilisable pour des validations automatiques ultérieures.

Problèmes d’interopérabilité entre logiciels BIM

L’interopérabilité est la promesse de l’OpenBIM, mais c’est aussi son talon d’Achille si elle n’est pas gérée correctement. Chaque logiciel (Revit, Archicad, Edificius, etc.) a son « langage » interne pour interpréter le schéma IFC.

Un problème courant est la différente interprétation des classes. Un objet modélisé comme « Mur » dans un logiciel pourrait être interprété comme un générique « Proxy » (IfcBuildingElementProxy) dans un autre si le mappage des classes n’a pas été configuré en amont. Cela rend l’édition impossible : vous ne pouvez pas modifier l’épaisseur d’un mur si le logiciel le lit comme un bloc solide générique dépourvu d’intelligence paramétrique.

Problèmes de visualisation du modèle IFC

Parfois, le fichier est techniquement correct, mais c’est le visualiseur qui échoue. Des phénomènes de Z-fighting (surfaces qui scintillent parce que superposées), des éléments transparents qui deviennent opaques, ou des couleurs qui ne correspondent pas à l’original se produisent.

Ces problèmes visuels rendent difficile l’édition car l’utilisateur n’est pas sûr s’il voit une erreur réelle du modèle ou un dysfonctionnement graphique du logiciel. Souvent, essayer de « corriger » une erreur visuelle qui n’existe en réalité pas dans la base de données du fichier conduit à endommager le modèle lui-même.

Mauvaise gestion des coordonnées et désalignement entre modèles

C’est peut-être le problème le plus critique dans les projets multidisciplinaires. Lorsque vous essayez d’éditer un IFC ou de le fédérer avec d’autres, vous vous rendez compte que le modèle « vole » dans l’espace ou est anormalement tourné.

L’IFC gère les coordonnées de manière rigoureuse (Project Base Point, Survey Point, Site Local Placement), mais si celui qui a exporté le fichier n’a pas correctement configuré l’origine, ou si celui qui l’édite déplace involontairement le système de référence local, le désalignement est garanti. Corriger les coordonnées directement dans un IFC est une opération mathématique complexe qui, si elle est effectuée manuellement, conduit presque toujours à des erreurs de positionnement millimétriques mais fatales pour le Clash Detection.

Fichiers IFC trop complexes : performances lentes et plantages

Un fichier IFC non optimisé peut peser des centaines de mégaoctets, voire des gigaoctets. Essayer d’éditer un fichier de ce type met à genoux même les stations de travail les plus puissantes.

Le problème réside souvent dans la redondance géométrique (par exemple, des vis et des boulons modélisés avec un très haut niveau de détail mais inutiles pour le coordination) ou dans une structure de données inefficace. Ouvrir, attendre le chargement, faire une petite modification et sauvegarder peut prendre des temps bibliques, rendant le processus d’édition économiquement insoutenable et augmentant le risque de plantage du logiciel avec une corruption du fichier en conséquence.

Données manquantes : propriétés, classifications, informations clés

Enfin, un problème classique est l’absence de données essentielles. Vous recevez un IFC qui est géométriquement parfait, mais c’est une « boîte vide ». Il manque des classifications (UniClass, OmniClass), il manque des matériaux, il manque des propriétés thermiques.

L’édition ici devient un travail de Data Entry massif. Le problème est que saisir ces données manuellement, élément par élément, sur un fichier IFC est impensable. Sans outils d’édition par lots (modification de groupe) ou scripts d’automatisation, enrichir un IFC pauvre en informations est une activité à haut risque d’erreur humaine et chronophage.

Problèmes plus courants lors de l’édition des fichiers IFC et solutions pour les résoudre

Solutions opérationnelles et meilleures pratiques pour résoudre les problèmes

Face aux problématiques récemment analysées, la tentation d’abandonner l’IFC et de revenir aux formats propriétaires peut être forte. Cependant, il existe des stratégies et des outils spécifiques qui transforment la gestion de l’IFC d’un cauchemar en un processus contrôlé et efficace. Voici comment intervenir de manière professionnelle.

Utiliser des éditeurs IFC dédiés pour des modifications ciblées

La règle d’or est : ne pas utiliser un logiciel d’authoring (BIM Authoring Tool) pour éditer un IFC. Des logiciels comme Revit, Archicad ou Edificius sont conçus pour créer des modèles, non pour modifier des fichiers IFC existants sans les convertir.

Pour des interventions chirurgicales sur les données ou la géométrie, il est nécessaire d’utiliser des éditeurs IFC natifs ou des plateformes de gestion de données dédiées (comme Simplebim, usBIM.editor ou BlenderBIM). Ces outils travaillent directement sur le schéma IFC sans conversions destructrices.

Le avantage de l’utilisation de ces outils est qu’ils permettent de modifier des propriétés, de déplacer des objets, de corriger des classifications ou de « tailler » le modèle (trimming) tout en maintenant intacte la structure originale du fichier et en garantissant que l’exportation suivante soit propre.

Configurer correctement les exportations IFC

La prévention est le meilleur remède. Une grande partie des problèmes d’édition se résout en amont, en configurant correctement la <em>Model View Definition</em> (MVD) lors de l’exportation.

• géométrie : choisir la représentation géométrique correcte. Pour la coordination, il est souvent préférable d’exporter des géométries simplifiées (<em>Coordination View</em>) plutôt que des modèles à très haute fidélité qui alourdissent le fichier ;
• mappage : s’assurer que les catégories du logiciel natif sont correctement mappées aux classes IFC (IfcWall, IfcSlab, etc.) avant d’exporter. Un fichier bien structuré à l’origine réduit drastiquement la nécessité d’édition corrective en aval.

Gérer correctement les coordonnées et les systèmes de référence

Pour éviter des modèles « volants », il est fondamental d’établir un point d’origine commun (Project Base Point) et de le partager entre tous les disciplines avant de commencer la modélisation.

• meilleure pratique : lors de l’exportation, vérifier toujours si le logiciel utilise les coordonnées relatives au projet ou les coordonnées géoréférencées (Survey Point) ;
• solution post-export : si vous recevez un fichier désaligné, au lieu de déplacer la géométrie manuellement (risquant des erreurs), utilisez les outils de « Placement Editor » présents dans les visualisateurs avancés ou les éditeurs IFC pour modifier uniquement la matrice de transformation du IfcSite ou IfcBuilding, réalignant le modèle sans toucher à la géométrie des objets.

Optimiser les fichiers IFC avant utilisation

Un fichier IFC « brut » sorti du logiciel d’authoring est rarement prêt pour l’utilisation finale. Il contient souvent des « déchets » numériques : objets invisibles, propriétés dupliquées ou géométries excessivement détaillées : 

• normalisation : utiliser des outils de validation et de normalisation pour nettoyer le fichier. Ce processus inclut la suppression d’objets non nécessaires (ex. mobilier intérieur pour une analyse structurelle), la simplification des maillages géométriques et la standardisation des noms des propriétés ;
• résultat : on obtient des fichiers plus légers, plus rapides à charger et beaucoup plus stables lors des opérations de visualisation ou de calcul.

Erreurs courantes à éviter

Même avec les meilleures intentions, il est facile de tomber dans des erreurs procédurales qui compromettent l’intégrité du projet BIM. Éviter ces faux pas est fondamental pour maintenir un flux de travail OpenBIM sain et productif.

Traiter l’IFC comme un fichier CAD

C’est l’erreur culturelle la plus ancrée. De nombreux opérateurs, habitués au format DWG/DXF, tentent de gérer l’IFC comme un ensemble de lignes et de couches.
L’IFC est une base de données orientée objet. « Exploser » un fichier IFC ou tenter de le manipuler comme s’il s’agissait de géométrie pure signifie détruire l’intelligence du modèle. Un mur n’est pas seulement deux lignes parallèles et un hachurage : c’est une entité (IfcWall) avec des propriétés thermiques, acoustiques et relationnelles. Le traiter comme un bloc CAD signifie perdre la « I » de BIM (Information), rendant le fichier inutile pour toute analyse avancée.

Faire de l’édition massive sans contrôle

L’utilisation de scripts ou d’outils de « Trouver et Remplacer » à grande échelle peut être dévastatrice si elle n’est pas gérée avec précaution.
Modifier massivement les noms des paramètres ou les valeurs des propriétés sans filtres adéquats peut écraser des données critiques ou, pire, altérer les GUID (Globally Unique Identifier). Le GUID est la « carte d’identité » unique de chaque objet : s’il est modifié ou régénéré accidentellement lors d’une édition massive, on perd la traçabilité de l’objet dans les révisions suivantes et on rompt les liens avec les plateformes de calcul ou de gestion des temps (4D/5D).

Utiliser des cycles continus d’import/export IFC

Comme mentionné au début, le soi-disant Round-tripping (Je crée avec le logiciel A -> J’exporte en IFC -> J’ouvre l’IFC avec le logiciel B -> J’exporte en IFC -> J’ouvre l’IFC modifié avec le logiciel A) est une pratique à éviter absolument.
Chaque fois qu’un fichier IFC est importé dans un logiciel d’authoring puis réexporté, il subit une « interprétation » de la part du moteur de conversion. Ce processus est similaire au jeu du « téléphone sans fil » : à la troisième ou quatrième conversion, la géométrie sera dégradée, les propriétés mal mappées et le fichier probablement corrompu. L’IFC doit toujours être le point d’arrivée ou de transit, jamais le format de travail continu.

Ignorer les versions, plugins et mises à jour logicielles

L’écosystème IFC est en évolution. Continuer à exporter en IFC 2×3 lorsque le client demande IFC4, ou utiliser des exportateurs obsolètes, est une grave erreur technique.

Les logiciels d’authoring (comme Revit, Archicad ou Edificius) publient fréquemment des mises à jour pour leurs plugins d’exportation IFC, qui corrigent des bugs et améliorent le mappage des géométries. Ignorer ces mises à jour signifie lutter contre des problèmes qui ont déjà été résolus par les développeurs. Vérifiez toujours d’avoir la dernière version du plugin d’exportation et convenez de la version du schéma IFC (MVD) au début du projet est le premier pas pour éviter des maux de tête lors de la livraison.

FAQ sur les problèmes causés par la modification de l’IFC

Pourquoi l’édition des fichiers IFC présente-t-elle des difficultés ?

L’erreur conceptuelle la plus répandue est de traiter un fichier IFC comme s’il s’agissait d’un fichier natif. L’IFC est, par définition, un format d’échange et d’archivage, conçu comme une ‘photographie’ statique d’un modèle. Tenter de modéliser ou de modifier lourdement la géométrie à l’intérieur d’un fichier IFC est techniquement ardu car la structure des données n’est pas paramétrique de la manière dont le sont les logiciels d’authoring.

Quelle est la différence entre l’édition directe et un workflow OpenBIM correct ?

L’approche ‘erronée’ (Édition Destructive) implique le cycle d’import/export (Round-tripping), qui cause une dégradation des données. Le workflow OpenBIM correct prévoit que l’IFC ne soit jamais modifié géométriquement par le récepteur ; les corrections doivent être effectuées sur le fichier natif par l’auteur. Cependant, pour des besoins d’enrichissement des données (BIM Data Enrichment), des outils spécifiques peuvent être utilisés pour des modifications ciblées sans toucher à la géométrie.

Quels sont les problèmes les plus courants lors de l’édition des fichiers IFC ?

Les problèmes les plus fréquents incluent : perte de données et tessellation des géométries courbes ; difficultés à modifier les propriétés informatives ; problèmes d’interopérabilité dus à différentes interprétations des classes entre logiciels ; erreurs d’affichage (Z-fighting) ; gestion incorrecte des coordonnées avec des modèles désalignés ; fichiers trop lourds causant des plantages ; et données manquantes comme des classifications ou des matériaux.

Comment résoudre les problèmes d’édition des fichiers IFC ?

Les solutions principales sont : utiliser des éditeurs IFC natifs dédiés (comme Simplebim ou usBIM.editor) au lieu des logiciels d’authoring pour des modifications ciblées ; configurer correctement les exportations (MVD et mappage des classes) en amont ; gérer rigoureusement les coordonnées (Project Base Point) et utiliser les ‘Placement Editor’ pour les réalignements ; optimiser et normaliser les fichiers en supprimant des objets inutiles et des propriétés dupliquées.

Quels sont les erreurs courantes à éviter dans la gestion de l’IFC ?

Les erreurs à éviter sont : traiter l’IFC comme un fichier CAD (en explosant les géométries et en perdant les informations) ; faire de l’édition massive sans contrôle en risquant d’altérer les GUID ; utiliser des cycles continus d’import/export (Round-tripping) qui corrompent le fichier ; ignorer les versions correctes du schéma IFC et ne pas mettre à jour les plugins d’exportation des logiciels.