Direction

Division

PTNB – Numérisation de règles

Rapport conclusif

Client : DHUP

Contrat : PTNB-CONV03-17-049

Date : 06/07/2018

N° : PTNB – NR - SE2 2018-01

DIRECTION ENERGIE ENVIRONNEMENT DIRECTION TECHNOLOGIES DE L’INFORMATION

2

Table des matières

1. INTRODUCTION ..................................................................................................... 4

2. OBJET DE CE DOCUMENT .......................................................................................... 5

3. BILAN SUR LA METHODOLOGIE DE TRAVAIL POUR SUPPORTER LES TRAVAUX DE

CONCEPTUALISATION ET DE FORMALISATION DES REGLES ................................................ 7

Méthodologie de travail selon les phases de l’acte de construire ................. 7

Vocabulaire « Franco-BIM » ........................................................................ 8

Termes candidats ......................................................................................... 9

Le traitement de la liste de réserve ........................................................... 10

Les langages utilisés .................................................................................. 11

4. BILAN SUR LES CHARTES BIM POUR LA CONSTITUTION DES MAQUETTES NUMERIQUES ADAPTEES

A LA SUPERVISION DE REGLES ................................................................................. 13

5. BILAN SUR LE DEVELOPPEMENT DU DEMONSTRATEUR DE SUPERVISION DE REGLES .............. 14

Les limites du démonstrateur .................................................................... 14

Les préconisations issues du projet PTNB- Numérisation de règles ........... 15

ANNEXES ............................................................................................................ 19

Annexe 1 : Exemple de règles en MVDXML / temps de traduction

Annexe 2 : Premières réflexions sur un système d’indexation des règles formelles et du

vocabulaire

Annexe 3 : Illustration d’un scénario d’utilisation du démonstrateur

3

4

1. INTRODUCTION

La filière construction est engagée dans une profonde mutation qui vise à intégrer le numérique dans l’ensemble de ses activités et process, de la programmation à la déconstruction des bâtiments, en passant par la conception, la réalisation et l’exploitation maintenance. La maquette numérique (ou BIM) est amenée à occuper une place de pivot central entre les acteurs intervenants sur un même projet de construction. Les règlementations de la construction, établies par l’Etat pour garantir un niveau minimal de qualité de la construction, sont, par nature, d’application obligatoire. Elles portent sur des champs essentiels tels que la sécurité incendie, l’aération, la thermique, l’acoustique et l’accessibilité. Leur expression est inscrite sous forme de décrets, d’arrêtés, de circulaires décrivant les exigences (techniques, fonctionnelles, performancielles) attendues des bâtiments, selon leur destination, leur catégorie ou leur usage. Les règles de l’art, établies par les acteurs de la construction (DTU, règles professionnelles, etc.) s’imposent de fait à l’ensemble des acteurs de la construction, notamment parce qu’elles segmentent les tâches et les responsabilités des différents acteurs. Dans le contexte actuel d’utilisation croissante de la maquette numérique, se pose naturellement la question de la faculté du BIM à faciliter et améliorer la conception et la vérification, à chaque étape de la construction, de la conformité des ouvrages aux règles de construction. Il n’existe pas ou quasiment pas aujourd’hui d’outil logiciel assurant de telles fonctions tant pour la règlementation que pour les règles de l’art. Pour participer à la généralisation de l’usage du BIM par l’ensemble des acteurs de la filière, et notamment par les TPE/PME, il est important de faire la démonstration de services innovants, apportant des réponses fonctionnelles à des questionnements et des besoins très opérationnels, auxquels il est aujourd’hui mal ou insuffisamment répondu. A terme, les référentiels quelle que soit leur nature (réglementaire, technique, de certification) devraient pouvoir être supportés par la maquette numérique. La possibilité de procéder automatiquement ou à la demande à des vérifications quant à leur respect demeure un objectif, dont les conditions de mise en œuvre ne sont pas aujourd’hui totalement connues. Le Plan de Transition Numérique du Bâtiment prévoit, dans sa feuille de route, d’étudier la faisabilité de nouveaux modes de formulation et de vérification des exigences technico-réglementaires. Dans ce contexte, la DHUP, a proposé de confier au CSTB la coordination de la conception et du développement d’un démonstrateur d’un service de vérification des exigences technico-réglementaires dans une finalité d’autocontrôle par les acteurs du projet. L’autocontrôle des projets doit permettre, à tous les acteurs du projet de construction, et notamment aux TPE et PME (ex ; architecte, BET, entreprises artisanales) de vérifier le

5

respect des exigences technico-réglementaires tant pendant la phase de conception que pendant la phase d’exécution. La réalisation d’un tel démonstrateur de superviseur de règles comporte plusieurs volets : • L’identification de quelques cas d’usage présentant un intérêt fort et donc

démonstratif. Un cas d’usage est défini par : un type de bâtiment, un type d’utilisateur, un domaine technico-réglementaire. Compte tenu de l’étude des domaines couverts par les règles techniques et du délai dans lequel le démonstrateur devrait être présenté, il pourra s’avérer nécessaire dans certains cas d’identifier une ou plusieurs étapes dans le process de conception/réalisation d’un projet.

• L’élaboration d’une méthodologie permettant d’une part de transformer l’expression littérale de règles en une énonciation formelle autorisant leur traitement informatique et d’autre part la mise en correspondance des exigences ainsi exprimées sous forme de règles avec les éléments de la maquette numérique (propriétés et attributs des objets du modèle IFC). Ce volet inclut également un travail préalable sur la vérification systématique des données disponibles dans la maquette au regard des besoins d’informations nécessaires à la vérification des règles.

• Le développement informatique et le test d’un démonstrateur, ainsi que des préconisations pour une généralisation.

