Automatisation Niveau 3 : Architecte
14 / 45

Module 3 · Concevoir pour l'échecEnviron 1 min

Réessayer sans aggraver

Le réglage Retry On Fail d’un nœud n8n relance l’appel en cas d’échec. Ses bornes, vérifiées dans le code source d’n8n en octobre 2026 : Max Tries de 2 à 5 (3 par défaut), Wait Between Tries de 0 à 5 000 ms (1 000 par défaut), à intervalle fixe.

C’est parfait pour un raté réseau d’une seconde, insuffisant pour une API en maintenance pendant vingt minutes, et dangereux quand des centaines d’exécutions réessaient ensemble : elles frappent l’API au même instant, vague après vague. La bonne pratique est l'attente exponentielle avec gigue : doubler l’attente à chaque essai et y ajouter une part de hasard, pour désynchroniser les exécutions. Dans un nœud Code, en mode Run Once for Each Item :

javascript
// Attente avant le prochain essai : 30 s, 60 s, 120 s… plafonnée à 15 minutes,
// avec une gigue aléatoire pour que les exécutions ne réessaient pas toutes ensemble.
const essai = $json.essai ?? 1;
const base = 30;      // secondes
const plafond = 900;  // 15 minutes
const attente = Math.min(plafond, base * 2 ** (essai - 1));
const gigue = Math.random() * attente * 0.3;
return { json: { ...$json, essai: essai + 1, attenteSecondes: Math.round(attente + gigue) } };

Branchez ensuite un nœud Wait sur {{ $json.attenteSecondes }} secondes, puis l’appel, puis un If qui renvoie vers ce calcul tant que l’appel échoue et que essai reste sous votre maximum. Au-delà de 65 secondes d’attente, n8n range l’exécution en base au lieu d’occuper un processus.

Ne réessayez pas toutRéessayer un 400 ou un 401 ne sert à rien et consomme des appels. Et ne réessayez jamais une action qui crée, envoie ou paie sans la protection de la carte suivante.