Deux articles ont déjà comparé les familles de réseaux pour faire de l’IoT et tranché entre WiFi et LoRaWAN pour un capteur industriel. Celui-ci descend d’un cran et explique la mécanique.
Qui fait quoi dans un réseau LoRaWAN
Le device mesure et émet. Il n’est associé à rien, ne connaît aucune gateway, et ne sait même pas combien l’ont entendu. Il se réveille, envoie son message, se rendort. C’est de là que vient l’autonomie : sans connexion à maintenir ni présence à signaler, il passe l’essentiel de sa vie éteint et ne consomme que pendant quelques fractions de seconde par jour. La contrepartie tient dans la même phrase, on ne peut pas l’interroger quand ça nous arrange.
La gateway entend et relaie. Elle ne décode rien, ne décide rien, ne stocke rien. Conséquence appréciable sur le terrain : ajouter une gateway ne demande de toucher à aucun device. On la pose, on la raccorde, la couverture s’améliore. C’est rare dans le sans fil.
Le serveur LoRaWAN fait le travail que personne ne voit. Quand trois gateways ont entendu le même message, elles le remontent toutes les trois et il n’en garde qu’une copie. Il vérifie l’intégrité de ce qui arrive. Il désigne, quand une réponse doit partir, laquelle des gateways l’émettra selon la qualité de réception et le temps d’antenne qu’il lui reste. Et il observe la liaison dans la durée pour ordonner au device d’ajuster son émission. Le réseau pilote le device, jamais l’inverse.
Ce découpage a une traduction physique simple. Chez le client, sur le site, il n’y a que deux choses : les devices et une ou deux gateways. Tout le reste, serveur, traitement, stockage, dashboards, tourne sur notre infrastructure hébergée en Europe. Rien à installer dans la salle serveur du client, rien à maintenir de son côté, et aucune donnée qui quitte le continent.
Sans décodeur, la mesure n’existe pas
C’est le point que les schémas d’architecture oublient et que l’installateur rencontre le premier jour. Un message qui arrive est une suite d’octets bruts. Rien dans la trame ne dit qu’il s’agit d’un index de compteur en litres ou d’une température en dixièmes de degré. Cette information est chez le constructeur du device.
Elle prend la forme d’un décodeur, un fichier fourni par le constructeur, qu’on charge dans le serveur LoRaWAN au moment d’ajouter le modèle. Sans lui, le device rejoint le réseau, ses messages arrivent, et il ne se passe rien d’utile. La LoRa Alliance a normalisé un format pour ces décodeurs, mais tous les constructeurs ne l’ont pas adopté. D’où un critère d’achat qui ne figure sur aucune fiche technique, au même titre que l’autonomie ou l’indice de protection. Et quand une valeur remonte aberrante alors que la liaison est bonne, c’est le décodeur qu’il faut regarder, pas le device.
Ce que devient la donnée ensuite
Tout message entrant est enregistré automatiquement, avant tout traitement, et la trame brute est conservée à côté de la valeur décodée. Ce n’est pas une précaution de principe : un décodeur peut être faux, un device peut être ajouté avant que sa configuration soit finalisée. Tant que le message brut existe, l’erreur se rattrape et l’historique se reconstruit. Sinon, ces journées sont perdues.
Le traitement passe ensuite par une solution no code : mise en forme des payloads, calculs, seuils, envoi de commandes programmées. Une logique métier écrite en code devient, quelques années plus tard, un objet que plus personne n’ose modifier. Construite dans un outil visuel, elle se relit et se corrige, y compris par quelqu’un qui n’a pas écrit la première version.
Ces briques ne se parlent pas en direct : le serveur publie ce qu’il reçoit, et les composants qui en ont besoin s’y abonnent, via un mécanisme d’échange de messages standard appelé MQTT. Conséquence pour le client, la donnée n’est pas prisonnière du dashboard. Un système déjà en place peut s’y raccorder, et une donnée peut aussi arriver d’un équipement qui n’a rien de LoRaWAN. C’est un sujet à part entière, sur lequel nous reviendrons.
Ce qui protège les messages
La question tombe à chaque rendez-vous, et elle est légitime : un réseau sans fil qui traverse les murs d’une usine, qu’est-ce qui empêche le voisin de lire ce qui passe.
Le chiffrement fait partie du protocole, il n’est pas une couche ajoutée par l’installateur. Chaque message est chiffré en AES-128 entre le device et le serveur, avec des clés propres à ce device. Un device qui n’a pas ses clés ne rejoint pas le réseau. Il n’y a donc pas d’installation LoRaWAN mal configurée qui émettrait en clair par distraction.
Chaque trame porte aussi un code de contrôle : un message modifié en route est rejeté au lieu d’être traité. Et chaque message embarque un compteur qui s’incrémente. Un message capté puis réémis plus tard arrive avec un compteur déjà utilisé, et le serveur l’ignore. C’est ce qui ferme la porte au rejeu, l’attaque la plus évidente sur un réseau sans fil : enregistrer le message d’un capteur de niveau et le renvoyer plus tard pour faire croire que la cuve est pleine.
Ce que ça ne protège pas, il faut le dire aussi. Un device physiquement accessible reste manipulable, et des clés mal gérées annulent le bénéfice. Le chiffrement sécurise le transport, pas l’installation. C’est déjà beaucoup, et c’est précisément ce qui sépare un réseau professionnel d’un montage sans fil bricolé.
La portée réelle, et pourquoi on ne cherche pas la maximale
Les brochures annoncent une quinzaine de kilomètres. C’est vrai en vue dégagée, entre deux points hauts, sans rien entre les deux. Aucun site industriel ne ressemble à ça. Ce qui détermine si un message passe n’est pas la distance mais ce qui se trouve sur son chemin : un device à cinquante mètres derrière deux murs en béton armé passe moins bien qu’un device à trois cents mètres dans une cour dégagée.
Position que nous assumons : nous ne cherchons pas à couvrir une commune. Nous couvrons la zone que le client demande, un atelier, un hall, un site. Personne n’achète de la portée, on achète des points de mesure qui remontent.
Ce n’est pas qu’une affaire de budget. Une antenne à fort gain ne rayonne pas davantage, elle rayonne différemment : elle concentre vers l’horizon ce qu’elle retire au-dessus et en dessous d’elle. Elle porte loin et couvre mal ce qui se trouve à son pied ou à un autre niveau du bâtiment. Sur un site compact, monter en gain fait perdre de la couverture utile.
Ce qui dégrade une liaison dans un bâtiment industriel
Le béton armé atténue, et son ferraillage davantage que sa masse. Les structures métalliques réfléchissent. Le stock compte aussi : un hall logistique ne se comporte pas de la même façon plein et vide, et une liaison vérifiée un jour creux se dégrade quand les racks se remplissent.
La position du device pèse autant que la distance. Au ras du sol, plaqué contre un mur, ou enfermé dans une armoire métallique, il est handicapé avant d’avoir émis. C’est le premier point que nous regardons quand un device remonte mal, avant de toucher à l’infrastructure.
Le compteur en fond de site
Un compteur d’eau dans une cavette, à l’autre bout d’un site. Le device est sous la trappe et les niveaux de réception sont mauvais. Deux gestes possibles, nous en écartons un.
Le premier ne coûte presque rien : sortir l’antenne. Le device reste dans la cavette, son antenne est déportée à l’extérieur. Une antenne sous une trappe métallique ne travaille pas, la même à l’air libre change tout. Attention, le câble de déport n’est pas neutre, il coûte du signal et d’autant plus qu’il est long. On déporte court, avec du câble prévu pour.
Le second geste est celui auquel on pense spontanément : ajouter une gateway pour couvrir ce point. Nous ne l’avons pas fait, une gateway pour un seul point de mesure ne se justifie pas. À la place, nous avons augmenté la cadence d’envoi. Le signal reste médiocre, des messages se perdent, et le suivant arrive assez vite pour que ça n’ait pas d’importance. Ça fonctionne parce qu’un index de compteur est cumulatif, un relevé manqué décale la mesure sans creuser de trou, et parce que la détection de fuite se lit sur une tendance.
La règle de décision, avec sa limite dans la même phrase : quand la donnée est cumulative et que l’usage tolère un retard, on compense un signal médiocre par la cadence plutôt que par du matériel. Sur une alarme, une sécurité, un comptage de production, on ne fait pas ça. On couvre correctement, ou on ne met pas de device à cet endroit.
Les parois métalliques de l’agroalimentaire
En agroalimentaire, les ateliers sont montés en panneaux sandwich : deux parements en tôle d’acier, lisses et lavables, avec un isolant entre les deux. Excellent pour l’hygiène et pour le froid. Pour une liaison sans fil, c’est un mur, et l’effet cage de Faraday est bien réel.
À l’intérieur de l’atelier le signal est fort, parce que les parois le renvoient au lieu de le laisser partir. À l’extérieur il s’effondre. Un bâtiment de ce type ne se traverse pas, il se couvre.
D’où la règle que nous appliquons : dans ce genre de construction, on ne dimensionne pas en distance mais en volumes fermés. Chaque bâtiment à couvrir intégralement reçoit sa gateway, parfois deux selon la géométrie. Arroser trois halls depuis un mât central est une fausse économie, elle se paie en points de mesure absents.
Le duty cycle, ou pourquoi la cadence n’est pas un réglage libre
La bande 868 MHz limite le temps pendant lequel un émetteur occupe l’antenne. En pratique, après avoir émis, un device se tait environ cent fois plus longtemps que n’a duré son message.
Côté device, la cadence d’envoi n’est donc pas un curseur qu’on pousse. Plus la liaison est mauvaise, plus le device émet lentement pour se faire entendre, plus son message occupe l’antenne longtemps, et plus le silence imposé derrière est long. Un device mal placé consomme davantage la ressource commune qu’un device bien placé.
Côté gateway, c’est plus structurant encore. Elle obéit à la même règle et se trouve seule face à des dizaines de devices. Le sens montant est confortable, chacun ne gère que son propre budget. Le sens descendant est la ressource rare du réseau : une installation qui doit envoyer beaucoup de commandes butera sur ce plafond bien avant de rencontrer un problème de couverture.
Ce n’est pas une faiblesse de la technologie, c’est ce qui rend la bande utilisable. Sans cette règle, le premier installateur bavard du quartier saturerait le spectre pour tout le monde.
Classes A, B et C : ce que le choix impose
En classe A, le device parle quand il l’a décidé, puis ouvre deux courtes fenêtres d’écoute juste après son message. En dehors, il est sourd. C’est ce qui lui permet de tenir des années sur batterie, et c’est le mode de tout ce qui mesure. Conséquence directe : une commande envoyée vers un device de classe A attend le prochain message de ce device. S’il parle une fois par heure, la commande part dans l’heure.
La classe B ajoute des fenêtres d’écoute périodiques. Sur le papier, c’est le compromis idéal. Sur le terrain, nous ne la rencontrons quasiment pas et le catalogue de devices qui la supportent réellement reste mince.
En classe C, le device écoute en permanence, sauf pendant qu’il émet. Une commande part et arrive. C’est ce qu’il faut dès qu’on pilote une vanne, un contacteur, un délestage. Mais l’écoute permanente est incompatible avec une batterie, et pas de peu. La classe C est réservée aux devices alimentés sur secteur. Ce n’est pas une recommandation de confort, c’est une condition.
D’où une règle qui n’a pas souffert d’exception chez nous : ce qui mesure fonctionne en classe A sur batterie, ce qui commande fonctionne en classe C sur alimentation. Quand un client veut piloter un équipement là où il n’y a pas de courant, la vraie question n’est pas le choix du device, c’est de savoir si on peut en amener. Si la réponse est non, le LoRaWAN n’est pas la bonne réponse à ce besoin précis, et mieux vaut le dire tout de suite.
Commander, et pas seulement mesurer
Un réseau LoRaWAN ne fait pas que remonter des mesures. Il redescend aussi des ordres, et c’est ce qui sépare une installation de télérelevé d’une installation de pilotage.
Une commande part de la logique de traitement, jamais d’un opérateur qui parlerait directement au device. Elle est déclenchée par un seuil franchi, par une programmation horaire, ou par une action sur un dashboard. Le serveur LoRaWAN la met en file d’attente pour ce device précis, choisit la gateway qui l’émettra, et attend le moment où le device sera capable de l’entendre.
C’est là que la classe décide de tout. En classe C, le device écoute en permanence, la commande part et arrive. En classe A, elle reste en file jusqu’à ce que le device parle de lui-même et ouvre sa fenêtre d’écoute. Elle ne se perd pas, elle attend. Sur un device qui remonte une fois par heure, il faut accepter que l’ordre parte dans l’heure.
Ce qu’on commande réellement chez nos clients : mettre un coffret sous tension, fermer ou ouvrir une vanne, délester un départ électrique, relancer un équipement après un arrêt. Ces actions ont un point commun, elles tolèrent un délai et elles se vérifient par une mesure qui remonte derrière.
La limite, et elle n’est pas négociable : une commande LoRaWAN n’est pas un organe de sécurité. Pas d’arrêt d’urgence, pas de fonction de sécurité machine, rien de ce qui protège une personne ou un équipement d’un dommage immédiat. Ces fonctions passent par du filaire et par des organes prévus et certifiés pour ça. Le sans fil pilote du process, du confort et de l’énergie, il ne remplace pas une chaîne de sécurité. Quand un client demande l’inverse, la bonne réponse est non.
Bande libre ne veut pas dire bande sans règles
La 868 MHz est d’usage libre en Europe : pas de licence, pas de redevance, aucune démarche. Elle n’est pour autant ni exclusive ni sans contrainte. La puissance est plafonnée, le temps d’occupation limité, et personne ne garantit le silence : on partage avec des télécommandes de portail, des alarmes, des compteurs communicants.
Là où ça devient une décision de conception, c’est à l’export. Le plan de fréquences européen n’a rien d’universel. L’Amérique du Nord travaille sur d’autres fréquences et avec d’autres règles, sans duty cycle mais avec une durée maximale d’occupation d’un canal. L’Australie, l’Inde et une grande partie de l’Asie ont chacune leur plan. Au Maroc, les usages courte portée ne commencent qu’à 868 MHz : la portion basse que l’Europe ouvre dès 863 MHz n’y est pas disponible. Pour un constructeur qui vend des machines instrumentées à l’export, la conséquence est concrète. Un device livré en configuration européenne émet hors des clous dès son arrivée sur site, et la responsabilité remonte au fournisseur de la machine. Ça se traite en conception, pas à la mise en service quand le matériel est déjà dans le conteneur.
Ce que ça change quand on instrumente un site
Le LoRaWAN n’est pas un réseau informatique aux performances modestes. C’est autre chose, avec ses règles propres, et les installations qui déçoivent sont celles où on a voulu lui faire jouer un rôle qui n’est pas le sien.
Deux décisions se prennent avant d’acheter le premier device : ce qu’il faut couvrir, en volumes fermés plutôt qu’en mètres, et ce qui mesure par rapport à ce qui commande, puisque la seconde catégorie a besoin de courant. Le reste se mesure avant de poser quoi que ce soit, et c’est le sujet de l’étude de couverture. Notre approche du réseau est détaillée sur la page infrastructure réseau.