Logiciel de supervision HWgroup SensDesk, tableau de bord des capteurs et alarmes

Les capteurs et les passerelles ne sont que la moitié d'un projet de bâtiment connecté. L'autre moitié est logicielle : il faut recevoir les données, les décoder, les stocker, les afficher, déclencher des alertes et, souvent, les transmettre à d'autres systèmes. C'est le rôle de la plateforme IoT, aussi appelée logiciel smart building, hyperviseur ou plateforme de supervision selon les fournisseurs.

Le choix est souvent fait trop tard, une fois les capteurs commandés. Ce guide présente la place de la plateforme dans l'architecture, les grandes familles de solutions et les critères pour choisir.

La place de la plateforme dans l'architecture

Une chaîne de données de bâtiment comprend en général six étapes :

  1. La mesure : capteurs, compteurs, automates.
  2. Le transport : réseau LoRaWAN, NB-IoT, Ethernet, bus de terrain.
  3. Le serveur réseau pour les technologies radio comme le LoRaWAN : il authentifie les capteurs et déduplique les messages. Il peut être intégré à la passerelle ou hébergé à part.
  4. Le décodage : la trame binaire du capteur est convertie en valeurs lisibles (température, CO2, index).
  5. Le stockage, la visualisation et les alertes : c'est le cœur de la plateforme.
  6. L'intégration vers d'autres systèmes : GTB, outil de maintenance, tableur, entrepôt de données.

Selon les projets, ces étapes sont réparties entre la passerelle, un serveur local et un service cloud. Une passerelle LoRaWAN récente comme la Milesight UG65 embarque son serveur réseau et peut publier directement en MQTT, en HTTP ou en BACnet : la plateforme reçoit alors des données déjà décodées.

Les grandes familles de plateformes

Les plateformes des constructeurs

Chaque fabricant d'équipements propose souvent son logiciel, optimisé pour ses produits. Exemples au catalogue :

  • HWgroup SensDesk : supervision des boîtiers et capteurs HWgroup, installable sur votre serveur ou en abonnement cloud, avec alertes e-mail, SMS et appel, et une Open API SNMP et XML.
  • Efento Cloud : supervision des capteurs Efento Bluetooth et NB-IoT, rapports PDF et CSV, API RESTful et webhooks, hébergement Amazon Web Services avec données conservées à Dublin et Francfort.
  • ControlByWEB Cloud : accès centralisé aux contrôleurs ControlByWEB, comptes hiérarchisés sur cinq niveaux et API REST ouverte.
  • AKCPro Server : supervision centralisée des boîtiers AKCP sur serveur Windows, avec cartes 2D et 3D et capteurs virtuels SNMP et Modbus pour les équipements tiers.

Atout : mise en route rapide et fonctions adaptées au matériel. Limite : la couverture des autres marques est souvent partielle.

Les plateformes de gestion de parc

Elles ne visualisent pas les mesures du bâtiment mais administrent les équipements réseau : état, mises à jour, accès distant. Robustel RCMS gère ainsi un parc de routeurs et passerelles Robustel, avec mises à jour signées, provisionnement automatique et accès VPN sans IP fixe. Elles complètent la plateforme de données, elles ne la remplacent pas.

Les hyperviseurs et plateformes multi-marques

Ils agrègent des sources variées : capteurs LoRaWAN de plusieurs fabricants, compteurs, GTB de plusieurs sites, données de facturation. Ils visent le gestionnaire de patrimoine qui veut une vue unique de ses bâtiments. Le point clé est la bibliothèque de décodeurs et de connecteurs : vérifiez que chacun de vos équipements est pris en charge.

Les solutions open source

Des briques libres permettent de construire sa propre chaîne : ChirpStack comme serveur réseau LoRaWAN, Node-RED pour décoder et router les données, une base de séries temporelles et un outil de tableaux de bord comme Grafana, ou une plateforme IoT complète comme l'édition communautaire de ThingsBoard. Atouts : pas de licence, maîtrise totale et hébergement où vous le souhaitez. Limite : il faut des compétences pour installer, sécuriser, sauvegarder et maintenir l'ensemble dans la durée.

