GTB Multi-protocoles
BACnet, KNX, Modbus, LoRaWAN… faut-il vraiment choisir un seul protocole GTB ? Un bâtiment enfermé dans un système propriétaire coûte cher à faire évoluer : chaque ajout dépend d’un seul fournisseur, chaque intégration devient un projet. Voici comment s’organise réellement une installation GTB, niveau par niveau, et ce que l’interopérabilité change concrètement pour un maître d’ouvrage ou un bureau d’études.
Sur le papier, un système unique paraît rassurant : un seul fournisseur, un seul interlocuteur, une seule facture. Le problème n’apparaît pas à la livraison. Il apparaît trois ans plus tard, quand il faut faire évoluer l’installation.
C’est le moment où l’on découvre que le système choisi ne parle qu’à lui-même :
Ce n’est pas une question de qualité du matériel : les grandes marques du marché sont fiables. C’est une question d’architecture. Un bâtiment a une durée de vie de plusieurs décennies, une GTB de dix à quinze ans, un capteur de cinq à dix ans. Ces cycles ne coïncident jamais. Le multi-protocole, ce n’est pas une prouesse technique : c’est simplement la reconnaissance que ces échéances sont décalées.
Une installation GTB ne se résume pas à un automate et un écran. Elle s’organise en quatre niveaux successifs, du capteur physique jusqu’aux applications métier — et chaque niveau a ses propres protocoles, pour de bonnes raisons techniques.
Un capteur sur pile qui envoie une mesure toutes les dix minutes n’a pas les mêmes contraintes qu’un superviseur qui interroge trois mille points en continu. Vouloir imposer un protocole unique à toute la pile revient à choisir le mauvais outil à au moins un étage.
Le schéma ci-dessous est interactif : survolez un équipement pour découvrir son rôle, des exemples concrets et les protocoles associés.
Survolez un équipement pour afficher son rôle et ses protocoles — touchez un équipement pour l'ouvrir
C'est la couche physique : ce qui touche réellement le bâtiment. Sans mesure fiable à ce niveau, aucune régulation fine ni aucun calcul d'économie n'est possible.
Modbus RTU · KNX · M-Bus · LoRaWAN · DALI
C'est ici que se joue l'essentiel de l'interopérabilité. Chaque équipement arrive avec son propre automate, livré par son constructeur, avec sa propre logique — et son propre protocole.
BACnet MS/TP · BACnet/IP · KNX · Modbus TCP
Le niveau où la donnée devient exploitable. Une GTB qui affiche des valeurs sans les comparer ne sert à rien : c'est l'analyse qui révèle les dérives et justifie les investissements.
BACnet/IP · OPC-UA
Le niveau le plus souvent oublié en conception, et le plus demandé après deux ans d'exploitation. La GTB devient une source de données parmi d'autres, pas une île.
API REST · MQTT · SQL · OCPP · CSV
Trois situations qu’on rencontre sur presque tous les projets de rénovation. Dans chacune, c’est le passage d’un niveau à l’autre qui crée la valeur.
Le multi-protocole n’a rien de magique. En pratique, tout repose sur un principe simple : un équipement expose des points de données, et un intégrateur les traduit vers un langage commun.
Première étape, souvent sous-estimée : identifier ce que chaque équipement sait réellement remonter. Un automate de CTA peut exposer trente points comme trois cents, selon sa configuration d’origine et la documentation du constructeur. C’est ce relevé qui détermine ce que la supervision pourra afficher — et ce qu’elle ne pourra pas.
Quand deux protocoles ne se parlent pas directement, une passerelle assure la traduction. Ce peut être un boîtier physique (Modbus vers BACnet, KNX vers IP) ou un pilote logiciel intégré au superviseur. Le choix dépend du volume de points, de la criticité et de la topologie du site.
Étape invisible mais décisive : deux capteurs de température de marques différentes peuvent remonter la même grandeur sous des noms, des unités et des échelles différentes. Sans convention de nommage cohérente, la supervision affiche des valeurs justes mais incomparables entre elles. C’est ce travail qui rend l’analyse possible plus tard.
Cette architecture multi-protocole, nous la déployons sur des installations réelles : supervision GTB Niagara N4 / iSMA, où comptage énergie multi-points, automates de zone et centrale d’alarme coexistent dans un même tableau de bord.
Nous intervenons en direct auprès des maîtres d’ouvrage comme en sous-traitance spécialisée pour des entreprises générales et des bureaux d’études, sur des projets de toutes tailles.
Un audit de 30 minutes suffit à le déterminer, et à vous donner un chiffrage réaliste avant tout engagement · Expert GTB multi-protocoles · Bourgogne-Franche-Comté