LA RECHERCHE / NOTRE LECTURE
buildingSMART précise que l’IDS décrit et vérifie les informations alphanumériques IFC, sans couvrir la géométrie. Cette distinction est essentielle lorsqu’un outil est présenté comme un contrôleur BIM.
Trois questions appellent trois types de contrôle
Chaque objet concerné possède-t-il un code matériau ? C’est une exigence d’information. La largeur libre entre deux faces mesurées respecte-t-elle le seuil convenu pour le projet ? C’est un test géométrique. L’accueil exprime-t-il l’identité souhaitée par le client ? C’est un jugement de conception. Tout regrouper sous « validation IA » masque les responsabilités. Décrivez pour chaque exigence l’entrée, la méthode et la preuve attendue.
- 01Exigence approuvée
- 02Règle exécutable
- 03Preuve issue du modèle
- 04Décision du réviseur
Chaîne de contrôle illustrative. Distinguez toujours « non testé » de « conforme ».
Un contrôle de porte commence par définir la mesure
Prenons une exigence de projet illustrative pour la porte D-02 : un passage libre d’au moins 900 mm. Il s’agit d’un seuil fourni par le projet, pas d’une exigence réglementaire affirmée ici. Une propriété nommée Width peut décrire le vantail, une ouverture ou un paramètre de famille ; son intitulé ne prouve pas la largeur de passage. La règle exige donc une définition de mesure convenue et deux faces de référence identifiées, dans un état défini de la porte. Si ces faces ne peuvent pas être extraites de façon fiable, le résultat est non testé. Sur le dessin de cette page, la valeur illustrative est de 870 mm, soit un écart de 30 mm. L’identifiant du modèle et de l’objet, la transformation de coordonnées, la conversion d’unités et la révision de la règle doivent accompagner le résultat. Sans eux, la mesure est difficile à reproduire ou à contester.
Commencez par un modèle et des règles explicites
Pour un pilote illustratif d’aménagement intérieur, choisissez une révision et quelques règles : noms d’objets requis, références de matériaux renseignées et dimension comparée aux exigences fournies. Dans SketchUp, Revit, Fusion ou un échange IFC, vérifiez d’abord ce que l’interface expose réellement. Une valeur manquante n’est pas zéro. Un objet non pris en charge ne doit pas être validé. Ces cas restent non résolus dans le rapport.
Séparer extraction, évaluation et explication
Un outil de contrôle maintenable sépare trois fonctions. L’adaptateur extrait la géométrie et les propriétés sans conclure à la conformité. Le moteur d’évaluation applique les règles approuvées à des données normalisées. La couche de rapport présente les preuves et peut utiliser l’IA pour les expliquer. Cette séparation permet de remplacer un adaptateur lorsque l’outil de conception change, sans modifier le sens de la règle. Dans un pilote Python, un enregistrement peut contenir model_revision, object_id, rule_id, measured_mm, required_mm et extraction_status. Le moteur classe d’abord les valeurs absentes, non finies ou non prises en charge comme non testées, puis compare les valeurs valides. Il ne doit pas arrondir discrètement une mesure insuffisante vers le haut. Toute tolérance figure dans la règle approuvée et le rapport. L’IA peut proposer du code ; la revue de la méthode de mesure et des tests reste un travail d’ingénierie distinct.
| Condition d’entrée | Mesuré / requis | Résultat attendu |
|---|---|---|
| Extraction valide | 920 / 900 mm | PASS |
| Extraction valide | 870 / 900 mm | FAIL |
| Face de référence absente | — / 900 mm | NOT TESTED |
| Unité non résolue | 0.87 / 900 | NOT TESTED |
900 mm est l’exigence du projet fictif, pas une affirmation réglementaire. La mesure dépend de la définition géométrique convenue.
Mesurez avec du code, expliquez avec l’IA
Une routine Python peut appliquer une condition définie et retourner l’identifiant de l’objet, la mesure, l’unité et la version de la règle. L’assistant peut proposer des contrôles à partir du brief ou expliquer une exception ; cette traduction en règles reste à valider. Séparez le résultat du commentaire. Si l’assistant écrit « acceptable » alors que la mesure échoue au test, le rapport doit conserver l’échec sans l’atténuer.
Tester les défauts qu’une démonstration réussie peut masquer
Le jeu de tests doit contenir une ouverture conforme, une ouverture volontairement trop étroite, un objet absent, un type de porte non pris en charge et une incohérence d’unités. Une occurrence symétrique ou transformée s’ajoute si l’adaptateur prétend la traiter. Un résultat qui varie lorsque la même géométrie est déplacée révèle un défaut de transformation. Une valeur de 0,87 interprétée en millimètres au lieu de mètres révèle un défaut d’unités. Un modèle vide qui renvoie zéro erreur sans indiquer une couverture nulle révèle un défaut de rapport. Ces anomalies demandent des résultats attendus distincts. Le résumé utile devient donc « 18 objets applicables sur 22 évalués ; 2 échecs ; 4 non testés », plutôt que « 2 problèmes ». La couverture, les exclusions et les extractions non résolues restent visibles, même dans une synthèse courte.
Faites du rapport un outil de revue
Distinguez éléments conformes, non conformes et non testés. Donnez accès à l’objet ou à la vue concernée, avec la révision et l’heure d’exécution. Testez un modèle volontairement erroné et des données manquantes. Réussir sur un exemple propre ne démontre pas une capacité de détection utile. Le pilote vise une détection fiable et explicable, avec un effort de revue raisonnable ; il n’approuve pas automatiquement le projet et ne prouve pas sa conformité réglementaire.
Relier le résultat au cycle de correction du concepteur
Le rapport est surtout utile lorsque chaque constat ouvre une vue reproductible ou sélectionne un objet identifiable dans l’outil de conception. Une capture d’écran seule devient périmée après une modification. La personne chargée de la revue doit retrouver la révision, la condition testée et la géométrie source. Une dérogation acceptée est consignée avec la règle, la révision, un motif et un responsable ; elle n’efface pas l’échec initial. Une modification du modèle relance ensuite les contrôles concernés. Pour une première intégration, une boucle fiable d’export et de revue peut suffire, sans plug-in en temps réel. Intégration native, échange IFC et traitement de fichiers ont des coûts de maintenance différents. Le choix dépend des modèles et des accès réels de l’agence, établis lors d’un pilote technique plutôt que déduits du nom du logiciel.