Étude de cas PMB : structurer un audit BIM à distance à partir de Revit et IFC

L’objectif : faire apparaître les problèmes qui coûtent du temps au projet

Quand j’aborde un audit BIM, je ne commence pas par chercher le nombre maximum d’erreurs. Je commence par les usages : production de plans, coordination, IFC, quantitatifs, DOE, exploitation, automatisation ou simplement fiabilité du modèle pour les équipes.

Une anomalie n’a d’intérêt que si elle affecte un usage ou révèle un défaut de méthode. Un paramètre vide sur 5 000 objets peut être critique s’il pilote une codification contractuelle. À l’inverse, un champ inutilisé peut être techniquement vide sans créer de risque réel.

1. Définir précisément les données d’entrée

Le premier travail consiste à comprendre ce qui est réellement disponible. Selon le projet, l’audit peut porter sur un ou plusieurs fichiers Revit, des exports IFC, un gabarit, des familles, des conventions de nommage, des nomenclatures, des extractions Excel ou encore la documentation BIM du projet.

Je distingue généralement trois niveaux : le modèle natif, le livrable d’échange et les règles du projet. Contrôler uniquement Revit ne permet pas de savoir ce que contient réellement l’IFC. Contrôler uniquement l’IFC ne permet pas toujours d’identifier la cause d’une mauvaise donnée côté auteur.

Cette distinction est fondamentale pour éviter le diagnostic « l’IFC est mauvais » alors que le problème vient en réalité d’un paramètre Revit mal renseigné, d’un mapping IFC incomplet ou d’une règle de projet ambiguë.

2. Extraire les données sans transformer l’audit en capture d’écran géante

Une partie importante de l’audit peut être industrialisée. Dans Revit, les données peuvent être extraites via des nomenclatures, Dynamo, l’API ou un plugin dédié. Pour l’IFC, on peut exploiter les classes, Property Sets, GUID, quantités, types et relations à l’aide d’outils de contrôle ou de bibliothèques spécialisées.

L’objectif est de constituer une table de travail structurée : un objet par ligne lorsque c’est pertinent, avec ses identifiants, catégories, types, paramètres critiques, informations de localisation et résultat des contrôles.

À ce stade, je préfère conserver une extraction aussi brute que possible. Si on transforme trop tôt les données, on perd la capacité à remonter à la source d’une anomalie.

3. Transformer les exigences en règles de contrôle

Le cœur de l’audit n’est pas l’outil d’extraction mais la définition des règles. Les contrôles peuvent être regroupés en familles : présence de données obligatoires, validité du format, cohérence entre paramètres, doublons, valeurs interdites, classification, géoréférencement, structure des types, nommage, qualité de l’export IFC ou encore cohérence entre plusieurs sources.

Une règle utile doit être suffisamment explicite pour produire le même résultat lorsqu’elle est exécutée deux fois sur les mêmes données. « Vérifier que les modèles sont bien renseignés » n’est pas une règle. « Pour tous les équipements de catégorie X, le paramètre CODE_ACTIF doit être non vide, unique et respecter l’expression définie par le projet » est déjà contrôlable.

4. Utiliser Power Query comme couche de transformation

Une extraction brute devient rapidement difficile à exploiter lorsqu’elle contient plusieurs dizaines ou centaines de milliers de cellules. Power Query est une bonne couche intermédiaire pour normaliser les colonnes, typer les données, joindre des tables de référence et produire des indicateurs reproductibles.

Je l’utilise notamment pour rapprocher une extraction modèle d’une table d’exigences, traduire certaines valeurs techniques, calculer des statuts de conformité ou préparer des vues synthétiques par discipline, zone, niveau, type d’objet ou règle.

Cette étape doit rester traçable. Une erreur classique consiste à construire tellement de transformations que personne ne sait plus d’où vient l’indicateur final. Chaque KPI doit pouvoir être relié à une donnée source et à une règle de contrôle.

5. Power BI sert à lire l’audit, pas à masquer les problèmes

Power BI est utile pour passer d’une liste brute d’erreurs à une lecture projet. On peut visualiser la complétude par discipline, les règles les plus souvent en échec, la répartition des anomalies par famille d’objets, ou encore l’évolution d’un contrôle entre deux versions.

