MQTT est un protocole de messagerie léger conçu pour assurer une communication efficace entre appareils, applications, capteurs, passerelles, plateformes cloud et systèmes de contrôle. Il est largement utilisé dans les réseaux IoT, les systèmes de télémétrie, les bâtiments intelligents, la supervision industrielle, les plateformes de véhicules, les systèmes d’énergie, la domotique, la gestion à distance des équipements et les applications mobiles lorsque la bande passante, l’énergie ou la stabilité du réseau peuvent être limitées.

Le protocole repose sur un modèle publication/abonnement. Au lieu qu’un appareil envoie directement des données à un autre appareil, les messages sont envoyés à un broker. Le broker distribue ensuite ces messages aux clients abonnés aux sujets correspondants. Cette structure rend la communication flexible, évolutive et bien adaptée aux systèmes comprenant de nombreux appareils qui n’ont pas besoin de connaître l’adresse réseau les uns des autres.

Une autre manière de penser la messagerie entre appareils

La communication client-serveur traditionnelle fonctionne souvent comme une demande et une réponse directes. Un client demande des informations à un serveur, et le serveur répond. MQTT suit une logique différente. Un appareil peut publier un message sans savoir qui le recevra, tandis qu’un autre appareil peut s’abonner à un sujet sans savoir qui y publiera.

Cette séparation est utile dans les grands systèmes distribués. Un capteur de température n’a pas besoin de savoir quel tableau de bord, quelle base de données, quelle application mobile ou quelle règle d’automatisation consommera ses données. Il lui suffit de publier dans un sujet défini. Le broker assure la distribution.

Il en résulte un modèle de communication qui réduit le couplage fort entre appareils. Les systèmes peuvent ajouter de nouveaux abonnés sans modifier le capteur. Ils peuvent aussi ajouter de nouveaux éditeurs sans réécrire chaque application. C’est l’une des raisons pour lesquelles le protocole est populaire dans les architectures IoT et de télémétrie.

Le broker comme concentrateur de messages

Le broker est le composant central de l’architecture. Il accepte les connexions des clients, authentifie les clients lorsque cela est nécessaire, reçoit les messages publiés, fait correspondre les sujets aux abonnements et transmet les messages aux bons abonnés.

Un broker peut fonctionner sur une plateforme cloud, un serveur privé, une passerelle edge, un ordinateur industriel, un appareil embarqué ou un service de messagerie géré. Dans les petits déploiements, un seul broker peut gérer tout le trafic. Dans les grands déploiements, plusieurs brokers peuvent être mis en cluster, reliés par pont, équilibrés en charge ou distribués entre régions.

Le broker contrôle aussi de nombreux comportements opérationnels, comme l’état de session, les messages conservés, le contrôle d’accès, la livraison selon la qualité de service, le délai keepalive, les limites de connexion, l’autorisation par sujet et la persistance des messages. Sa conception a donc un impact direct sur la fiabilité, l’évolutivité et la sécurité.

Cycle de vie de la connexion

Le client établit une session

Un client ouvre d’abord une connexion réseau vers le broker. MQTT fonctionne généralement sur TCP, et les déploiements sécurisés utilisent souvent le chiffrement TLS. Une fois la connexion de transport établie, le client envoie un paquet CONNECT contenant des informations telles que l’ID client, les données d’authentification, la valeur keepalive, le comportement de session et les paramètres facultatifs du message de testament.

Le broker vérifie la demande de connexion et répond avec un paquet CONNACK. Si la connexion est acceptée, le client peut commencer à publier, s’abonner, se désabonner et recevoir des messages. Si la connexion est refusée, le broker fournit une raison selon la version du protocole et la configuration.

Le battement garde le lien actif

Le mécanisme keepalive aide les deux côtés à détecter les connexions rompues. Si aucune donnée n’a été échangée pendant le délai convenu, le client envoie un paquet PINGREQ et le broker répond avec PINGRESP.

C’est important, car les appareils IoT peuvent fonctionner sur des réseaux instables, des liaisons mobiles, du Wi-Fi, des connexions cellulaires, des liens satellite ou des chemins WAN distants. Un réseau peut tomber en panne silencieusement sans fermer correctement la connexion. Keepalive permet de détecter cette situation.

Déconnexion et reconnexion

