Connecter MongoDB à n8n : le node natif, ses opérations et ses pièges

MongoDB s'est imposé comme la base de données de référence pour tout ce qui ne rentre pas proprement dans des lignes et des colonnes : catalogues produits aux attributs variables, réponses de formulaires hétérogènes, logs d'événements, contenus scrapés au format déjà JSON. C'est aussi la base derrière une bonne partie des applications SaaS modernes et des projets Node.js, ce qui en fait une cible fréquente pour n8n dès qu'il faut synchroniser, migrer ou interroger ces données depuis un workflow. Le node MongoDB de n8n couvre ce besoin nativement, avec une syntaxe de requête en JSON — proche du shell mongosh — assez différente du SQL des nodes Postgres et MySQL que nous avons déjà détaillés. Ce guide couvre la connexion, les sept opérations disponibles, le piège classique de l'ObjectId, et la protection contre l'injection NoSQL.

MongoDB face à Postgres et MySQL dans n8n : quand choisir quoi

Le choix ne se pose souvent pas : une base MongoDB existe déjà (une application Node.js, un SaaS tiers, un export JSON) et n8n vient s'y brancher, exactement comme pour notre guide du node MySQL. Mais pour un nouveau projet piloté depuis zéro, la question mérite d'être posée :

• Schéma stable et relationnel (clients, commandes, factures liées entre elles) → PostgreSQL reste le choix par défaut : jointures natives, contraintes d'intégrité, et l'écosystème pgvector si un usage RAG s'ajoute plus tard.
• Schéma variable ou imbriqué (chaque document a des champs différents, des tableaux de sous-objets, une structure qui évolue à chaque nouvelle source) → MongoDB évite l'alternative pénible entre une table hérissée de colonnes NULL et une cascade de tables de liaison pour représenter un JSON imbriqué.
• Un tiers impose déjà le format : API qui répond en JSON profondément imbriqué, export d'une app qui stocke en MongoDB nativement — répliquer cette structure telle quelle est souvent plus rapide que de la aplatir en colonnes.

Une étude de Li et Manoharan, A performance comparison of SQL and NoSQL databases, publiée aux actes du IEEE PACRIM 2013 (Google Scholar), a comparé lecture, écriture, suppression et instanciation sur plusieurs bases SQL et NoSQL : le résultat principal est qu'aucune des deux familles ne domine systématiquement — la performance dépend de l'opération et du moteur précis testé, pas d'une supériorité générique du modèle document sur le modèle relationnel (ou l'inverse). Le critère de choix pertinent reste la forme des données, pas une promesse de vitesse.

Se connecter : connection string ou valeurs séparées

Le credential MongoDB de n8n propose deux modes de configuration :

• Connection String — le format le plus courant avec MongoDB Atlas : collez directement l'URI fournie par Atlas (mongodb+srv://utilisateur:motdepasse@cluster.mongodb.net/?retryWrites=true&w=majority). C'est le mode recommandé dès que le cluster utilise le protocole mongodb+srv://, qui encode la découverte des nœuds du replica set.
• Values — hôte, port (27017 par défaut), base, utilisateur et mot de passe saisis séparément. Utile pour un serveur MongoDB auto-hébergé en Docker ou sur un VPS, sans le DNS géré par Atlas.

Avec MongoDB Atlas, deux étapes précèdent la connexion depuis n8n : ajouter l'adresse IP de votre instance n8n à la liste blanche réseau du cluster (Network Access), et créer un utilisateur de base de données avec les droits nécessaires (Database Access) — un compte Atlas de connexion n'est pas automatiquement un utilisateur de base de données. Le cluster gratuit M0 suffit largement pour tester un workflow avant de passer à un niveau payant.

En Docker local, comme pour Postgres et MySQL, l'hôte à renseigner dans le credential est le nom du service Docker (mongo ou mongodb selon votre docker-compose.yml), jamais localhost, qui désignerait le conteneur n8n lui-même.

Les sept opérations du node MongoDB

Le node expose une palette plus large que ses cousins SQL, reflet du modèle document :

• Find — recherche des documents selon un filtre JSON, avec tri, projection (champs à retourner) et pagination.
• Insert — ajoute un ou plusieurs documents à une collection.
• Update — modifie les documents correspondant à un filtre, en utilisant les opérateurs MongoDB ($set, $inc, $push…) plutôt qu'un simple remplacement de valeur.
• Delete — supprime les documents correspondant à un filtre.
• FindOneAndUpdate — trouve un document et le met à jour en une seule opération atomique, avec l'option de retourner le document avant ou après modification.
• FindOneAndReplace — trouve un document et remplace entièrement son contenu, plutôt que de fusionner des champs.
• Aggregate — exécute un pipeline d'agrégation MongoDB complet ($match, $group, $lookup, $project…), l'équivalent des jointures et des GROUP BY du monde SQL.

À cela s'ajoutent, dans les versions récentes, des opérations de gestion des index de recherche Atlas (créer, lister, mettre à jour, supprimer un index) — pertinentes uniquement si votre cluster utilise Atlas Search, sans équivalent sur une installation MongoDB générique.

Contrairement au node Postgres, il n'existe pas d'opération « Upsert » dédiée : ce comportement s'obtient via Update ou FindOneAndUpdate en activant l'option Upsert, qui insère un nouveau document si aucun ne correspond au filtre.

Écrire le filtre : la syntaxe JSON du champ Query

C'est le principal changement de posture pour qui vient de Postgres ou MySQL : là où ces nodes proposent des champs structurés (colonne, opérateur, valeur), le node MongoDB attend directement un objet JSON dans le style du shell mongosh :

