Pourquoi MQTT s’est imposé dans l’IoT industriel
L’IoT industriel génère des millions de mesures par jour : capteurs qui remontent toutes les minutes, automates qui envoient des états toutes les secondes, compteurs qui transmettent des index horaires. Ces flux de données doivent être transmis de façon fiable, légère et sécurisée.
MQTT répond exactement à ces besoins :
- Ultra-léger — en-tête de 2 à 5 octets. HTTP/REST génère des centaines d’octets de headers pour un payload de quelques octets.
- Connexion persistante — la gateway se connecte une fois au broker et maintient la connexion. Pas de handshake TCP à chaque message.
- Publish/Subscribe — plusieurs abonnés (supervision cloud, ERP, BI) peuvent recevoir les mêmes données sans que la gateway le sache.
- QoS configurable — selon la criticité des données.
- Résilience — les messages sont stockés si le client est temporairement déconnecté (retain, persistent session).
Architecture MQTT industrielle
Topics MQTT : structure et bonnes pratiques
Un topic MQTT est une chaîne hiérarchique séparée par des / :
eziwan/{site_id}/{équipement}/{variable}
Exemples :
eziwan/site-pompage-01/automate/pression_refoulement
eziwan/site-pompage-01/compteur/energie_kwh
eziwan/batiment-paris/cvc/temperature_zone_a
Bonnes pratiques de nommage :
- Toujours inclure l’identifiant de site pour filtrer par site.
- Séparer les types de données (mesure, état, alarme, commande) dans des topics distincts.
- Utiliser des noms lisibles, pas des codes opaques.
- Éviter les topics trop larges (
eziwan/#) pour les abonnements en production.
Niveaux de QoS : quel choix pour l’industrie ?
| QoS | Garantie | Overhead | Usage recommandé |
|---|---|---|---|
| 0 | Au plus une fois (best-effort) | Minimal | Mesures fréquentes (1/s), perte OK |
| 1 | Au moins une fois (avec accusé) | Faible | Supervision standard, alertes |
| 2 | Exactement une fois (4 échanges) | Moyen | Commandes, données critiques |
Pour la supervision IoT industrielle typique (mesures toutes les 5 à 60 secondes), QoS 1 est le bon compromis : fiabilité suffisante, overhead acceptable.
MQTT vs HTTP pour l’IoT : comparatif
| Critère | MQTT | HTTP/REST |
|---|---|---|
| Modèle | Publish/Subscribe | Requête/Réponse |
| Taille overhead | 2–5 octets | 200–400 octets |
| Connexion | Persistante | Par requête (ou keep-alive) |
| Push de données | Natif (subscribe) | Polling ou WebSocket |
| Latence | < 50 ms | 100–500 ms |
| Multi-abonnés | Natif | Webhooks/queues externes |
| Adapté IoT basse bande | ★★★★★ | ★★ |
L’approche Eziwan
L'Eziwan Gateway implémente un client MQTT qui publie les données Modbus/OPC UA collectées vers le broker MQTT de l'Eziwan Cloud. Les topics sont auto-générés selon la configuration de chaque équipement. Le transport est sécurisé TLS avec authentification par certificat client — jamais de connexion MQTT non sécurisée.
Pour aller plus loin : modbus cloud, gateway IoT industrielle et supervision de sites distants.