Pour de nombreuses organisations, la fin d’un projet de construction marque le début d’une phase tout aussi importante : assurer une exploitation efficace du bâtiment pendant les 20, 30, voire 50 années à venir.

À ce stade, une quantité considérable d’informations numériques a déjà été produite. Les propriétaires peuvent recevoir des maquettes BIM au format natif, des fichiers IFC, des plans CAO, des inventaires d’équipements, des manuels d’exploitation, des feuilles de calcul et de la documentation technique. Sur le papier, tout semble donc réuni pour assurer une bonne exploitation du bâtiment.

Pourtant, il reste souvent à identifier les équipements, à associer les documents correspondants, à harmoniser les conventions de nommage des locaux et des équipements techniques ou encore à compléter les informations manquantes. Une question aussi simple que « Quel équipement est installé ici et où se trouve sa documentation de maintenance ? » peut nécessiter de consulter plusieurs sources.

Le problème vient donc rarement d’un manque de données. Il tient plutôt au fait que les informations créées pour la conception et la construction ne présentent pas automatiquement la structure nécessaire à l’exploitation du bâtiment sur le long terme.

Quels formats et quelles structures de données sont alors généralement transmis lors du passage à la phase d’exploitation ? Et lesquels sont réellement utiles une fois le bâtiment en service ?

Quels modèles de données du bâtiment sont utilisés lors de la livraison ?

La réponse ne consiste pas simplement à choisir entre IFC, Revit, CAO ou un autre format. Chacun répond à des besoins différents au cours du cycle de vie d’un bâtiment.

Un dossier de livraison peut notamment comprendre :

• Des maquettes numériques dans leur format natif, comme les fichiers Revit
• Des fichiers IFC (Industry Foundation Classes) pour l’échange de données selon un standard ouvert
• Des plans au format DWG ou dans d’autres formats CAO
• Des jeux de données COBie (Construction Operations Building information exchange)
• Des inventaires d’équipements, parfois tenus à jour dans des feuilles de calcul
• Des documents PDF, tels que des manuels d’exploitation, des certificats et des rapports d’inspection
• Des métadonnées décrivant les espaces, les éléments du bâtiment et les équipements techniques
• Des informations déjà enregistrées dans des systèmes CAFM, CMMS, ERP ou d’autres applications d’exploitation

Chaque source apporte un éclairage différent sur le bâtiment.

Une maquette Revit native conserve la structure et le niveau de détail propres au logiciel dans lequel elle a été créée. Le format IFC, quant à lui, offre une structure standardisée permettant d’échanger certaines informations de la maquette indépendamment du logiciel d’origine.

Les plans CAO (conception assistée par ordinateur), souvent fournis au format DWG, restent particulièrement importants pour les patrimoines immobiliers existants. Ils contiennent des plans d’étage et d’autres informations graphiques, mais ne disposent généralement pas de la même structure orientée objet qu’une maquette BIM.

Les données et métadonnées des équipements apportent une autre dimension : identifiants, classifications, caractéristiques techniques, informations sur les fabricants et localisation des équipements. Elles peuvent provenir d’une maquette ou être gérées séparément dans des inventaires, des bases de données ou des feuilles de calcul.

COBie est un schéma standardisé destiné à transmettre des informations structurées sur les bâtiments et leurs équipements. Il peut alimenter les processus d’exploitation sans nécessiter l’ensemble de la maquette graphique, mais ne remplace pas celle-ci et ne couvre pas toutes les informations utiles à l’exploitation.

Il n’est donc pas nécessaire qu’une seule source contienne toutes les données. L’essentiel est de savoir quelles informations sont disponibles dans chaque source et si elles peuvent être utilisées dans les processus d’exploitation concernés.

Plus de données ne signifie pas forcément de meilleures données pour l’exploitation

Une maquette détaillée peut contenir des milliers d’objets et de propriétés. Mais tous n’ont pas la même importance une fois le bâtiment en exploitation.

Pour de nombreuses activités quotidiennes, connaître la géométrie exacte de chaque composant est moins important que de pouvoir répondre à des questions telles que :

