Tridium Niagara vs IronFlock : comparaison des frameworks ouverts (2026)

Le Niagara Framework de Tridium (filiale de Honeywell depuis 2005) est le standard de fait de l’intégration multi-constructeurs en gestion technique du bâtiment. Fondée en 1996, Tridium a conçu Niagara comme un framework Java qui normalise BACnet, Modbus, LonWorks, KNX et des dizaines d’autres protocoles dans un modèle objet unique, puis les restitue sous forme de synoptiques, d’historiques et de logique de régulation. Il s’exécute sur les contrôleurs JACE, sur le contrôleur de terrain Niagara Edge 10 et sur les serveurs Niagara Supervisor, et il est revendu sous de nombreuses marques OEM — Vykon, Honeywell, Centraline, KMC, Distech, Lynxspring et d’autres — sous la bannière « Powered by Niagara ». Les équipes qui cherchent une alternative à Niagara veulent généralement la même ouverture protocolaire sans licences au point, sans le passage obligé par un intégrateur certifié et sans un modèle de développement à base de modules Java.

IronFlock atteint la même ouverture par un autre chemin : au lieu de tout normaliser dans un framework tournant sur les contrôleurs d’un seul fournisseur, IronFlock exécute des applications conteneurisées Docker sur n’importe quel matériel Linux ou Windows, relié à des services centraux (FleetDB, orchestration IA, tableaux de bord) via un bus de messages WAMP temps réel.

Les deux systèmes sont agnostiques aux protocoles par conception, tous deux placent le calcul en périphérie et tous deux visent des flottes multi-sites. Les différences portent sur la manière d’étendre le système, sur qui a le droit de l’acheter et de le mettre en œuvre, sur le stockage et la tarification des données, et sur la présence ou non de l’IA dans la plateforme.

Cette page propose une comparaison honnête pour aider les équipes à choisir le bon système.

En un coup d’œil

Architecture

Niagara : un framework Java sur des contrôleurs sous licence

L’architecture de Niagara s’articule autour de la station — une instance Niagara en cours d’exécution qui héberge les pilotes, un arbre de composants, la logique de régulation, les historiques et les synoptiques :

• Contrôleurs JACE : le JACE 8000 (basé QNX) et le plus récent JACE 9000 sont les contrôleurs superviseurs qui exécutent les stations en périphérie, dialoguent avec les équipements de terrain et bufferisent les historiques localement. Le Niagara Edge 10 est un contrôleur de terrain IP à 10 points qui exécute Niagara 4 au plus près des équipements (licencié pour 3 appareils et 50 points).
• Niagara Supervisor : une station sur serveur Windows ou Linux qui agrège les données de nombreux JACE, archive les historiques, sert les synoptiques d’entreprise et exécute des travaux de provisioning par lots (mises à jour logicielles, sauvegardes, réglages TLS) sur toute la flotte de JACE.
• Niagara Workbench : l’outil d’ingénierie Java pour poste de travail. Toute l’ingénierie — configuration des pilotes, mappage des points, logique graphique wire sheet, pages de synoptiques Px — se fait dans Workbench connecté à une station.
• Pilotes : BACnet, Modbus TCP/RTU, LonWorks, KNX, SNMP, oBIX, OPC UA et MQTT sont livrés comme pilotes Niagara sous licence ; des centaines d’autres proviennent d’éditeurs tiers via le Niagara Marketplace. Cette bibliothèque de pilotes est le plus grand atout de Niagara.
• Modules : les extensions sont des modules JAR Java installés dans une station. Sous Niagara 5, les modules doivent être signés et tous les modules N4 doivent être refondus.
• Niagara Cloud Suite : un ensemble d’abonnements ajoutés par-dessus — Niagara Data Service (historisation cloud plus API de lecture/écriture sur les données de station), Niagara Recover (sauvegardes cloud des stations, cinq instantanés en rotation) et Niagara Remote (accès distant aux stations sans VPN côté client). Tous exigent un contrat de maintenance logicielle (SMA) actif.
• Niagara conteneurisé : depuis la 4.13, Niagara est livré sous forme de conteneur Docker regroupant le cœur Niagara, la JRE et les modules requis, pour x86-64 et Arm64 — destiné à faire tourner Niagara lui-même dans le cloud ou sur du matériel tiers, avec une licence par abonnement.

Notez le sens de cette conteneurisation : Niagara peut être empaqueté en conteneur, mais une station Niagara n’est pas un endroit où exécuter des charges de travail conteneurisées quelconques.

IronFlock : Edge distribué + Services centraux

