Ville intelligente IoT : l'architecture MQTT expliquée

Les projets IoT de ville intelligente démarrent généralement sous forme de pilotes séparés, un pour l'éclairage public, un pour les poubelles, un pour la qualité de l'air, puis peinent à partager leurs données. Ce guide présente une architecture à l'échelle de la ville dans laquelle chaque domaine publie vers une couche de messagerie MQTT commune, ce qui permet d'ajouter des services sans créer un nouveau silo à chaque fois. Vous y verrez les couches, une hiérarchie de topics pragmatique, les options de connectivité ainsi que les choix de sécurité et de montée en charge qui comptent.

Le problème des pilotes urbains en silo

Une ville type finit avec un portail fournisseur pour l'éclairage, un tableau de bord pour la collecte des déchets et une plateforme de surveillance environnementale, chacun avec son modèle de données, son identifiant de connexion et son format d'export. Les combiner, par exemple pour baisser l'éclairage quand la qualité de l'air est mauvaise ou pour faire contourner des travaux aux camions de collecte, devient à chaque fois un projet d'intégration.

Une couche de messagerie partagée change la donne par défaut. Si chaque système publie ses événements et ses états vers un seul broker sous un espace de noms commun, toute nouvelle application peut s'abonner à ce dont elle a besoin. Les fournisseurs continuent de livrer les équipements et les logiciels spécialisés ; ils s'engagent simplement à publier vers le backbone de la ville et à y lire. Pour un rappel sur le rôle du broker, lisez ce que fait un broker MQTT.

L'architecture IoT de la ville intelligente en cinq couches

Couche	Ce qu'on y trouve	Technologies typiques
Équipements	Contrôleurs de lampadaires, capteurs de remplissage, stations de qualité de l'air, palets de stationnement	Microcontrôleurs, nœuds de lampadaire NEMA/Zhaga, capteurs à ultrasons et optiques
Réseaux de terrain	Liaisons radio basse consommation et cellulaires	LoRaWAN, NB-IoT, LTE-M, Wi-Fi dans les bâtiments, fibre jusqu'aux armoires
Passerelles et serveurs réseau	Décodent les payloads radio, traduisent les protocoles	Serveurs réseau LoRaWAN, passerelles edge, convertisseurs de protocoles
Backbone de messagerie	Achemine les événements entre producteurs et consommateurs	Broker MQTT avec TLS, topics structurés
Applications	Tableaux de bord, analyses, logique de contrôle, open data	Node-RED, bases de données de séries temporelles, cartes SIG, services sur mesure

Le broker est placé au centre à dessein. Réseaux de terrain et applications évoluent à des rythmes différents ; les découpler par publish/subscribe signifie qu'un nouvel outil d'analyse de la qualité de l'air ne nécessite aucune modification des capteurs, et qu'un jumeau numérique de la ville peut s'abonner plus tard aux mêmes topics.

Trois domaines d'exemple

Éclairage public intelligent

Les contrôleurs de lampadaires remontent la puissance consommée, les heures de fonctionnement et les défauts, et acceptent des commandes de gradation. Les topics typiques comprennent un state retenu avec le niveau de gradation actuel et un topic de commande set utilisé par le service de planification. Les événements de défaut, comme un driver en panne, deviennent automatiquement des tickets de maintenance lorsqu'un abonné les récupère. Notre article sur l'éclairage intelligent avec MQTT détaille les schémas de commande et d'état.

Niveau de remplissage des poubelles

Des capteurs à ultrasons ou radar placés dans les poubelles remontent le pourcentage de remplissage quelques fois par jour en LoRaWAN ou NB-IoT. Un service de planification de tournées s'abonne à toutes les poubelles d'un quartier et planifie la collecte de celles qui dépassent un seuil. Ici, l'intérêt de MQTT tient moins à la latence qu'au découplage : le planificateur de tournées, le portail open data et le tableau de bord de propreté lisent tous les mêmes niveaux de remplissage retenus.

Surveillance de la qualité de l'air

Les stations mesurent les particules fines, le dioxyde d'azote, la température et l'humidité. Les données alimentent des cartes publiques, des alertes sanitaires et la recherche. L'approche de mesure et de publication utilisée en intérieur dans un capteur de qualité de l'air intérieur s'applique à l'échelle de la rue, avec davantage d'attention portée à l'étalonnage, au chauffage du boîtier et à la validation des données.

