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 débutant venant du dessin 2D passe ses premières semaines à se battre contre le logiciel. Ce n’est pas une question d’ergonomie : il demande à Revit quelque chose que Revit ne fait pas.
Dans un logiciel de dessin, vous produisez des traits. Chaque vue est un dessin distinct, que vous dessinez puis entretenez à la main. Si un mur bouge, vous corrigez le plan, puis la coupe, puis la façade, puis la nomenclature. Rien ne relie ces documents entre eux, sinon votre vigilance.
Dans Revit, vous ne produisez qu’une chose : un modèle, c’est-à-dire une base de données d’objets. Tout ce que vous regardez, plan, coupe, perspective, tableau, n’est qu’une manière d’interroger cette base. Vous ne dessinez jamais une coupe : vous demandez à voir le modèle coupé à tel endroit. Déplacez le mur, et les huit documents où il apparaît changent ensemble, parce qu’ils n’ont jamais été huit dessins.
Chaque fois que vous vous apprêtez à corriger quelque chose dans une vue, arrêtez-vous. Demandez-vous si le problème est dans la vue ou dans le modèle. Neuf fois sur dix, il est dans le modèle, et le corriger dans la vue crée une incohérence que quelqu’un paiera plus tard.
Toute l’interface s’organise autour de cette chaîne. La connaître permet de savoir, devant n’importe quelle commande, à quel étage on est en train d’agir.
Les vues sont des requêtes : un plan montre le modèle coupé à une hauteur donnée, avec des règles de visibilité. Les annotations ne sont pas du texte libre mais des étiquettes qui lisent une donnée de l’objet : cotez un mur, la cote se met à jour quand le mur bouge. Les feuilles assemblent des vues pour produire le document livré, sans jamais dupliquer le modèle.
Puisqu’une vue est un jeu de règles, ces règles se sauvegardent et se réappliquent. Un gabarit de vue impose d’un coup l’échelle, les filtres et la visibilité à des dizaines de vues. C’est le premier vrai gain de temps du logiciel, et celui que les autodidactes découvrent le plus tard.
Si vous ne deviez retenir qu’une seule structure de Revit, c’est celle-ci. Elle explique le classement des objets, le comportement des paramètres, et la façon dont vos données sortiront du logiciel.
La nature de l’objet, imposée par le logiciel : murs, portes, équipements électriques. Vous ne la créez pas, vous la choisissez en décidant avec quel outil modéliser.
Un modèle d’objet dans cette catégorie, avec sa géométrie paramétrable et son comportement. Une famille de porte à un vantail, par exemple.
Une déclinaison précise de la famille : la porte 90 × 210 coupe-feu une heure. Ce que vous choisissez dans une bibliothèque.
L’objet posé à un endroit du bâtiment. Cette porte-là, dans ce mur-là, avec son numéro de local.
Cette hiérarchie a une conséquence directe sur ce que vous pouvez livrer. La catégorie détermine comment l’objet sera compris par les autres logiciels : c’est elle qui pilote la traduction lors d’un export IFC. Un équipement technique modélisé en modèle générique sortira comme un objet sans identité, quel que soit le soin apporté à sa forme.
Retenez la subtilité qui piège tout le monde : une famille Revit ne choisit pas librement sa catégorie, elle en hérite du gabarit avec lequel on l’a créée. Renommer un objet ne change donc rien à ce qu’il est aux yeux du logiciel, ni à ce qu’il deviendra à l’export.
Modéliser dans une catégorie commode plutôt que dans la bonne. Le modèle générique accepte tout, se dessine facilement, et détruit silencieusement l’exploitabilité de l’objet : ni nomenclature fiable, ni contrôle automatique, ni export propre. Le coût n’apparaît qu’au moment de livrer, quand la reprise est massive.
Les paramètres, c’est-à-dire les données portées par les objets, existent à deux étages. Se tromper d’étage est réversible, mais laborieux à grande échelle.
Un paramètre de type est partagé par tous les objets du même type : modifiez le degré coupe-feu du type « porte 90 × 210 CF1h », et les quarante portes de ce type changent ensemble. Un paramètre d’instance appartient à un seul objet : son numéro, son local, sa date de pose.
Posez-vous une question simple : « si je change cette valeur, les autres objets identiques doivent-ils changer aussi ? » Si oui, c’est un paramètre de type. Si non, c’est une instance. Cette question évite la quasi-totalité des erreurs de structuration de données.
Une nomenclature n’est pas un tableau que vous remplissez : c’est une interrogation en direct de la base. Elle affiche ce que le modèle contient réellement, pas ce que vous croyez y avoir mis.
C’est la raison pour laquelle elle constitue le meilleur outil de contrôle qualité du logiciel, et il est gratuit. Créez une nomenclature des portes affichant type, niveau et degré coupe-feu : les cases vides sont vos données manquantes, les valeurs aberrantes vos erreurs de saisie, et les doublons vos types créés en double par inadvertance.
Avant chaque livraison, ouvrez une nomenclature des catégories que vous livrez et triez par la colonne qui doit être remplie. Les lignes vides remontent en haut. Trente secondes de contrôle qui repèrent ce qu’un export IFC vous reprocherait deux semaines plus tard.
On vous transmet un fichier dont vous n’avez pas écrit une ligne. Voici l’ordre dans lequel l’explorer pour comprendre en quinze minutes comment il est construit.
Ouvrez une élévation. Les niveaux sont la colonne vertébrale : tout objet s’y rattache, et c’est ce rattachement qui permettra plus tard de filtrer par étage. Des niveaux bricolés annoncent des ennuis.
La façon dont les vues sont nommées et rangées vous dit tout de la discipline de l’équipe. Une arborescence chaotique signale que chacun a créé ses vues dans son coin.
Vérifiez si les vues sont pilotées par des gabarits ou réglées à la main. Dans le second cas, toute modification d’affichage devra être répétée vue par vue.
Créez une nomenclature sur une catégorie que vous devez livrer. Vous saurez immédiatement si le modèle est renseigné ou seulement dessiné.
Repérez les objets modélisés en modèle générique. C’est là que se cachent les futurs problèmes d’export et de quantitatif.
Aucun outil n’est bon partout, et connaître les limites du vôtre évite de les découvrir en cours de projet.
Ce que vous venez de comprendre, catégories, types et occurrences, est exactement ce qu’un script manipule. C’est le préalable à l’automatisation, traitée dans Dynamo.
La suite immédiate est les familles Revit, où se joue concrètement le choix de catégorie évoqué plus haut. Cette même hiérarchie détermine la traduction lors de l’export IFC depuis Revit. 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.
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.
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.