On nous demande encore du LoRaWAN à toutes les sauces. Surtout les grosses collectivités, qui ont investi dans leurs réseaux privés et veulent continuer à les alimenter. C'est compréhensible.
Mais honnêtement ? Chez Codium, on considère le LoRaWAN comme une technologie dépassée pour la plupart des nouveaux projets. Voilà pourquoi.
Le LoRa, on connaît — on en a fait des kilomètres
Les fondateurs de Codium ont fait leurs armes en concevant beaucoup d'objets LoRa. Beaucoup. Compteurs d'eau, capteurs de stationnement, détecteurs de présence, systèmes de surveillance de cuve, trackers d'actifs fixes… On a appris la modulation CSS sur le tas, débogué des problèmes de DR (Data Rate), optimisé des trames jusqu'au dernier octet.
Et on comprend parfaitement pourquoi le LoRa a été une révolution. Dans les années 2010, c'était objectivement une technologie brillante. Elle cochait toutes les cases pour des objets connectés à faible coût et grande portée :
Le premier problème : la saturation du spectre libre
Le LoRa fonctionne dans la bande 868 MHz en Europe. Cette bande est libre — c'est son avantage historique. C'est aussi son talon d'Achille : elle est partagée avec tous les autres objets qui émettent à côté.
Dans les années 2010, quand il y avait quelques milliers d'objets en ville, ça marchait très bien. Aujourd'hui, dans une métropole qui a déployé son réseau de compteurs, de capteurs de stationnement, de surveillance de réseau d'eau et d'éclairage public — toutes sur LoRa — le spectre est saturé.
Le LoRa n'a pas été conçu pour supporter une montée en charge massive sur une même zone. Quand des milliers d'objets émettent dans le même espace spectral, les collisions de trames explosent.
Sur du relevé de compteur simple — où l'on envoie une mesure par jour et où perdre un message ici ou là n'a pas de conséquence — ça passe encore. Mais dès qu'on sort de ce cas de figure, ça devient problématique.
Des fonctions de sécurité active : verrouillage de portail, détection d'intrusion, surveillance de site, alarme technique. Avec comme contrainte de connectivité : le réseau LoRaWAN privé tout neuf de la collectivité. Et là, c'est non. Le principe est simple : quand on perd 30 à 40 % des trames, on ne peut plus faire de la sécurité ou de la surveillance. Ça n'a plus de sens.
Le coup de grâce : le LoRaWAN est incompatible avec le CRA
Le Cyber Resilience Act impose — entre autres — que tout produit connecté puisse recevoir des mises à jour de sécurité (OTA). C'est non-négociable. C'est l'un des piliers du CRA.
Et le LoRaWAN, architecturalement, ne peut pas le faire. Pas vraiment.
Les puristes vont dire que le LoRaWAN supporte les downlinks (classe B, classe C, fenêtres de réception). Techniquement, c'est vrai. En pratique, sur une flotte réelle en zone urbaine :
limité à 1 %
quelques kb/s
30–40 %
centaines de chunks
Ce n'est pas une opinion : l'incapacité à faire des mises à jour de firmware fiables à grande échelle condamne architecturalement le LoRaWAN vis-à-vis des nouvelles obligations réglementaires. Ce n'est pas une question de volonté ou d'effort — c'est une contrainte physique et protocolaire.
LTE-M et NB-IoT : la radio gérée, pas la radio espérée
Oui, LTE-M et NB-IoT fonctionnent sur des fréquences réglementées. Oui, on dépend des opérateurs. C'est le point qui dérange — et on le comprend.
Mais il faut comprendre ce que ça apporte en échange. La différence fondamentale avec le LoRa, c'est que la radio cellulaire est orchestrée à la microseconde près.
La vidéo YouTube streamée depuis un téléphone sur le même réseau, la donnée du compteur d'eau qui remonte une fois par jour, et le message d'alarme urgent qui arrive en urgence — tout ça s'intercale avec des règles de priorité, de débit, de gestion de l'énergie spécifiques à chaque type de device. Chaque trame arrive. On sait qu'elle arrive. C'est fondamentalement différent d'un spectre libre où les objets émettent un peu quand ils veulent en espérant qu'il n'y aura pas de collision.
La vérité sur le "réseau privé" LoRa
L'idée d'opérer son propre réseau d'objets de manière indépendante, sans dépendre d'un opérateur, reste séduisante sur le papier. On comprend que ça ait motivé des investissements importants dans les collectivités.
Mais sur le terrain, on observe quelque chose d'intéressant : les collectivités qui ont déployé leurs réseaux LoRa privés sous-traitent maintenant la maintenance à des sociétés privées tierces. La gateway en toit de mairie, les problèmes de firmware réseau, les mises à jour du serveur LoRaWAN, la supervision de la couverture…
L'indépendance tant vantée, elle est finalement assez relative. Et je ne suis pas persuadé que le coût à l'octet soit vraiment inférieur à ce qu'un MVNO IoT peut offrir aujourd'hui.
| Critère | LoRaWAN | LTE-M / NB-IoT |
|---|---|---|
| Fiabilité de réception (zone urbaine) | 60–70 % (30–40% pertes) | > 99 % |
| Communication descendante (downlink) | Théorique / peu fiable | Fiable, bidirectionnel |
| OTA firmware à grande échelle | Pratiquement impossible | Standard, chiffré |
| Compatibilité CRA (2027) | Incompatible | Conforme |
| Cas d'usage sécurité active | Impossible | Natif |
| Saturation en zone dense | Problème réel | Géré par l'opérateur |
| Consommation / autonomie batterie | Excellente | Equivalente (PSM) |
| Coût module | 3–6 € | 5–10 € |
| Coût réseau annuel par objet | ~0 € (réseau privé) | 1–5 € (MVNO IoT) |
| Infrastructure à déployer | Gateway + serveur + maintenance | Zéro — réseau opérateur |
| Couverture mondiale | Variable (gateway) | 176 pays |
| Mobilité objet | Non supportée | Native (LTE-M) |
Notre conclusion — nette
Pour un nouveau projet d'objet connecté, on déconseille le LoRaWAN. La saturation du spectre, l'impossibilité pratique de faire des mises à jour OTA fiables, et l'incompatibilité avec le CRA en font une impasse réglementaire et technique à court terme. LTE-M ou NB-IoT sont désormais nos recommandations par défaut.
Est-ce qu'il y a encore des cas où le LoRa est pertinent ? Sur du relevé de compteur simple, stationnaire, dans une zone peu dense, sans exigence de sécurité active, pour un client qui maîtrise son réseau et n'a aucune contrainte CRA — oui, ça peut encore tenir. Mais c'est une niche qui se réduit.
Pour le reste — et notamment pour tout ce que les collectivités veulent faire maintenant avec leur réseau d'objets : surveillance, sécurité, alertes, pilotage — LoRa ne peut pas répondre. Ce n'est pas une question d'effort ou d'investissement. C'est une limite architecturale.
DECT NR+ avec Nordic Semiconductor : le meilleur des deux mondes ?
Dans certains contextes, le besoin d'opérer de manière économique son propre réseau d'objets reste important et légitime. C'est pour cette raison que chez Codium, on travaille actuellement avec Nordic Semiconductor sur une technologie qui nous semble très prometteuse : le DECT NR+.
L'idée est simple et élégante : faire fonctionner sur des bandes libres (1,9 GHz en Europe) les technologies radio issues du monde 5G. On obtient potentiellement le meilleur des deux mondes — l'indépendance opérateur et la maîtrise du réseau propre au LoRa, avec la robustesse protocolaire, la qualité de service et la gestion intelligente du trafic qui caractérisent les réseaux cellulaires modernes.
On est convaincus que c'est une technologie d'avenir. On y contribue activement avec d'autres partenaires dans le but de la rendre disponible rapidement pour nos clients.