IronFlock est un système distribué à deux couches complémentaires. Des appareils edge autonomes exécutent un agent léger et des applications conteneurisées Docker au plus près du terrain. Les services centraux — FleetDB (TimescaleDB), le FleetDB Service, l’orchestration IA et l’interface web — assurent le stockage des données de la flotte, les tableaux de bord et l’intelligence. Un bus de messages WAMP relie l’ensemble en pub/sub et RPC temps réel.

Vous pouvez également provisionner des appareils virtuels — des nœuds de calcul hébergés dans le cloud qui rejoignent votre projet aux côtés des appareils physiques, pour exécuter des services à l’échelle de la flotte comme Grafana, Node-RED, Jupyter ou vos propres pipelines de données.

• Appareils edge : tout matériel capable d’exécuter Linux ou Windows — Raspberry Pi, PC industriels, NVIDIA Jetson, IPC Windows, passerelles — exécutant des applications de façon autonome (sous Windows, l’agent tourne en service natif avec redémarrage automatique et mise à jour autonome)
• Applications : conteneurs Docker dans n’importe quel langage, déployés sur des appareils edge ou virtuels
• Données : les applications edge publient la télémétrie via le bus de messages vers FleetDB, qui provisionne automatiquement des tables TimescaleDB par projet, interrogeables en SQL
• Services centraux : le FleetDB Service traite les flux de données, évalue les alarmes et sert les tableaux de bord ; le service IA orchestre des conversations multi-agents avec accès direct aux appareils
• Déploiement : cloud SaaS ou on-premises — toute la plateforme peut tourner dans votre propre infrastructure

Ce que cela signifie en pratique

Comparaison des fonctionnalités

Données et connectivité

Visualisation et tableaux de bord

Accès à distance et sécurité

Développement d’applications

IA et analytique

Gestion des appareils et de la flotte

Alarmes et notifications

Comparaison des prix

Niagara : licences par appareil/par point + maintenance obligatoire

Niagara se licencie par station, dimensionnée selon l’étendue de ce qu’elle raccorde :

• Licences de station : les licences JACE sont paliers selon la capacité en appareils et en points — par exemple 5 appareils / 250 points, 10 / 500, 25 / 1 250, 100 / 5 000 et 200 / 10 000 sur le JACE 8000. Les points se convertissent aussi en équivalents appareils (environ 50 points pour un appareil) pour la licence. Dépasser son palier signifie acheter une licence plus grande.
• Niagara Edge 10 : licencié pour 3 appareils et 50 points — dimensionné pour un seul équipement.
• Licences Supervisor : dimensionnées selon le nombre de stations et de points raccordés.
• Matériel : contrôleurs JACE 8000 / JACE 9000, contrôleurs de terrain Edge 10 et serveurs Supervisor, achetés via le canal OEM.
• SMA (contrat de maintenance logicielle) : exigé à la licence initiale (durée initiale typiquement de 18 mois) et nécessaire pour rester à jour. Sans SMA actif, ni mise à niveau de version, ni correctif de sécurité — et les abonnements Niagara Cloud Suite exigent un SMA actif pendant toute leur durée.
• Options : Niagara Analytics Framework (licencié au point analytique), Niagara Enterprise Security, pilotes tiers de la marketplace et abonnements Niagara Cloud Suite (Data Service, Recover, Remote) — Remote est facturé par contrôleur et par an.
• Certification et migration : la certification Niagara est un prérequis à l’achat d’une licence. Le passage de Niagara 4 à Niagara 5 exige un SMA actif et peut impliquer des frais de migration ; le matériel JACE 8000 ne peut pas être mis à niveau vers Niagara 5.

Comme tout est compté en appareils et en points, le coût suit la taille de l’installation, pas la valeur que vous tirez des données. Et comme le commerce passe par des intégrateurs certifiés, il n’existe aucun parcours en self-service : chaque déploiement commence par une discussion avec le canal de distribution.

IronFlock : cloud gratuit + abonnement pour l’on-premises

La version cloud d’IronFlock est gratuite — toutes les fonctionnalités de base (gestion des appareils, tableaux de bord, stockage de données, mises à jour OTA, alarmes, accès distant, déploiement d’applications) sont incluses sans frais. IronFlock facture à la consommation de ressources : stockage, sessions d’accès distant, appareils virtuels et usage de l’IA. Aucun comptage de points, aucune licence par palier d’appareils, aucun contrat de maintenance obligatoire. Voir la page tarifs pour le détail.

