Une maquette peut être irréprochable à l'écran et inutilisable en aval. Elle peut être visuellement grossière et parfaitement exploitable. La propreté d'un modèle ne se juge pas en le regardant : elle se juge à ce que les autres peuvent en faire.
« Propre » évoque le rangement : des noms cohérents, des vues classées, pas de calques orphelins. C’est agréable, et ce n’est pas le sujet. La question utile est ailleurs : qui, en aval, va se servir de ce fichier, et pour quoi ?
Un modèle n’a pas de qualité intrinsèque. Il a une aptitude à des usages déclarés. Le même fichier est excellent pour produire des plans et catastrophique pour sortir des quantités, sans qu’une seule ligne ait changé. Juger sa propreté sans savoir ce qu’on veut en faire n’a donc pas de sens, et c’est pourtant l’exercice auquel se livrent la plupart des revues.
Cela ne veut pas dire que tout se vaut. Cela veut dire que les règles de modélisation se déduisent des usages, et qu’un projet qui n’a pas déclaré ses usages ne peut pas dire ce qu’est une bonne maquette chez lui.
Ne demandez pas « cette maquette est-elle propre ? » mais « cette maquette permet-elle de faire ce qu’on a dit qu’on ferait ? ». La première question appelle un avis, la seconde une vérification. Ce guide traite du côté producteur ; mesurer l’écart chez le destinataire, c’est le sujet de l’audit.
Une seule décision de modélisation conditionne presque tout ce qui se passera ensuite, et elle se prend en trois secondes, souvent sans y penser : avec quel type d’objet je modélise ça ?
Prenons comme exemple un poteau béton de forme un peu particulière. La famille de poteau du logiciel ne permet pas la géométrie voulue, alors on le modélise en objet générique. À l’écran, le résultat est parfait : bonne forme, bonne position, bon matériau. Personne ne verra jamais la différence sur un plan.
En aval, ce poteau a disparu. Il n’apparaît pas dans le tableau de quantités de structure, qui interroge la catégorie et non la forme. Il échappe aux règles de détection de conflits ciblant les éléments porteurs. Il n’est pas sélectionné par les filtres du coordinateur. Et à l’export IFC, faute de catégorie signifiante, il part en IfcBuildingElementProxy : la classe fourre-tout, celle dont les guides d’application recommandent unanimement de limiter l’usage au strict minimum.
C’est d’ailleurs le contrôle le plus rentable qu’on puisse faire sur sa propre maquette. Comptez vos proxies. Leur nombre est une mesure directe du nombre d’objets que vous avez modélisés sans dire ce qu’ils étaient, et il ne demande ni audit ni outil spécialisé.
On croit corriger cela en forçant la classe au moment de l’export. C’est déconseillé pour une raison peu connue : forcer une classification fait perdre à l’objet sa logique de construction géométrique, ce qui peut fausser les quantitatifs et les simulations. Autrement dit, un mauvais choix de catégorie ne se répare pas en sortie. Il se répare là où il a été fait.
Aucune n’est visible sur un plan imprimé. Toutes se paient chez quelqu’un d’autre, plus tard.
Aucune ne se voit sur une impression, et trois sur quatre produisent un résultat visuellement correct. C’est ce qui les rend durables : rien ne signale l’erreur tant que quelqu’un, en aval, n’essaie pas de se servir du fichier pour autre chose que le regarder.
La tentation est grande de s’en remettre aux outils de vérification : on modélise, on lance le contrôle, on corrige. C’est un filet utile, avec des mailles beaucoup plus larges qu’on ne le croit.
Les contrôles automatiques ne remplacent pas la propreté à la source : ils la mesurent. Un défaut situé dans la tolérance ne déclenchera rien, et la maquette sera déclarée conforme. C’est pourquoi une équipe qui compte sur l’audit pour rattraper sa modélisation découvre ses erreurs tard, en aval, chez celui qui les subit.
Elles tiennent en une page dans la convention. Leur absence n’est pas un détail d’organisation : c’est ce qui rend impossible toute discussion sur la qualité, faute de référence commune.
La sixième. Un producteur qui contrôle avant de déposer transforme la nature de la relation : les remarques qu’il reçoit portent alors sur le fond, pas sur des oublis. C’est aussi ce qui rend un audit supportable, parce qu’il cesse d’être la découverte publique de ce qu’on aurait pu voir seul.
La propreté d’une maquette n’est pas une vertu de modeleur consciencieux. C’est une propriété relative aux usages, qui se décide en amont et se vérifie à la source.
Trois idées à emporter. « Propre » n’est pas un absolu : c’est l’aptitude à des usages déclarés, et un projet qui ne les a pas déclarés ne peut pas dire ce qu’est une bonne maquette. La catégorie de l’objet est la décision porteuse, parce que tout l’aval l’interroge (quantités, filtres, règles de conflits, classe d’export) et parce qu’elle ne se rattrape pas en sortie sans abîmer autre chose. Enfin, les contrôles automatiques mesurent la propreté, ils ne la produisent pas : ce qui reste dans la tolérance passe, et se paie chez quelqu’un d’autre.
Pour borner le détail utile plutôt que de modéliser au maximum, voyez LOD et LOIN. Pour le versant destinataire, celui qui mesure l’écart, auditer une maquette. Pour ce qui se joue au moment de la sortie du fichier, l’export IFC depuis Revit. Pour deux usages dont ce guide conditionne directement la réussite, le BIM 4D et le BIM 5D. Pour que les parois composites gardent leurs couches jusqu’au bout, les matériaux multicouches. Sur un ouvrage existant, ces règles s’appliquent aussi, avec une difficulté de plus : le scan to BIM. Pour les objets que vous ne modélisez pas mais que vous téléchargez, où le même défaut de catégorie se retrouve, objets BIM et bibliothèques. Et sur la tentation de corriger tout cela par un script plutôt que de modéliser juste, Dynamo. Et parce qu’un objet mal catégorisé est aussi un objet qu’aucun tableau de bord ne saura rattacher, Power BI et le BIM.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
Un même acronyme pour deux notions, des paliers américains détournés de leur sens, et une norme récente qui démonte toute l'approche. Le niveau d'information ne se décrète pas globalement : il se définit par objet, par usage et par jalon.
Sans exigences écrites à l'avance, un audit n'est qu'un avis, et le producteur a le droit de ne pas être d'accord. Voici les quatre familles de contrôle, dans l'ordre où elles se mènent, et ce qui sépare un audit qui améliore d'un audit qui indispose.
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.