Par ailleurs, la DHUP et le PTNB ont confié au CSTB la mise en œuvre d’une plateforme collaborative de gestion de projets en maquette numérique. Cette action vise à promouvoir l’utilisation du BIM par les TPE/PME. S’appuyant sur les technologies ouvertes, cette plateforme a vocation à favoriser l’émergence et à accueillir des outils et des services métier autour de la maquette numérique des projets de construction. Les services de vérification des exigences technico-réglementaires ou superviseur de règles font partie des services identifiés comme attendus sur cette plateforme par les parties prenantes des projets de construction. Un modèle économique est également proposé par un groupe de travail distinct pour l’exploitation des résultats du projet.

2. OBJET DE CE DOCUMENT

L’objet de ce document est de dresser le bilan du projet Numérisation de règles sur l’ensemble des phases :

- Méthodologie de travail pour supporter les travaux de conceptualisation et de

formalisation des règles, - Chartes BIM pour la constitution des maquettes numériques adaptées à la

supervision de règles,

6

- Développement du démonstrateur de supervision de règles (implantation des bases de règles, constitution du rapport d’analyse et fonctionnalités pour les

utilisateurs).

Ce bilan permet d’évaluer la pertinence de la démarche de supervision de règles et son intérêt pour les utilisateurs. Il identifie également les écarts avec la vision

initiale ayant conduit à retenir les cas d’usages traités. Il intègre aussi les préconisations sur les travaux complémentaires à réaliser en vue

d’une généralisation à d’autres cas d’usage et plus globalement, à l’élargissement du champ technico-réglementaire traité.

Dans le cadre du projet de loi pour un État au service d’une société de confiance1, ce bilan précise également comment intégrer à cette démarche les nouveaux outils

issus des travaux du projet PTNB-Numérisation de règles.

1 Le Gouvernement sera habilité à légiférer par ordonnances pour réécrire le code

de la construction et de l'habitation (CCH) de manière à substituer aux obligations

de moyens actuelles des obligations de résultats, qui laisseront plus de place à

l'innovation.

7

3. BILAN SUR LA METHODOLOGIE DE TRAVAIL POUR SUPPORTER LES TRAVAUX DE CONCEPTUALISATION ET DE FORMALISATION DES

REGLES

Méthodologie de travail selon les phases de l’acte de construire

Les 5 cas d’usage choisis par le Comité de pilotage du PTNB sont les suivants :

N° Bâtiment Acteur du

bâtiment

Domaine technico

réglementaire

Pilote

1 Logement collectif Entreprises Acoustique – Bruit d’impact FCBA

2 Maison individuelle Architectes Référentiel énergie carbone CSTB

3 ERP 5

ème

catégorie Architectes Accessibilité –

Circulations intérieures

horizontales – Circulations

verticales - Sanitaires

SHERP’

ACCES

4 Logement collectif Entreprises DTU 25.41 / 25.42 Cloisons en

plâtre

CSTB

5 ERP 5

ème

catégorie Architectes /

Entreprises

Sécurité incendie –

Construction, dégagement,

gaine- Aménagements

intérieurs- Désenfumage –

Moyen de secours

SOCOTEC

Les cas d’usage portent sur :

- De la conception (GT 3 Accessibilité – GT5 Sécurité incendie),

- De la qualification de l’ouvrage vis-à-vis de la réglementation (GT 2 E+C-), - De la mise en œuvre (GT1 Acoustique – GT4 DTU Cloisons – GT5 Sécurité

incendie).

Selon les phases de l’acte de construire, la méthodologie de travail s’est révélée

différente.

Les cas d’usage traitant de la conception ont pu donner lieu à la rédaction de bases de règles, selon figure 0 ci-dessous.

Figure 0 : Méthodologie de numérisation

8

A contrario, les cas d’usage traitant de la mise en œuvre et de la qualification de

l’ouvrage vis-à-vis de la réglementation ne font pas l’objet d’une base de règles :

- les cas d’usage de mise en œuvre sont traités par le biais de scénarii de pose

(maquette « exe »), - le cas d’usage du référentiel E+C- s’attache à identifier les éléments de la

maquette constituant les données d’entrées du calcul des indicateurs E+C-.

Vocabulaire « Franco-BIM »

Une « boite à outils » a été mise à disposition des experts pour faciliter leur travail. Pour rappel, l’objectif de cette première étape est de sélectionner des textes

technico-réglementaires actuels (pour les cas d’usages concernés) et d’en fournir une reformulation qui soit plus simple (phrases directes et non ambigües), tout en tenant compte qu’on ne demande pas aux experts métiers auxquels nous avons fait

appel d’être des experts informaticiens ou d’être dotés d’une expertise BIM.

Pour cela, le CSTB a préparé, dans le cadre de cette boite à outils, une première version d’un vocabulaire dit « contrôlé ». Ce vocabulaire contrôlé se présente sous la forme d’un listing structuré de termes en langue française dont il existe une

correspondance dans le langage de la maquette numérique, à savoir : le langage IFC.

L’élaboration de ce vocabulaire s’est faite en partant de la dernière version en date des IFC (IFC Version 4 - Addendum 2). Sur cette structure qui contient déjà des termes français, il a été ajouté d’autres termes provenant d’initiatives connexes

(comme par exemple le bSDD – buildingSMART Data Dictionnary).

Un travail important a été consacré à la catégorisation des mots du vocabulaire contrôlé afin de garder la correspondance avec la façon dont les IFC distinguent les concepts des relations ou des propriétés.

Il a été incorporé à notre vocabulaire des termes permettant la structuration des

phrases semi-formelles (comme par exemple l’expression « Si … Alors… »). A l’issue de ces travaux, le vocabulaire contrôlé contenait environ 2000 termes en

français ayant directement leur équivalent en IFC avec une catégorisation en 6 familles distinctes comme illustré par la figure 1 ci-dessous.

9

Figure 1 : Processus de génération et de catégorisation du vocabulaire contrôlé

Termes candidats

Dès les premiers travaux avec les experts, il est rapidement apparu que le champ lexical couvert par les 2000 termes alignés sur la maquette numérique ne suffisait

