Contact
Contact
Contact
Vers le glossaire

MQTT

MQTT (Message Queuing Telemetry Transport) est un protocole de communication léger destiné à la communication de machine à machine. Il a été conçu spécialement pour des environnements à bande passante limitée et à connexions réseau instables. Il s’est aujourd’hui imposé comme l’un des protocoles centraux de l’Internet industriel des objets (IIoT) et de la production connectée.

Sommaire

Qu’est-ce que MQTT ?

MQTT signifie Message Queuing Telemetry Transport et désigne un protocole de messagerie léger reposant sur le principe publish-subscribe. Contrairement à la communication client-serveur classique – où deux parties dialoguent directement – MQTT découple l’émetteur et le destinataire via un intermédiaire central, le broker.
Le protocole a été développé à l’origine pour la surveillance à distance d’oléoducs, où les liaisons satellite étaient coûteuses, à bande étroite et parfois peu fiables. Cette origine explique ses caractéristiques essentielles : un overhead minimal, une distribution robuste des messages même sur des connexions instables et une utilisation efficace des ressources.
MQTT est aujourd’hui un standard établi dans les infrastructures IoT – de la domotique aux véhicules connectés en passant par la production industrielle.

Comment fonctionne MQTT ? Broker, client, serveur et topics expliqués

Le modèle MQTT repose sur trois composants clés : le broker, le publisher et le subscriber. Ensemble, ils forment une architecture de communication flexible dans laquelle publishers et subscribers n’ont pas besoin de se connaître directement.

Le broker MQTT (serveur)

Le broker est le cœur de tout réseau MQTT. Il reçoit les messages entrants et les transmet à tous les clients ayant souscrit aux topics concernés. Le broker n’interprète pas le sens métier des données utiles – il agit uniquement comme intermédiaire entre émetteurs et destinataires. Parmi les solutions les plus répandues figurent Eclipse Mosquitto, HiveMQ et EMQX. L’exploitation s’appuie généralement sur les ports enregistrés auprès de l’IANA : 1883 pour les connexions MQTT non chiffrées et 8883 pour MQTT via TLS.

Publishers et subscribers (clients)

Chaque participant du réseau est un client MQTT – soit publisher (émetteur de données), soit subscriber (récepteur de données), soit les deux à la fois. Un capteur de température en production envoie par exemple en continu ses mesures au broker ; côté réception, un système de pilotage a souscrit à ce flux de données et réagit automatiquement aux dépassements de seuils.

Topics : la structure des messages

Dans MQTT, les messages sont adressés via des topics – des chaînes de caractères hiérarchisées qui classifient le contenu. Un exemple typique en environnement de production :
usine/hall3/ligne2/machine07/temperature
Les subscribers peuvent souscrire à des topics isolés ou à des ensembles entiers grâce aux caractères génériques : # couvre plusieurs niveaux de topic, + exactement un niveau. L’architecture devient ainsi évolutive et flexible. De nouvelles machines ou de nouveaux capteurs peuvent être intégrés sans coupler directement publishers et subscribers.

Quels niveaux de QoS (Quality of Service) MQTT propose-t-il ?

Une caractéristique essentielle de MQTT est le pilotage de la fiabilité de transmission via trois niveaux de qualité de service (QoS). Selon le cas d’usage, il devient possible d’arbitrer volontairement entre rapidité, overhead réseau et garantie de distribution.

QoS 0 – At most once (au plus une fois)

Le message est envoyé une seule fois, sans accusé de réception. S’il se perd, il n’est pas retransmis. Ce niveau convient aux données de télémétrie non critiques, pour lesquelles une perte occasionnelle est tolérable – par exemple des valeurs de capteurs à haute fréquence, où la mesure suivante arrive de toute façon peu après.

QoS 1 – At least once (au moins une fois)

Le broker envoie le message et attend un accusé de réception du destinataire. En son absence, il retransmet jusqu’à confirmation. La distribution est ainsi garantie au moins une fois ; le même message peut toutefois arriver plusieurs fois. Les destinataires doivent donc savoir gérer les doublons.

QoS 2 – Exactly once (exactement une fois)

Le mode le plus exigeant : un handshake en plusieurs étapes garantit au niveau du protocole que le message parvient au destinataire exactement une fois. Ce niveau génère l’overhead le plus élevé et s’adresse aux cas où ni la perte de messages ni les doublons ne sont acceptables – par exemple pour des acquittements, des ordres de fabrication, des libérations qualité ou des données de facturation.

