Exiger « un IFC » ne veut rien dire, et c'est vrai deux fois. Derrière ce mot se cachent deux choix que presque personne ne pose consciemment : quelle version du schéma, et quelle vue (MVD) pour quel usage. Ce sont eux qui décident de ce qui voyage vraiment, et notamment si la géométrie reste modifiable ou non.
Le guide sur le format l’a établi : exiger « un IFC » ne suffit pas, il faut exiger quelles informations. La même imprécision frappe l’export lui-même, à travers deux réglages que la boîte de dialogue présente sans expliquer.
Quand un logiciel exporte un IFC, il vous fait choisir, souvent sans que vous y prêtiez attention, une version du schéma et une vue d’export, ce qu’on appelle un MVD. Ces deux choix sont orthogonaux : le premier décide de la richesse du langage disponible, le second décide de la part de ce langage que l’on emploie, et pour quel usage. Ensemble, ils déterminent ce que le destinataire recevra réellement.
Ignorer ces deux réglages, c’est laisser le logiciel décider à votre place, exactement comme pour les property sets. Et le résultat le plus lourd de conséquences se joue là : selon la vue choisie, la géométrie que vous livrez sera figée ou au contraire modifiable par celui qui la reçoit. Ce n’est pas un détail technique, c’est une décision qui engage la suite du travail.
Le guide sur le format IFC explique ce qu’un fichier contient. Celui-ci explique comment ce contenu est cadré au moment de l’export : quelle version, quelle vue, quelle géométrie. C’est le réglage qui précède celui, propre à chaque logiciel, de l’export depuis Revit. Les repères ci-dessous s’appuient notamment sur le guide IFC de Buildwise (IP 51, 2025).
Le schéma IFC évolue, et chaque version substantielle est resoumise à l’ISO pour approbation. Trois versions se croisent aujourd’hui sur les projets, et elles ne se valent pas selon l’usage.
La plus répandue et la mieux prise en charge par les logiciels, mais la plus pauvre : moins de classes, et incapable de porter certaines données comme la planification. On la garde par sécurité d’échange, pas pour sa richesse.
Plus de classes, des propriétés et des quantités standard plus complètes, une bien meilleure prise en charge des techniques spéciales. C’est la cible raisonnable pour la plupart des projets de bâtiment aujourd’hui.
Normalisée sous ISO 16739-1:2024, elle étend pour la première fois le schéma aux ouvrages de génie civil : ponts, routes, voies ferrées, tunnels, ouvrages hydrauliques. C’est la grande nouveauté, décisive hors du bâtiment.
Le critère de choix tient en une phrase : la version la plus récente que toute votre chaîne sait lire. La plus récente structure mieux l’information, mais son support logiciel est inégal, et un fichier qu’un partenaire ne peut pas ouvrir ne vaut rien, quelle que soit sa qualité. La version conditionne aussi ce qui est exportable : certaines données n’existent tout simplement pas dans les schémas anciens.
Quand un export pose problème sans cause évidente, réexportez le même modèle dans une version antérieure du schéma et comparez. Si le problème disparaît, il vient de la version ou de son support dans l’un des logiciels, pas de votre modèle. C’est un test rapide qui isole souvent l’origine d’une perte d’information.
Un MVD, pour Model View Definition, est un sous-ensemble défini du schéma IFC. Personne n’échange le schéma entier : on en exporte une vue, choisie selon ce que le destinataire va faire du fichier. Trois vues reviennent en permanence.
Un MVD n’est pas qu’un filtre de contenu : il restreint les types de géométrie autorisés, et c’est là qu’est l’essentiel. La vue de référence privilégie une géométrie statique, non modifiable ; la vue de transfert autorise la géométrie paramétrique, faite pour être reprise. Choisir le MVD, c’est donc déclarer une intention : « à consulter » ou « à retravailler ». Se tromper de vue, c’est livrer un modèle inexploitable pour l’usage réel du destinataire.
Derrière le choix du MVD se cache une bascule entre deux familles de géométrie, aux propriétés opposées. C’est ce qui explique à la fois le poids des fichiers et la possibilité, ou non, de les rééditer.
La géométrie est, de loin, ce qui pèse le plus dans un IFC. Un modèle très détaillé, tout en triangles, produit des fichiers lourds à ouvrir et lents à parcourir. Avant d’incriminer le format, demandez-vous si le niveau de détail géométrique correspond vraiment à l’usage : modéliser chaque boulon d’une charpente métallique alourdit tout, pour un bénéfice le plus souvent nul. Le poids se décide à la modélisation, puis au choix du MVD, pas après.
La version et le MVD ne se choisissent pas par préférence, mais par l’usage que le destinataire fera du fichier. La séquence est courte.
Veut-il consulter et coordonner, ou reprendre la modélisation ? La réponse départage à elle seule la vue de référence et la vue de transfert. Aucune raison de livrer du modifiable à qui ne fera que regarder.
IFC4 pour la plupart des bâtiments, IFC4.3 dès qu’il y a de l’infrastructure. Vérifiez que chaque partenaire sait la lire, sinon redescendez d’un cran plutôt que de livrer l’illisible.
Les vues standard sont celles que les logiciels supportent le mieux. Bricoler une vue exotique se paie en incompatibilités : la sobriété est ici une vertu, pas une facilité.
Essayez vos réglages sur un échantillon en amont, à l’étape de mobilisation prévue par l’ISO 19650. C’est le moment de découvrir qu’une vue ou une version passe mal, pas au premier jalon.
Un export, même bien réglé, se vérifie avant d’être envoyé, selon la séquence du guide sur le format. Le bon réglage ne dispense jamais du contrôle.
On ne choisit pas « le meilleur » MVD, on choisit celui qui correspond à l’usage. Une vue de transfert livrée à un coordinateur est un gâchis de poids et de complexité ; une vue de référence livrée à qui doit re-modéliser est une impasse. Le bon réglage est toujours relatif au travail du destinataire, jamais absolu.
Deux réglages discrets qui décident, bien plus que le mot IFC, de ce que reçoit vraiment votre partenaire.
Trois idées à emporter. Un export, c’est une version plus une vue, pas un simple changement d’extension : la version fixe la richesse du langage, le MVD la part qu’on en emploie. Le critère de la version est la compatibilité de toute la chaîne : la plus récente qui se lit partout, IFC4 pour le bâtiment, IFC4.3 pour l’infrastructure. Enfin, le MVD encode une intention en restreignant la géométrie : statique pour consulter et coordonner, paramétrique pour re-modéliser, et se tromper de vue rend le fichier inutile pour l’usage réel.
Ce guide prolonge le format IFC, dont il détaille le cadrage à l’export, et précède les réglages concrets de l’export depuis Revit. Pour exprimer non plus la forme mais les informations exigées, la logique du MVD cède aujourd’hui la place à un standard ouvert dédié : l’IDS. Et pour resituer ces choix dans la stratégie d’ensemble, openBIM contre closed BIM.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
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.
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.
Un cahier des charges dit « les murs porteurs doivent indiquer leur résistance au feu ». Deux personnes le lisent et le vérifient différemment ; un ordinateur ne peut pas le vérifier du tout. L'IDS traduit cette même exigence dans une forme que la machine exécute, avec le même verdict partout. C'est le chaînon qui manquait entre écrire une exigence et la contrôler.