# Interopérabilité et automatisme dans les études du Bâtiment

## Interoperability and automation in building studies

Roland Billon*<fnref n="1" />, Isabelle Fasse<fnref n="2" /> et Thierry Parinaud**<fnref n="3" />

**Résumé.** Les professionnels constatent des difficultés dans l'exploitation de la norme ISO dite « IFC » d'échange de données du Bâtiment, ainsi que dans la maquette numérique des projets (BIM) telle qu'elle existe aujourd'hui. Deux disciplines qui selon les auteurs sont devenues inséparables dans la conception des ouvrages. Ajouter de l'information numérique dans cette maquette ne résout pas l'essentiel attendu : son partage et sa synthèse<fnref n="2" /> entre les métiers. Pour relever le défi d'une véritable interoperabilité dans les échanges de données entre métiers, qui supposent des procédures automatisées, les auteurs imaginent un outil logiciel.

**Mots-clés.** Acquisition 3D, Automatismes, BIM, Interopérabilité, Paramétrisation, Règles métier, Formalisation des connaissances.

**Abstract.** Professionals note difficulties in using the IFC ISO standard for building data exchange, as well as the digital model of projects (BIM). Two disciplines that the authors say have become inseparable in the design of building works. Adding information to a computer model doesn't resolve the critical role expected: its sharing and synthesis between trades. To meet the challenge of true interoperability in cross-trades data exchange, involving automated procedures, the authors imagine a software tool.

**Keywords.** 3D data capture, Automatism, BIM, Interoperability, Parametrization, Trade Rules, Formalization of knowledge.

<footnote n="1">¹Enseignant chercheur ENSA Marseille jusqu'en 2006, Laboratoire KEOPS 1985-1995, France</footnote>

<footnote n="2">²Maître de conférence, ENSA Marseille, Laboratoire MAP-GAMSAU UMR CNRS MC 3495, France</footnote>

<footnote n="3">³Architecte DPLG, AMO BIM du PUCA, Membre d'ADN¹ Construction et du GT BIM de l'UNSFA</footnote>

<footnote>* VP de Médiaconstruct jusqu'en 2017, Initiateur de son Collège des Ets Enseignement et Recherche. Courriel : rolandbillon@yahoo.fr</footnote>

<footnote>** VP de Médiaconstruct jusqu'en 2017 - Courriel : studio4@wanadoo.fr</footnote>

<footnote n="1">¹ Association pour le Développement du Numérique dans la Construction</footnote>

<footnote n="2">² Voir Terrin Jean-Jacques, Marie Jean-Baptiste, « Maquette BIM et projet collaboratif ».</footnote>
# 1. L'interopérabilité est-elle abandonnée ?

« Produire l'image du futur, puis les documents techniques du réel » pourrait résumer l'objectif de la conception. Les professionnels utilisent depuis 40 ans des logiciels de DAO, de CAO et des logiciels « métiers » toujours avec les mêmes méthodes immuables : saisir un aspect des objets du projet selon sa spécialité. Le logiciel calcule et met en page. Il produit les documents supposés satisfaire les métiers successifs des études, de la construction, de l'exploitation, et de la maintenance.

C'est long et sujet à erreurs, car le détail compte. Décrire le « perçu », rendre compte d'un « compris par tous » élargit l'acte de conception à la normalisation. L'informatique ne pourrait-elle mieux soulager les acteurs métier ?

La conception et la normalisation des objets dans le Bâtiment ont cet objectif commun : Echanger pour Décrire. Il faut cependant « changer de méthode».

Des tentatives méthodologiques ont commencé dans les années 70, avec la « Méthode systématique » promue par Paul Quintrand<fnref n="3" />. Manuelle, elle était impraticable. Il a fallu attendre 20 ans pour que ce souhait de remettre à plat l'organisation de l'information du projet soit envisageable avec des outils numériques.

Les majors du Bâtiment, en France, avec l'appui du Ministère de l'Equipement de l'époque, et quelques chercheurs du CSTB et du laboratoire KEOPS<fnref n="4" />, ont imaginé les premiers un standard d'échange de données basé tout d'abord sur le format d'échange DXF d'Autodesk : Le SUC-DXF<fnref n="5" />, Système Unitaire de Communication.