Un client peut se déconnecter normalement en envoyant un paquet DISCONNECT. Il peut aussi disparaître de manière inattendue à cause d’une coupure de courant, d’une panne réseau, d’un plantage du micrologiciel ou d’une perte de signal. Le broker applique alors les règles de session et de message de testament configurées pour ce client.

Le comportement de reconnexion est important dans les déploiements réels. Les appareils doivent gérer les interruptions réseau avec souplesse, éviter les tempêtes de reconnexion et reprendre la communication selon la politique de session requise.

Noms de sujets et routage des messages

Les sujets sont des chemins textuels utilisés pour classer les messages. Un sujet peut ressembler à une hiérarchie, comme building/floor1/room102/temperature ou factory/line3/motor7/status. Les éditeurs envoient les messages vers des sujets, et les abonnés reçoivent les messages provenant des sujets auxquels ils sont abonnés.

Une bonne conception des sujets est l’un des éléments les plus importants d’un déploiement réussi. Les noms doivent être prévisibles, lisibles et alignés sur la structure réelle du système. Une mauvaise conception rend le filtrage, les permissions, la supervision et la maintenance à long terme difficiles.

Les abonnés peuvent utiliser des sujets exacts ou des abonnements avec jokers. Un joker à un seul niveau peut correspondre à un niveau de sujet, tandis qu’un joker multiniveau peut correspondre à de nombreux niveaux. Les jokers sont utiles pour les tableaux de bord, les plateformes d’analyse, les outils de supervision et les applications de gestion qui doivent recevoir des messages de nombreux appareils.

Flux de publication et d’abonnement

Publication de données

Lorsqu’un client publie des données, il envoie un paquet PUBLISH au broker. Le paquet inclut le nom du sujet, la charge utile, le niveau de qualité de service, le drapeau de conservation et l’identifiant de paquet lorsque le niveau QoS choisi l’exige.

La charge utile peut contenir de nombreux formats de données. Il peut s’agir de texte brut, de JSON, de données binaires, de valeurs de capteurs, de messages d’état, de commandes, d’alarmes, d’enregistrements de télémétrie ou de données applicatives encodées. MQTT ne définit pas lui-même le sens de la charge utile. L’application décide comment la structurer et l’interpréter.

Réception des abonnements

Un client s’abonne en envoyant un paquet SUBSCRIBE avec un ou plusieurs filtres de sujet. Le broker répond par SUBACK et commence à livrer les messages correspondants à ce client selon le niveau QoS demandé et accordé.

Les abonnés peuvent être des tableaux de bord, des bases de données, des moteurs d’automatisation, des services cloud, des applications mobiles, des contrôleurs d’appareils ou d’autres équipements de terrain. Un message publié peut être livré à de nombreux abonnés en même temps.

Suppression de l’intérêt

Lorsqu’un client ne veut plus recevoir certains messages, il envoie un paquet UNSUBSCRIBE. Le broker cesse de transmettre les messages de sujets correspondants après avoir confirmé la demande.

Cela permet aux applications de modifier dynamiquement leur intérêt pour les données. Par exemple, un tableau de bord peut s’abonner à un bâtiment pendant que l’utilisateur le consulte, puis se désabonner lorsque l’utilisateur passe à un autre site.

Le modèle publication/abonnement permet aux producteurs et aux consommateurs de données d’évoluer indépendamment, tandis que le broker gère le routage, le comportement de session et le contrôle de livraison.

Niveaux de qualité de service

QoS 0 : au plus une fois

QoS 0 est le niveau de livraison le plus simple. Le message est envoyé une seule fois et il n’y a pas d’accusé de réception du destinataire dans la couche MQTT. Si le message est perdu, le protocole ne le retransmet pas.

Ce niveau est utile pour une télémétrie fréquente lorsqu’une perte occasionnelle de mise à jour est acceptable. Par exemple, un capteur de température envoyant des données toutes les quelques secondes n’a pas forcément besoin que chaque mesure arrive.

QoS 1 : au moins une fois

QoS 1 exige un accusé de réception. L’émetteur retransmet le message s’il ne reçoit pas de confirmation. Cela améliore la fiabilité de livraison, mais le destinataire peut recevoir des messages en double.

Les applications utilisant QoS 1 doivent être prêtes à gérer les doublons. C’est courant pour les alarmes, changements d’état, commandes et télémétries importantes où la livraison compte davantage que l’absence de répétition.

