- Méthodes pratiques pour importer des données MQTT dans Excel : scripts dans PythonExportation avec MQTT Explorer et flux de données dans Azure IoT.
- Contrôle total du pipeline avec sources, transformations et destinations, y compris la persistance et les schémas.
- Exporter au format CSV ou JSON et rediriger vers stockage dans le cloud sans perte de messages ni de structure.
- Il résout les problèmes d'exportation courants : formats, données incomplètes et volumes importants.
Si vous travaillez avec des objets connectés et devez transférer des données de télémétrie vers un tableur, vous vous demandez sans doute comment convertir efficacement les messages MQTT en fichier Excel. Heureusement, plusieurs solutions performantes existent : des scripts Python légers aux outils graphiques, en passant par des pipelines industriels dans le cloud . Je vais vous expliquer ici, en détail et sans détour, les différentes options qui s’offrent à vous et dans quels cas chacune est la plus adaptée.
Quel que soit votre niveau d'expérience, même si vous débutez, vous pouvez opter pour des solutions allant du simple « plug and export » aux architectures avec sources, transformations et destinations. Je vous présenterai des méthodes pratiques (avec Python et MQTT Explorer) et comment exploiter les flux de données Azure IoT à mesure que votre projet évolue , ainsi que des conseils utiles , les problèmes courants et leurs solutions.
Pourquoi importer des données MQTT dans Excel, et quelle est la solution la plus adaptée dans chaque cas ?
Dans un contexte personnel ou de laboratoire, un simple script suffit ; pour les tests et le débogage, une interface graphique comme MQTT Explorer vous sort d’affaire en quelques secondes ; et si votre entreprise a besoin de flux stables avec filtrage, enrichissement et livraison garantie, alors un flux de données géré, tel qu’Azure IoT Operations, est recommandé.

