Maîtrisez les expressions avancées et les transformations de données

Identifiez pourquoi vos expressions peuvent fragiliser un workflow

Dans le cours Prenez en main n8n, vous avez déjà utilisé des expressions pour rendre un workflow dynamique.

Le problème, c’est que les workflows « qui marchent » en test peuvent casser en production pour des raisons très simples :

• un champ attendu n’est pas présent (ex. un email vide) ;

• une donnée n’a pas le format attendu (ex. une date en texte) ;

• une valeur arrive avec une casse différente (ex."URGENT"vs"urgent") ;

• une liste est vide ou contient des éléments inattendus.

Dans ce chapitre, vous allez apprendre à écrire des expressions plus robustes et à regrouper vos transformations dans une étape dédiée, pour que votre workflow reste lisible et maintenable.

Imaginez : les tickets support arrivent de plusieurs canaux (formulaire web, email, API partenaire). Les mêmes informations portent parfois des noms différents (ex."urgence","priority","severity_level") et des formats différents. Votre objectif, ça va être de normaliser ces données pour obtenir un ticket « propre » avant de continuer le traitement.

Nommez vos nœuds et variables avec une convention lisible

Avant d’écrire des expressions avancées, une règle simple va vous faire gagner du temps : nommer vos nœuds et variables de manière adaptée et cohérente.

Si vous laissez des noms par défaut comme Set, Set2, IF1 et des champs comme field1, vous pouvez réussir à faire fonctionner le workflow… mais vous aurez du mal à :

• revenir dessus une semaine plus tard ;

• le faire relire ;

• le transmettre à quelqu’un d’autre (c’est l’objectif de la partie 2 de ce cours).

Voici une convention simple que vous pouvez appliquer dès maintenant :

Exemple : au lieu de produire un champpriority, vous pouvez produireout_priority(priorité normalisée), ce qui rend explicite que cette valeur est désormais fiable et prête à être utilisée par la suite du pipeline.

Définissez un contrat de données avant de transformer

Avant de transformer des données, prenez un moment pour définir un contrat de données.

Un contrat de données, c'est une mini-spécification que vous rédigez avant d'écrire vos transformations. Ce contrat décrit deux choses :

1. ce que vous acceptez en entrée : quels champs peuvent arriver, dans quels formats, avec quelles valeurs possibles ;

2. ce que vous garantissez en sortie : les champs qui seront toujours présents, leurs noms exacts, leurs formats et leurs valeurs autorisées.

Concrètement, c'est souvent une simple liste de champs avec leurs règles. L'idée c’est que tout ce qui suit dans le workflow peut s'appuyer sur ce contrat sans avoir à re-vérifier la forme des données.

Voici un exemple de contrat minimal :

• Entrée : la donnée peut être incomplète (champs absents), et venir de plusieurs canaux.

• Sortie : un ticket normalisé avec une structure stable (mêmes noms de champs, mêmes formats), et des valeurs par défaut quand c’est nécessaire.

Dans notre scénario de pipeline de tickets, vous pouvez viser par exemple ce ticket « propre » en sortie de votre étape de normalisation :

• out_source:"form"|"email"|"api_partner"

• out_customer_email: email (ounullsi absent)

• out_priority:"low"|"medium"|"high"

• out_subject: texte (jamais vide)

• out_message: texte

• out_created_at: date/heure normalisée (ou date par défaut si absente)

Parce que croyez moi, sans contrat clairement établit vous ne serez sûr de rien quand vous le reprendrez 6 mois plus tard.

Transformez les données courantes dans un nœud dédié

Dans n8n, vous pouvez techniquement « bricoler » des expressions un peu partout : dans une conditionIF, dans un champ du nœud Slack, dans une requête HTTP…

Mais plus vous dispersez la transformation, plus vous perdez :

• en lisibilité (vous devez ouvrir plusieurs nœuds pour comprendre) ;

• en débogage (vous ne savez plus où la donnée a été modifiée) ;

• en maintenance (une correction implique de chercher partout).

Voici des transformations très courantes dans un pipeline de tickets :

• Harmoniser du texte : harmoniser en minuscules, supprimer les espaces inutiles

• Renommer des champs : passer deurgence/priority/severity_levelàout_priority

• Convertir des types : texte → nombre ; texte → date

• Mettre en forme une date : produire un format unique

• Nettoyer une liste : enlever les vides, dédupliquer, limiter la longueur

Gérez les champs manquants sans bloquer le workflow

Quand des données viennent de sources différentes, il est normal qu’il manque des champs. L’objectif n’est pas d’avoir un workflow parfait mais d’avoir un workflow qui réagit correctement.

Vous avez principalement deux stratégies complémentaires :

1. Donner une valeur par défaut (fallback) quand l’absence est tolérable.

   Exemples : sujet vide →Ticket sans sujet, priorité absente →medium.

2. Créer une branche alternative quand l’absence doit arrêter (ou dégrader) le traitement.

   Exemple : pas d’email client → impossible d’enrichir via HubSpot → vous routez vers une brancheà traiter manuellement.