Quels sont les avantages de MQTT ?

Ce n’est pas un hasard si MQTT s’est imposé comme standard de fait dans l’IIoT. Son architecture réunit un ensemble de propriétés déterminantes, en particulier en environnement industriel.

Faible besoin en ressources : Le protocole fonctionne avec un overhead de message minimal – un paquet MQTT peut ne peser que quelques octets. Même des appareils à puissance de calcul très limitée et à mémoire réduite, comme de simples microcontrôleurs sur des commandes machine ou des capteurs directement en ligne de production, peuvent fonctionner sans difficulté comme clients MQTT. Cela réduit sensiblement les exigences matérielles et donc le coût par équipement raccordé.

Robustesse en cas de mauvaise qualité réseau : MQTT est conçu pour fonctionner de manière fiable même avec une latence élevée, une bande passante limitée ou des connexions instables – une propriété qui compte au quotidien dans de vastes halls de production ou sur des machines isolées. Les coupures sont détectées par un mécanisme keep-alive configurable. Pour les clients temporairement hors ligne, le broker peut mettre les messages en mémoire tampon sous certaines conditions, par exemple avec des sessions persistantes et QoS 1 ou QoS 2. Les retained messages remplissent une autre fonction : ils conservent, par topic, le dernier message publié portant le flag retained et fournissent ainsi immédiatement aux nouveaux subscribers le dernier état connu.

Évolutivité sans rupture d’architecture : Le découplage entre publishers et subscribers permet de raccorder des milliers d’équipements à un seul broker sans devoir adapter l’infrastructure existante. Une nouvelle machine, un capteur supplémentaire ou un système de pilotage additionnel peuvent être intégrés à tout moment – le système évolue sans nécessiter une nouvelle conception.

Communication bidirectionnelle : Contrairement aux mécanismes de polling purs, où un système doit interroger activement à intervalles réguliers, MQTT permet d’envoyer des commandes aux équipements aussi facilement que d’en recevoir des informations d’état. C’est un atout décisif pour les boucles de régulation et les scénarios de télécommande en production.

Disponibilité rapide des données : Grâce au modèle publish-subscribe piloté par événements, les nouvelles mesures sont à la disposition de tous les abonnés concernés immédiatement après leur acquisition – sans délai de polling supplémentaire. Pour les applications sensibles au temps comme l’assurance qualité, la surveillance d’installations, le suivi d’état ou la visualisation de process, c’est un avantage majeur par rapport aux transmissions par intervalles.

Standard ouvert et largement supporté : MQTT est un protocole normalisé au niveau international, porté par une large communauté de développeurs et un écosystème mature. Presque tous les langages de programmation courants disposent de bibliothèques clientes stables, et la plupart des plateformes IIoT ainsi que des fournisseurs cloud prennent en charge MQTT nativement – ce qui simplifie considérablement les projets d’intégration.

Quelles sont les limites et les défis de MQTT ?

Aussi adapté soit-il à de nombreux scénarios IIoT, MQTT atteint ses limites face à certaines exigences.

Pas de modèle de données intégré : MQTT transporte les messages sous forme d’octets bruts, sans format défini. La signification d’une mesure, son unité ou sa relation avec d’autres valeurs ne sont pas définies dans le protocole lui-même. Cela impose des conventions ou des métadonnées supplémentaires au niveau applicatif.

Sécurité pas entièrement intégrée au cœur du protocole : MQTT ne chiffre pas les messages par lui-même. En pratique, la sécurité est assurée par TLS au niveau du transport ainsi que par l’authentification, l’autorisation et les contrôles d’accès dans le broker. C’est performant, mais cela exige une configuration soignée – notamment au regard de la protection des données.

Pas de logique transactionnelle métier : MQTT peut sécuriser la distribution de messages individuels via les niveaux de QoS, par exemple avec QoS 2 pour une distribution exactement une fois au niveau du protocole. En revanche, les enchaînements complexes et à états – par exemple des flux d’ordres ou de process en plusieurs étapes avec boucles de retour – ne sont pas modélisés par MQTT. Ces états de process, dépendances et cas d’erreur doivent être modélisés au niveau applicatif.

Le broker, point de défaillance unique potentiel : Dans les architectures simples, le rôle central du broker constitue aussi une faiblesse. Si un broker unique tombe en panne, la communication peut être interrompue. Des configurations à haute disponibilité avec clustering, réplication ou services de broker managés sont possibles, mais elles augmentent la complexité technique.

