Donner des outils à un AI Agent n8n : HTTP Request Tool, Code Tool et Workflow Tool

Un node AI Agent sans outil n’est qu’un chatbot un peu cher : il peut discuter, résumer, reformuler — mais il ne peut rien faire. La différence entre un agent qui bavarde et un agent qui agit tient à une seule connexion, ai_tool, et à trois familles de sub-nodes qui l’alimentent. Ce guide détaille comment les choisir, les configurer, et surtout comment écrire les descriptions dont dépend toute leur utilité — c’est le point que la majorité des workflows ratent.

Si vous découvrez tout juste l’architecture en cluster nodes de n8n, commencez plutôt par notre guide Débuter avec les nodes IA de n8n, qui pose les bases du node AI Agent, des chaînes et de la mémoire. Ici, on part du principe que l’agent tourne déjà et on se concentre sur la connexion ai_tool.

Les trois familles d’outils

Sous la prise ai_tool d’un node AI Agent, trois sub-nodes couvrent la quasi-totalité des besoins :

HTTP Request Tool (toolHttpRequest)

C’est l’outil le plus utilisé en production : il enveloppe une requête HTTP classique (méthode, URL, headers, body) et l’expose à l’agent comme une capacité d’action. L’agent décide seul des valeurs à injecter dans les champs configurés — il peut interroger une API tierce, écrire dans une base de données via une API REST, ou déclencher une notification.

Concrètement, c’est le mécanisme derrière l’agent questionnaire de notre Pack Conformité & Audit : après chaque réponse validée par l’utilisateur, l’agent appelle un toolHttpRequest qui poste un POST vers l’API REST de Supabase, avec l’identifiant du dossier, la question posée et la réponse reformulée. L’agent ne sait pas ce qu’est Supabase — il sait juste, grâce à la description de l’outil, qu’il doit « enregistrer une réponse validée du questionnaire » après chaque échange confirmé.

Custom Code Tool (toolCode)

Même bac à sable JavaScript ou Python que le node Code standard de n8n, mais avec une interface différente : le Code Tool expose un schéma d’entrée/sortie typé que l’agent remplit lui-même, plutôt qu’un simple passage d’items en chaîne. C’est l’outil à choisir quand la logique n’existe dans aucune API — un calcul métier, une validation de format, une transformation de données propre à votre activité.

Call n8n Workflow Tool (toolWorkflow)

Cet outil expose un workflow n8n entier comme une capacité que l’agent peut appeler. C’est le plus puissant des trois : il permet de réutiliser n’importe quel workflow existant (y compris un workflow contenant lui-même de la logique complexe, des accès base de données, ou un autre appel IA) sans dupliquer sa logique dans un simple appel HTTP ou un bout de code. C’est aussi la brique qui permet de construire une hiérarchie d’agents : un toolWorkflow peut pointer vers un workflow qui contient lui-même un AI Agent spécialisé — un agent « routeur » qui délègue à des agents « experts ».

Le champ qui décide de tout : nom et description

C’est le point le plus mal compris de l’AI Agent en n8n : le modèle ne voit jamais votre configuration. Il ne lit ni l’URL appelée par le HTTP Request Tool, ni le code du Code Tool, ni le contenu du workflow branché en Workflow Tool. Il ne voit que deux champs texte — le nom de l’outil et sa description — et c’est à partir de ces deux champs qu’il décide s’il doit l’appeler, quand, et avec quelles données.

Une description vague comme « Appelle l’API » ou « Traite les données » condamne l’outil à être ignoré, ou pire, appelé au mauvais moment avec des paramètres inventés. Une bonne description répond à trois questions en une ou deux phrases :

• Quand faut-il l’appeler ? (« après chaque réponse validée par l’utilisateur », « quand la question porte sur la documentation interne »)
• Quelles données attend-elle ? (les noms de champs, leur format)
• Que renvoie-t-elle ?, si le résultat doit nourrir un raisonnement ultérieur.

Reprenons l’exemple du Pack Conformité & Audit : la description du toolHttpRequest d’enregistrement n’est pas « Enregistre en base », mais « Enregistre une réponse validée du questionnaire dans Supabase. Appelle cet outil après CHAQUE réponse de l’utilisateur validée, avec l’identifiant du dossier, l’intitulé numéroté de la question et la réponse reformulée. » Chaque mot compte : le « CHAQUE » en majuscules force la systématicité, et la liste des trois champs attendus évite que l’agent en omette un.

