n8n Evaluations : tester et fiabiliser vos workflows IA avant qu'un client ne le fasse à votre place

Un workflow n8n classique, une fois testé, reste stable : le même input produit toujours le même output. Un workflow qui s'appuie sur un LLM n'a pas cette garantie. Vous changez un mot dans le prompt, vous passez de gpt-4o à un modèle plus économique, le fournisseur met à jour discrètement son modèle un mardi soir — et la qualité des réponses de votre chatbot RAG ou la justesse du tri de vos emails peut se dégrader sans qu'aucun node ne passe au rouge. Le workflow « fonctionne » toujours au sens technique ; il répond juste moins bien. C'est exactement le trou que comble la fonctionnalité Evaluations de n8n : un moyen natif de rejouer un jeu de test contre votre workflow IA et de mesurer, en chiffres, si une version vaut mieux qu'une autre.

Pourquoi un workflow IA a besoin d'un filet différent

Sur un workflow classique — synchronisation Supabase, envoi d'email, traitement d'un webhook — un test consiste à vérifier qu'une entrée donnée produit exactement la sortie attendue. Sur un workflow IA, la sortie change légèrement à chaque exécution par nature, et « correct » est souvent une question de degré plutôt qu'une égalité stricte : un résumé de réunion peut être bon sans être identique à un résumé de référence, une réponse de chatbot RAG peut être exacte tout en étant formulée différemment. Tester ce genre de comportement demande donc autre chose qu'un assert égal à : un jeu de cas représentatifs, une façon de noter chaque sortie, et un historique pour comparer les scores dans le temps. C'est le rôle des nodes Evaluation Trigger et Evaluation, disponibles nativement dans n8n.

Le node Evaluation Trigger et le principe du dataset

L'Evaluation Trigger démarre une exécution d'évaluation à partir d'un jeu de données stocké soit dans un Google Sheet, soit dans une Data Table n8n. Chaque ligne du dataset représente un cas de test : les colonnes d'entrée reproduisent ce que reçoit normalement votre workflow (le texte d'un email, la question posée au chatbot, le contenu d'une facture), et une ou plusieurs colonnes contiennent la sortie attendue ou des critères de référence.

Concrètement, pour le workflow de tri d'emails d'un Pack Inbox IA, un dataset minimal ressemble à :

email_source	categorie_attendue	urgence_attendue
« Facture impayée depuis 60 jours, dernier rappel »	administratif	haute
« Newsletter hebdo du fournisseur X »	newsletter	basse
« Le serveur de prod est down, besoin d'aide immédiate »	client	haute

Chaque ligne, rejouée à travers le workflow réel (ou une copie dédiée aux tests), donne une sortie que l'on compare ensuite à la colonne attendue.

Light evaluations vs metric-based evaluations : deux usages, un même outil

n8n distingue deux façons d'utiliser cette mécanique :

• Light evaluations — pensées pour le développement : vous relancez à la main un petit jeu de cas choisis pendant que vous ajustez un prompt, pour repérer immédiatement une régression évidente avant de committer le changement.
• Metric-based evaluations — pensées pour la production : elles tournent sur un dataset plus large, calculent des scores numériques stockés et historisés dans l'onglet Evaluations du workflow, et permettent de comparer objectivement deux versions dans le temps — après un changement de modèle, une refonte de prompt, ou une évolution de votre base documentaire RAG.

La bonne pratique consiste à utiliser les deux : light evaluations en boucle rapide pendant que vous itérez, metric-based evaluations comme filet de non-régression avant chaque mise en production d'un changement de prompt ou de modèle.

Choisir ses métriques

Le node Evaluation, en opération Set Metrics, calcule et enregistre un score par exécution. Les métriques les plus utiles couvrent deux familles :

• Les métriques exactes, rapides et sans coût IA supplémentaire :
  • Categorization — correspondance exacte entre la catégorie prédite et la catégorie attendue (1 ou 0), idéale pour un workflow de tri comme celui du Pack Inbox IA ;
  • String Similarity — score de proximité textuelle (0 à 1), utile quand une réponse doit rester proche d'une formulation de référence sans l'être mot pour mot.