Bien vite, les chercheurs en question ont réalisé qu'un standard d'échange national, dicté pour raisons économiques, de qualité, de conformité, de concurrence, n'était pas suffisant et ne devait en aucun cas dépendre d'un éditeur privé. Avant d'échanger, il fallait normaliser, et à l'international. L'idée, qui date de 1992, est française, et déjà il était envisagé de la valider en utilisant le canal STEP<fnref n="6" /> et un format ISO.

## 1.1 L'aventure de l'IAI et de la norme IFC.

L'aventure (en termes de recherche) a débuté en 1995. L'association IAI (International Alliance for Interoperability) et en France l'association Médiaconstruct ont accompagné les avancées espérées. Nous les résumons par les deux objectifs :

* « Les documents papier, ou même numériques, élaborés de façon individuelle, laissent la place à une forme d'échanges interopérables, en circuit. »

* « Les données du projet produites par un acteur informatisé sont interprétées d'une façon automatique par les logiciels des métiers destinataires. Interopérabilité, formalisation des connaissances, automatismes, trois critères qui définissent véritablement le concept d'aide à la conception, en même temps que la normalisation des données. »

La responsabilité d'un acteur restait entière, bien que participant à des décisions devenues « collectives ». Il conservait la supervision de sa participation aux échanges, avec plusieurs avantages :

* La vitesse de réaction, due à l'automaticité,

* La garantie de conformité aux règles techniques, due à la formalisation des connaissances de son métier, ajoutées à son expertise propre.

<footnote n="3">³ Méthode systématique d'analyse et de programmation pour la conception architecturale et description des ouvrages. Rapport du groupe d'étude CERA Nantes, CIAB Marseille, CSTB, OTH, UPA Provence, Syndicats Ingénieurs-Conseils, Métreurs-Vérificateurs, Déc.1968.</footnote>

<footnote n="4">⁴ Laboratoire privé de recherche développement, logiciels CAO en architecture et ingénierie.</footnote>

<footnote n="5">⁵ Décision N°0494-19 du 4 Nov. 1994, PUCA, réunissant le CSTB, KEOPS Inf., STAR Inf.</footnote>

<footnote n="6">⁶ STEP: Standard for Exchange of Products.</footnote>
* La pratique de l'interopérabilité par l'intermédiaire de son logiciel.

Acteur et logiciel métier, tous deux sélectionnent la meilleure solution du moment à chaque problème, au cours d'une synthèse rendue permanente.

Si les rôles des acteurs sont clairs, les moyens technologiques pour y arriver ne sont aujourd'hui, 25 années après la création de l'IAI, pas encore satisfaisants. C'est le cas des IFC (Industry Foundation Classes), classification normalisée des objets du Bâtiment élaborée par l'IAI. Cette norme ISO décrit le contenu des objets du Bâtiment à échanger.

Le mécanisme logiciel imaginé pour atteindre les performances de l'interopérabilité était simple, il est résumé par la Figure N° 1. Chaque logiciel métier est muni de deux interfaces IFC, l'un de lecture (Import), l'autre d'écriture (Export).

<figure><img src="image_1.png" /><figcaption>**Figure 1.** Interfaces IFC</figcaption></figure>

Les premiers tests effectués entre deux logiciels de CAO d'éditeurs différents furent un succès. Cependant, ce type d'échange est d'un intérêt limité. Il fallait patienter.

Ces embryons de tests ont caché la véritable impossibilité conceptuelle des échanges hétérogènes, entre un logiciel de CAO et un logiciel métier de calcul, dans les deux sens.

Une divergence au sein de l'IAI s'est traduite par sa dissolution, entraînant la création de BuildingSmart, qui tente de résoudre le blocage de l'interopérabilité par un projet qui revient à « normaliser » les objets utilisés par les logiciels de chaque métier. Certains considèrent que cette extension de la norme est « trop » compliquée :

- Il existe une grande quantité de logiciels techniques à travers le monde, qui diffèrent par des règlements ou contextes nationaux spécifiques, et en constante évolution ;

