n8n, c'est LangChain avec un formulaire par-dessus

Un workflow n8n de quarante nœuds n'est pas simple. Il est illisible.

Personne ne le relit. Personne ne le teste. Et le jour où il casse en production, il n'y a rien à ouvrir — juste un canevas et un onglet d'exécutions dans lequel on cherche le nœud rouge.

Le réflexe reste pourtant compréhensible. Brancher un modèle de langage sur son application paraît lourd : un SDK à choisir, une boucle d'agent à écrire, des outils à décrire, des erreurs à gérer. L'interface visuelle paraît immédiate. C'était un arbitrage raisonnable.

Sauf qu'il repose sur deux prémisses qui ont changé cette année, et que presque personne n'a refait le calcul.

« L'interface m'évite la bibliothèque d'agents »

Elle est fausse, et le nommage du code le dit sans ambiguïté. Le paquet qui contient tous les nœuds IA de n8n s'appelle @n8n/n8n-nodes-langchain. Le nœud AI Agent, celui autour duquel tourne toute la documentation agentique, s'identifie littéralement comme n8n-nodes-langchain.agent.

Ses dépendances déclarées ne laissent pas plus de doute : langchain, @langchain/core, @langchain/langgraph, @langchain/langgraph-checkpoint, puis une vingtaine d'adaptateurs — Anthropic, OpenAI, Mistral, Ollama, Groq, Pinecone, Qdrant, Weaviate. Ce n'est pas un détail qu'on découvre en fouillant : la documentation de n8n a une section « LangChain in n8n ».

Le débat n'est pas interface visuelle contre bibliothèque d'agents. C'est interface au-dessus d'une bibliothèque, contre la bibliothèque directement.

Les deux camps utilisent une couche d'orchestration. La seule différence est le mode d'accès. Et cette différence coûte plus cher qu'elle ne rapporte, parce que la complexité conceptuelle ne disparaît pas : il faut toujours comprendre ce qu'est un agent, une chain, une memory, un retriever, un vector store. On les apprend simplement à travers des panneaux de configuration — sans types, sans la documentation de la bibliothèque sous-jacente, sans pouvoir lire ce qui s'exécute. On paie l'abstraction et le sous-jacent.

C'est précisément pour cela qu'un gros workflow devient incompréhensible. Non parce que le problème est complexe — il l'est souvent, légitimement. Mais parce que l'interface a retiré tous les outils qui servent à dompter la complexité : nommage, typage, factorisation, tests, revue de code.

« Écrire ce code coûte trop cher »

C'était l'argument fondateur du no-code, et il était juste. Mais n8n lui-même vient de le rendre caduc. Leur AI Workflow Builder génère un workflow complet — nœuds, logique, structure — à partir d'une description en langage naturel, puis le raffine par itérations. Chaque interaction consomme un crédit.

C'est un aveu très utile. Il signifie que n8n considère désormais que la bonne façon de construire un système agentique, c'est de le décrire à un agent de code et de laisser celui-ci produire l'artefact. Sur ce point : d'accord. C'est effectivement devenu la bonne façon de faire.

Si l'on accepte qu'un agent écrive le système, pourquoi lui faire produire du JSON de canevas plutôt que du code ?

Le débat n'est plus « visuel ou écrit à la main ». Les deux sont générés maintenant. Il porte sur une seule chose : ce que vous pouvez faire du résultat.

Ce que vous pouvez faire d'un résultat en code

Un JSON de workflow se relit mal, se teste par exécution manuelle, et ne se factorise pas. Une intégration en code dans votre application vous rend quatre choses.

