Bonjour,
Vous ne trouverez pas de ressources complètes en ligne, puisqu'il n'y a aucune contrainte règlementaire sur le nom des familles. Cela s'explique par le simple fait que chaque logiciel fonctionne à sa manière, et le concept de familles est inhérent à Revit. Or une règlementation, par essence, se veut généraliste et non spécifique.
Ceci répond donc aussi à votre question première concernant des "conventions de nommage qui fonctionnent bien".
A. Exemple de convention de nommage
Pour apporter tout de même une réponse technique à votre question, voici mes règles de nommage des familles pour les gabarits que je crée pour mes clients (sauf s'ils ont leurs propres exigences évidemment). C'est aussi celle que je préconise lorsque j'occupe le poste de coordinateur ou manager BIM et que de telles règles doivent être mises en place (autant que possible, dans ce rôle, je n'impose pas de règle pour les noms des familles, mais seulement pour les paramètres utiles à la gestion des bases de données).
Nom de la famille- Ecrit en toutes lettres
- Respect des accents
- Première lettre en majuscule, autres lettres en minuscule (sauf si le nom contient un nom propre)
- Pas de caractères spéciaux, sauf ( ) et -
- Pas de code, trigramme ou autre qui alourdissent et complexifient le décryptage du nom et parce que je trouve ça très moche (exemple, comme je le vois très souvent passer : FAC_ARI_POR_INT_2BAT.rfa pour désigner une famille appartenant/créée par la société Factotum (FAC), concernant l'architecture intérieure (ARI), s'agissant d'une porte (POR) intérieure (INT) à 2 battants (2BAT))
- Pas de règle de nommage qui risque de rendre la mise à jour ou la création d'une nouvelle famille ou d'un nouveau type laborieux (systèmes de numérotation souvent utilisée pour ordonner les familles/types dans le sélecteur de type, par exemple)
J'applique d'ailleurs la même règle pour les noms des types, des paramètres, des sous-catégories etc. bref, tout ce qui doit être nommer (exception faite des paramètres invisibles dont le nom commence toujours par #), que ce soit dans Revit ou d'autres logiciels, lorsque ceux-ci le permettent.
Vous trouverez en pièce jointe un extrait d'une base de données que j'ai créée pour un client, pour illustrer ces règles appliquées aux noms de familles, de types et de sous-catégories d'objets de modèle.
B. Revit ou BIM ?
Par ailleurs, travailler avec Revit ne signifie pas de facto que vous "faites du BIM".
On ne le dira jamais assez, travailler avec Revit (ou équivalent) à la manière d'Autocad, c'est à dire de manière totalement indépendante et circonscrite au seul dessin (aucun échange uni ou bidirectionnel avec d'autres logiciels/bases de données internes à l'entreprise ou externes normalisé et planifié) ne constitue pas une démarche BIM.
Si les projets que vous réalisez avec Revit ne s'inscrivent pas dans une réelle démarche BIM (= faire plus que juste échanger des 3D comme on échangerait des DWG) émanant de la MOA, de la MOE, voire en dernier lieu d'une concertation entre les entreprises de travaux, alors vous ne "faites pas du BIM" au seul titre de modéliser des ouvrages en 3D.
Donc,
si vous utilisez Revit de la sorte, peu importe la manière de nommer vos familles. La seule imposition cependant est de conserver une règle de nommage fixe, interne à votre entreprise, peu importe quelle est cette règle.
Si, a contrario, vos projets s'inscrivent dans une telle démarche, alors il est possible qu'en fonction de la MOA, de son projet, du positionnement technique du BIM manager et de la convention BIM ainsi établie, une règle de nommage des familles vous soit imposée.
C. Comment définir les règles de nommage internes ?
Si aucune règle ne vous est imposée par un BIM manager ou assimilé, vous devez donc définir les
règles qui conviennent à votre entreprise.
Quitte à faire, ouvrez la question des règles de nommage à tout ce que votre entreprise doit créer et donc nommer, pas seulement le nom des familles de Revit.
Pour ce faire, vous pouvez vous poser plusieurs questions. Je dresse ici une liste, sans doute non exhaustive, que je vous invite à explorer, affiner, développer, bref à faire vôtre avec vos collègues, car intégrer des processus BIM en internes commence par améliorer la (vraie) collaboration entre individus, services et outils numériques, laquelle ne consiste pas à travailler chacun dans son coin à l'avancement d'un projet commun, mais bien à unifier ou mutualiser les outils et méthodes de production, de manière collégiale et "horizontale", pour reprendre un terme en vogue dans le tout autant terme en vogue "management".
Export des données Revit- Les données des objets Revit sont-elles exportées ?
- De quelle manière sont-elles exportées ?
- Pour qui ?
- Pour quoi ?
- Comment sont-elles exploitées par les autres services de l'entreprise ?
Relation entre les données Revit et les données externes- Ces données exportées doivent-elles s'inscrire dans une base de données interne déjà existante dans la société (ERP, etc.) ?
- Doivent-elles plutôt cohabiter avec cette base de données ?
- Comment se crée le lien entre données Revit et base de données existante hors Revit ?
- S'il n'existe pas encore de base de données externe à Revit, faut-il en créer une pour faire dialoguer différents logiciels de l'entreprise entre eux ?
- Quelles sont les restrictions de chacun d'eux, dans les formats qu'ils utilisent, dans les limitations des noms de propriétés, etc. ?
Compréhension des règles de nommage- Si je crée des codes complexes pour construire les noms (voir exemple dans la liste sur mes critères de nommage), sont-ils compréhensibles par tous les utilisateurs ?
- Sont-ils faciles/rapides à assimiler ?
- Sont-ils amener à évoluer dans le temps ? Si oui, la mise à jour/le changement est-il facile et rapide ? Quelles en sont les répercussions sur les projets en cours, la relation entre les bases de données et logiciels de l'entreprise etc. ?
- Y'a-t-il des codes qui ne servent à rien (doublon avec d'autres propriétés de l'objet, information peu ou pas importante, etc.) ?
- Ont-ils un impact sur l'ergonomie (les noms trop longs sont parfois en partie masqués dans les interfaces des logiciels ou nécessitent d'agrandir des fenêtres de manière démesurée, par exemple) ?
- Combien de temps les utilisateurs mettent en moyenne pour assimiler ce code ?
- Ce temps est-il acceptable ou retarde-t-il continuellement l'édition des plans ?
- Même si s'assimile bien, reste-t-il "agréable" à l'usage ou est-il continuellement source de frustration ou d'agacement par les utilisateurs ? Un individu peut avoir réellement du mal à comprendre, accepter ou utiliser une règle. Faut-il changer l'individu ou la règle, dans ce cas ?
- Qui, dans l'entreprise, va utiliser Revit ? Quel est leur niveau de maitrise/d'aisance avec l'interface du logiciel ? Quelle est leur habileté à savoir si l'objet recherché existe déjà (=savoir quel objet désigne précisément un type de famille pour éviter les duplications) ? Quelle est leur habileté à trouver rapidement l'objet qu'ils cherchent en fonction du nom de l'objet dans le sélecteur de type/dans l'arborescence de projet, indépendamment de toute règle de nommage ? Quelle habileté avec les codes que j'ai défini ?
D. Informations complémentaires sur la création d'un gabarit Revit
Je vais plutôt parler d'environnement Revit. Car un gabarit seul (au sens du fichier de gabarit de projet .rte) ne suffit pas.
Un environnement Revit se compose, au minimum, des éléments suivants :
- Les familles Revit
- Le fichier de gabarit de projet
- Le(s) fichier(s) de paramètres partagés
Mais pour être complet, vous pouvez devoir y joindre (liste non exhaustive) :
- Des tables de consultation pour la création de types de familles issues de catalogues fabricant
- Des feuilles de calcul ou des bases de données SQL ou Access pour automatiser le renseignement de certaines propriétés
- Des scripts Dynamo ou autres extensions de Revit pour diverses tâches
- Une bibliothèque de matériaux par défaut
- Un ensemble de gabarits de familles adaptés à vos besoins (il est impossible de créer ses propres gabarits de familles, il faut donc faire des familles préparamétrées mais sans géométrie spécifique à l'intérieur)
- des projets "showroom" pour tester les familles, présenter les familles et concepts aux futurs utilisateurs, servir de support de formation aux nouveaux arrivants, etc.
Vous trouverez en pièce jointe une capture d'écran de la structure d'un de mes environnements de travail (pour info, il concerne une seule discipline et a demandé 6 mois de travail, en partant d'une "feuille vierge"). C'est de cet environnement qu'est issu l'autre capture d'écran concernant les règles de nommage.
Et si je mentionne le temps passé, ce n'est pas en vain. environ 40% de ce temps cité fut la conséquence des allers-retours de conception et de modification du cahier des charges de la part du client qui a pensé son environnement Revit au fil de l'eau, malgré mes précisions sur l'ensemble des informations en amont nécessaires à la bonne exécution du travail.
Ce temps passé fut donc une perte financière pour ma société. Et dans votre cas, puisqu'il s'agit de créer un environnement de travail pour votre organisation, ce temps passé résulterait en du temps perdu (et par voie de conséquence, d'argent pour votre organisation).
Alors, parce que j'aime bien les analogies et que je m'évertue à faire comprendre à beaucoup de décideurs un peu trop court-termistes les conséquences d'un manque d'anticipation et de planification : Ce n'est pas une fois à 20m du sol, avec votre tronc d'arbre suspendu à une grue, que vous allez vous demandez quelle section de bois est nécessaire pour votre charpente ni comment vous allez débiter ce tronc.
En conclusion, avant d'ouvrir Revit, avant même d'allumer l'ordinateur, la conception commence par un papier, un stylo et plein de cerveaux (aller, je vous autorise la tablette pour prendre des notes

).
Maintenant, à vous de jouer ! Et au besoin, il semble que nous soyons dans la même zone géographique...