Pourquoi pas une gateway commerciale ?
La question mérite d'être posée honnêtement. Des gateways LoRaWAN industrielles existent. Kerlink Wirnet, RAK Wireless, Cisco IR910 — des produits stables, certifiés, avec du support. Pourquoi repartir d'une carte de développement quand des gens ont déjà fait le travail ?
Trois raisons, dans l'ordre de leur poids réel.
Le prix d'abord. Une gateway commerciale d'entrée de gamme industrielle se négocie entre 800 et 2 000 euros pièce. Pour déployer SISKIA sur un massif forestier de taille moyenne — disons une vingtaine de nœuds sur 15 km² — il faut entre 4 et 6 gateways pour couvrir les zones en tenant compte du relief et du couvert. On est donc immédiatement à 4 000-12 000 euros de matériel réseau, avant même le premier capteur, avant le serveur, avant l'installation. Pour une association dont la mission est d'être reproductible avec des budgets limités, c'est un mur.
La dépendance cloud ensuite. La quasi-totalité des solutions commerciales sont pensées pour pointer vers un serveur de l'éditeur ou vers The Things Network. Ce n'est pas un défaut intrinsèque — c'est un modèle économique. Mais c'est incompatible avec la posture SISKIA : les données de surveillance collectées sur le terrain — mouvements, présences, flux — ne peuvent pas transiter par un cloud dont on ne maîtrise pas les conditions d'accès, les conditions de coupure, et les politiques de rétention. On a besoin d'une infrastructure auto-hébergée. ChirpStack tourne chez nous, sur nos serveurs. La gateway doit parler directement à ChirpStack sans intermédiaire.
La réparabilité enfin. Une gateway commerciale qui tombe en panne dans une forêt reculée, c'est une RMA chez le fabricant, des délais de six semaines, et potentiellement une discontinuité complète de la couverture réseau. Une gateway assemblée à partir de composants standards du commerce — ESP32-S3, SX1302, module 4G disponibles chez une dizaine de distributeurs — se remplace en 48 heures avec des composants commandés localement. C'est un argument opérationnel, pas théorique.
L'arbitrage en chiffres
BOM estimée pour une gateway complète : 150-250 € [FLAG — à valider sur devis]. Soit un rapport 4 à 10 avec les solutions Kerlink ou Cisco. Sur 5 gateways déployées, l'économie finance les capteurs de tout un site. Ce n'est pas de la frugalité — c'est du budget réalloué là où il crée de la valeur.
L'architecture brique par brique
Chaque composant a été choisi pour une raison précise. Ce n'est pas une liste de courses — c'est une série d'arbitrages.
Le MCU : pourquoi l'ESP32-S3 et pas le Raspberry Pi ?
La question revient souvent. Un Raspberry Pi est plus puissant, plus connu, plus facile à programmer pour quelqu'un qui vient du monde Linux. Mais pour une gateway déployée sur batterie solaire en plein air, le Pi a des défauts structurels : consommation élevée en veille, système de fichiers sur carte SD vulnérable aux coupures de courant, pas de mode sleep hardware, démarrage lent après une coupure. L'ESP32-S3 consomme quelques milliwatts en deep sleep, démarre en moins d'une seconde, n'a pas de système de fichiers critique. C'est taillé pour l'embarqué.
Le concentrateur LoRa : SX1302 plutôt que SX1301
Le SX1301 est le concentrateur historique du marché — fiable, testé, bien documenté. Mais son successeur SX1302 réduit la consommation d'environ 70 % à performances comparables, et surtout il est disponible en module intégré (HAT compatible Raspberry Pi, mais aussi breakout board pour MCU) avec un HAL open source maintenu par Semtech. Sur un bilan énergétique solaire en hiver, réduire la consommation du concentrateur de plusieurs centaines de milliwatts, c'est directement une journée d'autonomie en moins à stocker dans la batterie.
Le backhaul 4G : dernier recours, pas première option
Le module 4G est présent sur la carte, mais sa logique de déclenchement est stricte : il ne s'active que si la gateway ne voit aucun pair mesh disponible pendant un délai configurable. En forêt dense, la 4G est souvent médiocre ou inexistante — mais sur les zones en bordure, elle offre une sortie de secours utile. La consommation d'un module LTE en transmission active dépasse 500 mA à 3,3 V. Sur batterie, c'est coûteux. L'enjeu est donc de calibrer précisément le seuil de bascule pour ne jamais activer la 4G quand le mesh suffit, et de l'activer rapidement quand il ne suffit pas. Ce calibrage a été l'un des points de friction opérationnels les plus chronophages du projet.
Le mesh : la vraie astuce
Une gateway seule, même parfaitement placée, est un single point of failure. Si elle tombe — coupure d'alimentation, défaillance matérielle, interférence — tout le réseau de capteurs dans sa zone de couverture devient muet. C'est inacceptable pour un dispositif de surveillance où la continuité des données a une valeur opérationnelle.
La réponse classique dans les réseaux industriels est la redondance : on double les gateways critiques. C'est coûteux et ça n'élimine pas le problème, ça le réduit. La réponse que nous avons choisie est différente : le mesh crée une redondance organique. Chaque gateway est un relais potentiel pour ses voisines. Si la gateway A tombe, les capteurs dans sa zone tentent automatiquement d'atteindre les gateways B ou C via le réseau LoRaWAN standard — et les gateways B et C remontent les données vers ChirpStack via leur propre route mesh ou 4G. Aucune configuration centralisée à mettre à jour. Aucune adresse IP statique à gérer. Le réseau se reconfigure seul.
Ce n'est pas de la magie — c'est de la physique et du protocole. LoRaWAN est conçu pour que les capteurs puissent être reçus par plusieurs gateways simultanément. ChirpStack déduplique les trames. La partie mesh entre gateways, elle, gère l'acheminement de ces trames vers le serveur réseau. Les deux niveaux fonctionnent indépendamment.
Portée et topologie
En ligne de vue (LOS) sur terrain dégagé, LoRaWAN 868 MHz atteint facilement 10-15 km. En forêt dense avec couvert végétal épais, on retombe à 2-5 km. Portée estimée en forêt : 5-10 km LOS [FLAG — à confirmer sur terrain selon végétation et relief]. Le mesh étend la couverture par sauts successifs entre gateways — une zone non couverte directement par le serveur peut être atteinte en deux ou trois sauts, sans aucune liaison filaire.
Le maillage a aussi un avantage moins évident : il découple la couverture LoRa de la disponibilité d'une liaison Internet sur chaque nœud. On n'a pas besoin qu'une carte SIM soit disponible partout — juste que le réseau mesh rejoigne, quelque part, un nœud qui a du backhaul. Dans certaines configurations de terrain, une seule liaison 4G (ou Wi-Fi si disponible) suffit pour remonter les données de tout un massif.
Ce qui a frotté
Tout projet matériel a ses frictions. Voici celles qui ont demandé le plus de temps — non pour se plaindre, mais parce que les documenter est utile à quiconque voudrait reproduire ou adapter le dispositif.
L'autonomie hivernale
Le dimensionnement solaire en été est trompeur. Quatre heures d'ensoleillement direct par jour en juillet dans le Centre-Loire, ça charge vite 20 Ah de LiFePO4. En décembre, la même latitude tombe à moins d'une heure d'ensoleillement utile, avec des panneaux souvent couverts de condensation ou de givre. Nos premières estimations étaient trop optimistes. Il a fallu augmenter la capacité du panneau au-delà de ce que la consommation moyenne justifiait — non pas pour la puissance crête, mais pour les journées grises prolongées. La règle que nous avons stabilisée : dimensionner le stockage pour 5 jours d'autonomie sans soleil en tenant compte de la baisse de capacité de la LiFePO4 à basse température. C'est plus de batterie que ce qu'on aurait voulu, mais c'est ce que les données de terrain ont dicté.
Le choix du concentrateur LoRa
Le marché des concentrateurs LoRa pour DIY s'est structuré autour du SX1301 (RAK2245, iC880A) et du SX1302 (RAK2287, RAK5146). Les deux fonctionnent. Mais la documentation de référence pour faire tourner le HAL Semtech avec ChirpStack est encore majoritairement écrite pour le SX1301. Migrer vers le SX1302 a demandé de creuser dans les issues GitHub du HAL Semtech et les forums de la communauté ChirpStack pour aligner les versions. Pas insurmontable — mais non trivial pour quelqu'un qui arrive sur le sujet sans expérience LoRaWAN. C'est documenté dans notre dépôt.
Le calibrage de la bascule 4G
J'ai passé plus de temps que prévu sur ce point. Le comportement idéal est clair sur le papier : si aucun pair mesh n'est accessible depuis X secondes, activer la 4G ; si un pair redevient accessible, désactiver la 4G et le module pour préserver la batterie. En pratique, les coupures mesh en forêt sont souvent brèves et liées aux interférences RF — feuilles en mouvement dans le vent, pluie dense, passage d'un drone de surveillance dans la zone. Un seuil trop bas active la 4G pour rien et pompe la batterie. Un seuil trop haut laisse des minutes de données perdues si la coupure est réelle. La valeur stabilisée en conditions terrain — que nous ne publions pas en valeur fixe parce qu'elle dépend du site — est dans une fourchette de 45 à 120 secondes selon la densité du couvert. Le firmware expose ce paramètre en configuration.
Note de terrain
Lors d'une démonstration SIGRENEA sur site industriel, j'avais branché une gateway prototype directement sur le Wi-Fi du bâtiment pour la démo — le réseau mesh n'était pas encore opérationnel. La gateway a fonctionné parfaitement... jusqu'à ce que le responsable informatique du site coupe le SSID invité à mi-parcours, par réflexe sécurité. Trois minutes de données perdues, une salle qui attendait, un concentrateur qui regardait le plafond. Le lendemain, nous avons priorisé le fallback 4G. Parfois les décisions d'architecture se prennent pour de très bonnes raisons, sous la pression du réel.
Un pivot inattendu : Netscanner CE 2.4
Nous avons conçu cette gateway pour SISKIA. Ce que nous n'avions pas anticipé, c'est l'intérêt industriel qu'elle a suscité en dehors du contexte forestier.
Lors de deux présentations de terrain, des interlocuteurs de secteurs différents — logistique portuaire, surveillance de périmètre — ont posé la même question : est-ce que ce dispositif peut être déployé dans un contexte certifié, avec un support commercial et une traçabilité des composants ? La réponse courte était non. Notre gateway est conçue pour être reproductible et réparable, pas pour satisfaire un cahier des charges de marché industriel.
Cette demande a ouvert une trajectoire différente : Netscanner CE 2.4, un dérivé commercial qui reprend la même architecture de base en ajoutant les couches nécessaires — conformité CE, BOM tracée, documentation SAV, référencement fournisseur. La gateway SISKIA devient le prototype validé sur lequel Netscanner s'appuie. Les deux lignes restent distinctes : SISKIA reste open source, reproductible, documentation publique. Netscanner CE 2.4 est le produit commercial pour les structures qui ont besoin d'un cadre différent.
C'est un exemple de ce que la posture COTS rend possible : construire sur une base ouverte et réplicable, puis dériver vers un produit commercial quand la demande le justifie — sans que les deux ne se cannibalisent.
Dans la même série
- SISKIA : du proto au dispositif reproductible à l'internationalL'article pilier — comment ComiPi a structuré la stratégie produit et la documentation de l'association.
- Le capteur de détection SISKIAArchitecture électronique, firmware, BOM ouverte — le nœud terminal qui alimente la gateway.
- Netscanner CE 2.4 : quand un proto open source devient produit industrielLe pivot commercial issu directement de cette gateway — contexte, arbitrages, différences avec la version SISKIA.
- siskia.orgLe site de l'association — BOM publique, schémas, procédures d'installation.
- Le manifeste ComiPiLa posture qui sous-tend tous ces choix — pourquoi COTS, pourquoi open source, pourquoi reproductible à l'international.
Un terrain similaire ?
Parlons du déploiement.
Surveillance forestière, périmètre industriel, zone rurale sans infrastructure — si votre contexte ressemble à celui de SISKIA, on peut regarder ensemble ce qui est transposable.
Le reste de la série
Cluster SISKIA
Capteur de détection, drone de surveillance, infrastructure ChirpStack — chaque article détaille une brique du dispositif complet.