La même logique s’applique à un outil de recherche documentaire : notre guide RAG avec n8n et Supabase pgvector recommande exactement ce nommage explicite pour le Vector Store branché en mode outil — « Recherche dans la documentation interne de l’entreprise » suffit à l’agent pour savoir quand déclencher une recherche plutôt que répondre de mémoire.

Combien d’outils sur un seul agent ?

Ajouter des outils un à un semble sans risque — jusqu’à ce que l’agent commence à en confondre deux, ou à en ignorer un pertinent noyé dans une liste trop longue. En pratique, la fiabilité de sélection reste bonne jusqu’à 5 à 7 outils sur un même agent ; au-delà, il faut muscler nettement le systemMessage pour lever les ambiguïtés entre outils aux périmètres proches.

Deux stratégies pour scaler sans dégrader la précision :

1. Des descriptions qui s’excluent mutuellement. Si deux outils peuvent répondre à la même intention (par exemple « chercher un client » côté CRM et côté facturation), précisez le périmètre exact de chacun dans sa description plutôt que de compter sur le contexte de la conversation.
2. Découper en plusieurs agents spécialisés. Un agent « routeur » avec peu d’outils larges, dont l’un est un AI Agent Tool (toolAiAgent) ou un Workflow Tool pointant vers un sous-agent expert (facturation, support, conformité). Chaque sous-agent garde une liste d’outils courte et cohérente, ce qui préserve la précision de sélection à chaque niveau.

Depuis la version Tools Agent (typeVersion 1.7+)

Depuis les versions récentes de l’AI Agent, l’agent est par défaut un Tools Agent : la sélection d’outil s’appuie sur le function calling natif du modèle (OpenAI, Anthropic, etc.) plutôt que sur un parsing de texte fragile. C’est ce mécanisme qui rend les descriptions d’outils si déterminantes — elles sont transmises telles quelles au modèle comme définitions de fonctions, dans le même format que celui utilisé pour connecter Claude ou GPT à n8n. Le paramètre maxIterations (10 par défaut) plafonne le nombre de cycles raisonnement → appel d’outil → analyse du résultat avant que l’agent ne soit forcé de répondre ; abaissez-le si vos outils sont coûteux ou lents.

Sécuriser un agent qui agit

Un agent capable d’appeler un toolHttpRequest en écriture — un POST, un PATCH, un DELETE — n’est plus un simple générateur de texte : c’est un système qui déclenche des effets de bord réels, potentiellement sur la foi d’une hallucination. Trois précautions concrètes :

• Limitez les droits de la clé API utilisée par l’outil au strict périmètre nécessaire (une clé qui ne peut qu’insérer dans une table précise, plutôt qu’une clé admin partagée avec le reste du workflow).
• Validez côté API, pas seulement côté prompt : un champ obligatoire manquant ou un format invalide doit être rejeté par l’endpoint appelé, pas seulement « demandé gentiment » dans la description de l’outil.
• Ajoutez un point d’approbation humaine avant les actions les plus sensibles (envoi d’email externe, paiement, suppression) plutôt que de laisser l’agent agir seul — le pattern du node Wait avec des boutons Slack, détaillé dans notre article sur l’approbation humaine dans n8n, s’insère naturellement entre la décision de l’agent et l’exécution de l’outil.

Côté fiabilité, un appel d’outil qui échoue (API en panne, timeout) ne doit pas planter tout le workflow : les mêmes mécanismes de reprise que pour n’importe quel node — décrits dans notre guide gérer les erreurs dans n8n — s’appliquent aux sub-nodes d’outil.

Observer ce que l’agent a réellement appelé

Dans le panneau d’exécution de n8n, chaque appel d’outil apparaît comme une entrée distincte sous le node AI Agent, avec les paramètres exacts envoyés par le modèle et la réponse reçue. C’est le premier réflexe de débogage quand un agent se comporte mal : avant de suspecter le modèle, vérifiez ce qu’il a réellement transmis à l’outil — un champ mal nommé dans le schéma du Code Tool, ou une description ambiguë, expliquent l’immense majorité des comportements inattendus.

En résumé

Un AI Agent n8n n’est aussi capable que les outils qu’on lui branche — et un outil n’est aussi utile que sa description. HTTP Request Tool pour parler à une API existante, Code Tool pour une logique métier propre, Workflow Tool pour réutiliser ou hiérarchiser des workflows entiers : les trois couvrent la quasi-totalité des cas, à condition de soigner le nom et la description de chacun comme on soignerait un contrat d’interface. Nos Pack Inbox IA et Pack Conformité & Audit livrent plusieurs de ces outils déjà configurés et documentés — un bon point de départ pour voir le pattern tourner sur un cas réel avant de l’adapter au vôtre.