- De plus, il existe autant de visions et de procédures de calcul que d'ingénieurs, au-delà du respect obligatoire des règlements nationaux de mise en œuvre (Bazjanac 2008).

- Et surtout, lassés d'attendre, beaucoup d'éditeurs de logiciels techniques ont développé des interfaces sur mesure (les « Plug-In ») en se liant à un éditeur major. L'utilisateur devient dépendant d'un éditeur. C'est contraire à l'objectif d'un standard d'échange mondial des données, et interdit l'utilisation d'une maquette numérique unique.

## 1.2 Pourquoi utiliser la norme d'échanges et le BIM, est-il si laborieux ?

Les trois auteurs ont pu vérifier ces difficultés, à l'occasion d'un contrat d'exploration récent (2016) sur les outils du BIM, commandé par le PUCA<fnref n="7" />.

Mais le plus probant, à l'heure actuelle reste le retour d'expérience d'architectes travaillant sur le BIM depuis plusieurs années, cas de l'auteur Thierry Parinaud et de son confrère François Pelegrin<fnref n="8" /> qui décrit le BIM comme un **Bouleversement Interprofessionnel Majeur** qui induit une nouvelle méthodologie de travail.

<footnote n="7">⁷ Commande PUCA 14028125411 de Juillet 2016 « Le BIM ? Oui, mais ... l'interopérabilité dans le secteur du Bt : R Billon, G Castel, O Celnik, JM Dossier, I Fasse, J Hababou, L Ortas, T Parinaud, J Mirtshin, JY Ramelli et contributeurs étudiants du Master spécialisé BIM des écoles ESTP et ENPC.</footnote>

<footnote n="8">⁸ François PELEGRIN, Architecte, Président d'Honneur de l'UNSFA et d'ARCHINOV</footnote>
Pour échanger et inter-opérer, il semblerait admis qu'il est impératif de connaître les outils de ses partenaires pour leur envoyer un fichier compréhensible<fnref n="9" />.

Dans les échanges en 2D, il suffisait d'enregistrer depuis son logiciel CAO le fichier au format dwg (plus concis et performant que le DXF) et de l'envoyer. Et le même fichier dwg servait pour chaque partenaire.

