J'ai 12 capteurs terrain et un tableau Excel — par où commencer ?

Un bureau d'études environnemental déploie 12 pluviomètres connectés sur un bassin versant en Guyane. Les données arrivent dans un tableur partagé sur Google Drive, renseigné manuellement deux fois par semaine. La question arrive six mois plus tard : « on voudrait voir ça sur une carte, en temps réel ». Et personne dans l'équipe ne sait par où commencer. Ce scénario — ou une variante proche — est la situation de départ de la majorité des projets IoT terrain que j'observe. La question n'est pas de trouver LE bon outil : c'est de prendre les bonnes décisions dans le bon ordre. Quatre décisions structurent tout pipeline IoT géolocalisé, de l'ingestion à la carte. Les rater coûte cher à corriger. Les prendre dans l'ordre évite les refontes.

Avant tout : comprendre ce qu'est un pipeline IoT

Un pipeline IoT géolocalisé, c'est une chaîne de six maillons. Chaque maillon conditionne le suivant. On ne choisit pas son outil de visualisation sans savoir comment la donnée est stockée. On ne dimensionne pas son stockage sans connaître la fréquence d'envoi des capteurs.

La plupart des projets qui échouent ou deviennent incontrôlables ont sauté l'étape 4 ou mal dimensionné l'étape 5. Le reste découle de ces deux erreurs. L'enjeu de ce guide est simple : prendre les quatre décisions structurantes dans le bon ordre, avec les bons critères, avant d'acheter le premier capteur ou de déployer le premier conteneur.

Décision 1 — Quel protocole pour vos capteurs ?

La première décision est aussi la plus structurante : elle détermine l'infrastructure d'ingestion entière. Mal choisir ici revient à changer les fondations d'une maison déjà construite. Trois protocoles couvrent 95 % des cas terrain en 2026.

MQTT est le protocole de référence pour les capteurs connectés via Wi-Fi, 4G/LTE ou Ethernet. Il est asynchrone, léger (en-têtes de quelques octets), conçu pour les connexions instables et les appareils à faible consommation. Le mécanisme QoS (0, 1, 2) permet de choisir le compromis entre performance et garantie de livraison selon la criticité de la mesure. C'est le choix par défaut pour tout projet IoT terrain avec couverture réseau correcte.