• —Une surface d'API minuscule : un contrat d'outil bien conçu tient en quatre méthodes — un nom, une description, un schéma d'entrée, une exécution. C'est tout ce qu'un développeur doit apprendre pour exposer une capacité au modèle, à comparer avec la soixantaine de nœuds IA et leurs panneaux respectifs.
• —Un schéma garanti par le compilateur : dans un langage typé, le schéma JSON envoyé au modèle se dérive du type d'entrée de l'outil, donc description et code exécuté ne peuvent pas diverger. Dans une interface, on le saisit à la main — et la documentation de n8n admet le point faible : la qualité des descriptions d'outils détermine directement la fiabilité de l'agent.
• —Des prompts testables : un prompt est de la logique métier. Placé dans le domaine, à côté de ses tests, il se teste comme le reste du code — une entrée connue, une sortie attendue, une assertion qui casse la CI quand la sortie dérive.
• —Un vrai levier sur les coûts : derrière une interface commune, changer de fournisseur devient une variable d'environnement. Basculer vers DeepSeek, Mistral ou un endpoint OVH pour les tâches où la différence de qualité ne se voit pas relève de la configuration, pas de la migration.

À quoi s'ajoute la réutilisation. Une couche d'agents dans un dépôt sert plusieurs produits. Un workflow ne se factorise pas entre deux produits : il se duplique, et les deux copies divergent.

Ce que n8n fait vraiment bien

Un argumentaire honnête doit nommer les cas où l'autre camp gagne, et ils existent. Pour connecter six SaaS entre eux — un formulaire vers un CRM vers Slack vers une feuille de calcul — il n'y a pas plus rapide. Les centaines d'intégrations prêtes à l'emploi représentent un travail considérable que personne n'a envie de refaire. Webhooks, retries, ordonnancement, historique d'exécution : tout est là, sans rien installer.

Surtout, n8n ne vend pas de la qualité technique. Il vend de l'autonomie vis-à-vis d'une équipe de développement. Une personne aux opérations qui monte son automatisation seule un vendredi soir n'a pas de « meilleur résultat » possible en code — sans n8n, elle n'a aucun résultat. Ce n'est pas un argument technique, c'est un argument organisationnel, et il est solide.

Le problème n'est donc pas n8n. Le problème est le moment où l'on dépasse ce pour quoi il est bon.

Le plafond, et où il vous laisse

Tant que le besoin correspond à des nœuds existants, tout va bien. Dès qu'il en sort — une reprise sur erreur particulière, un enchaînement d'outils conditionnel, un format de sortie contraint — n8n vous rend la main. Concrètement, il vous renvoie vers le nœud Code, pour écrire du LangChain dans un champ texte de navigateur.

Sans compilateur. Sans tests. Sans autocomplétion ni navigation vers la définition. Sans revue de code, sans diff lisible, sans historique exploitable.

Le moment où l'interface cesse de payer est exactement celui où elle vous restitue le code, dans le pire environnement possible pour l'écrire.

Ce plafond arrive plus tôt qu'on ne l'imagine, parce qu'un système agentique qui atteint la production développe presque toujours ces besoins-là. Et pendant ce temps, le coût d'écrire cette couche proprement s'est effondré : les agents de code produisent ce type d'intégration bien plus vite qu'il y a dix-huit mois. C'est du code d'assemblage, avec un contrat clair et des types explicites — exactement ce que ces outils font le mieux.

Ce que ça change dans votre semaine

Plutôt que de passer vos soirées à comprendre pourquoi le nœud 34 ne reçoit pas le bon champ, mettez l'IA là où vit déjà votre métier : dans votre application, dans votre dépôt, dans votre pipeline.

Un agent de code écrit la plomberie — adaptateurs de fournisseurs, boucle d'outils, gestion des erreurs, nouvelles tentatives. Il vous reste ce qui a réellement de la valeur, et que personne ne peut écrire à votre place : les prompts, les outils que vous exposez, et les tests qui prouvent que l'ensemble fait ce que vous croyez.

Gardez n8n pour ce qu'il fait mieux que tout le monde : brancher des SaaS entre eux, vite, sans mobiliser un développeur. Mais votre produit n'est pas une intégration entre SaaS. Ne l'exportez pas dans un canevas.