BACnet vs Modbus : comparatif des protocoles pour bâtiments et usines

BACnet vs Modbus : tout ingénieur en exploitation de bâtiments, intégrateur ou équipe d'automatisme d'usine se pose la question tôt ou tard, généralement quand un groupe froid parle un protocole et les compteurs d'énergie l'autre. Ce guide compare les deux protocoles sur le modèle de données, le transport, la découverte, la sécurité et l'effort au quotidien, puis montre comment une passerelle les traduit tous deux en MQTT pour que les données arrivent au même endroit. À la fin, vous saurez quel protocole convient à quel usage et comment intégrer les deux dans une chaîne de télémétrie moderne.

Deux protocoles, deux mondes différents

Modbus a été créé à la fin des années 1970 pour les automates programmables. Il est volontairement minimaliste : un client demande à un serveur un bloc de registres de 16 bits ou de bits individuels, et le serveur répond. Aucun nom, aucune unité, aucune description ne circule sur le réseau. Tout ce qui donne un sens aux nombres se trouve dans une table de registres, généralement un PDF fourni par le fabricant de l'équipement.

BACnet (Building Automation and Control networks) a été développé par l'ASHRAE pour le CVC, l'éclairage, le contrôle d'accès et la sécurité incendie, et il est normalisé sous les références ASHRAE 135 et ISO 16484-5. Il a été conçu dès l'origine pour l'interopérabilité entre fabricants dans les grands bâtiments. Au lieu de registres anonymes, un équipement BACnet expose des objets typés dotés de propriétés nommées, et les équipements peuvent se découvrir mutuellement sur le réseau.

Cette différence de philosophie explique presque tout le reste du comparatif. Modbus est simple à implémenter et quasi universel sur les compteurs, variateurs et automates. BACnet est plus riche, autodescriptif, et domine la gestion technique du bâtiment (GTB).

BACnet vs Modbus en un coup d'œil

Modèles de données : registres contre objets

C'est généralement sur le modèle de données que se joue le choix BACnet vs Modbus, car il détermine le travail d'intégration que coûte chaque nouvel équipement.

Modbus : des nombres à des adresses

Un compteur d'énergie Modbus peut exposer la tension au holding register 3000 sous forme de flottant 32 bits réparti sur deux registres. Pour l'utiliser, il faut connaître l'adresse, le code fonction, le type de données, l'ordre des mots et un éventuel facteur d'échelle. Si l'ordre des mots est erroné, 230 V devient une valeur absurde. Chaque nouveau modèle d'équipement implique de lire une nouvelle table de registres et de la retranscrire dans la configuration de la passerelle.

L'avantage, c'est la prévisibilité : tous les automates, logiciels SCADA et passerelles le parlent.

BACnet : des objets typés avec des propriétés

Un contrôleur BACnet expose par exemple analog-input,3 avec des propriétés telles que object-name (« AHU-1 Supply Air Temp »), present-value (13.4), units (degrees-Celsius), status-flags et reliability. Un client peut parcourir la object-list de l'équipement et lire noms et unités sans aucun document externe. Les écritures passent par un tableau de priorités à 16 niveaux : une dérogation de sécurité des personnes en priorité 1 l'emporte sur une consigne planifiée en priorité 16, et libérer une priorité laisse le niveau suivant reprendre la main.

Cette richesse se paie en complexité : les piles sont plus volumineuses, les profils d'équipement définissent les services obligatoires, et les grands sites exigent une gestion rigoureuse des numéros d'instance d'équipement et des numéros de réseau.

Transports et réseau

Les deux protocoles ont une variante série et une variante IP, et les paires se ressemblent sur le papier.

• Modbus RTU vs BACnet MS/TP. Tous deux fonctionnent sur des bus RS-485 en chaîne. Modbus RTU utilise un maître unique qui interroge les esclaves à tour de rôle. MS/TP fonctionne par passage de jeton entre maîtres, si bien que plusieurs contrôleurs peuvent initier des échanges, les esclaves étant autorisés comme nœuds passifs. Les bus MS/TP sont courants pour les contrôleurs de terrain sur les boîtes VAV et les ventilo-convecteurs.
• Modbus TCP vs BACnet/IP. Modbus TCP est une simple connexion TCP vers le port 502, qui traverse facilement routeurs et pare-feu. BACnet/IP utilise UDP sur le port 47808 et s'appuie sur des diffusions pour la découverte. Les diffusions ne traversent pas les sous-réseaux, c'est pourquoi les sites BACnet utilisent des BACnet Broadcast Management Devices (BBMD) ou le Foreign Device Registration pour relier les sous-réseaux.

