Illustration générée par IA — visuel conceptuel.
À quoi sert vraiment une ontologie en exploitation multi-sites ?
Dans un parc de bâtiments (bureaux, retail, hôtellerie, sites industriels légers…), la “liste de points” GTB/BMS ne tient pas longtemps : un même capteur peut être nommé différemment selon l’intégrateur, l’automate, la zone, ou la période de rénovation. Le problème n’est donc pas seulement d’accéder aux données, mais de savoir ce que chaque donnée représente (température d’air soufflé, consigne, état de marche, énergie, etc.) et comment elle se relie au reste (équipement, espace, zone, système).
Un modèle sémantique (souvent appelé “ontologie” par extension) sert à rendre ces données :
- interopérables (mêmes concepts d’un site à l’autre),
- requêtables (retrouver “tous les points de telle nature”, “tous les équipements alimentés par…”, etc.),
- maintenables (gouvernance, évolution, recette) pour réduire les coûts de “jour 2” : tout ce qui arrive après la mise en service (correction des mappings, onboarding de nouveaux sites, refonte partielle d’un lot technique, changement d’exploitant, etc.).
Ce guide compare deux approches très répandues dans l’écosystème Smart Building : Brick Schema et Project Haystack, avec un angle décisionnel (AMO, DSI immobilier, gestion multi-sites).
Brick et Haystack : définitions utiles (selon les textes officiels)
Brick : ontologie (classes + relations) représentée en RDF
Brick se décrit comme un schéma de métadonnées basé sur une ontologie, qui capture les entités et relations nécessaires pour représenter un bâtiment et ses sous-systèmes, afin de permettre une exploration programmatique. (Voir : Brick Ontology Documentation — Design Principles)
Dans Brick, le modèle prend la forme d’un graphe représenté avec le modèle RDF. (Voir : Brick Ontology Documentation — Core Concepts)
Haystack : un “stack” open source (types, formats, API, ontologie, defs)
Project Haystack se présente comme une suite open source pour modéliser des données IoT : types de données, formats de fichiers, HTTP API, ontologie et mécanisme de Defs pour définir/étendre le vocabulaire. (Voir : Project Haystack — Introduction)
Le point qui change souvent la décision : “tags vs ontologie”
Haystack : dicts + tags, avec des “markers” pour typer
Dans Haystack, la collection principale est le dict (dictionnaire) : un ensemble de paires nom/valeur, appelées tags. Les entités (bâtiments, capteurs…) sont modélisées comme des dicts, et les tags informent le type et les faits à propos de l’entité. (Voir : Project Haystack — Introduction)
Haystack définit aussi les markers : des tags sans valeur, dont la présence est sémantiquement significative, utilisés notamment pour typer un dict (ex. marker site). (Voir : Project Haystack — Introduction)
Brick : des tags existent, mais le typage ne repose pas sur les tags seuls
Brick utilise aussi des tags (faits atomiques) et indique emprunter ce concept à Haystack pour la flexibilité, mais précise qu’il ne s’appuie pas uniquement sur les tags pour déterminer le type d’une entité. (Voir : Brick Ontology Documentation — Core Concepts)
La conséquence n’est pas “meilleur vs moins bon” : c’est un choix de posture. Si vous voulez privilégier une modélisation en graphe (classes + relations explicites), Brick pousse naturellement vers une logique RDF/ontologie. (Voir : Brick Ontology Documentation — Core Concepts) Si vous voulez un modèle directement manipulable comme des dicts/tags (et industrialisable via defs), Haystack est cohérent avec une approche pragmatique “tag-first”. (Voir : Project Haystack — Introduction)
Comparatif orienté décision (interop, analytics, multi-site, équipes, “jour 2”)
Repères rapides (lecture en survol)
| Critère de décision | Brick Schema | Project Haystack |
|---|---|---|
| Forme du modèle | Graphe RDF (ontologie : classes + relations) | Dicts + tags (markers pour le typage) |
| Ce qui est “standardisé” en premier | Le sens (concepts) et les relations (structure exploitable en graphe) | Un stack : types, formats, HTTP API + sémantique via Defs |
| Relations “métier” documentées | Relations explicites (ex. hasPoint, hasLocation, feeds) |
Deux niveaux complémentaires :
(Voir : Project Haystack — Introduction ; Project Haystack — Defs) |
| Inférence (raisonnement) | Documentée (profil OWL 2 RL) | Associations indiquées comme activant l’inférence lors des requêtes de connaissance |
| Gouvernance / évolutivité | Versionnement documenté via owl:imports vers un IRI versionné |
Organisation du vocabulaire via Defs (vocabulaire/taxonomie/ontologie) et libraries |
Note : ce tableau résume des différences de posture issues de la documentation officielle ; il ne remplace pas un pilote sur votre parc (outillage, compétences, intégrations).
1) Interopérabilité : quel “contrat” standardiser en premier ?
Si votre priorité est l’échange inter-systèmes (format + API + conventions), Haystack met en avant un stack incluant des formats et une HTTP API (au sein du périmètre documenté “Data Types / File Types / HTTP API”). (Voir : Project Haystack — Introduction)
Si votre priorité est le sens + les relations (reconstituer une “structure de bâtiment” exploitable en graphe), Brick est explicitement conçu pour capturer entités et relations, et documente un ensemble de relations utiles à l’exploitation : brick:feeds (topologie amont/aval), brick:hasLocation (localisation), brick:hasPoint (télémétrie liée à un équipement), etc. (Voir : Brick Ontology Documentation — Relationships)
2) Analytics multi-sites : capitaliser sur des requêtes réutilisables
Les cas d’usage qui “scalent” (energy analytics, commissioning continu, benchmark multi-sites, maintenance conditionnelle) reposent souvent sur des requêtes transverses :
- retrouver tous les points d’une famille (ex. températures “air”, consignes, états),
- relier points → équipements → zones → sites,
- comprendre des chaînes amont/aval (qui alimente qui),
- regrouper des sous-systèmes comparables d’un bâtiment à l’autre.
Brick documente l’inférence/raisonnement et indique utiliser le profil OWL 2 RL. (Voir : Brick Ontology Documentation — Inference and Reasoning) Dans un projet, cela peut faciliter la cohérence de certaines requêtes (par exemple, via l’exploitation de hiérarchies/relations déduites), à condition que votre outillage et vos compétences suivent.
Haystack formalise la sémantique via Defs et explicite une progression “vocabulaire → taxonomie → ontologie”. (Voir : Project Haystack — Defs) Il introduit aussi la notion d’associations (relations) entre defs, et précise que ces associations permettent l’inférence lors des requêtes de connaissance sur les données Haystack. (Voir : Project Haystack — Defs)
3) Compétences et exploitation : qui maintient le modèle sur la durée ?
La question n’est pas “qui sait le déployer”, mais “qui va le maintenir”. En parc multi-sites, le modèle vit : on ajoute des points, on remplace des équipements, on change de GTB, on découpe/remodèle des zones, on ajoute des compteurs, etc.
- Signal “plutôt Haystack” (à confirmer selon votre contexte) : équipes OT/IoT qui veulent une structuration en dict/tags, une montée en maturité progressive via Defs, et un cadre cohérent avec des échanges de données typés. (Voir : Project Haystack — Introduction)
- Signal “plutôt Brick” : équipes data/IT prêtes à porter un modèle de connaissance en RDF, avec logique d’ontologie et d’outillage associé. (Voir : Brick Ontology Documentation — Core Concepts)
Dans les deux cas, la réussite dépend plus de la gouvernance (règles, validation, responsabilités) que du choix du standard.
4) Coûts “jour 2” : où les efforts se concentrent souvent
Sans chiffrage universel (il dépend trop des outils et du parc), parmi les postes “jour 2” typiquement rencontrés dans les projets multi-sites, on retrouve :
- le rattrapage sémantique (points mal typés, ambiguïtés, duplications),
- les changements (rénovation, ajout de capteurs, remplacement de sous-systèmes),
- la recette (savoir prouver que les données sont exploitables, pas seulement “visibles”),
- la gouvernance (qui a le droit de modifier quoi, et comment on évite les divergences entre sites).
Côté Brick, la documentation explicite une approche de versioning fondée sur un namespace stable “depuis v1.2” et sur l’import d’une version via owl:imports vers un IRI versionné : on “verrouille” une version de référence et on peut la mettre à jour en changeant l’import. (Voir : Brick Ontology Documentation — Ontology Versioning)
Côté Brick toujours, la page “Validation” indique que la documentation détaillée est “coming soon” et renvoie vers des ressources (SHACL shapes, package brickschema). (Voir : Brick Ontology Documentation — Validation) Cela ne veut pas dire que la validation est impossible ; cela signifie que, dans votre projet, il faut cadrer précisément comment vous validez (outillage, règles, responsabilité, livrables) au-delà de l’intention.
Côté Haystack, la gouvernance passe souvent par les Defs : les définitions formelles, organisées en couches (vocabulaire/taxonomie/ontologie) et enrichies par associations. (Voir : Project Haystack — Defs)
Grille de choix : 7 questions à poser en AMO / DSI immobilier
1) Quel est votre “MVP sémantique” ?
- MVP = typer rapidement beaucoup de points (sans graphe riche au départ) : une approche dict/tags/markers (Haystack) peut être plus naturelle pour démarrer, puis s’enrichir via defs. (Voir : Project Haystack — Introduction)
- MVP = relations structurantes dès le début (feeds, hasPoint, hasLocation) : Brick documente ces relations et leur usage, ce qui aide à cadrer la cible attendue. (Voir : Brick Ontology Documentation — Relationships)
2) “Interop” signifie quoi chez vous ?
- Interop = normaliser l’échange entre briques (historian, hypervision, data lake, apps) : priorité aux formats / API / types (Haystack décrit ce périmètre dans son stack). (Voir : Project Haystack — Introduction)
- Interop = normaliser le sens pour des analytics réutilisables et des modèles comparables : priorité au graphe entités/relations (Brick se positionne explicitement sur cette représentation). (Voir : Brick Ontology Documentation — Design Principles)
3) Avez-vous besoin d’inférence (et à quel endroit) ?
Si l’inférence fait partie de la stratégie (ex. enrichir automatiquement certains liens/héritages), Brick annonce l’usage d’OWL 2 RL. (Voir : Brick Ontology Documentation — Inference and Reasoning) Haystack indique que ses associations “enable inference when querying knowledge”. (Voir : Project Haystack — Defs) Dans les deux cas, la vraie question est : votre outillage et vos compétences savent-ils l’exploiter de manière contrôlée (et testable) ?
4) Comment versionner et figer une base commune multi-sites ?
Si vous devez contractualiser “cette version de modèle s’applique à tel périmètre”, Brick documente une stratégie via owl:imports d’un IRI versionné. (Voir : Brick Ontology Documentation — Ontology Versioning) Pour Haystack, le mécanisme “Defs + libraries” organise le vocabulaire et sa diffusion, et peut servir de base à une gouvernance interne (à cadrer : règles de contribution, validation, compatibilité). (Voir : Project Haystack — Defs)
5) Qui fait quoi : intégrateur, exploitant, DSI, data team ?
Posez des rôles simples et stables :
- qui crée / met à jour (annotation, defs/ontologie, mappings),
- qui valide (tests, échantillonnage, revue),
- qui arbitre en cas de divergence entre sites,
- qui maintient l’outillage (pipelines, exports, sauvegardes, accès).
6) Quelles dépendances “jour 2” acceptez-vous ?
Un modèle sémantique ne vit jamais seul : il interagit avec des connecteurs, des bases de séries temporelles, des ETL, des tableaux de bord, des apps métiers. Avant de choisir, listez vos dépendances (et vos contraintes internes) : supervision existante, data lake, CMMS/GMAO, BI, exigences d’hébergement, etc.
7) Quel périmètre : CVC seulement, ou multi-lots ?
Le risque classique en multi-sites est de viser “tout le bâtiment” dès le départ. Une stratégie plus robuste consiste à démarrer par un périmètre gouvernable (ex. CVC + comptage, ou CVC + qualité d’air, etc.), puis à étendre une fois la recette stabilisée. Cette recommandation est une démarche projet (pas une exigence des standards).
Quand ne pas en faire (ou quand limiter l’ambition)
Il est rationnel de ne pas déployer une ontologie complète si :
- vous n’avez pas de cas d’usage multi-sites crédible (ou pas d’industrialisation d’analytics),
- vous ne pouvez pas financer la gouvernance (validation, arbitrages, maintien),
- le parc est trop hétérogène et aucun sponsor n’accepte le coût d’harmonisation,
- vous êtes en phase “rattrapage” (connectivité, supervision de base, fiabilisation terrain).
Dans ce cas, un compromis utile est de formaliser un minimum sémantique (conventions de nommage, unités, familles de points, identifiants stables) et de préparer un chemin de migration.
Démarche recommandée : réduire le risque avant de standardiser tout le parc
1) Piloter sur un échantillon représentatif
Choisissez quelques bâtiments “types” (un récent, un rénové, un complexe), puis vérifiez :
- le temps d’annotation/mapping réaliste,
- la qualité des requêtes (retrouver sans ambiguïté ce que vous cherchez),
- la capacité à absorber le changement (ajout/suppression de points, remplacement d’équipements).
2) Définir une recette sémantique (testable)
La recette ne doit pas se limiter à “on a livré un export”. Elle doit prouver :
- que chaque point critique est typé,
- que les relations indispensables sont présentes (au moins : site/zone/équipement/point),
- que les requêtes “métier” (analytics, exploitation) retournent des ensembles cohérents.
3) Industrialiser : gouvernance, diffusion, et gestion de versions
Une fois le pilote concluant, cadrez vos livrables : qui publie la “base commune”, comment on versionne, comment on vérifie la conformité, et comment on arbitre les extensions.
Aller plus loin (articles Domocasa liés au sujet)
- GTB, GTC et BMS : comprendre ce que l’on met derrière les mots (utile pour cadrer le périmètre avant de parler sémantique).
- Modéliser des points GTB/GRMS avec Project Haystack (hôtellerie) (approche opérationnelle “site/equip/point”).
- Organiser les données entre la maquette numérique et KNX : sémantique exploitable, sans promesse magique (gouvernance et méthode projet).
Conclusion : une règle de décision simple (sans promesse magique)
Choisissez Haystack si votre priorité est de structurer vos données IoT autour d’un modèle dict/tags/markers et d’un mécanisme formel de defs, dans un stack qui met aussi en avant types, formats et API. (Voir : Project Haystack — Introduction)
Choisissez Brick si votre priorité est une représentation en graphe (RDF) centrée sur classes + relations, avec une documentation explicite sur certaines relations clés (feeds/hasPoint/hasLocation), et un cadre de raisonnement/versioning au niveau ontologie (OWL 2 RL, imports versionnés). (Voir : Brick Ontology Documentation — Core Concepts)
Dans les deux cas, le gain “jour 2” viendra surtout de votre MVP, de votre recette sémantique et de votre gouvernance. Si vous souhaitez cadrer un pilote multi-sites (AMO, CCTP, recette), Domocasa peut vous aider à transformer le sujet “ontologie” en livrables exploitables.
Sources et documentation (références primaires)
- Brick Ontology Documentation — Design Principles
- Brick Ontology Documentation — Core Concepts
- Brick Ontology Documentation — Relationships
- Brick Ontology Documentation — Inference and Reasoning
- Brick Ontology Documentation — Ontology Versioning
- Brick Ontology Documentation — Validation
- Project Haystack — Introduction
- Project Haystack — Defs
