MQTT c'est quoi et comment l'utiliser en vidéoprotection
MQTT est un protocole de messagerie léger basé sur le modèle publier/souscrire, conçu pour faire dialoguer des équipements connectés sur des réseaux à bande passante limitée. Dans la pratique, il sert quand une caméra détecte un événement, que le NVR doit réagir tout de suite, et qu'un opérateur ne veut pas attendre un rafraîchissement manuel.
Vous êtes souvent dans ce cas sans forcément l'appeler comme ça. Une alarme technique remonte, une caméra change d'état, un site distant perd sa liaison, et il faut que l'information circule sans lourdeur, sans requêtes répétées, et sans architecture inutilement compliquée. C'est là que MQTT prend tout son sens, surtout en vidéoprotection et en supervision de sites.
Table des matières
- Table des Contents
- MQTT c'est quoi et pourquoi il existe
- Comment fonctionne le modèle publier-souscrire
- Les paramètres qui changent tout QoS, sessions, Last Will
- Sécuriser un déploiement MQTT TLS, auth, ACL
- MQTT face à HTTP et REST pour la supervision
- Cas d'usage concrets en vidéoprotection et supervision
- Recommandations pratiques pour intégrer MQTT chez Vizeo
Table des Contents
- MQTT c'est quoi et pourquoi il existe
- Comment fonctionne le modèle publier-souscrire
- Les paramètres qui changent tout QoS, sessions, Last Will
- Sécuriser un déploiement MQTT TLS, auth, ACL
- MQTT face à HTTP et REST pour la supervision
- Cas d'usage concrets en vidéoprotection et supervision
- Recommandations pratiques pour intégrer MQTT chez Vizeo
MQTT c'est quoi et pourquoi il existe
Une caméra repère une intrusion, un NVR doit lancer l'enregistrement prioritaire, et un poste de supervision doit afficher l'alerte sans délai. Dans ce genre de chaîne, MQTT joue le rôle d'un langage d'échange léger, pensé pour transmettre des événements plutôt que pour faire dialoguer des interfaces lourdes.
Son origine est très parlante. Le protocole a été créé en 1999 par Andy Stanford-Clark chez IBM et Arlen Nipper chez Arcom, devenu Eurotech, pour surveiller à distance des pipelines pétroliers quand la liaison satellite coûtait cher et que la bande passante devait être utilisée avec parcimonie, comme l'explique le retour historique d'IP Systèmes sur MQTT dans ce dossier technique. Cette contrainte de départ a façonné un protocole sobre, taillé pour les environnements contraints.
Une logique différente du web classique
Le point clé, c'est le modèle publier/souscrire. Au lieu d'interroger sans cesse un équipement, on publie un événement une fois, puis les systèmes intéressés le reçoivent automatiquement. L'équipement émetteur n'a pas besoin de connaître les destinataires, et c'est précisément ce qui simplifie les architectures distribuées.
Repère utile : si un système doit surtout remonter des événements, des états ou des alertes, MQTT est souvent plus naturel qu'un échange pensé comme une suite de requêtes ponctuelles.
Dans les ressources françaises, cette logique est bien ancrée. Éduscol STI décrit MQTT comme un protocole de messagerie de type publication/souscription s'appuyant sur TCP/IP, avec une faible bande passante, une faible charge en données et une faible consommation. Le fait qu'il soit aussi reconnu comme standard ISO/IEC 20922 renforce son statut de socle technique stable pour les projets d'IoT, de supervision et de vidéoprotection.
Pour un intégrateur, cette origine industrielle change la lecture du protocole. MQTT n'est pas un gadget domotique, c'est une brique de communication conçue pour des systèmes où la fiabilité, la sobriété et la simplicité de déploiement comptent autant que la rapidité. C'est aussi pour cela qu'il s'insère bien dans des architectures où la vidéo elle-même circule par d'autres moyens, tandis que les événements, eux, transitent par MQTT.
Pour une vue plus large des logiques d'automatisation événementielle dans un autre univers métier, le guide complet automatisation ecommerce montre bien la valeur d'un système qui réagit à des signaux plutôt que de tout vérifier manuellement.
Comment fonctionne le modèle publier-souscrire
Le modèle MQTT ressemble à une radio bien organisée. Un poste émet sur une fréquence précise, d'autres postes écoutent seulement ce qui les concerne, et un relais central assure la circulation du message. En MQTT, ce relais s'appelle le broker, et c'est lui qui reçoit, trie, puis redistribue les messages aux bons abonnés.
Éditeurs, abonnés et broker
Trois rôles suffisent pour comprendre l'essentiel. L'éditeur, ou publisher, envoie un message. L'abonné, ou subscriber, s'intéresse à un sujet donné. Entre les deux, le broker centralise la circulation et évite aux équipements de se parler directement.
Cette séparation change tout dans une architecture de supervision. Une caméra peut publier un événement sur un topic d'intrusion, un NVR peut publier son état de santé, et une application peut s'abonner aux deux sans que l'une connaisse l'adresse logique de l'autre. Cette indirection permet d'ajouter un nouvel usage sans reconfigurer toute la chaîne.
L'image la plus simple reste celle des topics hiérarchiques. On sépare les niveaux avec des barres obliques, comme dans un chemin de dossier, par exemple site1/camera1/intrusion ou nvr/site1/etat. Le topic n'est pas un décor, c'est l'adresse fonctionnelle du message.
Pourquoi cette structure est efficace sur le terrain
Dans une salle de contrôle, on ne veut pas que chaque équipement connaisse tous les autres. On veut qu'il publie ce qu'il sait, puis que les bons consommateurs réagissent. C'est exactement ce que permet MQTT, avec une mécanique très lisible pour un intégrateur et très fiable pour un exploitant.
La connexion TCP/IP reste ouverte et réutilisée, ce qui évite de recommencer sans cesse des échanges complets. C'est particulièrement utile quand beaucoup d'objets dialoguent en continu, ou quand la liaison réseau n'est pas idéale. Sur un site de vidéoprotection, cette sobriété réduit la complexité d'exploitation.
La logique prend encore plus de sens dès qu'on l'applique aux équipements réels. Une caméra, comme la CA50HD, peut publier un état ou un événement au lieu d'être interrogée en permanence, et un NVR ou une application de supervision réagit ensuite selon ses propres règles.
Pour visualiser cette logique avec un schéma de simulation, l'environnement de simulation Vizeo aide à relier le concept de broker à des usages de terrain.
Les paramètres qui changent tout QoS, sessions, Last Will
On reconnaît vite un prototype et un vrai déploiement aux paramètres MQTT choisis avec soin. QoS, session persistante et Last Will ne sont pas des options théoriques, ce sont des leviers qui changent la perception de fiabilité côté exploitation.
QoS, la promesse de livraison
MQTT définit trois niveaux de QoS. Le QoS 0 fonctionne en mode au plus une fois, pratique pour des télémétries fréquentes où une perte ponctuelle n'est pas dramatique. Le QoS 1 vise au moins une fois, ce qui en fait un choix courant quand il faut privilégier la livraison. Le QoS 2 cherche l'exactement une fois, utile pour des commandes sensibles où un doublon poserait problème.
Le bon réflexe, c'est de choisir selon la criticité du message, pas selon une préférence technique. Une température de boîtier n'a pas la même exigence qu'une commande d'ouverture ou qu'un événement de sécurité. Le protocole laisse ce tri au concepteur du système.
Règle pratique : plus le message a un impact opérationnel direct, plus le niveau de QoS doit être réfléchi avec prudence.
Sessions et message testament
La session dit ce qui se passe quand un client se reconnecte. Avec une session éphémère, il repart presque de zéro. Avec une session persistante, il peut récupérer ce qui a été conservé pendant son absence, ce qui compte beaucoup pour la supervision d'équipements distants.
Le Last Will and Testament, souvent abrégé LWT, ajoute un filet de sécurité très concret. Si un client se coupe brutalement, le broker peut publier automatiquement un message prévu à l'avance. Dans un contexte de vidéoprotection, c'est précieux pour signaler qu'un NVR, une caméra ou un équipement réseau n'est plus joignable.
Lire ces choix en termes métier
Ces paramètres ne servent pas à faire joli dans une configuration. Ils traduisent une politique d'exploitation. Un poste de contrôle veut savoir si une alerte a été livrée, si un équipement est bien revenu après une coupure, et si une rupture de connexion doit elle-même devenir un événement.
Sécuriser un déploiement MQTT TLS, auth, ACL
Dès qu'un système MQTT sort du simple banc de test, il faut le traiter comme un vrai flux opérationnel. Les messages transportent des états, des alertes et parfois des commandes, donc la sécurité repose sur trois couches concrètes, TLS, authentification et ACL.
Chiffrer d'abord, identifier ensuite
Le TLS protège les échanges en transit. Sans lui, les messages circulent lisiblement sur le réseau, ce qui n'est pas acceptable pour un système qui véhicule des événements de sécurité ou des informations de supervision. Dès qu'on quitte un réseau strictement isolé, le chiffrement devient la base.
L'étape suivante, c'est l’authentification. Un identifiant et un mot de passe suffisent parfois pour un premier niveau, mais les déploiements plus exigeants s'orientent volontiers vers des certificats clients. L'idée reste simple, chaque équipement doit prouver qui il est avant de publier quoi que ce soit.
Verrouiller les topics avec des ACL
Les ACL côté broker servent à découper les droits avec précision. Une caméra n'a pas besoin de lire toutes les alertes du site, et un poste de supervision n'a pas vocation à envoyer des commandes à n'importe quel équipement. Le broker devient alors un point d'application des règles métier.
Côté outillage, des brokers comme Mosquitto, EMQX ou HiveMQ sont souvent cités dans les déploiements MQTT. Le port 8883 est couramment associé aux connexions chiffrées en TLS, ce qui donne un repère simple pour la mise en service.
Conseil de terrain : créez les comptes et certificats pour chaque site ou chaque famille d'équipements, puis révoquez-les proprement lors des remplacements. C'est beaucoup plus sain qu'un identifiant partagé entre tous les clients.
La sécurité ne se résume donc pas à cocher une case. Elle consiste à décider qui publie, qui lit, et sur quels sujets. Dans une architecture de supervision, cette discipline évite qu'un équipement prenne un rôle qu'il ne devrait jamais avoir.
MQTT face à HTTP et REST pour la supervision
HTTP et REST restent très utiles, mais ils répondent à une autre logique. Ils conviennent bien quand un utilisateur consulte une caméra, télécharge un clip ou déclenche une action ponctuelle. Dès qu'il faut faire remonter des événements en continu, MQTT devient plus naturel.
Deux logiques, deux usages
HTTP suit un schéma de requête et réponse. C'est simple pour un échange déclenché à la demande, mais moins adapté quand plusieurs équipements doivent pousser des états sans arrêt. Pour du temps réel, il faut alors soit interroger fréquemment, soit ajouter des mécanismes plus complexes.
MQTT, lui, est pensé pour les événements. Un producteur publie, les abonnés reçoivent, et le broker fait le tri. Cette logique s'applique très bien à la supervision de sites, parce qu'elle évite de multiplier les appels inutiles.
| Critère | HTTP/REST | MQTT |
|---|---|---|
| Sens de communication | Principalement à la demande | Publication d'événements vers des abonnés |
| Overhead réseau | Plus lourd dans les usages répétés | Plus léger pour les messages fréquents |
| Scalabilité | Bonne pour des requêtes ponctuelles | Très adaptée à de nombreux équipements |
| Simplicité de mise en œuvre | Simple pour consulter une ressource | Très simple pour diffuser un événement |
| Adéquation au temps réel | Moins naturelle sans mécanismes additionnels | Très naturelle pour les alertes et états |
Le bon découpage dans une architecture vidéo
MQTT ne remplace pas HTTP. Il le complète. Les flux vidéo peuvent très bien rester servis via des mécanismes classiques comme RTSP ou HTTP, pendant que MQTT orchestre les états, les alarmes et les notifications. Cette séparation évite de forcer un protocole à faire ce pour quoi il n'a pas été pensé.
Dans un projet de supervision, ce découpage est souvent plus lisible pour l'intégrateur comme pour l'exploitant. La vidéo transporte l'image, MQTT transporte l'événement, et chacun reste dans son rôle.
Cas d'usage concrets en vidéoprotection et supervision
Le vrai intérêt de MQTT apparaît quand la théorie devient une réaction visible sur le terrain. Une caméra publie une alerte, le NVR la reçoit, et le système de supervision agit immédiatement au lieu d'attendre qu'un opérateur vienne interroger l'équipement.
Intrusion, enregistrement et notification
Prenons un site d'entrepôt. Une caméra détecte une présence hors horaire et publie l'événement sur un topic d'alerte. Le NVR s'abonne à ce topic, déclenche l'enregistrement prioritaire et relaie ensuite l'information vers l'application de supervision. Le gardien n'a pas besoin de rafraîchir un tableau de bord, l'alerte lui parvient dans la chaîne d'événements.
Cette logique est particulièrement cohérente avec des caméras de type Full Color dotées d'analyse embarquée. L'événement n'est pas seulement une image, c'est une donnée exploitable par d'autres systèmes. Dans un parking ou un site industriel, le gain opérationnel se situe là, dans la capacité à réagir sans attendre une action manuelle.
Télémétrie des NVR et santé des équipements
Les NVR assemblés en France dans l'écosystème Vizeo peuvent aussi publier leur état, comme la température, l'espace disque ou le statut des disques, sur des topics dédiés. Un superviseur central récupère alors la santé de plusieurs sites dans une vue unique, sans interroger chaque appareil séparément.
C'est aussi utile pour les alarmes techniques. Une perte réseau, une coupure électrique ou un défaut caméra peut remonter comme un événement structuré, lisible par un tableau de bord ou une application métier. Le système gagne en homogénéité, parce que les événements techniques et les événements vidéo suivent la même logique de transport.
Un socle pour les scénarios intelligents
Les scénarios PAI utilisés dans certaines architectures de vidéoprotection prennent ici tout leur sens. Une détection n'a de valeur que si elle peut déclencher une suite d'actions compréhensible par le système de supervision. MQTT donne cette colonne vertébrale événementielle.
Pour des déploiements orientés stationnement, le contexte de Vizeo pour les parkings illustre bien l'intérêt d'un protocole capable d'aligner caméra, alarme et supervision autour d'événements partagés.
Recommandations pratiques pour intégrer MQTT chez Vizeo
Un déploiement propre commence par une discipline simple. Choisissez un broker adapté au niveau de maturité du projet, structurez vos topics de manière lisible, puis décidez quel message mérite un traitement prioritaire et lequel peut rester léger.
Une checklist de mise en œuvre
- Choisir le broker avec pragmatisme : Mosquitto convient bien pour démarrer, EMQX prend davantage de sens quand l'architecture doit monter en charge.
- Nommer les topics clairement : une logique du type
site/equipement/type/evenementfacilite la maintenance et les droits d'accès. - Activer TLS systématiquement : surtout dès que le système ne reste plus strictement confiné.
- Adapter le QoS à la criticité : les alertes ne se traitent pas comme les simples états périodiques.
- Prévoir la persistance pour les alarmes : un événement important ne doit pas disparaître à la première coupure.
Côté intégration Vizeo
Dans un projet Vizeo, la logique MQTT s'inscrit naturellement entre les équipements terrain, les NVR et la suite logicielle. Les remontées d'état et d'événements peuvent alimenter une supervision centralisée, tandis que les choix d'hébergement et de conformité s'alignent avec une exploitation pensée pour l'Europe et le RGPD. Pour les équipes qui veulent cadrer l'architecture matérielle et logicielle, la page produits Vizeo sert de point d'entrée utile.
L'intérêt de cette brique va au-delà de la simple remontée d'alertes. Dans la logique de R&D, elle prépare aussi des usages plus riches, comme la recherche descriptive par prompt, où un événement MQTT peut aider à retrouver plus vite un extrait vidéo pertinent.
Décision utile : si votre projet doit faire parler caméra, NVR et supervision sans multiplier les consultations manuelles, MQTT mérite d'être pensé dès la conception, pas ajouté en fin de chantier.
Vizeo accompagne les projets de vidéoprotection avec des caméras, des NVR assemblés en France, des logiciels de supervision et un appui technique de l'étude à la mise en service. Si vous voulez structurer un déploiement où les événements remontent proprement en MQTT, visitez Vizeo et voyez comment relier vos équipements, vos alertes et votre supervision dans une architecture claire.