Au contraire, le BIM nécessite un processus minutieux, un tri préalable. Passer de la technologie classique 2D à la maquette numérique est un challenge pour tous, financier (formation + achat matériel) mais surtout de management pour chaque entreprise (du MOA à l'artisan).

Ce processus BIM est lourd car on échange des données ; ce qui implique en amont de
bien définir les objets, de les organiser, de vérifier la conformité à la norme IFC, de choisir
le bon traducteur IFC selon le partenaire destinataire<fnref n="10" />, de le contrôler à l'aide d'un Viewer
avant envoi, etc.

Pour envoyer un fichier au format IFC, plusieurs manipulations sont nécessaires :

- Tout d'abord savoir à qui le fichier est destiné (il sera différent selon le cas),

- Par conséquent, connaître le logiciel utilisé par chaque partenaire,

- Enfin, vérifier avec un Viewer les classifications IFC et les informations détaillées selon l'arborescence définie par la norme IFC. Pour chaque niveau : les zones (Espace), les objets (mur, dalle, porte, fenêtre, etc...), les locaux, les parties privatives et communes, les appartements et ses pièces.

L'obligation d'utiliser des traducteurs aujourd'hui, pour dialoguer entre la maîtrise d'œuvre et le lot Gros-œuvre ; entre la maîtrise d'œuvre et le lot CVC ; entre la maîtrise d'œuvre et le lot VRD ; etc., nous amène à rechercher des "traducteurs" spécifiques et il en existe autant que de "logiciels".

Le BIM induit également une révolution des pratiques pour passer d'une ingénierie « séquentielle » à « collaborative ». Par ailleurs, le BIM n'est pas qu'une simple représentation géométrique ou base de données : il se décline en 4D, 5D, 6D, 7D<fnref n="11" />. Il n'est pas limité en superficie, qui va de la parcelle (BIM) à l'agglomération (CIM<fnref n="12" />) et au territoire (TIM<fnref n="13" />). D'où la nécessité des « conventions BIM » : protocole d'échanges décrivant les procédures collaboratives supports en apparence d'interopérabilité.

1.3 L'obstacle majeur oublié : les différences sémantiques entre métiers.

Les trois auteurs formulent une hypothèse pour expliquer la difficulté d'utilisation des IFC : n'aurions-nous pas oublié un préalable obligatoire avant de normaliser les objets du Bâtiment ?

Aujourd'hui, cet « oubli » est évident : l'information du même objet ne conserve pas forcément le sens de son auteur quand elle est communiquée d'un métier à l'autre. Bien sûr, l'objet lui-même peut changer de forme, ce qui reste gérable. Mais si ses propriétés, sa « sémantique », sont modifiées lors de l'échange, la norme deviendrait alors « multiforme ». Cas imprévu pour les IFC et compliqué à formaliser.

Pourtant, dès 1970, les chercheurs travaillant sur le Descriptif, avaient prévenu : « le problème majeur de la description des objets dans le Bâtiment, c'est de savoir où ils

<footnote n="9">⁹ Les auteurs pensent ici que les échanges devraient logiquement être indépendants des outils du destinataire.</footnote>

<footnote n="10">¹⁰ De plus non seulement l'architecte doit connaître les outils de son destinataire, mais en plus choisir un traducteur spécifique lié à chaque logiciel métier.</footnote>

<footnote n="11">¹¹ 4D : Temps, 5D : Coûts, 6D : énergie et carbone, 7D : Durée et cycle de vie.</footnote>

<footnote n="12">¹² City Information Modeling</footnote>

<footnote n="13">¹³ Territory Information Modeling</footnote>
commencent, et où ils finissent ». Le meilleur exemple est celui d'un Mur, premier de la liste (voir Figure N° 2 : Un mur de l'architecte peut devenir six murs pour le thermicien).

Au-delà des Murs, c'est le cas aussi de la structure porteuse, du clos et couvert, de l'innervation, et plus généralement des composants fabriqués ou assemblés sur place pour lesquels plusieurs corps de métiers interviennent.

<figure><img src="image_2.png" /><figcaption>**Figure 2.** Transformations sémantiques d'un mur entre trois « vues » métier.</figcaption></figure>

Autrement dit, la sémantique d'un objet est variable selon le métier qui l'observe et le construit. Les « vues métier » d'une configuration d'objets sont différentes.

L'ambigüité sémantique se prolonge dans les descriptifs, le planning, les calculs quantitatifs, estimatifs, les relations portées par l'objet avec son environnement. La norme IFC a bien marché tant que les échanges concernaient le même métier.

Les premiers chercheurs de l'IAI étaient en majorité des architectes. Inconsciemment, ils ont privilégié la description pour ce métier, et n'ont perçu le problème sémantique que plus tard. Une mésaventure qui a eu de lourdes conséquences : on retrouve cette difficulté prescriptive dans le lieu de stockage et d'échange de l'information du projet : la maquette numérique BIM. De plus, ce constat interdit l'existence d'une maquette centralisée, difficile à construire.

## 2. Poursuivre l'innovation pour échanger.

Les auteurs ont repris le problème des échanges de données à la racine. Pour traiter (et donc automatiser) les différences sémantiques portées par les objets, il s'agit au préalable de construire une représentation générique de tous les objets quelques soient les métiers, et la stocker dans une maquette BIM unique, centralisée : la référence. C'était l'idée de l'IAI en 1995¹⁴. Elle a été abandonnée dans la recherche poursuivie par BuildingSmart.

Le terme « Générique » signifie « qui contient en puissance toutes les représentations métiers, toutes les vues métiers ». C'est l'innovation structurante que nous utilisons.

Ensuite l'échange est réalisé en deux étapes par des transformations indépendantes dans le temps, mais dans un ordre logique. Ce n'est surtout pas le métier émetteur qui réalise l'export.

