FlowKit

Basic LLM Chain vs AI Agent dans n8n : lequel choisir pour votre workflow

Publié le 1 août 2026 · 6 min de lecture

Dans la section IA de n8n, deux nodes semblent faire la même chose : le Basic LLM Chain et l'AI Agent prennent tous les deux un prompt, appellent un modèle de langage et renvoient une réponse. Choisir le mauvais des deux a pourtant des conséquences très concrètes : un agent utilisé là où une chain suffisait multiplie les appels LLM, la latence et la facture, tout en introduisant du non-déterminisme là où vous n'en vouliez pas. Ce guide pose les critères de décision, avec un tableau comparatif, des exemples de workflows pour chaque cas, et les nodes spécialisés qui remplacent souvent avantageusement l'agent. Si vous découvrez la palette IA de n8n, commencez par notre introduction aux nodes IA de n8n.

Deux nodes, deux philosophies

Les deux nodes reposent sur LangChain, mais leur mécanique interne n'a rien à voir.

Le Basic LLM Chain effectue exactement un appel au modèle : votre prompt entre, la réponse sort, le node passe la main au suivant. Pas d'outils, pas de mémoire, pas de boucle. Ses seules connexions latérales sont le modèle (obligatoire) et, en option, un output parser pour forcer un format de sortie. Un appel = un coût connu, une latence à peu près constante, un comportement reproductible d'une exécution à l'autre.

L'AI Agent exécute une boucle de raisonnement : le modèle lit la tâche, décide s'il a besoin d'un outil (requête HTTP, recherche vectorielle, calcul, sub-workflow…), reçoit le résultat de l'outil, raisonne à nouveau, et recommence jusqu'à estimer la tâche terminée — dans la limite du paramètre Max Iterations. Il accepte des outils, une mémoire de conversation et un output parser. Ce fonctionnement s'inscrit dans la lignée du paradigme ReAct formalisé par Shunyu Yao et ses co-auteurs dans « ReAct: Synergizing Reasoning and Acting in Language Models », publié à ICLR 2023 : alterner raisonnement et actions sur l'environnement améliore nettement les tâches qui exigent d'aller chercher de l'information.

Conséquence pratique : une exécution d'agent peut représenter un, trois ou dix appels LLM selon ce que le modèle décide. Coût et latence deviennent des variables, pas des constantes. Notre guide complet du node AI Agent détaille cette mécanique.

Tableau comparatif

