Le building operating system est un concept séduisant : à l’instar d’un iOS ou d’un Android, il s’agit de disposer d’un système d’exploitation pour articuler tous les systèmes ou équipements du bâtiment. Un système pour les gouverner tout en somme. Pourtant, lorsque l’on regarde au-delà de nos frontières, le concept n’existe que très timidement et aucun produit ne s’impose. Le concept de BOS est à rapprocher dans le monde anglo-saxon de celui de « plateforme d’intégration ». Wikipedia ignore le concept de BOS. Pourtant, en France, Sensinov, SpinalCom ou encore Vayandata ont une certaine visibilité. Faut-il croire au BOS ?
1. Le BOS : un concept français pour décrire un logiciel de type « middleware »
La fonction principale d’un OS (operating system ou système d’exploitation) est celle d’intermédiaire, entre d’une part des logiciels et d’autre part un matériel informatique (smartphone, PC,…), pour gérer les demandes de ressources de ces logiciels (stockage, calcul,….). Or, la fonction principale d’un BOS est de faire dialoguer des logiciels entre eux. Le BOS est une analogie au concept d’OS mais il ne correspond pas, stricto sensu, à une logique de système d’exploitation :
- En revanche, le BOS fait le lien entre différents systèmes.
Le BOS n’est donc pas un OS mais un middleware, c’est-à-dire un logiciel qui crée un réseau d'échange d'informations entre différents systèmes informatiques. Il permet de décloisonner des systèmes souvent installés en local (système de GTB, de contrôle d’accès,…) pour les rapprocher d’application souvent Cloud (GMAO, IWMS, système de réservation, …).
2. Encore beaucoup d’incertitude sur le modèle d’avenir…
Le BOS vise l’interopérabilité en permettant aux différents systèmes de dialoguer. Mais l’interopérabilité ne suffit pas si chaque système a son propre référentiel. Pour croiser une alarme de la GTB avec une demande d’intervention gérée dans l’outil de maintenance, il faut que les deux systèmes nomment les équipements et les locaux concernés par l’alarme de la même manière. Pareillement, la dénomination d’une salle dans le calendrier Outlook, dans l’outil de maintenance et dans la GTB doit être la même.
Le choix opéré par un acteur comme SpinalCom est de s’appuyer sur la maquette BIM pour créer l’ontologie (c’est-à-dire le modèle de données avec ses règles de nommage et ses relations entre tous les éléments qui composent un bâtiment).
Mais l’ontologie fondée sur le BIM présente certaines limites. D’autres se sont ainsi développées indépendamment du BIM. Les principales sont Project Haystack et Brick Schema, mais RealEstateCore qui est utilisé par Microsoft Azure Digital Twins (plateforme de conception de jumeaux numériques utilisée par ProptechOS et Willow) pourrait gagner du terrain tandis que Digital Buildings Project de Google semble plus isolé.
Aujourd’hui, les bâtiments bénéficiant d’une maquette BIM sont une infime minorité dans le parc existant et les ontologies Project Haystack et Brick sont naturellement bien plus représentées dans le smart building (plusieurs dizaines de milliers de sites pour project Haystack). Un alignement entre le standard IFC (utilisé pour le BIM) et les ontologies ci-dessus serait évidemment souhaitables mais il n’est pas encore réalisé pour toutes. En revanche, ces différentes ontologies sont pour certaines compatibles entre-elles.
3. Attention de ne pas céder aux sirènes du BOS tout-en-un
Certains BOS intègrent, en complément de leurs fonctionnalités d’intégration (c’est-à-dire « de middleware »), des fonctionnalités correspondant à d’autres catégories de logiciel du marché (GMAO, Digital twin, IWMS…) ce qui contribue à créer de la confusion sur le positionnement de ces BOS.
Mais cette approche est contradictoire avec le principe même d’un middleware qui permet de choisir les meilleurs logiciels de chaque catégorie sans se préoccuper de leur intégration car le BOS s’en chargera. Choisir des logiciels « inclus dans le package » revient à se priver d’une approche « best of breed » qui constitue pourtant un intérêt fort d’une architecture s’appuyant sur un middleware de type BOS. Il serait dommage de décevoir les utilisateurs par un logiciel « inclus dans le package » mais qui serait en dessous des standards du marché.
Choisir les meilleures solutions informatiques dans leur catégorie plutôt que de se tourner vers un progiciel généraliste.
4. L’hypercentralisation dans un BOS n’est pas nécessairement l’architecture informatique offrant le meilleur ROI
Considérer le BOS pour ce qu’il est réellement d’un point de vue informatique (un middleware) est fondamental pour bien concevoir l’architecture : un OS impose une centralisation de l’architecture (toutes les applications d’un Iphone fonctionnent sur iOS) tandis qu’un « middleware » est un outil de rationalisation de l’architecture qui ne présuppose pas de l’architecture à mettre en place.
Les bonnes pratiques d’architecture informatique doivent donc guider la réflexion et il n’est pas nécessaire de faire du BOS l’unique nœud d’interopérabilité entre les systèmes. Ainsi, lorsque 2 systèmes communiquent nativement, il n’est pas nécessaire de positionner le BOS en intermédiaire. Le partage des données via le BOS ne doit être prévu que lorsque des usages de ces données dans d’autres systèmes sont identifiés. Prévoir le partage de toutes les données « au cas où » est une solution bien couteuse qui trop souvent élude le véritable débat : quels sont les usages que devra servir le BOS ? Et donc in fine, quelle sera sa valeur ?
Pour une stratégie et une organisation optimales dans un environnement de travail hybride, explorez nos services d'Assistance à Maîtrise d'Ouvrage (AMO). Nous vous aidons à choisir et à implémenter les meilleures solutions pour votre entreprise
5. Le BOS n’a de valeur qu’au travers des usages qui résultent de la combinaison des systèmes
Recourir à une solution pour distribuer un référentiel immobilier unique sur lequel chacun des systèmes pourra s’appuyer est un atout important. Toutefois, il existe des moyens de partager un référentiel immobilier sans recourir à un BOS. Par ailleurs, on l’a vu ci-dessus, il existe quelques incertitudes sur le modèle de données d’avenir pour gérer ce référentiel immobilier dans un BOS. La différence que le BOS peut créer résultera donc plutôt de sa capacité à faire interagir des systèmes différents.
L’interopérabilité peut apporter confort et performance énergétique grâce aux automatismes du bâtiment. Pour autant les systèmes ouverts de Gestion Technique du Bâtiment (GTB) comme Distech Controls couvrent déjà ce besoin. En revanche, dans un contexte où le système de GTB est moins ouvert, le BOS permettra de réaliser l’interopérabilité. Mais attention aux coûts qui seront imposés par les acteurs historiques de la GTB pour ouvrir leur API.
Les véritables usages du BOS résultent plutôt de sa capacité à réunir deux mondes. D’une part celui des systèmes du bâtiment (GTB, IOT, GTC,…) qui a ses propres intégrateurs et qui est très lié à des équipements physiques. Et, d’autre part, celui des systèmes d’information (GMAO, IWMS, application immeuble, système de réservation,…). Il est donc opportun d’imaginer les usages résultant d’une combinaison de ces systèmes en prenant l’angle de vue de chaque partie prenante du bâtiment : les occupants, la direction immobilière, la direction de l’environnement de travail, les prestataires du bâtiment,…
Une fois ces usages impliquant de combiner plusieurs systèmes identifiés, il faudra qualifier l’opportunité de leur mise en œuvre. À titre d’exemple, faire en sorte que certaines alarmes déclenchent un processus de maintenance curative dans une GMAO ou un IWMS (automatisation du ticket) est utile. Pour autant, cela ne fera qu’alléger la tâche du mainteneur et il parait difficile de justifier l’investissement dans un BOS par la réduction de quelques tâches qui incombent à un prestataire multitechnique...
Le BOS est un sujet nécessitant une réflexion approfondie au risque de dépenser beaucoup d’argent dans une architecture qui n’apporte que peu de valeur. L’effet wahou ne suffira pas à justifier la facture : le BOS doit apporter une véritable valeur ajoutée ! Pour faire les bons choix, les équipes d’AREMIS sont là pour vous guider.
ÉCRIT PAR
Après plus de 15 ans d’expérience auprès de certains des plus grands acteurs du marché immobilier, j’ai compris une chose sur mes clients.
Plus que tout, ils ont besoin de quelqu’un qui écoutera leurs besoins et les aidera à prendre les bonnes décisions
