Edibatec, ATITA, Eurovent, Gencod, INIES… Les bases de données sont nombreuses, avec chacune leurs spécificités. Elles ont fait la preuve de leur utilité et évoluent dans la perspective du BIM.
Les premières bases de données, sont apparues avec les premiers logiciels techniques. Chaque éditeur récupérant lui-même, à partir de catalogues papier, les informations du fabricant pour réaliser sa base de données. En même temps, dès les années 80, des travaux théoriques ont été menés, par exemple au CSTB qui cherchait une façon rationnelle de stocker les avis techniques. Ces travaux ont porté essentiellement sur la façon de fixer les règles pour définir les attributs et les classes de produits. Le travail pour la réalisation d’un dictionnaire complet pour tous les produits du bâtiment a été à peine amorcé et aucune base de données n’a découlé de ces travaux.
Parallèlement apparaissaient aussi, dans les logiciels de métré et de gestion, des bases de données qui associaient quelques informations techniques sur les produits à des informations sur le prix et les conditions logistiques.
Dans les travaux anciens, on peut signaler une thèse de 1986 : « Structuration des données de la conception d’un bâtiment pour une utilisation informatique » de Assed Tlili réalisée à l’Ecole Nationale des Ponts et Chaussé, qui cherche déjà à définir :
– Un dictionnaire de données ;
– Un schéma de structuration de données ;
– Un schéma des structurations des traitements.
Beaucoup de travaux actuels, académiques ou industriels, menés depuis cette thèse traitent de ces 3 problématiques.
Naissance d’Edibatec
Pour la réalisation des bases de données, l’exemple d’Edibatec, est intéressant, car cela a été, en France, la première base de données multi fabricants réalisée par les fabricants eux-mêmes. Le projet est né d’un appel d’offre du PUCA (Plan Urbanisme Construction Architecture) de 1991. En 2014, le rapport final de la mission numérique souligne les objectifs de la démarche :
« Il faut noter que l’association Edibatec, qui rassemble environ 100 industriels en relation avec les corps d’état techniques du bâtiment, met à disposition un format de base de données (en cours d’intégration dans «BSDD») pour :
- Simplifier le langage d’échange de données entre les acteurs de la construction
- Standardiser les formats d’échanges de données techniques destinés aux outils de calculs techniques (de prescription)
- Faciliter l’accès aux informations techniques dématérialisées »
Le plan de travail originel a comporté 3 étapes :
- Définition de la méthodologie
- Réalisation d’un dictionnaire.
- Constitution effective de la base de données.
Le principe retenu a été de classer les produits par classe et de définir pour chaque classe une liste d’attributs. Une caractéristique de la méthode est de ne comporter aucune hiérarchie entre composants. Par exemple il existe une classe pour les vitrages de fenêtres, une classe pour les profilés de fenêtres et une classe pour les fenêtres sans lien entre les attributs des 3 classes. La charge de créer ces liens est laissée aux logiciels qui exploitent la base.
Cette limite du système a été sa force en facilitant la réalisation des bases de données. Chaque fabricant a pu, avec un travail sans complexité excessive, réaliser sa propre base, dont il était naturellement propriétaire. Les bases de tous les fabricants ont été rassemblées dans une unique base Edibatec qui a été ensuite distribuée librement en particulier à tous les éditeurs de logiciels.
Ce principe de fonctionnement a permis à Edibatec de se développer et la base Edibatec est devenue la base technique pour l’application de règlements thermiques demandant des calculs complexes : la RT2012 puis la RE2020. Les travaux actuels d’Edibatec portent essentiellement sur :
- La correction ou l’ajout d’un attribut en fonction de l’évolution des normes ;
- La création de nouvelles classes pour des produits innovants ;
- Les démarches qualité pour minimiser les erreurs existantes dans les bases.
Les autres bases de données
Par la suite toutes les bases de données, réalisées en France dans le bâtiment, ont adopté un modèle similaire à celui d’Edibatec.
- Celles de l’ATITA et d’Eurovent. Dans les deux cas, les dictionnaires de données ont été homogénéisés avec celui d’Edibatec, ce qui a permis une synchronisation permanente des bases de données. Des accords ont été conclus pour laisser à Edibatec la distribution des bases vers les éditeurs de logiciel.
- Celle de Gencod qui souhaitait disposer d’une base de données incluant des données commerciales et logistique. Dans un projet soutenu par le ministère de l’industrie dans le cadre UCIP le dictionnaire de Gencod a pu être homogénéisé avec celui d’Edibatec pour permettre aux fabricants d’alimenter plus facilement les 2 bases.
- Celle d’INIES. Cette base portée par le CSTB occupe une place importante car elle a été d’utilisation obligatoire pour l’expérimentation E+C- et elle va l’être pour la réglementation RE2020. Sa particularité est de comporter des données de fabricants et des données génériques pénalisantes élaborées par les pouvoirs publics ou les syndicats professionnels. Pour éviter des doubles saisies de produits dans les logiciels, Edibatec permet aux fabricants de réaliser des liens entre des fiches produits de sa base et des fiches produits de la base INIES.
Quelle perspective dans le BIM ?
D’un côté, le format IFC est très complet pour la représentation 3D, et contient quelques informations techniques, par exemple pour les fenêtres : le U et le S. De l’autre, la base Edibatec ne contient sur le plan géométrique que la longueur et la largeur, mais détaille les caractéristiques techniques ; pour l’exemple des fenêtres, on trouve un U été et un U hiver, et tous les types de facteur solaire thermique et de facteur solaire lumineux (cela représente plusieurs centaines de valeurs, pour les fenêtres équipées de store vénitiens). La base Edibatec contient aussi des informations sur le verre que l’on n’a pas dans les IFC : lorsque les valeurs spectrales sont renseignées, c’est quelques milliers de données pour un seul verre. On comprend dans ces conditions que lorsqu’un bâtiment contient des milliers de fois le même verre il n’y a pas d’intérêt à inclure dans le fichier IFC à chaque fois la description du verre.
La question s’est donc posée d’adjoindre à la description IFC d’un bâtiment la description de ces composants, dans une structure adaptée et de manière à éviter de décrire plusieurs fois le même élément.
Au plan international, ce problème, qui reste ouvert, a été à l’origine d’une très abondante recherche académique ou industrielle. Pour la France on peut citer :
- Une démarche pour formaliser la façon de décrire les dictionnaires de données. Cela a donné naissance aux références ISO PASS 12006-2 (2002) et 12006-3 (2007) puis à PPBIM développé à l’AFNOR qui a été porté à l’international comme la norme expérimentale XP P07 150 (2014) puis ISO 23386 (2020).
- En France, en 2002, le PUCA a soutenu le projet SDC qui voulait expérimenter l’usage de l’ISO PASS 12006-3. Le ministère de l’industrie dans le cadre des projet UCIP a soutenu en 2005 le projet « Produit Interopérable ».
- Une part significative du Plan BIM 2022 a soutenu le projet PPBIM et son portage international.
Et en pratique?
Le projet BEE (BIM Energétique et Environnemental soutenu par l’ADEME) aborde ces questions d’un point de vue pratique. Dans ce projet, on cherchait à rendre opérationnel les calculs thermiques et environnementaux à partir d’une maquette actuelle et possiblement incomplète, mal exportée, voire erronée. Nous sommes est arrivés au fait qu’il fallait permettre de travailler avec des données incomplètes et de fournir les outils pour corriger et compléter ensuite, tout en tirant profit un maximum des données déjà présentes. Aujourd’hui, ces recherches continuent. Par ailleurs, nous participons au groupe de travail BEM de BuildingSmart France, dans lequel on se retrouve avec nos pairs pour faire évoluer au mieux les formats du BIM.
