Guillaume Duvernay

Maîtriser les sous-workflows n8n peut vous rendre redoutablement efficace avec l'IA

13 min de lecture

n8nagentsAI efficiencyarchitecture

Un sous-workflow dans n8n est un workflow dont le déclencheur est When executed by another workflow. Vous définissez les données d’entrée, vous construisez les étapes, et le résultat du dernier nœud est ce que le workflow appelant récupère.

C’est une fonction, ou un microservice si vous préférez. On peut tout construire sans jamais en utiliser, c’est pourquoi beaucoup de gens ne le font jamais.

Je veux aller plus loin que le titre de la vidéo. Maîtriser cela n’est pas une compétence propre à n8n. C’est là que vous apprenez, sur un canevas où chaque étape est visible, les quatre points qui déterminent si une solution IA est rentable : découper une tâche répétitive en étapes, limiter le contexte de chaque étape, choisir un modèle par étape et cesser de confier des décisions à un agent dès que l’ordre est connu. n8n n’est pas le sujet, c’est l’endroit où ces quatre points sont les plus évidents.

Les sous-workflows sont utiles pour deux choses. La première est évidente et facilite la maintenance. La seconde est celle qui m’a tout appris.

Video: Sous-workflows dans n8n : boostez vos agents IA et passez à l’échellePlay

L’avantage pragmatique : build it once

Exemple avec les opérations commerciales. Un workflow gère les demandes de démo. Un autre traite un CSV de participants à un événement. Tous deux doivent, à un moment donné, enrichir un lead : prendre un e-mail, récupérer l’entreprise et le secteur via un fournisseur de données, utiliser un modèle pour résumer l’activité de l’entreprise et scorer le lead.

Cela représente cinq ou six nœuds. Vous pourriez les construire dans le workflow de demande de démo, puis les reconstruire dans celui du CSV, et ainsi de suite pour les huit autres endroits qui finiront par avoir besoin de la même chose.

La sortie du dernier nœud est la sortie du sous-workflow, je termine donc par un nœud Edit Fields. C’est le contrat, et il vaut mieux l’écrire explicitement plutôt que de laisser fuiter n’importe quel résultat du nœud précédent.

Le gain se manifeste six mois plus tard, quand le fournisseur de données change ou que quelqu’un souhaite ajouter un champ en sortie. Vous modifiez un seul workflow. Tous les appelants en bénéficient.

L’avantage stratégique : un outil qui ne renvoie que l’essentiel

Voici la configuration. Un cours de biologie est stocké dans Airtable : 15 chapitres, chacun avec un nom, un résumé et le contenu complet. Un agent répond aux questions à son sujet.

Cet agent est déjà plus performant que la version naïve. Il dispose de deux outils plutôt qu’un bloc massif : rechercher tous les chapitres, qui renvoie uniquement les ID et les résumés, et récupérer le contenu d’un chapitre. Le system prompt lui demande de lire les résumés d’abord, de choisir un à trois chapitres, puis de les récupérer.

Cette conception en deux étapes représente déjà la majeure partie du gain.

Mesuré en collant les sorties réelles des outils dans un compteur de caractères. La troisième barre correspond à ce qu’une configuration naïve envoie pour chaque question, même pour celles ne concernant qu’un chapitre.

Alors pourquoi changer quoi que ce soit ? Deux raisons, et aucune n’est liée au nombre de mots.

Le grand modèle s’exécute à chaque appel d’outil

Analysons une exécution. GPT-5.1 est connecté, il est coûteux et performant, et il a été appelé trois fois : une fois pour décider de rechercher des chapitres, une fois pour décider de récupérer le contenu, et une fois pour rédiger la réponse.

Chacun de ces appels transporte le message système et la mémoire accumulée des résultats des outils précédents. L’entrée s’alourdit à chaque tour.

