n8n Assistant : ce que l’été 2026 a réellement changé

n8n a beaucoup parlé de son Assistant au début de septembre. Pris isolément, le billet peut donner l’impression d’une nouveauté fraîchement lancée. En réalité, l’histoire commence plusieurs mois plus tôt : le produit est apparu en preview le 9 juillet 2026, puis a été modifié presque en continu pendant l’été.

C’est justement ce recul qui le rend intéressant aujourd’hui. La question n’est plus seulement de savoir si une IA peut dessiner quelques nodes à partir d’une phrase. Elle est de savoir si elle peut réellement participer au cycle de vie d’un workflow n8n : comprendre l’intention, construire avec les bons composants, exécuter, lire les erreurs et corriger sans transformer l’automatisation en boîte noire.

Avant l’Assistant, n8n avait déjà ouvert la porte aux agents

Le nouvel Assistant n’arrive pas dans le vide. Dès le printemps 2026, n8n avait étendu son serveur MCP intégré pour permettre à des outils comme Claude Code, Cursor ou d’autres clients MCP de créer et modifier des workflows. L’annonce du 24 mars présentait cette capacité dans n8n 2.14.0 en beta. La documentation MCP actuelle décrit aujourd’hui la création, l’édition, le test et l’exécution de workflows depuis un agent externe.

C’était déjà un changement important : au lieu de demander à un modèle de produire du JSON à importer manuellement, l’agent pouvait intervenir directement sur l’instance n8n.

Mais ce fonctionnement conservait une séparation nette entre deux environnements : l’agent d’un côté, n8n de l’autre. Il fallait choisir et configurer le client, lui donner les bons outils et souvent travailler à partir d’un terminal ou d’un IDE.

Le futur n8n Assistant va reprendre une partie de cette logique pour la déplacer dans le produit lui-même.

9 juillet : n8n passe du générateur à l’agent de workflow

Le 9 juillet 2026, n8n annonce un nouvel AI Assistant disponible en preview sur n8n Cloud à partir de la version 2.29.9. Dès cette première version, la promesse va plus loin que l’ancien AI Workflow Builder : l’Assistant peut créer, modifier, tester et dépanner un workflow.

La distinction est importante. L’ancien Workflow Builder suivait essentiellement une logique de génération : on décrivait le besoin, il produisait un workflow, puis la suite revenait à l’utilisateur. n8n explique aujourd’hui que l’Assistant remplace ce Builder : il peut construire le workflow, l’exécuter, observer ce qui se passe et proposer des corrections.

Le billet publié le 9 septembre résume cette boucle : l’utilisateur décrit l’automatisation, l’Assistant planifie, construit sur le canvas, demande les credentials nécessaires, lance le workflow, inspecte l’exécution puis itère lorsqu’un node échoue.

Le résultat reste un workflow n8n standard. Il apparaît sur le canvas, peut être ouvert et modifié manuellement et conserve son historique d’exécution. C’est un point essentiel : le promptConsigne / contexte fourni au modèle pour orienter sa génération (system, user, exemples, outils). n’est pas l’artefact final, le workflow l’est.

Pourquoi cela change plus de choses qu’un simple « prompt vers workflow »

Un générateur est surtout utile au premier jet. Un agent intégré devient plus intéressant lorsqu’il peut travailler sur ce qui se passe après le premier jet.

La documentation actuelle de n8n Assistant permet par exemple de lui demander de diagnostiquer la dernière exécution en erreur, d’expliquer la cause, puis de suggérer une correction avant de modifier le workflow. Il peut également mettre à jour une automatisation existante, créer ou modifier des Data Tables et demander une validation avant certaines actions importantes.

n8n précise que les secrets des credentials ne sont pas envoyés au modèle : lorsque l’Assistant en a besoin, l’utilisateur passe par l’écran de credentials habituel. Les actions à fort impact, comme la publication ou la suppression, doivent également passer par une confirmation.

La différence pratique est donc moins spectaculaire qu’un nouveau type de node, mais plus structurante : la conversation devient une autre manière de manipuler le même environnement de travail.

Sous le capot, n8n essaie d’éviter le piège du « gros Code node »

C’est probablement le point le plus intéressant pour les utilisateurs qui ont déjà testé des générateurs externes de workflows.

