Smart streetlighting : de pilote à déploiement ville entière

Summary

Passer d’un pilote de 200 à 500 points lumineux à un déploiement de 20 000 à 50 000 luminaires impose une architecture réseau hiérarchisée, une plateforme IoT scalable (10⁶ messages/jour) et une gouvernance des données conforme RGPD (99,9 % de disponibilité).

Key Takeaways

Concevoir une architecture réseau en 3 couches (terrain, agrégation, plateforme) capable de gérer 10 000 à 100 000 luminaires avec une latence typique 99,5 %, synchronisation NTP < 1 s) pour garantir la qualité de service à l’échelle métropolitaine
Structurer la gouvernance des données (catalogue, DPIA RGPD, rôles RBAC) dès 1 000 points pour éviter une refonte coûteuse lors du passage à 20 000+ équipements
Mettre en œuvre un jumeau numérique réseau (topologie + inventaire) mis à jour quotidiennement pour réduire de 20 à 30 % les temps de diagnostic et d’intervention terrain

Introduction : du pilote à l’échelle de la ville

Les projets d’éclairage public intelligent démarrent souvent par un pilote limité, de 50 à 500 points lumineux, sur un quartier ou un axe prioritaire. À cette échelle, un réseau simple, quelques dashboards et une base de données unique semblent suffisants. Le passage à un déploiement ville entière – 10 000 à 50 000 luminaires, parfois plus – change radicalement l’équation technique.

Les défis se déplacent alors vers la scalabilité du réseau radio ou cellulaire, la résilience des concentrateurs, la performance de la plateforme IoT, la qualité des données et la conformité réglementaire (RGPD, cybersécurité). Sans une architecture pensée pour l’échelle, les coûts d’exploitation explosent, les taux de disponibilité chutent et la ville se retrouve enfermée dans un silo technologique difficile à faire évoluer.

L’objectif de cet article est de proposer un cadre d’architecture réseau et de gestion des données permettant de passer d’un pilote limité à un déploiement métropolitain maîtrisé, en s’appuyant sur des standards ouverts et des bonnes pratiques issues de l’IoT industriel.

Architecture réseau pour un éclairage public intelligent à grande échelle

Trois couches structurantes

Une architecture robuste de smart streetlighting s’organise typiquement en trois couches :

Couche terrain (field layer)
- Contrôleurs de luminaires (NLC – Networked Lighting Controllers)
- Capteurs additionnels (trafic, environnement, bruit)
- Interfaces DALI/1-10 V/0-10 V, alimentation, horloge locale
Couche agrégation (edge / backhaul)
- Concentrateurs / passerelles RF ou PLC
- Routeurs IP, VPN, pare-feu
- Liens de collecte (4G/5G, fibre, Ethernet, LPWAN)
Couche plateforme (cloud / datacenter)
- Plateforme IoT (ingestion, device management)
- Systèmes métiers (GMAO, SIG, supervision, facturation)
- API ouvertes pour intégration avec d’autres verticales smart city

Cette séparation claire permet :

d’isoler les évolutions technologiques (changer de radio sans refondre la plateforme)
de segmenter la sécurité
de répartir l’intelligence entre edge et cloud

Choix des technologies de communication

Le réseau d’accès entre les luminaires et les concentrateurs est un point critique. Les options courantes incluent :

Technologie	Portée typique	Débit utile	Topologie	Cas d’usage principal
RF maillé 2,4/868	50–150 m/saute	50–200 kbit/s	Mesh multi-sauts	Urbain dense, rétrofit
PLC (CPL G3/PRIME)	200–1 000 m	10–100 kbit/s	Ligne électrique	Réseaux existants, zones mixtes
LoRaWAN	1–5 km urbain	0,3–50 kbit/s	Étoile	Télémetrie, capteurs faibles volumes
NB-IoT / LTE-M	1–10 km	20–200 kbit/s	Cellulaire	Zones étendues, pas d’infra RF dédiée
4G/5G (IP direct)	1–5 km	Mbit/s	Cellulaire	Armoires/segments critiques

La plupart des projets ville entière adoptent une approche hybride :

