Une passerelle edge IIoT est l'équipement qui transforme une usine remplie d'automates, de compteurs et de variateurs en un flux de messages MQTT structurés exploitables par le reste de l'entreprise. Cet article explique les quatre missions de toute passerelle (traduction de protocoles, mise en tampon, sécurité et calcul en périphérie), présente une architecture de référence et vous donne une check-list pratique pour en choisir une.
Pourquoi les sites industriels ont besoin de passerelles edge
Les équipements industriels ont été conçus pour dialoguer avec d'autres équipements sur le même réseau, pas avec le cloud. Un atelier typique mélange Modbus RTU sur RS485, Modbus TCP, OPC UA, EtherNet/IP, PROFINET et des protocoles propres aux fabricants, souvent sur des réseaux volontairement isolés du réseau bureautique et d'internet. Ces protocoles fonctionnent pour la plupart en requête-réponse : un client doit interroger chaque équipement pour chaque valeur.
Les systèmes cloud, tableaux de bord, outils d'analyse et jumeaux numériques attendent autre chose : des données sécurisées, sortantes, pilotées par les événements, avec des noms et des unités cohérents. La passerelle est à la fois le traducteur et le poste de garde entre ces deux mondes. Sans elle, chaque application souhaitant accéder aux données machines aurait besoin de ses propres pilotes, de son propre chemin réseau vers le réseau OT et ferait peser sa propre charge d'interrogation sur des automates fragiles.
Les quatre rôles essentiels d'une passerelle edge IIoT
1. Traduction de protocoles et modélisation des données
La passerelle interroge les équipements, ou s'abonne à eux, dans leurs protocoles natifs et republie les données via MQTT. Une bonne passerelle ne se contente pas de copier des registres : elle applique facteurs d'échelle, unités et noms, si bien que 40001 = 2351 devient {"temperature_c": 23.51} sur un topic parlant comme acme/plant1/packaging/line2/filler/temperature.
C'est par cette étape de nommage que la passerelle contribue à un Unified Namespace. Si chaque passerelle publie dans une hiérarchie partagée de type ISA-95 (entreprise, site, zone, ligne, cellule), les consommateurs trouvent les données sans savoir quelle passerelle ni quel protocole les a produites. Les chemins de traduction spécifiques sont traités dans les guides Modbus TCP vers MQTT et passerelle OPC UA vers MQTT.
2. Mise en tampon et store-and-forward
Les réseaux d'usine et les liaisons WAN tombent en panne. Une passerelle qui se contente de perdre les données tant que le broker est injoignable laisse dans l'historique des trous souvent impossibles à combler. Les passerelles industrielles mettent les messages en file d'attente localement, sur disque et pas seulement en mémoire, puis les rejouent dans l'ordre au retour de la connexion. Les détails de conception (taille du tampon, horodatage, débit de rejeu) sont présentés dans store-and-forward pour MQTT.
3. Frontière de sécurité
La passerelle est généralement le seul équipement qui touche à la fois le réseau OT et un réseau externe. C'est donc le bon endroit pour appliquer plusieurs règles :
- Connexions sortantes uniquement. La passerelle ouvre une connexion TLS vers le broker ; rien sur internet n'initie de connexion vers l'usine.
- Isolation des identifiants. Seule la passerelle détient les identifiants du broker. Jamais les automates.
- Lecture seule par défaut. L'écriture de consignes depuis le cloud doit être explicitement activée par variable, si elle l'est.
- Segmentation réseau. Deux interfaces réseau, une par zone, sans routage entre elles, ou un placement dans une DMZ industrielle.
4. Calcul en périphérie
Une partie de la logique a sa place à côté de la machine : filtrer le bruit, calculer des moyennes, détecter des franchissements de seuil ou gérer des alarmes qui doivent fonctionner même lorsque le cloud est injoignable. Le calcul edge le plus utile est souvent aussi le plus simple : le report by exception, qui ne publie une valeur que lorsqu'elle change de manière significative et peut réduire considérablement le trafic par rapport à une interrogation à intervalle fixe.
Architecture de référence
Shop floor (OT network) Edge Cloud / IT
------------------------ ----------------- ------------------
PLC (EtherNet/IP) ---\ | IIoT edge | TLS | MQTT broker |
Energy meter (Modbus) ----+----> | gateway | -----> | (8883) | --> dashboards
CNC (OPC UA / MTConnect) --/ | - drivers | outbound| | --> historian
| - modeling | only | | --> analytics
| - buffer | | |
| - RBE / rules | ------------------
-----------------
La passerelle publie sur des topics qui suivent la hiérarchie de l'usine. Un payload typique ressemble à ceci :
{
"ts": "2026-10-16T08:14:03.512Z",
"values": {
"spindle_speed_rpm": 11980,
"spindle_load_pct": 41.5,
"program": "O1234",
"state": "RUNNING"
},
"quality": "GOOD",
"source": "gw-plant1-02"
}
Inclure dans chaque message un horodatage source, un indicateur de qualité et l'identifiant de la passerelle facilite grandement les rejeux de données tamponnées et le dépannage.
Choisir une passerelle edge IIoT : check-list de sélection
| Critère | Questions à poser |
|---|---|
| Pilotes de protocoles | Prend-elle en charge tous les protocoles présents aujourd'hui dans l'atelier, y compris les liaisons série anciennes ? Les pilotes sont-ils licenciés par protocole ou par variable ? |
| Qualité du client MQTT | MQTT 3.1.1 et 5 ? TLS avec autorité de certification personnalisée ? QoS, retained messages, Last Will et keep alive configurables ? |
| Options de payload | JSON simple, Sparkplug B, ou les deux ? Pouvez-vous maîtriser entièrement la structure des topics ? |
| Store-and-forward | Sur disque ? Quelle capacité ? Rejeu ordonné ? Rejeu à débit limité ? |
| Logique edge | Bandes mortes, mise à l'échelle, scripts, ou conteneurs pour du code personnalisé ? |
| Matériel | Rail DIN, plage de température étendue, sans ventilateur, alimentation industrielle, ports série ? |
| Gestion | Configuration et mises à jour firmware à distance sans ouvrir de ports entrants sur le pare-feu ? |
| Sécurité | Démarrage sécurisé, mises à jour signées, accès local par rôles, interfaces réseau séparées ? |
| Cycle de vie | Combien de temps le fabricant la supportera-t-il, et pouvez-vous exporter la configuration si vous la remplacez ? |
Les types de passerelles courants
- Passerelles industrielles dédiées. Boîtiers sur rail DIN conçus pour cet usage, avec un outil de configuration du fabricant. Rapides à déployer, limités aux protocoles et à la logique fournis par le fabricant.
- PC industriels équipés d'un logiciel de passerelle. Plus flexibles : exécutez une plateforme de connectivité commerciale, Node-RED ou vos propres conteneurs. Demandent une maintenance de type IT plus importante.
- Automates et contrôleurs avec MQTT intégré. De nombreux contrôleurs modernes peuvent publier en MQTT directement. Cela supprime un boîtier mais transfère les responsabilités réseau au contrôleur, ce qui ne convient pas à toutes les usines.
- Passerelles à microcontrôleur. Pour de petits retrofits, un microcontrôleur peut relier quelques équipements Modbus à MQTT, comme dans le tutoriel ESP32 Modbus RS485 vers MQTT. Idéal pour des pilotes et de la surveillance non critique.
Sparkplug B ou JSON simple ?
Les passerelles proposent de plus en plus Sparkplug B, qui ajoute un espace de noms de topics standard, des certificats de naissance et de mort (birth et death) pour connaître l'état des équipements, et des payloads Protobuf compacts. Le JSON simple est plus facile à lire et à consommer depuis n'importe quel outil. Beaucoup d'usines utilisent les deux : Sparkplug B depuis les passerelles, et une vue JSON ISA-95 lisible pour les consommateurs. ConnectMQ peut décoder les payloads Sparkplug B et les republier dans des topics ISA-95, transformant par exemple spBv1.0/factory1/DDATA/line1/cnc1 en connectmq/factory1/production/line1/cnc1/telemetry, afin que les deux styles coexistent sur un même broker. La vue d'ensemble se trouve dans le guide de l'IoT industriel avec MQTT.
Tester une passerelle avant le déploiement
Avant de connecter une passerelle aux données de production, pointez-la vers un broker de test et vérifiez les topics, les payloads et le comportement en reconnexion :
mosquitto_sub -h broker.connectmq.com -p 1883 -i gw-test-viewer-81 -t "connectmq/demo/gw-test-81/#" -v
Configurez la passerelle pour publier des valeurs simulées ou non sensibles sous connectmq/demo/gw-test-81/... sur le serveur MQTT public gratuit, puis débranchez son câble réseau quelques minutes et vérifiez que les messages tamponnés arrivent dans l'ordre à la reconnexion. N'oubliez pas que la zone publique est lisible par tous : n'y envoyez jamais de vraies données d'usine.
La place du broker
La passerelle n'est que la moitié du système. Le broker vers lequel elle publie doit gérer TLS, l'authentification, de nombreux abonnés simultanés et l'état retenu de chaque variable. Exploiter vous-même cette infrastructure implique correctifs, renouvellement des certificats et supervision. Un broker MQTT managé vous libère de cette charge, avec des options allant des brokers serverless partagés pour les projets pilotes aux clusters dédiés ou aux brokers déployés dans votre propre compte cloud pour des exigences plus strictes. Pour comprendre d'abord les compromis de l'hébergement, consultez le guide pour choisir un broker MQTT cloud, et pour décider quelle part de logique doit rester en périphérie plutôt que dans le cloud, lisez edge computing vs cloud computing dans l'IIoT.
Connectez vos passerelles à ConnectMQ
ConnectMQ offre à chaque passerelle un point de connexion TLS sur le port 8883, des identifiants émis et liés à son client ID, un explorateur de topics en direct et une vue des équipements organisée selon les niveaux ISA-95. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et pointez-y votre première passerelle.
Questions fréquentes
Quelle est la différence entre une passerelle edge IIoT et un routeur ?
Un routeur achemine des paquets réseau sans les comprendre. Une passerelle edge comprend les protocoles industriels, lit les valeurs, les convertit en messages porteurs de sens et les publie via MQTT.
Ai-je besoin d'une passerelle si mon automate prend en charge MQTT ?
Pas toujours. Une passerelle reste utile si vous avez de nombreux équipements anciens, si vous avez besoin d'une mise en tampon sur disque, ou si vous voulez tenir les identifiants du broker et l'accès internet à l'écart de vos contrôleurs.
La passerelle doit-elle utiliser Sparkplug B ?
Utilisez Sparkplug B si vos applications consommatrices le prennent en charge et que vous souhaitez une gestion d'état standardisée. Utilisez du JSON simple si de nombreux outils simples doivent lire les données directement ; certaines usines publient les deux.
Quelle quantité de données une passerelle doit-elle mettre en tampon ?
Dimensionnez le tampon pour la plus longue coupure que vous voulez absorber à votre débit de données normal, avec de la marge. Le report by exception réduit à la fois le trafic normal et les besoins en tampon.
