Gestion technique du bâtiment MQTT : BACnet, KNX et MQTT

Une couche MQTT de gestion technique du bâtiment vous permet de prendre des données enfermées dans des contrôleurs BACnet, des lignes KNX et des compteurs Modbus, et de les publier en un seul endroit où tableaux de bord, outils d'analyse et d'alerte peuvent les exploiter. Ce guide explique où MQTT a sa place dans une gestion technique du bâtiment (GTB), ce qu'il doit et ne doit pas remplacer, et comment concevoir topics, passerelles et sécurité pour que des dizaines de bâtiments puissent partager un même broker.

Pourquoi les bâtiments ont-ils besoin d'un protocole de plus ?

La plupart des bâtiments tertiaires exploitent déjà un protocole de terrain mature. BACnet domine le CVC et les installations centrales, KNX est courant en Europe pour l'éclairage, les stores et la gestion des pièces, et Modbus RTU ou TCP se retrouve dans les compteurs d'énergie, les groupes froids et les variateurs de vitesse. Ces protocoles excellent dans ce pour quoi ils ont été conçus : un contrôle déterministe sur un réseau local, avec des modèles d'objets que les ingénieurs CVC comprennent.

Là où ils sont faibles, c'est pour sortir du bâtiment. BACnet/IP s'appuie sur des broadcasts UDP et suppose un LAN plat et de confiance. Le routage KNX/IP utilise le multicast. Aucun des deux ne franchit un pare-feu avec élégance, aucun n'a été conçu pour des milliers d'abonnés distants, et les exposer sur Internet est une erreur de sécurité bien connue. Les équipes de gestion des installations qui veulent une vue de parc sur la consommation d'énergie, les plaintes de confort ou les défauts d'équipement se retrouvent avec une supervision par site, chacune avec son identifiant et son format d'export.

MQTT comble précisément ce manque. C'est un protocole publish/subscribe léger dans lequel chaque équipement et chaque application établit une connexion TCP ou TLS sortante vers un broker MQTT central. Dans chaque bâtiment, des passerelles traduisent les points locaux en topics, et tout ce qui a besoin des données s'abonne, sans savoir où se trouve la passerelle ni combien de sites existent.

La place de MQTT dans une gestion technique du bâtiment

Considérez un bâtiment en trois niveaux :

Niveau terrain : capteurs, actionneurs, boîtes VAV, boutons-poussoirs KNX, compteurs. La communication se fait en BACnet MS/TP, KNX TP, Modbus RTU, DALI ou sur des bus propriétaires.
Niveau automatisme : contrôleurs et postes de supervision qui exécutent les boucles de régulation, les programmations horaires et les verrouillages. On y trouve toujours BACnet/IP, KNX/IP ou Modbus TCP.
Niveau intégration : l'endroit où les données sont normalisées et partagées avec le reste de l'organisation. C'est là que MQTT a sa place.

La règle essentielle est que les boucles de régulation restent locales. Une boucle PID de température d'air soufflé doit continuer à tourner si la connexion Internet tombe ; elle réside donc dans le contrôleur, pas dans le cloud. MQTT transporte la télémétrie vers le haut et, avec prudence, des changements de consigne ou des dérogations de programmation vers le bas. En pratique, la couche MQTT de la gestion technique du bâtiment est une interface nord, pas un remplacement du réseau de terrain.

Comparaison des rôles des protocoles

Protocole	Rôle typique dans un bâtiment	Transport	Points forts	Points faibles
BACnet/IP	Contrôleurs CVC, installations centrales, supervision	UDP 47808, broadcasts	Modèle d'objets riche, interopérabilité entre fabricants	Traversée du NAT et des pare-feu, nombreux clients distants
BACnet MS/TP	Contrôleurs de terrain, boîtes VAV	RS-485	Câblage économique, déterministe	Bande passante, accès à distance
KNX	Éclairage, stores, gestion des pièces	Paire torsadée, KNX/IP multicast ou tunneling	Automatisation des pièces décentralisée et robuste	Intégration hors du bâtiment
Modbus RTU/TCP	Compteurs, variateurs, groupes froids	RS-485 ou TCP 502	Simplicité, omniprésence	Pas de métadonnées, interrogation uniquement
MQTT	Intégration, cloud, analyse	TCP/TLS vers un broker	Nombreux sites, nombreux consommateurs, connexions sortantes uniquement	Contrôle temps réel strict

Les passerelles : transformer des points en topics

Chaque bâtiment a besoin d'au moins une passerelle. Elle lit les points du protocole de terrain et les publie sous forme de messages MQTT. Vous avez trois options réalistes :