RF maillé ou PLC pour les luminaires
4G/5G ou fibre pour les concentrateurs

Le passage à l’échelle impose :

une densité de concentrateurs optimisée (1 pour 100 à 300 luminaires selon la topologie)
une planification radio (puissance, canaux, redondance) basée sur des simulations et des mesures terrain
une capacité de reconfiguration OTA (over-the-air) pour ajuster les paramètres sans intervention physique

Protocoles et adressage

Pour éviter les impasses technologiques, il est recommandé de :

utiliser IPv6 pour l’adressage des équipements, en cohérence avec les recommandations de l’IEEE et de l’IETF pour l’IoT
standardiser les couches applicatives sur des protocoles largement supportés :
- MQTT ou MQTT-SN pour la télémétrie et la commande
- CoAP pour les équipements très contraints
- HTTPs/REST pour les API de la plateforme

À l’échelle de 50 000 luminaires, la gestion des identifiants devient critique :

schéma d’adressage logique (ville/quartier/armoire/point)
synchronisation avec le SIG et l’inventaire patrimonial
gestion du cycle de vie (commissioning, mise à jour, décommissionnement)

Résilience et haute disponibilité

Pour garantir une disponibilité de service ≥ 99,5 % à l’échelle de la ville, l’architecture doit intégrer :

Redondance des concentrateurs
- double chemin de communication (ex. RF + cellulaire de secours)
- possibilité de reroutage maillé en cas de panne d’un nœud
Haute disponibilité de la plateforme
- déploiement en cluster multi-zones (cloud) ou datacenter redondé
- base de données répliquée (RPO ≤ 15 min, RTO ≤ 1 h selon criticité)
Gestion des pannes dégradées
- profils d’éclairage locaux (horloge astronomique) en cas de perte de liaison
- files d’attente de commandes avec reprise automatique

Gestion des données : du flux terrain à la gouvernance métropolitaine

Volumétrie et modèles de données

Un luminaire connecté génère typiquement :

télémétrie d’état (ON/OFF, niveau de gradation) : 1 à 4 messages/heure
mesures électriques (U, I, P, PF, kWh) : 1 message/15 à 60 minutes
événements (ouverture de porte, défaut, surtension) : événements sporadiques

Pour 20 000 points lumineux, cela représente facilement :

200 000 à 1 000 000 messages/jour
plusieurs dizaines de Go de données/an si l’on conserve l’historique détaillé

Le modèle de données doit être :

normalisé (unités, horodatage ISO 8601, fuseau horaire unique)
extensible (ajout de capteurs : bruit, pollution, trafic)
aligné sur des référentiels ouverts (par exemple NGSI-LD pour l’interopérabilité smart city)

Pipeline d’ingestion et traitement

Une architecture type de traitement de données comprend :

Ingestion
- brokers MQTT/AMQP hautement disponibles
- passerelles de protocole (traduction RF propriétaire → MQTT/JSON)
Traitement temps réel
- moteur de règles (détection d’anomalies, alertes, automatisme local/global)
- agrégation temps réel (puissance par quartier, par armoire)
Stockage opérationnel
- base de données de séries temporelles (TSDB) pour la télémétrie (ex. InfluxDB, TimescaleDB)
- base relationnelle ou orientée documents pour l’inventaire et la configuration
Stockage analytique
- data lake ou entrepôt de données pour l’historique long terme et la BI
Exposition
- API REST/GraphQL sécurisées
- connecteurs vers GMAO, SIG, systèmes financiers et plateformes open data

Stratégie de stockage et de rétention

Pour maîtriser les coûts, il est pertinent de définir plusieurs niveaux de rétention :

Données chaudes (0–12 mois)
- granularité fine (1 à 15 minutes)
- accessibles en temps réel pour l’exploitation et le SAV
Données tièdes (1–3 ans)
- données agrégées (horaire/journalière)
- utilisées pour le suivi de performance, les rapports réglementaires
Données froides (3–10 ans)
- archivage compressé ou stockage objet
- nécessaires pour les audits, les analyses de long terme, les contentieux éventuels

Une telle stratégie peut réduire de 30 à 40 % les coûts de stockage par rapport à une conservation brute de tous les échantillons.