QoS 2 : exactement une fois

QoS 2 utilise une poignée de main plus complexe pour garantir qu’un message est livré exactement une fois au niveau du protocole. Il fournit la garantie de livraison la plus forte, mais ajoute davantage de surcharge et de latence.

Ce niveau peut être utilisé lorsque le traitement en double serait dommageable. Cependant, de nombreux déploiements réels utilisent QoS 0 ou QoS 1, car ils offrent un meilleur équilibre entre performance et fiabilité.

Messages conservés et dernier état connu

Un message conservé est stocké par le broker comme le dernier message d’un sujet. Lorsqu’un nouvel abonné s’abonne à ce sujet, le broker lui envoie immédiatement le message conservé afin qu’il voie l’état connu le plus récent.

C’est utile pour les informations d’état telles que l’état en ligne d’un appareil, l’état d’un interrupteur, une valeur de capteur, une version de configuration, un état d’alarme ou le mode de fonctionnement actuel. Sans messages conservés, un nouvel abonné devrait peut-être attendre la prochaine mise à jour pour connaître la situation actuelle.

Les messages conservés doivent être utilisés avec prudence. Ils sont utiles pour l’état, mais pas toujours appropriés pour les flux d’événements. Un événement conservé « porte ouverte » peut tromper un nouvel abonné s’il n’est plus vrai. Les sujets d’état et les sujets d’événement doivent être conçus séparément.

Comportement de session et livraison hors ligne

MQTT prend en charge un comportement de session qui détermine ce qui se passe lorsqu’un client se déconnecte puis se reconnecte. Selon la version du protocole et la configuration, le broker peut stocker les abonnements, les messages en file d’attente et l’état de session d’un client.

C’est utile pour les appareils qui dorment, se déplacent entre réseaux ou perdent temporairement la connectivité. Lorsque l’appareil se reconnecte, il peut continuer à recevoir les messages mis en file d’attente pendant qu’il était hors ligne, si la politique de session et les règles QoS le permettent.

La persistance de session doit correspondre au rôle de l’appareil. Un capteur alimenté par batterie n’a pas forcément besoin que chaque commande soit conservée indéfiniment. Un contrôleur distant peut nécessiter des mises à jour de configuration en file d’attente. Trop de files hors ligne consomment les ressources du broker, tandis que trop peu peuvent faire manquer des commandes.

Messages de testament pour les pannes inattendues

Un message de dernière volonté permet à un client de définir un message que le broker doit publier si le client se déconnecte de façon inattendue. Cela aide les autres systèmes à détecter une panne d’appareil, une perte réseau ou un arrêt anormal.

Par exemple, un appareil peut définir un message de testament sur un sujet d’état comme device/123/status. Si l’appareil perd l’alimentation sans envoyer de déconnexion normale, le broker publie le message hors ligne configuré.

Cette fonction est largement utilisée dans les tableaux de supervision, les systèmes de santé des appareils, la télémétrie industrielle, la supervision de passerelles et la gestion d’actifs à distance. Elle offre un moyen simple d’exposer une déconnexion anormale aux autres parties du système.

Sécurité et contrôle d’accès

Authentification

Le broker doit vérifier l’identité du client avant d’autoriser l’accès. L’authentification peut utiliser un nom d’utilisateur et un mot de passe, des certificats client, des jetons, des identifiants API ou une intégration avec un système d’identité externe.

Une authentification faible peut permettre à des appareils non autorisés de publier de fausses données, de s’abonner à des sujets sensibles ou de perturber l’environnement de messagerie.

Autorisation

Une fois l’identité vérifiée, le broker doit décider sur quels sujets le client peut publier et à quels sujets il peut s’abonner. Un capteur ne doit pas pouvoir publier des commandes vers des appareils sans rapport. Une application locataire ne doit pas recevoir les données d’un autre locataire.

Les permissions au niveau des sujets sont essentielles dans les déploiements multi-appareils, multisites et multitenants.

Chiffrement

Le chiffrement TLS protège les données en transit entre les clients et le broker. C’est important lorsque les messages circulent sur des réseaux publics, des réseaux cellulaires, des connexions cloud ou une infrastructure non fiable.

