n8n : 4 astuces pour bien démarrer un workflow

Pourquoi ces astuces changent tout

n8n a un énorme avantage : on peut construire un workflow fonctionnel en quelques minutes, sans écrire une ligne de code. C'est aussi son plus grand piège — un workflow qui "marche" au premier essai peut devenir illisible et impossible à déboguer trois mois plus tard, une fois qu'il gère 15 nœuds et plusieurs branches conditionnelles.

Ces 4 astuces sont celles qui, avec l'expérience de plusieurs workflows en production (inscriptions automatisées, chatbot Emii connecté à Claude et Google Sheets, notifications email + webhook en parallèle), évitent le plus de temps perdu en debug.

1. Nommer chaque nœud clairement, dès le départ

Par défaut, n8n nomme les nœuds selon leur type : HTTP Request, HTTP Request1, Set1, IF... Sur un workflow de 3 nœuds, ce n'est pas grave. Sur un workflow de 20 nœuds avec plusieurs branches, c'est un cauchemar de navigation — impossible de savoir ce que fait HTTP Request3 sans cliquer dessus.

La règle : renomme chaque nœud avec un verbe d'action + son objet, en double-cliquant sur son titre.

2. Toujours passer par un nœud Set en entrée

Un déclencheur (Webhook, formulaire, trigger planifié) reçoit souvent des données brutes, mal nommées, ou avec une structure imprévisible selon la source. Le réflexe à prendre : immédiatement après le déclencheur, ajouter un nœud Edit Fields (Set) qui reformate proprement les données dont tu auras besoin.

Webhook (données brutes)
↓
Set — "Normaliser les champs"
↓
[reste du workflow, données propres et prévisibles]

Sans ce nœud intermédiaire, chaque nœud suivant référence directement les champs bruts du webhook — souvent via des expressions comme {{ $json.body.data.user.email }}. Si la source change sa structure (un webhook tiers qui évolue, un formulaire qui ajoute un champ), il faut retrouver et corriger chaque occurrence dans le workflow.

Avec un nœud Set en entrée, un seul endroit à corriger :

email: {{ $json.body.data.user.email }}
nom: {{ $json.body.data.user.firstName }} {{ $json.body.data.user.lastName }}
dateInscription: {{ $now.toISO() }}

Tout le reste du workflow référence ensuite simplement {{ $json.email }}, {{ $json.nom }} — lisible, stable, et centralisé.

3. Gérer les erreurs avec Promise.allSettled en tête

Dès qu'un workflow déclenche plusieurs actions indépendantes — envoyer un email ET notifier un webhook, par exemple — la question à se poser avant même de construire le workflow : si l'une des deux actions échoue, l'autre doit-elle quand même s'exécuter ?

Dans la plupart des cas, la réponse est oui. Un email qui échoue à partir ne doit pas empêcher l'enregistrement de l'inscription dans Google Sheets, et inversement. C'est exactement la logique de Promise.allSettled côté code — chaque action est indépendante, aucune ne bloque les autres.

Concrètement dans n8n : connecte plusieurs nœuds à la même sortie du nœud précédent (au lieu de les chaîner les uns aux autres), et active l'option "Continue On Fail" dans les paramètres de chaque nœud critique. Ça reproduit exactement le comportement de Promise.allSettled — chaque branche vit sa vie, sans dépendre du succès des autres.

4. Tester avec des données réelles, pas des exemples fictifs

n8n permet d'exécuter un workflow manuellement avec des données de test saisies à la main ({"email": "test@test.com"}). C'est pratique pour valider rapidement la structure, mais insuffisant pour détecter les vrais bugs — ceux qui apparaissent avec des données réelles : accents, apostrophes, champs vides, emails avec des + (nicolas+test@nicaux.com), noms composés avec espaces.

Les cas qui cassent le plus souvent un workflow qui semblait fonctionner :

En résumé

Ces quatre habitudes ne demandent que quelques minutes de plus à la création d'un workflow — mais elles évitent des heures de debug le jour où ce workflow tourne en production depuis plusieurs mois et qu'il faut y toucher sans tout casser.