Node-RED vs n8n pour les workflows IoT : support MQTT, déploiement et cas d'usage

La question Node-RED vs n8n se pose dès qu'une équipe veut de l'automatisation low-code et doit relier à la fois des appareils et des systèmes métier. Les deux outils permettent de câbler des nœuds sur un canevas, les deux savent s'abonner et publier en MQTT, et les deux peuvent être auto-hébergés ; pourtant, ils ont été conçus pour des tâches différentes. Ce comparatif explique les différences de modèle d'exécution, de support MQTT, de licence et de déploiement, et se termine par un schéma hybride qui confie à chaque outil le travail qu'il fait le mieux.

La différence fondamentale : flux de messages contre exécutions de workflows

Node-RED est un processus de longue durée qui fait circuler des messages entre les nœuds, en mémoire. Un message arrive sur un nœud mqtt in, traverse une fonction, un switch et un nœud mqtt out, puis disparaît. Il n'y a aucune comptabilité par message. Node-RED est donc très à l'aise avec les flux continus : un capteur qui remonte une mesure chaque seconde, une passerelle automate qui publie des centaines de tags, un tableau de bord mis à jour en direct. Créé chez IBM pour câbler l'IoT, c'est aujourd'hui un projet de l'OpenJS Foundation sous licence Apache 2.0.

n8n est une plateforme d'automatisation de workflows. Chaque déclencheur lance une exécution : un passage distinct du workflow dont l'entrée, la sortie et le statut peuvent être stockés et inspectés plus tard. Ce modèle est excellent pour les processus métier du type « nouveau formulaire, enrichir le contact, créer une fiche CRM, poster dans Slack », car chaque exécution est traçable et peut être relancée. Il est moins naturel pour la télémétrie à haute fréquence, où transformer chaque message MQTT en exécution enregistrée ajoute de la surcharge et remplit le journal d'exécutions. n8n est distribué sous sa Sustainable Use License, une licence fair-code qui autorise l'auto-hébergement gratuit pour un usage interne mais restreint certains usages commerciaux ; il est aussi proposé en service cloud hébergé.

Aucun modèle n'est meilleur dans l'absolu. Ils sont optimisés pour des formes de travail différentes.

Comparatif des fonctionnalités Node-RED vs n8n

Le support MQTT en détail

Pour l'IoT, c'est le support MQTT qui tranche la plupart des comparaisons.

Node-RED traite MQTT comme un citoyen de première classe. Le nœud de configuration du broker prend en charge MQTT 3.1.1 et 5, TLS avec CA personnalisées, certificats client, Last Will, sessions propres ou persistantes, ainsi que les propriétés MQTT 5 comme l'expiration des messages, le response topic et les user properties. Le nœud mqtt in gère les wildcards + et #, les abonnements dynamiques via des messages de contrôle et le parsing automatique des payloads JSON. Le tutoriel Node-RED MQTT passe tout cela en revue.

n8n comprend un nœud MQTT pour publier des messages et un nœud MQTT Trigger qui lance un workflow quand un message arrive sur un topic auquel il est abonné. Cela couvre les cas d'usage essentiels : réagir à un événement d'appareil ou envoyer une commande à la fin d'un processus métier. Il ne cherche pas à être un moteur de traitement de flux : vous voudrez donc généralement placer devant lui quelque chose qui transforme la télémétrie brute en événements significatifs et peu fréquents.

Les deux outils se connectent à tout broker conforme aux standards. Pointé vers un serveur MQTT public gratuit comme broker.connectmq.com sur le port 1883 avec un client ID unique, l'un comme l'autre fonctionne en une minute.

Déploiement et exploitation

En pratique, Node-RED tourne souvent en edge, au plus près des machines, tandis que n8n tourne de façon centralisée, à côté des systèmes métier avec lesquels il dialogue.

Quand choisir Node-RED

• Vous traitez des données continues de capteurs ou de machines et avez besoin de filtrage, d'agrégation ou de conversion d'unités.
• Vous avez besoin de protocoles industriels comme Modbus ou OPC UA en plus de MQTT.
• Le workflow doit tourner sur un appareil edge ou une passerelle capable de fonctionner hors ligne.
• Vous voulez un tableau de bord local pour les opérateurs.
• Une licence open source permissive compte pour vous.

Quand choisir n8n

• Le workflow concerne surtout des outils SaaS : CRM, ticketing, tableurs, messagerie, e-mailing.
• Vous avez besoin d'un historique auditable de chaque exécution, avec relances.
• Des non-développeurs côté métier maintiendront le workflow.
• Les événements sont relativement peu fréquents : alarmes, lots terminés, demandes de maintenance.

Le schéma hybride : Node-RED en edge, n8n pour les événements métier

Les installations les plus robustes utilisent les deux. Node-RED consomme la télémétrie brute et publie des événements compacts ; n8n ne s'abonne qu'à ces événements et exécute les processus métier. Le broker MQTT est le contrat entre eux.