MQTT ou OPC UA – quelles différences ?

En environnement industriel, MQTT et OPC UA apparaissent souvent comme des concurrents – ce sont en réalité des technologies complémentaires qui répondent à des problématiques différentes.
OPC UA (Open Platform Communications Unified Architecture) est une norme industrielle complète qui définit non seulement le transport des données, mais aussi la modélisation sémantique, la sécurité, le contrôle d’accès et l’interopérabilité indépendante des plateformes. Les valeurs ne sont pas simplement transmises : elles peuvent être décrites via un modèle d’information avec leur signification, leur unité, leur type de données et leur contexte. L’équipement se décrit en quelque sorte lui-même.
MQTT, à l’inverse, est nettement plus léger et agnostique quant au contenu. Il définit comment les messages sont transportés – pas ce qu’ils signifient sur le plan métier.

Critère MQTT OPC UA
Objectif principal Transport de données Modélisation des données + transport
Besoin en ressources Très faible Plus élevé
Sémantique Aucune sémantique dans le cœur du protocole Intégrée via un modèle d’information
Sécurité Généralement via TLS, configuration du broker et ACL Largement couverte par la norme
Application typique Données capteurs, télémétrie, edge-to-cloud Intégration machine, MES/SCADA, interopérabilité industrielle

Dans la pratique, les deux protocoles sont souvent combinés : OPC UA structure et décrit les données au niveau machine, MQTT les transporte efficacement vers le cloud ou vers des systèmes de niveau supérieur. Avec OPC UA PubSub, la transmission de données OPC UA structurées via MQTT est désormais formellement spécifiée.

Où MQTT est-il utilisé ? Cas d’usage dans l’IIoT et la production

MQTT trouve sa place partout où de nombreux équipements doivent échanger des données de manière fiable et économe en ressources. Dans la production industrielle, il s’agit avant tout des scénarios suivants :

Surveillance de l’état des machines (condition monitoring)

Les capteurs installés sur les équipements de production transmettent en continu des valeurs de vibration, de température ou de pression via MQTT vers des systèmes de niveau supérieur. Les écarts par rapport à l’état normal peuvent ainsi être détectés rapidement, avant qu’ils n’entraînent des arrêts non planifiés. Un équipementier automobile peut par exemple surveiller en parallèle de nombreux points de contrôle ou de process et signaler automatiquement les écarts qualité à un système d’analyse ou de pilotage – sans qu’un opérateur ait à interroger les données activement.

Acquisition des données de production (MDE)

MQTT sert de couche de transport pour la collecte automatique des données machine – quantités, temps de cycle ou codes défaut – et leur transmission vers des systèmes MES ou ERP. Sur une ligne de production chaînée, chaque machine publie son état de manière autonome ; le système de niveau supérieur souscrit à tous les topics pertinents et obtient ainsi une image continuellement actualisée du taux d’utilisation global.

Communication edge-to-cloud

À l’interface entre le shopfloor et les plateformes cloud, MQTT s’est imposé comme protocole léger pour la transmission d’informations de télémétrie et d’état. Les données sont prétraitées à l’edge puis transmises efficacement – par exemple lorsqu’un site de production envoie ses données machine vers une plateforme d’analyse centrale qui réalise des évaluations OEE / TRS multi-sites.

Maintenance prédictive

La transmission continue de données capteurs constitue une base importante pour la maintenance prévisionnelle. Scénario typique : des capteurs de vibration sur les broches d’une machine CNC fournissent des mesures en continu via MQTT ; un modèle d’analyse reconnaît précocement des signatures caractéristiques, identifie les signes d’une défaillance de roulement possible et déclenche automatiquement un ordre de maintenance.

Gestion de l’énergie

Les données de consommation des machines, de l’éclairage ou de la climatisation peuvent être regroupées de manière centralisée via MQTT et analysées rapidement. Dans une fonderie par exemple, les pics de charge peuvent être réduits de façon ciblée : dès que la consommation totale dépasse un seuil défini, le système bride les consommateurs non critiques ou décale les process énergivores – sur la base des messages MQTT reçus en continu.

De quoi ai-je besoin pour utiliser MQTT ?

Démarrer avec MQTT reste techniquement accessible – les composants de base sont vite réunis et, grâce à un écosystème très large, il existe des briques prêtes à l’emploi pour presque tous les cas d’usage.

Broker MQTT

