Choisissez la bonne MVD et évitez les IFC “inutilisables”

Vous allez apprendre à expliquer (et justifier) la logique des Model View Definitions (MVD), à distinguer les MVD majeures (CV 2.0, RV 1.2, DTV 1.1) selon vos usages, et à relier ces choix aux mécanismes de certification logicielle et de validation technique des fichiers IFC.

Introduction

Pourquoi “tout l’IFC” n’existe pas en pratique

Quand un projet dérape en openBIM, la cause n’est pas toujours « l’IFC ». Très souvent, c’est un mauvais alignement entre le cas d’usage (ce que vous voulez faire) et le sous-ensemble d’IFC réellement pris en charge (ce que les logiciels savent produire/lire correctement).

L’IFC est un schéma de données très vaste, conçu pour couvrir un grand nombre de domaines et de scénarios. Or, aucun logiciel n’a intérêt à implémenter l’intégralité : un outil de coordination n’a pas besoin des mêmes capacités qu’un outil d’architecture ou qu’un outil de statique. C’est exactement pour résoudre ce problème qu’existent les MVD (Model View Definitions).

Définition

Définition : MVD (Model View Definition)

Une Model View Definition (MVD) décrit un sous-ensemble de la spécification IFC (classes, types, quantités, Pset, propriétés) adapté à un scénario d’échange précis.

Elle répond concrètement à deux questions :

Quoi échanger (quelles classes IFC, quelles informations) ?
Comment l’échanger (quelles restrictions/attentes de représentation pour que le destinataire sache l’interpréter) ?

La MVD est donc un moyen de rendre l’échange répétable, prévisible et interopérable entre logiciels.