<footnote n="14">¹⁴ ‘Comprendre les concepts des IFC, décrire son projet en vue des échanges’ par Roland Billon. Médiaconstruct 1999, pages 84 et suivantes.</footnote>
C'est le destinataire qui doit aller extraire du BIM centralisé l'information de l'échange, car il est le seul à savoir ce dont il a besoin. Donc nous devons inverser la procédure actuelle qui oblige l'émetteur à connaître les outils et méthodes du métier destinataire.

BuildingSmart a contourné ce blocage en proposant d'élaborer des « Traducteurs ». Une complexité superflue si on utilise par exemple une forme « générique » qui autorise aussi une maquette centralisée : deux problèmes résolus à la fois. Résumons cette méthode proposée par les auteurs:

<figure><img src="image_3.png" /><figcaption>**Figure 3.** Schéma d'échanges des données à travers un BIM générique centralisé. Remarquons que le message peut être envoyé à tous les partenaires supposés concernés.</figcaption></figure>

L'émetteur A modifie le projet dans le BIM générique et se contente d'envoyer un message au métier destinataire B : « j'ai modifié tel aspect du projet ». Sous-entendu, « Extrais ce dont tu as besoin ». La transformation sémantique vers le métier B est réalisée par les règles métier de concatenation (voir chapitre 3) dont B est le seul propriétaire. L'émetteur ignore la technologie du destinataire. Cette méthode non seulement permet de simplifier la procédure d'échanges, mais rend caduque les traducteurs. Toute erreur d'extraction n'endommage pas le contenu de la base. Toute erreur de remplissage est de la faute de celui qui a renseigné la maquette BIM centralisée. Encore qu'un contrôle sévère et automatique de cohérence soit possible, de quelque acteur qu'elle provienne.

## 2.1 L'interopérabilité dans le bâtiment n'est plus une recherche.

La quantité des transformations implique obligatoirement des procédures automatiques. Certaines ont déjà été expérimentées, d'autres sont à améliorer, mais surtout il s'agit de les faire fonctionner ensemble. Etalée sur plus de 20 ans et s'appuyant sur des expériences encore plus anciennes, l'operérabilité dans le bâtiment, selon les auteurs, n'est plus une recherche, elle est arrivée au stade du développement d'un prototype logiciel : « un moteur numérique » composé de cinq éléments qui fonctionnent séquentiellement, et d'une discipline transversale :

<figure><img src="image_4.png" /><figcaption>**Figure 4.** Les cinq modules du moteur numérique et les règles qui ont le statut de données.</figcaption></figure>
1. Le filaire topologique de volumes, support de conception et d'information (donnée initiale manuelle saisie au sein d'un logiciel de DAO ou de CAO).

2. Sa décomposition en éléments insécables (automate).

3. La matérialisation d'une solution constructive par des règles (automate).

4. La représentation générique des technologies de construction (automate).

5. La traduction d'une vue métier vers un autre métier (automate).

Et un sixième élément, transversal :

6. La formalisation de connaissances métier par des règles (rules) paramétrables.

## 2.2 Le filaire volumique, support de conception et d'information.

Ce concept date de l'époque des systèmes constructifs modulaires en préfabrication lourde. Le filaire topologique n'est donc pas une innovation. Ce sont les usages qui le sont. Les chercheurs semblent avoir oublié ce support d'information. Les auteurs ont pu, entre-autre, vérifier cette absence à l'international, à l'occasion d'un contrat d'exploration récent (2016) sur les outils du BIM, commandé par le PUCA<fnref n="15" />. Il existait à leur connaissance une exception, aux Etats-Unis<fnref n="16" />.

<figure><img src="image_5.png" /><figcaption>**Figure 5.** La représentation volumétrique filaire, un concept puissant</figcaption></figure>

Ce concept a évolué vers l'intégration de formalisation des connaissances au sein même d'une maquette numérique, elle-même concept précurseur. La figure N°5 illustre les bénéfices attendus pour les échanges de données. Dans l'approche des auteurs, le « Filaire topologique » est la première étape formelle de transformation de l'information du projet, et aussi du bâti existant.