Dans vos expressions, adoptez ce réflexe : ne supposez pas qu’un champ existe. Prévoyez un plan B.

À vous de jouer !

Dans la série d'exercices qui va ponctuer le cours dans les sections "À vous de jouer !", nous allons volontairement changer de contexte pour vous permettre de mettre en pratique ce que vous apprenez.

On change donc de domaine, pour partir sur un projet n8n lié au monde agricole. C'est parti !

Consigne

Nous sommes dans un projet fictif nommé AgroTech. Dans un workflow, vous recevez trois exemples de relevés issus de trois types de capteurs :

1. Capteur Sol LoRaWAN (champ  alerta_gel  ,  notes  ,  sender_device  )

2. Station Météo Web (champ  risk_level  ,  title  ,  obs_text  ,  reporter  )

3. Sonde Humidité API (champ  severity  ,  log  ,  subject  )

Votre mission : créer une étape de normalisation (un nœud dédié) qui produit exactement la même structure en sortie, quel que soit le capteur source.

• out_source

• out_subject

• out_message

• out_device_email

• out_priority  (low / medium / high)

• out_created_at  (format unique)

Contraintes :

• Si le sujet est vide ou absent, remplacez-le par "Relevé sans sujet" ;

• Si la priorité/niveau de risque est absent, utilisez "medium" ;

• Si l’email/identifiant expéditeur est absent, mettez null(ne mettez pas une fausse valeur sous forme de texte).

Corrigé

Voici un exemple de ce que vous pouviez faire pour y arriver :

Description de la capture d'écran :

Le workflow est divisé en 3 étapes visuelles :

• Étape 1 (orange) : Données brutes : 3 nœuds ('When clicking Test workflow', 'Capteur Sol LoRaWAN', 'Station Météo Web', 'Sonde Humidité API') reliés entre eux.

• Étape 2 (marron) : Normalisation : 1 nœud ('Normalisation Relevés Agricoles') avec des paramètres en code (ex:tolowerCase()).

• Étape 3 (rouge) : Décision : 1 nœud conditionnel ('IF Alerte Gel') avec 2 branches ('Déclencher Arrosage Anti-Gel' et 'Abonnement Log Météo').Bouton 'Execute workflow' en bas à droite. Interface sombre avec menu latéral (Overview, Personal, etc.).

Capture d’écran du même workflow n8n après exécution réussie. Les 3 étapes sont visibles :

• Étape 1 : Nœuds exécutés avec succès (icônes vertes).

• Étape 2 : Nœud 'Normalisation Relevés Agricoles' marqué 'Success in 2ms'.

• Étape 3 : Nœud 'IF Alerte Gel' avec conditionout_priority == 'high'et branches exécutées ('Déclencher Arrosage Anti-Gel' et 'Abonnement Log Météo'). En bas : logs montrant 'Workflow executed successfully' et détails des nœuds (durée, statut). Bouton 'Execute workflow' grisé.

Capture d’écran des logs du workflow n8n. À gauche :

• Liste des nœuds exécutés avec leur statut (ex: 'When clicking Test workflow' en 125ms, 'Sonde Humidité API' en 174ms).

• Logs en texte brut (ex:Batterie faible sur le capteur).À droite :

• Onglet 'Output' ouvert pour le nœud 'Normalisation Relevés Agricoles', affichant un tableau de données avec colonnes :severity,device_id,subject,log,out_source,out_subject,out_message,out_priority, etc.

• Valeurs exemples :out_priority: high,out_message: Niveau d’humidité critique au secteur Nord.

Capture d’écran des paramètres du nœud 'Normalisation Relevés Agricoles' dans n8n.

• Onglet Parameters ouvert, mode 'Manual Mapping'.

• Champs configurés :

  • out_source: Code JavaScript pour normalisersender_deviceetdevice_id.

  • out_subject: Condition pour ajouter 'Relevé sans sujet' si le champ est vide.

  • out_message: Récupère les notes ou le texte brut du nœud.

  • out_device_email: Construit l’email du device (ex:sens-sol-01@farm.local).

• À droite : Aperçu des données Input (ex:alerta_gel: CRITIQUE) et Output (ex:out_priority: high).

Retrouvez rapidement la bonne expression

Voici les expressions n8n les plus utiles, classées par situation. Toutes s'utilisent entre doubles accolades{ }dans les champs dynamiques de n8n.

Accéder à une valeur

Définir une valeur par défaut

Manipuler du texte

Formater une date

Parcourir une liste

En résumé

• Dans un workflow “production-ready”, une expression doit être robuste : elle ne doit pas casser si un champ est absent ou mal formé.

• Donnez des noms explicites à vos nœuds et adoptez une convention (in_,tmp_,out_) pour rendre le pipeline lisible.

• Définissez un contrat de données : ce que vous acceptez en entrée et ce que vous garantissez en sortie.

• Regroupez les transformations dans un nœud dédié plutôt que de les disperser.

• Distinguez les champs critiques (branche alternative) des champs optionnels (valeur par défaut).

Dans le prochain chapitre, vous allez connecter une API via HTTP Request pour enrichir vos tickets avec des informations client.