MQTT, RS485, Modbus : quel protocole pour vos capteurs terrain ?

· 13 minutes de lecture
13 min read
Équipe Eziwan
Équipe Eziwan
Infrastructure IoT

Connecter des capteurs industriels au cloud revient souvent à faire dialoguer deux mondes : l’OT avec ses bus série robustes, ses automates et ses équipements existants ; l’IT avec ses réseaux IP, ses brokers, ses bases de données temps réel et ses tableaux de bord cloud.

La bonne approche ne consiste pas forcément à remplacer l’installation terrain. Dans beaucoup de projets IIoT, le plus efficace est de conserver RS485/Modbus côté terrain et d’utiliser MQTT côté cloud, avec une passerelle capable de traduire, filtrer et publier les données proprement.

RS485, Modbus, MQTT : trois notions à ne pas confondre​

Avant de choisir un protocole, il faut distinguer trois niveaux souvent mélangés :

TermeRôleExemple d’usage
RS485Couche physique sérieRelier plusieurs équipements sur un bus deux fils
Modbus RTUProtocole applicatif sur liaison sérieLire des registres d’un compteur ou d’un capteur
MQTTProtocole publish/subscribe sur IPPublier des mesures vers un broker cloud

À retenir RS485 transporte le signal, Modbus RTU structure les échanges terrain, MQTT publie les données vers des systèmes IT ou cloud.

RS485 / Modbus : le socle OT des équipements industriels​

RS485 : une liaison série robuste pour le terrain​

Le RS485 est une liaison série différentielle utilisée depuis longtemps dans l’industrie. Il reste très présent car il est robuste, économique et adapté aux environnements où les équipements sont répartis dans une armoire, un atelier ou un site distant.

On le retrouve fréquemment pour connecter :

  • des automates industriels ;
  • des compteurs d’énergie ;
  • des onduleurs ;
  • des variateurs de fréquence ;
  • des capteurs de température, pression, débit ou humidité ;
  • des analyseurs d’air, d’eau ou d’énergie.

La distance maximale théorique d’un bus RS485 peut atteindre environ 1 200 mètres dans de bonnes conditions, mais elle dépend fortement du débit, de la qualité du câble, de la topologie, de la terminaison et du niveau de bruit électromagnétique.

Modbus RTU : lire et écrire des registres​

Sur RS485, le protocole le plus courant est Modbus RTU. Il définit une façon standardisée d’interroger des équipements esclaves à partir d’un maître : adresse esclave, fonction de lecture ou d’écriture, adresse de registre, valeur, contrôle d’erreur.

Avantages et limites de Modbus RTU​

PointLecture terrain
RobustesseAdapté aux environnements industriels et aux longues distances maîtrisées
InteropérabilitéTrès répandu sur les capteurs, compteurs, variateurs et automates
SimplicitéLecture de registres claire, facile à diagnostiquer avec les bons outils
Limite principalePas natif IP : il faut une passerelle pour l’intégrer au cloud
Point d’attentionUne mauvaise terminaison, un câblage en étoile ou des paramètres série incohérents peuvent dégrader fortement la communication

MQTT : le protocole adapté à la publication cloud​

MQTT est un protocole publish/subscribe conçu pour transporter des messages légers sur TCP/IP. Il est très utilisé dans les architectures IoT et IIoT, car il sépare les producteurs de données des consommateurs.

Le principe est simple :

  • un client MQTT publie des messages ;
  • les messages sont envoyés sur des topics ;
  • un broker MQTT reçoit, distribue et sécurise les échanges ;
  • les applications abonnées consomment les données : supervision, base de séries temporelles, alerting, datalake, outils métier.

Pourquoi MQTT complète bien Modbus​

Modbus est très efficace pour interroger des équipements terrain. MQTT est plus adapté pour publier des données vers des applications distantes.

BesoinProtocole le plus adapté
Lire les registres d’un capteur RS485Modbus RTU
Interroger un automate sur EthernetModbus TCP
Envoyer des mesures vers le cloudMQTT
Découpler collecte terrain et exploitation ITMQTT
Conserver des équipements industriels existantsRS485 / Modbus

MQTT n’est donc pas un remplaçant direct de RS485. Il intervient plutôt comme couche de transport applicatif vers l’IT, une fois les données terrain collectées, normalisées et contextualisées.

Le rôle de la gateway Eziwan : faire le pont entre OT et cloud​

La gateway Eziwan permet de connecter des équipements terrain et de publier leurs données vers des services distants. Dans une architecture typique, elle joue trois rôles :

  1. Collecte OT : interrogation d’équipements Modbus RTU sur RS485 ou Modbus TCP sur réseau local.
  2. Normalisation : conversion des registres en valeurs exploitables avec tag, unité, horodatage et qualité.
  3. Publication IT : envoi des données vers un broker MQTT, une plateforme cloud ou un système de supervision.

Configuration Modbus vers MQTT : les paramètres à maîtriser​

1. Définir le polling Modbus​