Les logiciels produits par le laboratoire KEOPS utilisaient le filaire topologique et s'appuyaient sur cette approche méthodologique traduite par la formule : « Définir le contenu (les espaces) avant le contenant (les composants) ». Méthode opposée à celle communément pratiquée dans la saisie des logiciels de DAO-CAO, dite « du maçon », qui consiste à placer des composants les uns après les autres, à côté ou au-dessus.

<footnote n="15">15 Commande PUCA, déjà citée</footnote>

<footnote n="16">16 Outils SBT « Space Boundary Tool» de l'Université de Berkeley (USA)</footnote>
## 2.3 Décomposition du filaire en éléments insécables.

C'est la deuxième étape, cachée pour l'utilisateur, mais fondamentale. Nous proposons de réduire la représentation volumique en éléments « finis », découpés de telle sorte que vis-à-vis des fonctions bioclimatiques et fonctionnelles des locaux, les morceaux de parois des volumes deviennent « homogènes ». Chaque point de la surface d'un élément doit posséder les mêmes contraintes vis-à-vis de l'environnement. Il en est de même pour les éléments linéaires. L'objectif est de permettre les automatismes de traduction inter-métiers, par la transformation des parois de volumes en technologie de construction. Cette opération devient accessible à un automate, car elle utilise par définition la procédure de « concaténation » des objets insécables, dans toutes les directions. Cette avancée a fait l'objet de plusieurs publications scientifiques<fnref n="17" /> et d'enseignement<fnref n="18" />.

## 2.4 Matérialisation automatique d'une solution constructive.

L'énorme avantage du découpage homogène décrit précédemment est ensuite opérationnel pour plusieurs autres séries de transformations. Il permet de rendre compte d'une technologie de construction choisie par l'utilisateur, en la matérialisant sur le projet d'une façon « automatique ». Soit : « créer de la matière » accrochée au « squelette représenté par le filaire ». Au dire de l'utilisateur des logiciels de COMPUTERVISION<fnref n="19" />, cette performance est « magique ». C'est la machine qui dessine pour lui ! Elle procure un gain de temps de saisie exceptionnel, en évitant de plus les oublis, incohérences et erreurs manuelles inévitables en DAO et CAO.

Le gain se manifeste surtout au droit des nœuds, le moteur pouvant alimenter les dessins de jonctions d'un logiciel de CAO et même de DAO d'une façon automatique. Nous ne rentrerons pas dans le détail de ces innovations, pour nous attarder sur l'aspect essentiel de la formalisation des connaissances professionnelles d'un métier.

## 2.5 Formalisation des règles paramétrables d'un métier.

En examinant à nouveau la figure N°4, on s'aperçoit que ce concept de règles métier (Rules) intervient tout au long de l'utilisation du moteur numérique. Elles ont le statut de données et offrent, entre-autre, des avantages opératoires d'automaticité et d'évolution.

Les premières sont internes, réservées aux développeurs (Internal Semantic Rules). Les deux autres appartiennent à l'utilisateur (Building Technology Rules, Trade Rules) et s'appliquent en fonction d'un contexte d'organisation des locaux, de l'ambiance, de fonctions de reconnaissance du voisinage. Certaines s'appliquent uniformément, d'autres selon une gradation conditionnelle (moteur d'inférences). Nous n'avons pas encore fini d'explorer la puissance de ce concept, qui présente des avantages inconnus jusqu'alors, dont l'économie déterminante de développement et d'utilisation.

Il existe une gradation fonctionnelle de ces règles pour l'utilisateur. Les plus simples sont les règles de « dimensionnement » des ouvrages, le filaire ne fournissant que les dimensions « nominales ». La règle apportera épaisseurs, couches, priorités aux nœuds.

<footnote n="17">¹⁷ Système unitaire de communication du bâtiment, SUC-DXF : commentaires à l'usage des utilisateurs : le filaire topologique et les principaux objets d'un plan de bâtiment. R.Billon & al.</footnote>

<footnote n="18">¹⁸ Par exemple : Contrat UNIT N°2010-25 Avril 2013. Maquette Numérique et Interopérabilité dans le Bâtiment. CSTB, ENPC, MEDIACONSTRUCT (R. Billon et I.Fasse), UVHC, UNIT.</footnote>

