Tutoriel Agent IA N8N : Du Prompt Simple aux Données de Flux de Travail Structuré

Pourquoi l’automatisation des workflows a maintenant besoin de plus que des règles fixes

Imaginez qu’un workflow reçoit une phrase comme celle-ci : “A new client named John bought a gpu server on 01/06/2026.” Une personne lit cela et voit instantanément trois valeurs utiles : le nom du client, le produit et la date.

Un workflow rigide ne le fait pas. Il peut diviser le texte, rechercher des modèles et valider des formats, mais dès que la formulation change — “John just ordered a GPU server yesterday” ou “New customer John purchased hosting on June 1” — l’analyse fragile commence à se fissurer.

C’est la limite entre l’automatisation classique et la couche IA. Les workflows déterministes excellent une fois que les entrées sont propres : routage des données, transformation des champs, validation des enregistrements, appel des API et répétition des séquences de manière fiable. Ils échouent à la première étape désordonnée — interpréter l’intention, classer les demandes, résumer le contenu non structuré ou extraire des champs du langage naturel avant que le workflow puisse agir.

C’est exactement là qu’un n8n AI Agent devient pratique. Dans ce guide, vous obtiendrez d’abord une compréhension en langage clair de ce qu’est réellement le n8n AI Agent dans un workflow, puis vous construirez un premier cas d’usage fondé qui transforme le langage naturel en données structurées.

Ce qu’un agent IA n8n est réellement

Dans n8n, un agent IA est mieux compris comme une étape de raisonnement à l’intérieur d’un workflow. C’est un nœud qui utilise un modèle pour interpréter l’entrée, travailler avec le contexte et aider à façonner ce qui se passe ensuite. Cela peut signifier répondre à une invite, extraire des champs, classer une demande ou décider comment l’étape de workflow suivante doit être préparée. L’important est que l’agent vit à l’intérieur du workflow. Ce n’est pas le système entier en lui-même.

Les éléments mobiles sont plus faciles à comprendre quand vous les séparez par rôle :

Le modèle gère l’interprétation flexible. Les nœuds n8n environnants possèdent toujours la structure : d’où proviennent les données, comment elles sont mappées, ce qui est validé, quel nœud s’exécute ensuite et ce qui est finalement écrit dans un autre système. Si vous avez besoin d’une exécution prévisible, d’approbations, d’intégrations ou de règles métier, le workflow reste responsable.

💡 Conseil : Le modèle mental le plus clair est celui-ci : le workflow reste les rails ; l’agent est l’étape de raisonnement à l’intérieur de ces rails.

Cela facilite également de dire ce que l’agent IA n8n n’est pas. Ce n’est pas juste un nœud chatbot. Ce n’est pas une autonomie magique. Ce n’est pas quelque chose dont chaque workflow a besoin. Si une règle fixe, une simple transformation ou une seule invite IA délimitée résout déjà le problème, ajouter une couche d’agent n’ajoute que de la complexité. La valeur apparaît quand le workflow doit traiter l’ambiguïté avant de pouvoir redevenir déterministe.

Où les agents IA n8n aident le plus dans les workflows réels

Le meilleur endroit pour utiliser un agent IA n8n est à la limite où l’ambiguïté humaine entre dans le système.

• Les équipes d’assistance pourraient avoir besoin de lire une demande entrante et de classer si elle concerne la facturation, le technique ou l’urgent.
• Les équipes d’exploitation pourraient recevoir des demandes internes en langage naturel et avoir besoin d’extraire des champs avant le routage.
• Les équipes commerciales pourraient vouloir transformer un message de prospect confus en données prêtes pour le CRM.
• Les workflows lourds en documents pourraient avoir besoin d’extraire des noms, des dates, des numéros de facture ou des détails de service à partir de texte non structuré.

