Le jalonnement de notre parking : la première supervision CiteosVision

27/09/2026 · 5 min de lecture IoT LoRa Parking

Avant de superviser l’éclairage public ou les bornes de recharge, CiteosVision a commencé beaucoup plus modestement : par le parking de notre propre entreprise, à Le Petit-Quevilly. Pas un client, pas un cahier des charges : un besoin qu’on vivait tous les jours.

Le besoin

Le parking est découpé en trois zones : Collaborateur, Visiteur et PMR. Sans visibilité sur les places libres, on tournait pour rien, surtout aux heures d’affluence. L’idée de départ était simple : un capteur par place, un panneau à l’entrée qui indique combien de places restent dans chaque zone.

Écran de gestion des zones de parking, listant les capteurs affectés à chaque zone (Collaborateur, PMR, Visiteur) — Chaque capteur est rattaché à une zone. Le nombre de places libres est recalculé zone par zone.

La solution

Chaque place reçoit un capteur LoRaWAN à détection magnétique et radar 60 GHz (référence SPS200, IP68, IK7), qui combine les deux techniques pour fiabiliser la détection quelle que soit la météo, et remonte son état par radio avec sa charge de batterie, jusqu’à dix ans d’autonomie annoncés. Les trames sont captées par une antenne fibre de verre omnidirectionnelle 8 dBi, IP67, reliée à une passerelle LoRaWAN qui fait aussi office de concentrateur sur site (modèle OptimaGate, alimentée en PoE). Ces mesures arrivent ensuite sur notre superviseur, qui les enregistre et recalcule en continu le nombre de places libres par zone. Un panneau d’affichage à l’entrée du site montre ce compte en temps réel, zone par zone, jusqu’à afficher « COMPLET » quand il n’y a plus de place.

flowchart LR
    A["Capteur LoRaWAN<br/>magnétique + radar 60 GHz<br/>SPS200 · IP68 / IK7"] -->|"LoRaWAN 868 MHz"| B["Antenne 8 dBi<br/>omnidirectionnelle · IP67"]
    B --> C["Passerelle LoRaWAN<br/>OptimaGate · PoE"]
    C -->|"HTTP webhook"| D["Superviseur<br/>nginx + PHP + PostgreSQL<br/>VM Debian 13 sur Proxmox VE"]
    D -->|"TCP 4001 · LCR NF P99-341"| E["Panneau d'affichage<br/>3 modules × 7 caractères"]

Comment ça fonctionne

Le capteur envoie une trame à chaque changement d’état (véhicule détecté ou parti), pas en continu : ça préserve sa batterie, pensée pour durer plusieurs années. Côté serveur, chaque trame devient une ligne dans une table d’événements, jamais écrasée : on peut ainsi reconstruire l’historique d’occupation d’une place, pas seulement son état du moment. Ce service tourne dans une VM Debian 13, sur un hyperviseur Proxmox VE.

Le panneau d’affichage, lui, pose un problème différent : il doit toujours montrer une valeur juste, même si le réseau a un accroc. Il est composé de trois modules de sept caractères, un par zone, pilotés en TCP par le protocole LCR (Langage de Commande Routier, norme NF P99-341), chez le fabricant TTS. Le panneau ne fait aucune intelligence : il affiche tel quel ce qu’on lui envoie, une trame texte par zone :

Le totem CITEOS à l'entrée du parking, avec le panneau LED trois modules affichant les places libres par zone (Collaborateurs, Visiteurs, PMR) — Le panneau installé à l'entrée du parking, un module par zone (Collaborateurs, Visiteurs, PMR).

PA AM=1.0 AF="9 LIBRE" EC=AU AT=0 CL=0 AM=2.0 AF="1 LIBRE" EC=AU AT=0 CL=0 AM=3.0 AF="COMPLET" EC=AU AT=0 CL=0

Cette trame est renvoyée toutes les 3 secondes, qu’elle ait changé ou non : c’est ce battement régulier, plus que le calcul d’occupation lui-même, qui garantit qu’un panneau ne reste jamais figé sur une ancienne valeur après un accroc réseau.

Console de supervision de l'afficheur : prévisualisation des trois modules, état de la connexion TCP et dernière trame LCR envoyée — La console de supervision du panneau : connexion, dernière trame envoyée, et contrôle manuel par zone en cas de besoin.

Maintenir cet affichage synchronisé, sans jamais laisser une ancienne valeur s’y figer, s’est révélé être la partie la plus délicate du projet, bien plus que le calcul d’occupation lui-même : un panneau qui affiche une information fausse est pire qu’un panneau éteint.

Ce qu’on en a retenu

Ce premier déploiement, grandeur nature et sur notre propre terrain, a posé des questions qu’on n’aurait pas anticipées sur le papier : que faire d’un capteur dont la batterie faiblit ? Comment distinguer un capteur en maintenance d’un capteur en panne ? Comment garantir qu’un panneau ne reste jamais bloqué sur une ancienne valeur ?

Ce sont ces questions, pas la technologie LoRa elle-même, qui ont façonné la suite : un compteur de places libres est un cas particulier d’un problème plus général, celui de superviser n’importe quel équipement de terrain de façon fiable.

Et aujourd’hui

Cette première brique a donné naissance à CiteosVision, la même plateforme qui supervise aujourd’hui notre éclairage public. Le principe reste le même : un cœur générique qui ne connaît que des équipements, des mesures et des commandes, et des connecteurs qui dialoguent chacun dans le protocole du terrain, qu’il s’agisse d’un capteur de parking, d’un point lumineux ou d’une caméra.

Le parking, lui, continue de tourner : la carte ci-dessous montre l’état de chaque place en temps réel, capteur par capteur.

Synoptique du parking : vue aérienne avec l'état de chaque place (libre, occupée, batterie faible, en travaux, hors ligne) et le détail d'un capteur — Le synoptique du parking aujourd'hui : chaque place affiche son état en temps réel, avec le détail du capteur au survol.

Technologies

LoRaWAN, HTTP (webhook), TCP, LCR (NF P99-341), nginx, PHP, C, PostgreSQL, Debian, Proxmox VE.

Me contacter

← Tous les articles