Tout projet LoRaWAN rencontre la même confusion dès la première semaine. L’équipe met en place un network server, voit arriver les données des appareils et demande pourquoi une autre plateforme reste nécessaire. Ou bien elle souscrit à une plateforme applicative, enregistre un capteur et demande pourquoi rien n’apparaît. Les deux questions ont la même réponse : un déploiement LoRaWAN repose sur deux couches distinctes que l’on prend souvent pour une seule, et chacune fait un travail que l’autre refuse délibérément.
Bien tracer cette séparation fait gagner des semaines. Voici ce que possède chaque couche, où se situe la frontière et comment les deux se relient en pratique.
Ce que possède le network server
Un network server LoRaWAN (LNS) relève de la gestion d’infrastructure radio. Il authentifie les appareils à leur arrivée sur le réseau, déduplique le même paquet reçu par plusieurs passerelles, planifie les downlinks par la meilleure passerelle, pilote le débit adaptatif pour préserver la batterie et applique la couche MAC de LoRaWAN. ChirpStack, The Things Stack et les serveurs exploités par des opérateurs comme Actility appartiennent tous à cette couche, et nous avons comparé les options publiques et privées dans réseaux LoRaWAN privés vs publics.
Ce que le LNS vous remet au bout de tout ce travail, c’est un payload déchiffré : quelques dizaines d’octets binaires, plus des métadonnées radio. Pas de dashboards, pas d’utilisateurs, pas d’alertes, pas d’historique digne d’être interrogé. Ce n’est pas une lacune du produit. C’est sa conception.
Ce que possède la plateforme applicative
Une plateforme applicative IoT commence là où le paquet cesse de compter et où les données commencent. Elle décode le payload binaire en variables nommées, les stocke en séries temporelles interrogeables et les transforme en ce que les gens achètent réellement : dashboards, alertes, comptes utilisateurs avec permissions, rapports et intégrations avec le reste de l’entreprise.
La couche qui distingue de plus en plus les plateformes applicatives entre elles, c’est l’intelligence. Stocker un relevé de température est le minimum. Prévoir où il sera dans six heures, signaler qu’un capteur a commencé à dériver deux jours avant sa panne et convertir une prévision en ordre de travail : c’est là que la valeur se concentre. TagoIO fait cela avec des scripts Analysis et Analytics et l’IA intégrés, de sorte que prévisions, signalements d’anomalie et recommandations apparaissent dans la même interface que les données en direct, et non dans un outil de BI séparé que quelqu’un doit penser à ouvrir.
La frontière en une phrase
Le network server garantit que le paquet arrive une fois, en sécurité et efficacement. La plateforme applicative fait en sorte que le paquet signifie quelque chose pour un humain ou pour un autre système. Si une tâche touche à la radio, à l’arrivée sur le réseau, aux passerelles ou aux facteurs d’étalement, elle appartient au LNS. Si elle touche à un utilisateur, un graphique, un seuil, une prévision ou un ERP, elle appartient à la plateforme applicative.
Confondre les couches coûte du temps réel. Des équipes tentent de bâtir l’alerting dans un LNS à coups de webhooks et de scripts, et se retrouvent à maintenir une plateforme applicative fragile qu’elles n’ont jamais voulu écrire. Ou bien elles attendent d’une plateforme applicative qu’elle diagnostique la couverture des passerelles, qu’elle ne voit pas. Chaque couche est délibérément aveugle au travail de l’autre.
Comment les deux se relient
En pratique, l’intégration est un pont de données. Le LNS pousse chaque uplink décodé vers la plateforme applicative en HTTPS ou MQTT, et les downlinks repartent par le même chemin. TagoIO fournit des intégrations prêtes pour les principaux network servers, dont The Things Network, ChirpStack et les réseaux d’opérateurs, ainsi qu’une bibliothèque de connecteurs couvrant des centaines de capteurs : le décodage de payload devient de la configuration, pas du code.
Une pile de production typique finit ainsi : capteurs, passerelles, un LNS (réseau public ou ChirpStack privé) et TagoIO au-dessus pour tout ce que voit le client. Le choix du LNS et celui de la plateforme sont des décisions indépendantes, et c’est sain : vous pouvez changer d’opérateur réseau sans reconstruire votre application, et inversement.
A-t-on parfois besoin d’une seule des deux ?
Parfois. Une simple étude de couverture peut vivre sur le seul LNS. Un déploiement cellulaire ou Wi-Fi se passe entièrement du LNS et parle directement à la plateforme applicative. Mais dès que le projet comporte des capteurs LoRaWAN et que quelqu’un d’autre qu’un ingénieur regarde les données, les deux couches sont nécessaires, et le budget honnête les inclut toutes deux dès le départ.
Si un LNS tourne déjà chez vous et que vous voulez voir la couche applicative travailler par-dessus, TagoIO se connecte en quelques minutes. Réservez une démo ou démarrez gratuitement.