Le traitement en périphérie

Une passerelle edge exécute une partie des traitements sur site : décodage, règles d'alerte, calculs, mise en mémoire tampon en cas de coupure. La Milesight EG71 embarque Node-RED, Docker et un SDK Python ; la Robustel EG5100 fonctionne sous un système basé sur Debian avec Docker ; l'Elastel EG500 repose sur un Raspberry Pi Compute Module 4 avec LoRaWAN et 4G en option ; le Dragino MS20 est une base Linux open source avec Node-RED préinstallé. Voir la catégorie passerelles edge computing et la gamme Robustel passerelles edge.

Cloud, sur site ou open source : le comparatif

CritèreCloud du fournisseurLogiciel sur siteOpen source auto-hébergé
Mise en routeRapideInstallation sur un serveurInstallation et paramétrage complets
MaintenanceAssurée par le fournisseurPar votre service informatiquePar vos équipes ou un prestataire
Hébergement des donnéesChez le fournisseur, localisation à vérifierDans vos locauxOù vous le décidez
Accès Internet requisOuiNon, si usage localSelon l'architecture
Multi-marquesVariableVariableOui, avec du développement
LicenceAbonnementLicence logiciellePas de licence, coûts d'exploitation
Adapté àDéploiement rapide, multisiteSites sensibles, réseau ferméÉquipes techniques, besoins spécifiques

À retenir

  • La plateforme se choisit en même temps que les capteurs, pas après.
  • Le cloud accélère la mise en route ; le sur site et l'open source donnent la maîtrise de l'hébergement.
  • La prise en charge de chaque équipement par un décodeur ou un connecteur est le premier point à vérifier.

Les critères de choix

Les sources de données

Listez tous les équipements à raccorder, avec leur protocole : LoRaWAN, NB-IoT, Modbus, BACnet, SNMP, MQTT. Pour chaque capteur radio, vérifiez qu'un décodeur existe dans la plateforme ou qu'il peut être ajouté. Notre testeur de décodeur LoRaWAN permet de vérifier un décodeur sur une trame réelle.

Les utilisateurs

Exploitant technique, gestionnaire immobilier, prestataire de maintenance, occupants : chacun a besoin de vues et de droits différents. Vérifiez la gestion des profils, des sites et des équipes.

Les alertes

Destinataires, canaux (e-mail, SMS, notification, webhook), escalade, acquittement avec commentaire, détection du silence d'un capteur : ce sont ces fonctions qui transforment une plateforme en outil d'exploitation.

L'ouverture

API documentée, export CSV, connecteurs MQTT ou BACnet vers la GTB : la plateforme ne doit pas être une impasse. Prévoyez aussi la réversibilité : comment récupérer l'historique si vous changez de solution ?

L'hébergement et la sécurité

Localisation des données, chiffrement, authentification forte, journal d'audit, séparation entre réseau de gestion technique et réseau bureautique. Pour les capteurs d'occupation, la protection des données personnelles doit être examinée avec votre délégué à la protection des données.

L'exploitation dans la durée

Qui met à jour la plateforme, qui ajoute les capteurs, qui gère les comptes ? Une plateforme puissante mais sans responsable désigné finit rarement bien.

Trois architectures types

Avant de détailler ces architectures, un rappel utile : une même plateforme peut recevoir à la fois des capteurs sans fil, des compteurs et des boîtiers de supervision filaires. Par exemple, un boîtier HWgroup Perseus qui expose ses mesures en Modbus TCP, en SNMP ou en MQTT peut alimenter la même base de données que des capteurs LoRaWAN décodés par la passerelle. C'est l'homogénéité des noms de points et des unités, plus que le protocole, qui fait la qualité de l'exploitation.

  1. Petit tertiaire ou site unique : passerelle LoRaWAN avec serveur réseau intégré, plateforme cloud du fournisseur pour les tableaux de bord et les alertes. Mise en route en quelques jours.
  2. Parc multisite : une passerelle par bâtiment, données publiées en MQTT vers un hyperviseur central, gestion de parc des passerelles et routeurs pour la maintenance à distance.
  3. Site sensible ou réseau fermé : serveur réseau et plateforme sur site, sans flux vers Internet, avec remontée en BACnet ou Modbus vers la GTB locale.