Un problème classique des approches basées sur un LLMLarge Language Model : modèle de langage entraîné sur d’énormes corpus pour prédire et générer du texte. consiste à contourner les nodes natifs dès que leur configuration devient compliquée. Le modèle finit alors par produire un Code node, un appel HTTP générique ou un bloc JavaScript qui fonctionne peut-être, mais qui perd une partie de l’intérêt de n8n : lisibilité, maintenance et configuration visuelle.

Le code public de n8n montre que ce problème est traité explicitement. Dans le skill workflow-builder du module Instance AI, l’instruction est sans ambiguïté : « Native node first ».

Le constructeur doit privilégier Edit Fields, Filter, IF, Switch, Sort, Remove Duplicates, Aggregate, Split Out, Limit ou Merge. Le Code node est réservé à des cas où il apporte réellement quelque chose : algorithme nécessitant plusieurs passes, gestion d’un état avec $getWorkflowStaticData, nettoyage d’une sortie de modèle, gestion particulière avec try/catch, ou étape qui demanderait autrement trois nodes ou plus.

Cette règle n’est pas une garantie que tous les workflows générés seront élégants. Elle montre en revanche que n8n a encodé directement dans son agent le comportement que l’on attend d’un bon utilisateur de la plateforme : utiliser d’abord les abstractions natives.

Le Workflow SDK sert de couche de construction et de validation

n8n a parallèlement publié @n8n/workflow-sdk, un SDKSoftware Development Kit : bibliothèques et outils pour intégrer un service dans une application. TypeScript destiné à créer des workflows par programmation. Son README mentionne notamment le typage, les structures de contrôle comme IF, Switch, Merge et Loop, ainsi qu’une validation intégrée.

La documentation technique du sandbox montre le chemin suivi par l’Assistant : le workflow peut être construit sous forme de source TypeScript dans un environnement isolé, validé, converti en JSON n8n puis soumis à une validation côté serveur avant d’être sauvegardé. Le sandbox embarque également un catalogue des types de nodes et une base de références destinée au constructeur. Le détail est documenté dans le code du module Instance AI.

Autrement dit, l’Assistant ne repose pas uniquement sur la capacité d’un modèle à « se souvenir » de la structure JSON d’un node. n8n lui fournit une couche spécifique pour construire et vérifier ce qu’il produit.

Assistant intégré ou MCP : ce n’est pas vraiment l’un contre l’autre

Il serait tentant de présenter l’Assistant comme le remplaçant des solutions MCP. Ce serait trop simple.

Dès l’annonce de juillet, n8n expliquait que son Assistant et son serveur MCP avaient des capacités proches et partageaient une partie de leur architecture. La différence principale tient à l’expérience utilisateur : avec l’Assistant, la conversation, le canvas et l’exécution restent dans n8n ; avec le MCP, l’utilisateur choisit son propre agent ou environnement de développement.

Le vrai changement est donc que le scénario auparavant réservé aux utilisateurs prêts à assembler un agent externe devient une fonctionnalité native de n8n.

Août : le self-hosted devient beaucoup moins expérimental à installer

Le lancement de juillet avait une limite importante pour les équipes qui auto-hébergent n8n. Les premières instructions self-hosted parlaient explicitement d’une pre-release preview avec plusieurs composants à assembler : provider LLM, sandbox obligatoire et, si l’on voulait la recherche Web, Brave Search ou SearXNG.

Le 18 août, n8n annonce une simplification avec la version 2.35. Pour une nouvelle installation Docker, la commande curl -fsSL https://get.n8n.io | sh peut préparer n8n avec un sandbox et SearXNG préconfigurés. Le fournisseur de modèle reste à connecter. Les installations Docker existantes peuvent, elles, ajouter le sandbox et la recherche à leur configuration. n8n détaille cette évolution ici.

La page de lancement publiée en septembre indique désormais le self-hosted Docker à partir de n8n 2.36, tandis que la simplification du setup avait commencé en 2.35. Pour une installation actuelle, mieux vaut donc suivre la documentation en vigueur plutôt que figer les prérequis du mois de juillet.

Un point important pour les installations existantes : n8n indique que l’Assistant self-hosted est supporté avec Docker uniquement. Les installations npm ne sont pas prises en charge à ce stade.