Dans chacun de ces cas, la division du travail reste la même. L’agent interprète, extrait, résume ou classe. Les nœuds déterministes valident ensuite la sortie, la routent vers la bonne branche, créent des enregistrements, notifient les personnes ou écrivent le résultat dans un autre système. Cette limite est importante car elle conserve la partie utile de l’IA — l’interprétation flexible — sans abandonner la prévisibilité qui rend l’automatisation des workflows utile en premier lieu.

L’extraction structurée est un cas d’usage particulièrement fort car elle est délimitée, visible et immédiatement utile en aval. Vous pouvez voir la phrase d’entrée, définir les champs que vous voulez récupérer, puis utiliser ces champs comme des données de workflow normales. Cela rend le bénéfice concret. Au lieu de « l’IA a dit quelque chose d’utile », vous obtenez « le workflow a maintenant nom, produit et date, et le nœud suivant peut agir dessus ».

C’est aussi un bon endroit pour garder une discipline à l’esprit : plus de comportement d’agent n’est pas automatiquement mieux. Si une règle fixe ou une seule invite résout déjà le problème, vous n’avez probablement pas besoin d’une couche d’agent complète. Cet article se concentre sur l’extraction structurée car elle montre une valeur de workflow réelle sans prétendre que chaque problème d’automatisation a besoin d’une large autonomie.

Ce que nous construisons dans ce tutoriel

Ce tutoriel enseigne intentionnellement deux workflows. Le workflow A est le plus petit motif possible :

Manual Trigger -> Set -> AI Agent -> OpenRouter Chat Model -> plain response

Son rôle n’est pas de vous impressionner. Son rôle est de rendre le chemin des données visible afin que vous puissiez voir exactement comment le prompt entre dans le workflow, atteint l’agent, et revient comme une réponse normale.

Le workflow B conserve cette même base et l’améliore avec un Structured Output Parser plus un nœud de code Create invoice. Au lieu de retourner un paragraphe, l’agent retournera des champs prévisibles. Ces champs sont ensuite utilisés pour construire un objet facture, ce qui rend la sortie immédiatement utile au reste du workflow.

Cette progression en deux étapes est importante. D’abord, vous voyez comment l’agent se comporte dans sa forme la plus simple. Ensuite, vous voyez pourquoi la sortie IA brute n’est que la moitié de l’histoire pour l’automatisation. Le vrai bénéfice arrive quand le workflow transforme le langage naturel en données structurées.

Avant de commencer : prérequis et préparation

Avant de construire le workflow, préparez trois choses :

1. Une instance n8n en cours d’exécution
2. La permission de créer et modifier un workflow
3. Des identifiants API OpenRouter fonctionnels

Vous pouvez exécuter la même logique dans n8n Cloud si vous le souhaitez, mais cet article est structuré autour d’un environnement auto-hébergé car c’est un cas d’usage courant de style AlexHost lorsque les équipes veulent plus de contrôle sur les données, la mise en réseau ou les intégrations privées.

La source pratique de ce tutoriel a été observée sur n8n 2.26.8 s’exécutant sur un VPS AlexHost. Si vous devez encore déployer n8n avant de tenter la partie IA, utilisez le guide AlexHost séparé ici : n8n automation tutorial for Ubuntu: from zero to flow.

📓 Note : Une petite note de terminologie avant de continuer : la documentation plus récente peut afficher le nœud Set comme Edit Fields (Set), mais cette procédure conserve la terminologie plus simple Set car c’est ce que la source pratique utilise.

La raison pour laquelle cet article commence par Manual Trigger + Set au lieu de Chat Trigger est simple : cela rend l’entrée explicite, facilite l’inspection du mappage et supprime une couche de confusion pour une première construction. Vous apprenez comment un nœud AI Agent s’intègre dans un workflow et comment ce workflow passe d’une invite libre à une sortie structurée et prête pour l’automatisation.

Partie pratique 1 : construire le plus petit flux d’agent IA n8n possible

