Créer des scripts Dynamo internationaux : Maîtriser les BuiltInParameters

Article complémentaire de « Créer des scripts Dynamo internationaux : Maîtriser les BuiltInCategories ».

Dans le précédent article, nous avons vu comment rendre la sélection par catégorie indépendante de la langue de Revit grâce aux BuiltInCategories. Mais une fois les éléments sélectionnés, la deuxième étape de presque tous les scripts Dynamo consiste à lire ou écrire un paramètre. Et c'est exactement le même piège qui nous attend.

Le problème : le nom du paramètre dépend de la langue

Voici la configuration classique de nœuds utilisée pour lire un paramètre :

Le nœud « Element.GetParameterValueByName » (et son équivalent en écriture « Element.SetParameterByName ») attend le nom affiché du paramètre. Or ce nom est traduit par Revit : « Hauteur » sur un poste français devient « Height » sur un poste anglais, « Höhe » sur un poste allemand. Le même script échoue donc dès qu'il change de langue — et parfois même de version, car Autodesk fait évoluer certaines traductions au fil des années.

Il existe pourtant, comme pour les catégories, un nom interne invariable : le BuiltInParameter (BIP). Le paramètre « Hauteur » d'une porte s'appelle en interne DOOR_HEIGHT, l'« Identifiant » s'appelle ALL_MODEL_MARK, le « Coût » ALL_MODEL_COST. Ces noms sont identiques sur toutes les installations de Revit, quelle que soit la langue, et restent stables de version en version.

La solution : passer par le nom interne

L'astuce consiste à stocker dans le script le nom interne du BIP, puis à le convertir à l'exécution vers le nom localisé du Revit en cours. C'est l'API Revit elle-même qui fait la traduction, via LabelUtils.GetLabelFor() :

Le nœud Python tient en quelques lignes (moteur CPython3/PythonNet3) :

import clr
import System

clr.AddReference("RevitAPI")
from Autodesk.Revit.DB import BuiltInParameter, LabelUtils

from System import Enum


def get_label(bip_name):
    if bip_name is None:
        return ""
    name = str(bip_name).strip()
    if not name:
        return ""
    try:
        bip = Enum.Parse(clr.GetClrType(BuiltInParameter), name)
    except Exception:
        return ""
    try:
        return LabelUtils.GetLabelFor(bip)
    except Exception:
        return ""


if isinstance(IN[0], list):
    OUT = [get_label(n) for n in IN[0]]
else:
    OUT = get_label(IN[0])

En entrée IN[0], un nom de BIP (ou une liste de noms) ; en sortie, le nom du paramètre dans la langue du Revit exécuté. Le même graphe affiche « Identifiant » sur un poste français et « Mark » sur un poste anglais, sans modifier une seule ligne. Votre script devient réellement international.

L'avantage est double, exactement comme pour les BuiltInCategories : la valeur d'entrée est invariable quelle que soit la langue, et si dans une future version le nom français du paramètre change, le script restera valable.

La liste complète, vérifiée dans Revit

Ci-joint, vous trouverez la liste des BuiltInParameters avec leur ID interne et leur nom Revit français, couvrant les versions 2024 à 2027 (paramètres stables, nouveautés et suppressions par version, alias) :

Télécharger ici : Revit_BuiltInParameter_FR_with_ids

Un mot sur la fiabilité de ce fichier, un point important : chaque nom, chaque ID et chaque libellé français a été vérifié directement contre l'API de Revit 2027, via un script Dynamo qui parcourt l'énumération BuiltInParameter complète et interroge LabelUtils sur un poste en français. Aucune valeur ne provient d'une simple compilation documentaire. Les seuls paramètres sans libellé sont ceux pour lesquels Autodesk n'a jamais défini de chaîne d'interface (paramètres purement internes), et quelques nouveautés 2027 ont un libellé encore en anglais dans le pack de langue français — c'est Autodesk qui ne les a pas encore traduits.

Pour aller plus loin : nom ou ID, qui est le véritable identifiant ?

