Non, l'IFC n'est pas « le PDF de la maquette ». C'est une base de données structurée qui transporte vos objets et leurs propriétés d'un logiciel à l'autre. Comprendre ce qu'il contient vraiment, c'est arrêter de subir les exports ratés.
C’est la comparaison qu’on entend partout, et elle est trompeuse sur le point le plus important.
Un PDF fige une image. Il conserve l’apparence et perd tout le reste : vous ne pouvez plus demander à un PDF combien il contient de portes coupe-feu. Un fichier IFC, lui, conserve la structure : chaque mur reste un mur, chaque porte connaît son degré coupe-feu, sa hauteur, son numéro de local, et sait à quel étage elle appartient.
La confusion vient d’un vrai point commun : dans les deux cas, on fige quelque chose pour l’envoyer à quelqu’un d’autre. L’IFC n’est pas un format dans lequel on travaille au quotidien, c’est un format dans lequel on livre. Mais ce qu’il livre reste interrogeable, filtrable et vérifiable, alors qu’un PDF ne livre qu’un dessin.
L’IFC (Industry Foundation Classes, normalisé sous l’ISO 16739 et maintenu par buildingSMART) est un format ouvert qui décrit un ouvrage sous forme d’objets typés porteurs de propriétés et de relations. Il permet à des logiciels d’éditeurs concurrents d’échanger autre chose que de la géométrie. Le schéma évolue par versions successives, jusqu’à IFC4.3 (ISO 16739-1:2024) qui l’étend aux infrastructures de génie civil (ponts, routes, voies ferrées, tunnels).
Un IFC n’est pas un tas d’objets en vrac. Il est organisé selon une hiérarchie spatiale stricte, à laquelle tout élément est rattaché. C’est cette ossature qui rend le fichier exploitable.
Si un objet n’est rattaché à aucun étage, il existera dans le fichier mais deviendra invisible à toute requête du type « donne-moi les équipements du niveau 3 ». C’est la première cause d’exports qui « ne marchent pas ».
IfcWall, IfcDoor, IfcSpace, IfcDistributionElement…). C’est ce qui permet au logiciel receveur de comprendre ce qu’il reçoit.IfcBuildingElementProxy) arrive comme une forme sans identité.Pset_ (par exemple Pset_WallCommon et sa propriété FireRating).Chaque élément porte un GlobalId, une suite de caractères unique générée par le logiciel et stable dans le temps. Elle n’a aucun sens pour un humain, mais c’est elle qui permet à une remarque de désigner sans ambiguïté « cet objet-là », et à un enrichissement d’être réinjecté au bon endroit d’une livraison à l’autre. Sans cette identité persistante, ni le BCF ni le suivi entre versions ne seraient possibles.
La phrase revient à chaque projet. Elle mélange deux choses très différentes : ce que le format est incapable de transporter, et ce que votre export n’a pas transporté.
La colonne de gauche est une propriété du format : elle est normale et assumée, puisque l’IFC sert à livrer, pas à co-éditer. La colonne de droite, en revanche, relève entièrement de vos réglages et de votre convention. Quand quelqu’un dit « l’IFC perd tout », il parle presque toujours de la colonne de droite.
La géométrie impressionne, mais c’est dans les property sets que se joue l’utilité réelle d’un IFC. Trois familles à distinguer.
Définis par buildingSMART et compris par tous les logiciels. Le socle interopérable, à privilégier systématiquement.
Vos propres jeux de propriétés. Ils voyagent parfaitement, mais leur signification doit être documentée dans la convention BIM.
Les quantités calculées (surfaces, volumes, longueurs). Précieuses pour les métrés, à condition que l’export les ait activées.
Une propriété qui n’a pas été demandée avant ne sera pas dans l’export. Exiger « un IFC » ne veut rien dire : il faut exiger quelles informations, sur quels objets, dans quels property sets. C’est exactement le rôle de l’EIR et de la convention BIM, et c’est pour cela que l’ISO 19650 insiste tant sur l’expression des besoins.
Prenons comme exemple une porte coupe-feu, objet dont la valeur ne tient pas à sa forme mais à ses propriétés réglementaires. Voici ce qui lui arrive au moment de l’export, étape par étape.
Dans la maquette, c’est une porte. À l’export, elle doit devenir l’entité porte du format, et non un objet générique. Un mauvais typage ici rend tout le reste inutile.
C’est cette relation qui permettra la requête « toutes les portes coupe-feu du niveau 3 », impossible sans rattachement correct.
Le degré coupe-feu et le sens d’ouverture partent vers un property set convenu. Sans ce mappage, ils restent dans le logiciel d’origine et disparaissent silencieusement.
Si l’export active les quantités, les dimensions d’ouverture accompagnent l’objet, prêtes pour le chiffrage.
Avant d’exploiter le fichier, le receveur contrôle que la porte existe, qu’elle est typée, localisée et renseignée. Cinq minutes ici évitent trois semaines de reprise.
Correctement portée par l’IFC, l’information permet de vérifier automatiquement que chaque porte d’un cheminement d’évacuation présente le degré exigé.
Vous n’avez pas besoin d’un outil de contrôle qualité avancé pour repérer les trois quarts des problèmes. Une visionneuse gratuite et cette séquence suffisent.
Faites ce contrôle à la réception de chaque fichier, pas à la fin de la phase. Un export mal réglé détecté le jour même se corrige en une heure ; détecté trois mois plus tard, il a déjà contaminé tous les travaux qui s’appuyaient dessus. Quand le fichier compte, ce tri express se prolonge en une inspection complète : contrôler un IFC pas à pas.
L’IFC n’est ni magique ni défaillant : c’est un contenant, et sa qualité dépend de ce que vous avez demandé qu’on y mette.
Trois idées à emporter. L’IFC transporte des objets typés porteurs de propriétés, pas une image : c’est ce qui le rend interrogeable. Il ne sert pas à co-éditer mais à livrer, et lui reprocher de ne pas faire d’aller-retour revient à lui reprocher de faire son travail. Enfin, la quasi-totalité des « pertes » attribuées au format viennent en réalité de réglages d’export et d’exigences jamais formulées.
Ce guide pose le socle. Pour ouvrir concrètement un fichier et en lire les propriétés, voyez les visionneuses IFC gratuites. Le choix de la version et de la vue d’export est détaillé dans versions d’IFC et MVD, et les réglages concrets logiciel par logiciel dans exporter un IFC propre depuis Revit. À ne pas confondre avec les systèmes de classification, qui rangent l’objet dans une grille externe au lieu de dire ce qu’il est. Ce format est le socle d’un choix plus large, l’openBIM contre closed BIM. Si vous ne deviez lire qu’un guide après celui-ci, prenez le cycle de vie de la donnée : l’IFC n’est que le véhicule d’un trajet qui, lui, commence bien avant l’export.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Un export IFC n'est pas un enregistrement, c'est une traduction. Tant que vous ne décidez pas comment Revit traduit, il décide à votre place. Voici les trois réglages qui font 90 % du résultat, et la logique derrière, valable quelle que soit votre version.
Une information saisie une fois doit servir jusqu'à l'exploitation, sans jamais être retapée. Ce principe explique à lui seul pourquoi les normes, les processus et les logiciels BIM sont faits comme ils le sont. Le comprendre, c'est arrêter de subir le BIM.
La norme dont tout le monde parle, expliquée sans jargon : qui demande quoi, qui livre quoi, et comment l'information est validée avant d'être partagée. Après ce guide, l'ISO 19650 ne vous impressionnera plus.