La résidence des données MQTT consiste à savoir, et à maîtriser, où vos messages IoT sont traités et stockés entre l'appareil et l'application. Cet article explique quelles parties d'un système MQTT manipulent des données, quelles questions réglementaires et contractuelles s'appliquent généralement, et comment le choix de la région et les déploiements bring-your-own-cloud vous aident à y répondre. Il s'agit d'un guide d'ingénierie pratique, pas d'un avis juridique : impliquez votre équipe juridique ou conformité dans les décisions.
Ce que signifie la résidence des données pour MQTT
La résidence des données est l'exigence selon laquelle certaines données doivent être stockées ou traitées dans une zone géographique précise, comme un pays ou l'Espace économique européen. Des termes voisins sont souvent employés de manière approximative :
- Résidence des données : l'endroit où les données se trouvent physiquement.
- Souveraineté des données : la juridiction dont les lois s'appliquent aux données.
- Localisation des données : une obligation légale imposant que les données restent dans un pays.
Un broker MQTT se trouve sur le chemin de chaque message. Même si votre base de données est dans le bon pays, un broker situé dans une autre région reçoit, traite et éventuellement stocke ces messages. Comprendre ce que fait un broker MQTT de vos données est le point de départ.
Où se trouvent les données dans un système MQTT
Recensez chaque endroit où un message peut exister, pas seulement votre base de données :
| Emplacement | Contenu | Question de résidence |
|---|---|---|
| Appareil | Mesures avant envoi, messages en mémoire tampon | Où les appareils sont-ils déployés ? |
| Chemin réseau | Messages en transit | Le trafic est-il chiffré en TLS de bout en bout jusqu'au broker ? |
| Mémoire du broker | Messages en cours de routage | Dans quelle région le broker tourne-t-il ? |
| Retained messages | Dernière valeur par topic | Stockés où, et pour combien de temps ? |
| Sessions persistantes | Messages en file pour les clients hors ligne | Stockés où, et quand expirent-ils ? |
| Logs du broker | Client IDs, adresses IP, parfois les topics | Les logs contiennent-ils des données personnelles, et où sont-ils conservés ? |
| Abonnés et backends | Tout ce qui est en aval | Où tournent vos services et vos bases de données ? |
Deux éléments passent facilement inaperçus. D'abord, les retained messages et les messages en file des sessions sont des données au repos sur le broker. Ensuite, les logs du broker peuvent contenir des adresses IP et des identifiants clients, qui peuvent constituer des données personnelles au sens de certaines réglementations.
Facteurs réglementaires et contractuels
RGPD et données personnelles
En vertu du Règlement général sur la protection des données de l'UE, les données personnelles ne peuvent être transférées hors de l'EEE qu'avec des garanties appropriées. Toutes les données IoT ne sont pas personnelles, mais beaucoup peuvent l'être : la position d'un traceur de véhicule, l'occupation d'un logement, la consommation d'énergie liée à un foyer ou les mesures de santé d'un objet connecté porté. Si un appareil peut être relié à une personne, sa télémétrie peut constituer une donnée personnelle.
Exigences sectorielles et des clients
Au-delà du droit de la vie privée, les exigences de résidence proviennent souvent de :
- Marchés publics qui imposent un hébergement dans le pays.
- Infrastructures critiques et services publics soumis à des règles de sécurité nationale.
- Clients du secteur de la santé et de la finance avec leurs propres politiques.
- Questionnaires d'achat des grandes entreprises demandant où tourne chaque sous-traitant.
Souvent, l'exigence la plus stricte n'est pas une loi, mais une clause d'un contrat client. Rassemblez ces exigences avant de choisir un modèle d'hébergement.
Réduire le risque de résidence dès la conception
Des choix d'ingénierie peuvent réduire le problème, quel que soit l'endroit où tourne le broker :
- Limitez les données personnelles dans les payloads. Envoyez des identifiants d'appareil, pas des noms ni des adresses. Résolvez les identités dans votre backend, dans la bonne région.
- Gardez les données personnelles hors des noms de topics. Les topics apparaissent dans les logs, les explorateurs et les outils de débogage.
- Utilisez TLS sur chaque connexion. Les ports 8883 et 8084 chiffrent les données en transit.
- Limitez les données au repos sur le broker. Utilisez l'expiration des messages de MQTT 5 et une expiration de session raisonnable, et évitez de conserver en retained des messages contenant des données personnelles.
- Traitez en périphérie. Agrégez ou anonymisez sur une passerelle avant de publier vers le cloud.
- Documentez le flux de données. Un schéma listant chaque composant et sa région répond à la plupart des questions des services achats.
Voici un exemple Python (paho-mqtt 2.x) qui publie une télémétrie pseudonymisée avec une expiration de message MQTT 5, de sorte que le broker la supprime si aucun abonné ne la récupère dans les dix minutes.
import json
import ssl
import time
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_start()
props = Properties(PacketTypes.PUBLISH)
props.MessageExpiryInterval = 600 # secondes
payload = {"device": "dev-4f9a", "kwh": 1.84, "ts": int(time.time())} # ni noms ni adresses
info = client.publish("site-07/meter/dev-4f9a/telemetry", json.dumps(payload),
qos=1, properties=props)
info.wait_for_publish()
client.loop_stop()
client.disconnect()
Les arbitrages du choix de région
Choisir la région du broker revient à équilibrer résidence, latence et praticité :
- Résidence : la région doit satisfaire vos exigences légales et contractuelles.
- Latence : les appareils et consommateurs éloignés du broker subissent des allers-retours plus longs ; voir la latence d'un broker MQTT selon la région.
- Co-localisation : placer le broker près de votre backend réduit les transferts de données entre régions.
- Flottes multi-régions : si vous vendez dans plusieurs juridictions, il vous faudra peut-être un broker par région, chaque appareil étant configuré pour son broker d'origine.
Ce dernier point a des conséquences sur l'architecture. Une flotte d'appareils répartie entre plusieurs régions implique généralement des brokers et des backends distincts par région, seules des données agrégées et non personnelles remontant vers une vue globale.
Conservation et suppression
Les questions de résidence s'accompagnent généralement de questions de conservation. Décidez combien de temps chaque type de donnée peut vivre à chaque étape : dans la mémoire tampon de l'appareil, sur le broker sous forme de retained messages ou de messages en file, dans les logs et dans vos bases de données. Rendez la suppression possible par appareil et par client, car le départ d'un client ou une demande d'effacement impose de supprimer les données partout où elles ont été copiées. Effacer un retained message est simple en MQTT : publiez un payload retained vide sur le même topic.
Comment le BYOC répond à la résidence
La meilleure réponse à « où sont nos données ? » est « dans notre propre compte cloud, dans une région que nous avons choisie ». C'est le modèle bring-your-own-cloud. Avec ConnectMQ BYOC, le broker tourne dans votre compte cloud et ConnectMQ le gère : vous décidez de la région, des frontières réseau et de la politique de journalisation, tout en évitant la charge opérationnelle de l'auto-hébergement. Les détails se trouvent dans notre article sur le broker MQTT BYOC.
Les autres plans ConnectMQ répondent à d'autres besoins. Les brokers Serverless sur le cluster mutualisé sont idéaux pour le développement, les pilotes et les données sans contrainte de résidence. Un plan Dedicated vous fournit un cluster isolé. Dans les deux cas, demandez à ConnectMQ où tourne l'infrastructure et intégrez la réponse à la documentation de votre flux de données. Les organisations qui doivent tout exploiter elles-mêmes peuvent envisager Self Managed Enterprise.
Quel que soit le plan, rien ne change côté client : MQTT 3.1.1 ou 5.0 sur TLS via le port 8883, ou Secure WebSocket sur le port 8084 avec le chemin /mqtt. Faire passer une flotte d'un modèle d'hébergement à un autre se résume à mettre à jour l'hôte et les identifiants.
Checklist de résidence avant le lancement
- Listez les juridictions où se trouvent les appareils, les utilisateurs et les clients.
- Classez les champs des payloads : personnels, pseudonymisés ou non personnels.
- Consignez la région du broker, de chaque abonné et de chaque base de données.
- Configurez l'expiration des messages, l'expiration des sessions et la politique des retained messages.
- Vérifiez que TLS est obligatoire pour tous les clients.
- Déterminez si le BYOC ou des brokers par région sont nécessaires.
- Gardez les données de test hors des brokers publics ; l'espace du serveur MQTT public gratuit est lisible par tous et ne convient qu'à des expériences non sensibles.
Démarrer avec ConnectMQ
Commencez à construire sur le plan Serverless gratuit sur app.connectmq.com, sans carte bancaire, avec des données de test non personnelles. Lorsque vos exigences de résidence se précisent, parlez avec ConnectMQ des déploiements Dedicated ou BYOC. Pour une vue d'ensemble des modèles d'hébergement, lisez le guide du broker MQTT cloud et la présentation du broker MQTT managé.
Questions fréquentes
La résidence des données MQTT ne concerne-t-elle que les données stockées ?
Non. Dans de nombreuses politiques, le traitement compte aussi, et un broker traite chaque message. Les retained messages, les sessions en file et les logs sont également des données au repos sur le broker.
La télémétrie IoT est-elle une donnée personnelle au sens du RGPD ?
Elle peut l'être si elle se rapporte à une personne identifiable, comme une position ou la consommation d'énergie d'un foyer. Demandez à votre délégué à la protection des données de classer vos payloads.
En quoi le BYOC aide-t-il pour la résidence des données ?
Le broker tourne dans votre propre compte cloud, dans une région que vous choisissez, selon vos politiques, tandis que le fournisseur l'exploite.
Puis-je utiliser un seul broker pour des appareils situés dans plusieurs pays ?
Techniquement oui, mais si chaque pays impose des règles de résidence, il vous faudra peut-être un broker par région, chaque appareil étant affecté à son broker d'origine.
