Fallback IA dans n8n : basculer automatiquement entre OpenAI, Anthropic et Mistral

Un digest d’emails qui ne part jamais un lundi matin parce qu’OpenAI a un incident. Un chatbot RAG client-facing qui reste muet pendant vingt minutes suite à une saturation de rate limit. Un workflow de scoring de leads qui échoue silencieusement toute la nuit parce qu’une clé API a expiré. Dans les trois cas, le problème n’est pas le modèle IA choisi — c’est l’absence d’alternative quand ce modèle, pour une raison ou une autre, ne répond plus. Un workflow n8n entièrement dépendant d’un seul fournisseur IA a un point de défaillance unique, et n8n dispose justement des briques nécessaires pour le supprimer.

Pourquoi un seul fournisseur IA est un point de défaillance unique

Les pannes des API OpenAI, Anthropic ou Mistral ne sont pas des événements rarissimes : elles se comptent en heures cumulées chaque trimestre sur les statuts publics des fournisseurs, sans compter les dégradations partielles (latence multipliée par dix, taux d’erreur 5xx en hausse) qui n’apparaissent même pas sur ces pages de statut. Une étude fondatrice de la fiabilité des systèmes en production, celle de Jim Gray chez Tandem Computers (1985), montrait déjà que l’essentiel des interruptions de service provient du logiciel et de l’administration plutôt que du matériel — et que la parade la plus efficace reste la redondance active, pas l’espoir que l’incident ne se produise pas. Le principe n’a pas vieilli : pour une API tierce que vous ne contrôlez pas, la seule protection réaliste est d’avoir un second chemin déjà câblé avant que le premier ne tombe.

Notre guide sur les rate limits OpenAI et Anthropic traite le cas où le fournisseur répond mais trop lentement pour votre volume — la solution y est le cadencement (Loop Over Items, Wait). Le fallback multi-fournisseurs traite un cas différent et complémentaire : celui où le fournisseur ne répond pas du tout, ou pas dans un délai acceptable, quel que soit le cadencement appliqué.

Le réglage n8n qui rend le fallback possible

Tout se joue dans l’onglet Settings du nœud IA concerné (OpenAI, Anthropic, ou tout nœud HTTP Request appelant une API IA), sur le paramètre On Error. Par défaut, il est réglé sur Stop Workflow : la moindre erreur interrompt toute l’exécution. En le passant sur Continue Using Error Output, le nœud gagne une seconde sortie, activée uniquement en cas d’échec, que vous pouvez relier à un nœud de secours plutôt qu’à rien.

C’est cette seconde sortie qui remplace le classique « le workflow plante » par « le workflow bascule ». Elle se combine naturellement avec un Error Workflow dédié qui capture les échecs définitifs pour alerte — le fallback absorbe les pannes récupérables, l’Error Workflow journalise celles qui ne le sont pas.

Construire une chaîne de secours à trois niveaux

L’architecture la plus robuste enchaîne plusieurs fournisseurs plutôt qu’un simple duo :

1. Nœud principal — le fournisseur habituel (souvent OpenAI ou Anthropic, voir nos guides pour connecter Claude ou GPT à n8n), avec On Error réglé sur Continue Using Error Output.
2. Nœud de secours n°1 — un second fournisseur indépendant, par exemple Mistral ou Gemini : une panne d’infrastructure chez un fournisseur n’a statistiquement aucune raison de coïncider avec celle d’un concurrent.
3. Nœud de secours n°2 (optionnel) — un modèle Ollama auto-hébergé comme filet de sécurité ultime : plus limité en qualité, mais indépendant de toute API tierce et donc insensible à une panne réseau généralisée côté cloud.
4. Un nœud Merge en mode « append » ou un simple aiguillage régule ensuite les trois chemins possibles vers la suite du workflow, qui ne voit qu’une seule sortie normalisée.

Chaque niveau reprend le On Error du précédent : le nœud de secours n°1 a lui-même sa sortie d’erreur reliée au nœud de secours n°2, formant une cascade plutôt qu’un aiguillage à deux branches seulement.

Distinguer erreur transitoire et panne du fournisseur