Critère Basic LLM Chain AI Agent
Appels LLM par exécution Exactement 1 1 à N (boucle, plafonnée par Max Iterations)
Outils (HTTP, vector store, code…) Non Oui, entrée Tools dédiée
Mémoire de conversation Non Oui, en option
Coût par exécution Fixe et prévisible Variable, dépend du nombre d'itérations
Latence Celle d'un appel Cumulée sur toutes les itérations
Reproductibilité Élevée (même prompt, même structure) Plus faible (le chemin d'exécution varie)
Débogage Simple : un prompt, une réponse Plus complexe : inspecter chaque itération
Cas d'usage type Transformer un texte connu à l'avance Décider quoi faire et avec quels outils

Quand le Basic LLM Chain suffit

La règle empirique : si la tâche se décrit comme « prends ce texte, produis cette sortie », la chain suffit. Quelques workflows représentatifs :

  • Classification de messages entrants : un email arrive, la chain lui attribue une catégorie parmi une liste fermée, un node Switch route ensuite. Un appel, une réponse courte, coût minimal.
  • Extraction de champs : tirer nom, montant et date d'échéance d'un texte de facture ou d'un formulaire libre, en sortie JSON.
  • Réécriture et résumé : condenser un ticket en deux phrases pour une notification Slack, traduire une description produit.
  • Génération à partir d'un template : rédiger une réponse type à partir de variables déjà présentes dans l'item.

Exemple de configuration concrète — une chain de classification dont le prompt injecte les données de l'item courant :

Tu es un classificateur de demandes client.
Catégories autorisées : facturation, technique, commercial, autre.

Message à classer :
Sujet : {{ $json.subject }}
Corps : {{ $json.body }}

Réponds uniquement en JSON : {"categorie": "...", "urgence": "haute|normale|basse"}

Pour garantir une sortie JSON exploitable par les nodes suivants (et pas une phrase d'explication autour), activez l'option de format de sortie et branchez un parser — notre guide du Structured Output Parser montre comment définir le schéma et gérer les sorties invalides.

Le point décisif : dans tous ces cas, la séquence est connue à l'avance. Le modèle n'a aucune décision d'orchestration à prendre ; c'est votre workflow n8n qui orchestre, avec des nodes IF, Switch et Merge déterministes.

Quand l'AI Agent se justifie

L'agent devient pertinent quand la tâche exige des décisions prises à l'exécution :

  • Le chemin dépend du contenu : un assistant support qui, selon la question, doit chercher dans la documentation (vector store), consulter le statut d'une commande (API) ou escalader à un humain. Impossible de câbler toutes les branches à l'avance.
  • Des allers-retours avec des outils : vérifier une disponibilité, puis réserver, puis confirmer — chaque étape dépendant du résultat de la précédente. La création d'outils sur mesure est couverte dans notre guide des outils personnalisés pour l'AI Agent.
  • Une conversation suivie : un chatbot qui doit se souvenir des échanges précédents s'appuie sur l'entrée mémoire de l'agent, détaillée dans notre article sur la mémoire de conversation d'un agent IA.

Exemple : un webhook reçoit une question client, l'AI Agent dispose de trois outils (recherche documentaire, lecture du CRM, création de ticket) et choisit lui-même lesquels invoquer et dans quel ordre. Exactement le scénario qu'une chain ne peut pas couvrir.

Les nodes spécialisés : le juste milieu souvent oublié

Entre la chain brute et l'agent complet, n8n propose des nodes LangChain spécialisés qui encapsulent un cas d'usage précis avec un seul appel LLM et une sortie déjà structurée :

  • Text Classifier : catégorisation avec branches de sortie natives par catégorie — plus direct qu'une chain suivie d'un Switch. Voir notre guide du node Text Classifier.
  • Information Extractor : extraction de champs selon un schéma, avec validation intégrée — le remplaçant naturel d'un agent bricolé pour lire des documents. Voir notre guide du node Information Extractor.
  • Question & Answer Chain : réponse à une question sur la base d'un retriever (vector store), sans boucle d'agent — suffisant pour un RAG simple où la seule « action » est la recherche documentaire.

Beaucoup d'AI Agents en production n'exploitent qu'un seul outil, toujours le même : un node spécialisé ferait le même travail avec moins d'appels et moins de variance.

Les pièges classiques

  • Un agent pour une tâche à un seul appel : l'erreur la plus fréquente. L'agent ajoute un tour de raisonnement (voire plusieurs) autour d'une tâche que la chain règle en un appel — vous payez la boucle sans en tirer de valeur. Suivez vos dépenses par workflow avec notre méthode pour suivre le coût des appels IA dans n8n : le surcoût saute aux yeux.
  • Sous-estimer le non-déterminisme : le benchmark τ-bench de Yao, Shinn et Narasimhan (2024), qui évalue des agents LLM outillés sur des scénarios réalistes (réservation aérienne, e-commerce), introduit la métrique pass^k pour mesurer la constance sur plusieurs essais de la même tâche : la fiabilité chute nettement dès qu'on exige que l'agent réussisse à chaque tentative. En production, un agent qui « marche en test » peut donc échouer par intermittence sur la même entrée.
  • Pas de garde-fous sur la boucle : plafonnez Max Iterations, prévoyez le cas où l'agent n'aboutit pas, et consultez notre revue des erreurs courantes du node AI Agent avant la mise en production.
  • Déboguer l'agent comme une chain : une chain se teste en comparant prompt et réponse ; un agent exige d'inspecter chaque itération et chaque appel d'outil dans le journal d'exécution.

En résumé

Commencez toujours par la question : « la séquence d'étapes est-elle connue avant l'exécution ? ». Si oui, un Basic LLM Chain — ou mieux, un node spécialisé comme Text Classifier ou Information Extractor — fait le travail avec un coût fixe, une latence d'un seul appel et un comportement reproductible. Réservez l'AI Agent aux cas où le modèle doit réellement décider quoi faire : choix d'outils à l'exécution, allers-retours dépendants des résultats, conversation avec mémoire. Si vous hésitez encore, le budget tranche vite : une chain coûte un appel, un agent en coûte un nombre que vous ne découvrez qu'après coup.

FAQ

Questions fréquentes

Peut-on connecter des outils (tools) à un Basic LLM Chain dans n8n ?

Non. Le Basic LLM Chain n'accepte qu'un modèle et, en option, un output parser. Il effectue exactement un appel au LLM : prompt en entrée, réponse en sortie. Si votre cas d'usage exige que le modèle appelle une API, cherche dans une base ou déclenche une action, il faut passer au node AI Agent, qui expose une entrée Tools dédiée.

L'AI Agent donne-t-il de meilleures réponses que le Basic LLM Chain ?

Pas en soi : les deux nodes appellent le même modèle avec les mêmes capacités. L'agent n'est « meilleur » que si la tâche exige réellement plusieurs étapes ou des informations à aller chercher via des outils. Pour une tâche à un seul appel (résumé, classification, réécriture), la chain produit la même qualité, plus vite et pour moins cher.

Comment limiter le nombre d'itérations d'un AI Agent dans n8n ?

Dans les options du node AI Agent, le paramètre Max Iterations plafonne le nombre de tours de boucle raisonnement-outil (10 par défaut). C'est un garde-fou indispensable : sans lui, un agent qui tourne en rond peut multiplier les appels LLM, donc les coûts et la latence, avant d'échouer.

Peut-on remplacer un AI Agent par plusieurs Basic LLM Chains enchaînées ?

Souvent, oui. Si la séquence d'étapes est connue à l'avance (extraire, puis classer, puis rédiger), plusieurs chains reliées par des nodes n8n classiques donnent un pipeline déterministe, testable étape par étape et au coût prévisible. L'agent ne se justifie que lorsque l'ordre des étapes ou le choix des outils doit être décidé à l'exécution.

Bundle FlowKit Complet

269 €