Option 1 : Script Python qui exporte les données MQTT vers Excel (rapide et contrôlé)
Une solution légère et efficace consiste en un petit programme Python qui se connecte au courtier, s'abonne à un ou plusieurs sujets et enregistre les messages dans une feuille de calcul Excel. Cette approche est idéale lorsque l'on recherche la portabilité, l'absence de dépendances d'interface et un contrôle précis sur le contenu, la méthode et la quantité des données enregistrées, à l'instar des techniques d' exportation de la sortie d'un script.
Il existe un exemple public, mqtt2excel, qui illustre ce principe : vous choisissez le broker, le nom du fichier Excel et la quantité de données à stocker. Si vous ne spécifiez pas de quantité, le script capture un nombre limité de messages (par exemple, les 10 premiers reçus) . Si vous êtes abonné à deux fils de discussion et que neuf messages arrivent du premier et un du second, ce seront ces dix enregistrements qui seront ajoutés à la feuille de calcul.
Avant de l'utiliser, vous devez avoir installé Python et deux bibliothèques : une pour l'écriture dans Excel et une autre pour le client MQTT. La combinaison la plus courante est xlwt (pour les fichiers XLS) avec la bibliothèque MQTT Paho . Exemple d'installation :
pip install xlwt
pip install paho-mqtt
Une fois les dépendances installées, adaptez l'exemple à votre courtier, au nom du fichier et aux thèmes. Vous pouvez définir une limite d'enregistrements pour que le programme s'arrête automatiquement une fois la capture terminée . Voici un pseudo-exemple :
from MQTT2Excel import MQTT2Excel
broker = "BROKER_O_DIRECCION"
salida = "lecturas-demo.xls"
m2e = MQTT2Excel(broker, salida)
m2e.setRecordsNumber(50) # total de mensajes combinados de todos los temas
m2e.addTopics("TOPICO1")
# Si necesitas más temas:
# m2e.addTopics("TOPICO2")
m2e.start()
Lors de son exécution, ce programme exportera chaque message avec son horodatage. Une fois le nombre d'enregistrements spécifié atteint, il s'arrêtera et vous fournira un fichier prêt à être ouvert dans Excel . Si votre courtier exige un nom d'utilisateur et un mot de passe, ou une authentification TLS, vous pouvez facilement l'étendre en ajoutant quelques lignes.
Dépôt de référence : github.com/gsampallo/mqtt2excel . Bien qu’il s’agisse d’un exemple, il constitue une excellente base pour le personnaliser selon vos besoins.
Option 2 : Exporter avec MQTT Explorer au format CSV ou JSON (idéal pour le débogage et le partage)
MQTT Explorer est une application graphique très pratique pour visualiser, tester et comprendre vos messages MQTT. Elle permet de se connecter aux brokers, d'explorer l'arborescence des sujets, de publier des tests et de filtrer les données grâce à une interface simple . Pour Excel, sa principale fonctionnalité est l'exportation des données reçues vers des formats standards tels que CSV ou JSON.
Fonctionnalités clés à prendre en compte : gestion des connexions, exploration et abonnement aux sujets, publication, affichage structuré des données et filtres/recherches. En pratique, cet outil est extrêmement utile pour nettoyer les données et capturer des instantanés que vous pouvez ensuite ouvrir dans Excel ou votre outil d’analyse préféré.
Étapes habituelles pour exporter des données avec MQTT Explorer : connectez-vous au broker, accédez au sujet qui vous intéresse, choisissez l’option d’exportation et sélectionnez le format (CSV ou JSON). Vous pouvez appliquer des filtres par plage horaire, sujet ou contenu avant l’exportation, ce qui vous fera gagner du temps et des efforts par la suite.
À quoi sert généralement cette exportation ? Analyse hors ligne, archivage historique, intégration avec d’autres outils ou partage avec des collègues. Un fichier CSV exporté s’ouvre dans Excel en un seul clic, et un fichier JSON s’intègre facilement dans les pipelines ou les bases de données.
Cas d'utilisation courants lors de l'exportation MQTT
Les raisons les plus courantes pour extraire des messages vers des fichiers externes sont généralement les mêmes : analyse hors ligne, archivage, intégration avec d’autres systèmes, partage avec des tiers, débogage et documentation. C’est également un moyen rapide de migrer des données entre plateformes et d’effectuer des sauvegardes avant maintenance.
Des exemples concrets incluent : la création de rapports Excel avec graphiques et statistiques, le stockage de séries de données historiques à des fins d’audit, le chargement de fichiers JSON dans un lac de données ou votre base de données, ou encore l’envoi d’un fichier CSV à une personne n’ayant pas accès au courtier. Lors des tests, l’exportation d’un échantillon permet souvent de détecter les valeurs aberrantes et de vérifier que les données publiées et reçues sont correctes.
Option 3 : Flux de données dans Azure IoT Operations (lorsque le projet se développe)
Si votre organisation a besoin d'une solution plus robuste qu'un script ou une exportation ponctuelle, vous pouvez orchestrer des flux de données gérés dans Azure IoT Operations. Le principe est simple : définir un pipeline avec une source, des transformations optionnelles et une ou plusieurs destinations . L'ensemble est géré à l'aide de profils et de points de terminaison réutilisables.
Vous devez d'abord disposer d'une instance Azure IoT Operations et, si nécessaire, définir des profils de flux de données distincts pour répartir la charge (en évitant de concentrer trop de flux dans un seul). Outre les profils, vous aurez besoin de points de terminaison pour les sources et les destinations : MQTT local, Kafka, Event Hubs, OpenTelemetry ou un stockage tel que Data Lake ou Fabric OneLake.
La création ou la mise à jour d'un flux peut s'effectuer via l'interface de ligne de commande Azure (Azure CLI), Bicep ou les manifestes Kubernetes. Par exemple, avec Azure CLI, vous appliquez un fichier JSON contenant les propriétés du flux, en spécifiant le mode, les opérations, ainsi que les paramètres de source, de transformation et de destination. Cette flexibilité vous permet de versionner la configuration et d'automatiser les déploiements.
Origines : MQTT ou Kafka, filtres thématiques et abonnements partagés
Une source de données est définie par une référence à un point de connexion et une liste de sources de données. En MQTT, vous pouvez utiliser des filtres de sujets avec des caractères génériques (+ et #), tandis qu'en Kafka, vous devez lister statiquement chaque sujet. Ceci est pratique car vous pouvez réutiliser le même point de terminaison dans plusieurs flux, simplement en modifiant les sujets à écouter.
Concernant les abonnements partagés avec les serveurs de messagerie MQTT : si le profil de flux comporte plusieurs instances, le préfixe `$shared` est automatiquement activé et la charge est répartie entre les consommateurs. Il n’est pas nécessaire d’ajouter `$shared` manuellement, sauf si vous souhaitez l’activer ; en général, il est préférable de laisser la plateforme gérer cela.
Si vous utilisez une « ressource » comme source, le schéma est déduit de sa définition et les données transitent toujours par le courtier MQTT local sous-jacent. Notez la règle de fonctionnement : si le point de terminaison par défaut de l’agent MQTT n’est pas utilisé comme source, il doit être utilisé comme destination.
Concernant le « schéma source », il sert actuellement à afficher les données dans l’interface, mais pas à valider ni à désérialiser les messages d’entrée. Il contribue à la clarté de l’interface utilisateur, même si le typage effectif est effectué lors de la sérialisation si cette option est configurée.
Transformations : enrichir, filtrer, mapper et créer de nouvelles propriétés
Les transformations sont facultatives ; si vous n’avez rien à modifier, vous pouvez les omettre. Leur utilisation se déroule en plusieurs phases : enrichissement, filtrage et enfin mappage/renommage/création de nouvelles propriétés. L’enrichissement consiste à effectuer un croisement avec un jeu de données de référence stocké dans l’état de la plateforme (par exemple, ajouter la localisation et le fabricant à partir d’un identifiant).
Lors du filtrage, vous appliquez des conditions aux champs sources afin de ne conserver que les données nécessaires. Lors du mappage, vous pouvez déplacer des champs, convertir des types, calculer des dérivées (par exemple, la température en degrés Celsius), et également renommer des points de données ou ajouter de nouvelles propriétés pour les étapes ultérieures.
Pour sérialiser des données de manière fiable avant de les envoyer à destination, il est nécessaire de définir un schéma et un format de sérialisation. Pour les solutions de stockage telles que Microsoft Fabric ou Azure Data Lake, l'utilisation de Parquet ou Delta avec un schéma explicite est recommandée afin de garantir la cohérence et l'efficacité des requêtes.
Détail pratique : vous pouvez accéder aux métadonnées MQTT dans les formules, telles que les propriétés du sujet ou de l’utilisateur, en utilisant une syntaxe spécifique (par exemple, @$metadata.topic). Cette flexibilité vous permet de router et de transformer non seulement par charge utile, mais aussi par informations d’en-tête.
Persistance du disque pour éviter la perte de messages lors du redémarrage
Lorsque la continuité est essentielle, vous pouvez demander la persistance sur disque (MQTT v5) afin que l'état soit restauré en cas de redémarrage du broker ou du flux. Ceci est possible lorsque le flux utilise l'agent/broker MQTT comme source et que la persistance est activée sur le broker, avec le mode dynamique activé pour les files d'attente d'abonnés.
En activant cette option pour chaque flux, seules les canalisations qui en ont besoin consomment des ressources de persistance. Cela évite les pertes lors des coupures de courant ou des redémarrages et maintient des performances optimales pour les autres.
Destinations : d’un thème MQTT vers un lac de données, ADX ou un stockage local
La destination est configurée avec un point de terminaison et une liste de « dataDestinations ». Dans MQTT ou Event Grid, il s’agit d’un sujet ; dans Kafka/Event Hubs, d’un sujet/hub ; dans Data Lake, d’un conteneur ; dans Azure Data Explorer, d’une table ; et dans le stockage local, d’un dossier. Ce concept permet de réutiliser le même point de connexion pour plusieurs flux, en modifiant uniquement la destination de chaque donnée.
Pour MQTT, vous disposez également de « sujets de destination dynamiques » avec des variables telles que ${inputTopic} ou ${inputTopic.index}, qui vous permettent de construire le sujet de sortie à partir de segments du sujet d'entrée. Remarque : si une variable ne peut être résolue (parce que le segment est manquant), le message est ignoré et un avertissement est consigné ; les caractères génériques ne sont pas autorisés dans les destinations.
Exemple de logique de flux et de vérification de pipeline
Imaginez un flux qui lit un sujet MQTT, l'enrichit de données de géolocalisation, convertit une mesure en degrés Fahrenheit et filtre les valeurs aberrantes. Il transmet ensuite ces données à un sujet « usine/… » construit dynamiquement, en utilisant le deuxième segment du sujet d'entrée . Cette topologie est parfaitement adaptée aux environnements industriels comportant de multiples lignes de production et capteurs.
Pour vérifier le bon fonctionnement d'un flux de bout en bout, une méthode éprouvée consiste à configurer un pont MQTT bidirectionnel vers un bus (par exemple, Event Grid) et à vérifier que les messages arrivent bien et respectent le schéma, les filtres et les mappages. La vérification à l'aide de messages synthétiques et d'un exemple d'exportation facilite la validation du format et des champs.
Exporter la configuration et automatiser les déploiements (CLI, Bicep, Kubernetes)
Vous pouvez gérer ces flux à la fois depuis l'interface d'opérations et depuis l'infrastructure en tant que code. Avec l'interface de ligne de commande (CLI), vous appliquez une configuration JSON ; avec Bicep, vous définissez des ressources imbriquées (profil, flux de données, références de points de terminaison) ; et avec Kubernetes, vous décrivez une définition de ressource personnalisée (CRD) avec la spécification des opérations. Cette approche déclarative vous permet de versionner les modifications et de faire évoluer votre infrastructure sans avoir à effectuer de modifications manuelles fragiles.
Dans Bicep, par exemple, vous référencez l'instance IoT Operations, l'emplacement personnalisé et le profil par défaut, puis vous créez la ressource « dataflow » avec les opérations Source, BuiltInTransformation et Destination. Ce même processus se traduit en YAML dans Kubernetes, en pointant vers la référence de profil appropriée dans l'espace de noms de la solution.
Problèmes courants lors de l'exportation et comment les surmonter
Lorsque vous utilisez des outils comme MQTT Explorer, l'option d'exportation peut ne pas apparaître ou être inactive. Mettez à jour votre application, vérifiez votre connexion et assurez-vous d'avoir sélectionné des données ou un thème spécifique avant de rechercher le bouton d'exportation.
Une autre erreur fréquente consiste à exporter dans un format incorrect ou avec des données incomplètes. Vérifiez vos paramètres d'exportation, vos filtres actifs et, si vous traitez des volumes importants, divisez l'exportation en périodes ou par sujet afin d'éviter les plantages.
Si le fichier exporté ne s'ouvre pas ou semble corrompu, essayez de l'ouvrir avec une autre application, relancez l'exportation et vérifiez l'espace disque disponible. Lorsqu'une application se bloque, son redémarrage ou sa réinstallation permet souvent de résoudre les problèmes de blocage temporaire.
Dans les pipelines gérés, surveillez la conformité entre le schéma et le format (Parquet/Delta) ainsi que l'existence de la destination (table, conteneur, dossier). Les problèmes de destination liés à des variables non résolues entraînent la suppression de messages ; il est donc conseillé de surveiller les avertissements.
Bonnes pratiques de sécurité et de confidentialité sur les plateformes
En entreprise, vous trouverez des écrans de consentement aux cookies et des paramètres de confidentialité, comme sur les sites web professionnels affichant des publicités ou des offres d'emploi. Avant d'accéder aux consoles ou aux applications intégrées , acceptez ou refusez les cookies non essentiels conformément à votre politique de confidentialité, et n'oubliez pas que vous pouvez modifier vos préférences ultérieurement.
Certaines applications d'entreprise (par exemple, les catalogues techniques ou les plateformes de connaissances) chargent des interfaces complexes nécessitant JavaScript et une authentification. Si vous voyez des messages du type « Chargement de l'application… », vérifiez les autorisations, les scripts activés et votre réseau d'entreprise ; il ne s'agit pas d'un problème de pipeline, mais d'un problème de couche web.
Contexte industriel : automates programmables et télémétrie en temps réel
Dans le secteur manufacturier, les automates programmables industriels (API) sont au cœur du contrôle des processus ; ce sont des ordinateurs industriels robustes qui pilotent les chaînes de montage, les robots ou tout processus exigeant fiabilité et diagnostic. De nombreuses installations modernes utilisent l’interface API → passerelle → MQTT pour exposer les mesures et les événements de manière standardisée.
Pour les analystes, la possibilité d'exporter un échantillon vers Excel est essentielle, que ce soit pour des audits, le contrôle qualité ou les enquêtes sur les incidents. C'est pourquoi trois niveaux coexistent : l'exportation ad hoc pour une analyse rapide, les scripts répétables pour les opérations de maintenance et les pipelines cloud pour un fonctionnement continu.
Conseils pour débuter avec votre propre appareil IoT
Si vous développez un appareil et devez transférer des données vers une feuille de calcul, commencez par l'essentiel : quel courtier utilisez-vous, quels sujets publiez-vous et à quelle fréquence les messages arrivent-ils ? Avec ces informations, le choix entre un script, une interface graphique ou un flux de travail géré sera beaucoup plus simple.
Pour un prototype initial, MQTT Explorer et l'exportation CSV vous donneront des résultats immédiats. Si vous souhaitez automatiser la collecte régulière de données, un script Python est une excellente solution. Enfin, si vous devez gérer la transformation, la gouvernance et plusieurs destinations, envisagez sérieusement un flux de données dans Azure IoT. De plus, si vous prévoyez d'analyser les données, apprenez à intégrer des données Excel à Power BI . À chaque étape, l'essentiel est de garantir la cohérence du format et d'éviter toute perte de messages lors des redémarrages.
Cette approche offre trois solutions éprouvées : la rapidité et la maîtrise de Python, la simplicité d’exportation avec MQTT Explorer et la puissance d’un pipeline Azure IoT avec des sources, des transformations (enrichissement, filtrage et mappage), une persistance et des destinations flexibles . Quel que soit votre point de départ, vous obtiendrez vos données MQTT dans Excel ou des formats compatibles, sans aucune difficulté, et avec des options d’adaptation à la taille de votre projet.
Sommaire
- 1 Pourquoi importer des données MQTT dans Excel, et quelle est la solution la plus adaptée dans chaque cas ?
- 2 Option 1 : Script Python qui exporte les données MQTT vers Excel (rapide et contrôlé)
- 3 Option 2 : Exporter avec MQTT Explorer au format CSV ou JSON (idéal pour le débogage et le partage)
- 4 Cas d'utilisation courants lors de l'exportation MQTT
- 5 Option 3 : Flux de données dans Azure IoT Operations (lorsque le projet se développe)
- 6 Origines : MQTT ou Kafka, filtres thématiques et abonnements partagés
- 7 Transformations : enrichir, filtrer, mapper et créer de nouvelles propriétés
- 8 Persistance du disque pour éviter la perte de messages lors du redémarrage
- 9 Destinations : d’un thème MQTT vers un lac de données, ADX ou un stockage local
- 10 Exemple de logique de flux et de vérification de pipeline
- 11 Exporter la configuration et automatiser les déploiements (CLI, Bicep, Kubernetes)
- 12 Problèmes courants lors de l'exportation et comment les surmonter
- 13 Bonnes pratiques de sécurité et de confidentialité sur les plateformes
- 14 Contexte industriel : automates programmables et télémétrie en temps réel
- 15 Conseils pour débuter avec votre propre appareil IoT