Toutes les erreurs ne méritent pas de changer de fournisseur. Un 429 isolé se résorbe souvent avec le cadencement décrit dans notre article sur les rate limits ou avec Retry On Fail réglé sur 2-3 tentatives et un Wait Between Tries de quelques secondes — inutile de basculer vers un modèle moins bien testé pour un simple pic ponctuel. Le fallback vers un autre fournisseur devient pertinent après l’épuisement des tentatives locales, ou immédiatement sur une erreur 5xx / timeout qui signale une vraie indisponibilité côté fournisseur plutôt qu’un simple ralentissement.

Harmoniser les réponses entre fournisseurs

Le piège le plus fréquent d’un fallback mal conçu : chaque fournisseur renvoie un format légèrement différent (structure JSON, nom des champs, tendance à ajouter du texte autour d’une réponse structurée). Si votre workflow attend un JSON précis pour remplir une table Supabase ou déclencher une action, une réponse de secours mal formée casse la suite silencieusement. La parade est d’imposer le même schéma de sortie aux deux fournisseurs, via un Structured Output Parser configuré identiquement sur les deux branches, ou à défaut un nœud Code de normalisation juste après le Merge qui ramène les deux formats à une structure commune avant de continuer.

Une cascade sert aussi à réduire les coûts

Le fallback n’a pas qu’une vertu défensive. Une étude de chercheurs de Stanford, Chen, Zaharia et Zou (2023) sur FrugalGPT, montre qu’une cascade de modèles — interroger d’abord un modèle économique, et n’escalader vers un modèle plus coûteux qu’en cas de réponse insuffisante — peut réduire le coût d’inférence jusqu’à 98 % tout en conservant une qualité comparable au modèle le plus cher utilisé seul. Le même mécanisme On Error qui sert de filet de sécurité en cas de panne peut donc aussi servir de logique d’escalade délibérée : un modèle économique en premier nœud, un modèle plus capable en secours, déclenché non seulement sur erreur technique mais aussi sur un score de confiance insuffisant renvoyé par le premier modèle. Notre article sur le suivi du coût des appels IA et le cache sémantique avec Redis complètent naturellement cette logique de maîtrise des coûts.

Industrialiser le pattern avec un sub-workflow

Dupliquer cette cascade de trois nœuds dans chaque workflow qui appelle un LLM devient vite ingérable dès qu’on en a plus de deux ou trois. La solution : l’extraire dans un sub-workflow réutilisable qui prend un prompt en entrée et renvoie une réponse normalisée, appelé via Execute Workflow depuis chaque workflow métier. Toute évolution de la chaîne de secours (ajout d’un fournisseur, changement de modèle) se fait alors à un seul endroit plutôt que dans chaque workflow qui consomme de l’IA.

Pièges fréquents

• Chemin de secours jamais testé : une clé API de secours qui a expiré depuis trois mois ne se découvre que le jour où on en a besoin — testez-le périodiquement en forçant une erreur sur le nœud principal.
• Prompts non synchronisés : un prompt affiné pour GPT-4o ne donne pas nécessairement les mêmes résultats tel quel sur Claude ou Mistral ; validez la qualité de sortie du fournisseur de secours, pas seulement sa disponibilité.
• Bascule silencieuse : sans notification (Slack, log Supabase) quand le fallback se déclenche, on découvre une dérive de coût ou de qualité des semaines plus tard.
• Fallback en cascade infinie : sans un dernier niveau qui échoue proprement vers l’Error Workflow, une panne généralisée simultanée de tous les fournisseurs peut faire tourner le workflow indéfiniment sans jamais aboutir.

Pour aller plus loin

Les workflows de classification et de brouillons du Pack Inbox IA (79 €) et le chatbot à citations du Pack Assistant RAG (119 €) reposent tous les deux sur un appel IA critique pour l’expérience utilisateur — exactement le type de nœud où ce pattern de fallback apporte le plus de valeur une fois en production sur un vrai volume. Si vous partez de zéro, nos guides pour connecter Claude/GPT, Mistral et Gemini couvrent la configuration initiale des credentials nécessaires à chaque branche de la cascade.