pas pour couvrir le domaine lexical règlementaire. Il a fallu, en parallèle des travaux des experts, augmenter le nombre des traductions Français / IFC. Nous sommes passé pour cela à environ 4000 termes. Néanmoins, certains termes

utilisés dans les textes règlementaires restaient sans équivalences directes avec les concepts présents dans les IFC. Ces termes, alors placés temporairement dans

une liste de réserve, ont été traités dans un second temps (après la phase de reformulation avec les experts).

Afin de permettre des enrichissements du vocabulaire contrôlé mis à disposition initialement, il a été imaginé un processus entre les groupes de travail et les experts

BIM du CSTB afin de collecter régulièrement des notions manipulées par ces groupes et dont ils n’auraient pas trouvé d’équivalence dans le vocabulaire de base que nous

avions élaboré. Il a été demandé à chacun des groupes de rassembler ces notions sous forme de

listes de « Termes Candidats ». Ces termes et la sémantique associée étaient analysés par les experts du CSTB pour déterminer si le terme candidat pouvait avoir

une transcription directe en IFC (une correspondance pouvait être établie entre le terme candidat et une entité, une relation, une propriété, un terme dans une énumération) ou si le terme recouvrait une notion plus complexe nécessitant un

pré-traitement spécifique de la maquette (par exemple la notion « d’angle rentrant » ou « d’escalier encloisonné »).

10

Ce processus est illustré par la figure 2 ci-dessous.

Figure 2 : Mécanisme d’enrichissement du vocabulaire contrôlé par l’ajout après analyse des termes

candidats proposés par les experts

Le traitement de la liste de réserve

Comme évoqué dans le chapitre précédent, il est nécessaire de mettre en place des mécanismes permettant d’aller au-delà de l’expressivité native des IFC pour couvrir

les notions manipulées dans les textes règlementaire. Pour traiter ces termes candidat de la liste de réserve, il a été nécessaire de faire

appel à des technologies issues du web sémantique. Grace à cela, différents termes intermédiaires ont alors été définit et par composition ont permis la définition de

notions présentes dans les textes règlementaires. Cette démarche est illustrée en figure 3 pour le cas de la réglementation incendie.

La notion d’Espace_Protégé est présente dans la règlementation incendie mais pas dans les IFC. Elle est une composition de plusieurs notions comme

Circulation_Horizontale , Cage_Escalier par exemple qui doivent en plus présenter des caractéristiques particulières (être à l’abris des fumés ou être protégées par une

ventilation naturelle), alors que les IFC traitent d’Escalier, d’Etage, de Mur. Il a été mis en place des mécanismes permettant, à partir des IFC, de définir des

notions dites d’usage, de rajouter à ces notions d’usage des caractéristiques particulières ou de définir des notions composées à partir de ces notions d’usage

pour enfin atteindre la notion évoquée dans le vocabulaire règlementaire.

11

Figure 3 : Mécanisme d’enrichissement du vocabulaire contrôlé par l’ajout des termes de la liste de réserve – basée sur l’usage des technologies du web sémantique – exemple de la règlementation incendie

Dans le cadre de cette étude de faisabilité, environ 100 termes « règlementaires » ont été ainsi créés. La méthode mise en place a permis de traiter l’ensemble des

termes de la liste de réserve sans rencontrer de blocage ni laisser entrevoir d’impossibilité future.

Les langages utilisés

3.5.1 OPEN BIM : le choix des IFC

La maquette numérique et son cycle de vie représente ce que l’on appelle

aujourd’hui le BIM sans pour autant que cela ait la moindre conséquence sur les outils et les langages qui vont concrètement soutenir cette notion de BIM.

Au moment des choix techniques, il existe deux grandes catégories, les solutions propriétaires et les solution dites « ouvertes ». C’est vers ce dernier que nous nous orientons dans le cadre de cette étude de faisabilité.

La maquette numérique sera donc définie en langage IFC (Industry Foundation Classes) qui est un langage ouvert (open source) et dédié à l’échange d’information.

Cette précision signifie qu’il n’existe pas d’outil logiciel qui travaille de façon native avec les IFC mais beaucoup d’outils sont capable d’importer / exporter au format

IFC. Il est cependant nécessaire d’explicitement définir la façon dont l’information doit être portée par le format IFC afin d’aider les utilisateurs à paramétrer correctement leur fonction d’exportation des fichiers IFC. Cette définition explicite

des IFC attendues est dévolue au document s’intitulant « Cahier des Charges BIM » ou encore « Charte BIM ».

3.5.2 Le BIM sémantique : les standards du W3C

12

Cela a été évoqué dans le chapitre 3.4 consacré au vocabulaire, il a été très vite nécessaire de définir des « vocabulaires de jonction » pour assurer des

correspondances entre les concepts couverts par les IFC et les concepts manipulés dans les textes règlementaires. Pour cela, le CSTB s’est tourné vers les technologies

adéquates. Il s’agit des technologies que l’on appelle « sémantiques » et qui sont apparus, il y a quelques décennies, autour de la vision d’un Internet des

connaissances (par opposition à un internet des données). Les langages de référence en la matière sont multiples, le CSTB a choisi le RDF (Ressource description framework – standard ouvert du W3C) comme langage de description

des données. Le mécanisme de base en RDF est une assertion permettant d’exprimer qu’un « Objet1 » « Est_en_relation » avec un « Objet2 ».

RDF permet donc d’écrire des phrases simples de type « Sujet/Verbe/complément ». Les notions complexes s’expriment par composition de phrases simples et aboutissent à la construction de graphes comme illustré par

les figures 4 et 5 ci-dessous.

Figure 4 : Le triplet RDF

Figure 5 : Un graphe RDF -exemple d’une porte coupe-feu 1h

Il est à noter que depuis 2015, buildingSmart, l’association internationale qui gère notamment le langage IFC, propose une version « sémantique » des IFC et met à disposition un outil de transformation d’un fichier IFC en fichier RDF. Il est donc

possible de disposer d’une version « sémantique » RDF, miroir d’un fichier IFC.

13

