Ressources · Intégration n8n

Nœud Stop and Error n8nConfigurer Stop and Error dans n8n.

Une exécution qui se termine en vert sur des données fausses coûte plus cher qu'une exécution qui plante. Le nœud Stop and Error n8n coupe le workflow à l'endroit exact où tu le poses et renvoie le message ou l'objet JSON que tu as écrit. Un seul paramètre, 2 types d'erreur, version 1 au catalogue.

Tester le nœud Stop and Error sur n8nVoir les 1 paramètres

Avis vérifiés sur Trustpilot · Agence IA, automatisation & growth

Pourquoi automatiser

À quoi sert le nœud Stop and Error n8n ?

Stop and Error fait échouer l'exécution en cours, pile là où tu l'as placé. Plutôt que de laisser le workflow aller au bout sur une donnée dont tu sais déjà qu'elle est mauvaise, le nœud renvoie une erreur que tu as rédigée toi-même, un message lisible ou un objet JSON, et l'exécution part en échec dans la liste. C'est un nœud core livré avec n8n : rien à installer, il est déjà dans le panneau.

Premier usage : faire remonter l'information à qui doit la traiter. Un flux se termine sur un appel qui a mal tourné plus haut, et avec l'option errorObject le nœud renvoie un objet structuré au lieu d'une phrase : le workflow qui réagit à l'échec peut en relire les propriétés une par une. La doc n8n décrit ce couple : le nœud Error Trigger lance un workflow d'erreur, et l'objet que tu as renvoyé voyage avec lui. Un code et une description suffisent à router l'alerte vers la bonne personne, sans qu'un humain ait besoin d'ouvrir l'exécution en échec pour comprendre ce qui s'est passé.

Deuxième usage : derrière un appel d'API. Un nœud HTTP Request renvoie une réponse techniquement valide mais inutilisable pour la suite, une liste vide là où un enregistrement était attendu. Avant d'écrire ce vide dans Google Sheets, Stop and Error transforme ce cas silencieux en échec visible, bien plus facile à repérer qu'un run terminé sans rien produire.

Troisième usage : le garde-fou. Un workflow démarre sur un Webhook, c'est-à-dire une URL qu'un service extérieur appelle pour déposer des données dans n8n, et parfois ces données arrivent sans l'identifiant dont la suite a besoin. Un nœud If teste le champ, la branche fausse tombe dans Stop and Error, et le workflow s'arrête là plutôt que d'écrire une ligne à moitié vide trois nœuds plus loin.

Un autre nœud fait parfois mieux le travail. Switch gère plus de deux sorties et les laisse toutes vivre, utile quand la branche a encore une suite valable, contrairement à celle qui finit dans Stop and Error.

Les limites tiennent en trois lignes. Le nœud n'expose qu'un paramètre, donc il n'y a rien à régler au-delà de l'erreur que tu écris. Il s'exécute sur chaque item entrant et n'ouvre jamais un workflow tout seul : un Schedule Trigger, un Webhook ou le trigger d'un outil passe devant. Si tu en es encore à choisir la plateforme avant de câbler ta gestion d'erreur, l'Avis n8n traite le terrain autour de ce nœud.

Paramètres

Quel paramètre Stop and Error propose-t-il ?

Le nœud Stop and Error compte un paramètre. Pour chacun : le nœud tel que tu le configures dans n8n, ce que le paramètre change, et nos notes de terrain.

01

Error Type

errorType

Ce que tu vois dans n8n

Notes & cas d'usage

Error Type choisit le type d'erreur renvoyée, et ce choix change le champ affiché juste en dessous.

Paramètres clés

  • Error Type : deux options, errorMessage (Error Message) et errorObject (Error Object).
  • Error Message : requis avec la première option, une chaîne sur le modèle du placeholder An error occurred!, souvent composée depuis l'item entrant avec {{ $json.status }}.
  • Error Object : requis avec la seconde option, un objet JSON qui contient les propriétés de l'erreur, du type { "code": "404", "description": "The resource could not be fetched" }.