Le broker est le composant d’infrastructure central d’une architecture MQTT classique. Pour débuter et pour les installations de taille modeste, Eclipse Mosquitto convient bien – un broker open source léger, qui tourne sur du matériel standard et se configure facilement. Pour des environnements de production exigeants en matière d’évolutivité et d’administration, les solutions commerciales ou les services MQTT hébergés des grands fournisseurs cloud et de plateformes constituent une alternative pertinente.

Bibliothèque cliente MQTT

Une bibliothèque cliente MQTT est nécessaire sur chaque équipement ou système devant émettre ou recevoir des données. Le choix est vaste : pour Python, Eclipse Paho MQTT est une solution établie et bien documentée ; pour Java, C et d’autres langages, il existe également des implémentations clientes matures. Les systèmes embarqués et les microcontrôleurs se raccordent via des bibliothèques ou frameworks spécifiquement optimisés, comme PubSubClient ou ArduinoMqttClient dans l’univers Arduino, ainsi que le client MQTT d’ESP-IDF pour les systèmes basés sur ESP32.

Connexion réseau

MQTT n’impose aucune exigence particulière à l’infrastructure réseau – il fonctionne sur toute connexion compatible TCP/IP, qu’il s’agisse d’Ethernet, de Wi-Fi ou de réseau mobile. Pour une transmission chiffrée, TLS au niveau du transport est recommandé, ce qui suppose une gestion adaptée des certificats selon le modèle de sécurité retenu.

Planification de la structure des topics

Ce n’est pas un outil, mais c’est souvent sous-estimé en pratique : avant de raccorder les premiers équipements, la hiérarchie des topics doit être planifiée avec soin. Une nomenclature cohérente – par exemple selon le schéma site/secteur/machine/pointdedonnees – facilite considérablement les extensions ultérieures et évite un désordre difficile à maintenir en exploitation.

Outils de test et de débogage

Pour le développement, les tests et le diagnostic, les clients MQTT graphiques sont très utiles. Des outils comme MQTT Explorer rendent la structure des topics visible, affichent les messages entrants en direct et permettent de publier manuellement des messages de test – sans avoir à écrire son propre code au préalable.

Comment MQTT a-t-il évolué ? Histoire et versions

MQTT a été développé en 1999 par Andy Stanford-Clark (IBM) et Arlen Nipper (alors chez Arcom) afin de transmettre de manière fiable les données de capteurs d’oléoducs via des liaisons satellite étroites et coûteuses. Les exigences de l’époque – faible consommation de ressources, bande passante réduite et grande fiabilité – marquent encore aujourd’hui la conception du protocole.
En 2013, la normalisation de MQTT débute au sein d’OASIS, l’Organization for the Advancement of Structured Information Standards.
MQTT 3.1.1 a été adopté comme norme OASIS en 2014, puis ratifié comme norme ISO/IEC 20922:2016. Cette version reste utilisée aujourd’hui dans de nombreux environnements de production.
MQTT 5.0 a été adopté comme norme OASIS en 2019 et a apporté des extensions majeures : meilleure gestion des erreurs, message expiry, shared subscriptions pour la répartition de charge et métadonnées enrichies sous forme de user properties. Pour les nouveaux projets, MQTT 5.0 constitue en règle générale le choix à privilégier, à condition que le broker et les clients prennent pleinement en charge cette version.

MQTT en bref : les points essentiels

MQTT est un protocole de communication léger, fondé sur le principe publish-subscribe, conçu spécifiquement pour des équipements à ressources limitées et des réseaux peu fiables. Son élément central est le broker, qui achemine les messages entre clients émetteurs et clients destinataires sans que ceux-ci aient à communiquer directement.
Trois niveaux de QoS permettent de graduer volontairement la garantie de distribution – d’une transmission rapide sans accusé de réception jusqu’à une distribution exactement une fois au niveau du protocole. Comparé à OPC UA, MQTT se distingue par un faible besoin en ressources et une forte évolutivité ; pour des modèles de données sémantiquement riches, il est fréquemment associé à OPC UA dans la pratique.
Dans la production connectée et l’IIoT, MQTT est aujourd’hui solidement établi : comme couche de transport des données machine, comme trait d’union entre le shopfloor et le cloud, et comme socle d’applications allant de la surveillance d’état à la maintenance prédictive. Avec MQTT 5.0, une version moderne et enrichie est disponible, capable de soutenir des architectures IIoT plus exigeantes.