Si le RDF permet de décrire les données, le W3C a développé un autre langage, appelé « SPARQL » qui lui permet d’interroger les données (écrites en RDF).

On parle alors de requêtes SPARQL dont le mécanisme consiste à parcourir les graphes RDF et recenser les objets d’un ou plusieurs triplets qui répondent à la

contrainte exprimée dans la requête.

Afin d’illustrer le processus de traduction de concepts de haut niveau, des exemples concrets ainsi que le temps passé à réaliser leurs traductions figurent en annexe 1.

4. BILAN SUR LES CHARTES BIM POUR LA CONSTITUTION DES

MAQUETTES NUMERIQUES ADAPTEES A LA SUPERVISION DE REGLES

Si l’on considère que, d’un point de vue utilisateur, le processus se déroule comme

illustré en figure 6 ci-dessous, alors les étapes majeures sont les suivantes :

Figure 6 : Les étapes du processus de vérification

1> La production de maquette numérique de bâtiment Cette étape, même si elle se trouve en dehors du champ de notre étude de

faisabilité, doit être considéré avec attention pour plusieurs raisons. A l’heure actuelle, il n’existe pas de logiciel permettant de travailler nativement en IFC, le

format IFC étant avant tout un format d’échange. Les utilisateurs doivent passer par une étape d’exportation de leur travail au format IFC ; cela demande une certaine expertise, notamment dans les règles de paramétrage de cette

exportation. 2> La vérification de la maquette

Comme mentionné au-dessus, l’obtention d’un fichier IFC (les IFC étant un format d’échange) se fait par une fonction d’export dans la plupart des logiciels de conception orienté Bâtiment. Cette fonction d’exportation est hautement

paramétrable et dépend également de l’état initial de la maquette. Le fichier IFC résultant d’un export doit être vérifié pour s’assurer qu’il est conforme aux

conventions définies dans la charte BIM. 3> Enrichissement Cette étape est transparente pour l’utilisateur, c'est une étape “système”. Il

s’agit de rajouter des informations à la maquette afin de la mettre au même niveau de vocabulaire que celui employé dans la règlementation. Par exemple,

dans la règlementation, il va être question de “dernier étage”, de “circulation

14

horizontale” : ces notions n’ont pas d’équivalence dans le langage de la maquette numérique. Il est nécessaire, non seulement de rajouter ces notions,

mais également d'indiquer les liens qui existent entre ces notions règlementaires et les entités de la maquette numérique. Cette liaison est réalisée en faisant

appel à des technologies dites sémantiques. 4> Contrôle règlementaire

C’est la dernière étape du processus. La maquette enrichie est confrontée à un ensemble de règles au travers d’un moteur de vérification. A l’issue du processus, un rapport d’analyse est généré indiquant les éléments pour lesquels

une non-conformité a été détectée.

5. BILAN SUR LE DEVELOPPEMENT DU DEMONSTRATEUR DE

SUPERVISION DE REGLES

Le démonstrateur du projet du PTNB sur la numérisation des règles vise plusieurs

domaines :

• Dans les cas d’usage en conception (réglementations accessibilité et

incendie), le démonstrateur permet, à partir de fichiers IFC conformes à la charte BIM, de repérer les non conformités sur la maquette numérique par

rapport à la réglementation.

• Dans les cas d’usage liés à la pose, le démonstrateur permet :

- pour le cas spécifique de la réglementation acoustique, une visualisation des étapes de mise en œuvre pouvant déboucher sur de la planification de

travaux, des informations techniques (fiches pathologies, guides pratiques, vidéos de démonstration, …), - pour le cas spécifique des DTU 25.41 et 25.42, un guide de choix des

matériaux selon le type de localisation de la cloison pouvant être associé à des catalogues produits.

• Dans le cas d’usage lié au référentiel E+C-, une partie des propriétés relatives

au cycle de vie des objets présents dans la maquette numérique (FDES, PEP, …) peut être reprise pour le calcul de l’indicateur carbone de l’ouvrage. L’exploitation de la maquette numérique et de sa constitution permet

d’envisager un calcul spécifique pour l’indicateur Energie (perte thermique dans les canalisations, ponts thermiques, …).

Les limites du démonstrateur

L’objectif du projet est d’explorer/investiguer la faisabilité d’un

démonstrateur permettant de vérifier l’absence de non-conformités des maquettes numériques par rapport à la réglementation.

Il ne s’agit pas de fournir un outil utilisable et exhaustif pour la vérification des maquettes numériques vis-à-vis des règles de construction.

% de règles traduites :

On estime une moyenne d’environ 30% des règles issues des cas d’usage prévus

traduite dans le démonstrateur ; les raisons sont les suivantes :

15

- Cas d’usage visant des situations précises (ouvrages définis, sujets issus des Groupes de travail souhaitant se focaliser sur les points les plus pertinents),

- Règles interprétables ou imprécises, - Nécessité d’avoir recours à des préprocesseurs de calculs annexes,

- Concepts de haut niveau nécessitant beaucoup d’analyse pour les traduire, - Foisonnement des cas abordés dans les textes (ex : DTU).

Cas particulier de la réglementation accessibilité : Plus de 90 % de la réglementation accessibilité relative au cas d’usage prévu a été

traduit. Le cas d’usage choisi porte sur les circulations intérieures horizontales, les circulations verticales et les sanitaires en ERP 5ème catégorie.

Foisonnement des cas abordés dans les règles :

Pour la plupart des règles, les textes ne décrivent pas un ouvrage donné mais donnent des préconisations de conception ou de mise en œuvre selon les cas

rencontrés (exemple : ERP de 5ème catégorie, pièces humides, passage de canalisations…). Il en résulte une multitude de possibilités de configuration d’ouvrages ; pour une couverture optimale du vérificateur de règles, un

développement informatique complet pour chaque règle abordée, adressant chaque type de configuration, devra être mis en œuvre.

Identification des non-conformités sur la maquette numérique :

