Tester un agent IA n8n avec Claude avant de le livrer

Pour tester un agent IA construit dans n8n, connectez Claude à votre instance par le MCP officiel de n8n : il exécute le workflow sur des scénarios concrets, analyse les exécutions et suggère des ajustements. Vous trouvez le bug avant votre client, et non après la livraison. Dans la vidéo, Claude a détecté une erreur 500 que mon workflow ne gérait pas, puis il l’a corrigée.

20:25

Pourquoi tester à la main ne tient plus sur un projet client

Sur un projet d’automatisation, le test prend plus de temps que la construction : il faut faire passer le workflow sur tous les cas métier du client, un par un, et vérifier chaque sortie.

À la main, vous testez trois cas, ceux qui vous viennent en tête. Le client, lui, en a vingt. Le jour où l’API d’en face répond une erreur, c’est lui qui la découvre.

Avec Claude branché sur n8n, vous avez un testeur qui exécute les cas à votre place, dans 80 à 90 % des situations, et qui vous rend les résultats. Vous gardez la décision, il fait les allers-retours.

Si vous débutez avec n8n, lisez d’abord le guide n8n et comment construire un workflow n8n. Pour la différence entre un workflow et un agent, voyez ce qu’est un agent IA.

Ce qui a changé depuis la vidéo (vérifié le 27 octobre 2026)

La vidéo date de décembre 2025, sur n8n 1.121.2. J’ai relu la documentation de n8n le 27 octobre 2026. La méthode tient ; les écrans et les droits ont bougé.

Deux changements comptent pour un projet client. test_workflow fait tourner le workflow sur des données épinglées sans appeler les services externes : aucun email ne part chez les clients de votre client, aucun crédit d’API ne brûle. Et Claude peut maintenant modifier vos workflows, ce qui demande des règles (plus bas).

Étape 1 : activer le MCP de n8n et exposer le workflow

1. Mettez votre instance à jour (sur n8n Cloud : Admin Panel > Manage, dernière version stable).
2. Dans Settings > Instance-level MCP, activez l’accès MCP.
3. Exposez le workflow à tester : menu de sa carte dans la liste, puis « Enable MCP access », ou depuis ses réglages dans l’éditeur.
4. Écrivez sa description. C’est l’étape que tout le monde saute.

Le serveur MCP montre vos workflows à l’extérieur. L’IA qui l’interroge ne sait pas ce que fait chacun : elle lit la description. Sans elle, Claude choisit au hasard.

Pour le workflow de mannequins de la vidéo (celui de l’article sur le mannequin IA), j’ai écrit :

Génère des mannequins IA personnalisés selon vos critères : type de photo,
type de prise de vue, genre, perspective, âge, ethnicité, morphologie et style.
Crée des modèles photoréalistes prêts à porter vos produits. Idéal pour tester
différents profils avant de produire des visuels e-commerce.

Le workflow de shooting a eu la sienne : 18 variations par photo produit, mannequin complet, focus produit, pose fashion. Les deux apparaissent ensuite dans la page MCP de l’instance, description comprise.

Étape 2 : connecter Claude à votre instance

Dans Claude Desktop : le bouton « Recherche et outils », puis « Ajouter des connecteurs », puis n8n. Collez l’URL de votre serveur MCP (elle s’affiche dans les réglages de n8n), puis autorisez la connexion dans la fenêtre qui s’ouvre.

Dans la vidéo, Claude a obtenu trois droits : exécuter des workflows, lire leurs détails, les rechercher. Aujourd’hui la liste est plus longue, et la même instance se branche aussi sur Claude Code, Claude.ai ou Cursor. Deux limites de la documentation : tous les clients connectés voient les mêmes workflows, et un client cloud comme Claude.ai exige une instance accessible depuis Internet.

Si le protocole MCP vous est nouveau, l’article sur les MCP dans Claude Code l’explique en partant de zéro.

Étape 3 : faire tourner les cas du client

Premier essai, sans préparation :

Peux-tu exécuter l’un de mes workflows n8n qui génère des versions de mannequin pour moi ?

Claude a trouvé le bon workflow grâce à sa description, puis lu ses détails. L’entrée était un formulaire n8n : il a repéré les champs à remplir et me les a demandés. Votre workflow n’a donc pas besoin d’un format spécial. Formulaire, webhook : le MCP sait l’appeler.

Je lui ai demandé un mannequin « selon le cas le plus courant en Europe ». Il a choisi les critères, lancé le workflow, qui a rendu 6 images, et m’a donné les liens.