Des capacités supplémentaires peuvent être ajoutées en achetant des applications sur la marketplace — connecteurs de protocoles spécialisés, outils d’analyse ou solutions métier développées par IronFlock ou des éditeurs tiers.

Pour les déploiements on-premises (air-gapped ou infrastructure privée), IronFlock propose une licence par abonnement.

Quand choisir Niagara

Niagara peut être le meilleur choix si :

• Votre projet est d’abord de la gestion technique du bâtiment — l’intégration BACnet, LonWorks et KNX à travers le CVC, l’éclairage, le comptage et le contrôle d’accès est exactement ce pour quoi Niagara a été conçu, et rien n’égale sa profondeur de pilotes sur ce terrain.
• Vous avez besoin d’un pilote sur étagère pour un protocole exotique — le Niagara Marketplace a accumulé des centaines de pilotes en deux décennies.
• Vous travaillez avec un intégrateur Niagara certifié de confiance, ou vous disposez d’ingénieurs certifiés en interne et d’une infrastructure JACE existante.
• Votre cahier des charges impose Niagara — de nombreux appels d’offres publics et de campus nomment le framework directement, précisément parce qu’il évite l’enfermement chez un fabricant au niveau des équipements.
• Vous voulez des synoptiques bâtiment riches et des workflows d’alarme matures (masquage, escalade, classes d’alarme) prêts à l’emploi.
• Vous avez besoin de tagging sémantique et de modèles Project Haystack sur un large parc d’équipements techniques.
• Vous préférez le modèle du canal OEM — un partenaire local qui spécifie, réalise, met en service et maintient le système dans un seul contrat.

Quand choisir IronFlock comme alternative à Niagara

IronFlock est le meilleur choix quand :

• Vous voulez exécuter de véritables applications en périphérie — des conteneurs Docker dans n’importe quel langage, pas des modules Java contraints par l’API d’un framework.
• Vous avez besoin d’une IA intégrée — requêtes en langage naturel sur les données de la flotte, orchestration multi-agents et IA physique qui exécute des fonctions sur les appareils.
• La licence au point ne correspond pas à vos données — télémétrie machine haute fréquence, vision ou vibrations seraient économiquement absurdes facturées en points Niagara.
• Vous voulez du self-service — créer un compte et connecter un appareil aujourd’hui, sans cours de certification ni partenaire de distribution comme préalable.
• Vous voulez vos données dans une base ouverte — TimescaleDB par projet avec accès SQL direct, plutôt que des historiques de station sur fichiers plus un abonnement cloud pour y accéder.
• Vous avez besoin d’opérations de flotte sur toute la pile — mises à jour OS, agent et applications diffusées à distance depuis un seul plan de contrôle, pas seulement le provisioning du logiciel Niagara.
• Vous voulez l’accès distant inclus — tunneling HTTP, SSH, VNC, TCP et UDP intégré à la plateforme, plutôt qu’un abonnement par contrôleur conditionné à un contrat de maintenance actif.
• Vous construisez des machines et des équipements, pas des bâtiments — IronFlock est conçu pour les flottes OEM qui livrent des services numériques à leurs propres clients, avec isolation des données par client.
• Vous voulez des mises à jour de sécurité comme allant de soi, et non comme un avantage qui expire avec un contrat de maintenance.
• Vous voulez créer et monétiser des applications — empaqueter votre expertise métier et la vendre sur une marketplace ouverte, sans barrière de certification côté développeur.

Chemin de migration

IronFlock et Niagara cohabitent sans heurt, car ils se rencontrent au niveau des données plutôt que de se disputer les mêmes câbles. Le schéma courant consiste à laisser les stations Niagara faire ce qu’elles font bien — intégration BACnet et LonWorks, séquences de régulation du bâtiment, synoptiques locaux — et à ajouter IronFlock pour tout ce que Niagara n’a jamais eu vocation à porter : applications conteneurisées, télémétrie machine haute fréquence, données de flotte accessibles en SQL, accès distant par navigateur et IA.

Concrètement, cela revient à faire tourner un agent IronFlock sur un PC industriel ou un appareil edge du même site, en lisant la station via BACnet, Modbus ou MQTT, ou en s’abonnant aux données qu’elle publie déjà. À partir de là, les tableaux de bord de flotte, les alarmes, les tunnels et l’IA s’appliquent aux données issues de Niagara comme à toutes les autres. Avec le temps, les nouveaux équipements et les nouveaux sites peuvent être raccordés sans ajouter de licences de points Niagara, pendant que le parc existant continue de fonctionner.

Prêt à essayer ? Commencez gratuitement — connectez un appareil et voyez votre premier tableau de bord en quelques minutes.