Le rapport issu à la suite de la confrontation de la maquette au vérificateur de règles

contient une liste d’éléments non conformes. Les éléments non-conformes peuvent être directement localisés sur la maquette numérique.

Le rapport de non-conformités est disponible sous deux formats : l’un destiné à être lu (pdf), l’autre (bcf) à être ouvert dans un outil de visualisation de maquettes numériques, afin de pointer directement et graphiquement dans la maquette les

éléments de non-conformités. Un exemple de recherche et de visualisation des éléments non conformes est situé en annexe 3.

Les préconisations issues du projet PTNB- Numérisation de règles

Des règles structurées :

Les règles de construction doivent être rédigées de manière précise et non interprétables afin de pouvoir être confrontées à la maquette numérique. De

nombreuses règles existent (textes réglementaires, DTU, règles RAGE, …). Une structuration identique au moins pour chaque type de document permettrait de mieux hiérarchiser les exigences numériquement.

Des règles précises et non interprétables :

Dans la mesure où les règles de construction doivent être précisées, un groupe de travail peut être constitué par l’Etat pour définir les critères. Il est également possible de s’appuyer sur les comités déjà existants, identifiés et

représentatifs du monde de la construction : les commissions de normalisation du BNTEC, les comités de certification, les Groupes Spécialisés au sein de la

Commission Chargée de Formuler des Avis Techniques, ….

16

Exemple de la réglementation accessibilité – accès aux établissements :

Les dispositifs d’accès doivent être visibles : être contrastés par rapport à leur environnement immédiat. Cette caractéristique n’est pas exprimée par un critère

quantifié dans la réglementation. Elle a été néanmoins définie, par ailleurs, dans le cadre du règlement de certification QB Produits pour l’accessibilité et l’autonomie

relatif aux rampes d’accès. Ce critère a été validé par le comité particulier de la certification composé d’experts du domaine.

Dans la mesure du possible, nous préconisons une identification systématique des

zones de flou et des travaux réalisés sur ces sujets par des comités d’experts pour quantifier les critères qualitatifs exprimés dans la réglementation.

Une maquette numérique conforme à la charte BIM :

De même, la maquette numérique doit être construite selon une charte précise

permettant la confrontation au vérificateur de règles. Un outil permettant d’enrichir la maquette au format IFC selon la charte BIM applicable doit être utilisé et mis à

jour selon l’avancée des règles et des techniques logicielles. Un vocabulaire contrôlé et évolutif Franco BIM :

Outil créé pour le projet PTNB-Numérisation de règles, ce vocabulaire permet le passage de texte en langage naturel vers un concept ou un objet reconnu dans la

maquette numérique. Il s’affranchit du jargon « métier ». Il importe de maintenir et enrichir ce vocabulaire contrôlé. Sa mise à disposition, ainsi que le suivi de son évolution, pour tous les acteurs de la construction, par

exemple sur la plateforme KROQI, constitue la base de tout développement concernant le BIM.

Une adaptation des vérifications selon l’avancement de l’ouvrage :

La confrontation d’une maquette aux règles dépend également du niveau

d’avancement du projet de construction ; il importe de constituer une maquette adaptée aux besoins du projet, selon sa phase d’avancement, notamment pour en

réduire le traitement. Exemple : la hauteur d’une poignée de fenêtre sera à vérifier en phase DCE, lorsque les menuiseries seront choisies dans l’ouvrage.

Mode de preuves, traçabilité et responsabilités :

La maquette numérique constitue un ensemble d’informations. Ces informations font elles-mêmes appel à d’autres outils, extérieurs à la maquette (base INIES, catalogue produits, Calepins de chantier, guides pratiques, documents normatifs,

DTU, …). La maquette numérique, ses évolutions tout au long de la vie de l’ouvrage et ses

étapes de vérification vis-à-vis des règles constituent ainsi la carte d’identité d’un ouvrage. Ces éléments pourraient être utilisés pour la maintenance ou en cas de

litiges ou sinistres. Il importe d’en assurer la traçabilité et l’archivage. Qui en est responsable ? Qui peut en réaliser la mise à jour ? Comment en assurer l’intégrité, la conservation,

l’accès aux données ?

17

A ce stade, on peut envisager des investigations vers des technologies numériques prometteuses comme le BLOCKCHAIN.

On s’attachera par la suite à définir les rôles et responsabilités des acteurs de la construction, ainsi que d’en assurer la formation.

Evolution du vérificateur de règles et gestion de la configuration :

Le vérificateur de règles doit évoluer au même titre et au même rythme que les règles en question. Il comprendra notamment la date de vérification de la maquette, l’identification et le numéro de version de la maquette vérifiée et le numéro de

version des règles concernées.

Interactions de règles de construction pour la vérification :

L’interaction entre les règles de construction n’a pas été testée au travers du vérificateur de règles. Néanmoins, il a été identifié par les experts des zones sur

lesquelles les règles n’ont pas le même niveau d’exigences (exemple de l’éclairage des parties communes dans la réglementation accessibilité versus la réglementation

incendie). Une des potentialités de l’outil est de mettre en évidence ce type de divergence.

Interactions de règles de construction lors de leurs évolutions asynchrones :

Les règlementations de la construction constituent un assemblage de règles unitaires.

Dans le cas d’une évolution d’une des réglementations, l’approche développée dans

le projet PTNB Numérisation des règles peut servir à identifier les autres réglementations impactées.

Exemple : si la réglementation accessibilité évolue, quelles sont les autres réglementations impactées ? Pour tracer ces évolutions dans le vérificateur de règles, une indexation par règle

unitaire devra être opérée, par exemple selon l’annexe 2.

Vérificateur de règles de mise en œuvre – 4D :

Au travers du vérificateur des règles de mise en œuvre, par exemple par rapport à un DTU, l’exploitation des scénarii de pose permettent d’envisager une extension

4D, c’est-à-dire la création automatique d’une planification pour la réalisation d’un ouvrage. Cet élément rappelle notamment les étapes ainsi que la chronologie