Qualité, gouvernance et sécurité des données

À l’échelle métropolitaine, la donnée devient un actif stratégique. Les bonnes pratiques incluent :

Qualité des données
- validation à l’ingestion (plages de valeurs, cohérence temporelle)
- détection automatique de dérives de capteurs
Gouvernance
- catalogue de données (métadonnées, propriétaires, finalités)
- politiques de partage (interservices, partenaires, open data)
- comité de gouvernance associant DSI, direction de l’éclairage, juridique et DPO
Sécurité
- chiffrement en transit (TLS 1.2+) et au repos (disques chiffrés)
- contrôle d’accès basé sur les rôles (RBAC) et journalisation des accès
- tests de pénétration réguliers et supervision SOC pour les grandes métropoles

La conformité au RGPD est généralement moins complexe que pour d’autres verticales, car l’éclairage public traite peu de données personnelles. Néanmoins, l’ajout de capteurs (vidéo, Wi-Fi, comptage de terminaux mobiles) peut changer la donne et impose des analyses d’impact (DPIA).

Cas d’usage et ROI : ce que permet une architecture bien conçue

Optimisation énergétique et maintenance prédictive

Une architecture réseau et data robuste permet :

Réduction de la consommation
- gradation dynamique en fonction du trafic (jusqu’à –50 % sur certains axes)
- adaptation saisonnière et événementielle (festivals, travaux)
Maintenance optimisée
- détection automatique des lampes défaillantes (courant, puissance, PF)
- priorisation des tournées (clustering des pannes)
- réduction du temps moyen de réparation (MTTR) de 20 à 40 %

Sur un parc de 30 000 points, une économie énergétique de 50 % et une réduction de 20 % des coûts de maintenance peuvent représenter plusieurs centaines de milliers d’euros par an.

Intégration multi-services smart city

Les candélabres constituent un support idéal pour d’autres services :

capteurs environnementaux (NO₂, PM2.5, bruit)
caméras de vidéoprotection
bornes de recharge pour véhicules électriques
Wi-Fi public ou small cells 5G

Une architecture réseau modulaire et une gouvernance des données claire facilitent :

le partage sécurisé des infrastructures (alimentation, backhaul)
la mutualisation des coûts d’exploitation
la création de tableaux de bord transverses (énergie, mobilité, sécurité)

Passage de 500 à 20 000 points : points de bascule

Le saut d’échelle s’accompagne de plusieurs « points de bascule » :

Passage de l’administration manuelle à l’industrialisation
- outils de provisioning massif (batch de 100–1 000 équipements)
- scripts d’automatisation (API-first)
Passage d’un seul opérateur à une organisation multi-équipes
- séparation des rôles (exploitation réseau, exploitation applicative, data)
- procédures ITIL (incident, problème, changement)
Passage d’un simple dashboard à une plateforme de pilotage
- KPIs standardisés (taux de disponibilité, temps de réponse, consommation)
- rapports périodiques pour les élus, les services techniques, les citoyens

Une bonne anticipation de ces points de bascule dès la phase pilote permet d’éviter des refontes coûteuses et des interruptions de service lors du déploiement massif.

Guide de sélection et bonnes pratiques d’architecture

Critères clés pour la sélection de la solution

Domaine	Critère mesurable	Cible recommandée pour ville 20k–50k points
Scalabilité	Capacité de devices gérés	≥ 100 000
Performance	Débit de messages traités	≥ 1 million/jour
Disponibilité	SLA plateforme	≥ 99,9 %
Sécurité	Chiffrement, gestion des identités	TLS 1.2+, PKI, RBAC
Interopérabilité	Protocoles et API	MQTT/CoAP, REST/JSON, support NGSI-LD
Exploitabilité	Outils de supervision et d’alerting	Intégration avec outils NMS/SIEM
Réversibilité	Export complet des données et configurations	Formats ouverts, documentation API

Bonnes pratiques pour réussir le passage à l’échelle