Deux de ces trois appels n’ont nécessité aucun raisonnement justifiant un modèle coûteux. Ils se sont contentés de choisir les chapitres pertinents dans une liste de résumés.

L’outil renvoie des champs non demandés

L’outil Get Record d’Airtable n’a pas de filtre de champ. Demandez le contenu complet d’un chapitre et vous recevrez aussi le nom du chapitre, l’heure de création et le résumé, que vous aviez déjà lors du premier appel et que vous transportez désormais en double.

On ne peut pas corriger cela au niveau de l’outil. On peut le corriger une étape plus tard, s’il y a une étape.

Un sous-workflow pour gérer toute la récupération

Supprimez les deux outils. Remplacez-les par un unique outil de sous-workflow qui passe d’un sujet au contenu complet des chapitres appropriés.

Le seul nœud coloré est le seul modèle sur ce canevas, et c’est un petit modèle. Tout le reste concerne le mouvement des données, ce pour quoi n8n est réellement conçu.

L’étape de sélection est celle sur laquelle il faut s’attarder. Son prompt système tient en une phrase : le message utilisateur nomme un sujet, trouvez un à trois chapitres pertinents, et voici la liste complète des chapitres avec leurs résumés. Sa sortie structurée est une liste d’ID d’enregistrement.

C’est un travail de tri parmi une liste de 15 résumés. GPT-4.1 Mini le fait correctement et rapidement, et je ne paie jamais le prix des modèles de pointe pour cela.

Passage de deux appels à un seul pour la décision, et l’étape supprimée était celle qui transportait le plus de mémoire accumulée.

Et parce qu’il y a un nœud Set entre Airtable et la sortie, je renvoie le titre du chapitre et le contenu complet. Rien d’autre ne transite.

Le prompt système de l’agent devient également plus court, ce qui, je ne m’y attendais pas, a un impact significatif. C’est maintenant : réponds à partir du cours de biologie, appelle toujours cet outil en premier, puis réponds uniquement avec ce qu’il t’a donné. Un seul outil, pas de règles d’ordonnancement, rien à se tromper.

La même astuce pour un outil de recherche web

Deuxième exemple, même structure. Un agent avec un outil de recherche web, dans mon cas Linkup, bien que Perplexity ou tout autre outil fonctionne de la même manière.

Si vous connectez l’API directement, vous rencontrez deux problèmes. Elle ne prend qu’une question par appel, donc une question large doit être posée par morceaux, avec un aller-retour à chaque fois. De plus, la réponse inclut la liste complète des sources, qui atterrit dans le contexte, que vous le vouliez ou non.

Quatre nœuds, dont deux servent uniquement à rejeter des données. L’appel API au milieu est la partie que vous auriez obtenue en connectant l’API directement.

Demandez par exemple comment le SEO et l’optimisation des moteurs génératifs s’articulent en 2026, et l’agent divise seul la demande en trois recherches : tendances et stratégies, comment optimiser pour les deux, meilleures pratiques selon la taille de l’entreprise. Un seul appel d’outil, trois recherches parallèles, un seul élément agrégé et nettoyé en retour.

C’est le parallélisme qui se traduit par une vitesse ressentie. Trois appels séquentiels de dix secondes représentent une demi-minute où l’utilisateur regarde un indicateur de chargement.

C’est un seul squelette, pas trois workflows

J’en ai construit un troisième pour un agent RAG, basé sur un cours vectorisé dans Supabase. L’apparence sur le canevas diffère, mais c’est exactement la même chose.

Chacun de mes sous-workflows de récupération suit ce schéma. Les étapes qui varient sont la source au milieu et la présence ou non d’un filtre.

Le filtre est l’étape que les deux autres n’ont pas, car un store de vecteurs renvoie un score de similitude, contrairement à Airtable. Quand la source fournit un nombre, vous pouvez rejeter les résultats insuffisants. Dans ce workflow, la limite est à 0.4, et tout ce qui est en dessous n’atteint jamais l’agent.