indispensable à respecter (temps de séchage, …) conformément aux règles de l’art. Expression des règles sans texte, avec un schéma :

Rédiger les règles de construction de manière « spatiale », c’est-à-dire en utilisant des schémas ou des gabarits, permettrait de limiter les interprétations et traduction

de règles en langage formel. Il en résulterait une simplification de l’expression des exigences, en toute pédagogie. Cela revient à proposer des solutions types.

Exemple en réglementation accessibilité : Les escaliers doivent pouvoir être utilisés en sécurité par les personnes handicapées : proposer le schéma d’un escalier avec son giron, sa main courante, son dispositif d’éveil à la vigilance, …

18

Expression de règles spécifiques à l’aide d’un outil validé :

Afin de permettre la vérification de règles spécifiques, disposer d’un éditeur

permettant à tout un chacun d’exprimer ses propres contraintes à partir de contraintes unitaires existantes.

Cet éditeur serait relié au vocabulaire contrôlé, à ses évolutions et à sa grammaire. Il exploiterait la base des règles déjà formalisées et exécutables en permettant leurs

recombinaisons et paramétrages éventuels, voir figure 7 ci-dessous.

Il pourrait recourir à des outils et technologies basés sur l’intelligence artificielle afin de faciliter et optimiser le travail de transcription.

Figure 7 : Préconisation d’organisation pour généraliser la numérisation des règles

19

ANNEXES

Annexe 1 : Exemple de règles en MVDXML / temps de traduction

Annexe 2 : Premières réflexions sur un système d’indexation des règles

formelles et du vocabulaire

Annexe 3 : Illustration d’un scénario d’utilisation du démonstrateur

20

ANNEXE 1 : EXEMPLE DE REGLES EN MVDXML / TEMPS DE

TRADUCTION

Les estimations de temps à passer pour l’écriture des règles se basent sur le temps passé pour l’écriture des règles dans le cadre du projet PTNB NR et plus globalement

sur l’expérience acquise dans l’écriture de règles MVDXML au-delà du projet PTNB NR. Ces temps sont des estimations et peuvent donc fortement varier.

Les estimations tiennent compte : - du temps estimé à l’écriture de la règle en elle-même,

- du temps de test,

- du temps de modélisation : au-delà des maquettes de test livrées, il est

impératif de tester chaque règle sur des maquettes simples ne contenant

que les objets nécessaires. Cette modélisation est souvent complexe,

faisant appel à une maitrise des logiciels de CAO, au contournement de

leurs limitations d’export IFC et aux potentielles modifications manuelles

des maquettes exportées via des logiciels tiers ou des éditeurs de texte,

- du temps d’investigation sur les limites du moteur de règle.

21

Exemple du GT3 – Accessibilité :

Arrêté du 20 avril 2017 relatif à l’accessibilité aux personnes handicapées des établissements

recevant du public lors de leur construction et des installations ouvertes au public lors de leur

aménagement

GT3

Article/ Règle Temps passé (1/2 jours)

Pré - processeur

6.1 3,5

6.2 6,5

6.3 5

6.4 1 - Calcul largeur libre IfcSpace

6.5 2

6.6 1,25

6.7 3

7.1 0,5 - Calcul largeur entre mains courantes

7.2 0,5

7.3 0,5

7.4 0,5

7.5 9

7.6 3 - Hauteur garde-corps

7.7 0,5 - Calcul largeur entre mains courantes

7.8 2

7.9 0,25

7.10 3

7.11 1

7.12 0 - Calcul hauteur entre deux étages

12.1 0,5 - Vérification adjacence espace/wc - Vérification dimensions espace 12.2 0

12.3 0 - Vérification emplacement espaces - Compte Nb total sanitaires adaptés - Compte Nb sanitaires adaptés D/G 12.4 0

12.5 1

TOTAL GT3 44,5

22

ANNEXE 2 : PREMIERES REFLEXIONS SUR UN SYSTEME

D’INDEXATION DES REGLES FORMELLES ET DU VOCABULAIRE

1. OBJET DE CE DOCUMENT

Au cours du premier volet de la réalisation d’un démonstrateur de règles, les groupes d’experts ont réalisé un travail de reformulation en langage « semi-formel » d’une partie des textes technico-réglementaires écrit en langage naturel

sur la base d’un vocabulaire dit « contrôlé ». Ce vocabulaire se présentait sous la forme d’un listing structuré de termes en langue française dont il existe une

correspondance dans le langage de la maquette numérique, à savoir le langage IFC. A ce vocabulaire, il a été incorporé des termes permettant la structuration des

phases semi-formelles (comme par exemple l’expressions « Si ... Alors… »). Un éditeur de texte dénommé « Cuda Text », associé à une coloration syntaxique

et à une complétion des saisies correspondant au vocabulaire contrôlé, a été mis à disposition des groupes d’experts. Grâce à cet éditeur de texte, les membres des

groupes d’experts ont pu proposer une traduction de la règlementation en règles semi-formelles contenant des mots ou expressions du vocabulaire contrôlé.

Afin de permettre l’enrichissement du vocabulaire contrôlé mis à disposition initialement, il a été imaginé un processus entre les groupes de travail et les experts

BIM du CSTB afin de collecter régulièrement des notions manipulées par les groupes et dont ils n’auraient pas trouvé d’équivalence dans le vocabulaire de base. Ces termes et la sémantique associée étaient analysés par les experts du CSTB pour

déterminer si le terme candidat pouvait avoir une transcription directe en IFC ou si le terme recouvrait une notion plus complexe nécessitant un pré-traitement

spécifique de la maquette.

Suite à ce travail du groupe d’expert, les règles semi-formelles établies par les groupes d’expert ont été transformées en règles processables (Web Sémantique).

Un outil logiciel spécifique, appelé « moteur de règles » a été dévelopé afin de confronter ces règles avec des maquettes numériques de bâtiment (propriétés et

attributs des objets du modèles IFC). Ces règles processables ont été écrites dans le langage de requête SPARQL (SPARQL Protocol and RDF Query Language). Ces

