Un modèle qu'un humain lit sans peine peut être totalement invérifiable par une machine. Un contrôleur par règles comme Solibri n'interroge pas ce qu'on voit, il interroge une structure : des objets typés, des propriétés, des relations. Si cette structure manque, la règle ne trouve rien à contrôler, et rend un verdict qui ne veut rien dire. Préparer une maquette, c'est lui donner de quoi être jugée.
On prépare une maquette pour qu’elle soit belle et compréhensible à l’écran, et l’on suppose qu’elle sera, du coup, contrôlable automatiquement. C’est une erreur : un œil humain pardonne ce qu’une règle ne pardonne jamais.
Un contrôleur par règles ne regarde pas votre modèle, il l’interroge. Il demande : donne-moi tous les murs porteurs, vérifie que chacun porte une résistance au feu, mesure la distance entre ces portes et ces sorties. Ces questions ne portent pas sur l’apparence, elles portent sur une structure : des objets correctement typés, des propriétés renseignées au bon endroit, des relations spatiales exploitables. Un humain devine qu’une forme est un mur ; une règle ne le sait que si l’objet le déclare.
Préparer une maquette pour un outil comme Solibri, c’est donc s’assurer que cette structure est là. Cela suppose un export propre, celui des guides sur l’export depuis Revit ou Archicad, mais cela va plus loin : un export peut être techniquement parfait et rester inexploitable par une règle, faute de contenir ce que la règle interroge.
Ne préparez pas la maquette pour qu’elle s’affiche bien, préparez-la pour qu’elle réponde aux questions qu’on va lui poser. Ce sont deux exigences différentes, et la seconde est bien plus stricte. Tant qu’on pense affichage, on livre un modèle joli et muet ; dès qu’on pense interrogation, on livre un modèle qui peut être jugé.
Pour préparer un modèle, il faut savoir ce qu’un contrôle interroge réellement. Quatre choses, et l’absence de l’une suffit à rendre une règle aveugle.
La règle sélectionne par classe : « tous les murs ». Un objet non typé, tombé dans l’entité fourre-tout, n’existe pas pour elle. Le typage conditionne l’existence même de l’objet aux yeux du contrôle.
La règle vérifie une valeur : la résistance au feu, le caractère porteur. Si la propriété n’est pas là, au bon endroit, la règle ne peut ni la lire ni la juger.
La règle raisonne par étage, par local, par système. Un objet non rattaché à sa place dans la hiérarchie échappe aux contrôles qui s’appuient sur cette hiérarchie.
Les contrôles de distance, de dégagement ou de collision interrogent la forme. Une géométrie trop simplifiée ou mal exportée prive ces règles de la matière qu’elles analysent.
Ces quatre éléments sont ceux que le contrôle d’un IFC pas à pas vérifie à la main. Les préparer pour une machine, c’est la même exigence, portée un cran plus haut : ce qui est simplement souhaitable pour une lecture humaine devient indispensable pour un contrôle automatique. Une donnée que l’œil reconstitue, la règle ne la reconstitue pas : elle est là, ou la règle échoue.
Le pire résultat d’un contrôle n’est pas un rapport rouge plein d’erreurs. C’est un rapport vert obtenu sur un modèle sous-informé, car il donne une confiance que rien ne justifie.
Imaginez une règle qui vérifie la résistance au feu de tous les murs porteurs. Si, dans le modèle, les murs ne sont pas typés comme murs, ou ne portent pas la propriété « porteur », la règle ne trouve aucun mur porteur à contrôler. Elle ne signale donc aucune violation, et rend un verdict vert. Ce vert ne veut pas dire « tous les murs sont conformes », il veut dire « je n’ai trouvé aucun mur à vérifier ». La différence est immense, et elle est invisible pour qui lit seulement la couleur.
Un contrôle vert n’a de valeur que si l’on sait combien d’objets il a réellement examinés. Avant de se réjouir d’un rapport sans erreur, vérifiez qu’il a bien porté sur le bon nombre d’éléments : cent murs contrôlés et conformes rassurent, zéro mur contrôlé alarme, et pourtant les deux affichent la même couleur. Un contrôle n’est fiable que sur un modèle assez informé pour lui donner prise. Autrement, le vert est un faux vert, plus dangereux qu’un rouge honnête.
On ne prépare pas une maquette « pour le contrôle » en général, on la prépare pour des contrôles précis. La seule méthode fiable remonte des règles vers le modèle, et non l’inverse.
Commencez par connaître ce que le jeu de règles va interroger : quelles classes, quelles propriétés, quelles relations. C’est cette liste qui dicte la préparation, et elle vient des exigences du projet, l’EIR, souvent formalisées de façon exécutable par l’IDS. Une fois cette liste connue, la préparation devient une vérification point par point.
Les guides d’export garantissent un IFC bien formé : bon typage général, bonne origine, jeux de propriétés activés. C’est nécessaire, ce n’est pas suffisant pour un contrôle par règles, et deux écarts l’expliquent.
Le premier écart tient aux propriétés précises que les règles interrogent : un export peut produire tous les property sets standards et ne pas contenir la propriété exacte, souvent projet, sur laquelle porte le contrôle. Le second tient à la géométrie : le choix de la vue de modèle à l’export, développé dans versions d’IFC et MVD, décide du type de forme transmis. Une vue orientée vers la représentation statique convient à la coordination visuelle mais peut priver certains contrôles spatiaux de la géométrie qu’ils analysent. Et pour tout contrôle entre disciplines, collision ou dégagement, les maquettes doivent partager une même origine, sans quoi le contrôleur compare des objets qui ne se superposent pas.
Avant d’exporter vers un contrôle par règles, posez-vous : mon export contient-il ce que ces règles précises vont lire, et une géométrie qu’elles peuvent analyser ? Un export réglé pour « livrer proprement » et un export réglé pour « être vérifié » ne sont pas forcément le même. Connaître le contrôle visé avant d’exporter évite de découvrir, une fois le rapport rendu, que le modèle ne pouvait pas être jugé.
Préparer une maquette pour un contrôle par règles, c’est passer de l’affichage à l’interrogation, une exigence bien plus stricte.
Trois idées à emporter. Une règle interroge une structure, pas une image : un objet non typé, une propriété absente, une place spatiale manquante rendent l’objet invisible au contrôle, quelle que soit sa beauté à l’écran. Le faux vert est le vrai danger : un rapport sans erreur sur un modèle sous-informé signifie souvent « rien n’a été contrôlé », pas « tout est conforme », et il faut toujours vérifier combien d’objets ont réellement été examinés. Enfin, on prépare en partant des règles : connaître ce que le contrôle va lire, propriétés et géométrie comprises, avant d’exporter, car un export propre ne garantit pas un export vérifiable.
L’outil qui exécute ces contrôles est Solibri, et la version ouverte des exigences qu’il vérifie est l’IDS. L’export dont ce flux dépend est traité dans exporter depuis Revit et depuis Archicad, et le contrôle manuel qui reste utile en complément dans contrôler un IFC pas à pas. Le cadre qui décide quoi contrôler reste auditer une maquette.
Les guides qui prolongent naturellement celui-ci, dans d'autres sections du site.
On le range parmi les visionneuses, et c'est le rater complètement. Solibri ne sert pas à regarder une maquette : il sert à la confronter à un règlement et à dire, objet par objet, ce qui passe et ce qui ne passe pas. Comprendre l'outil, c'est comprendre ce qu'est une règle, et pourquoi certaines ne s'écrivent qu'ici.
Un export IFC n'est pas un enregistrement, c'est une traduction. Tant que vous ne décidez pas comment Revit traduit, il décide à votre place. Voici les trois réglages qui font 90 % du résultat, et la logique derrière, valable quelle que soit votre version.
Avant l'outil de contrôle par règles, avant l'IDS, avant même l'audit contractuel, il y a un geste que n'importe qui peut faire avec une visionneuse gratuite : ouvrir le fichier reçu et l'inspecter méthodiquement. En une à deux heures, sans licence ni règles écrites, on répond à la seule question qui compte d'abord : ce fichier est-il seulement exploitable ?