Quel que soit leur niveau de sophistication, les appareils IoT sont quasi inutiles s’ils ne peuvent pas communiquer avec d’autres dispositifs, services ou applications. Pour pouvoir se connecter, ils ont besoin d’un protocole et le plus populaire d’entre eux est MQTT.
Entre la fin du 20ème et le début du 21ème siècle, la convergence de plusieurs facteurs a soudain fait de l’IoT (Internet des Objets) une réalité viable, lui permettant alors d’exploser. Ces facteurs sont multiples : l’avènement de la technologie RFID (radio-identification), l’introduction du protocole IPv6 qui augmente largement le nombre de dispositifs pouvant être connectés, ou encore les connexions réseau plus rapides. Les deux-tiers des entreprises industrielles françaises ont déployé des technologies comme l’IoT et le Big Data pour exploiter au mieux les données collectées par des capteurs, selon le cabinet de conseil Wavestone, qui a réalisé une étude sur la digitalisation de l’industrie française. Et, selon Gartner, au niveau mondial, 12 millions de devices IoT seront achetés chaque jour en 2022.
Mais un autre facteur figure parmi ceux ayant le plus contribué à ce qu’est l’IoT aujourd’hui : MQTT (Message Queuing Telemetry Transport). Il s’agit d’un protocole de messagerie léger, à utiliser lorsqu’on ne dispose que d’un petit espace de données et que l’on est connecté à des réseaux peu fiables ou à la bande passante limitée. Il est principalement utilisé pour les communications machine to machine (M2M) ou les connexions de l’IoT.
Les origines de MQTT
A la fin des années 90, les systèmes Scada (Supervisory Control and Data Acquisition) étaient très utilisés pour gérer à distance de grandes infrastructures industrielles, tels que les oléoducs ou les réseaux électriques, et ils le sont encore beaucoup aujourd’hui. Comme ils se connectaient à distance à des machines et des appareils, ils sont souvent considérés comme les précurseurs des systèmes IoT actuels.
Ce moyen de connexion était appelé « télémétrie » et fonctionnait avec une grande diversité de protocoles propriétaires développés par des fabricants, entraînant toutes sortes de problèmes de compatibilité. C’est pourquoi deux ingénieurs d’IBM, Andy Stanford-Clark et Arlen Nipper, ont décidé de créer un protocole open source pour tous les remplacer : MQTT.
Le fondement du développement de ce protocole, publié en 1998, reposait sur trois principes toujours en vigueur aujourd’hui dans ses mises à jour : il devait être compact, facile à comprendre et simple à mettre en œuvre. Bien qu’il n’ait été initialement destiné qu’à la gestion à distance par satellite des composants des oléoducs, il est vite devenu évident que MQTT pourrait avoir des applications en dehors des systèmes Scada.
L’IoT adopte MQTT
Lors de l’essor de l’IoT dans les années 2000, les ingénieurs et les fabricants cherchaient un moyen de connecter leurs nouveaux appareils. Par sa sophistication et son utilité, MQTT répondait parfaitement à leurs besoins et s’est donc peu à peu répandu. C’est vers 2008 que le point de bascule s’est produit lorsqu’a été lancé le broker MQTT open source Mosquitto (appelé aujourd’hui Eclipse Mosquitto), rendant le protocole plus accessible. Son taux d’adoption a alors fortement augmenté.
Devenu une norme ISO en 2016, MQTT connectait déjà des millions d’appareils dans le monde, dans toutes sortes d’applications et d’industries. IBM, Amazon et Microsoft ne sont que quelques exemples de grands acteurs qui ont adopté MQTT comme protocole central.
Si MQTT a rencontré un tel succès, c’est grâce à l’objectif des trois principes que ses créateurs ont réussi à atteindre. En fait, MQTT a été si bien conçu que très peu de changements ont été apportés au protocole au cours de ses 10 premières années d’existence.
L’architecture de MQTT
En tant que protocole open source léger et grâce à sa simplicité, MQTT nécessite peu de traitement et de consommation de la part des appareils IoT, mais aussi peu de bande passante, avec des en-têtes de message très courts. Il est également possible de définir différents niveaux de Qualité de Service (QoS) pour les messages, afin de pouvoir contrôler le nombre de fois où ils sont envoyés et le type d’authentification utilisé. Tout cela rend MQTT pratique pour de nombreux types de réseaux différents.
Au cœur de son concept se trouvent les serveurs et les clients. Ceux-ci sont capables de s’envoyer des messages en utilisant les éléments suivants :
- Sujets (topics) : ils servent à catégoriser le type de message à envoyer. Par exemple, si un capteur mesure la température, le sujet peut être défini en « TEMP » et le capteur enverra des messages étiquetés « TEMP ».
- Éditeurs (publishers) : les appareils peuvent être configurés pour envoyer des messages contenant des données. Dans l’exemple ci-dessus, le capteur mesurant la température publie ces données.
- Abonnés (subscribers) : les appareils ou systèmes peuvent être configurés pour recevoir des messages sur un sujet spécifique uniquement et également s’abonner à plusieurs sujets.
- Broker : c’est le serveur central qui transmet les messages publiés aux clients abonnés à des sujets spécifiques. Il s’agit donc d’une solution très simple où des serveurs peuvent publier des messages, et où d’autres serveurs/clients sont configurés pour «écouter» des messages spécifiques.
L’omniprésence de MQTT
Devenu une norme industrielle, le protocole MQTT est le plus utilisé dans les environnements IoT, alors qu’il existe pourtant plusieurs alternatives telles que :
- HTML : il y a dix ans, il aurait pu être la solution la plus évidente, mais il n’est pas adapté aux exigences de l’IoT dans sa manière de gérer les événements. Avec HTML, le destinataire doit interroger continuellement la source pour vérifier si l’événement d’envoi s’est produit, ce qui n’est pas très efficace et peu économe en traitement et alimentation. Avec MQTT, au contraire, un message est envoyé une fois que l’événement s’est produit, il n’est pas nécessaire de procéder à une écoute continue.
- AMQP : il s’agit d’un protocole plus bavard, mais aussi plus flexible que MQTT car il ne s’embarrasse pas d’établir un lien vers un nœud ni d’autoriser le flux. Il en résulte que sur des sessions de longue durée, la quantité de données transférées peut être inférieure à celle des opérations équivalentes de MQTT. AMQP est donc une bonne option, mais MQTT est souvent nécessaire lorsque l’on a besoin d’une option légère et peu encombrante.
- CoAP : une autre bonne solution, similaire à HTTP, mais conçue pour les appareils sous contraintes. Contrairement à MQTT, qui permet de faire passer des messages entre plusieurs serveurs par un broker central, CoAP est un protocole de transfert d’état entre un client et un serveur, non basé sur des événements. Comme de nombreuses installations IoT sont basées sur des événements, MQTT lui est très souvent préféré.
Attention aux problèmes de sécurité
MQTT a donc connu une croissance fulgurante et il est aujourd’hui très populaire, mais on ne peut ignorer les questions de sécurité qu’il implique. En tant que protocole, MQTT est sûr, mais c’est la façon dont il est mis en œuvre et configuré peut poser problème. Car comme toujours, si la configuration n’est pas sécurisée, c’est tout l’environnement informatique qui est compromis. D’après une étude de Gemalto, 65 % des consommateurs redoutent la prise de contrôle des appareils IoT par un pirate informatique, tandis que six sur dix (60 %) se montrent préoccupés par le vol de données. D’autant que seulement 67 % des entreprises chiffrent toutes les données enregistrées ou stockées via des périphériques IoT.
Dans le cas de MQTT, le problème de sécurité est exacerbé par le fait que si un tiers accède à l’environnement, il peut s’abonner à tous les messages qui circulent. Lors d’une récente affaire, sur 49 000 serveurs MQTT exposés sur Internet, on a constaté que plus de 32 000 d’entre eux n’étaient pas protégés par un mot de passe. De multiples données liées à la smart city, telles que des mesures environnementales, des données GPS et plus encore, étaient ainsi accessibles.
En réalité, les problèmes de sécurité auxquels MQTT est confronté sont les mêmes que ceux de l’IoT en général. Tant que les personnes qui mettent en œuvre ces systèmes ne seront pas mieux informées et sensibilisées à la manière de configurer et sécuriser des environnements, la sécurité restera le plus grand danger pour l’avenir de l’IoT. On peut être sûr cependant que la facilité d’utilisation et la simplicité de MQTT font qu’il continuera à contribuer fortement à la révolution de l’IoT actuellement en cours.
Cet article a été écrit par Fabien Pereira Vaz, Technical Sales Manager France chez Paessler AG.
Plateformes IoT : les quatre catégories
- Les plateformes IoT pour le déploiement rapide d’applications permettent une connectivité des périphériques, la visualisation des données via des tableaux de bord par glisser-déposer et le traitement des événements.
- Les plateformes IoT pour la gestion des produits connectés prennent en charge la gestion critique de divers parcs d’objets connectés à grande échelle. D’un point de vue fonctionnel, outre le « provisioning » d’objets, ces plateformes se concentrent principalement sur les mises à jour logicielles gérées de manière centralisée au niveau des produits connectés, mais également sur leur configuration et leur contrôle à distance.
- Les plateformes IoT destinées aux applications analytiques permettent le développement d’applications IoT plus complexes, telles que la maintenance prédictive. Une plateforme IoT doit fournir des fonctionnalités dédiées en matière d’analyse de données, d’intelligence artificielle, d’intégration d’applications et de développement applicatif.
- Les plateformes IoT pour le développement de produits connectés.
Source : Teknowlogy Group.