fichiers SPARQL contiennent également le vocabulaire règlementaire dit « de haut niveau » défini entre les experts et le CSTB.

Sur la base des fichiers SPARQL créés dans le cadre de ce projet expérimental, il

apparait clairement que pour une règlementation donnée, il sera nécessaire de créer plusieurs dizaines de fichiers SPARQL. Dans l’objectif d’une numérisation quasi

complète de l’ensemble de la réglementation, cette base de fichiers sera conséquente. Pour faciliter la mise à jour de ces fichiers dans le cadre d’une modification de certaines parties de la réglementation, il est nécessaire d’élaborer

une indexation (via, par exemple, l’usage de méta données) des fichiers SPARQL. Cette indexation permettra ainsi de connaitre facilement quels sont les fichiers à

modifier lors d’un changement de tout ou partie d’une réglementation. C’est l’objet du présent document : proposer un système d'indexation des fichiers SPARQL pour en faciliter la maintenance en cas de mise à jour de la réglementation.

23

2. METHODOLOGIE

Le présent document propose un système d’indexation des fichiers SPARQL contenant des règles issues uniquement de la réglementation législative (textes de loi, arrêtés, décrets, circulaires, …) en se basant sur les travaux du GT3

(Accessibilité – ERP 5ème catégorie). De ce premier travail, un travail similaire pourra en découler pour définir un système d’indexation des fichiers SPARQL contenant des

règles issues de normes, de DTU ou d’autres textes non législatifs. L’indexation proposée est basée sur le « système NOR » et sur la notion de

« Légistique ».

3. LE SYSTEME NOR

L’ensemble des textes officiels français publiés depuis le 1er janvier 1987, sont

numérotés suivant le système normalisé de numérotation dénommé : NOR. Avant cette date, seuls les lois et les décrets obéissaient à un système de numérotation mis en place en 1941. Le système NOR vise à immatriculer tous les textes ayant

force obligatoire ou s’imposant au moins à l’administration. Font donc objet de la numérotation NOR :

• tous les actes publiés au Journal Officiel de la République Française, qu'il s'agisse de textes de portée générale ou de mesures individuelles ou collectives, avis, communications ;

• tous les actes de portée générale publiés dans les bulletins officiels des ministères.

La numérotation normalisée a pour objectif de faciliter :

• le repérage de tous les textes officiels dès leur première émission, afin d'assurer

un meilleur suivi de leur élaboration ;

• l'établissement de statistiques sur l'activité normative des administrations ;

• le classement rationnel de ces textes dans les divers fonds documentaires ;

• leur enregistrement et leur recherche dans les banques de données juridiques ;

• l'accès du public à ces textes.

Le NOR est composé de douze caractères alphanumériques :

• un code à trois lettres identifiant le ministère ou l'autorité administrative indépendante se trouvant à l'origine du texte. Ce code est fourni par une table

de codification interministérielle dont la mise à jour est assurée par le secrétariat général du gouvernement ;

• une lettre identifiant la direction ou le service le plus directement intéressé par

le texte. Chaque ministère ou autorité administrative indépendante établit et tient à jour la liste codée de ces directions ou services ;

• deux chiffres pour identifier l'année de la mise à la signature du texte ;

24

• cinq chiffres identifiant un numéro d'ordre, pris dans une séquence propre à chaque responsable de l'attribution du NOR au sein du ministère ou l'autorité

administrative indépendante concerné ;

• une lettre pour identifier la nature du texte parmi les suivantes :

1. A : Arrêté 2. B : Tableau (d'avancement, des ouvertures de crédits…)

3. C : Circulaire 4. D : Décret 5. E : Exequatur

6. G : Remise de lettres de créance 7. J : Instruction

8. K : Liste 9. L : Loi 10. N : Note de service

11. P : Rapport 12. R : Ordonnance

13. S : Décision (Conseil constitutionnel, autorités administratives, etc.) 14. T : Citation à l'ordre de la Nation 15. V : Avis (homologation et annulation de normes, concours et vacance

d'emploi, etc.) 16. W : Réponse ministérielle

17. X : Autres textes (délibérations, règlements, saisine du Conseil constitutionnel, observations du Gouvernement)

18. Y : Lettre-circulaire

19. Z : Rectificatif

Exemples :

• Les travaux du groupe d’experts GT3 (Accessibilité – ERP 5ème catégorie) sont basés sur l’arrêté du 20 avril 2017 relatif à l’accessibilité aux personnes handicapées des établissements recevant du public lors de leur construction

et des installations ouvertes au public lors de leur aménagement. Cet arrêté est appliqué depuis le 1 er juillet 2017. Son numéro NOR est : LHA L 17

04269 A (Arrêté émit en 2017, portant le numéro 04269).

• PRM G 85 00001 C = Circulaire du Premier ministre, émanant du secrétariat général du Gouvernement, émise en 1985 et portant le numéro 1

La numérotation NOR d’un texte officiel est donc l’identifiant unique de ce

texte. Cette identification unique suivant la numérotation NOR peut-être complétée par

des identifications liées à des dates. Un texte législatif est associé aux dates suivantes :

• Date du texte • Date de mise en application (date en vigueur)

• Date de publication au Journal Officiel

Elle peut également être complétée par le numéro au Journal Officiel (numéro

JORF).

25

4. CONTENU D’UN TEXTE OFFICIEL : LA LEGISTIQUE

La légistique est l’ensemble des méthodes et conventions de rédaction des textes normatifs. Un guide de légistique officiel a été élaboré par le Conseil d’État. Ce guide a pour objet de présenter l’ensemble des règles, principes et méthodes qui doivent

être observés dans la préparation des textes normatifs : lois, ordonnances, décrets, arrêtés. La troisième édition de ce guide est téléchargeable en format PDF ou ePUB

sur : https://www.legifrance.gouv.fr/Droit-francais/Guide-de-legistique2 Le chapitre 3.2.2 de ce guide décrit les éléments constitutifs d’un texte (c’est à dire

l’ensemble des divisions possibles d’un texte réglementaire) :

