IBMS
IBMS — système intégré de gestion technique du bâtiment
L’IBMS expliqué : comment un système intégré de gestion technique du bâtiment réunit la CVC, l’éclairage, le contrôle d’accès, la CCTV, l’énergie et l’état du système incendie dans une vision d’exploitation unique.
Ce que signifie IBMS
IBMS désigne un système intégré de gestion technique du bâtiment. Il s’agit d’une couche d’intégration, et non d’une marque unique de contrôleur. Elle collecte les données du BMS et des autres systèmes du bâtiment, normalise ces données dans un modèle commun et offre aux opérateurs un point unique pour consulter l’état, acquitter les alarmes et émettre des commandes. Le BMS continue de contrôler les installations ; l’IBMS coordonne les systèmes entre eux et produit des rapports sur le bâtiment dans son ensemble. Cette distinction garde l’architecture honnête et empêche un projet d’intégration de devenir un remplacement de contrôle non planifié. Cette frontière compte aussi sur le plan commercial : un IBMS ne doit pas devenir un moyen de remplacer un BMS en fonctionnement sans décision distincte. L’IBMS doit être chiffré et cadré comme une prestation d’intégration, et non comme une licence assortie d’une ingénierie non spécifiée. Un périmètre clair nomme les systèmes, les données, les règles et les rôles opérateur que la plateforme doit prendre en charge.
- Couche d’intégration au-dessus du BMS
- Modèle commun de données et d’alarmes
- Une vue opérateur unique sur tous les systèmes
- Le BMS conserve le contrôle des installations
Sous-systèmes dans un modèle unique
Un périmètre IBMS type comprend la CVC et les installations techniques, l’éclairage, la protection solaire, le contrôle d’accès, la CCTV, l’alarme d’intrusion, le parking, la sonorisation, les ascenseurs, les compteurs d’énergie, le contrôle des chambres d’hôtel et l’état du système incendie. Chaque sous-système conserve son propre contrôleur et ses propres responsabilités de sécurité. L’IBMS lit les états, écrit les commandes autorisées et relie les événements entre systèmes. La matrice d’intégration doit indiquer, pour chaque sous-système, quelles données sont en lecture seule, lesquelles sont accessibles en écriture et quel fournisseur reste responsable de l’équipement. Cette matrice constitue la définition opérationnelle du projet. Chaque sous-système doit avoir un propriétaire désigné, un document d’interface et un mode de défaillance testé. Les points en lecture seule ne sont pas une limitation ; ils constituent une frontière qui protège la sécurité et la garantie du sous-système. La matrice doit aussi consigner le sens des données, la fréquence de mise à jour et le comportement en cas de perte de liaison, car ces trois éléments déterminent si l’opérateur peut faire confiance à l’écran.
- CVC, éclairage et protection solaire
- Contrôle d’accès, CCTV et intrusion
- Parking, ascenseurs et sonorisation
- Énergie, chambres d’hôtel et état du système incendie
Des alarmes exploitables par les opérateurs
Un IBMS collecte les alarmes de systèmes qui n’ont jamais été conçus pour les partager. Sans rationalisation, le résultat est un mur de bruit. Un modèle d’alarmes exploitable normalise les descriptions, supprime les doublons, classe les événements selon leur conséquence, les achemine vers le bon rôle et enregistre l’acquittement et l’escalade. Une défaillance d’eau glacée, une porte forcée et un défaut de communication de compteur ne doivent pas arriver avec la même priorité. La philosophie d’alarme est arrêtée pendant la conception, testée pendant la mise en service et revue après la première saison d’exploitation. L’opérateur doit pouvoir voir pourquoi une alarme a été émise, et pas seulement qu’elle existe ; le contexte fait partie de l’alarme. Le nombre d’alarmes et les événements répétitifs doivent être examinés, car un système bruyant apprend aux opérateurs à l’ignorer. Un indicateur utile est le nombre d’alarmes nécessitant une action ; si la plupart sont des nuisances, le modèle d’alarmes doit être retravaillé, pas le nombre d’écrans.
- Descriptions d’alarmes normalisées
- Classement par conséquence
- Acheminement, acquittement et escalade
- Revue des alarmes après la saison
Interverrouillages et logique inter-systèmes
La valeur d’un IBMS apparaît lorsque les systèmes agissent ensemble. L’ouverture d’une pièce par le contrôle d’accès peut mettre l’éclairage, la CVC et la CCTV dans l’état voulu. Une entrée de parking peut allumer l’éclairage de la zone d’approche. Une alarme incendie peut libérer les portes et arrêter les centrales de traitement d’air, tandis que le tableau incendie conserve l’autorité sur les fonctions de sécurité des personnes. Les interverrouillages doivent être configurés sous forme de règles visibles, et non de câblage caché entre les contrôleurs de fournisseurs. Chaque règle a besoin d’un déclencheur, d’une condition, d’une action, d’un délai d’expiration et d’un comportement en cas de défaillance. Les essais prouvent que la règle fonctionne, et la piste d’audit montre qui l’a modifiée. Une règle qui ne peut pas être testée ne doit pas être déployée, car le bâtiment finira par en dépendre. Les règles inter-systèmes doivent échouer dans une direction définie, en laissant généralement le sous-système concerné dans son état de sécurité local. Les règles ont aussi besoin d’un responsable et d’une date de revue ; sinon elles s’accumulent et se contredisent.
- Liaison contrôle d’accès, éclairage et CVC
- Parking et éclairage de façade
- Mode incendie avec autorité du tableau
- Règles visibles avec enregistrements d’audit
Expérience opérateur
Un IBMS se juge à 02h00, quand une seule personne est en poste et qu’un problème survient. L’interface doit montrer ce qui a changé, où cela se situe, ce que cela affecte et quoi faire ensuite. Des vues par rôle permettent à l’opérateur, à l’ingénieur et à la direction de travailler sur les mêmes données à des niveaux de détail différents. Les plans d’étage, les tendances et l’historique des alarmes doivent être accessibles sans fouiller dans les menus. L’accès mobile aide une petite équipe à couvrir un grand site. La formation et la documentation font partie du produit, pas d’une réflexion après coup. Un test utile consiste à faire réaliser une tâche de routine par une personne qui ne connaît pas le projet, sans demander d’aide. Les vues doivent être conçues autour des rôles et des tâches, et non autour de la structure de menus du fournisseur. L’interface doit aussi distinguer une valeur mesurée d’une valeur périmée, car un écran qui semble en direct mais affiche des données anciennes est pire que pas d’écran du tout.
- Hiérarchie claire et exploration par niveaux
- Vues et permissions par rôle
- Tendances, plans d’étage et historique des alarmes
- Formation et documentation opérateur
Protocoles ouverts et contrôle local prioritaire
L’IBMS dépend des interfaces. BACnet/IP et Modbus sont courants pour les installations et les compteurs, KNX pour l’éclairage et le contrôle des pièces, DALI pour les luminaires, les API et ODBC pour les systèmes de gestion, et les contacts secs pour les équipements qui n’offrent rien d’autre. La plateforme doit fonctionner sur le réseau local, conserver l’historique sur site et traiter l’accès à distance comme une option avec authentification et journalisation. La segmentation réseau entre OT et IT fait partie de la conception. Le maître d’ouvrage doit pouvoir changer d’intégrateur sans perdre le modèle de points, les graphiques et les données. La documentation doit comprendre le schéma réseau, le modèle de points et la situation des licences, afin que le maître d’ouvrage ne soit pas lié à un seul fournisseur. L’accès à distance doit être révocable sans perturber l’exploitation locale. Le contrôle local prioritaire ne signifie pas isolé : cela signifie que le bâtiment continue de fonctionner lorsque la liaison étendue est indisponible et que l’opérateur peut toujours accéder aux données sur site.
- BACnet, Modbus, KNX et DALI
- API et ODBC pour les systèmes de gestion
- Serveurs locaux et historique
- Segmentation et accès à distance audité
Architecture, réseaux et cybersécurité
Un IBMS est un projet réseau autant qu’un projet de contrôle. Le serveur d’intégration, les passerelles et les postes opérateur reposent sur un réseau segmenté ; les services techniques du bâtiment ne doivent pas partager un réseau plat avec l’informatique de bureau. Une conception courante utilise un VLAN OT dédié, un pare-feu entre OT et IT et un accès à distance maîtrisé via un VPN ou un broker avec authentification multifacteur. La synchronisation horaire est importante, car les alarmes et les tendances issues de systèmes différents doivent concorder ; sans source de temps cohérente, la corrélation des événements relève de la conjecture. Le stockage de l’historique, la sauvegarde et la restauration doivent être spécifiés, y compris la durée de conservation des données et qui peut les exporter. Les comptes utilisateurs doivent provenir d’un annuaire lorsque c’est possible, avec des permissions par rôle et un journal d’audit des commandes et des changements de consigne. L’accès à distance doit être révocable sans perturber l’exploitation locale. La cybersécurité n’est pas une fonctionnalité ajoutée à la fin ; elle fait partie de l’architecture d’intégration.
- Segmentation OT / IT
- Synchronisation horaire cohérente
- Comptes par rôle et journaux d’audit
- Politique de sauvegarde, de conservation et d’accès à distance
Étapes de réalisation et modes de défaillance courants
La réalisation suit une séquence. Un audit confirme les systèmes, les versions et les interfaces disponibles. Une matrice d’intégration définit les droits de lecture et d’écriture, les responsables et les frontières. Un modèle de points attribue à chaque élément un nom, une unité, une permission et une priorité d’alarme. Les passerelles et interfaces sont configurées et testées en usine lorsque c’est possible, puis sur site. La mise en service passe des contrôles point par point aux règles inter-systèmes et aux essais de défaillance, et se termine par une période de rodage (soft landing) pendant laquelle les opérateurs utilisent le système en conditions réelles. La documentation comprend le schéma réseau, le modèle de points, la matrice d’intégration, les relevés d’essais, la situation des licences et la procédure de reprise. Les modes de défaillance courants sont prévisibles : une API supposée mais jamais testée, des avalanches d’alarmes qui masquent l’événement réel, des données périmées issues d’une passerelle, des noms de points en doublon, une dérive horaire entre systèmes et un modèle de licence qui empêche le maître d’ouvrage d’ajouter des points sans le fournisseur d’origine.
- Audit et matrice d’intégration
- Modèle de points et essais de passerelle
- Essais inter-systèmes et de défaillance
- Rodage et documents conformes à l’exécution
Matrice d’intégration IBMS
18 rows| Sous-système | Interface type | Rôle de l’IBMS | Frontière |
|---|---|---|---|
| CVC et BMS | BACnet/IP, Modbus, 0–10 V | Horaires, consignes, alarmes, tendances | Le BMS conserve le contrôle des installations |
| Éclairage | DALI, KNX, relais | Scènes, occupation, état de défaut | Le contrôleur d’éclairage conserve le contrôle local |
| Protection solaire | KNX, Modbus, contacts secs | Règles solaires et de vent, scènes | Le contrôleur de moteur ou de façade conserve les limites |
| Contrôle d’accès | API, OSDP via contrôleur, contacts secs | État des portes, déverrouillage, couplage d’événements | Le système de contrôle d’accès conserve la logique d’autorisation |
| CCTV | ONVIF ou API du fournisseur | Carte des caméras, liaison d’événements, état de santé | Le VMS assure l’enregistrement et la conservation |
| Alarme intrusion | Contacts secs, API | État de zone, événements d’armement/désarmement | La centrale d’alarme conserve la logique de détection |
| Alarme incendie | Contacts secs, entrées supervisées | Statut, pré-alarme et asservissements uniquement | La centrale incendie conserve l’autorité sur la sécurité des personnes |
| Désenfumage | Contacts secs, API | Statut et position des registres | Le système de désenfumage conserve sa séquence |
| Parking | API, TCP/IP | Statut des entrées, comptage des places, exceptions | Le système de parking conserve la commande des barrières |
| Sonorisation | API, contacts secs | Statut des zones, messages programmés | Le système de sonorisation conserve la priorité d’urgence |
| Ascenseurs | Contacts secs, API | Signaux d’état, de défaut et d’alarme | Le contrôleur d’ascenseur conserve la sécurité des déplacements |
| Compteurs d’énergie | Modbus, M-Bus via passerelle, impulsions | Sous-comptage, références de base, répartition | Le système de comptage conserve les données tarifaires |
| Compteurs d’eau et de gaz | Modbus, M-Bus via passerelle, impulsions | Tendances de consommation et alarmes de fuite | Le comptage des utilités conserve les données de facturation |
| Recharge de véhicules électriques | OCPP, API du fabricant | Statut des sessions, pilotage de la charge, exceptions | L’opérateur de recharge conserve la facturation et la sécurité |
| Onduleurs et groupes électrogènes | SNMP, Modbus, contacts secs | Heures de marche, niveau de carburant, événements de basculement | Le système électrique conserve la logique de basculement |
| Chambres et PMS | API, ODBC, interface RCU | Événements d’arrivée et de départ, statut des chambres, limites d’énergie | Le PMS conserve les réservations et la facturation |
| Gestion des visiteurs | API, contacts secs | Statut des pré-enregistrements, événements de porte | Le système de visiteurs conserve les contrôles d’identité |
| Analytique du bâtiment et FDD | API de l’historien, export de base de données | Détection de défauts, références de base, rapports de performance | La couche analytique conserve ses modèles |
Images du projet
3 images
Questions fréquentes
01Qu’est-ce qu’un IBMS ?
Un système intégré de gestion technique du bâtiment relie les sous-systèmes du bâtiment dans un modèle de données, une liste d’alarmes et une vue d’exploitation uniques. Il ajoute des règles inter-systèmes et des rapports, tandis que chaque sous-système conserve son propre contrôleur et ses responsabilités de sécurité.
02Quelle est la différence entre un IBMS et un BMS ?
Un BMS commande et supervise les services du bâtiment, en particulier la CVC et les installations techniques. Un IBMS se situe au-dessus et intègre le BMS avec le contrôle d’accès, la vidéosurveillance, le parking, l’énergie, les chambres et le statut incendie. Le BMS reste la couche de commande.
03Faut-il remplacer le BMS existant ?
Non. L’approche habituelle consiste à intégrer le BMS existant via BACnet, Modbus ou une autre interface disponible. Le remplacement est une décision commerciale distincte, et non une condition préalable à un IBMS.
04Un IBMS peut-il fonctionner sans Internet ?
Oui. La plateforme d’intégration et la logique de commande doivent fonctionner sur le réseau local, avec un historique stocké sur site. L’accès Internet est facultatif, pour le support à distance et les rapports.
05Quels protocoles un IBMS prend-il en charge ?
Les interfaces courantes comprennent BACnet/IP, Modbus RTU et TCP, KNX, DALI, les API, ODBC et les contacts secs. L’ensemble réel dépend des équipements installés et des passerelles retenues pour le projet.
06Comment les alarmes incendie sont-elles traitées ?
L’incendie reste un système distinct de sécurité des personnes. L’IBMS lit les statuts et les signaux de pré-alarme via des contacts secs ou des entrées surveillées et peut déclencher des asservissements définis, mais la centrale incendie conserve l’autorité en toutes circonstances.
07Comment les alarmes sont-elles hiérarchisées ?
Les alarmes sont normalisées, dédoublonnées et classées selon leurs conséquences, et non selon le système source. La philosophie d’alarme définit la priorité, le routage, l’acquittement et l’escalade ; elle est testée lors de la mise en service.
08Un IBMS peut-il couvrir plusieurs bâtiments ?
Oui. Des contrôleurs locaux peuvent exploiter chaque bâtiment, tandis qu’une couche centrale consolide les alarmes, l’énergie et les rapports. La conception doit définir ce qui reste local et ce qui dépend du réseau entre les sites.
Étape suivante
Apportez-nous le bâtiment.
Indiquez le type de bâtiment, les systèmes concernés et le résultat dont vous avez besoin. Nous tracerons le chemin le plus court vers un système opérationnel.