Ce premier workflow prouve le modèle de base avant de lui demander de faire quelque chose de plus utile. Vous allez créer une entrée visible, la transmettre à l’agent IA, connecter un modèle OpenRouter et confirmer que le workflow retourne une réponse textuelle normale.

1.0 Ajouter le nœud de déclenchement et le nœud d’entrée

Commencez par placer un nœud Manual Trigger et un nœud Set sur le canvas. Cela garde le point d’entrée simple et vous donne un seul champ clair à transmettre à l’agent.

À ce stade, vous ne faites rien de « spécifique à l’IA » encore. Vous préparez une entrée de workflow propre pour que le nœud suivant ait quelque chose d’explicite à lire.

1.1 Configurer le nœud Set

Ouvrez le nœud Set, basculez-le en Manual Mapping, créez un champ nommé prompt, et collez le texte de démarrage ci-dessous. Cela donne au workflow une valeur visible que vous pouvez ensuite remplacer par une phrase plus professionnelle.

Hello, who are you?

Ce que cela fait est simple mais important : au lieu de masquer le prompt dans le nœud IA, vous le conservez dans les données normales du workflow. Cela rend le chemin d’entrée plus facile à comprendre et à réutiliser.

2.0 Placer l’agent IA et connecter un modèle de chat

Maintenant, ajoutez un nœud AI Agent et connectez un OpenRouter Chat Model à son entrée Chat Model. En termes simples, les entrées visibles signifient ceci : Chat Model est le modèle que l’agent utilise pour répondre, Memory est un contexte optionnel qui persiste entre les tours, et Tool est la connexion optionnelle qui permet à l’agent d’appeler des capacités externes. Dans ce premier workflow, seul le modèle est connecté car l’objectif est de comprendre le plus petit modèle fonctionnant.

Une fois ceci en place, la division des rôles devient visible : le workflow porte l’entrée, et l’agent gérera l’étape d’interprétation.

2.1 Configurer le modèle OpenRouter

Sélectionnez votre identifiant OpenRouter account et choisissez le même modèle montré dans le workflow source : deepseek/deepseek-v4-flash. Vous n’avez pas besoin d’ajustement supplémentaire pour cette première tentative.

📝 Note : Les modèles OpenRouter disponibles peuvent varier selon le compte, même si l’exemple source-of-truth ici utilise deepseek/deepseek-v4-flash.

Si votre compte affiche une liste différente, le modèle de workflow importe toujours plus que le nom exact du modèle.

3.0 Mapper le champ prompt dans l’agent IA

Connectez la sortie du nœud Set à l’AI Agent, définissez Source for Prompt (User Message) sur Define below, et mappez la valeur du workflow dans le champ prompt en utilisant l’expression ci-dessous. Cela indique à l’agent de lire la valeur prompt à partir des données en amont au lieu d’utiliser un message codé en dur dans le nœud.

{{ $json.prompt }}

Ce mapping est le pont clé entre les données normales de n8n et l’étape IA. Une fois que vous le comprenez, le reste du tutoriel devient beaucoup plus facile à suivre.

3.1 Exécuter le workflow

Exécutez le workflow pour que les données se déplacent dans la chaîne complète : Manual Trigger -> Set -> AI Agent -> OpenRouter Chat Model. Vous vérifiez non seulement que le modèle répond, mais que le workflow transmet le prompt proprement d’un nœud à l’autre.

Si l’exécution réussit, vous avez maintenant la preuve que l’agent peut consommer les données du workflow plutôt que de seulement taper librement dans sa propre interface.

3.2 Examiner la réponse

Ouvrez la sortie et inspectez le résultat. À ce stade, l’agent IA retourne une réponse textuelle normale au prompt. C’est le modèle de base dans sa forme la plus simple : entrée de prompt, sortie de réponse.

Ce premier workflow importe car il prouve la plomberie. Il montre aussi clairement la limitation : un paragraphe convient pour l’interaction, mais est maladroit pour l’automatisation en aval. L’étape suivante est où le workflow devient beaucoup plus utile.