• Les métriques jugées par IA (LLM-as-judge), pour les sorties où « correct » ne se réduit pas à une égalité :
  • Correctness — un modèle juge, sur une échelle de 1 à 5, si la réponse est factuellement exacte au regard d'une référence ;
  • Helpfulness — même principe, pour juger si la réponse répond réellement à la question posée, indépendamment de son exactitude stricte.

Pour un chatbot RAG comme celui du Pack Assistant RAG, Correctness est la métrique centrale : elle détecte le jour où le modèle commence à répondre à côté des documents ingérés plutôt qu'à partir d'eux — le symptôme précis que le prompt anti-hallucination décrit dans notre guide RAG avec Supabase pgvector est censé prévenir.

Construire un pipeline d'évaluation concret

Le montage type ressemble à ceci :

1. Evaluation Trigger — lit une ligne du dataset (Google Sheet ou Data Table).
2. Execute Sub-workflow — appelle le workflow métier réel (ou sa logique de génération de réponse), avec l'entrée de la ligne courante. Isoler la logique métier dans un sub-workflow, comme recommandé dans notre guide sur la piste d'audit RGPD, évite ici aussi de dupliquer le prompt entre le workflow de production et celui de test.
3. Evaluation → Set Metrics — compare la sortie obtenue à la sortie attendue et enregistre les scores (Correctness, Categorization, etc.).
4. Evaluation → Set Outputs (optionnel) — réécrit le résultat détaillé dans le Google Sheet, pour pouvoir relire manuellement les cas qui ont mal scoré.

Une fois ce montage en place, l'onglet Evaluations du workflow affiche l'historique des runs et leurs scores moyens — la vue qui permet de répondre objectivement à la question « ce changement de prompt a-t-il amélioré ou dégradé la qualité ? » sans se fier à une impression après trois essais manuels.

Détecter la dérive avant qu'un client ne le fasse

L'intérêt principal de ce dispositif n'est pas de valider un prompt une fois, mais de le rejouer à chaque changement : mise à jour de modèle côté fournisseur, ajustement du prompt, ajout de nouveaux documents dans la base RAG, changement de fournisseur IA (voir notre guide pour connecter Claude ou GPT à n8n si vous testez un changement de modèle). Un jeu de test de vingt à trente cas, relancé en quelques minutes, transforme une question qui prenait auparavant une relecture manuelle hasardeuse en une réponse chiffrée et reproductible. Et chaque incident réel signalé en production — une réponse fausse, une catégorisation ratée — devient un nouveau cas ajouté au dataset : le jeu de test grossit avec l'usage réel, pas seulement avec l'imagination de qui l'a écrit.

Pièges fréquents

• Un dataset qui ne couvre que les cas faciles : un jeu de test rempli uniquement d'exemples nets ne détecte jamais les régressions qui comptent, précisément sur les cas ambigus.
• Confondre light et metric-based evaluations : relancer à la main dix cas pendant le développement ne remplace pas un passage automatisé et historisé avant chaque mise en production.
• Un seul juge IA sans grille de notation explicite : un prompt de jugement vague (« note cette réponse sur 5 ») produit des scores peu reproductibles ; détaillez les critères comme vous le feriez pour un correcteur humain.
• Ne jamais relire les scores bas : un score qui baisse ne dit pas pourquoi — l'onglet Set Outputs, qui conserve la sortie complète, est ce qui permet de comprendre le cas raté plutôt que de le constater seulement.

Pour aller plus loin

Le Pack Assistant RAG (119 €) et le Pack Conformité & Audit (149 €) reposent tous deux sur des réponses générées par IA où la justesse compte directement — un chatbot documentaire, un rapport de synthèse d'audit. Mettre en place un dataset d'évaluation, même minimal, est le complément naturel une fois ces workflows en production : c'est ce qui vous permet de changer de modèle ou d'ajuster un prompt en confiance, sans attendre qu'un utilisateur remonte le problème. Si la fiabilité de vos automatisations IA est un sujet transverse à toute votre pile (tri d'emails, RAG, conformité), le Bundle FlowKit Complet (269 €) réunit les trois packs sur cette même exigence de base.