Brancher un LLM dans n8n : ce que le nœud IA ne fait pas à votre place

Ajouter un nœud OpenAI ou Anthropic dans un workflow n8n prend le même temps qu'ajouter un nœud HTTP : on glisse le bloc, on renseigne la clé API, on connecte l'entrée et la sortie. C'est justement ce qui trompe. Dans notre article sur la mise en production d'un LLM, on part d'un principe simple : un appel LLM est un composant non déterministe posé au milieu d'un pipeline déterministe. n8n ne le sait pas. Le nœud fait ce qu'on lui demande, ni plus ni moins ; le reste, comme pour n'importe quel workflow n8n qu'on veut fiable, c'est à celui qui construit de le brancher à côté.

Voici les quatre endroits où ça se joue concrètement, dans l'éditeur n8n.

Un nœud LLM n'est pas un nœud HTTP

Un nœud HTTP a un contrat simple : même entrée, même sortie, et un statut d'erreur explicite quand ça casse. Un nœud LLM n'a aucune de ces deux garanties. La même entrée peut produire deux formulations différentes d'une exécution à l'autre, et une sortie inexploitable (un JSON tronqué, un champ manquant, une catégorie inventée) revient très souvent avec un statut "succès", parce que l'appel API lui-même s'est bien déroulé. Le nœud a fait son travail ; c'est le contenu de la réponse qui est mauvais, pas l'appel.

Ça change ce qu'on peut déléguer aux mécanismes natifs de n8n, et ce qu'il faut vérifier soi-même juste après le nœud.

Retry on Fail ne voit pas une mauvaise sortie

Notre guide sur la gestion d'erreur n8n recommande d'activer Retry on Fail sur tout appel réseau. Sur un nœud LLM, c'est nécessaire mais très insuffisant : cette option ne se déclenche que si n8n considère le nœud en échec (timeout, erreur HTTP). Une sortie JSON mal formée ou incomplète, qui est la panne la plus fréquente sur un appel LLM, ne coche aucune de ces cases : le nœud reste vert, et le JSON cassé continue tranquillement sa route dans le workflow.

Le pattern qui fonctionne ajoute une étape de validation explicite juste après le nœud LLM :

1. Un nœud Code (ou un Structured Output Parser si le nœud IA le propose) qui tente de parser la sortie contre le schéma attendu.
2. Un nœud IF qui route vers la suite du workflow si la validation passe, et vers une branche de reprise sinon.
3. La branche de reprise renvoie l'entrée au nœud LLM, avec le message d'erreur de parsing ajouté au prompt, pour une nouvelle tentative.
4. Un compteur de boucle qui plafonne le nombre de reprises (deux ou trois), au-delà duquel l'exécution part directement en erreur.

Ce dernier point compte plus qu'il n'y paraît. Dans notre article sur la mise en production, les retries non plafonnés sont la première source de dérive de coût silencieuse : chaque reprise double l'appel qui a échoué, et sans plafond explicite, une instabilité de sortie sur un prompt peut multiplier la facture d'un workflow entier sans qu'aucune alerte ne se déclenche.

La sortie structurée se vérifie dans le workflow, pas seulement dans le prompt