<footnote n="19">¹⁹ Numéro 1 mondial de la CFAO dans les années 1990, COMPUTERVISION a commercialisé le logiciel KEOPS sous le nom de PERSONAL ARCHITECT</footnote>
## 2.6 Un exemple d'exécution de règles de connaissances métier.

Choisissons une règle proposée par défaut (Figure 6) : elle déduit automatiquement la fonction de la paroi Mur qui sépare deux locaux filaires contigus. L'utilisateur a déjà renseigné le type d'espace des volumes filaires lors de la saisie. Les règles sélectionnent une fonction de mur parmi 18. De quoi satisfaire tous les besoins, sauf certains trop dépendants du contexte (Ex : parois coupe-feux utilisant des règles de type règlementaire).

### Liste des règles de matérialisation

Par comparaison des espaces entre deux volumes.
Espace type 1 : Peu chauffé et silence

<table><caption>**Figure 6.** Liste des règles de matérialisation: règles pour obtenir la fonction d'une paroi verticale</caption><thead><tr><th>Type espace 1<br>Intérieur<br>ou devant</th><th>Type espace 2<br>extérieur<br>ou derrière</th><th>Comparaison<br>Nom local Niv 4<br>= ou #</th><th>Comparaison<br>Nom Pièce Niv 5<br>si #</th><th>Résultat :<br>Type de paroi<br>à matérialiser</th></tr></thead><tbody><tr><td>1</td><td>0</td><td>sans objet</td><td>sans objet</td><td>Façade</td></tr><tr><td>1</td><td>1</td><td>#</td><td>sans objet</td><td>Refend phonique</td></tr><tr><td>1</td><td>1</td><td>=</td><td>#</td><td>Cloison phonique</td></tr><tr><td>1</td><td>2</td><td>#</td><td>sans objet</td><td>Refend phonique</td></tr><tr><td>1</td><td>2</td><td>=</td><td>#</td><td>Cloison phonique</td></tr><tr><td>1</td><td>3</td><td>#</td><td>sans objet</td><td>Refend phonique et hydrofuge</td></tr><tr><td>1</td><td>3</td><td>=</td><td>#</td><td>Cloison phonique et hydrofuge</td></tr><tr><td>1</td><td>4</td><td>#</td><td>sans objet</td><td>Refend phonique</td></tr><tr><td>1</td><td>4</td><td>=</td><td>#</td><td>Cloison phonique</td></tr><tr><td>1</td><td>5</td><td>#</td><td>sans objet</td><td>Refend phonique</td></tr><tr><td>1</td><td>5</td><td>=</td><td>#</td><td>Cloison phonique</td></tr><tr><td>1</td><td>6</td><td>#</td><td>sans objet</td><td>Refend thermique</td></tr><tr><td>1</td><td>6</td><td>=</td><td>#</td><td>Cloison thermique</td></tr><tr><td>1</td><td>7</td><td>#</td><td>sans objet</td><td>Façade sans ouverture</td></tr></tbody></table>

<figure><img src="image_6.png" /><figcaption>**Figure 7.** Règle topo-géométrique de matérialisation par rapport au filaire. Sources : Logiciels KEOPS et Personal Architect.</figcaption></figure>

Le tableau de la figure n°6 fonctionne comme une table de décision. Les deux premières colonnes contiennent les types d'espace de locaux contigus.

La 3ème colonne permet de savoir si le nom du service ou de l'appartement est différent (#). La 4ème colonne si le nom de pièce des deux locaux est différent (#). Le résultat, affiché dans la 5ème colonne fournit la fonction de la paroi homogène à matérialiser entre les deux locaux.

Une trentaine de tableaux similaires permettent de matérialiser une technologie par des règles modifiables. Par exemple si le contexte bioclimatique de la région peut simplifier le résultat à atteindre (pays tropical) ou au contraire le complexifier (usines chimiques, process industriel, etc.). La fonction de la paroi une fois connue, l'automate consulte ce qu'a prévu l'architecte.