Cas d'usage
le message quand un humain lira l'échec dans la liste, l'objet quand un autre workflow doit trier les échecs par code.
Besoin d'aide

Besoin d'aide pour automatiser Stop and Error avec n8n ?

L'équipe te répond directement.

Chaque message est lu par une personne.

FAQ

Stop and Error dans n8n, les questions fréquentes

01Le nœud Stop and Error est-il inclus dans n8n Cloud et en auto-hébergé ?
Oui. Stop and Error est un nœud core livré avec n8n : aucune installation, aucun coût supplémentaire côté n8n. Il se comporte pareil sur n8n Cloud, l'offre hébergée par n8n, et sur une instance auto-hébergée montée avec Docker ou npm en Community Edition, sous licence Sustainable Use. Un workflow qui échoue volontairement d'un côté échoue de la même façon de l'autre, ce qui compte quand un projet démarre sur Cloud puis part sur ton propre serveur. Le catalogue donne le nœud en version 1, et rien n'est réservé à une offre payante.
02Faut-il configurer un compte ou une clé avant de s'en servir ?
Non, il n'y a rien à configurer côté compte. Le nœud n'a aucun credential, c'est-à-dire aucun jeu d'identifiants enregistré, et aucun sélecteur Authentication : pas de clé à coller, pas d'autorisation à valider avant le premier run. Ce dont il a besoin, c'est d'un déclencheur devant lui, parce qu'il n'ouvre pas un workflow : un Schedule Trigger, un Webhook ou le trigger d'un outil lance l'exécution, et Stop and Error se place plus loin dans la chaîne. Remplis le champ correspondant au type choisi, un champ requis laissé vide bloque le nœud.
03Quelles sont les limites du nœud Stop and Error n8n ?
Il fait échouer, et c'est tout son métier. Le nœud porte un seul paramètre avec 2 options, donc il n'y a plus rien à régler une fois le message ou l'objet écrit. Il s'exécute sur chaque item entrant, un lot qui arrive dessus échoue sur l'item en cours de traitement. Relire ce qui a cassé est un autre travail : c'est le nœud Error Trigger qui lance le workflow d'erreur destinataire de l'information renvoyée. Le catalogue s'arrête à la version 1, un workflow ancien affiche donc le même panneau court.
04Quand préférer Stop and Error à un simple nœud If ?
If aiguille, Stop and Error termine. Un nœud If envoie les items sur une branche vraie ou une branche fausse, les deux continuent de tourner et rien n'est marqué en échec. Stop and Error sert quand l'une de ces branches n'a plus de suite valable, par exemple un enregistrement arrivé sans l'identifiant que tous les nœuds suivants attendent. Dans les faits, les deux vont ensemble : If pose la question, Stop and Error tranche pour la mauvaise moitié, et Switch fait le même travail au-delà de deux sorties. À éviter là où un résultat vide est une fin normale.
05n8n ou Make pour gérer ce genre d'échec ?
Les deux dessinent la même logique visuelle, la question se joue donc rarement sur le canvas. n8n tourne sur ton propre serveur avec Docker ou npm, ou sur n8n Cloud. Make est hébergé uniquement, sans option d'auto-hébergement, et se facture à l'opération. Si les données qui traversent la branche en échec doivent rester sur une infrastructure que tu maîtrises, l'auto-hébergement tranche. Si le volume est faible et que gérer un serveur ne te dit rien, la version hébergée de l'un comme de l'autre fait le travail. Côté coût, compare les opérations consommées par un run dans Make à ce que te coûte un serveur ou un plan Cloud.
Hack'celeration Lab

Reçois nos tips intégration chaque semaine.

Pas de spam. Désinscription à tout moment.

Même plateforme

Autres docs utiles sur ce stack.

Voir toutes les intégrations