Le schéma précédent illustre l'évolution proposée et en cours vers le bâtiment digital. Nous passons d'une vision "silotée" de la gestion des applications et des données (à gauche) à une vision "convergente" (à droite). Ce qui converge dans cette vision cible du bâtiment digital, c'est l'infrastructure digitale du bâtiment. Cette infrastructure est composée de deux éléments :

• Une infrastructure "physique" convergente : le réseau IP d'infrastructure du bâtiment qui constitue le réseau de nerf du bâtiment intelligent

• Une infrastructure "logique" convergente : le modèle de synthèse représentatif du bâtiment, le jumeau numérique, géré par le système d'exploitation du bâtiment, le Building Operating System (BOS) qui constitue le centre nerveux du bâtiment et qui assure la gouvernance des données (fonctions de "moelle épinière" du bâtiment pour prolonger la métaphore avec le corps humain).

La mise en place de cette infrastructure convergente est un élément essentiel pour la digitalisation du bâtiment (et de tout autre système physique intelligent). Elle permet de séparer concrètement les couches physiques et logiques. Ceci facilite et rend plus économique le développement d'une multitude d'applications digitale (logiques) de qualité car d'une part il devient possible de développer de nouvelles applications sans déployer de nouveaux équipements dédiés (les données des capteurs existants peuvent être réutilisées) et d'autre part il n'est pas nécessaire d'apprendre et de formaliser une nouvelle description du bâtiment à chaque déploiement d'une nouvelle application. Le jumeau numérique fournie la description à jour, homogène et de qualité à chaque nouvelle application déployée.

Nous préconisons donc un principe d'architecture de système d'information en trois couches :

• la couche logique IT : les applications digitales offrant un véritable service à valeur ajouté

• la couche d'infrastructure convergente IT / OT / BIM : le réseau IP dus bâtiment, les Building Operating system (BOS) et le jumeau numérique

• la couche physique OT : les capteurs, actionneurs, automates... du bâtiment

Un point important pour réaliser concrètement cette architecture intelligente est que l'ensembles des éléments composant les couches physiques et logiques puissent échanger leur données de manière compréhensible. Il faut pour cela que l'ensemble des systèmes OT et des applications IT fournissent leur "dictionnaire", ce qui permettra de construire les connecteurs avec la couche d'infrastructure. Ce "dictionnaire" est ce que nous appelons une API en informatique (Application Programming Interface).

Le bâtiment digital doit être capable de mettre en œuvre un grand nombre d'applications, de systèmes d'informations... qui sont autant de sources de données différentes, comme le montre la partie "data source" du premier schéma. Historiquement fermée, la grande majorité des systèmes du bâtiment commence à s'ouvrir en communiquant sur un réseaux IP et en fournissant des API ouvertes et documentées. La SBA (Smart Building Alliance) a joué un grand rôle en ce sens.

Cette ouverture est très importante mais elle n'est pas suffisante. Des difficultés persistent liées à la profusion des API de natures différentes ou à la diversité et l'hétérogénéité des points d'accès...

Les BOS et le jumeau numérique permettent d'unifier et de rationaliser l'ensemble :

• Le jumeau numérique apporte le modèle de données de synthèse unifiant et contextualisant les données du bâtiment en termes de description, d'état, d'historique et de comportement.

• Le BOS est le logiciel de gestion de la base de données du jumeau numérique qui orchestre les échanges de données avec les autre systèmes et met en œuvre une API unifiée simplifiant le développement d'applications

• L'API unifiée rationalise et facilite le développement d'applications en offrant un point d'accès unique et sécurisé à l'ensemble des données du jumeau numérique, quelle que soit sa source initiale

Le jumeau numérique et l'API unifiée du bâtiment font entrer le bâtiment dans l'ère du digital et dans les "canons" de l'IT.

Le projet digital organise la mise en place d'une infrastructure physique convergente (réseau IP), d'une infrastructure de gouvernance des données (BOS & jumeau numérique) et d'une "API unifiée du bâtiment" qui permet le déploiement de nombreuses applications digitales avec un haut niveau de qualité. Cette architecture permet l'évolutivité digitale du bâtiment sur tout son cycle de vie.