{
  "statut": "en_attente",
  "montant": { "$gte": 100 },
  "creeLe": { "$gte": { "$date": "2026-08-01T00:00:00Z" } }
}

Ce format se prête bien aux expressions n8n injectées dans les valeurs ({{ $json.statut }}), mais impose de connaître les opérateurs MongoDB ($gte, $in, $exists, $regex…) plutôt qu'un simple SQL WHERE. Pour l'agrégation, le champ Pipeline attend un tableau JSON d'étapes, exactement comme un pipeline db.collection.aggregate([...]) copié depuis mongosh ou Compass — un bon réflexe est d'ailleurs de prototyper le pipeline dans Compass avant de le coller dans n8n, plutôt que de le construire à l'aveugle dans le node.

Le piège classique : l'ObjectId

Le champ _id de MongoDB n'est pas une chaîne de caractères mais un type binaire spécifique, l'ObjectId. Une erreur fréquente consiste à filtrer avec {"_id": "{{ $json.id }}"} : la comparaison échoue silencieusement, sans erreur, et ne retourne simplement aucun document, parce que MongoDB compare un ObjectId à une chaîne et ne trouve jamais de correspondance. La syntaxe correcte enveloppe la valeur avec l'extension JSON attendue par le driver :

{ "_id": { "$oid": "{{ $json.id }}" } }

Le même principe s'applique aux dates ({"$date": "..."}) et à d'autres types BSON qui n'ont pas d'équivalent JSON natif. Cette conversion oubliée est, avec la confusion entre Update (qui fusionne des champs via des opérateurs) et FindOneAndReplace (qui remplace tout le document), la source d'erreur la plus fréquente pour qui découvre ce node en venant du monde SQL.

Injection NoSQL : le risque existe aussi côté MongoDB

Le champ Query en JSON libre du node MongoDB pose le même problème de fond que le champ Execute Query d'un node SQL exposé à une entrée non fiable : une chaîne construite dynamiquement à partir d'une donnée externe (formulaire, webhook, sortie d'un LLM) peut injecter des opérateurs MongoDB inattendus plutôt qu'une simple valeur. Un article de référence sur le sujet, Ron, Shulman-Peleg & Bronshtein, No SQL, No Injection? Examining NoSQL Security (2015, arXiv — Google Scholar), documente comment des opérateurs comme $where (qui exécute du JavaScript côté serveur) ou $ne peuvent être injectés dans une requête MongoDB mal construite pour contourner un filtre d'authentification ou extraire des données hors périmètre.

La contre-mesure côté n8n : ne jamais construire le champ Query en concaténant une chaîne brute issue d'une entrée externe dans un objet JSON. Préférez injecter la valeur à l'intérieur d'une clé JSON déjà fixée par vous ({"email": "{{ $json.email }}"}) plutôt que de laisser une entrée externe fournir la structure même du filtre. Si un cas d'usage nécessite vraiment de construire dynamiquement les clés du filtre (recherche multi-critères depuis un formulaire, par exemple), validez et filtrez explicitement la liste des champs autorisés dans un node Code avant de composer l'objet JSON envoyé au node MongoDB.

Cas d'usage concrets avec n8n

• Synchroniser un catalogue produit hétérogène vers un site ou une marketplace : chaque produit a des attributs différents (taille, couleur, capacité, matière) qui rentrent naturellement dans un document MongoDB mais forceraient une table SQL vers un modèle EAV pénible. Un workflow planifié lit les documents modifiés depuis la dernière synchronisation (champ misAJourLe filtré en $gte) et pousse les changements vers l'API du site.
• Centraliser des logs d'événements applicatifs — webhooks reçus, exécutions d'agents IA, erreurs — dans une collection MongoDB plutôt qu'une table SQL rigide, puis interroger ces logs avec Aggregate pour produire un rapport de synthèse, sur le même principe que la piste d'audit RGPD décrite pour Supabase, adaptée à un stockage document quand le format des événements varie trop pour une table fixe.
• Alimenter un pipeline RAG depuis Atlas Search : MongoDB Atlas propose son propre moteur de recherche vectorielle, une alternative à Supabase/pgvector abordée dans notre guide RAG avec Supabase — pertinent si les documents sources vivent déjà dans MongoDB et qu'il n'y a pas de raison de les dupliquer ailleurs. Le Pack Assistant RAG (119 €) est bâti sur Supabase/pgvector, mais le même schéma d'ingestion (découpage, embeddings, recherche par similarité) se transpose au node Aggregate MongoDB avec l'opérateur $vectorSearch.

Check-list de mise en route

• Credential configuré en Connection String (Atlas) ou en Values (serveur auto-hébergé), avec l'IP de n8n whitelistée côté Atlas si applicable.
• Filtre JSON du champ Query testé sur un jeu de données de développement avant la production, avec les ObjectId et les dates correctement enveloppés ($oid, $date).
• Distinction claire entre Update (fusion via opérateurs) et FindOneAndReplace (remplacement complet) avant d'écrire dans une collection en production.
• Aucune entrée externe non filtrée ne compose directement la structure du filtre JSON envoyé au node.
• Pipeline Aggregate prototypé dans Compass ou mongosh avant d'être collé dans n8n.

MongoDB dans n8n demande un temps d'adaptation si votre réflexe est le SQL — la syntaxe JSON du filtre et la distinction entre les opérations de mise à jour n'ont pas d'équivalent direct dans les nodes Postgres ou MySQL. Mais pour des données dont la forme varie légitimement d'un enregistrement à l'autre, c'est souvent le chemin le plus court entre l'API d'un tiers et un workflow n8n qui fonctionne sans contorsion de schéma.