Les pièges à éviter

  • Multiplier les plateformes : une par marque de capteur, et plus personne ne regarde aucune d'elles.
  • Oublier les décodeurs : un capteur sans décodeur dans la plateforme ne produit que des trames illisibles.
  • Négliger la réversibilité : sans export des historiques, changer de solution revient à repartir de zéro.
  • Sous-estimer la maintenance d'une solution auto-hébergée : sauvegardes, mises à jour de sécurité, supervision du serveur lui-même.

Les questions à poser au fournisseur

Avant de retenir une plateforme, faites remplir à chaque fournisseur une grille identique :

  1. Quels équipements de ma liste sont déjà pris en charge, et qui écrit les décodeurs manquants ?
  2. Quels protocoles d'entrée sont acceptés : MQTT, HTTP, BACnet, Modbus, SNMP, intégrations directes avec un serveur réseau LoRaWAN ?
  3. Combien de temps l'historique est-il conservé, avec quelle résolution, et comment l'exporter ?
  4. Où sont hébergées les données, et qui peut y accéder ?
  5. Comment sont gérés les comptes, les droits et l'authentification ?
  6. Quelles alertes sont possibles, sur quels canaux, avec quelle escalade ?
  7. Une API est-elle documentée, et avec quelles limites d'usage ?
  8. Comment le modèle de licence évolue-t-il avec le nombre de capteurs, de sites ou d'utilisateurs ?
  9. Que se passe-t-il en cas de coupure Internet : les passerelles conservent-elles les données ?
  10. Quelle est la feuille de route du produit, et depuis combien de temps est-il commercialisé ?

Les réponses à ces questions pèsent souvent plus que la richesse des tableaux de bord présentés en démonstration.

Notre accompagnement

Nous pouvons vous aider à choisir l'architecture, préconfigurer les passerelles, développer les décodeurs manquants ou des flux Node-RED pour router les données vers votre plateforme. Le détail est sur notre page Services. Pour le choix du matériel en amont, voir nos articles choisir une passerelle LoRaWAN, quels capteurs pour un smart building et notre comparatif LoRaWAN, NB-IoT et LTE-M. Les logiciels du catalogue sont réunis dans la catégorie logiciels et plateformes cloud.

Questions fréquentes

Quelle différence entre une plateforme IoT et une GTB ?

La GTB pilote les équipements techniques du bâtiment : chauffage, ventilation, éclairage. La plateforme IoT collecte, stocke et affiche des données de capteurs et de compteurs, et déclenche des alertes. Les deux se complètent souvent : la plateforme peut transmettre des mesures à la GTB en BACnet ou en Modbus.

Existe-t-il des plateformes IoT open source pour le smart building ?

Oui. Des briques comme ChirpStack pour le serveur réseau LoRaWAN, Node-RED pour le traitement et Grafana pour les tableaux de bord, ou une plateforme complète comme l'édition communautaire de ThingsBoard, permettent de construire une solution sans licence. Elles demandent des compétences pour l'installation et la maintenance.

Faut-il un serveur réseau LoRaWAN séparé ?

Pas forcément. Plusieurs passerelles, comme la Milesight UG65, intègrent un serveur réseau et publient directement les données décodées. Un serveur séparé devient utile avec de nombreuses passerelles ou plusieurs sites.

Où sont hébergées les données dans le cloud ?

Cela dépend du fournisseur. Efento indique par exemple un hébergement Amazon Web Services avec données conservées à Dublin et Francfort. Posez la question pour chaque plateforme, en particulier pour les données d'occupation.

Peut-on changer de plateforme plus tard ?

Oui, si les équipements utilisent des protocoles standards et si la plateforme permet d'exporter l'historique. C'est un critère à vérifier avant de signer.

Votre projet

Décrivez-nous vos équipements, le nombre de sites et vos contraintes d'hébergement : nous vous proposons l'architecture et les équipements adaptés sous 24 h ouvrées, ou contactez-nous.

Produits cités dans cet article