Pour l'accès à distance, les deux protocoles classiques sont mal adaptés à Internet. Aucun ne dispose d'authentification ni de chiffrement intégrés, et exposer publiquement le port 502 ou 47808 est un moyen bien connu de voir son bâtiment ou son usine scanné et sondé. La réponse moderne consiste à les garder sur le réseau local et à faire sortir les données via un protocole chiffré et authentifié : c'est là qu'intervient MQTT.

Interrogation contre Change of Value

Modbus n'a aucune notion d'événement. Pour savoir quand une température change, vous l'interrogez toutes les quelques secondes et comparez. Cela convient pour quelques compteurs, mais c'est du gaspillage pour des milliers de points.

BACnet propose les abonnements COV : un client s'abonne à un objet, et l'équipement envoie une notification quand la valeur varie au-delà de son incrément COV ou que les status flags changent. Les abonnements ont une durée de vie et doivent être renouvelés, et tous les équipements ne prennent pas en charge le COV sur tous les types d'objets : les passerelles de production combinent donc généralement le COV quand il est disponible avec l'interrogation en solution de repli.

C'est important pour MQTT, qui est piloté par les événements : transformer les notifications COV ou les interrogations filtrées par bande morte en publications limite la bande passante. Consultez le guide sur le report by exception pour le réglage des bandes mortes.

Quand choisir l'un ou l'autre

Utilisez cette checklist lorsque vous avez le choix, par exemple pour spécifier une nouvelle installation :

1. Le système concerne-t-il principalement le CVC, l'éclairage ou les services du bâtiment ? Privilégiez BACnet. Votre GTB, ses synoptiques et sa gestion des alarmes attendront des objets BACnet.
2. S'agit-il d'un compteur, d'un variateur, d'un onduleur ou d'un capteur simple ? Modbus est souvent la seule option, et elle est tout à fait suffisante. La plupart des GTB intègrent les équipements Modbus via une passerelle ou un driver.
3. Avez-vous besoin de plannings, d'historiques et d'alarmes dans les équipements de terrain ? BACnet dispose d'objets natifs pour cela ; avec Modbus, vous les implémentez dans l'automate ou le SCADA.
4. Des contrôleurs de fabricants différents devront-ils interopérer directement ? BACnet, avec des équipements listés BTL.
5. Le budget d'intégration par équipement est-il serré et la liste de points courte ? Modbus est plus rapide à câbler et à configurer.
6. Avez-vous besoin d'un transport sécurisé sur le réseau local ? Recherchez la prise en charge de BACnet/SC ou de Modbus/TCP Security, et prévoyez une segmentation réseau dans tous les cas.

En pratique, la plupart des sites utilisent les deux. La vraie question n'est pas BACnet vs Modbus, mais comment réunir les deux dans une couche de données unique et bien nommée.

Relier BACnet et Modbus à MQTT

Une passerelle de protocoles se place sur le réseau local, parle BACnet et Modbus vers le bas et publie en MQTT vers le haut, vers un broker. Ce peut être une passerelle de bâtiment commerciale, un PC industriel exécutant Node-RED ou un petit service Python. Le principe reste le même :

1. Interroger les registres Modbus selon un planning, les décoder en valeurs physiques et appliquer une bande morte.
2. S'abonner au COV BACnet quand il est pris en charge et interroger le reste.
3. Normaliser les deux dans un format de payload unique avec valeur, unité, qualité et horodatage.
4. Publier sur des topics qui décrivent l'équipement, pas le protocole.

Ce dernier point est essentiel. Les consommateurs n'ont pas à savoir si la température de soufflage provient de analog-input,3 ou du holding register 3000. Une arborescence de topics fondée sur l'emplacement et l'équipement, dans l'esprit des topics MQTT ISA-95, masque complètement le protocole :

connectmq/demo/a7f3k2/campus1/building-b/floor3/ahu1/supply-air-temp
connectmq/demo/a7f3k2/campus1/building-b/floor3/ahu1/fan-status
connectmq/demo/a7f3k2/campus1/building-b/plantroom/meter1/active-power
connectmq/demo/a7f3k2/campus1/building-b/plantroom/meter1/voltage-l1

Un payload normalisé, quelle que soit la source, ressemble à ceci :

{
  "value": 13.4,
  "unit": "degC",
  "quality": "good",
  "ts": "2026-10-16T09:41:07Z",
  "source": "bacnet:device-120001/analog-input:3"
}

Tester l'arborescence de topics sur le serveur MQTT public gratuit

Avant de connecter de vrais équipements, vous pouvez valider la conception des topics sur le serveur MQTT public gratuit broker.connectmq.com. Utilisez un préfixe aléatoire, car ce serveur est lisible par tout le monde et réservé aux tests :