Le chiffrement doit être associé à la gestion des certificats, au stockage sécurisé des clés et à un provisionnement soigneux des clients. Une couche de transport sécurisée n’aide pas si les identifiants sont exposés dans le micrologiciel ou les fichiers de configuration.

Modèles de déploiement

De l’appareil au cloud

Dans de nombreux systèmes IoT, les capteurs et les passerelles publient les données vers un broker cloud. Les applications cloud stockent, visualisent, analysent et exploitent ensuite ces données. Ce modèle est courant dans les bâtiments intelligents, la gestion de l’énergie, la supervision de flottes et les plateformes d’équipements distants.

Les principaux points de conception sont la sécurité, la résilience réseau, l’identité des appareils, le volume de messages et la montée en charge côté cloud.

Agrégation par passerelle edge

Une passerelle edge peut collecter les données des appareils locaux et publier des données résumées ou filtrées vers un broker central. Elle peut aussi s’abonner à des sujets de commande et transmettre les instructions aux équipements locaux.

Cela réduit la bande passante, améliore le contrôle local et permet au site de conserver certaines fonctions même lorsque la connexion cloud est indisponible.

Broker local pour systèmes de site

Certains déploiements utilisent un broker local dans une usine, un bâtiment, un laboratoire, un campus ou une salle de contrôle. Les appareils et applications échangent les données localement avec une faible latence et une dépendance réduite aux réseaux externes.

Un broker local peut ensuite relier certaines données à une plateforme cloud ou d’entreprise. Cela donne aux concepteurs plus de contrôle sur les flux de données et la dépendance réseau.

Applications dans les systèmes connectés

Supervision industrielle

Les usines et sites de services publics utilisent MQTT pour collecter l’état des équipements, les données de capteurs, les messages d’alarme, les valeurs d’énergie, les mesures de température, les données de vibration et les indicateurs de production. Le protocole convient aux environnements où de nombreux appareils envoient de petits messages à des plateformes de supervision.

Les déploiements industriels doivent prendre en compte la segmentation réseau, la redondance du broker, le choix du QoS, l’état conservé et le provisionnement sécurisé des appareils.

Bâtiments intelligents

Les systèmes de bâtiment peuvent utiliser le protocole pour connecter éclairage, CVC, contrôle d’accès, capteurs de présence, compteurs, ascenseurs, panneaux de salle et tableaux de bord. La structure des sujets peut refléter la hiérarchie bâtiment, étage, pièce et appareil.

Cela rend les données plus faciles à organiser et aide les règles d’automatisation à ne s’abonner qu’aux événements ou états pertinents.

Énergie et comptage

Les plateformes d’énergie peuvent utiliser MQTT pour collecter les relevés de compteurs, les données d’onduleurs, l’état des batteries, les informations de charge et la télémétrie liée au réseau. La messagerie légère est utile lorsque de nombreux appareils rapportent périodiquement de petites valeurs.

Comme les systèmes d’énergie peuvent affecter la facturation, le contrôle ou la sécurité, l’authentification et l’intégrité des messages doivent être traitées avec soin.

Véhicules connectés et mobilité

Les plateformes de véhicules, bornes de recharge, systèmes de flotte et services de mobilité peuvent utiliser le protocole pour la télémétrie, les mises à jour de localisation, les diagnostics, les alertes et les fonctions de contrôle à distance.

Les réseaux mobiles peuvent être instables, donc la gestion de session, la logique de reconnexion et la conception efficace de la charge utile sont importantes.

Grand public et domotique

Les systèmes de domotique utilisent MQTT pour connecter capteurs, interrupteurs, lampes, thermostats, caméras, hubs et règles d’automatisation. Le modèle publication/abonnement permet facilement à un événement de capteur de déclencher plusieurs actions.

Pour les déploiements domestiques, des noms de sujets simples et une configuration sécurisée du broker local sont importants afin d’éviter la confusion et les accès non autorisés.

Considérations de performance et d’évolutivité

La taille des messages doit rester raisonnable. MQTT est efficace pour les petits messages, mais il n’est pas idéal pour les très gros fichiers ou les flux multimédias lourds. Les grosses charges utiles peuvent augmenter l’utilisation mémoire du broker, la congestion réseau et les délais de traitement.

