Uniclass, OmniClass, Uniformat, MasterFormat : on cherche à choisir « la bonne », et c'est déjà se tromper. Un même mur est un système fonctionnel pour qui conçoit, un produit à acheter pour qui construit, un ensemble à maintenir pour qui exploite. Ce ne sont pas des systèmes concurrents, ce sont des angles de lecture.
Avant de comparer les systèmes, il faut lever une confusion qui rend toute la suite incompréhensible. Trois notions distinctes portent des noms voisins, et on les mélange en permanence.
Dans votre outil de modélisation, un objet appartient à une catégorie interne : « mur », « poteau », « équipement ». C’est propre au logiciel, et c’est ce que traite modéliser proprement.
À l’export, l’objet devient une entité du format ouvert : un mur devient une classe de mur. C’est le socle de l’IFC, et il décrit ce que l’objet est, techniquement.
Un code venu d’un référentiel externe, ajouté à l’objet, qui dit à quoi il se rattache dans une organisation du monde construit. C’est le sujet de ce guide, et c’est autre chose que les deux premières.
La distinction cruciale est entre la deuxième et la troisième. La classe d’échange dit qu’un objet est un mur. La classification dit que ce mur relève de telle famille d’ouvrages, tel résultat de travaux, tel poste de coût. La première est intrinsèque à l’objet, la seconde lui est attribuée selon une grille choisie.
Demandez-vous : cette information décrit-elle ce que l’objet est, ou la case dans laquelle je range cet objet ? Le premier relève de la classe d’échange, décrite dans le format IFC. Le second, seulement, est une classification. Un objet peut être un seul type de mur et porter en même temps plusieurs classifications, sans contradiction.
C’est l’idée qui débloque tout le sujet : une classification n’est pas une étiquette unique, c’est un axe de lecture. Comme un objet se lit selon plusieurs axes, il porte plusieurs classifications à la fois.
Prenons comme exemple un mur de façade ventilé. Il n’est pas « une » chose dans le classement : il en est plusieurs, selon la question qu’on lui pose.
Les deux lectures sont justes en même temps, et un objet bien renseigné porte les deux codes. Vouloir en choisir un seul, c’est amputer soit l’estimation précoce, soit la prescription détaillée. La bonne question n’est donc jamais « quel système », mais « pour quels usages, et donc quels axes ai-je besoin de renseigner ? ».
Une classification est une clé de rangement, orientée usage. Elle sert à retrouver, regrouper, chiffrer et vérifier des ensembles d’objets. C’est exactement la même famille de besoin que le code de zone du BIM 5D : sans code partagé porté par les objets, aucun rapprochement automatique avec une bibliothèque de prix ou un référentiel n’est possible.
Il existe une poignée de systèmes de référence. Les connaître par cœur ne sert à rien ; comprendre l’axe que chacun privilégie sert à savoir lequel répond à votre question.
Vous ne pouvez pas vous reposer sur un système national évident, parce qu’il n’y en a pas. Cela ne vous dispense pas de choisir : cela vous oblige à le faire explicitement, dans votre cahier des charges et votre convention. Un projet sans classification convenue n’a pas « pas de classification » : il a autant de classifications improvisées que d’intervenants.
La décision se prend comme toute exigence d’information : à partir de l’usage, jamais à partir du système.
N’exigez une classification que si quelqu’un s’en servira pour regrouper ou chiffrer. Un code que personne n’interroge est un champ rempli pour rien, qui alourdit la saisie et donne l’illusion de la rigueur. La bonne classification est celle qui répond à une question que vous vous posez réellement, sur le bon axe, et pas une de plus.
Le sujet paraît aride et administratif. Il tient en trois idées, dont la première dissout la moitié des malentendus.
Trois idées à emporter. Une classification n’est ni la catégorie de l’outil ni la classe d’échange : les deux premières disent ce qu’un objet est, la troisième dit dans quelle case on le range selon une grille choisie. Un objet porte plusieurs classifications à la fois, parce qu’il est un système fonctionnel, un produit et un ensemble à exploiter selon qui le regarde ; vouloir choisir « un seul » système ampute un usage. Enfin, on choisit par l’usage, pas par le système : l’axe utile se déduit de ce qu’on veut faire, et une classification que personne n’interrogera est un champ rempli pour rien.
La distinction avec la classe d’échange se comprend dans le format IFC, et celle avec la catégorie de l’outil dans modéliser proprement. L’usage qui exploite le plus les classifications est le chiffrage, décrit dans le BIM 5D. Et pour transformer un besoin de classification en exigence opposable, tout part de rédiger un EIR.
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.
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.
On attend du 5D qu'il chiffre. Il ne chiffre pas. Il extrait des quantités géométriques, et le standard IFC lui-même livre deux valeurs différentes pour le même mur. Entre ce que la maquette mesure et ce que l'entreprise facture, il reste une convention que presque personne n'écrit.