Deux enseignements tirés de la construction du troisième que j’appliquerais désormais à tous.

Nommez les champs de sortie. L’agrégation finale ne produit pas un bloc anonyme, mais un champ nommé Knowledge base retrieval, et à l’intérieur, chaque entrée apparie Query to the knowledge base avec Chunks returned. Le modèle lit ces noms. Lui envoyer un tableau en espérant qu’il devine quel résultat répond à quelle question est un risque qui se paie sur la réponse finale.

Signalez quand rien n’a été trouvé. Un filtre qui supprime tout ne produit aucun élément, et aucun élément signifie que le nœud suivant ne s’exécute jamais et que l’agent reçoit un silence. Il y a donc un nœud IF après le filtre, et sa branche vide écrit une phrase : rien n’a atteint le seuil de pertinence pour cette requête. Dans n8n, cela signifie également configurer le filtre pour qu’il sorte toujours des données, sinon la branche créée pour ce cas ne se déclenchera jamais.

Ce deuxième élément modifie les capacités de l’agent. Son prompt système se termine par une instruction lui demandant de dire qu’il ne sait pas plutôt que de répondre à partir de connaissances générales, et cette instruction n’est honnête que si la récupération de données qui suit l’est aussi lorsqu’elle revient vide.

Tout cela ne concerne pas vraiment n8n

Toutes ces trois approches font une seule chose : elles insèrent des étapes entre l’agent et la réponse brute, et durant ces étapes, elles éliminent le superflu. Voici pourquoi je pense que cela a plus de valeur qu’un simple flux de travail.

Découper une tâche répétitive en étapes est la clé. Une tâche exécutée une seule fois peut être approximative. Une tâche exécutée trois cents fois paie son approximation trois cents fois, et un agent qui décide de l’ordre à chaque exécution revient à payer un modèle pour redécouvrir un schéma que vous auriez pu tracer sur papier. Dès que vous connaissez les étapes, les formaliser n’est pas une perte de flexibilité, c’est tout l’intérêt.

Chaque étape reçoit le contexte dont elle a besoin, et rien d’autre. C’est ce que fait chaque nœud de nettoyage dans cet article. C’est également ce que j’ai mesuré avec Jev : placer un petit classificateur devant un agent pour décider quelles compétences précharger et supprimer les champs qu’il ne lira jamais dans chaque réponse d’outil a réduit les coûts de 29 % en moyenne, et de 61 % sur la meilleure tâche, sans baisse de qualité. Même idée, un niveau au-dessus. Le contexte a un coût et la majeure partie de ce qui s’y trouve n’est jamais lue.

Le modèle approprié pour chaque étape. Un travail de tri parmi quinze résumés ne nécessite pas un modèle de pointe. Une fois les étapes séparées, cela cesse d’être une opinion pour devenir un paramètre modifiable par nœud.

Ensuite, orchestrer plutôt que déléguer. Les étapes doivent se transmettre des informations utiles, c’est pourquoi les champs de sortie sont nommés et pourquoi un résultat vide l’indique explicitement. C’est cela l’orchestration, et c’est la partie que l’agent gère de manière invisible et maladroite.

C’est le même raisonnement qui m’a poussé à arrêter d’utiliser MCP pour tout ce qui est répétitif : un script via l’API peut gérer le filtrage, le mappage et la boucle sans modèle intermédiaire, alors que MCP ne le peut pas, car le modèle est l’intermédiaire.

Les agents masquent ces quatre aspects, et c’est précisément pourquoi il est utile d’en avoir construit un à la main. Quand je suis dans Claude Code et que quelque chose semble lent ou coûteux, je cherche l’étape qui a tout renvoyé alors que je n’avais besoin que de trois champs. C’est presque toujours le cas, et je sais où regarder parce que j’ai moi-même câblé cette étape un jour en surveillant le nombre de tokens.

Sources