La première étape consiste à décrire les équipements à interroger :

  • adresse Modbus de chaque esclave ;
  • type de registre : holding register, input register, coil, discrete input ;
  • adresse de registre ;
  • format de donnée : entier 16 bits, entier 32 bits, float 32 bits, booléen ;
  • ordre des mots et des octets si nécessaire ;
  • unité physique ;
  • intervalle de lecture ;
  • nom de tag publié côté MQTT.

Point de vigilance Deux équipements peuvent exposer une même mesure avec des formats différents. Il faut donc toujours vérifier la documentation constructeur : adresse exacte, base d’indexation, type de registre, facteur d’échelle et endianness.

2. Exemple de configuration JSON​

{
  "modbus": {
    "baud_rate": 9600,
    "parity": "none",
    "stop_bits": 1,
    "slaves": [
      {
        "slave_id": 1,
        "registers": [
          {
            "address": "0x0001",
            "type": "holding",
            "format": "float32",
            "tag": "temperature",
            "unit": "°C"
          },
          {
            "address": "0x0003",
            "type": "holding",
            "format": "float32",
            "tag": "humidity",
            "unit": "%"
          }
        ]
      },
      {
        "slave_id": 2,
        "registers": [
          {
            "address": "0x0010",
            "type": "input",
            "format": "int16",
            "tag": "pressure",
            "unit": "mbar"
          }
        ]
      }
    ]
  },
  "mqtt": {
    "broker": "mqtt.example.com",
    "port": 8883,
    "tls": true,
    "base_topic": "site/{site_id}/gateway/{device_id}/sensors"
  }
}

3. Publier des données structurées​

Une fois la valeur lue, la passerelle peut publier un message MQTT structuré :

Topic  : site/paris/gateway/eziwan-01/sensors/temperature
Payload: {"value":23.4,"unit":"°C","timestamp":"2025-02-20T14:32:01Z","quality":"good"}

Un payload clair facilite ensuite l’intégration avec :

  • une base de séries temporelles ;
  • un dashboard Grafana ;
  • un flux Node-RED ;
  • un SCADA cloud ;
  • une application métier ;
  • une plateforme de supervision centralisée.

Modbus RTU vs Modbus TCP : quelle différence ?​

Modbus existe principalement sous deux formes dans les projets industriels : Modbus RTU et Modbus TCP.

CritèreModbus RTUModbus TCP
SupportRS485 / RS232Ethernet ou réseau IP
Mode d’adressageAdresse esclaveAdresse IP + port
TrameCompacte, avec CRCEncapsulée dans TCP
Usage typiqueCapteurs, compteurs, équipements de terrainPLC, variateurs, équipements Ethernet
DiagnosticAnalyseur série, testeur Modbus RTUPing, scan réseau, client Modbus TCP
Point d’attentionCâblage, terminaison, vitesse, paritéRoutage, pare-feu, VLAN, latence réseau

Dans une architecture Eziwan, les deux approches peuvent cohabiter : le bus RS485 pour les équipements terrain existants, et le réseau IP local pour les équipements Ethernet.

Exemple d’architecture : usine avec équipements mixtes​

Un site industriel peut combiner plusieurs générations d’équipements :

  • un compteur d’énergie en Modbus RTU ;
  • un automate sur bus série ;
  • un variateur accessible en Modbus TCP ;
  • une supervision cloud consommant les données en MQTT.

Cette architecture évite de remplacer les équipements qui fonctionnent déjà. La gateway devient le point de collecte, de traduction et de publication.

Comment choisir le bon protocole selon votre contexte​

Situation terrainChoix recommandéPourquoi
Équipements existants avec port RS485Modbus RTUCompatible avec de nombreux capteurs, compteurs et automates
Équipement industriel avec port EthernetModbus TCPPlus simple à intégrer sur réseau local IP
Nouveaux capteurs connectésMQTT natif si disponiblePublication directe vers un broker ou une plateforme cloud
SCADA existant à maintenirAccès distant sécurisé ou VPNContinuité avec l’architecture déjà en place
Données vers Grafana, InfluxDB ou Node-REDMQTTDécouplage propre entre collecte et exploitation
Site isolé ou mobileGateway avec connectivité cellulaireCollecte terrain sans dépendre d’un réseau filaire local

Sécurité : points essentiels pour une passerelle terrain​

Relier l’OT au cloud demande une approche prudente. L’objectif n’est pas seulement de transmettre des données, mais de le faire avec un niveau de contrôle adapté au contexte industriel.

Bonnes pratiques recommandées​

  • Segmenter les réseaux IT et OT pour éviter les accès trop larges depuis le cloud vers le terrain.
  • Limiter les flux sortants aux services nécessaires : broker MQTT, supervision, mises à jour ou administration.
  • Appliquer le moindre privilège : un équipement ou un utilisateur ne doit accéder qu’aux ressources utiles.
  • Journaliser les connexions et événements pour faciliter l’audit et le diagnostic.
  • Prévoir la révocation des accès en cas de changement de prestataire, de perte d’équipement ou d’incident.
  • Chiffrer les communications MQTT lorsque les données sortent du réseau local.
  • Surveiller l’état de la connectivité : latence, reconnexions, pertes de signal, files d’attente locales.