L’unité de base d’un texte est l’article. Un article peut comporter parfois plusieurs subdivisions précédées chacune d’un chiffre romain : I, II, III. Un article (ou une subdivision) peut comporter plusieurs alinéas. Constitue un alinéa

toute phrase, tout mot, tout ensemble de phrases ou de mots commençant à la ligne, précédés ou non d’un tiret, d’un point, d’une numérotation ou de guillemets,

sans qu’il y ait lieu d’établir des distinctions selon la nature du signe placé à la fin de la ligne précédente (point, deux-points ou point-virgule). Un tableau constitue

un seul alinéa. Une règle numérisable est par conséquent un alinéa.

Les articles peuvent être sont regroupés en titres/chapitres/sections. Les sections

peuvent être subdivisées en sous-sections. La section ou la sous-section peut être divisée en paragraphe et en sous-

paragraphe. Cependant, le guide préconise d’éviter cette utilisation des paragraphes et des sous-paragraphes.

Un texte peut donc être divisé en : • Titre (1er, 2ème, 3ème , …)

• Chapitre (I, II,, III, …) • Section (1, 2, 3, …)

• Sous-Section (1.1, 1.2, 1.3, ..) • Paragraphe (pas de numérotation)

• Sous-Paragraphe (pas de numérotation)

• Article (1, 2, 3, …) • Subdivision d’article (1.1, 1.2, 1.3,

…) • Alinéa (pas de

numérotation)

L’arrêté du 20 avril 2017 relatif à l’accessibilité aux personnes handicapées des

établissements recevant du public lors de leur construction et des installations ouvertes au public lors de leur aménagement contient des articles subdivisés en sous-articles et contenant des alinéas. Il ne contient pas de titre, de chapitre, de

section. La règle « Un palier de repos est nécessaire en haut et en bas de chaque plan incliné

quelle qu’en soit la longueur. En cas de plan incliné de pente supérieure ou égale à 4 %, un palier de repos est nécessaire tous les 10 m » est :

26

Le deuxième alinéa de la subdivision « Profil en long », de la subdivision « 2° Caractéristiques dimensionnelles », de la subdivision « Caractéristiques minimales

: », de l’article II (Dispositions relatives aux cheminements extérieurs).

5. LIAISON ENTRE LES TEXTES MODIFIES

Deux cas sont possibles :

1er cas : un texte de loi dont certains articles sont modifiés (ou créés) par un

nouveau texte de loi (ou par plusieurs textes de loi). Ce nouveau texte (ou ces nouveaux textes) contient(contiennent) des alinéas spécifiant les articles modifiés et le contenu de la modification. Il(s) ne contient(ent) pas les alinéas non modifiés.

Sur le site www.legifrance.gouv.fr une version consolidée contenant le texte complet modifié est publiée.

Pour l’indexation des fichiers SPARQL, il est proposé de garder le numéro du NOR d’origine avec la date du premier texte et les numéros NOR et les dates de tous les textes modificatifs.

2nd cas : un nouveau texte remplace l’intégralité d’un ancien texte. Dans ce cas, le nouveau texte a un nouveau numéro NOR et une nouvelle date de texte. Les deux

textes sont indépendants. Le nouveau texte annule et remplace (abroge) la totalité de l’ancien texte.

En résumé :

Les articles d’un texte sont modifiés (ou créés) par un ou plusieurs autres textes, le premier texte avec les modifications reste en vigueur. Exemple :

https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000276738&dateTexte=20180426

Un texte (et tous ses articles) est abrogé par un nouveau texte : exemple : https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000821682&dateTexte=20170630

6. INDEXATION D’UN FICHIER SPARQL

Nous partons du principe qu’un fichier SPARQL élaboré dans le cadre du projet

« Numérisation des règles », contient une seule règle correspondant à un alinéa d’un texte règlementaire. Cet alinéa est rattaché à un article (ou sous-article

rattaché à un article) lui-même rattaché aux éléments supérieurs de l’arborescence. L’indexation d’un fichier SPARQL proposée consiste à intégrer en début de fichier,

par exemple sous forme de commentaires, les références (méta données) suivantes :

• Numéro NOR

• Date du texte (D<date>)

• Listes des numéros NOR des éventuels textes modificatifs (pour l’article concerné par le fichier, sinon vide)

27

• Dates des textes modificatifs (pour l’article concerné par le fichier, sinon vide)

• Numéro de titre précédé de la lette T ou T0 si pas de titre

• Numéro du chapitre précédé de la lette C ou C0 si pas de titre

• Numéro de la section précédé de la lette S ou S0 si pas de section

• Numéro de la sous-section précédé de la lette R ou R0 si pas de sous-section

• Numéro de l’article précédé de la lette A

• Numéro du sous-article article précédé de la lettre B ou B0 si pas de sous-article

À noter que les alinéas (correspondant à des règles numérisables) ne sont pas

numérotés. Un complément à l’indexation proposée consisterait à numéroter tous les alinéas du texte réglementaire et à intégrer ce numéro dans le fichier SPARQL.

28

ANNEXE 3 : ILLUSTRATION D’UN SCENARIO D’UTILISATION DU

DEMONSTRATEUR

Analyse des propriétés des matériaux « stables au feu 1h » dans le cadre de la réglementation incendie

1. Se connecter sur la plateforme KROQI

29

2. Choisir un fichier IFC d’une maquette numérique dans son espace de travail et lancer le service

3. Choisir le service de contrôle

30

4. Synchroniser le fichier de la maquette numérique

5. Choisir le protocole de contrôle souhaité

31

6. Le résultat du contrôle s’affiche

7. Enregistrer le fichier IFC contrôlé

32

8. Ouvrir le fichier IFC contrôlé

9. Les anomalies sont repérées sur le fichier

33

10. Sélectionner et visualiser l’anomalie