• Où se trouve l’équipement ?
• Quel équipement est précisément installé ?
• À quel système appartient-il ?
• Qui en est le fabricant ?
• Quand doit-il faire l’objet d’une maintenance ?
• Quels documents lui sont associés ?

Prenons l’exemple d’une centrale de traitement d’air. Sa maquette peut contenir de nombreux paramètres de conception qui étaient essentiels pendant les phases d’étude et de construction. Pour l’exploitation, les équipes chargées du bâtiment ont surtout besoin de son identifiant unique, de son emplacement exact, du fabricant et du modèle, de ses principales caractéristiques techniques, des exigences de maintenance et de la documentation associée.

Les identifiants des équipements doivent être cohérents entre les maquettes, la documentation et les systèmes d’exploitation concernés. Lorsqu’ils sont absents ou différents d’une source à l’autre, il peut être nécessaire de les rapprocher et d’établir les correspondances. La localisation doit permettre de rattacher chaque équipement au bon bâtiment, au bon étage et au bon local. Ses relations techniques peuvent également le situer dans un système ou un sous-système particulier. Des structures telles que bâtiment → étage → local → équipement ou système technique → sous-système → composant facilitent la navigation entre ces informations.

Ce principe ne se limite pas à la maintenance. La gestion des espaces repose davantage sur les numéros de locaux, les surfaces, les usages et les taux d’occupation. À l’échelle d’un portefeuille immobilier, le Corporate Real Estate Management (CREM) peut nécessiter des informations sur les bâtiments, les espaces, les surfaces, leur utilisation et d’autres caractéristiques immobilières.

Les données à transférer dépendent donc avant tout des processus qu’elles doivent alimenter. Cela ne signifie pas que les maquettes détaillées et les informations géométriques sont superflues. Les représentations visuelles et spatiales peuvent être particulièrement utiles pour localiser un équipement ou comprendre ses relations avec son environnement. En revanche, transférer systématiquement tous les éléments et paramètres disponibles dans une maquette apporte peu de valeur si une grande partie de ces détails n’intervient pas dans les processus d’exploitation.

Un jeu de données réellement utile à l’exploitation associe le niveau de détail géométrique approprié, des informations structurées sur les objets, leurs attributs et leurs relations. Selon les besoins, ces éléments peuvent provenir de différentes sources.

Comment réunir différentes sources de données pour l’exploitation ?

Les différentes sources d’information ne disparaissent pas une fois la construction terminée. Une maquette Revit peut rester utile lors de futures transformations. Le format IFC peut servir à transférer des informations entre systèmes. Les plans CAO peuvent demeurer la référence la plus pratique pour certaines zones du bâtiment, tandis que les données structurées sur les équipements alimentent les applications d’exploitation.

La véritable question est donc de savoir comment exploiter ces différentes sources sans devoir tout convertir dans un format unique.

Pour les professionnels qui travaillent avec les données du bâtiment, le contexte spatial peut constituer le lien entre ces informations.

Un technicien de maintenance, un gestionnaire immobilier ou tout autre professionnel du bâtiment n’a pas nécessairement besoin de savoir dans quel fichier une information était initialement stockée. Ce qui compte, c’est de pouvoir retrouver l’équipement ou l’espace concerné, comprendre de quoi il s’agit et accéder aux informations nécessaires.

Par exemple, en sélectionnant une pompe à son emplacement dans le bâtiment, il serait possible de consulter ses caractéristiques techniques, ses informations de maintenance et la documentation associée, quelle que soit la source d’origine de ces données.

C’est sur ce principe que repose speedikon VIP, qui rassemble des informations issues de différentes sources dans un contexte spatial commun. Les représentations d’origine peuvent rester disponibles, tandis que les informations sont mises en relation avec le bâtiment physique et les équipements qu’il contient.

L’objectif n’est donc pas de créer un format de données universel, mais de rendre les bonnes informations accessibles, compréhensibles et utiles dans le contexte où elles sont nécessaires.

Le modèle de données adapté dépend des processus qu’il doit prendre en charge. Si vous réfléchissez à la manière de transférer les données de vos bâtiments vers les systèmes d’exploitation, nous serons ravis de partager notre expérience avec vous.