La question « plateforme IoT ou broker MQTT » déroute de nombreuses équipes, car les deux se recoupent et les éditeurs emploient ces termes de façon floue. Cet article sépare clairement les couches, explique ce qu'une plateforme IoT complète ajoute à un broker et vous donne une méthode pratique pour décider si vous avez besoin d'une plateforme ou si un broker MQTT managé léger, complété par quelques outils ouverts, couvre votre projet.
Deux couches différentes
Un broker MQTT est un routeur de messages. Les clients se connectent, publient des messages sur des topics et s'abonnent à des topics ; le broker livre chaque message à tous les abonnés correspondants avec la QoS demandée. Il gère les sessions, les retained messages, les messages de testament et, avec MQTT 5, des fonctionnalités comme les abonnements partagés et l'expiration des messages. Pour un rappel, lisez le rôle d'un broker MQTT.
Une plateforme IoT est un ensemble de services construits autour d'un cœur de messagerie. Selon le produit, elle ajoute tout ou partie des éléments suivants :
- Registre des appareils, provisioning et gestion des identités.
- Services d'état des appareils comme les shadows ou les twins.
- Orchestration des mises à jour de firmware à distance (OTA).
- Moteurs de règles qui filtrent, transforment et routent les données.
- Stockage de séries temporelles et requêtes historiques.
- Tableaux de bord, alarmes et notifications.
- Gestion des utilisateurs, multi-tenancy pour vos propres clients et API applicatives.
De nombreuses plateformes incluent un endpoint MQTT, parfois un broker complet, parfois une passerelle appareil-vers-cloud aux topics fixes. La valeur de la plateforme réside dans l'intégration de toutes ces briques.
Plateforme IoT ou broker MQTT : la comparaison
| Capacité | Broker MQTT seul | Plateforme IoT complète | Broker léger et outils ouverts |
|---|---|---|---|
| Pub/sub en temps réel | Oui | En général, parfois uniquement appareil-vers-cloud | Oui |
| Identité des appareils | Identifiants par client | Registre avec cycle de vie | Identifiants plus votre propre inventaire |
| État des appareils | Retained messages | Service de shadow ou de twin | Topics d'état retenus |
| Traitement des données | Non | Règles intégrées | Node-RED, petits services |
| Stockage et historique | Non | Intégré | InfluxDB, TimescaleDB, PostgreSQL |
| Tableaux de bord | Console du broker uniquement | Intégrés | Grafana, Node-RED Dashboard |
| Alertes | Selon le broker | Intégrées | Alertes du broker ou alerting Grafana |
| Mises à jour de firmware | Non | Souvent intégrées | Outillage OTA séparé |
| Portabilité | Élevée | Souvent plus faible | Élevée |
| Effort de démarrage | Faible | Faible à moyen | Moyen |
La colonne du milieu est pratique mais impose ses choix. Celle de droite demande un peu plus d'assemblage mais laisse chaque élément remplaçable.
Quand une plateforme IoT complète est le bon choix
Une plateforme justifie son coût et ses contraintes lorsque :
- Vous avez besoin d'une gestion du cycle de vie des appareils à grande échelle, comme le provisioning en masse, la rotation des certificats et des mises à jour OTA progressives sur de nombreux types d'appareils.
- Vous manquez de personnes pour intégrer des composants et voulez qu'un seul éditeur soit responsable de toute la pile.
- Votre back-end vit déjà dans le cloud de cette plateforme et vous voulez que les données y arrivent avec un minimum de code d'intégration.
- Vous construisez un produit multi-clients et le modèle de tenants, d'utilisateurs et d'API de la plateforme correspond au vôtre.
Dans ces cas, choisissez la plateforme en connaissance de cause et lisez dépendance fournisseur MQTT pour garder le firmware des appareils aussi portable que possible.
Quand un broker léger suffit
Un broker MQTT managé associé à quelques outils ouverts est souvent le meilleur choix lorsque :
- Votre besoin principal est la circulation de données en direct entre machines, passerelles, applications et tableaux de bord.
- Vous utilisez déjà des outils comme Node-RED, Grafana, Telegraf ou une base de données de séries temporelles.
- Vous construisez un Unified Namespace et voulez maîtriser entièrement la hiérarchie de topics.
- Vous tenez à la portabilité entre clouds et systèmes sur site.
- Votre flotte est modeste et la gestion des appareils peut tenir dans un simple inventaire.
ConnectMQ est conçu pour ce schéma. C'est un broker MQTT managé avec MQTT 3.1.1 et 5.0, TLS et Secure WebSocket, et un portail qui couvre plusieurs fonctions de base « façon plateforme » sans devenir une plateforme : un client MQTT dans le navigateur, un explorateur de topics en direct, un tableau de bord, une vue des appareils par niveaux ISA-95, des règles d'alerte sur seuil avec journal des alertes, ainsi que le décodage de Sparkplug B et sa republication dans des topics ISA-95. Il n'inclut volontairement ni moteur de règles, ni webhooks, ni bridges vers des bases de données ; ces tâches reviennent à des outils externes.
Une architecture de référence légère
Une pile courante, entièrement ouverte, autour d'un broker MQTT managé ressemble à ceci :
Devices / PLC gateways --MQTT/TLS--> Managed MQTT broker (ConnectMQ)
|
+-------------------------------+-----------------------------+
| | |
Telegraf (mqtt_consumer) Node-RED flows Browser apps (WSS 8084)
| (logic, alerts, APIs)
InfluxDB (time series)
|
Grafana (dashboards, alerting)
Chaque composant se connecte au broker comme un client MQTT ordinaire. Vous pouvez remplacer n'importe lequel d'entre eux sans toucher aux appareils.
Exemple : stocker la télémétrie avec Telegraf
L'entrée MQTT consumer de Telegraf peut s'abonner à votre broker et écrire dans InfluxDB uniquement par configuration :
# telegraf.conf
[[inputs.mqtt_consumer]]
servers = ["ssl://broker.connectmq.com:8883"]
topics = ["acme/plant1/+/+/telemetry"]
qos = 1
client_id = "YOUR_CLIENT_ID"
username = "YOUR_USERNAME"
password = "YOUR_PASSWORD"
data_format = "json"
topic_tag = "topic"
[[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
token = "${INFLUX_TOKEN}"
organization = "acme"
bucket = "telemetry"
Lancez-le et vérifiez que les points arrivent :
export INFLUX_TOKEN=your-influx-token
telegraf --config telegraf.conf --test # vérification ponctuelle du parsing
telegraf --config telegraf.conf # exécution en continu
Avec des payloads JSON comme {"temp": 72.4, "rpm": 1450}, les champs numériques deviennent des champs InfluxDB et le topic devient un tag sur lequel filtrer dans Grafana. N'oubliez pas que chaque connexion simultanée a besoin de ses propres identifiants et de son propre client ID ; sur ConnectMQ, les client ID sont liés aux identifiants délivrés.
Les coûts cachés des deux côtés
Aucune des deux voies n'est exempte de compromis, et il est utile de les nommer avant de décider.
Avec une plateforme complète, les coûts cachés sont généralement conceptuels et contractuels. Votre équipe apprend le modèle d'appareils, de règles et d'état de la plateforme, et ce savoir ne se transpose pas ailleurs. La tarification augmente souvent sur plusieurs dimensions à la fois, comme les connexions, les messages, les exécutions de règles et le stockage, ce qui complique les prévisions. Et les fonctionnalités que vous n'utilisez pas influencent malgré tout la conception de celles que vous utilisez.
Avec un broker léger et des outils, les coûts cachés sont opérationnels. Quelqu'un doit exploiter Node-RED, la base de séries temporelles et Grafana, les tenir à jour et les sauvegarder. Les décisions d'intégration, comme le nommage des topics et les formats de payload, sont à vous de documenter et de faire respecter. Pour une petite équipe, c'est gérable ; pour une grande organisation sans équipe plateforme, cela peut vite s'éparpiller.
Le test pratique consiste à esquisser les deux prochaines années : combien d'appareils, quelles destinations de données et qui maintient chaque brique. L'option dont la charge de maintenance correspond à votre équipe est généralement la bonne.
Liste de décision
Répondez à chaque question par oui ou par non :
- Avez-vous besoin d'orchestrer des mises à jour OTA sur une grande flotte depuis une seule console ?
- Avez-vous besoin d'un registre d'appareils avec des états de cycle de vie allant au-delà d'une liste d'identifiants ?
- Les données doivent-elles arriver automatiquement dans les services d'un cloud précis ?
- Manquez-vous de personnes à l'aise pour exploiter Node-RED, Grafana ou un petit service ?
- Avez-vous besoin d'une couche applicative multi-tenant prête à l'emploi pour vos propres clients ?
Majorité de oui : évaluez des plateformes IoT complètes. Majorité de non : commencez par un broker MQTT managé léger et ajoutez des outils au fil des besoins. De nombreuses équipes combinent aussi les deux, en utilisant un broker comme épine dorsale temps réel neutre et une plateforme pour une tâche précise comme les mises à jour OTA.
Pour des comparaisons plus poussées, consultez alternative à AWS IoT Core et alternative à Azure IoT Hub, qui examinent deux plateformes bien connues sous cet angle.
Commencez avec un broker MQTT managé léger
Vous pouvez valider l'approche légère en un après-midi. Créez un broker Serverless gratuit sans carte bancaire, connectez un appareil et pointez Telegraf ou Node-RED vers lui. Pour un tout premier essai sans compte, le serveur MQTT public gratuit suffit, à condition de n'y envoyer que des données de test, jamais de données de production. Le guide du broker MQTT cloud explique les options de déploiement à mesure que votre projet grandit, et connectmq.com présente l'ensemble des plans, de Serverless à Dedicated, BYOC et Self Managed Enterprise.
Questions fréquentes
Un broker MQTT est-il une plateforme IoT ?
Non. Un broker route des messages entre des clients. Une plateforme IoT associe une couche de messagerie à la gestion des appareils, au stockage, aux règles et aux tableaux de bord.
Puis-je construire une solution IoT avec seulement un broker MQTT ?
Oui, avec quelques outils externes. Un broker associé à Node-RED, une base de séries temporelles et Grafana couvre de nombreux projets de supervision et de pilotage.
ConnectMQ inclut-il un moteur de règles ou des intégrations de bases de données ?
Non. Les intégrations fonctionnent comme des clients MQTT externes, par exemple Node-RED, Telegraf ou vos propres services, ce qui les garde portables.
Puis-je utiliser ensemble une plateforme IoT et un broker MQTT séparé ?
Oui. De nombreuses équipes utilisent un broker neutre comme épine dorsale temps réel et une plateforme pour des tâches précises comme les mises à jour de firmware ou le provisioning des appareils.