Partie pratique 2 : transformer la réponse en données de flux de travail structurées

Maintenant, nous conservons le même flux de travail de base et changeons l’objectif. Au lieu de demander à l’agent une réponse générale, nous lui demanderons d’extraire des champs prévisibles que le nœud suivant peut utiliser comme JSON normal.

4.0 Modifier l’invite et exiger un format spécifique

Retournez au nœud Set et remplacez la salutation décontractée par la phrase de style commercial ci-dessous. Ensuite, activez Require Specific Output Format dans l’AI Agent pour que le flux de travail cesse de viser la prose et commence à viser l’extraction structurée.

A new client named John bought a gpu server on 01/06/2026

C’est le moment où le cas d’usage devient réel. La phrase contient des données qu’un humain comprend instantanément, et le flux de travail apprend maintenant à retourner ces données dans une forme utilisable par une machine.

4.1 Ajouter un analyseur de sortie structurée

Connectez un Structured Output Parser à l’entrée Output Parser de l’AI Agent. Cet analyseur est ce qui donne au modèle une structure cible au lieu de le laisser répondre en texte libre.

📝 Note : Le Structured Output Parser est bien adapté à cette première démo, mais les directives officielles de n8n notent que l’analyse directe sur les agents peut être moins fiable dans les flux de travail plus avancés. Pour ce modèle pour débutants, c’est toujours la bonne étape d’enseignement car elle rend le changement de forme de données facile à voir.

L’idée importante n’est pas le nœud supplémentaire en soi. C’est que vous transformez « réponse IA » en « contrat de flux de travail ».

4.2 Définir le schéma de sortie à partir d’un exemple JSON

Dans l’analyseur, définissez Schema Type sur Generate From JSON Example et utilisez l’exemple exact ci-dessous. Cela donne à l’agent un schéma clair avec les trois champs que le flux de travail attend en retour.

{
  "name": "Alex",
  "product": "VPS hosting",
  "date": "21/6/2026"
}

Une fois que vous définissez cet exemple, vous ne demandez plus au modèle de « dire quelque chose d’utile ». Vous lui demandez de retourner une structure prévisible avec name, product et date.

4.3 Vérifier le résultat structuré

Exécutez le flux de travail à nouveau et inspectez la sortie de l’AI Agent. Cette fois, le résultat devrait revenir sous forme de champs au lieu d’un paragraphe.

Ce changement de forme est la véritable amélioration. La sortie structurée n’est pas seulement un formatage plus joli. C’est ce qui rend le résultat suffisamment fiable pour que la logique en aval le consomme sans deviner.

4.4 Utiliser les champs analysés dans un nœud JavaScript de facture

Maintenant, transmettez le résultat à un nœud JavaScript Create invoice. Le détail clé de la source de vérité dans cette procédure pas à pas est que l’objet analysé est lu à partir de $input.first().json.output, ce qui signifie que le code consomme la sortie structurée de l’agent directement.

// Input data
const order = $input.first().json.output

// Parse the order date
const [day, month, year] = order.date.split("/");
const orderDate = new Date(`${year}-${month}-${day}`);

// Generate a pseudo unique invoice ID (8 chars)
function generateId() {
  return Math.random().toString(36).substring(2, 10);
}
const invoiceId = generateId();

// Calculate payment due date (7 days later)
const dueDate = new Date(orderDate);
dueDate.setDate(orderDate.getDate() + 7);

// Build invoice record
const invoice = {
  invoice_id: invoiceId,
  customer: order.name,
  product: order.product,
  order_date: orderDate.toISOString().split("T")[0],
  due_date: dueDate.toISOString().split("T")[0],
  status: "Pending"
};

// Print invoice
console.log("Invoice Generated:");
for (const [key, value] of Object.entries(invoice)) {
  console.log(`${key}: ${value}`);
}

// If inside n8n Function node, return JSON
return [{ json: invoice }];

