Il existe dans la culture de l’ing\u00e9nierie r\u00e9seau une liste de v\u00e9rit\u00e9s fondamentales formul\u00e9es dans le RFC 1925, publi\u00e9 en 1996 par R. Callon. Ces “fundamental truths” \u2014 observations humoristiques mais rigoureusement vraies \u2014 ont forg\u00e9 des g\u00e9n\u00e9rations d’ing\u00e9nieurs r\u00e9seau. ThingsLog y ajoute sa propre v\u00e9rit\u00e9, forg\u00e9e par des ann\u00e9es de d\u00e9veloppement IoT terrain : “\u00e7a doit d’abord marcher pour nous”. Ce principe, qui ressemble au c\u00e9l\u00e8bre “eat your own dogfood” de la culture Silicon Valley, est chez ThingsLog une pratique concr\u00e8te et document\u00e9e. L’\u00e9quipe utilise son propre r\u00e9seau LoRa communautaire et a test\u00e9 ses produits sur des itin\u00e9raires de d\u00e9placement quotidien avec le gateway UND1101 et l’enregistreur LPMDL-1103, cartographiant la couverture via TTN Mapper.<\/p>\n
Le RFC 1925, intitul\u00e9 “The Twelve Networking Truths”, est un document publi\u00e9 le 1er avril 1996 dans la s\u00e9rie des RFC (Request for Comments) de l’IETF. Bien que la date de publication puisse laisser croire \u00e0 un poisson d’avril, les v\u00e9rit\u00e9s qu’il \u00e9nonce sont prises au s\u00e9rieux par les ing\u00e9nieurs r\u00e9seau du monde entier. Parmi les plus c\u00e9l\u00e8bres : “It Has To Work” (\u00e7a doit marcher), “You can’t push on a string” (on ne peut pas pousser une corde), et “Good, Fast, Cheap \u2014 pick any two” (bon, rapide, pas cher \u2014 choisissez-en deux).<\/p>\n
Ces v\u00e9rit\u00e9s ont un m\u00e9rite rare dans l’ing\u00e9nierie : elles sont \u00e0 la fois amusantes et profond\u00e9ment vraies. “It Has To Work” r\u00e9sume l’essence de tout projet d’ing\u00e9nierie : peu importe l’\u00e9l\u00e9gance th\u00e9orique d’une solution, si elle ne fonctionne pas dans les conditions r\u00e9elles, elle ne vaut rien. ThingsLog a fait sienne cette philosophie en y ajoutant une pr\u00e9cision pratique essentielle : avant qu’une solution fonctionne pour les clients, elle doit d’abord avoir fonctionn\u00e9 pour l’\u00e9quipe qui l’a d\u00e9velopp\u00e9e, dans des conditions aussi proches que possible de celles du terrain.<\/p>\n
Cette culture de la rigueur se manifeste dans chaque d\u00e9cision de d\u00e9veloppement chez ThingsLog. Avant qu’une nouvelle fonctionnalit\u00e9 firmware soit d\u00e9ploy\u00e9e sur les enregistreurs des clients, elle est test\u00e9e en interne sur des appareils de production, dans des environnements vari\u00e9s (bureau, cave, ext\u00e9rieur), avec diff\u00e9rents op\u00e9rateurs r\u00e9seau, dans plusieurs pays. Ce processus rallonge le temps de d\u00e9veloppement, mais il \u00e9limine les surprises d\u00e9sagr\u00e9ables au moment du d\u00e9ploiement chez les clients.<\/p>\n
L’expression “eating your own dogfood” (manger sa propre nourriture pour chiens) d\u00e9signe la pratique qui consiste \u00e0 utiliser soi-m\u00eame les produits que l’on d\u00e9veloppe. Cette pratique est particuli\u00e8rement pr\u00e9cieuse dans le d\u00e9veloppement de produits IoT de terrain, o\u00f9 la diff\u00e9rence entre les conditions de laboratoire et les conditions r\u00e9elles peut \u00eatre abyssale. Dans un laboratoire, la couverture r\u00e9seau est bonne, la temp\u00e9rature est stable, les c\u00e2bles sont bien connect\u00e9s. Sur le terrain, la couverture peut \u00eatre marginale, la temp\u00e9rature peut varier de -10 \u00b0C \u00e0 +60 \u00b0C, et les c\u00e2bles subissent vibrations et condensation.<\/p>\n
Chez ThingsLog, l’\u00e9quipe de d\u00e9veloppement utilise ses propres enregistreurs pour surveiller les compteurs d’eau et d’\u00e9nergie des locaux de l’entreprise. Les data de ces d\u00e9ploiements internes nourrissent directement le d\u00e9veloppement produit : si la plateforme affiche une donn\u00e9e incoh\u00e9rente, si une alarme se d\u00e9clenche \u00e0 tort, si un enregistreur perd sa connexion de mani\u00e8re r\u00e9p\u00e9t\u00e9e, l’\u00e9quipe de d\u00e9veloppement le constate imm\u00e9diatement et peut corriger avant que cela n’impacte des clients. Ce feedback loop court entre l’usage et le d\u00e9veloppement est un avantage concurrentiel majeur.<\/p>\n
Le test de l’itin\u00e9raire de d\u00e9placement quotidien avec TTN Mapper illustre parfaitement cette philosophie. En \u00e9quipant un v\u00e9hicule d’un gateway LoRaWAN portable (UND1101) et d’un enregistreur LPMDL-1103, l’\u00e9quipe ThingsLog a cartographi\u00e9 la couverture LoRaWAN le long de ses trajets habituels \u2014 trajets domicile-travail, visites clients, d\u00e9placements professionnels. Les donn\u00e9es TTN Mapper ainsi collect\u00e9es ont r\u00e9v\u00e9l\u00e9 des zones de couverture insuffisante qui auraient pu compromettre des d\u00e9ploiements clients, permettant d’ajuster les recommandations de d\u00e9ploiement et les param\u00e8tres firmware (spreading factor adaptatif, retry logic).<\/p>\n
Les tests en laboratoire sont indispensables mais insuffisants pour valider un produit IoT destin\u00e9 au terrain. Le laboratoire offre un environnement contr\u00f4l\u00e9 id\u00e9al pour valider les fonctionnalit\u00e9s de base, mesurer la consommation \u00e9lectrique avec pr\u00e9cision, et v\u00e9rifier la conformit\u00e9 aux sp\u00e9cifications. Mais il ne reproduit pas fid\u00e8lement les conditions r\u00e9elles : variabilit\u00e9 de la qualit\u00e9 de couverture r\u00e9seau selon l’heure de la journ\u00e9e et la m\u00e9t\u00e9o, interf\u00e9rences \u00e9lectromagn\u00e9tiques d’\u00e9quipements industriels, condensation dans des regards b\u00e9ton, vibrations dans des armoires \u00e9lectriques.<\/p>\n
Les tests de terrain internes r\u00e9v\u00e8lent des classes enti\u00e8res de probl\u00e8mes invisibles au laboratoire. La gestion des reprises de connexion apr\u00e8s une perte de couverture prolong\u00e9e (le firmware g\u00e8re-t-il correctement le retour en PSM apr\u00e8s un \u00e9chec de transmission ?) ; le comportement face \u00e0 un r\u00e9seau satur\u00e9 en heure de pointe ; la d\u00e9gradation des performances de l’antenne lorsque l’appareil est recouvert de condensation ; la r\u00e9sistance aux surtensions transitoires sur les lignes de capteurs. Ces probl\u00e8mes, s’ils ne sont pas d\u00e9couverts et corrig\u00e9s en interne, deviendront des tickets de support clients difficiles \u00e0 reproduire et \u00e0 corriger \u00e0 distance.<\/p>\n
La cartographie TTN Mapper r\u00e9alis\u00e9e par ThingsLog a \u00e9galement produit des donn\u00e9es pr\u00e9cieuses sur les performances r\u00e9elles de LoRaWAN dans des conditions urbaines et p\u00e9ri-urbaines. Ces donn\u00e9es, partag\u00e9es avec la communaut\u00e9 TTN, contribuent \u00e0 l’am\u00e9lioration collective de la connaissance sur les performances de LoRaWAN \u2014 une d\u00e9marche open source coh\u00e9rente avec les valeurs de la communaut\u00e9 IoT.<\/p>\n
Les locaux de ThingsLog sont \u00e9quip\u00e9s de la m\u00eame mani\u00e8re que les sites de ses clients. Les compteurs d’eau, d’\u00e9lectricit\u00e9 et de gaz sont connect\u00e9s \u00e0 des enregistreurs ThingsLog de production. Les donn\u00e9es sont visualis\u00e9es sur la m\u00eame plateforme que celle utilis\u00e9e par les clients. Les alarmes sont configur\u00e9es sur les m\u00eames crit\u00e8res. Cette transparence \u2014 l’\u00e9quipe vit au quotidien avec les m\u00eames outils que ses clients \u2014 cr\u00e9e une empathie naturelle pour les probl\u00e8mes et les besoins des utilisateurs finaux.<\/p>\n
Des passerelles LoRaWAN UND-1101 sont d\u00e9ploy\u00e9es dans et autour des locaux de ThingsLog, contribuant \u00e0 la couverture TTN locale. Ces passerelles servent \u00e0 la fois au r\u00e9seau communautaire (tout appareil LoRaWAN \u00e0 port\u00e9e peut les utiliser gratuitement) et aux tests de nouveaux firmwares et fonctionnalit\u00e9s. Le fait d’op\u00e9rer sa propre infrastructure r\u00e9seau LoRaWAN donne \u00e0 ThingsLog une compr\u00e9hension op\u00e9rationnelle des d\u00e9fis des op\u00e9rateurs r\u00e9seau \u2014 une compr\u00e9hension qui enrichit ses conseils aux clients qui d\u00e9ploient leurs propres r\u00e9seaux.<\/p>\n
L’ing\u00e9nierie de la fiabilit\u00e9 (Reliability Engineering) pour les syst\u00e8mes IoT de terrain pose des d\u00e9fis sp\u00e9cifiques. Les appareils sont d\u00e9ploy\u00e9s dans des environnements difficiles, doivent fonctionner sans maintenance pendant des ann\u00e9es, et ne peuvent souvent pas \u00eatre red\u00e9marr\u00e9s facilement en cas de probl\u00e8me. La fiabilit\u00e9 n’est pas une fonctionnalit\u00e9 qu’on ajoute \u00e0 la fin du d\u00e9veloppement \u2014 c’est un attribut qu’on doit concevoir d\u00e8s le d\u00e9part dans chaque composant du syst\u00e8me.<\/p>\n
ThingsLog applique plusieurs principes de fiabilit\u00e9 dans ses produits. Le fail-safe by design : si la communication r\u00e9seau \u00e9choue, les donn\u00e9es sont stock\u00e9es localement et transmises d\u00e8s que la connexion revient. Si le capteur envoie une valeur hors plage, l’enregistreur la marque comme invalide plut\u00f4t que de l’accepter silencieusement. Le watchdog hardware : un circuit mat\u00e9riel ind\u00e9pendant du firmware red\u00e9marre automatiquement l’enregistreur si le firmware se bloque (situation rare mais possible). La mise \u00e0 jour firmware \u00e0 distance (OTA \u2014 Over The Air) permet de corriger des bugs et d’ajouter des fonctionnalit\u00e9s sans intervention physique sur les appareils d\u00e9ploy\u00e9s.<\/p>\n
La surveillance de la sant\u00e9 de l’appareil lui-m\u00eame (tension batterie, temp\u00e9rature interne, compteur de red\u00e9marrages, erreurs de transmission) est transmise avec chaque trame de donn\u00e9es, permettant une maintenance pr\u00e9dictive des enregistreurs d\u00e9ploy\u00e9s. Ces donn\u00e9es de sant\u00e9 sont visibles sur la plateforme ThingsLog et peuvent d\u00e9clencher des alertes si un appareil montre des signes de d\u00e9faillance imminente \u2014 batterie faible, red\u00e9marrages fr\u00e9quents, taux d’erreur de transmission \u00e9lev\u00e9.<\/p>\n
| Principe<\/th>\n | Application chez ThingsLog<\/th>\n<\/tr>\n<\/thead>\n |
|---|---|
| RFC 1925 adapt\u00e9<\/td>\n | “\u00c7a doit d’abord marcher pour nous” avant les clients<\/td>\n<\/tr>\n |
| Dogfood interne<\/td>\n | Compteurs des bureaux connect\u00e9s aux m\u00eames enregistreurs ThingsLog<\/td>\n<\/tr>\n |
| Tests terrain<\/td>\n | Cartographie TTN Mapper sur itin\u00e9raires quotidiens<\/td>\n<\/tr>\n |
| Fail-safe design<\/td>\n | Stockage local, watchdog HW, OTA firmware, donn\u00e9es sant\u00e9 appareil<\/td>\n<\/tr>\n |
| Contribution communaut\u00e9<\/td>\n | Passerelles UND-1101 ajout\u00e9es au r\u00e9seau TTN communautaire<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nQuestions fr\u00e9quentes<\/h2>\n |