Mais un beau tableau de bord peut être trompeur si les données sources sont mauvaises. Le dashboard n’est donc jamais la première étape. Il arrive après la définition des exigences, l’extraction et le contrôle.

Je privilégie des indicateurs simples : taux de conformité par règle, nombre d’objets concernés, criticité, tendance entre versions et concentration des erreurs. Le nombre total d’anomalies, pris seul, est rarement un bon indicateur.

6. Distinguer défaut ponctuel et défaut de système

Lors de la restitution, je sépare les erreurs à corriger dans le modèle des problèmes qui nécessitent une action plus structurelle. Si 400 portes utilisent une mauvaise valeur, on peut corriger les 400 portes. Mais si le paramètre n’est pas documenté, que les familles contiennent plusieurs variantes du même champ et qu’aucun contrôle n’existe avant publication, le vrai problème est le système de production.

C’est là que l’audit devient intéressant : il peut déboucher sur une évolution du gabarit, une règle de codification, une bibliothèque plus maîtrisée, un contrôle automatique avant livraison, une configuration IFC versionnée ou une clarification de la convention BIM.

7. Produire des recommandations actionnables

Une recommandation doit préciser ce qu’il faut changer, pourquoi, qui est concerné et idéalement comment vérifier que la correction fonctionne. « Améliorer la qualité des paramètres » est inutile. « Créer un paramètre partagé unique, supprimer les doublons historiques, documenter son usage dans le gabarit et contrôler sa complétude avant publication » peut être mis en œuvre.

Je classe généralement les recommandations selon trois horizons : correctifs immédiats sur les modèles, standardisation à court terme, puis automatisation ou évolution de processus.

Cette priorisation évite le piège classique d’un plan d’action de 80 lignes que personne ne traite après la restitution.

Exemple : un problème de classification IFC

Supposons qu’un ensemble de portes soit correctement visible dans le modèle IFC mais qu’une partie soit exportée dans une classe générique. Un contrôle IFC fait apparaître l’anomalie. L’audit remonte ensuite au modèle Revit pour identifier si le problème vient du mapping, d’un paramètre d’export ou d’une famille particulière.

La recommandation n’est donc pas seulement « corriger l’IFC ». Elle peut consister à harmoniser le paramètre de classification, vérifier le mapping d’export, tester un fichier témoin, puis intégrer ce test dans le contrôle avant livraison.

C’est ce passage du symptôme à la cause qui fait la différence entre un checker et un audit BIM.

Les limites d’un audit à distance

Un audit de fichiers ne permet pas d’observer directement la manière dont les équipes travaillent. Certaines mauvaises pratiques ne sont visibles qu’en entretien ou en accompagnement : contournements manuels, exports locaux non maîtrisés, dépendance à une personne, absence de responsabilité claire ou temps perdu dans des tâches répétitives.

À l’inverse, les données du modèle permettent souvent de révéler objectivement des problèmes que les équipes ne perçoivent plus parce qu’elles se sont habituées à les contourner.

Le meilleur dispositif combine donc analyse des données, compréhension des usages et échange avec les personnes qui produisent réellement les maquettes.

De l’audit ponctuel au contrôle continu

Une fois les règles stabilisées, une partie de l’audit peut devenir un contrôle récurrent. Les tests de complétude, codification, classification IFC ou cohérence de paramètres peuvent être automatisés et exécutés avant une publication.

C’est précisément la logique que je cherche à développer avec Pimp My BIM : côté Revit, rapprocher les contrôles de l’environnement de production ; côté IFC, pouvoir analyser le livrable indépendant du logiciel auteur. Le rôle du BIM Manager reste de définir les exigences, qualifier la criticité et décider des actions.

Conclusion

Le véritable livrable d’un audit BIM n’est pas un PDF rempli de captures d’écran. C’est une compréhension structurée de l’état du système de production : quelles données sont fiables, quelles règles échouent, pourquoi elles échouent et quelles actions auront le plus d’impact.

Une chaîne extraction → transformation → contrôle → visualisation fonctionne bien à condition de conserver la traçabilité entre le modèle, la règle et l’indicateur. C’est cette traçabilité qui permet ensuite de passer d’un audit ponctuel à un contrôle qualité réellement industrialisé.

Ressources associées