LoRaWAN prend le relais quand la couverture cellulaire est absente ou trop coûteuse — zones rurales, forêts, zones industrielles isolées. La contrepartie : débit très faible (quelques dizaines d'octets par message), latence importante, infrastructure de gateways à déployer ou louer. Adapté pour les capteurs qui envoient peu et rarement — niveau de rivière toutes les 15 minutes, température de sol toutes les heures.

HTTP Push fonctionne pour les capteurs avec connectivité stable qui envoient peu de données. Simple à implémenter, mais fragile sur connexion instable, coûteux en overhead, pas adapté à la montée en charge. À réserver aux cas simples ou aux plateformes qui n'exposent que du HTTP.

Décision 2 — Où et comment ingérer la donnée ?

Un broker MQTT reçoit les messages des capteurs et les distribue aux consommateurs. C'est le cœur nerveux du pipeline. Deux options dominent en open source : Mosquitto et EMQX.

Mosquitto est léger, éprouvé, simple à déployer en quelques minutes sur un VPS. Il couvre sans broncher des dizaines de capteurs avec un faible volume. C'est le point d'entrée naturel pour un premier projet IoT — zéro configuration superflue, documentation solide, consommation mémoire minimale.

EMQX entre en jeu quand le volume de connexions simultanées dépasse quelques centaines, ou quand on a besoin de règles de routage complexes, de clustering, ou d'une interface de supervision intégrée. Sa courbe de configuration est plus élevée, sa robustesse en production bien supérieure.

Entre le broker et le stockage, il faut un étage de traitement. C'est là que Node-RED intervient — un orchestrateur visuel qui permet de normaliser les messages MQTT, d'enrichir les données (géocodage, conversion d'unités, validation), de router vers plusieurs destinations et de gérer les erreurs sans écrire une ligne de code pour les cas courants. Il couvre 80 % des besoins de traitement de flux IoT en PME et bureaux d'études.

Ce que le traitement doit faire avant le stockage

Avant d'écrire en base, chaque mesure devrait avoir passé trois contrôles. D'abord, la validation des bornes : un capteur de température qui envoie 1 500°C ou une coordonnée GPS à 0,0 a manifestement un problème — ces valeurs aberrantes doivent être filtrées ou mises en quarantaine avant d'atteindre la base. Ensuite, l'enrichissement géospatial : si la coordonnée GPS est brute, elle doit être transformée en EPSG:4326 et optionnellement associée à une zone administrative ou à un périmètre métier (bassin versant, commune, zone industrielle). Enfin, l'horodatage UTC explicite : le timestamp de la mesure doit être en UTC avec la timezone stockée explicitement. Les décalages horaires silencieux sont la cause la plus fréquente d'incohérences dans les dashboards de monitoring.

Décision 3 — Comment stocker les séries temporelles géolocalisées ?

C'est la décision qui fait le plus de dégâts quand elle est mal prise, parce que migrer un schéma de stockage en production avec des millions de mesures est une opération coûteuse et risquée. Les données capteurs ont des propriétés qui les distinguent des données métier classiques : elles sont append-only (on n'édite pas une mesure passée), leur volume croît de façon prévisible et linéaire, et 90 % des requêtes portent sur des fenêtres temporelles récentes. Ces propriétés appellent un moteur spécialisé.

La combinaison TimescaleDB + PostGIS est rare dans sa capacité à faire cohabiter time series performant et requêtes spatiales dans la même base transactionnelle ACID. SELECT * FROM mesures WHERE ST_DWithin(position, zone_interet, 500) AND time > NOW() - INTERVAL '24 hours' — ce type de requête est natif, indexé et rapide. Sans cette stack, il faudrait deux bases distinctes et une logique d'agrégation applicative.

Les trois erreurs de schéma à éviter absolument

• 1 Stocker les coordonnées GPS en deux colonnes lat et lng de type FLOAT au lieu d'une colonne geometry(POINT, 4326). On perd l'indexation spatiale et toutes les fonctions PostGIS — impossible à corriger sans réécrire toutes les données.
• 2 Ne pas définir de politique de rétention dès le départ. Sans tiering hot/warm/cold, la base grossit sans contrôle et les coûts de stockage explosent. TimescaleDB intègre des politiques de compression et d'archivage automatiques — les configurer dès le déploiement, pas quand le disque est plein.
• 3 Créer une table par capteur au lieu d'une hypertable unifiée avec un champ device_id. La multiplication des tables rend les requêtes inter-capteurs impossibles et la maintenance un cauchemar dès qu'on dépasse une dizaine de capteurs.

Décision 4 — Comment visualiser les données capteurs sur une carte ?

La visualisation est souvent la première question posée — « on veut voir ça sur une carte » — mais c'est la dernière décision à prendre, parce qu'elle dépend entièrement des trois précédentes. La bonne nouvelle : avec TimescaleDB + PostGIS en base, les deux outils standards s'y connectent nativement.

La règle de choix est simple : si la carte est un widget dans un dashboard opérationnel, Grafana Geomap suffit et évite du développement inutile. Si la carte est le produit principal — portail public, application terrain, visualisation de trajectoires ou de zones de chaleur — MapLibre + Martin est la bonne architecture.

Ce que ça donne en pratique : trois architectures selon votre contexte

Quatre décisions, dans l'ordre

Un pipeline IoT géolocalisé n'est pas un catalogue de technologies à assembler au hasard. C'est une chaîne où chaque maillon conditionne le suivant. Prendre les quatre décisions dans le bon ordre — protocole, ingestion et traitement, stockage, visualisation — évite les refontes coûteuses et garantit une architecture qui tient dans le temps.

La bonne nouvelle : avec l'outillage open source disponible en 2026 (MQTT, Node-RED, TimescaleDB + PostGIS, Grafana, MapLibre), un pipeline complet et pérenne tourne pour 20 à 80 € par mois d'infrastructure, sans licence propriétaire. Ce qui coûte, c'est de prendre les mauvaises décisions — pas de les prendre avec les bons outils.