# Terminal 1 : observer tout ce qui se trouve sous votre préfixe de test
mosquitto_sub -h broker.connectmq.com -p 1883 -i bms-watch-a7f3k2 \
  -t 'connectmq/demo/a7f3k2/#' -v

# Terminal 2 : simuler un point BACnet et un point Modbus
mosquitto_pub -h broker.connectmq.com -p 1883 -i bms-sim-a7f3k2 \
  -t 'connectmq/demo/a7f3k2/campus1/building-b/floor3/ahu1/supply-air-temp' \
  -m '{"value":13.4,"unit":"degC","quality":"good"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i bms-sim2-a7f3k2 \
  -t 'connectmq/demo/a7f3k2/campus1/building-b/plantroom/meter1/active-power' \
  -m '{"value":42.7,"unit":"kW","quality":"good"}'

Comptez les niveaux de topic pendant la conception : le serveur MQTT public gratuit autorise jusqu'à 8 niveaux, il faudra donc peut-être aplatir les longues hiérarchies de bâtiment pour les tests. Les brokers de production sur votre propre plan ne sont pas soumis à cette limite de test.

Pour le détail côté Modbus, consultez Modbus TCP vers MQTT et Modbus RTU vers MQTT.

Production : un broker privé

Pour de vrais bâtiments et de vraies usines, faites pointer la passerelle vers un broker privé avec identifiants et TLS sur le port 8883. Avec ConnectMQ, vous créez un broker dans le portail, copiez le nom d'utilisateur, le mot de passe et le client ID générés dans la passerelle, et voyez immédiatement les topics entrants dans l'explorateur de topics en direct. Les règles d'alerte à seuil du portail peuvent signaler une température de soufflage ou une puissance qui franchit une limite, tandis que historians, tableaux de bord, jumeaux numériques et outils d'analyse s'abonnent comme des clients MQTT ordinaires. Pour comprendre d'abord les compromis d'hébergement, découvrez les avantages d'un broker MQTT managé.

Pièges courants lors de l'intégration des deux

• Ordre des mots et mise à l'échelle Modbus. Vérifiez chaque valeur 32 bits par rapport à l'afficheur de l'équipement avant de vous y fier.
• Instances d'équipement BACnet en double. Deux contrôleurs avec le même numéro d'instance provoquent des comportements intermittents et déroutants. Faites un audit avant d'intégrer.
• Écriture à la mauvaise priorité BACnet. Une passerelle qui écrit à une priorité élevée sans jamais la libérer peut bloquer le planning du bâtiment.
• Interrogation trop rapide. Un bus RS-485 partagé peut être saturé par une passerelle trop agressive.
• Noms de topics plats. Des topics comme modbus/40001 sont impossibles à exploiter à grande échelle. Nommez par équipement.

Pour une vue d'ensemble de la façon dont ces éléments s'assemblent dans une usine, le guide de l'IoT industriel avec MQTT détaille de bout en bout l'architecture, les passerelles edge et la modélisation des données.

Démarrer avec ConnectMQ

Une fois que votre passerelle traduit BACnet et Modbus en topics MQTT propres, elle a besoin d'un broker MQTT dans le cloud fiable vers lequel publier. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et connectez votre passerelle en TLS en quelques minutes. ConnectMQ vous offre l'explorateur de topics en direct et les alertes à seuil pour vérifier chaque point dès sa mise en service.

Questions fréquentes

BACnet est-il meilleur que Modbus ?

Aucun n'est meilleur dans l'absolu. BACnet est plus riche et autodescriptif, ce qui convient à l'automatisation du bâtiment ; Modbus est plus simple et quasi universel sur les compteurs, variateurs et automates.

Les équipements BACnet et Modbus peuvent-ils communiquer directement entre eux ?

Non, ce sont des protocoles différents. Il vous faut une passerelle ou un contrôleur qui parle les deux, ou bien vous pouvez les faire remonter tous deux dans MQTT et laisser les consommateurs travailler avec une couche de données unique et normalisée.

Quels ports utilisent BACnet/IP et Modbus TCP ?

BACnet/IP utilise le port UDP 47808 et Modbus TCP le port TCP 502. Aucun des deux ne doit être exposé sur Internet ; envoyez plutôt les données vers l'extérieur via MQTT avec TLS.

BACnet prend-il en charge les mises à jour événementielles ?

Oui, grâce aux abonnements Change of Value (COV), même si la prise en charge varie selon les équipements et les types d'objets. Modbus n'a pas d'équivalent et repose toujours sur l'interrogation.