Le premier principe de l’ingénieur IoT : ça doit d’abord marcher pour nous

Il existe dans la culture de l’ingénierie réseau une liste de vérités fondamentales formulées dans le RFC 1925, publié en 1996 par R. Callon. Ces “fundamental truths” — observations humoristiques mais rigoureusement vraies — ont forgé des générations d’ingénieurs réseau. ThingsLog y ajoute sa propre vérité, forgée par des années de développement IoT terrain : “ça doit d’abord marcher pour nous”. Ce principe, qui ressemble au célèbre “eat your own dogfood” de la culture Silicon Valley, est chez ThingsLog une pratique concrète et documentée. L’équipe utilise son propre réseau LoRa communautaire et a testé ses produits sur des itinéraires de déplacement quotidien avec le gateway UND1101 et l’enregistreur LPMDL-1103, cartographiant la couverture via TTN Mapper.

Table des matières

• RFC 1925 et la culture de la rigueur ingénierie
• La philosophie “eat your own dogfood” appliquée à l’IoT
• Pourquoi les tests internes révèlent ce que les tests labo ne voient pas
• Déploiements IoT internes de ThingsLog
• Principes d’ingénierie de la fiabilité pour l’IoT
• Questions fréquentes

RFC 1925 et la culture de la rigueur en ingénierie réseau

Le RFC 1925, intitulé “The Twelve Networking Truths”, est un document publié le 1er avril 1996 dans la série des RFC (Request for Comments) de l’IETF. Bien que la date de publication puisse laisser croire à un poisson d’avril, les vérités qu’il énonce sont prises au sérieux par les ingénieurs réseau du monde entier. Parmi les plus célèbres : “It Has To Work” (ça doit marcher), “You can’t push on a string” (on ne peut pas pousser une corde), et “Good, Fast, Cheap — pick any two” (bon, rapide, pas cher — choisissez-en deux).

Ces vérités ont un mérite rare dans l’ingénierie : elles sont à la fois amusantes et profondément vraies. “It Has To Work” résume l’essence de tout projet d’ingénierie : peu importe l’élégance théorique d’une solution, si elle ne fonctionne pas dans les conditions réelles, elle ne vaut rien. ThingsLog a fait sienne cette philosophie en y ajoutant une précision pratique essentielle : avant qu’une solution fonctionne pour les clients, elle doit d’abord avoir fonctionné pour l’équipe qui l’a développée, dans des conditions aussi proches que possible de celles du terrain.

Cette culture de la rigueur se manifeste dans chaque décision de développement chez ThingsLog. Avant qu’une nouvelle fonctionnalité firmware soit déployée sur les enregistreurs des clients, elle est testée en interne sur des appareils de production, dans des environnements variés (bureau, cave, extérieur), avec différents opérateurs réseau, dans plusieurs pays. Ce processus rallonge le temps de développement, mais il élimine les surprises désagréables au moment du déploiement chez les clients.

La philosophie “eat your own dogfood” dans le développement IoT

L’expression “eating your own dogfood” (manger sa propre nourriture pour chiens) désigne la pratique qui consiste à utiliser soi-même les produits que l’on développe. Cette pratique est particulièrement précieuse dans le développement de produits IoT de terrain, où la différence entre les conditions de laboratoire et les conditions réelles peut être abyssale. Dans un laboratoire, la couverture réseau est bonne, la température est stable, les câbles sont bien connectés. Sur le terrain, la couverture peut être marginale, la température peut varier de -10 °C à +60 °C, et les câbles subissent vibrations et condensation.

Chez ThingsLog, l’équipe de développement utilise ses propres enregistreurs pour surveiller les compteurs d’eau et d’énergie des locaux de l’entreprise. Les data de ces déploiements internes nourrissent directement le développement produit : si la plateforme affiche une donnée incohérente, si une alarme se déclenche à tort, si un enregistreur perd sa connexion de manière répétée, l’équipe de développement le constate immédiatement et peut corriger avant que cela n’impacte des clients. Ce feedback loop court entre l’usage et le développement est un avantage concurrentiel majeur.

Le test de l’itinéraire de déplacement quotidien avec TTN Mapper illustre parfaitement cette philosophie. En équipant un véhicule d’un gateway LoRaWAN portable (UND1101) et d’un enregistreur LPMDL-1103, l’équipe ThingsLog a cartographié la couverture LoRaWAN le long de ses trajets habituels — trajets domicile-travail, visites clients, déplacements professionnels. Les données TTN Mapper ainsi collectées ont révélé des zones de couverture insuffisante qui auraient pu compromettre des déploiements clients, permettant d’ajuster les recommandations de déploiement et les paramètres firmware (spreading factor adaptatif, retry logic).

Pourquoi les tests internes révèlent ce que les tests en laboratoire ne voient pas

Les tests en laboratoire sont indispensables mais insuffisants pour valider un produit IoT destiné au terrain. Le laboratoire offre un environnement contrôlé idéal pour valider les fonctionnalités de base, mesurer la consommation électrique avec précision, et vérifier la conformité aux spécifications. Mais il ne reproduit pas fidèlement les conditions réelles : variabilité de la qualité de couverture réseau selon l’heure de la journée et la météo, interférences électromagnétiques d’équipements industriels, condensation dans des regards béton, vibrations dans des armoires électriques.

Les tests de terrain internes révèlent des classes entières de problèmes invisibles au laboratoire. La gestion des reprises de connexion après une perte de couverture prolongée (le firmware gère-t-il correctement le retour en PSM après un échec de transmission ?) ; le comportement face à un réseau saturé en heure de pointe ; la dégradation des performances de l’antenne lorsque l’appareil est recouvert de condensation ; la résistance aux surtensions transitoires sur les lignes de capteurs. Ces problèmes, s’ils ne sont pas découverts et corrigés en interne, deviendront des tickets de support clients difficiles à reproduire et à corriger à distance.

