Le module MQTT de Meshtastic relie un mesh LoRa local à l’internet élargi en laissant un node connecté à internet agir comme gateway qui achemine les packets du mesh vers un broker MQTT sur IP. Cela relie des meshes physiquement séparés, alimente les cartes en ligne et permet la télémétrie à distance — mais le broker public par défaut peut exposer les identifiants de nodes, les métadonnées de gateway et la position à quiconque écoute, de sorte que les opérateurs soucieux de la vie privée devraient héberger eux-mêmes un broker privé et réduire la précision de position plutôt que de faire l’uplink de tout vers mqtt.meshtastic.org.
Meshtastic repose sur LoRa, une radio longue portée et à faible bande passante qui fonctionne sans internet, sans tours cellulaires et sans opérateur. Cette indépendance est tout l’enjeu — c’est pourquoi le réseautage mesh et Bitcoin partagent une thèse de souveraineté commune. Le module MQTT est l’endroit où ce mesh hors réseau rejoint délibérément internet, et comprendre exactement ce qui traverse ce pont est essentiel avant de l’activer. Ce guide explique ce que fait le module, comment le pont est câblé, la configuration qui compte, et les compromis sur lesquels la documentation officielle est explicite. Si vous n’avez pas encore configuré une radio, commencez d’abord par notre guide de démarrage Meshtastic.
Ce que le module MQTT fait réellement
Par lui-même, un mesh LoRa est une île. Deux meshes Meshtastic dans des villes différentes ne peuvent pas s’entendre — la portée radio est la limite dure. Le module MQTT résout cela en donnant au mesh une rampe d’accès optionnelle vers internet. Selon la documentation officielle Meshtastic, le module « permet aux appareils connectés à internet via WiFi ou ethernet de transmettre les packets du mesh vers un serveur MQTT », reliant les utilisateurs du mesh local aux systèmes connectés à internet.
En pratique, cela débloque trois choses. Premièrement, cela relie des meshes distants : les packets en uplink depuis un mesh peuvent être en downlink dans un autre, de sorte que deux régions liées au même broker se comportent comme un seul réseau logique. Deuxièmement, cela alimente cartes et tableaux de bord — les nodes peuvent publier des rapports de position et de télémétrie que les services de cartographie en ligne affichent. Troisièmement, cela permet la surveillance à distance : vous pouvez observer les infos de node d’un site distant, la télémétrie des capteurs et le trafic de messages depuis n’importe où, sans être à côté de la radio. MQTT (Message Queuing Telemetry Transport) est un protocole léger de publication/abonnement conçu exactement pour ce type de messagerie machine-à-machine à faible surcharge, ce qui explique pourquoi Meshtastic l’a adopté comme pont.
Comment fonctionne le pont
Le pont a besoin d’un ou plusieurs nodes ayant accès à internet — via WiFi, ethernet, ou en passant par la connexion d’un téléphone. Ces nodes deviennent des gateways. Un gateway s’abonne et publie vers un broker MQTT pour le reste du mesh, qui peut n’avoir aucun accès internet. Les radios hors réseau continuent de parler LoRa au gateway ; le gateway traduit entre LoRa et IP.
Fait crucial, le module ne transmet pas aveuglément tout. La documentation indique qu’« un ou plusieurs canaux doivent aussi être activés en uplink et/ou downlink pour que les packets soient transmis depuis et/ou vers votre mesh ». C’est une décision par canal, contrôlée par deux commutateurs sur chaque canal :
- Uplink activé — « Si activé, les messages du mesh seront envoyés vers l’internet public via le gateway configuré de tout node. » Par défaut : désactivé.
- Downlink activé — « Si activé, les messages captés depuis un gateway internet public seront transmis au mesh local. » Par défaut : désactivé.
Vous choisissez donc la direction par canal. Un canal peut être uplink seulement (le mesh rapporte vers l’extérieur mais n’accepte rien en retour), downlink seulement, les deux, ou ni l’un ni l’autre. Cette granularité est votre premier et plus important contrôle de confidentialité : un canal avec les deux commutateurs désactivés ne touche jamais MQTT, peu importe ce que fait le gateway.
Root topic, et JSON versus protobuf
Les packets en uplink sont publiés sous un root topic, qui par défaut est msh/REGION. Le topic complet pour un packet protobuf chiffré ressemble à msh/REGION/2/e/CHANNELNAME/USERID. La documentation note que « les versions de firmware antérieures à 2.3.0 publieront vers un topic avec /c/ à la place de /e/ ». Le corps du packet sur le chemin /2/e/ est un protobuf brut MeshPacket, et si le chiffrement de canal est en vigueur le payload reste chiffré sur le broker.
Meshtastic pouvait historiquement publier une représentation JSON décodée sur un topic comme msh/US/2/json/CHANNELNAME/USERID, couvrant des types de packets tels que les messages texte, la télémétrie, les infos de node et la position. Le JSON est pratique pour les scripts, tableaux de bord et intégrations parce qu’il est lisible par l’humain — mais cette lisibilité est le piège : la sortie JSON est non chiffrée. (Le JSON n’est pas non plus pris en charge sur le matériel de classe nRF52.) À compter de la mi-2026, ce chemin est déprécié en amont : la définition protobuf marque json_enabled comme déprécié et note que le support des packets JSON sur MQTT a été retiré et que le champ est ignoré, de sorte que le firmware actuel n’honore plus le commutateur — tandis que les firmwares plus anciens encore en service publient toujours sur /2/json/, ce qui explique pourquoi le format reste documenté ici. Choisir un root topic personnalisé permet d’isoler votre trafic dans son propre espace de noms sur un broker partagé, ce qui compte une fois que vous hébergez vous-même avec des listes de contrôle d’accès.
Bases de configuration
Les paramètres du module sont accessibles depuis les applications Meshtastic ou le CLI. Les champs qui comptent le plus sont résumés ci-dessous.
| Paramètre | Ce qu’il contrôle | Note de confidentialité |
|---|---|---|
| Enabled | Active le module MQTT pour ce node. | Désactivé par défaut ; rien n’est ponté tant que vous ne l’activez pas. |
| Server Address | Point de terminaison du broker ; par défaut mqtt.meshtastic.org. | Pointez-le vers votre propre broker pour garder le trafic privé. |
| Username / Password | Identifiants d’authentification du broker. | Le broker public utilise des identifiants partagés, documentés publiquement. |
| Encryption Enabled | Si le payload protobuf envoyé au broker est chiffré. | Si désactivé, les payloads arrivent au broker en clair. |
| JSON Enabled | Publie une copie JSON décodée des packets. Déprécié en amont — le champ json_enabled est ignoré par le firmware actuel ; seuls les firmwares plus anciens publient encore du JSON. | La sortie JSON est toujours non chiffrée ; non disponible sur nRF52. |
| TLS Enabled | Enveloppe la connexion au broker en TLS. | Protège le lien en transit, pas les données au repos sur le broker. |
| Root Topic | Préfixe d’espace de noms pour vos topics publiés. | Utilisé avec les ACL du broker pour isoler les réseaux. |
| Proxy to Client Enabled | Achemine MQTT via le téléphone/l’application connectés au lieu du WiFi propre du node. | Utile lorsque le node lui-même n’a pas d’uplink IP. |
| Map Reporting Enabled | Envoie périodiquement un rapport de carte non chiffré (firmware 2.3.2+). | Toujours non chiffré par conception ; la précision de position contrôlée s’applique. |
Deux autres réglages se trouvent sur le canal, pas sur le module. Le paramètre de précision de position (position_precision) contrôle la granularité de la localisation partagée, de 0 (aucune donnée de localisation envoyée) jusqu’à la précision complète. Et chaque canal porte sa propre clé pré-partagée (PSK) pour le chiffrement AES. Ces deux paramètres — commutateurs de direction plus précision de position et PSK — sont là où votre véritable posture de confidentialité se décide.
Le broker public par défaut versus l’auto-hébergement
Par défaut, Meshtastic pointe vers le broker communautaire mqtt.meshtastic.org. C’est le chemin de moindre résistance et un excellent moyen de voir le module fonctionner. La documentation officielle est toutefois candide sur ses coûts. Elle avertit que « le canal par défaut (LongFast) sur le serveur public a habituellement beaucoup de trafic. Votre appareil peut être surchargé et peut ne plus fonctionner correctement » — un mode de défaillance réel et pratique, pas hypothétique.
Héberger vous-même votre propre broker contourne à la fois le problème de trafic et le problème d’exposition. Meshtastic documente l’utilisation de Mosquitto, un broker MQTT open source largement déployé, que vous pouvez faire tourner sur un Raspberry Pi, un petit VPS, ou un serveur domestique. Le démarrage rapide dans la documentation montre la config minimale — un listener sur le port 1883 — mais pour tout ce qui dépasse un banc d’essai vous devriez exiger un nom d’utilisateur et un mot de passe, activer TLS, et utiliser des ACL de broker limitées à votre root topic afin que seuls vos nodes puissent publier et s’abonner. Notre guide de broker Mosquitto privé pas à pas parcourt exactement cette construction — le mosquitto.conf verrouillé, les utilisateurs, les ACL limitées à votre root topic, et les paramètres de node correspondants. Un broker privé signifie que les métadonnées de votre mesh ne se retrouvent jamais dans un bassin communautaire partagé, et cela s’accorde naturellement avec l’état d’esprit d’auto-hébergement plus large derrière le fait de faire tourner votre propre relay Nostr ou autre infrastructure personnelle.
Les compromis à bien comprendre
C’est la partie à relire deux fois. MQTT est un trou délibéré percé dans l’isolement de votre mesh, et la documentation est explicite sur ce qui fuit.
Premièrement, le chiffrement n’est pas automatique sur le pont. La documentation avertit : « Tous les messages sont envoyés au broker MQTT non chiffrés si cette option n’est pas activée, même lorsque vos canaux en uplink ont des clés de chiffrement définies. » Autrement dit, une PSK de canal solide protège vos packets à l’antenne, mais elle ne garantit pas qu’ils restent chiffrés une fois qu’un gateway les republie vers MQTT — cela dépend du paramètre Encryption Enabled du module lui-même, et la sortie JSON (là où les firmwares plus anciens l’émettent encore) est non chiffrée dans tous les cas.
Deuxièmement, les métadonnées fuient même lorsque les payloads sont chiffrés. La chaîne de topic elle-même — msh/REGION/2/e/CHANNELNAME/USERID — divulgue votre région, le nom du canal et l’ID utilisateur du node gateway à quiconque peut lire le broker. Sur le broker public, c’est effectivement le public. Un observateur qui ne peut pas déchiffrer vos messages peut quand même voir qu’un node particulier existe, sur quel canal il se trouve, approximativement où (par région), et quand il est actif. Le chiffrement du payload de canal protège le contenu des messages ; il ne cache pas que la conversation a lieu.
Troisièmement, la position et le map reporting sont intentionnellement tournés vers le public. Map Reporting envoie un rapport non chiffré contenant les identifiants de node, la position, le modèle matériel, la version de firmware, la configuration LoRa et un décompte de pairs locaux, à un intervalle minimal d’une heure, afin que les cartes en ligne puissent l’afficher. Les atténuations sont intégrées : le serveur MQTT public filtre les positions les plus précises, et vous contrôlez position_precision par canal — réglez-le à 0 pour ne partager aucune localisation, ou à une valeur grossière pour ne partager qu’une zone approximative. Si la confidentialité de la localisation compte, abaissez la précision avant l’uplink, pas après.
Rien de tout cela n’est un défaut de Meshtastic — c’est le coût honnête de relier un réseau hors grille à l’internet mondial, et le projet vous donne les commutateurs pour le gérer. La leçon est simple : ne faites l’uplink que des canaux que vous voulez vraiment, préférez un broker privé, gardez Encryption Enabled activé, traitez le JSON comme un héritage (déprécié en amont et ignoré par le firmware actuel — les firmwares plus anciens le publient encore, non chiffré), et baissez la précision de position. Pour les utilisateurs qui veulent relier des sites distants indépendamment d’internet sans un broker public au milieu, la pile Reticulum et d’autres approches dans notre comparaison des protocoles de réseautage mesh méritent d’être pesées. Le module MQTT et ces alternatives s’inscrivent tous dans le même outillage de souveraineté numérique plus large.
Ce qui reste privé, ce qui fuit
| Élément | Sur le broker public par défaut | Sur un broker privé auto-hébergé (TLS + ACL) |
|---|---|---|
| Payload de message de canal (protobuf, Encryption Enabled activé) | Chiffré au repos, mais présent dans un bassin public | Chiffré et confiné à votre broker |
| Payload décodé JSON (firmware plus ancien — déprécié en amont) | Public et lisible | Lisible seulement par vos clients authentifiés |
| Métadonnées de topic (région, nom du canal, ID du gateway) | Visibles à quiconque lit le broker | Visibles seulement à l’intérieur de votre réseau |
| Rapport de carte / position | Publié pour les cartes publiques ; positions précises filtrées | Reste sur votre broker ; vous choisissez les destinataires |
| Connexion (TLS) | Disponible ; protège le transit seulement | Vous l’imposez de bout en bout |
L’angle bitcoiner
Pour un opérateur souverain, le module MQTT porte moins sur le clavardage sur la carte publique que sur la coordination lorsque la connectivité est rare. Imaginez un hangar de minage éloigné, un node domestique et un site de secours, dont aucun n’a d’internet fiable sauf un emplacement. Faites tourner un gateway au site connecté, pointez chaque node vers un broker privé que vous contrôlez, et vous obtenez une liaison sélective indépendante d’internet : les sites hors grille parlent LoRa au gateway, et le gateway n’achemine sur IP que les canaux que vous choisissez.
C’est véritablement utile pour la télémétrie à faible bande passante. Les packets de télémétrie Meshtastic peuvent transporter des données de capteurs et environnementales, de sorte qu’un site distant peut rapporter la température, l’état d’alimentation, ou un simple battement de cœur via le mesh, et le pont MQTT le fait remonter sur un tableau de bord à l’unique emplacement connecté. C’est le même instinct architectural qui pousse les bitcoiners à faire tourner leur propre infrastructure de bout en bout — votre propre node, votre propre relay, votre propre broker — plutôt que de louer la confiance à un tiers. Si vous publiez ouvertement, notre hub de données ouvertes montre le type de sortie structurée et interrogeable que cette télémétrie peut devenir, et le motif de pontage de relay rime avec la façon dont les relays Nostr relient des clients autrement isolés. Gardez le broker privé, gardez la précision de position basse pour tout site dont vous préférez ne pas annoncer l’emplacement, et vous obtenez la portée d’internet sans céder la souveraineté qui a justifié de bâtir le mesh.
Questions fréquentes
Activer MQTT signifie-t-il que mon mesh LoRa a maintenant besoin d’internet?
Non. Le mesh continue de fonctionner entièrement sur LoRa sans internet. MQTT n’ajoute qu’un pont optionnel via un ou plusieurs nodes gateway qui se trouvent avoir internet. Si le gateway perd sa connexion, le mesh local poursuit comme avant — seul le pont internet s’interrompt.
Si mon canal a une clé de chiffrement solide, mon trafic MQTT est-il en sécurité sur le broker public?
Pas nécessairement. Une PSK de canal protège les packets à l’antenne, mais la documentation avertit que les messages atteignent le broker non chiffrés sauf si l’option Encryption Enabled du module est activée, et la sortie JSON — que les firmwares plus anciens publient encore malgré la dépréciation en amont — est toujours non chiffrée. Même avec le chiffrement du payload activé, les métadonnées de topic — région, nom du canal et ID du gateway — restent visibles à quiconque lit le broker.
Devrais-je utiliser le broker public par défaut ou faire tourner le mien?
Le broker public (mqtt.meshtastic.org) convient pour les tests et pour participer aux cartes communautaires, mais la documentation note que son canal LongFast par défaut peut surcharger un appareil, et vos métadonnées se trouvent dans un bassin partagé. Pour la confidentialité et la fiabilité, hébergez vous-même un broker Mosquitto avec authentification, TLS et des ACL limitées à votre propre root topic.
Comment garder ma localisation privée tout en utilisant MQTT?
Utilisez le paramètre position_precision par canal. Réglez-le à 0 pour ne partager aucune localisation, ou à une valeur grossière pour ne partager qu’une zone approximative. Le serveur MQTT public filtre déjà les positions les plus précises, mais sur votre propre broker c’est vous qui fixez la politique. Laissez aussi Map Reporting désactivé si vous ne voulez pas de rapports de position périodiques non chiffrés publiés.
Quelle est la différence entre uplink et downlink sur un canal?
Uplink activé envoie les messages de votre mesh vers le broker ; downlink activé amène les messages du broker dans votre mesh. Ce sont des commutateurs indépendants par canal, de sorte que vous pouvez rendre un canal en rapport seulement, en réception seulement, bidirectionnel, ou entièrement isolé de MQTT.
Deux meshes distants peuvent-ils se parler via MQTT?
Oui. Si les deux meshes partagent un canal et un broker, et que les canaux de liaison ont l’uplink et le downlink activés de façon appropriée, les packets en uplink depuis un mesh sont en downlink dans l’autre. C’est le mécanisme central pour relier des sites géographiquement séparés en un seul réseau logique sur internet.
