Vous avez choisi le LoRaWAN pour la portée et l’autonomie. Bon choix. Reste une seconde décision tout aussi importante, et que la plupart des équipes bâclent : qui exploite le réseau auquel vos appareils parlent ?
Trois réponses possibles. Vous pouvez rejoindre un réseau communautaire public comme The Things Network. Vous pouvez vous appuyer sur un réseau de couverture décentralisé comme Helium. Ou vous pouvez exploiter vos propres gateways avec un serveur réseau tel que The Things Stack ou ChirpStack. Tous font circuler les mêmes paquets LoRaWAN. Ce qui change, c’est qui contrôle la couverture, qui garantit la disponibilité, qui voit votre trafic et qui paie quoi.
Ce guide passe en revue les trois modèles, les arbitrages entre eux et le moment où chacun est le bon choix. À la fin, il relie la décision du serveur réseau à la couche au-dessus, parce que c’est la partie que les équipes oublient jusqu’à ce que les données commencent à circuler sans que personne n’ait décidé où elles vont.
Les trois modèles, sans détour
Réseau communautaire public. The Things Network en est l’exemple le plus connu. C’est un réseau LoRaWAN partagé et géré par la communauté. N’importe qui peut installer un gateway et l’ajouter à la carte de couverture publique, et n’importe qui peut enregistrer des appareils et utiliser le réseau gratuitement, dans les limites d’un usage équitable. L’infrastructure appartient à celui qui a installé le gateway le plus proche : ça peut être vous, un amateur trois rues plus loin, ou personne du tout.
Réseau de couverture décentralisé. Helium est le cas connu ici. Les opérateurs de gateways sont rémunérés par une incitation en token pour fournir de la couverture, ce qui est censé étendre la carte plus vite qu’un modèle purement bénévole. Côté appareil, ça se comporte toujours comme un réseau public : vous ne possédez pas les gateways, et votre trafic dépend d’une couverture que d’autres personnes choisissent d’exploiter.
Réseau privé. Vous achetez et placez vos propres gateways, et vous les pointez vers un serveur réseau que vous contrôlez. Ce serveur est généralement The Things Stack ou ChirpStack. La couverture est à vous, la disponibilité est à vous de gérer, et les données ne transitent jamais par l’infrastructure de quelqu’un d’autre. En contrepartie, vous assumez le coût du matériel et le travail d’exploitation.
Ce que fait réellement le serveur réseau
Avant les arbitrages, un point de vocabulaire qui fait trébucher. Le serveur réseau LoRaWAN est le cerveau entre vos gateways et vos données. Il déduplique les paquets reçus par plusieurs gateways, vérifie les clés de sécurité de l’appareil, gère les demandes de jointure, ajuste les débits de données, puis transmet la charge utile déchiffrée plus loin.
The Things Stack et ChirpStack sont tous deux des serveurs réseau. La différence entre LoRaWAN public et privé tient souvent à qui exploite ce serveur. Sur The Things Network, la communauté exécute The Things Stack pour vous. Sur un réseau privé, vous exécutez vous-même The Things Stack ou ChirpStack, sur votre propre matériel ou dans votre propre compte cloud.
C’est important pour la section suivante, et ça l’est encore plus pour la partie sur les plateformes applicatives plus loin.
Les arbitrages qui tranchent
Six facteurs distinguent les trois modèles. Aucun ne l’emporte sur les six.
Couverture. Les réseaux publics et décentralisés vous offrent une couverture que vous n’avez pas construite, là où elle existe. Dans une ville dense, The Things Network ou Helium atteignent peut-être déjà votre site. Dans un champ isolé, un sous-sol ou un campus industriel privé, cette couverture est faible ou absente, et vous ne ferez pas apparaître des gateways communautaires par la seule force de votre désir. Un réseau privé vous donne de la couverture exactement là où vous posez un gateway, et nulle part ailleurs.
Contrôle. Sur un réseau privé, vous définissez le plan de canaux, l’emplacement des gateways, la politique de débit et le calendrier de mises à jour. Sur un réseau public ou décentralisé, vous prenez ce qui est là. Si un gateway communautaire proche tombe en panne, ce n’est pas votre gateway à réparer.
Fiabilité. Un gateway que vous possédez et surveillez est un gateway dont vous pouvez exiger des comptes. Les gateways communautaires et décentralisés peuvent apparaître et disparaître sans préavis, car ceux qui les exploitent ne vous doivent rien. Pour un projet de loisir, c’est acceptable. Pour un site en production, c’est un risque qu’il faut intégrer au calcul.
Sécurité. Le LoRaWAN chiffre les charges utiles de bout en bout quel que soit le modèle, donc le lien radio n’est pas le souci. La différence est opérationnelle : sur un réseau privé, vos serveurs de jointure, vos clés et votre trafic restent dans une infrastructure que vous contrôlez. Pour des activités réglementées, cette frontière est souvent le facteur décisif à elle seule.
Coût. Les réseaux communautaires publics ne coûtent rien par message dans le cadre d’un usage équitable, ce qui est difficile à battre pour de petits projets ou des débuts. Les réseaux décentralisés impliquent généralement un coût par paquet ou en crédits de données. Un réseau privé suit la forme inverse : de l’argent réel d’emblée pour les gateways et l’installation, puis un coût quasi nul par message ensuite. Pour un déploiement dense avec de nombreux appareils sur un seul site, le modèle privé l’emporte souvent sur le coût total sur la durée de vie des appareils, même s’il paraît plus cher le premier jour.
SLA. C’est le point le plus court. Les réseaux communautaires et décentralisés ne s’accompagnent d’aucun accord de niveau de service. Personne ne vous promet de disponibilité. Un réseau privé a le SLA que vous construisez et exploitez, ce qui signifie que vous portez à la fois la promesse et le travail pour la tenir.
Quand chacun convient
Partez du besoin, pas du réseau.
Loisir, prototypage et preuve de concept. Si vous testez si le LoRaWAN convient seulement à votre idée, rejoignez The Things Network. Gratuit, rapide à lancer, sans engagement matériel si la couverture vous atteint déjà. Helium convient à un stade précoce similaire quand vous voulez une couverture plus large et acceptez un petit coût par paquet. Ne montez pas votre propre serveur pour envoyer une centaine de messages de test.
Déploiements en production. Une fois les appareils sur le terrain et productifs, le calcul bascule vers le contrôle et la fiabilité. Beaucoup d’équipes passent alors à un réseau privé, ou au moins à une instance payante et exploitée de The Things Stack, pour que la couverture et la disponibilité relèvent de la responsabilité réelle de quelqu’un. Que vous l’hébergiez vous-même ou utilisiez un serveur réseau exploité, l’objectif est le même : aucune coupure surprise.
Sites réglementés ou isolés. Santé, services publics, tout ce qui a des règles de résidence des données, ou tout site sans aucune couverture communautaire. Ici, un réseau privé est généralement la seule réponse honnête. Vous avez besoin de la frontière des données, de la couverture garantie, ou des deux, et une carte publique ne peut vous offrir ni l’une ni l’autre.
La ligne n’est pas rigide. Beaucoup de déploiements réels mélangent les modèles : un réseau privé sur le campus principal, The Things Network pour un site annexe qui dispose déjà d’une couverture. C’est très bien, et ça mène directement au point suivant.
Le serveur réseau n’est pas votre application
Quel que soit le modèle choisi, le serveur réseau fait circuler et déchiffre les paquets. C’est tout ce qu’il fait. Il ne stocke pas l’historique, ne dessine pas de dashboard, ne prévient pas un opérateur quand une cuve se vide, ne déclenche pas de pompe. Ces tâches vivent une couche au-dessus, dans la plateforme applicative. C’est là que les projets calent en général.
C’est là que TagoIO se place. TagoIO est une plateforme applicative IoT gérée qui s’exécute au-dessus du serveur réseau. Elle ingère les données déchiffrées qui sortent de votre réseau LoRaWAN, les stocke, les affiche dans des dashboards, gère vos appareils, et vous permet de construire des alertes, des API et des actions automatisées par-dessus.
Comme TagoIO s’intègre en aval du serveur réseau, le modèle choisi en dessous ne vous enferme pas. Vous utilisez The Things Network ? TagoIO récupère les données depuis The Things Stack. Vous hébergez ChirpStack sur un réseau privé ? TagoIO se connecte à ChirpStack. Vous mélangez les deux selon les sites ? La couche applicative reste identique pendant que les réseaux diffèrent en dessous. Vous pouvez changer ou combiner les modèles de réseau sans reconstruire les dashboards et la logique sur lesquels votre équipe s’appuie.
Pour les équipes qui doivent revendre ou marquer en marque blanche l’application auprès de leurs propres clients, TagoRUN le permet sur la même plateforme. Pour le traitement en périphérie au plus près des gateways, TagoCore est un runtime open source qui exécute la logique applicative sur site. La plateforme elle-même est certifiée ISO 27001 et alignée sur le GDPR, ce qui compte surtout pour ces mêmes équipes réglementées qui penchent vers le privé côté réseau.
En bref
Il n’existe pas de meilleur modèle de réseau LoRaWAN, seulement le bon pour le travail qui vous attend. Tranchez selon la couverture, le contrôle, la fiabilité, la sécurité, le coût et le SLA, pondérés par ce dont votre projet a réellement besoin. Utilisez The Things Network pour le loisir et le prototypage, Helium quand vous voulez une couverture décentralisée et en acceptez le coût, et un réseau privé sur The Things Stack ou ChirpStack quand vous avez besoin de contrôle, d’une couverture garantie ou d’une frontière de données stricte pour la production et les activités réglementées.
Choisissez ensuite la couche applicative qui se place au-dessus de tout cela, pour que les données que vous avez collectées avec effort deviennent quelque chose qu’une personne peut voir et sur quoi elle peut agir. Choisissez tôt le bon modèle de réseau. Comme le choix de la radio qui le précède, il est difficile à défaire une fois les capteurs sur le terrain.