Le deuxième prompt est plus utile, parce qu’il teste la liste du client au lieu d’un seul cas :

Prends les 5 cas les plus fréquents pour ce workflow. Lance-le avec chacun,
puis rends-moi un tableau : entrée, résultat attendu, résultat obtenu, écart.

C’est le plus fiable quand le résultat est déterministe : un calcul, un fichier déposé dans un dossier précis, une ligne ajoutée dans une base. Claude vérifie lui-même l’écart. Pour une sortie libre (un texte, une image), il vous montre le résultat et vous jugez.

Sur un workflow qui écrit chez le client (CRM, emails, facturation), préférez test_workflow avec des données épinglées : le test passe, rien ne sort.

Étape 4 : lire l’exécution qui casse et la corriger

Ensuite, j’ai demandé : « Est-ce que tu penses qu’il y a des améliorations possibles sur ce workflow ? »

Claude a lu l’exécution et en a sorti quatre pistes. La plus juste : mon prompt générait 6 fois le même mannequin, il fallait un nœud qui varie le prompt au départ. Les autres : gestion d’erreur, traitement par lots plutôt qu’un par un, métadonnées enrichies.

Puis le cas que je connaissais. Parfois, l’API qui génère les images ne répond pas et renvoie une erreur 500. Mon workflow ne la gérait pas. J’ai collé à Claude le JSON de l’exécution en échec. Son diagnostic : le workflow traitait les statuts successFlag 1 et 0, jamais le 3.

Sa correction, que j’ai collée dans l’éditeur de n8n :

• un switch modifié pour envoyer les erreurs vers une branche à part ;
• un nouvel appel au bout de 5 secondes, puis 10, puis 20 (délai exponentiel), pour ne pas marteler une API déjà tombée ;
• 3 tentatives au maximum, puis le mannequin est sauté ;
• chaque échec écrit dans Airtable, avec une note dans le workflow qui explique ce qui a été ajouté.

Après le collage, des points d’interrogation sont apparus sur les connexions : un bug d’affichage de n8n, elles étaient bien en place. Ensuite, relancez vous-même le workflow pour vérifier qu’il fait ce qui est prévu. Ça, je ne le délègue pas.

La règle de prudence : Claude propose, vous appliquez

Avant le MCP officiel, un nœud communautaire branchait déjà Claude à n8n, avec le droit de tout modifier. Si l’IA part en hallucination, vous perdez le travail. Même à 5 ou 10 % de risque, dans l’entreprise d’un client, je ne le fais pas et je ne vous le conseille pas.

Le MCP officiel peut maintenant créer et modifier des workflows lui aussi. Ma règle ne change pas :

• Claude teste, lit et propose ; vous appliquez la correction vous-même, comme dans la vidéo avec le JSON collé.
• S’il doit modifier, il travaille sur une copie du workflow, jamais sur la version en production.
• restore_workflow_version existe pour revenir en arrière : vérifiez qu’il y a une version saine avant de lui laisser la main.

Pour les clients, je déploie sur n8n Cloud quand rien n’impose l’auto-hébergement : il est sécurisé et mis à jour, et ces soucis sortent de votre liste comme de celle du client.

Les évaluations n8n : le jeu de tests qui reste chez le client

Claude via le MCP sert à explorer et à corriger. Les évaluations de n8n servent à rejouer le même jeu de tests à chaque modification, pour vérifier que la correction d’hier n’a rien cassé.

Le principe, d’après la documentation :

• Le dataset : une data table n8n ou un Google Sheets, une ligne par cas, avec l’entrée et souvent la sortie attendue.
• Le déclencheur Evaluation fait passer chaque ligne dans le workflow.
• Le nœud Evaluation calcule les scores (Set Metrics). Son action « Check if evaluating » évite de les calculer en production, donc d’en payer le coût.

Les métriques intégrées :

Vous pouvez ajouter vos propres métriques. Pour un agent qui répond aux questions à partir des documents du client (un RAG), Correctness sur 30 questions dont vous connaissez la réponse vous dit vite s’il invente.

Deux niveaux existent. L’évaluation légère, avant le déploiement : quelques cas, une comparaison à l’œil, sans métrique. L’évaluation à métriques : sur n8n Cloud Pro, Cloud Enterprise et l’Enterprise auto-hébergé, et pour un seul workflow sur les offres Community (compte enregistré) et Starter. Le nombre de cas testés en parallèle va de 1 à 5 selon l’offre.