Le sandbox n’est pas un détail de déploiement : il exécute le code de construction généré par l’Assistant dans un environnement isolé. La documentation Docker Compose actuelle recommande au moins 4 Go de RAM et 2 vCPU pour la stack incluant ce sandbox. n8n présente son sandbox intégré comme adapté au développement et aux tests et recommande actuellement Daytona pour une instance de production.

Septembre : l’Assistant élargit encore son périmètre

La recherche Web ne date pas de septembre : elle était déjà prévue dans le lancement de juillet, avec permission de l’utilisateur, et les premières instructions self-hosted citaient déjà Brave Search ou SearXNG. En septembre, n8n élargit surtout les usages accessibles depuis le même Assistant.

Dans une mise à jour publiée le 10 septembre, n8n met notamment en avant la possibilité de :

• construire les nouveaux agents n8n ;
• connecter des serveurs MCP directement à l’Assistant ;
• créer et mettre à jour des Data Tables ;
• utiliser la recherche Web lorsqu’elle est configurée et autorisée ;
• travailler avec les dossiers et utiliser d’autres workflows du même dossier comme contexte.

C’est également à cette période que le nom AI Assistant devient n8n Assistant.

La même mise à jour indique que les conversations survivent désormais mieux aux redémarrages et que n8n a corrigé plusieurs problèmes dans la boucle build-and-verify, notamment des cas de données de test épinglées vides et certaines vérifications qui pouvaient rester bloquées. Ces correctifs montrent que cette boucle faisait encore l’objet d’ajustements, mais n8n ne les relie pas explicitement aux sessions bloquées signalées par des utilisateurs pendant l’été.

Où l’Assistant est disponible aujourd’hui

La disponibilité dépend encore du mode d’hébergement et du plan. Dans sa mise à jour de septembre, n8n indique que l’Assistant est activé par défaut sur les nouvelles instances Cloud Starter et Pro ; les instances existantes le reçoivent lors de leur mise à niveau. En self-hosted Community, le support est annoncé pour Docker. Les installations npm ne sont pas supportées.

À l’inverse, n8n indique que les plans Enterprise ne disposent pas encore de l’Assistant et les place sur la roadmap. Cette situation peut sembler contre-intuitive pour une fonctionnalité avancée, mais c’est bien l’état annoncé pendant la preview.

Les premiers retours : une vraie promesse, mais pas encore une expérience parfaitement stable

Deux mois ne suffisent pas pour tirer un bilan définitif, et il n’existe pas à notre connaissance de benchmarkJeu de référence public ou interne pour comparer des modèles (MMLU, HumanEval, etc.) — à lire avec prudence hors domaine. indépendant permettant de mesurer un taux de réussite global. Les retours disponibles sont surtout des témoignages et des tickets de bugs. Il faut les lire comme tels.

Côté positif, des utilisateurs self-hosted ont rapidement souligné l’intérêt d’avoir l’agent directement dans n8n. Dans le fil de lancement, un utilisateur indique que cette intégration lui paraît plus naturelle qu’un agent MCP externe. Un autre relate quelques problèmes Docker lors de son installation, mais décrit ensuite la mise en place comme relativement simple. Ce sont des expériences individuelles, pas une mesure de fiabilité générale.

Les limites sont tout aussi visibles. Le cas le mieux documenté côté GitHub est l’issue #35849, ouverte le 7 août 2026. L’utilisateur est sur n8n Cloud 2.34.1 et rapporte deux sessions distinctes où l’Assistant est resté bloqué pendant des heures sur « generating workflow ».

Un autre ticket, #35729, vise explicitement l’AI Workflow Generator et ne renseigne ni la version de n8n ni le mode d’hébergement. Il ne permet donc pas d’attribuer ce problème au nouvel Assistant et n’est pas utilisé ici comme preuve sur sa stabilité.

Le 27 août, un autre utilisateur indique sur le forum n8n que l’Assistant reste parfois en réflexion pendant plus d’une heure. Le lendemain, il précise utiliser n8n Cloud et confirme que des crédits sont consommés pendant cette exécution. Là encore, il s’agit d’un témoignage individuel et non d’une mesure de fréquence.

La cause de ces blocages n’est pas établie publiquement. Dans le même fil, un contributeur renvoie d’ailleurs vers un signalement similaire de juillet en précisant qu’aucune cause n’avait été identifiée. Il serait donc excessif de présenter les correctifs de septembre comme la résolution directe de ces incidents.