Architecturer pour 10x dès le pilote
- dimensionner le réseau et la plateforme pour au moins 10 fois le périmètre initial
- tester des scénarios de charge (stress tests) avant le déploiement massif
Standardiser les interfaces
- imposer des protocoles et formats ouverts dans les cahiers des charges
- éviter les dépendances fortes à des stacks propriétaires non documentées
Investir dans l’outillage
- supervision réseau (NMS), supervision applicative (APM), observabilité (logs, métriques, traces)
- outils de gestion de configuration et d’inventaire intégrés au SIG
Mettre la cybersécurité au cœur du design
- segmentation réseau (VLAN/VRF par zone ou par service)
- durcissement des équipements (mots de passe uniques, mises à jour régulières)
Prévoir l’évolution
- capacité d’ajouter de nouveaux services (capteurs, services tiers) sans refonte
- roadmap technique alignée avec la stratégie smart city globale

FAQ

Q: Comment dimensionner le réseau pour passer de 500 à 20 000 luminaires ? A: Le dimensionnement doit partir des flux unitaires : nombre de messages par luminaire et par heure, taille moyenne des messages, latence acceptable pour les commandes. En multipliant ces valeurs par le nombre cible de points, vous obtenez un ordre de grandeur du trafic. Il faut ensuite ajouter une marge de 30 à 50 % pour absorber les pics (campagnes de mise à jour, reconfigurations massives). Enfin, vérifiez que les concentrateurs et la plateforme peuvent gérer au moins 2 à 3 fois le nombre maximal de connexions simultanées prévu.

Q: Quels protocoles privilégier pour garantir l’interopérabilité à long terme ? A: Pour la couche IP, IPv6 est fortement recommandé afin de disposer d’un espace d’adressage suffisant et de s’aligner sur les bonnes pratiques IoT. Pour la télémétrie et la commande, MQTT est devenu un standard de facto, grâce à sa légèreté et à son large support. CoAP est intéressant pour les équipements très contraints. Au niveau applicatif, des modèles de données ouverts comme NGSI-LD facilitent l’interopérabilité entre différents domaines smart city (éclairage, mobilité, environnement) et réduisent le risque d’enfermement propriétaire.

Q: Comment assurer la cybersécurité d’un réseau de smart streetlighting ? A: La cybersécurité repose d’abord sur le chiffrement systématique des communications (TLS 1.2 ou supérieur) et une gestion rigoureuse des identités (certificats X.509, rotation régulière des clés). La segmentation réseau est essentielle : séparer les flux d’éclairage des autres services, limiter le rayon d’attaque à des sous-réseaux de quelques centaines de points. Il faut également durcir les équipements (mots de passe uniques, désactivation des services inutiles) et mettre en place une supervision de sécurité (logs centralisés, corrélation d’événements, tests de pénétration périodiques).

Q: Quels sont les principaux risques lors du passage du pilote au déploiement ville entière ? A: Les risques majeurs sont la sous-estimation de la complexité opérationnelle et la dépendance à des solutions trop propriétaires. Un pilote peut fonctionner avec des processus manuels et des scripts ad hoc, mais ces approches ne tiennent plus à 20 000 points. Sans industrialisation (outils de provisioning, supervision, automatisation), les coûts d’exploitation explosent. Par ailleurs, des choix de protocoles fermés ou de formats de données non documentés compliquent l’intégration avec d’autres systèmes et rendent toute migration ultérieure très coûteuse.

Q: Comment gérer la qualité des données sur plusieurs dizaines de milliers de points lumineux ? A: Il est indispensable de mettre en place des contrôles automatiques dès l’ingestion : plages de valeurs acceptables, cohérence temporelle, détection de capteurs muets. Des tableaux de bord de qualité de données (taux de complétude, taux d’erreurs, latence moyenne) doivent être suivis régulièrement. La standardisation des unités, des horodatages et des codes d’événements réduit les risques d’interprétation erronée. Enfin, un processus de correction (manuelle ou semi-automatique) et de relecture périodique des règles de validation permet d’améliorer progressivement la fiabilité du système.