Devices --raw telemetry--> MQTT broker --> Node-RED (filter, aggregate, detect)
Node-RED --events--> MQTT broker --> n8n MQTT Trigger --> CRM / tickets / Slack / sheets
n8n --commands--> MQTT broker --> devices

Voici un nœud function Node-RED qui transforme des compteurs machine remontés chaque seconde en un événement utile à l'équipe toutes les cinq minutes, plus un événement immédiat quand une machine s'arrête :

// Input: connectmq/demo/n8x4w1/line1/press3/count, payload = total parts produced
const PREFIX = "connectmq/demo/n8x4w1/events";
const WINDOW_MS = 5 * 60 * 1000;

const count = Number(msg.payload);
if (isNaN(count)) return null;

const now = Date.now();
const s = context.get("s") || { start: now, first: count, last: count, lastChange: now, stopReported: false };
if (count !== s.last) {
    s.lastChange = now;
    s.stopReported = false;   // machine is producing again
}
s.last = count;

const out = [];

// Stop detection: no new parts for 3 minutes, report once
// (relies on the gateway publishing the counter every few seconds)
if (now - s.lastChange > 3 * 60 * 1000 && !s.stopReported) {
    s.stopReported = true;
    out.push({ topic: `${PREFIX}/press3/stopped`, payload: { since: new Date(s.lastChange).toISOString() } });
}

// Five-minute production summary
if (now - s.start >= WINDOW_MS) {
    // note: msg objects in "out" go to the single output one after another
    out.push({
        topic: `${PREFIX}/press3/summary`,
        payload: { parts: s.last - s.first, from: new Date(s.start).toISOString(), to: new Date(now).toISOString() }
    });
    s.start = now;
    s.first = s.last;
}

context.set("s", s);
return [out];

Reliez-le à un nœud mqtt out. Dans n8n, un nœud MQTT Trigger abonné à connectmq/demo/n8x4w1/events/+/stopped peut alors ouvrir un ticket de maintenance et prévenir le chef d'équipe, et un second workflow peut écrire les synthèses dans un tableur. n8n voit quelques messages par heure au lieu de milliers, ce qui garde son historique d'exécutions exploitable.

Testez le côté événements depuis un terminal pendant que vous construisez le workflow n8n :

mosquitto_pub -h broker.connectmq.com -p 1883 -i n8n-test-n8x4w1 \
  -t "connectmq/demo/n8x4w1/events/press3/stopped" -m '{"since":"2026-10-16T08:12:00Z"}'

Le même principe de traitement en edge apparaît dans nos guides sur les alertes e-mail Node-RED et Node-RED avec Home Assistant, et le guide du nœud function de Node-RED approfondit le contexte et les sorties multiples.

Le broker au milieu

Quelle que soit la combinaison retenue, les deux outils sont des clients, et aucun ne doit servir de système de référence pour les messages. Un broker fiable les découple : Node-RED peut être redéployé sans que n8n s'en aperçoive, et n8n peut être mis à jour sans que les appareils perdent leur connexion. ConnectMQ fournit cette couche sous la forme d'un broker MQTT managé avec MQTT 3.1.1 et 5, TLS sur le port 8883 et WebSocket sécurisé sur le port 8084. Il n'exécute pas de workflows et ne se connecte pas lui-même aux outils SaaS : c'est précisément le travail que vous confiez à Node-RED et à n8n, connectés comme des clients MQTT ordinaires avec leurs propres identifiants.

En production, donnez à chaque outil ses propres identifiants issus du portail (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID), utilisez le port 8883 avec TLS et le QoS 1 pour les topics d'événements, afin qu'une brève reconnexion ne fasse pas perdre un événement d'arrêt.

Connectez Node-RED et n8n à ConnectMQ

Inscrivez-vous sur app.connectmq.com à l'offre gratuite Serverless, sans carte bancaire, créez un broker et connectez Node-RED et n8n avec des identifiants distincts. L'explorateur de topics en direct du portail affiche côte à côte les topics bruts et les topics d'événements, ce qui permet de vérifier facilement que seuls les bons messages atteignent vos workflows métier.

Questions fréquentes

n8n peut-il remplacer Node-RED pour l'IoT ?

Pour des événements d'appareils peu fréquents, le MQTT Trigger de n8n fonctionne bien. Pour la télémétrie continue, le déploiement en edge, les tableaux de bord et les protocoles industriels, Node-RED est plus naturel.

n8n prend-il en charge MQTT ?

Oui. n8n dispose d'un nœud MQTT pour publier et d'un nœud MQTT Trigger pour s'abonner, et il peut se connecter à n'importe quel broker standard, y compris ConnectMQ, avec ou sans TLS.

n8n est-il open source comme Node-RED ?

Node-RED est open source sous licence Apache 2.0. n8n est source-available sous sa Sustainable Use License, qui autorise l'auto-hébergement gratuit pour un usage interne mais restreint certains usages commerciaux.

Node-RED et n8n doivent-ils communiquer directement ?

Il est plus propre de les relier via un broker MQTT. Node-RED publie des événements, n8n s'y abonne, et chacun peut être modifié ou redémarré sans casser l'autre.