Et la jeunesse de l’infrastructure reste visible : le 11 septembre, un utilisateur a signalé dans le fil officiel un échec du sandbox parce qu’une version requise de @n8n/workflow-sdk n’était pas disponible. Un membre de l’équipe n8n a répondu qu’un correctif était en cours de publication. Le message ne précise pas le mode d’hébergement de cet utilisateur.

Les crédits peuvent aussi devenir un paramètre du workflow de travail

Sur n8n Cloud, l’Assistant consomme des crédits en fonction des tokensUnité de texte traitée par un modèle (souvent un morceau de mot). Les coûts et fenêtres de contexte se comptent en tokens. traités. La documentation précise que les longues conversations, les workflows volumineux, les sessions de debugging et les itérations répétées consomment davantage.

C’est logique pour un agent qui ne s’arrête plus après la première génération : chaque nouvelle analyse ou correction ajoute du contexte et de nouveaux appels au modèle. Cela signifie aussi que la qualité du prompt initial — déclencheur, services utilisés, données attendues, comportement en cas d’erreur — devient un enjeu de coût autant que de qualité.

Deux retours communautaires permettent de documenter un cas plus concret. Le 21 juillet, un utilisateur Cloud rapporte une session bloquée plus de 35 minutes, annulée manuellement, tout en constatant que des crédits AI avaient été déduits. Dans le fil du 27 août, l’auteur confirme le 28 août être sur Cloud et voir lui aussi des crédits consommés pendant la session bloquée.

Ces deux témoignages établissent que le phénomène a bien été observé par des utilisateurs ; ils ne permettent pas, à eux seuls, de déterminer la règle générale de facturation ni la fréquence du problème.

En self-hosted, le fonctionnement est différent : le modèle est fourni avec sa propre clé APIApplication Programming Interface : contrat machine pour consommer un service (HTTP, SDK, webhooks). et l’usage est facturé directement par le provider choisi.

Ce que « Preview » veut encore dire

n8n ne présente pas l’Assistant comme capable de produire automatiquement un workflow prêt pour la production. Sa documentation demande explicitement de vérifier la logique, la configuration des nodes, les credentials, les résultats d’exécution, les erreurs et les effets de bord avant activation.

Le billet de septembre le dit également clairement : le premier workflow n’est pas garanti production-ready.

C’est probablement la meilleure manière d’aborder l’outil aujourd’hui. n8n Assistant peut raccourcir la distance entre une idée et un premier workflow fonctionnel, mais il ne supprime ni la conception métier ni la revue technique.

Le bon test n’est pas de lui faire construire un workflow de démonstration

Pour mesurer l’intérêt réel de l’Assistant dans une équipe qui connaît déjà n8n, mieux vaut éviter le classique « quand un formulaire arrive, envoie un message Slack ».

Un test plus révélateur consiste à prendre un workflow dont on connaît déjà la bonne solution et à observer quatre choses :

1. Le choix des nodes. Utilise-t-il les nodes natifs attendus ou contourne-t-il la difficulté avec du Code et des requêtes HTTP ?
2. La qualité de la modification. Peut-il changer une partie d’un workflow existant sans dégrader le reste ?
3. Le cycle de debugging. Lorsqu’une API renvoie une erreur, sait-il exploiter les données d’exécution, corriger puis relancer ?
4. Le coût de l’itération. Combien de tours et combien de tokens sont nécessaires avant d’obtenir une automatisation que l’on accepterait de maintenir ?

C’est sur ces critères que l’évolution de l’été devient réellement intéressante.

n8n savait déjà générer des workflows et savait déjà se laisser piloter par MCP. Avec n8n Assistant, la plateforme essaie désormais d’intégrer l’agent dans son propre modèle de travail : nodes natifs, credentials, logs, sandbox, ressources du projet et confirmations humaines.

Après un peu plus de deux mois, la direction est crédible et les briques techniques sont plus solides qu’un simple générateur de JSON. Les tickets et témoignages de l’été rappellent toutefois que la promesse n’est pas encore synonyme de fiabilité de production. Pour l’instant, l’Assistant est surtout une nouvelle façon, potentiellement beaucoup plus rapide, de construire et déboguer avec n8n — à condition de continuer à regarder ce qu’il fait.