Le choix du gabarit au moment de créer une famille fixe sa catégorie, et cette catégorie ne se change plus. C'est la décision la plus lourde de conséquences du logiciel, prise en trois secondes par quelqu'un qui ignore souvent qu'il la prend.
Au moment de créer une famille, on choisit un gabarit de départ. Ce geste anodin fixe la catégorie de l’objet, et la catégorie ne se change pas après coup.
Comme le montre le guide sur la logique de Revit, la catégorie détermine ce que l’objet est aux yeux du logiciel : comment il se range, ce qu’on peut en quantifier, quels filtres le voient, et surtout ce qu’il deviendra à l’export IFC. Une porte créée depuis un gabarit de modèle générique restera un modèle générique, même nommée « Porte 90 × 210 », même parfaitement dessinée.
Le problème est que ce choix se fait au tout début, souvent par la personne la moins informée de la chaîne, et que ses conséquences n’apparaissent que des mois plus tard, quand on tente de sortir une nomenclature ou de livrer un fichier exploitable. À ce stade, la seule correction possible consiste à recréer la famille et à remplacer toutes ses occurrences.
Avant de créer une famille, posez la question à voix haute : de quelle nature est cet objet dans le bâtiment ? Puis choisissez le gabarit correspondant, même s’il est moins commode à dessiner. Trois secondes de réflexion contre plusieurs jours de reprise, l’arbitrage est vite fait.
Beaucoup de blocages de débutant viennent de là : on essaie de traiter un mur comme une porte, et le logiciel refuse. Ce ne sont pas les mêmes objets.
Murs, sols, toitures, réseaux. Elles n’existent qu’à l’intérieur d’un projet, ne se créent pas depuis un gabarit et ne s’enregistrent pas en fichier séparé. On ne peut qu’en dupliquer les types et en régler la composition.
Portes, fenêtres, mobilier, équipements. Ce sont des fichiers autonomes, créés depuis un gabarit et chargés dans les projets. C’est là que se joue l’essentiel du travail de bibliothèque.
Modélisées directement dans le projet pour un cas unique. Pratiques pour une forme non standard, coûteuses à maintenir, et incapables d’être réutilisées ailleurs.
Cette distinction explique une bonne partie des questions sans réponse apparente. « Pourquoi je ne trouve pas le fichier de ce mur » : parce qu’il n’y en a pas. « Pourquoi je ne peux pas charger ce sol dans un autre projet » : parce qu’un sol n’est pas un objet chargeable, seul son type se copie d’un projet à l’autre.
Elles sont utiles pour un élément véritablement unique, et elles doivent le rester. Multipliées, elles alourdissent le fichier, échappent à toute logique de bibliothèque et rendent les nomenclatures incohérentes. Si vous en créez deux fois la même, elle aurait dû être une famille chargeable.
Neuf fois sur dix, quand quelqu’un se lance dans la création d’une famille, un simple type aurait suffi. La différence d’effort est considérable.
Demandez-vous si la différence recherchée s’exprime en valeurs ou en formes. Une porte plus large, un mur plus épais, un matériau différent : ce sont des valeurs, donc des types. Une porte à galandage là où la famille ne gère que des vantaux battants : c’est un comportement, donc une famille.
Une famille réussie n’est pas la plus détaillée ni la plus paramétrable. C’est celle qui reste juste, légère et prévisible sur toute la durée d’un projet.
C’est le raccourci le plus tentant du logiciel, et celui qui coûte le plus cher en fin de projet.
Le gabarit de modèle générique accepte tout. Il ne pose aucune contrainte, se dessine facilement, et permet de produire rapidement un objet qui ressemble à ce qu’on veut. C’est précisément ce qui le rend dangereux : rien ne signale que quelque chose ne va pas, jusqu’au jour où l’on tente d’exploiter le modèle.
Les conséquences arrivent groupées et tardivement. La nomenclature du lot ne voit pas l’objet, puisqu’il n’appartient pas à la catégorie attendue. Les filtres et les vues ne le distinguent pas. L’export IFC le transmet comme un objet sans identité métier, invisible aux contrôles automatiques et inutilisable en exploitation. Et la reprise suppose de recréer la famille, puis de remplacer chaque occurrence en conservant les données déjà saisies.
Ouvrez une nomenclature de modèles génériques sur le projet. Si elle contient des objets qui devraient être des équipements, des menuiseries ou des éléments de structure, vous connaissez déjà votre prochaine reprise. Faites ce contrôle tôt : son coût croît avec le nombre d’occurrences posées.
Elles ne relèvent pas de la maîtrise du logiciel, mais de décisions prises trop vite au mauvais moment.
Une bonne part des familles d’un projet ne sont pas fabriquées mais téléchargées. Comment distinguer un objet exploitable d’un objet de vitrine, et pourquoi un objet de fabricant est prématuré en conception : objets BIM et bibliothèques.
La structure catégorie, famille, type, instance est posée dans Revit, une base de données déguisée en logiciel de dessin. Les conséquences du typage à la livraison sont traitées dans exporter un IFC propre depuis Revit. Et pour savoir jusqu’où pousser le détail de vos objets, voyez LOD et LOIN.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
La plupart des blocages de débutant viennent d'un malentendu : on essaie de dessiner, et Revit résiste. Il ne dessine pas, il enregistre. Comprenez ce déplacement et l'interface devient lisible, y compris les parties que vous n'avez jamais ouvertes.
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 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.