Q: Quels bénéfices concrets attendre d’une architecture bien conçue en termes de ROI ? A: Une architecture réseau et data adaptée à l’échelle permet d’atteindre des économies d’énergie de 50 % ou plus grâce à la gradation dynamique et à l’optimisation des horaires. La maintenance prédictive et la détection automatique des pannes réduisent de 20 à 40 % les coûts d’intervention. La mutualisation de l’infrastructure pour d’autres services (capteurs environnementaux, vidéoprotection, télécommunications) améliore encore le retour sur investissement. Enfin, la disponibilité élevée du système et la qualité des données facilitent l’obtention de financements et la démonstration de résultats aux élus et aux citoyens.

Q: Comment intégrer les systèmes d’éclairage intelligent avec les outils existants (GMAO, SIG, supervision) ? A: L’intégration passe par des API ouvertes, bien documentées, idéalement REST/JSON ou GraphQL, avec des webhooks pour les événements temps réel. Le référentiel d’inventaire des luminaires doit être synchronisé avec le SIG pour garantir la cohérence géographique. Les événements de panne et les compteurs de fonctionnement peuvent être automatiquement transmis à la GMAO pour générer des ordres de travail. Pour la supervision, l’export de métriques vers des outils NMS/APM standard permet de suivre l’état de santé du système au même titre que les autres infrastructures de la ville.

Q: Quels sont les enjeux RGPD pour un projet de smart streetlighting ? A: L’éclairage public en tant que tel génère peu de données personnelles, ce qui limite les contraintes RGPD. Toutefois, dès que l’on ajoute des capteurs susceptibles d’identifier indirectement des personnes (vidéo, Wi-Fi, comptage de terminaux), il faut réaliser une analyse d’impact (DPIA) et définir des finalités claires. Les données doivent être minimisées, pseudonymisées lorsque c’est possible, et conservées pour une durée limitée. Il est également important d’informer les citoyens de manière transparente sur les traitements réalisés et de mettre en place des procédures pour répondre à leurs droits (accès, rectification, opposition).

Q: Faut-il privilégier une plateforme cloud ou on-premise pour la gestion des données ? A: Le choix dépend du contexte réglementaire, des politiques internes de la collectivité et des compétences disponibles. Le cloud offre généralement une meilleure élasticité, une mise à l’échelle plus simple et des services managés (bases de données, sécurité, observabilité) qui réduisent la charge d’exploitation. Une approche on-premise peut être justifiée pour des raisons de souveraineté, de latence ou d’intégration avec des systèmes existants très sensibles. De plus en plus de villes optent pour des architectures hybrides, combinant un socle cloud pour la scalabilité et des briques locales pour les fonctions les plus critiques.

Q: Comment préparer l’évolution vers de nouveaux services (5G, capteurs, mobilité) ? A: Il est essentiel de concevoir dès le départ une architecture modulaire, avec des interfaces standardisées et une capacité de backhaul suffisante. Les candélabres doivent être prévus pour accueillir des équipements additionnels (emplacements, alimentation, connectique). Sur le plan logiciel, une plateforme orientée microservices et API-first facilite l’ajout de nouvelles verticales (mobilité, environnement, sécurité). Enfin, la gouvernance des données doit anticiper le partage interservices, en définissant des règles d’accès, des modèles de données communs et des processus de concertation entre les directions concernées.

References

IEEE (2018): IEEE 1547-2018 – Standard for Interconnection and Interoperability of Distributed Energy Resources with Associated Electric Power Systems Interfaces
IEC (2023): IEC 62351 – Power systems management and associated information exchange – Data and communications security
IEA (2022): IEA – Digital Demand-Driven Electricity Networks: Smart street lighting and connected public infrastructure
ETSI (2020): ETSI TS 103 645 – Cyber Security for Consumer Internet of Things: Baseline Requirements
IRENA (2019): IRENA – Innovation landscape for a renewable-powered future: smart charging and smart infrastructure
ENISA (2020): ENISA – Guidelines for securing the Internet of Things – Smart Infrastructures

À propos de SOLARTODO

SOLARTODO est un fournisseur mondial de solutions intégrées spécialisé dans les systèmes de production d'énergie solaire, les produits de stockage d'énergie, l'éclairage public intelligent et solaire, les systèmes de sécurité intelligents et IoT, les pylônes de transmission électrique, les tours de télécommunications et les solutions d'agriculture intelligente pour les clients B2B du monde entier.