La conception des sujets affecte les performances. L’usage excessif d’abonnements à jokers larges peut augmenter la charge du broker, car de nombreux messages doivent être comparés et livrés à de nombreux clients. Une hiérarchie claire aide les systèmes à évoluer de façon plus prévisible.

Le nombre de connexions est un autre facteur. Un broker servant des milliers ou des millions de clients doit gérer le trafic keepalive, l’authentification, l’état de session, les messages conservés, les messages en file et les limites réseau. La mise à l’échelle peut nécessiter clustering, équilibrage de charge, agrégation edge ou partitionnement des sujets.

Le niveau QoS affecte aussi les performances. QoS 2 fournit une sémantique de livraison plus forte, mais crée davantage d’échanges de paquets. Pour une télémétrie à fort volume, QoS 0 ou QoS 1 avec une logique applicative est souvent plus pratique.

Erreurs de conception courantes

Nommage des sujets peu clair

Des noms de sujets aléatoires ou incohérents compliquent la gestion des permissions, tableaux de bord, alertes et analyses. Un plan de sujets doit être créé avant un déploiement à grande échelle.

Utiliser les messages conservés pour des événements

Les messages conservés conviennent mieux à l’état courant. Les utiliser pour des événements ponctuels peut induire les nouveaux abonnés en erreur, car ils peuvent recevoir un ancien événement comme s’il venait de se produire.

Absence de gestion des doublons

QoS 1 peut livrer des doublons. Les applications doivent utiliser des horodatages, des ID de message, des numéros de séquence ou un traitement idempotent lorsque les messages dupliqués peuvent poser problème.

Gestion faible des identifiants

Des mots de passe partagés codés en dur, des ID client réutilisés et des certificats non protégés peuvent créer de graves risques de sécurité. Chaque appareil doit disposer d’une identité gérable et d’un chemin de révocation.

Ignorer la panne du broker

Le broker est central dans l’architecture. S’il tombe en panne sans redondance ni plan de reprise, la communication peut s’arrêter. Les déploiements critiques doivent envisager le clustering, des brokers de secours, une conception de pont ou un comportement local de repli.

MQTT fonctionne bien lorsque les sujets, sessions, QoS, états conservés, sécurité et capacité du broker sont conçus ensemble au lieu d’être configurés comme des paramètres isolés.

Maintenance et supervision

Les équipes d’exploitation doivent surveiller le CPU du broker, la mémoire, le nombre de connexions, le débit de messages, le nombre de messages conservés, le nombre d’abonnements, les messages en file, les échecs d’authentification, les connexions perdues et la latence réseau.

La santé des clients doit également être visible. Des reconnexions répétées, des sessions expirées, des ID client dupliqués, des taux de publication anormaux et des accès inattendus aux sujets peuvent indiquer des pannes d’appareils ou des problèmes de sécurité.

Les sauvegardes de configuration sont importantes. Les paramètres du broker, listes de contrôle d’accès, certificats, politiques de sujets, réglages de pont et comportements d’état conservé doivent être documentés et récupérables.

Questions fréquentes

MQTT peut-il fonctionner sur WebSocket ?

Oui. De nombreux brokers prennent en charge MQTT sur WebSocket, ce qui permet aux applications basées sur navigateur et aux tableaux de bord web de communiquer via des chemins de transport adaptés au web.

Convient-il à l’envoi de grosses vidéos ou de fichiers volumineux ?

En général, pas comme méthode principale. Il convient mieux aux petits messages, à la télémétrie, aux événements, aux commandes et aux mises à jour d’état. Les gros fichiers sont souvent transférés par d’autres protocoles, avec un message contenant la référence du fichier.

Que se passe-t-il si deux clients utilisent le même ID client ?

De nombreux brokers déconnectent le client existant lorsqu’un nouveau client se connecte avec le même ID. Des ID client uniques sont importants pour un comportement de session stable.

Un broker peut-il se connecter à un autre broker ?

Oui. Le pont entre brokers ou le clustering peuvent être utilisés pour échanger des sujets sélectionnés entre sites, régions, passerelles edge et plateformes cloud, selon les capacités du broker.

Comment planifier les noms de sujets ?

Utilisez une hiérarchie cohérente fondée sur le site, le système, l’appareil, le type de données et la fonction. Évitez les noms aléatoires, les informations sensibles dans les chemins de sujet et une dépendance excessive aux jokers larges.