Demander du JSON dans le prompt système ne garantit rien : c'est une instruction, pas une contrainte. Le nœud IA de n8n permet d'attacher un schéma de sortie structurée directement au nœud (via l'option native selon le fournisseur, ou un Structured Output Parser en aval) ; c'est ce schéma, pas le texte du prompt, qui doit porter la contrainte réelle.

Le même principe que dans l'article pilier s'applique ici tel quel : le schéma doit prévoir une valeur explicite pour l'incertitude ("non_déterminé" dans une énumération, un champ incertain: true), sinon le modèle est poussé à choisir la catégorie la plus plausible même quand aucune ne convient. Dans n8n, ce champ devient la condition d'un nœud Switch juste après la validation : les sorties confiantes continuent tout droit, les sorties marquées incertaines partent sur une branche différente. C'est un IF de plus dans le workflow, pas un changement d'architecture.

Où brancher l'humain, avec les nœuds qu'on a déjà

L'article pilier décrit trois régimes selon le coût d'une erreur et le volume traité : validation systématique, validation par échantillon, validation par exception. Les trois se construisent dans n8n avec les mêmes briques, sans nœud spécialisé à installer :

• Validation systématique : le workflow s'arrête sur un nœud d'attente (Wait, ou Wait for Webhook) après la branche IA, et ne reprend qu'une fois une approbation reçue, par exemple via un message Slack avec boutons d'action qui renvoie sur ce webhook.
• Validation par échantillon : un nœud Code tire un pourcentage aléatoire des exécutions et les redirige vers la même branche d'attente ; le reste continue directement.
• Validation par exception : c'est la branche du Switch construite à la section précédente, sur le champ d'incertitude. Seules les sorties marquées incertaines remontent vers un humain ; le reste part en production sans arrêt.

Le troisième régime est celui qu'on installe le plus souvent, parce qu'il ne ralentit pas le flux principal. Il repose entièrement sur la fiabilité du champ d'incertitude qui l'alimente : un signal jamais calibré contre des cas dont on connaît la bonne réponse ne protège rien, il donne juste l'impression qu'un filet existe.

Dans n8n, brancher l'humain ne demande pas de nœud exotique : un IF, un Wait, un message Slack avec des boutons. Ce qui manque presque toujours, ce n'est pas la brique technique, c'est la décision explicite de s'en servir avant le premier incident plutôt qu'après.

Logger l'appel complet, pas l'historique d'exécution par défaut

L'historique d'exécution de n8n donne l'impression d'un log déjà en place : chaque exécution y est visible, avec l'entrée et la sortie de chaque nœud. C'est trompeur pour un usage LLM. Cet historique obéit à une politique de rétention (souvent purgée après un nombre de jours ou d'exécutions, en particulier sur les exécutions réussies), et il n'est pas pensé pour être interrogé : impossible d'y chercher "toutes les sorties marquées incertaines de la semaine dernière" sans rouvrir les exécutions une par une.

Ce que demande l'article pilier (logger systématiquement l'entrée, la sortie, le modèle et sa version, les tokens, la latence, sur 100 % du trafic) se construit avec un nœud dédié après l'appel LLM, qui écrit ces champs dans une table à part, avec une politique de rétention choisie et non subie. C'est redondant avec l'historique natif, volontairement : l'historique sert à déboguer une exécution précise, la table sert à mesurer une dérive dans le temps.

Checklist avant de mettre un nœud LLM n8n en production

1. Un nœud de validation suit chaque appel LLM, avec une boucle de reprise plafonnée (deux à trois tentatives), pas un Retry on Fail seul.
2. Le schéma de sortie structurée du nœud prévoit une valeur explicite pour l'incertitude, exploitée par un Switch en aval.
3. Le régime de validation humaine (systématique, par échantillon, ou par exception) est choisi explicitement selon le coût d'erreur et le volume, pas laissé au comportement par défaut du workflow.
4. Un nœud dédié persiste entrée, sortie, modèle et tokens dans une table interrogeable, distincte de l'historique d'exécution natif.

En résumé

Le nœud IA de n8n rend l'appel à un LLM aussi simple qu'un nœud HTTP à poser, mais il ne résout aucun des problèmes qui rendent un LLM différent d'un appel API classique : ceux-là restent entièrement à la charge de celui qui construit le workflow, sous forme de quelques nœuds supplémentaires (validation, boucle plafonnée, Switch sur l'incertitude, persistance dédiée). Pour le cadre général sur ce qui casse entre la démo et la production, notre article sur la mise en production d'un LLM reste le point de départ ; pour le cadre général sur n8n, c'est notre bilan sur la fiabilité des workflows.