Qu'est-ce que MQTT, et pourquoi chaque cours d'IoT à l'école réclame-t-il soudain un broker ?
MQTT est un protocole de messagerie léger qui permet aux microcontrôleurs de la classe de partager des données sans connexion directe de pair à pair. En faisant transiter le trafic par un broker central, il contourne les pare-feu scolaires restrictifs et évite que les appareils ne s'effondrent sous la charge réseau.
Si vous avez récemment consulté un programme de codage et robotique aligné sur le CAPS, ou tenté de concevoir un travail pratique d'Internet des objets (IoT) pour votre classe, vous êtes sans doute tombé sur l'acronyme MQTT et sur l'exigence d'un « broker MQTT ». Pour un enseignant d'informatique ou un coordinateur technologique débordé, cela peut ressembler à de la complexité inutile. Pourquoi un microcontrôleur, un ESP32 ou un Raspberry Pi Pico W par exemple, ne peut-il pas simplement envoyer ses données de capteur directement à l'ordinateur portable ou au téléphone d'un élève via le réseau Wi-Fi local ?
La réponse courte, c'est que la communication directe d'appareil à appareil est fragile, gourmande en ressources et presque totalement incompatible avec la sécurité des réseaux scolaires. MQTT (Message Queuing Telemetry Transport) résout ce problème en séparant l'émetteur des données de son destinataire, tous les messages transitant par un gestionnaire central appelé broker. C'est le standard de l'industrie pour l'IoT industriel, et il devient de plus en plus indispensable à l'informatique embarquée en classe.
Le panneau d'affichage de la classe : comprendre le pub/sub
Pour comprendre pourquoi MQTT fonctionne, imaginez une classe de 40 élèves. Si chaque élève voulant connaître la température extérieure devait aller trouver le seul élève assis près de la fenêtre pour lui demander « il fait quelle température ? », celui-ci passerait tout le cours à répondre à des questions répétitives au lieu de faire son propre travail. Et si dix élèves de plus voulaient savoir à quelle heure a lieu la prochaine récréation, ils devraient interrompre directement l'enseignant.
Installons maintenant un panneau d'affichage dans le couloir. L'élève près de la fenêtre écrit « Température : 22 °C » sur un post-it et l'épingle sous l'intitulé « Météo ». L'enseignant épingle « Prochaine récréation : 10h30 » sous « Emploi du temps ». Quiconque veut connaître la température ou l'heure de la récréation se rend simplement au panneau et le lit. L'élève près de la fenêtre ne sait pas qui lit la température, et cela lui est égal : il se contente de publier la mise à jour. Les lecteurs, eux, n'ont pas besoin de le déranger.
C'est le modèle Publication/Abonnement (pub/sub) qu'utilise MQTT :
- Le publieur : le microcontrôleur équipé d'un capteur (l'élève près de la fenêtre) qui envoie des données au broker.
- L'abonné : le tableau de bord, l'application mobile ou la base de données (les élèves qui lisent le panneau) qui souhaite recevoir ces données.
- Le broker : le serveur central (le panneau d'affichage) qui reçoit les messages des publieurs et les achemine vers les bons abonnés.
Le cœur technique : topics, messages retenus et dernières volontés
MQTT repose sur trois notions fondamentales pour garder une communication efficace et fiable, même sur des liaisons sans fil médiocres.
1. Les topics : les messages ne sont pas envoyés à des appareils précis, ils sont publiés sur des « topics ». Les topics sont structurés à l'aide de barres obliques, ce qui crée une hiérarchie du type school/lab1/temp ou home/garden/moisture. Un appareil peut s'abonner à un topic très précis, ou utiliser des caractères génériques pour écouter plusieurs topics à la fois. Par exemple, s'abonner à school/+/temp permet à un seul tableau de bord d'afficher les relevés de température de tous les laboratoires de l'établissement.
2. Les messages retenus : normalement, si un capteur publie un relevé et que personne n'est abonné à cette milliseconde précise, le message est perdu à jamais. Si un élève ouvre son application de tableau de bord cinq minutes plus tard, il voit un écran vide jusqu'à la prochaine transmission du capteur. En activant l'indicateur « retained » sur un message, le publieur dit au broker : « garde cette dernière valeur en réserve ; la prochaine fois que quelqu'un s'abonne à ce topic, donne-la-lui immédiatement ». C'est essentiel pour les données à évolution lente, comme l'humidité du sol ou le niveau d'une cuve d'eau.
3. Le testament (Last Will and Testament, LWT) : dans les classes sud-africaines, les microcontrôleurs subissent des déconnexions fréquentes et brutales, dues au délestage, à des piles à plat ou à des élèves qui débranchent un câble d'alimentation par mégarde. Lorsqu'un appareil se connecte pour la première fois au broker, il enregistre un message de « dernières volontés » (par exemple, topic : status/sensor1, message : offline). Si l'appareil perd soudainement son alimentation sans envoyer de signal de déconnexion propre, le broker détecte la rupture de connexion et publie automatiquement ce message à sa place, avertissant le reste du système que le matériel est hors ligne.
Trois choses qui tournent mal sur un réseau scolaire
MQTT a beau être robuste, le déployer en milieu éducatif suppose de composer avec les réalités de l'infrastructure informatique des écoles. Trois modes de défaillance courants perturbent régulièrement les cours :
Défaillances courantes des réseaux scolaires
| Caractéristique du réseau | Pourquoi elle existe | Comment elle casse le cours d'IoT |
|---|---|---|
| Sécurité WPA2-Enterprise | Protège les réseaux scolaires en exigeant un identifiant et un mot de passe individuels pour chaque élève. | Les microcontrôleurs courants (comme les puces ESP8266 de base) ne savent pas négocier facilement les protocoles de sécurité Enterprise en sortie de boîte, ce qui les empêche de rejoindre le Wi-Fi. |
| Isolation des points d'accès (AP isolation) | Empêche les élèves de pirater les ordinateurs portables des autres ou d'y accéder via le Wi-Fi local. | Bloque le trafic local de pair à pair. Si vous faites tourner un broker MQTT sur un Raspberry Pi dans la salle de classe, les appareils des élèves connectés au même Wi-Fi ne pourront pas l'atteindre. |
| Rotation dynamique des adresses IP (DHCP) | Recycle les adresses IP pour éviter que le routeur de l'école n'en manque. | Si vous faites tourner un broker local sur un ordinateur portable, son adresse IP changera régulièrement. Tout code de microcontrôleur contenant une adresse IP en dur ne parviendra plus à se connecter le lendemain. |
Pour contourner ces obstacles du réseau local, les enseignants doivent généralement choisir entre batailler avec leur service informatique pour obtenir des configurations de routeur sur mesure, ou faire transiter leur trafic par un broker externe hébergé dans le cloud, accessible sur les ports web standard. Pour les enseignants en quête d'une solution simplifiée et prête pour la classe, qui évite entièrement ces casse-tête de réseau local, la plateforme sheen IoT fournit un environnement MQTT préconfiguré et hébergé dans le cloud, conçu spécifiquement pour fonctionner avec les contraintes des pare-feu scolaires.
En déplaçant la charge de messagerie des microcontrôleurs vers un broker dédié, MQTT garantit que, même si le code d'un élève n'est pas optimisé ou si le Wi-Fi de l'école faiblit, les objets connectés de la classe peuvent communiquer de façon fiable et sécurisée.