Bien sur, l'infrastructure ne suffit pas. Il faut livrer un bâtiment avec des applications déjà fonctionnelles qui apportent une valeur directe.

Il n'est cependant pas nécessaire de spécifier toutes les applications futures envisagées. C'est tout l'intérêt de la mise en place de cette infrastructure convergente et de ces principes. Toute application ou système qui respectera les principes et les chartes de données pourra être intégré au système d'information global par la suite (communication IP, API ouvertes, partage de référentiels communs de données...).

Nous vous conseillons de préparer un tableau d'applications de base à déployer pour la livraison et un autre tableau facultatif présentant les applications et cas d'usages qui pourront être envisagés par la suite. Les listes de cas d'usage à rallonge n'apportent pas de valeur à la réponse et la rende souvent confuse.

Il faut comprendre qu'aucune entreprise, même les plus grandes, n'est en capacité de fournir tous les services digitaux du bâtiment dans une seule plateforme. Le système d'information final construit sera donc composé d'un écosystème d'applications venant d'éditeurs différents mais qui peuvent collaborer entre elles grâce à l'infrastructure commune de gouvernance des données mise en place (BOS, jumeau numérique et API).

"Dé-siloter" les applications, les rendre "compatibles"... la traduction technique de ces termes implique qu'il doit y avoir concrètement un partage, un échange des données entre les applications. Le lot smart doit donc permettre de répondre à deux écueils :

1. Quels échanges de données doivent être mis en place ?

2. Comment des applications qui ne parlent pas la même langue peuvent-elles se comprendre ?

Pour répondre à la première question, une " fiche données" doit être mise en place. Cette fiche liste pour chaque cas d'usage prévu (application), les grands jeux de données qui lui sont utiles. Cette fiche permet de visualiser les interactions importantes entre applications et données et donc de comprendre quels sont les jeux de données communs et mutualisés entre de nombreuses applications.

Dans le cadre du bâtiment, deux jeux (ou plus) de données ont une grande importance et doivent être mutualisés, nous les appelons des référentiels partagés :

• L'annuaire des occupants du bâtiment, souvent partagés entre l'ensemble des applications rendant des services aux occupants. Par exemple, le système LDAP géré par la DSI a cette comme fonction de maintenir, de partager et de jouer le rôle de tiers de confiance pour le référentiel occupant.

• La description du bâtiment, dont toutes les applications fonctionnant sur bâtiment ont besoin pour décrire les espace, les pièces, les équipements... Le BOS a comme première fonction de maintenir, de partager et de jouer le rôle de tiers de confiance pour le référentiel de description du bâtiment.

Pour répondre à la deuxième question il existe deux solutions :

• Version "spaghettiware" : faire des traductions deux à deux entre application. C'est long, cher et difficile à maintenir !

• Version "middleware" : mettre en place un langage et des modèle de données commun (un jumeau numérique). Soit chaque application s'adapte à ce langage commun, soit elles fournissent leur traducteur avec le langage commun. Une architecture digitale du bâtiment reposant sur un BOS suit ce principe.

La "fiche data" et le "tableau des connexions" sont deux outils simples et concret qui permettent de lister et comprendre ces liens entre application (Fiche Data et tableau des connexion )

Faire du bâtiment digital, c'est coupler deux expertises, deux mondes :

• le monde du bâtiment avec son jargon et ses termes

• le monde du digital avec son jargon et ses termes

Ce couplage donne une clé de lecture pour un grand nombre de termes que nous employons. Tous les nouveaux acronymes son un assemblage de termes venant de chaque monde. Voici quelques exemples pour mieux comprendre :

• BOS est un couplage entre "Building" (terme du bâtiment) et Operating System (terme du digital)

• BDOE est un couplage entre BD (Base de Données) et DOE (Dossier des Ouvrages Exécutés)

Les autres acronymes sont le plus souvent des termes existants, qui ont un sens dans chacun des domaines :

• Bâtiment : GTB, GMAO, BIM, IWMS, SSI....

• Digital : SGBD, OS, SI, API, Data management, API Management, IP...

C'est pourquoi nous préconisons un rapprochement fort entre experts du bâtiment et experts du digital.