Le node Set (Edit Fields) dans n8n : transformer vos données sans écrire de code

Entre deux applications connectées par n8n, les données arrivent rarement dans le bon format : un CRM renvoie first_name, votre outil d'emailing attend prenom ; une API livre un prix en chaîne de caractères là où votre base exige un nombre ; un webhook déverse quarante champs dont vous n'en utilisez que cinq. Le node Set — renommé Edit Fields (Set) dans les versions récentes de n8n — est la brique conçue exactement pour ce travail de plomberie : renommer, créer, supprimer et typer des champs, item par item, sans écrire une ligne de code. C'est probablement le node de transformation que vous poserez le plus souvent sur votre canvas, juste devant le node Merge pour combiner des sources ou le node IF pour router selon une condition.

Deux modes : Manual Mapping et JSON output

Le node Set propose deux façons de définir sa sortie, sélectionnables dans le paramètre Mode :

• Manual Mapping — vous construisez la sortie champ par champ dans l'interface : pour chaque ligne, un nom de champ, un type et une valeur. La valeur peut être fixe (« Paris ») ou dynamique via une expression. C'est le mode le plus lisible, celui qui documente le mieux la transformation pour la personne qui reprendra le workflow.
• JSON — vous écrivez directement l'objet JSON de sortie complet, avec des expressions insérées où nécessaire :

{
  "prenom": "{{ $json.first_name }}",
  "email": "{{ $json.email.toLowerCase() }}",
  "source": "webhook-site"
}

Le mode JSON est plus rapide quand la structure cible est profonde ou déjà connue, et pratique pour coller un gabarit existant. En contrepartie, il ne bénéficie pas du typage explicite par champ du Manual Mapping : tout ce qui sort d'une expression garde le type que l'expression renvoie.

Ce choix entre construction visuelle et écriture directe n'est pas anecdotique. Une étude de Kandel, Paepcke, Hellerstein et Heer présentée à la conférence CHI en 2011 (« Wrangler: Interactive Visual Specification of Data Transformation Scripts » — voir sur Google Scholar) a montré qu'une interface visuelle de spécification des transformations de données réduit fortement le temps nécessaire par rapport à l'écriture manuelle de scripts équivalents. C'est exactement le pari du Manual Mapping : la plupart des transformations courantes se spécifient plus vite en cliquant qu'en codant.

Manual Mapping en pratique : drag & drop et expressions

En mode Manual Mapping, le panneau de gauche du node affiche les données d'entrée (vues Schema, Table ou JSON). Le geste le plus efficace est le drag & drop : glissez un champ depuis le panneau d'entrée vers la zone de valeur d'un champ de sortie, et n8n génère l'expression correspondante automatiquement — {{ $json.first_name }} par exemple. Vous pouvez ensuite l'enrichir à la main :

• {{ $json.first_name.trim() }} — nettoyer les espaces parasites ;
• {{ $json.first_name + ' ' + $json.last_name }} — concaténer deux champs en un ;
• {{ $json.price ?? 0 }} — fournir une valeur par défaut si le champ est absent ou nul ;
• {{ $now.toISO() }} — horodater le passage de l'item.

Tout ce que permettent les expressions n8n est utilisable ici : méthodes JavaScript sur les chaînes et les nombres, variables $json, $now, $itemIndex, données d'un node antérieur via $('Nom du node'). Pour aller plus loin sur cette syntaxe, notre guide des expressions JavaScript dans n8n détaille les cas avancés.

Typer les champs : string, number, boolean, array, object

Chaque champ défini en Manual Mapping porte un type : String, Number, Boolean, Array ou Object. Ce n'est pas décoratif — le node convertit la valeur vers le type demandé quand c'est possible. Un "42" reçu en chaîne devient le nombre 42 si le champ est typé Number ; un "true" devient le booléen true.

Ce typage évite une famille entière de bugs silencieux en aval : un node IF qui compare "10" > 9 en mode chaîne ne fera pas ce que vous croyez, une API qui exige un entier rejettera la chaîne, et un export vers Excel ou CSV alignera mal ses colonnes si les types varient d'un item à l'autre. Prenez le réflexe de typer explicitement dès le node Set, à l'entrée du workflow : tout ce qui suit devient prévisible.

Si la conversion est impossible (typer « abc » en Number), le node signale une erreur — comportement ajustable dans les options du node si vous préférez ignorer les conversions ratées plutôt que d'interrompre l'exécution.