C’est le moment où le flux de travail cesse de se comporter comme une démo de chat et commence à se comporter comme une automatisation. L’agent a extrait les champs, et le nœud suivant les a utilisés exactement comme n’importe quelle autre entrée structurée.

4.5 Examiner les données de facture générées

Ouvrez la sortie finale et inspectez l’objet de facture. Vous devriez voir des champs utilisables tels que invoice_id, customer, product, order_date, due_date et status.

C’est le cycle de vie complet vers lequel l’article a été construit : phrase en langage naturel -> extraction structurée -> enregistrement de facture. Une fois que le résultat a cette forme, le flux de travail peut le transmettre aux étapes suivantes aussi fiablement que n’importe quel autre payload JSON.

Ce que ces deux premiers workflows prouvent réellement

Ensemble, les deux workflows montrent deux modèles différents pour l’Agent IA n8n. Le premier modèle est une simple invite-réponse : l’agent reçoit du texte et répond par du texte. Le deuxième modèle est l’extraction structurée : l’agent reçoit du langage humain désorganisé et retourne des champs que le workflow peut réellement utiliser.

Cette différence est importante car la mise à niveau porte sur la capacité, non sur l’apparence. La génération de texte aide à l’interaction. L’extraction structurée aide à l’automatisation. Le deuxième modèle est ce qui transforme l’étape IA de « intéressante » en « opérationnellement utile ».

Le tableau ci-dessous résume ce changement :

Une fois que vous comprenez ce chemin de mise à niveau, l’exemple de facture cesse d’être « un tutoriel de facture » et devient un modèle de workflow réutilisable. La même approche peut alimenter la capture de prospects, l’admission du support, l’analyse de commandes, l’enrichissement de tickets ou le routage de demandes internes. Dans chaque cas, l’objectif est le même : transformer le langage naturel en données structurées, puis laisser les nœuds de workflow déterministes faire le reste.

Que essayer ensuite après ce premier cas d’usage

L’étape la plus sûre n’est pas l’autonomie—c’est de conserver le motif délimité et de mettre à niveau une variable à la fois. Remplacez Manual Trigger par un Chat Trigger ou Webhook lorsque vous avez besoin d’une entrée entrante. Ajoutez la mémoire uniquement lorsque la continuité est importante. Attachez des outils uniquement lorsque l’agent doit rechercher quelque chose ou agir au-delà du nœud. Ensuite, ajoutez une validation ou une approbation si les résultats touchent des systèmes réels.

L’auto-hébergement devient critique lorsque les workflows ont besoin d’entrées privées, d’accès aux services internes, d’une disponibilité prévisible ou d’un contrôle plus strict—ici l’infrastructure VPS de style AlexHost fait partie de la conception, pas seulement de l’arrière-plan. Pour le déploiement, le même guide AlexHost couvre la configuration : tutoriel d’automatisation n8n pour Ubuntu : de zéro à flux.

📝 Note : La règle directrice : heuristique du plus petit système. Si l’extraction structurée résout le problème, arrêtez-vous là. N’ajoutez pas de mémoire, d’outils ou d’autonomie à moins que le workflow ne l’exige vraiment.

Commencez par un cas d’usage délimité, pas par le battage médiatique de l’autonomie

L’automatisation rigide casse généralement au moment où une entrée humaine désordonnée entre dans le système. C’est l’écart sur lequel cet article s’est concentré. Vous disposez maintenant à la fois du modèle mental et d’un schéma fonctionnel : l’Agent IA n8n gère l’étape d’interprétation flexible, et le flux de travail environnant transforme ce résultat en quelque chose de structuré et fiable.

C’est la règle de conception qui vaut la peine d’être conservée. Commencez par des tâches d’interprétation contrôlées qui produisent des données prêtes pour le flux de travail. Élargissez-vous à la mémoire, aux outils ou à des déclencheurs plus riches uniquement lorsque le flux de travail réel en a besoin — pas parce que le mot « agent » rend une plus grande autonomie plus impressionnante.