La cartographie TTN Mapper réalisée par ThingsLog a également produit des données précieuses sur les performances réelles de LoRaWAN dans des conditions urbaines et péri-urbaines. Ces données, partagées avec la communauté TTN, contribuent à l’amélioration collective de la connaissance sur les performances de LoRaWAN — une démarche open source cohérente avec les valeurs de la communauté IoT.

Déploiements IoT internes de ThingsLog : les bureaux comme terrain d’essai

Les locaux de ThingsLog sont équipés de la même manière que les sites de ses clients. Les compteurs d’eau, d’électricité et de gaz sont connectés à des enregistreurs ThingsLog de production. Les données sont visualisées sur la même plateforme que celle utilisée par les clients. Les alarmes sont configurées sur les mêmes critères. Cette transparence — l’équipe vit au quotidien avec les mêmes outils que ses clients — crée une empathie naturelle pour les problèmes et les besoins des utilisateurs finaux.

Des passerelles LoRaWAN UND-1101 sont déployées dans et autour des locaux de ThingsLog, contribuant à la couverture TTN locale. Ces passerelles servent à la fois au réseau communautaire (tout appareil LoRaWAN à portée peut les utiliser gratuitement) et aux tests de nouveaux firmwares et fonctionnalités. Le fait d’opérer sa propre infrastructure réseau LoRaWAN donne à ThingsLog une compréhension opérationnelle des défis des opérateurs réseau — une compréhension qui enrichit ses conseils aux clients qui déploient leurs propres réseaux.

Principes d’ingénierie de la fiabilité pour l’IoT

L’ingénierie de la fiabilité (Reliability Engineering) pour les systèmes IoT de terrain pose des défis spécifiques. Les appareils sont déployés dans des environnements difficiles, doivent fonctionner sans maintenance pendant des années, et ne peuvent souvent pas être redémarrés facilement en cas de problème. La fiabilité n’est pas une fonctionnalité qu’on ajoute à la fin du développement — c’est un attribut qu’on doit concevoir dès le départ dans chaque composant du système.

ThingsLog applique plusieurs principes de fiabilité dans ses produits. Le fail-safe by design : si la communication réseau échoue, les données sont stockées localement et transmises dès que la connexion revient. Si le capteur envoie une valeur hors plage, l’enregistreur la marque comme invalide plutôt que de l’accepter silencieusement. Le watchdog hardware : un circuit matériel indépendant du firmware redémarre automatiquement l’enregistreur si le firmware se bloque (situation rare mais possible). La mise à jour firmware à distance (OTA — Over The Air) permet de corriger des bugs et d’ajouter des fonctionnalités sans intervention physique sur les appareils déployés.

La surveillance de la santé de l’appareil lui-même (tension batterie, température interne, compteur de redémarrages, erreurs de transmission) est transmise avec chaque trame de données, permettant une maintenance prédictive des enregistreurs déployés. Ces données de santé sont visibles sur la plateforme ThingsLog et peuvent déclencher des alertes si un appareil montre des signes de défaillance imminente — batterie faible, redémarrages fréquents, taux d’erreur de transmission élevé.

Questions fréquentes

Comment ThingsLog utilise-t-il TTN Mapper pour améliorer ses produits ?

TTN Mapper est un outil collaboratif de cartographie de la couverture LoRaWAN. ThingsLog l’utilise de deux façons. En tant que collecteur de données : en équipant des véhicules ou des techniciens terrain d’un appareil LoRaWAN ThingsLog, les données de couverture (signal reçu par les gateways TTN environnantes) sont automatiquement envoyées à TTN Mapper et cartographiées. Ces données révèlent les zones de couverture marginale, les zones mortes, et l’impact de l’atténuation par les bâtiments. En tant qu’utilisateur des données : les cartes TTN Mapper permettent d’orienter les recommandations de déploiement chez les clients et d’ajuster les paramètres firmware (spreading factor plus élevé dans les zones de couverture marginale).

Quels problèmes les tests terrain internes ont-ils permis de corriger dans les produits ThingsLog ?

Les tests terrain internes ont permis d’identifier et corriger plusieurs classes de problèmes. La gestion des timeouts réseau : dans les zones de couverture NB-IoT faible, les tentatives de connexion pouvaient durer plusieurs minutes, empêchant l’entrée en PSM et épuisant prématurément la batterie. Le firmware a été optimisé avec un timeout agressif et une logic de retry intelligente. La robustesse face aux transitoires : des surtensions sur les lignes de capteurs dans des environnements industriels pouvaient corrompre les valeurs mesurées. Des filtres logiciels de validation ont été ajoutés. La gestion du passage heure d’été/heure d’hiver : des erreurs d’horodatage ont été détectées et corrigées avant d’atteindre les clients.

La philosophie “tester en interne d’abord” ralentit-elle le développement de ThingsLog ?

Cette philosophie rallonge effectivement le temps entre le développement d’une fonctionnalité et sa disponibilité chez les clients — typiquement de 2 à 4 semaines supplémentaires pour la validation interne. Mais elle réduit considérablement les coûts cachés : le temps de support pour diagnostiquer des bugs terrain, les mises à jour firmware urgentes, la dégradation de la satisfaction client. Dans l’IoT, où les appareils sont déployés dans des endroits difficiles d’accès et où les bugs firmware peuvent persister des mois avant d’être détectés, la rigueur des tests préventifs est économiquement plus efficiente que la réactivité aux bugs post-déploiement. C’est un investissement en qualité qui protège la réputation et réduit le coût total du développement.