L'interface visuelle supprime la syntaxe, pas le raisonnement. Ce qui arrête les débutants n'est jamais l'interface : c'est la gestion des listes. Et ce qui coûte cher ensuite n'est pas d'écrire le script, c'est de le maintenir vivant quand Revit change de version.
C’est une nuance, et elle décide de la réussite. Relier des boîtes par des fils supprime la syntaxe, la ponctuation et les fautes de frappe. Cela ne supprime ni les variables, ni les conditions, ni les structures de données.
L’argument commercial est honnête sur un point : la barrière d’entrée est réellement plus basse. On produit quelque chose qui fonctionne en une heure, ce qui est impossible avec un langage classique. Beaucoup de professionnels franchissent ce pas et n’auraient jamais ouvert un éditeur de code.
Puis vient le mur, et il est toujours au même endroit. Ce n’est ni l’interface, ni le vocabulaire : ce sont les listes. Comment une opération s’applique quand on lui donne dix éléments d’un côté et un seul de l’autre, comment on traite une liste de listes, à quel niveau de profondeur agir. Ces notions ont des noms dans l’outil, et ce sont les premières à apprendre, avant tout le reste.
Si votre script renvoie un résultat mais pas le bon nombre de résultats, vous avez un problème de listes, pas de logique. C’est le diagnostic le plus fréquent, et l’essentiel du temps passé dans l’outil est du dépannage, pas de la construction. Sachez-le avant de commencer : ce n’est pas vous, c’est la nature de l’exercice.
Les démonstrations montrent des façades paramétriques qui ondulent. Les usages qui font gagner du temps sont infiniment plus ternes, et c’est une bonne nouvelle.
Un conseil revient chez ceux qui enseignent l’outil, et il est contre-intuitif : commencez par les données, nombres, textes, éléments, et ignorez l’aperçu géométrique. La géométrie est ce qui attire, et c’est aussi ce qui rend les premiers scripts fragiles et lents.
Prenons comme exemple une tâche ingrate et payante : écrire sur chaque équipement le code de la zone dans laquelle il se trouve. Personne ne le fait à la main sur huit cents objets. Sans ce code, pourtant, il n’y a ni rattachement d’un planning à des objets, ni rapprochement d’un quantitatif avec une bibliothèque de prix, ni tableau de bord possible. C’est exactement la clé de jointure dont dépendent le phasage, le chiffrage et le pilotage.
Dans quel paramètre écrivez-vous ce code ? Un paramètre de projet ordinaire fera l’affaire à l’écran et se perdra à l’export. Un paramètre partagé, doté d’un identifiant stable, peut être visé dans un mappage vers un jeu de propriétés IFC, donc atteindre les autres intervenants. Le script est identique dans les deux cas ; ce qu’il produit ne l’est pas du tout.
Fabriquer et entretenir les identifiants partagés qui rendent la maquette interrogeable. C’est laid à regarder, ça ne fait pas une bonne vidéo, et c’est ce qui débloque le BIM 4D, le BIM 5D et les tableaux de bord d’un seul coup.
Un développeur travaille avec un historique de versions, des tests, une revue par un pair et de la documentation. Un script d’agence n’a généralement rien de tout cela, et il porte pourtant les mêmes risques.
Aucun script ne circule sans une phrase qui dit ce qu’il fait, ce qu’il attend en entrée et ce qu’il modifie. Écrite dans le fichier lui-même, pas dans un courriel. C’est cinq minutes, et c’est ce qui sépare un outil d’entreprise d’une bricole personnelle que personne n’osera reprendre.
L’automatisation a un charme propre : elle est plus intéressante que la tâche qu’elle remplace. C’est précisément pourquoi il faut poser la question froidement.
Le calcul habituel compare le temps d’écriture au temps gagné. Il est faux, parce qu’il oublie le coût de possession : maintenir le script à chaque version, le réparer quand une extension disparaît, et le réexpliquer à chaque nouvel arrivant. Un script utilisé deux fois par an ne rembourse presque jamais ce coût.
Une tâche répétée à chaque projet justifie l’effort. Une tâche unique, presque jamais : la faire à la main coûte moins cher que la décision de l’automatiser.
Un script lié à une convention de projet meurt avec le projet. Un script lié à vos standards internes vit des années, et mérite d’être soigné.
Si la réponse est « personne d’autre que moi », vous ne créez pas un actif, vous créez une dépendance.
Quand le script sert à rattraper une règle de modélisation absente. Corriger automatiquement des catégories mal choisies ou des paramètres vides traite le symptôme et pérennise la cause : l’équipe continue de produire mal, puisque le script répare. La bonne réponse est dans modéliser proprement, et elle coûte moins cher à long terme.
La progression qui fonctionne est l’inverse de celle que suggèrent les démonstrations.
La logique interne du logiciel que vous automatisez. Un script manipule des catégories, des types et des occurrences : si ces notions sont floues, l’automatisation amplifiera la confusion au lieu de la résoudre. Le préalable est Revit, comprendre sa logique.
Un excellent outil, dont les échecs sont presque toujours des erreurs de décision plutôt que de technique.
Trois idées à emporter. « Sans coder » supprime la syntaxe, pas le raisonnement : le mur est toujours à l’endroit des listes, et l’essentiel du temps passé dans l’outil est du dépannage. Son meilleur usage est le moins spectaculaire : fabriquer et entretenir les identifiants partagés qui rendent une maquette interrogeable, ce dont dépendent le phasage, le chiffrage et les tableaux de bord. Enfin, un script est du code sans la discipline du code : auteur unique, extensions bénévoles, interface logicielle qui change chaque année. Le vrai coût n’est pas de l’écrire, c’est de le garder vivant.
Le préalable est Revit, comprendre sa logique : on n’automatise bien que ce qu’on comprend. Ce que les identifiants produits permettent ensuite est décrit dans Power BI et le BIM. Et pour la question de fond, celle de savoir s’il faut automatiser ou mieux modéliser, modéliser proprement.
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.
Power BI ne lit pas une maquette. Il joint des tables. Pour relier un objet de la maquette à un coût, à une tâche de planning ou à un relevé de chantier, il faut une colonne commune présente des deux côtés. Cette clé n'existe presque jamais, et c'est là que 90 % des projets s'arrêtent.
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.