Les propriétés topologiques conditionnent la faisabilité des échanges
L'impossibilité décelée n'est pas due à l'organisation de la structure de données, mais aux propriétés topo-géométriques de certaines entités. C'est à dire que la difficulté est cachée, non décelable à l'examen d'un modèle conceptuel de données qui peut être parfait.
Que de déconvenues en perspective, si l'on n'est pas averti du problème !
Ces difficultés d'échange ont été mises en évidence lors d'une recherche française, intitulée CCM[1] (Communication entre logiciels de Conception et logiciels de Maintenance).
L'objectif, expérimental, était d'analyser les modèles conceptuels de données utilisés par les différents logiciels en présence. Les échanges ont été ensuite testés en développant ou en utilisant des interfaces spécialisés, la plupart « sur mesure ».
Le résultat théorique consistait à élaborer une maquette de modèle conceptuel[2] d'échange, comme une synthèse et une extrapolation de l'expérimentation (une étude qui rejoignait déjà les objectifs de l'IAI[3] et de BuildingSmart[4]).
L'étude a permis de théoriser une classification des structures de représentation graphique des bâtiments, et de mettre en évidence les problèmes de faisabilité des échanges automatisés.
Les points de vue, la façon de voir le bâtiment, et donc la façon de représenter graphiquement le projet, sont en effet toujours différents selon les logiciels. Chaque métier privilégie un type d'objets, soit dans la saisie, soit dans le traitement, soit dans le résultat produit, bien souvent graphique.
Par exemple, les opérateurs de la majorité des logiciels de CAO[5] privilégient la saisie directe des composants du bâtiment. Ils construisent leur maquette un peu comme un maçon ou plus exactement comme s'il s'agissait de composants préfabriqués que l'on met bout à bout et que l'on empile.
C'est surtout la production de plans 2D, et une maquette géométrique 3D pour une représentation réaliste, qui sont privilégiés comme résultats.
Avec des nuances sur la sémantique des entités géométriques offertes par les logiciels, certains étant très pauvres, d'autres plus riches, mais en général, tous étant déficients sur la qualité du réseau relationnel. Ce qui limite les exploitations qualitatives du type DQE[6] et de calcul en général.
D'autres logiciels, beaucoup plus rares, privilégient une représentation du bâtiment par les locaux, soit sous une forme filaire, soit sous la forme de nus d'enveloppe (NU DE LOCAL[7]).
L'aspect sémantique est alors beaucoup plus riche, car ces logiciels peuvent déduire par un système de règles topologiques simples soit les objets voisins (les composants de structure), soit les objets qui ne sont pas saisis (les revêtements). Ces règles de topologie spatiale, basées sur le contact géométrique d'entités jointives, définissent le système relationnel entre ces types d'objets dont on a besoin pour les échanges graphiques.
Pour l'opérateur des logiciels de CAO, cette constatation signifie en pratique qu'il devra s'attacher à définir les locaux et les composants en se coordonnant sur des axes de référence, à faire coïncider en plan et dans l'espace. Il construit ainsi une organisation topologique des objets entre-eux qui garantit les transformations dans l'espace en 3 dimensions des différentes vues métiers.
