Quand une équipe BIM commence à automatiser Revit, le réflexe est souvent de chercher directement un script Dynamo ou d’écrire du code. Pourtant, une partie des besoins peut être résolue plus simplement avec un plugin existant. À l’inverse, certaines tâches dépassent rapidement ce qu’un outil générique peut faire et justifient un développement spécifique.
Je raisonne donc en niveaux. D’abord les fonctions natives de Revit. Ensuite les plugins prêts à l’emploi. Puis Dynamo. Puis Python. Enfin l’API Revit avec un add-in dédié lorsque le processus devient suffisamment critique, complexe ou récurrent.
1. Avant l’outil : vérifier que le processus mérite d’être automatisé
Une mauvaise procédure automatisée reste une mauvaise procédure, simplement exécutée plus vite. Avant de développer quoi que ce soit, je cherche donc à décrire le processus manuellement : quelles données en entrée, quelles règles, quelles exceptions, quel résultat et quel contrôle final ?
Si deux BIM coordinateurs ne sont pas d’accord sur la règle à appliquer, le problème n’est pas encore technique. Il faut d’abord standardiser la méthode.
C’est particulièrement vrai pour les paramètres. Un script qui remplit automatiquement une donnée dont la définition varie selon les projets crée une dette technique et informationnelle.
2. Plugins prêts à l’emploi : commencer par ne pas réinventer
Pour beaucoup de tâches courantes, des plugins matures existent déjà. La suite DiRootsOne est aujourd’hui proposée en modèle freemium et regroupe plusieurs outils de productivité Revit.
SheetLink permet par exemple d’exporter des données du modèle vers Excel ou Google Sheets, puis de les réimporter pour mettre à jour Revit. ParaManager travaille sur la gestion des paramètres. FamilyReviser aide à gérer familles et worksets. D’autres outils couvrent les filtres, feuilles, vues ou renumérotations.
Ces outils sont particulièrement efficaces lorsque le besoin est générique : éditer en masse des paramètres, créer des feuilles, nettoyer des familles ou produire des exports. Le coût de développement est nul ou faible et l’utilisateur dispose d’une interface.
La limite apparaît lorsque la logique métier devient très spécifique : règles propres au projet, contrôles croisés entre plusieurs paramètres, workflows de validation ou intégration avec des systèmes externes.
3. Dynamo : excellent pour transformer un workflow en logique visuelle
Dynamo est installé avec Revit et Autodesk le décrit comme une interface de programmation graphique permettant de personnaliser les workflows d’information du bâtiment. C’est souvent le meilleur point d’entrée pour une équipe BIM qui veut automatiser sans construire immédiatement un add-in complet.
Dynamo est adapté aux séquences structurées : sélectionner des éléments, lire des paramètres, filtrer, calculer, créer des vues, renseigner des valeurs, exporter des résultats. Le graphe rend la logique visible, ce qui facilite sa compréhension par des personnes qui ne sont pas développeurs.
Mais un graphe peut devenir illisible lorsqu’il contient des centaines de nœuds, de nombreux packages externes et des branchements complexes. À ce stade, la programmation visuelle ne réduit plus vraiment la complexité : elle la dessine.
4. Dynamo Player : séparer l’auteur du script de l’utilisateur
Un bon workflow Dynamo n’oblige pas forcément chaque collaborateur à ouvrir le graphe. Dynamo Player permet de distribuer des scripts à des utilisateurs qui exécutent une tâche préparée.
C’est une étape importante pour industrialiser une automatisation interne. L’auteur contrôle le graphe et les dépendances ; l’utilisateur fournit les entrées nécessaires et récupère le résultat.
Je recommande cependant d’ajouter des messages de contrôle, des validations d’entrée et un rapport final. Un bouton qui « fait quelque chose » sans expliquer les éléments traités est difficile à auditer.
5. Python : quand la logique devient plus facile à écrire qu’à dessiner
Python devient intéressant dès que le workflow contient beaucoup de logique, de boucles, de dictionnaires, de transformations de chaînes ou de traitements de données. Il peut être utilisé dans l’écosystème Dynamo pour concentrer une partie du traitement dans des nœuds de script.
Revit 2026 a continué à faire évoluer Dynamo et ses moteurs Python. Autodesk documente notamment le package PythonNet3, qui améliore la compatibilité .NET et peut être sélectionné comme moteur pour les nœuds Python. Comme toujours, une montée de version peut casser certains scripts : il faut tester.
Python est aussi particulièrement efficace hors de Revit pour traiter des exports IFC, CSV ou Excel. Beaucoup de contrôles n’ont pas besoin d’ouvrir Revit à chaque exécution.
6. API Revit : quand le workflow devient un produit
L’API Revit est la couche la plus puissante pour développer une fonctionnalité intégrée. Autodesk indique que l’API peut être utilisée pour automatiser des tâches répétitives, vérifier des standards, extraire des données, importer des informations externes, intégrer d’autres applications ou générer automatiquement de la documentation.
Dans Revit 2026, le développement API s’appuie sur .NET 8.0. Un add-in peut implémenter des commandes externes et créer sa propre interface dans Revit.
Cette approche est pertinente lorsque l’outil doit être utilisé par de nombreuses personnes, gérer des cas complexes, proposer une interface robuste, journaliser les actions ou être distribué à l’extérieur de l’entreprise.
C’est évidemment la logique suivie pour le plugin Pimp My BIM : une automatisation devenue produit ne peut plus dépendre d’un graphe local posé sur le bureau d’un BIM Manager.
7. Comment choisir la bonne couche ?
| Besoin | Outil souvent adapté | Pourquoi |
|---|---|---|
| Modifier des paramètres en masse | Plugin / DiRoots | Interface prête et usage standard |
| Créer un workflow projet visuel | Dynamo | Rapide à prototyper et compréhensible |
| Traitement complexe de données | Python | Logique compacte et bibliothèques |
| Outil distribué et maintenu | API Revit / C# | Interface, contrôle, déploiement, performances |
| Contrôle IFC hors Revit | Python / plateforme dédiée | Pas besoin d’ouvrir le logiciel d’authoring |
8. Cas concret : contrôler une codification d’équipements
Imaginons 8 000 équipements MEP qui doivent porter un code structuré selon discipline, système, niveau et numéro séquentiel.
Un plugin générique peut remplir une colonne en masse, mais il ne connaît pas nécessairement la règle. Dynamo peut construire le code à partir des paramètres existants et identifier les éléments incomplets. Python peut simplifier le traitement de chaînes et la détection de doublons. Un add-in dédié peut enfin proposer une interface de contrôle, bloquer les cas incohérents, journaliser les modifications et produire un rapport.
Il n’y a donc pas un outil « meilleur ». Le niveau d’investissement doit suivre la criticité et la fréquence.
9. Excel reste utile, mais il doit rester une interface contrôlée
Les workflows Excel sont extrêmement efficaces dans le BIM parce qu’ils rendent les données accessibles à des personnes qui n’utilisent pas Revit. SheetLink ou des exports personnalisés permettent de faire le pont.
Mais il faut protéger le retour vers le modèle. Une colonne mal triée, un identifiant supprimé ou une unité modifiée peut produire des erreurs massives. Le fichier doit conserver une clé stable et les valeurs réimportées doivent être validées.
10. Le risque caché des packages Dynamo
Les packages accélèrent énormément la création de graphes. Ils introduisent aussi des dépendances. Lors d’un changement de version Revit/Dynamo, un package peut ne plus être compatible ou modifier son comportement.
Pour les scripts critiques, je documente donc la version de Revit, la version de Dynamo, les packages et leurs versions. Les mises à jour sont testées sur une copie avant diffusion.
Ce sujet est particulièrement actuel : Autodesk publie des versions de Dynamo différentes selon les mises à jour Revit 2026, et les notes de version signalent aussi des nœuds supprimés ou dépréciés. Une automatisation n’est jamais « terminée pour toujours ».
11. Modifier un modèle exige une stratégie de sécurité
Une automatisation qui lit des données est relativement peu risquée. Une automatisation qui modifie des milliers d’objets doit être conçue autrement.
Je privilégie un mode aperçu : le système indique ce qu’il va changer, combien d’objets sont concernés et quelles anomalies empêchent l’exécution. Ensuite seulement, l’utilisateur confirme.
Pour un outil API, les transactions Revit offrent un cadre de modification du modèle. Les erreurs doivent être gérées et les modifications doivent pouvoir être annulées lorsque l’exécution échoue.
12. Automatiser le contrôle, pas uniquement la production
Les premiers scripts d’une équipe servent souvent à créer plus vite. Pourtant, l’automatisation du contrôle apporte parfois plus de valeur : détecter les paramètres vides, doublons, familles non conformes, niveaux incorrects, coordonnées douteuses ou mappings IFC incohérents.
Un script de création fait gagner quelques minutes. Un contrôle automatique peut empêcher une erreur de se propager pendant plusieurs semaines.
C’est l’une des orientations principales de Pimp My BIM : combiner productivité et qualité plutôt que multiplier les boutons d’action.
13. La maintenance fait partie du coût réel
Un script créé en deux heures peut coûter beaucoup plus cher s’il faut le réparer à chaque mise à jour, expliquer son fonctionnement à tous les utilisateurs et gérer cinq versions différentes dans l’entreprise.
Pour chaque automatisation récurrente, je recommande donc un minimum de gouvernance : propriétaire, version, environnement supporté, dépendances, documentation courte et jeu de test.
14. Ma progression recommandée
Commencer par identifier les tâches répétitives et les contrôles manuels. Chercher ensuite si Revit ou un plugin existant répond déjà au besoin. Si la logique est spécifique, prototyper dans Dynamo. Introduire Python lorsque le graphe devient trop complexe. Enfin, transformer le workflow en add-in lorsque son usage et sa valeur sont suffisamment établis.
Cette progression évite de consacrer plusieurs semaines de développement à un problème qui aurait pu être résolu avec un outil existant, tout en donnant une voie claire vers l’industrialisation.
Conclusion
DiRoots, Dynamo, Python et l’API Revit ne sont pas concurrents. Ils correspondent à des niveaux différents d’un même continuum d’automatisation.
La compétence la plus utile n’est donc pas de maîtriser un seul outil. C’est de savoir reconnaître la complexité du problème, choisir la couche adaptée et construire un processus qui restera compréhensible lorsque son auteur ne sera plus devant l’écran.
Quand les scripts internes deviennent des outils métier.
Le plugin PMB transforme des workflows de contrôle, gestion de données et productivité Revit en fonctions distribuables et maintenables directement dans le logiciel.