En construisant ce fichier, nous avons mis en évidence une subtilité qui mérite d'être connue : contrairement à ce qu'on pourrait croire, l'ID numérique d'un BuiltInParameter n'est pas unique. Plusieurs noms internes peuvent partager la même valeur : DOOR_HEIGHT, WINDOW_HEIGHT, CASEWORK_HEIGHT, FURNITURE_HEIGHT et FAMILY_HEIGHT_PARAM pointent tous vers l'ID -1001300. Ce sont des alias historiques de l'énumération : pour Revit, c'est le même paramètre « Hauteur », exposé sous plusieurs noms au fil des versions. À l'inverse, le nom interne, lui, est unique par construction — un DOOR_COST ne peut désigner qu'une seule chose.
Pour résumer: un paramètre intégré peut être soit appelé par son nom interne (BIP) ou la combinaison (Catégorie + ID interne).

C'est exactement l'inverse des paramètres partagés : là, deux paramètres peuvent porter le même nom d'affichage (deux « Coût » issus de deux fichiers .txt différents), et c'est le GUID qui garantit l'unicité. Quant aux paramètres de projet non partagés, ils n'ont ni nom interne ni GUID — seulement un ElementId local au fichier, sans aucune portabilité qui varie donc d'un projet à un autre.

On peut résumer les trois familles ainsi :

La leçon transversale est la même que pour les catégories : dans Revit, le nom affiché n'a jamais eu vocation à être un identifiant. Pour écrire des scripts Dynamo robustes et internationaux, appuyez-vous sur le nom interne pour les BuiltInParameters, sur le GUID pour les paramètres partagés — et réservez le nom localisé au seul cas où rien d'autre n'existe.

Une anecdote qui a son importance : quand Autodesk corrige ses fautes d'orthographe

Petite surprise découverte lors de la vérification du fichier : les noms internes eux-mêmes contiennent parfois des fautes de frappe... et Autodesk les corrige de temps en temps. Ainsi, BENDING_DETAIL_REPESENTATION_FOR_3D_BARS (il manque un « R » à representation) et BENDING_DETAIL_SEGMENET_REPESENTATION (segment mal orthographié) ont disparu de l'énumération dans Revit 2027 au profit de leurs versions corrigées BENDING_DETAIL_REPRESENTATION_FOR_3D_BARS et BENDING_DETAIL_SEGMENT_REPRESENTATION. Même chose pour TOPOSOLID_SUBDIVIDE_HEIGNT, remplacé par TOPOSOLID_SUBDIVIDE_HEIGHT. Dans chaque cas, l'ID numérique sous-jacent reste le même : seul le nom du symbole change.

Conséquence pratique : un script qui utilisait l'ancien nom fautif fonctionnait en 2026 mais casse en 2027. « Stable de version en version » signifie donc « très stable, sauf correction exceptionnelle » — d'où l'intérêt de la colonne de suivi par version dans le fichier Excel, et de la valeur sentinelle <BIP inconnu> renvoyée par notre nœud Python, qui permet de détecter immédiatement ce cas au lieu d'échouer silencieusement.

Amusant : toutes les coquilles ne sont pas corrigées. MEP_HORIZONTAIL_OFFSET (pour horizontal) et STRUCTURAL_SECTION_COMPUTE_AUTOMATICALY_ANALYSIS_PROPERTIES (pour automatically) sont toujours présents tels quels en 2027 — probablement parce que trop de code en dépend. Et les traductions n'échappent pas à la règle : le libellé français de TOPOSURFACE_POINT_BASETYPE_ENUM affiche encore « surface topogaphique », sans son « r ». Preuve supplémentaire, s'il en fallait, qu'aucune chaîne de caractères n'est parfaitement fiable dans Revit — mais le nom interne reste, et de très loin, le plus sûr des identifiants disponibles.

Cette proposition a été soumise officiellement à l'équipe Dynamo : si vous souhaitez la soutenir, ajoutez un 👍 sur [l'issue GitHub], et la discussion communautaire se poursuit sur [le forum Dynamo].

Si vous remarquez des erreurs dans le fichier Excel, nous vous remercions de votre retour.

Utilisez-vous déjà les BuiltInParameters dans vos scripts ? Partagez votre expérience en commentaire !

A bientôt sur votre blog Aplicit