Introduction

À ce stade du cours, vous maîtrisez le branchement avec les nœuds IF et Switch, la boucle avec le fractionnement d'items et le traitement par lots, la fusion de branches parallèles, et l'enveloppement des opérations à risque dans une gestion d'erreurs. Cette dernière leçon consiste à assembler tout cela dans un seul workflow qui reflète la façon dont les automatisations de production réelles sont construites.

L'objectif n'est pas d'introduire de nouveaux nœuds. L'objectif est de montrer comment ces patterns s'articulent — comment une boucle alimente une fusion, comment un gestionnaire d'erreurs enveloppe une boucle, et comment la logique de branchement détermine le chemin que prend un résultat fusionné ensuite. Le workflow que vous construisez ici est un modèle pratique que vous pouvez adapter à vos propres cas d'usage.

Le scénario : un workflow qui lit une liste de contacts depuis une API externe, enrichit chaque contact en appelant une seconde API, gère les échecs avec élégance, fusionne les résultats et envoie un rapport de synthèse par e-mail.

Étape 1 : Récupérer et fractionner les données d'entrée

Le workflow démarre avec un déclencheur planifié qui s'exécute tous les matins. Le premier nœud HTTP Request appelle votre API de contacts et renvoie un tableau d'objets contact. Comme n8n encapsule ce résultat dans un seul item par défaut, vous devez fractionner le tableau avant de boucler dessus.

Utilisez un nœud Code pour fractionner le tableau en items individuels que le reste du workflow pourra traiter un par un :

return $input.first().json.contacts.map(contact => ({ json: contact }));

C'est la fondation. Chaque nœud en aval reçoit désormais un contact par item, ce qui signifie que le traitement en boucle avec SplitInBatches ou les appels HTTP par item fonctionneront correctement.

Étape 2 : Enrichir chaque contact avec gestion d'erreurs

L'étape d'enrichissement appelle une API tierce pour chaque contact. Les API tierces échouent. Elles appliquent des rate limits, expirent et renvoient des formes inattendues. Encapsuler cet appel dans un pattern Try/Catch est non négociable pour la production.

Connectez votre nœud HTTP Request (l'appel d'enrichissement) à un Error Trigger limité à ce nœud. Le chemin de succès ajoute les données enrichies à l'item. Le chemin d'erreur ajoute une structure de secours pour que l'item ne soit jamais silencieusement perdu :

// On the error branch — Code node that normalizes the failed item
return [{
  json: {
    ...($input.first().json),
    enriched: false,
    enrichmentError: $input.first().json.error?.message ?? 'Unknown error'
  }
}];

Le chemin de succès et le chemin d'erreur doivent tous deux produire des items avec la même forme au niveau supérieur. C'est essentiel pour l'étape de fusion qui suit — si une branche renvoie des objets avec des clés différentes, les nœuds en aval deviennent fragiles.

Étape 3 : Fusionner et agréger les résultats

Après l'étape d'enrichissement (branches succès et erreur), un nœud Merge en mode Append rassemble tous les items dans un seul flux. À partir de là, un nœud Code agrège les résultats dans un objet de synthèse :

const items = $input.all();
const total = items.length;
const succeeded = items.filter(i => i.json.enriched !== false).length;
const failed = items.filter(i => i.json.enriched === false).length;

return [{
  json: {
    total,
    succeeded,
    failed,
    failureRate: (failed / total * 100).toFixed(1) + '%',
    items: items.map(i => i.json)
  }
}];

Ce nœud d'agrégation est la frontière entre le traitement par item et la logique au niveau du workflow. Tout ce qui le précède opère sur des contacts individuels. Tout ce qui le suit opère sur le lot dans son ensemble.

Étape 4 : Brancher selon le résultat

Chaque exécution ne devrait pas produire la même notification. Un taux d'échec de 0 % mérite un e-mail de succès épuré. Un taux d'échec de 100 % devrait alerter quelqu'un immédiatement. Un échec partiel se situe entre les deux.

Utilisez un nœud IF ou Switch pour router en fonction du taux d'échec :

// Switch node — Expression for routing
{{ $json.failed === 0 ? 'success' : $json.succeeded === 0 ? 'critical' : 'partial' }}

Chaque branche se connecte ensuite à un nœud de notification différent — e-mail pour le succès et le partiel, Slack ou PagerDuty pour le critique. C'est ici que le branchement et la fusion des leçons précédentes portent leurs fruits : vous avez construit la capacité à produire une synthèse propre en un seul item précisément pour que ce nœud Switch ait quelque chose de simple à évaluer.

Étape 5 : Envoyer le rapport

Chaque branche de notification formate son propre message. La branche succès envoie une courte confirmation. La branche partielle inclut la liste des contacts en échec pour qu'une personne puisse enquêter. La branche critique déclenche une alerte urgente avec tous les détails d'erreur.

Le nœud e-mail sur la branche partielle utilise une expression pour construire le corps dynamiquement :

// Code node before the email — builds the failure list
const failures = $json.items
  .filter(i => i.enriched === false)
  .map(i => `${i.email}: ${i.enrichmentError}`)
  .join('\n');

return [{ json: { ...$json, failureList: failures } }];

À ce stade, le workflow est terminé. Il dispose d'un déclencheur, d'un traitement par item avec gestion d'erreurs, d'une fusion de résultats, d'un branchement basé sur le résultat et de notifications ciblées.

Résumé

Un workflow prêt pour la production n'est pas un workflow qui gère bien le chemin nominal — c'est un workflow qui gère l'échec sans perdre de données, qui branche sans dupliquer la logique, et qui rend compte de sa propre santé. Les patterns que vous avez appliqués ici — fractionner avant la boucle, normaliser les branches d'erreur, agréger avant le branchement, brancher selon le résultat — sont les briques réutilisables pour à peu près toute automatisation que vous construirez dans n8n. Utilisez ce workflow comme modèle de référence et adaptez les étapes à vos propres sources de données, API et canaux de notification.