Dot notation : manipuler des objets imbriqués sans code

Pour créer ou modifier un champ à l'intérieur d'un objet imbriqué, inutile de reconstruire l'objet entier : la dot notation dans le nom du champ suffit. Nommer un champ de sortie user.address.city avec la valeur Paris crée automatiquement les objets user et address s'ils n'existent pas, puis y place la valeur :

{
  "user": {
    "address": {
      "city": "Paris"
    }
  }
}

La même notation fonctionne en lecture dans les expressions — {{ $json.user.address.city }} — et pour les tableaux avec un index : {{ $json.items[0].sku }}. Pour aplatir un payload de webhook profondément imbriqué en une structure plate exploitable (le besoin classique après un Webhook trigger), quelques champs en dot notation remplacent avantageusement un script.

Include Other Input Fields : garder ou jeter le reste

Par défaut, le node Set ne laisse passer que les champs que vous avez définis : tout le reste de l'item d'entrée disparaît de la sortie. C'est voulu — le Set sert aussi de filtre pour ne garder que l'essentiel avant d'envoyer les données à une API ou à un modèle IA — mais c'est aussi la première cause de « champ disparu » chez les débutants.

L'option Include Other Input Fields inverse ce comportement : les champs non redéfinis sont recopiés tels quels en plus des vôtres. Trois variantes sont disponibles : inclure tous les autres champs, n'inclure que des champs listés (Selected), ou tout inclure sauf des champs listés (All Except). Cette dernière variante est la façon la plus simple de supprimer un ou deux champs sensibles (un token, un mot de passe) tout en conservant le reste intact.

Quand préférer un node Code

Le node Set travaille item par item : pour chaque item d'entrée, il produit un item de sortie transformé. Dès que la logique sort de ce cadre, le node Code devient plus adapté :

• Agrégations entre items — sommer un champ sur tous les items, dédupliquer, regrouper : le Set ne voit qu'un item à la fois.
• Tableaux de longueur variable — transformer chaque élément d'un tableau interne demande une boucle, donc du code (ou un passage par Loop Over Items après avoir éclaté le tableau).
• Logique conditionnelle riche — une expression ternaire dans un Set reste lisible ; trois ternaires imbriqués ne le sont plus.
• Restructurations profondes — renommer dynamiquement des clés, pivoter une structure, fusionner des objets arbitraires.

En pratique, les workflows propres combinent les deux : un ou plusieurs nodes Set pour normaliser et typer aux frontières (juste après un trigger, juste avant un envoi), et un node Code réservé aux transformations réellement algorithmiques. Notre article sur les expressions et le node Code aide à situer la frontière.

Pièges fréquents

• Oublier « Include Other Input Fields » et perdre des champs en silence. Le comportement par défaut ne garde que les champs définis ; si un node en aval cherche un champ « disparu », c'est presque toujours ici qu'il faut regarder.
• Laisser des nombres en chaînes de caractères. Un prix ou une quantité non typés Number produisent des comparaisons et des tris faux plus loin dans le workflow, souvent sans erreur visible.
• Reconstruire un objet imbriqué à la main alors que la dot notation dans le nom du champ (user.address.city) crée les niveaux intermédiaires automatiquement.
• Empiler la logique métier dans des expressions ternaires de plus en plus longues au lieu de basculer vers un node Code ou un node IF quand la condition devient structurante.
• Utiliser le mode JSON avec des valeurs non échappées. Une chaîne d'entrée contenant un guillemet ou un retour à la ligne peut casser le JSON produit ; en Manual Mapping, le problème ne se pose pas, chaque valeur étant gérée champ par champ.
• Multiplier les nodes Set successifs pour une même normalisation : un seul Set bien rempli reste plus lisible et plus rapide à maintenir que quatre Set en chaîne.

Pour aller plus loin

Le node Set est le cheval de trait discret de la plupart des workflows sérieux : dans le Pack Inbox IA (79 €), les workflows de tri d'emails l'utilisent intensivement pour normaliser les données extraites des messages (expéditeur, objet, catégorie, priorité) avant classification et routage — c'est ce qui garantit que chaque node en aval reçoit une structure stable et typée. Pour compléter votre boîte à outils de manipulation de données, voyez comment combiner plusieurs sources avec le node Merge et comment générer des fichiers Excel ou CSV à partir de données fraîchement normalisées par un Set.