Le stationnement est un quatrième domaine courant, décrit de bout en bout dans notre plan de parking intelligent IoT.

Une hiérarchie de topics à l'échelle de la ville

Un espace de noms partagé est l'accord le plus précieux de tout le projet. Une organisation qui a fait ses preuves suit le schéma domaine d'abord, puis géographie, puis actif :

city/<domain>/<district>/<asset-type>/<asset-id>/<signal>

city/lighting/north/lamp/L-10442/state          retained {"on":true,"dim":60,"watts":38}
city/lighting/north/lamp/L-10442/state/set      {"dim":30}
city/lighting/north/lamp/L-10442/fault          {"code":"DRIVER_FAIL","ts":1760600000}
city/waste/centre/bin/B-2210/fill               retained {"pct":82,"ts":1760600000}
city/air/harbour/station/AQ-07/pm25             retained {"ugm3":14.2,"ts":1760600000}
city/parking/old-town/summary                   retained {"free":112,"total":420}

Pourquoi le domaine en premier ? Parce que la responsabilité suit les domaines. Le service de l'éclairage est responsable de city/lighting/#, ce qui simplifie la délimitation des identifiants, l'audit et les contrats fournisseurs. Les applications qui ont besoin de la géographie peuvent toujours s'abonner à travers les domaines : city/+/harbour/# renvoie tout ce qui concerne le quartier du port.

Les règles à formaliser dès le départ :

Chaque payload est en JSON, avec un horodatage et des unités explicites dans les noms de clés.
Les états sont retenus ; les événements et les commandes ne le sont pas.
Les identifiants d'actifs correspondent au registre des actifs de la ville, pas aux numéros de série des fournisseurs.
Les commandes utilisent toujours un suffixe /set et seuls les services désignés les publient.

Connectivité : acheminer les données jusqu'au broker

La plupart des capteurs urbains fonctionnent sur batterie et loin du Wi-Fi ; le réseau de terrain est donc généralement LoRaWAN ou l'IoT cellulaire. Aucun des deux n'exige que chaque capteur parle lui-même MQTT :

Les capteurs LoRaWAN envoient de petits payloads binaires à des passerelles installées sur les toits ; un serveur réseau les décode et les publie en MQTT. Exploiter votre propre serveur avec ChirpStack et MQTT est un choix courant pour les collectivités qui veulent garder la main sur leur réseau.
Les équipements NB-IoT et LTE-M peuvent ouvrir directement une connexion MQTT sur TLS, ce qui convient aux actifs alimentés sur secteur comme les contrôleurs de lampadaires ou les stations de mesure de l'air.
Les actifs filaires situés dans des armoires et des bâtiments se connectent via des passerelles edge qui traduisent Modbus ou les protocoles propriétaires.

Dans tous les cas, le broker reçoit des données propres et décodées. Effet secondaire utile : le nombre de connexions reste modeste, car des milliers de capteurs LoRaWAN peuvent arriver par une poignée de connexions de serveurs réseau.

Consommer les données de la ville : un petit exemple

Toute application n'est qu'un client MQTT de plus. Cet abonné Python, basé sur paho-mqtt 2.x, surveille toutes les stations de qualité de l'air et signale les mesures au-dessus d'un seuil. Testez-le sur le serveur MQTT public gratuit, réservé aux tests et aux prototypes, avec votre propre préfixe :

import json
import paho.mqtt.client as mqtt

PREFIX = "connectmq/demo/c9d1e4"   # your own random id
LIMIT = 25.0                       # example threshold for PM2.5 in ug/m3

def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{PREFIX}/air/+/station/+/pm25", qos=1)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    district, station = parts[-4], parts[-2]
    reading = json.loads(msg.payload)
    if reading["ugm3"] > LIMIT:
        print(f"High PM2.5 in {district} at {station}: {reading['ugm3']}")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="air-watch-c9d1e4")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

mosquitto_pub -h broker.connectmq.com -p 1883 -i aq-c9d1e4 -r -q 1 \
  -t connectmq/demo/c9d1e4/air/harbour/station/AQ-07/pm25 -m '{"ugm3":31.5,"ts":1760600000}'

Le préfixe de démonstration utilise déjà trois niveaux ; l'exemple supprime donc la racine city pour rester sous la limite de huit niveaux du serveur MQTT public gratuit. Sur un broker privé, vous utiliseriez le chemin complet city/air/.... En production, les seuils d'alerte peuvent aussi résider dans le portail du broker : ConnectMQ propose des règles d'alerte à seuil et un journal des alertes, tandis qu'une logique plus riche a sa place dans Node-RED ou dans vos propres services connectés en tant que clients.