À ne pas négliger Une liaison 4G ou LTE peut être intermittente selon la couverture, l’antenne, l’environnement radio et la charge réseau. Il faut donc prévoir une stratégie de reconnexion, de tampon local et d’horodatage des données lorsque la continuité de mesure est importante.

Erreurs fréquentes lors d’un projet Modbus vers MQTT​

Confondre adresse registre et adresse documentaire​

Certains constructeurs documentent les registres en base 1, d’autres en base 0. Une mesure attendue sur 40001 peut donc correspondre à une adresse réelle différente selon l’outil utilisé.

Ignorer l’ordre des mots​

Les valeurs 32 bits, notamment les flottants, peuvent être encodées avec différents ordres de mots. Une mauvaise configuration peut produire des valeurs incohérentes sans que la communication Modbus soit en erreur.

Poller trop fréquemment​

Un bus RS485 partagé ne doit pas être interrogé comme une API HTTP. Un polling trop agressif peut saturer le bus, augmenter les erreurs CRC ou masquer les équipements les plus lents.

Publier des topics MQTT trop vagues​

Un topic comme data/value1 devient vite inutilisable. Il vaut mieux structurer les topics avec le site, la gateway, l’équipement et le tag.

site/{site_id}/gateway/{gateway_id}/equipment/{asset_id}/metric/{tag}

Oublier la qualité de donnée​

Une valeur sans indicateur de qualité peut être mal interprétée. Ajouter un champ quality, un horodatage et éventuellement un code d’erreur facilite l’exploitation côté supervision.

Architecture type recommandée​

CoucheRôleExemple
TerrainMesure et automatismeCapteurs, compteurs, PLC, variateurs
Collecte edgeLecture Modbus, filtrage, horodatageGateway Eziwan
TransportPublication MQTT sécuriséeBroker MQTT
TraitementHistorisation, alertes, transformationInfluxDB, Node-RED, plateforme cloud
VisualisationSupervision et décisionGrafana, SCADA cloud, application métier

Cette séparation rend l’architecture plus lisible : le terrain reste stable, la gateway traduit les données, le cloud les exploite.

FAQ — MQTT, RS485 et Modbus​

Peut-on faire coexister Modbus RTU et MQTT sur une même gateway ?​

Oui. C’est même l’un des scénarios classiques d’une passerelle IIoT : collecter les données terrain en Modbus RTU via RS485, puis les publier en MQTT vers un broker ou une plateforme cloud. Les deux protocoles n’ont pas le même rôle : Modbus sert à interroger les équipements, MQTT sert à transporter les données vers les applications.

Quelle est la différence entre RS485 et Modbus RTU ?​

RS485 est la couche physique : câblage, signaux électriques, topologie de bus. Modbus RTU est le protocole applicatif : structure des trames, adressage des esclaves, fonctions de lecture ou d’écriture, contrôle d’erreur. On peut utiliser RS485 avec d’autres protocoles, mais l’association RS485 + Modbus RTU reste très courante en environnement industriel.

Combien d’équipements peut-on connecter sur un bus RS485 ?​

La réponse dépend des transceivers, de la charge électrique du bus, de la longueur de câble, du débit et de la qualité d’installation. La limite souvent citée pour un segment RS485 classique est de 32 charges unitaires, mais des équipements modernes à faible charge et des répéteurs peuvent permettre des architectures plus étendues. En pratique, il faut valider la topologie avec les spécifications des équipements et les contraintes du site.

MQTT est-il adapté si la connectivité 4G est intermittente ?​

MQTT peut être adapté aux liaisons intermittentes si l’architecture est conçue correctement : qualité de service adaptée, reconnexion propre, horodatage local, file d’attente côté passerelle et supervision de l’état réseau. Il ne faut toutefois pas confondre robustesse protocolaire et disponibilité radio : la qualité de la couverture mobile reste un facteur déterminant.

Faut-il choisir MQTT ou OPC UA ?​

Les deux protocoles ne répondent pas exactement au même besoin. MQTT est léger et très efficace pour publier des messages vers un broker. OPC UA est plus riche pour modéliser des équipements, exposer une sémantique industrielle et intégrer certains systèmes d’automatisation. Dans de nombreux projets, MQTT est choisi pour la publication cloud, tandis qu’OPC UA reste pertinent côté supervision industrielle ou intégration machine.

Comment sécuriser une publication MQTT industrielle ?​

Il faut au minimum chiffrer les connexions lorsque les données sortent du réseau local, authentifier les clients, limiter les droits par topic, journaliser les connexions et prévoir la révocation des accès. La sécurité doit aussi couvrir la gateway elle-même : administration protégée, mises à jour maîtrisées, segmentation réseau et supervision des événements.

Aller plus loin avec Eziwan​

Vous avez des équipements RS485, Modbus RTU, Modbus TCP ou MQTT à intégrer dans une architecture cloud ? La bonne approche consiste à cartographier les protocoles existants, identifier les contraintes terrain, puis définir une passerelle adaptée entre OT et IT.

Ressources complémentaires​