MQTT intégré au contrôleur ou au superviseur. De nombreux contrôleurs de GTB récents et systèmes d'exploitation de bâtiment peuvent publier directement en MQTT. Vérifiez qu'ils prennent en charge TLS et l'authentification par nom d'utilisateur et mot de passe avant de vous y fier.
Une petite passerelle Linux. Un équipement de classe Raspberry Pi ou un PC industriel exécutant un script ou un flow Node-RED. Nos tutoriels BACnet vers MQTT et KNX vers MQTT présentent des ponts open source complets.
Une passerelle de protocoles du commerce. Utile si vous avez besoin d'un comportement BACnet certifié ou de centaines de points par équipement.

Quel que soit votre choix, la passerelle doit interroger ou s'abonner localement (abonnements COV BACnet, télégrammes de groupe KNX), appliquer des bandes mortes pour ne pas inonder le broker de bruit, et publier du JSON avec un horodatage, une valeur, une unité et un indicateur de qualité.

{
  "ts": "2026-10-16T08:15:02Z",
  "value": 13.4,
  "unit": "degC",
  "quality": "good",
  "source": "bacnet:1201/analogInput:3"
}

Inclure la référence d'objet d'origine dans source facilite grandement le dépannage le jour où quelqu'un demande pourquoi la valeur d'un tableau de bord diffère de celle de la supervision GTB.

Concevoir les topics pour des bâtiments multisites

La conception des topics est la décision avec laquelle vous vivrez le plus longtemps. Une hiérarchie calquée sur l'emplacement physique fonctionne bien pour les bâtiments, car c'est ainsi que les gens raisonnent :

<org>/<site>/<building>/<floor>/<zone>/<equipment>/<point>
acme/ist01/tower-a/f12/zone-east/ahu-2/supply-air-temp
acme/ist01/tower-a/f12/zone-east/ahu-2/filter-dp
acme/ank02/hq/f03/meeting-301/occupancy/present

Cela reprend le style ISA-95 utilisé dans les usines (entreprise, site, zone, ligne, cellule), ce qui compte, car ConnectMQ reconnaît les structures de topics ISA-95 et Unified Namespace et peut afficher les équipements regroupés selon ces niveaux dans sa vue des équipements. Les gestionnaires d'installations peuvent alors parcourir un parc par site et par étage au lieu de chercher dans des listes de topics à plat. La même hiérarchie sert aussi de squelette naturel si vous construisez plus tard un jumeau numérique du bâtiment.

Quelques règles pratiques :

Utilisez des minuscules, des tirets au lieu des espaces, et aucun nom de personne dans les topics.
Placez le nom du point en dernier pour que les wildcards restent utiles : acme/+/+/+/+/+/supply-air-temp renvoie toutes les températures d'air soufflé du parc.
Publiez les métadonnées qui évoluent lentement (unités, consignes, modèle d'équipement) sous forme de messages retenus pour que les nouveaux abonnés connaissent immédiatement l'état actuel.
Séparez les commandes de la télémétrie, par exemple .../ahu-2/cmd/setpoint et .../ahu-2/supply-air-temp, et n'autorisez que les clients habilités à publier sur les topics de commande.

Si vous exploitez déjà des sites industriels, la même logique se retrouve dans notre article sur Sparkplug B et le Unified Namespace.

Écrire vers le bâtiment en toute sécurité

Lire des données présente peu de risques. Écrire des consignes depuis le cloud, si. Avant qu'un message MQTT puisse modifier une valeur dans un équipement BACnet ou KNX, installez des garde-fous dans la passerelle :

Tenez une liste blanche explicite des points accessibles en écriture. N'exposez jamais de topic générique du type « écrire n'importe quel objet ».
Validez les plages dans la passerelle (par exemple, une consigne de zone comprise entre 18 et 26 degrés Celsius).
Pour BACnet, écrivez à une priorité définie et relâchez-la à la fin de la dérogation, pour que les programmations locales reprennent la main.
Renvoyez la valeur acceptée sur un topic d'état et journalisez l'auteur de la demande.
Utilisez QoS 1 pour les commandes et rendez le traitement idempotent, car un message QoS 1 peut arriver deux fois. Notre guide des niveaux de QoS MQTT explique pourquoi.

Centraliser de nombreux bâtiments dans un seul broker

Dès que chaque passerelle publie en sortant, centraliser un parc devient une question d'hébergement. Vous pouvez exploiter un broker dans votre propre datacenter, mais vous êtes alors responsable des correctifs, des certificats, de la supervision et du dimensionnement d'un système que les équipes de gestion des installations s'attendent à voir fonctionner en permanence.

Un broker MQTT managé supprime ce travail. Avec ConnectMQ, chaque passerelle de bâtiment se connecte au même broker via TLS sur le port 8883 avec ses propres identifiants générés, et le portail fournit un explorateur de topics en direct pour inspecter ce que publie chaque site. Des règles d'alerte à seuil peuvent signaler des conditions comme une température d'air soufflé qui reste hors plage, et le journal des alertes conserve l'historique de leurs déclenchements. Tableaux de bord, flows Node-RED, collecteurs Telegraf ou services Python qui écrivent dans votre base de données se connectent comme des clients MQTT ordinaires et s'abonnent avec des wildcards.

Checklist de dimensionnement

Comptez les passerelles par site et chaque application consommatrice ; chacune représente une connexion.
Estimez les messages par seconde après application des bandes mortes, pas les fréquences d'interrogation brutes.
Vérifiez la taille du plus gros message nécessaire (un instantané complet d'équipement peut être plus volumineux qu'un point unique).
Déterminez si vous avez besoin de QoS 2 ou d'abonnements partagés pour des consommateurs en répartition de charge.
Prévoyez l'isolation : un parc exigeant une séparation stricte entre locataires peut justifier un cluster dédié.

Les petits pilotes tiennent dans l'offre Serverless gratuite (jusqu'à 25 connexions, QoS 0 et 1, messages de 256 Ko). Les parcs plus importants passent à l'offre Serverless payante (jusqu'à 1 000 connexions, QoS 2, abonnements partagés) ou à un cluster Dedicated.