Sécurité et gouvernance

L'infrastructure urbaine est une infrastructure critique, et la couche de messagerie doit être traitée comme telle :

TLS partout. Port 8883 pour les équipements et les passerelles, 8084 en WebSocket sécurisé pour les tableaux de bord dans le navigateur.
Des identifiants uniques par passerelle ou par service. Ne partagez jamais un même identifiant entre fournisseurs. Des client IDs liés aux identifiants rendent l'usurpation plus difficile.
Des chemins de commande séparés. Seul le service de planification doit publier les commandes d'éclairage ; fournisseurs et tableaux de bord doivent se contenter de lire l'état.
De l'isolation si nécessaire. Les domaines sensibles peuvent résider sur un broker séparé ou un cluster dédié plutôt que de partager celui des données publiques.
L'open data par la publication, pas par l'accès. Publiez des jeux de données organisés sur le portail open data au lieu de distribuer des identifiants de broker.

Notre guide des bonnes pratiques de sécurité MQTT approfondit les identifiants, TLS et la supervision.

Choix de montée en charge et d'hébergement

Les projets urbains passent d'un quartier pilote à la ville entière en plusieurs années ; choisissez donc un modèle d'hébergement qui grandit avec eux. Exploiter votre propre cluster de brokers est possible, mais rend la ville responsable des correctifs, des certificats, de la supervision et de la capacité. Un broker MQTT managé transfère ce travail au fournisseur. ConnectMQ propose des offres serverless mutualisées pour les pilotes, des clusters dédiés et isolés pour la production, et des déploiements BYOC qui s'exécutent dans le compte cloud de la ville lorsque des règles de résidence des données l'exigent. Pour une comparaison plus large des modèles d'hébergement, consultez le guide du broker MQTT cloud.

Des cas d'usage connexes comme la surveillance de la chaîne du froid pour la logistique alimentaire et vaccinale municipale suivent le même schéma, et le guide de l'automatisation IoT rassemble des projets pour les bâtiments, les exploitations agricoles et l'énergie.

Checklist de préparation pour la ville intelligente IoT

Un espace de noms de topics documenté, avec domaine, quartier, type d'actif et identifiant.
Une convention de payload avec horodatages et unités.
Un registre des actifs qui associe les identifiants aux emplacements et aux responsables.
Des réseaux de terrain choisis par domaine, reliés à MQTT par des passerelles.
Des identifiants par passerelle et par service, TLS sur chaque connexion.
Une liste claire des services autorisés à publier des commandes.
Une supervision de la disponibilité des équipements et du niveau des batteries.
Un plan d'hébergement qui passe du pilote à l'échelle de la ville.

Construisez le backbone de données de votre ville sur ConnectMQ

Lancez un quartier pilote sur un broker Serverless gratuit, validez le modèle de topics avec de vrais capteurs, puis passez à un déploiement dédié ou BYOC pour la production. Inscrivez-vous sur app.connectmq.com, sans carte bancaire, et regardez vos premiers topics urbains apparaître dans l'explorateur de topics en direct.

Questions fréquentes

Les capteurs de ville intelligente doivent-ils prendre en charge MQTT directement ?

Non. La plupart des capteurs sur batterie utilisent LoRaWAN ou NB-IoT, et un serveur réseau ou une passerelle décode leurs payloads et les publie vers le broker MQTT en leur nom.

Pourquoi placer le domaine avant le quartier dans le topic ?

La responsabilité et les accès suivent généralement les domaines, comme l'éclairage ou les déchets. Des topics organisés par domaine facilitent l'attribution des responsabilités tout en permettant des abonnements par wildcard à l'échelle d'un quartier.

Un seul broker peut-il servir tous les services de la ville ?

Oui, à condition que chaque service utilise ses propres identifiants et sa propre sous-arborescence de topics. Les systèmes très sensibles peuvent toujours être placés sur un broker séparé ou un cluster dédié.

Comment une ville doit-elle publier en open data les données de ses capteurs ?

Exécutez un abonné qui organise, agrège et publie des jeux de données sur le portail open data. Ne distribuez pas d'identifiants de broker au public.

Architecture IoT pour la ville intelligente avec MQTT : éclairage, déchets, qualité de l'air et couche de messagerie