Considérations de sécurité propres aux bâtiments

Les réseaux de bâtiment sont souvent plats, anciens et partagés avec des prestataires. MQTT aide, car les passerelles n'ont besoin que de connexions sortantes : vous n'ouvrez jamais de ports entrants sur le pare-feu pour BACnet ou KNX. Au-delà :

Utilisez toujours TLS (port 8883, ou 8084 pour les tableaux de bord en WebSocket sécurisé).
Donnez à chaque passerelle ses propres identifiants, afin de pouvoir révoquer un équipement compromis sans toucher aux autres. ConnectMQ lie les client IDs aux identifiants délivrés et bloque les adresses IP après des échecs de connexion répétés.
Placez la passerelle sur un VLAN distinct du réseau de terrain, avec uniquement les ports dont elle a besoin.
Ne publiez jamais de données personnelles, comme des identifiants de badge, sur des topics que de nombreuses applications peuvent lire.

La checklist plus large des bonnes pratiques de sécurité MQTT s'applique aux bâtiments autant qu'aux usines.

Un plan de déploiement réaliste

Commencez par un bâtiment et un petit ensemble de points à forte valeur : températures de soufflage et de reprise, pression différentielle des filtres, compteur d'énergie principal et quelques températures de zone. Publiez-les sur le serveur MQTT public gratuit, prévu pour les tests et non pour la production, uniquement si les données ne sont pas sensibles et que vous voulez seulement valider les payloads ; passez à un broker privé dès que des adresses réelles ou des données d'occupation entrent en jeu. Ajoutez ensuite l'alerte, puis les tableaux de bord, puis un deuxième site. Au troisième bâtiment, vous saurez si votre schéma de topics passe à l'échelle. Pour d'autres cas d'usage, consultez notre guide de l'automatisation IoT, et pour des applications précises, lisez la surveillance CVC avec des capteurs IoT.

Connectez vos bâtiments à ConnectMQ

Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire. Vous obtenez en quelques minutes un nom d'utilisateur, un mot de passe et un client ID pour votre première passerelle, et l'explorateur de topics affiche les données de votre bâtiment dès leur arrivée. Quand le parc grandit, changez d'offre sans modifier votre conception de topics.

Questions fréquentes

MQTT remplace-t-il BACnet dans une gestion technique du bâtiment ?

Non. BACnet et KNX restent les réseaux de contrôle à l'intérieur du bâtiment. MQTT est la couche d'intégration qui transporte une sélection de points vers les tableaux de bord, les outils d'analyse et les autres sites.

Puis-je piloter des équipements CVC via MQTT ?

Oui, via une passerelle qui écrit dans le contrôleur, mais limitez-la à une liste blanche de points, validez les plages et gardez les boucles de régulation en local pour que le bâtiment continue de fonctionner si la connexion tombe.

Quel niveau de QoS utiliser pour la télémétrie d'un bâtiment ?

QoS 0 convient aux mesures fréquentes, dont la valeur suivante arrive rapidement. Utilisez QoS 1 pour les alarmes et les commandes, et rendez le traitement des commandes idempotent.

De combien de connexions un bâtiment a-t-il besoin ?

Généralement une par passerelle, plus une par application consommatrice. Un bâtiment pilote typique avec une seule passerelle et un tableau de bord n'a besoin que de quelques connexions.

Gestion technique du bâtiment et MQTT : la place de MQTT aux côtés de BACnet et KNX