Aller au contenu
Tous les projets

Outil · Projet personnel · en développement

Banc d'essai n8n

Savoir si un workflow est livrable avant de le livrer

Capture d'écran de Banc d'essai n8n

Un laboratoire qui fait tourner un workflow n8n sous instruments, simule ses appels externes et rend un verdict argumenté sur sa conformité, exigence par exigence.

Le besoin

Un workflow n8n qui marche en démo peut casser en production : un service qui répond autrement, un email parti par erreur, un coût qui explose. Il fallait un moyen de répondre à « est-ce que je peux livrer ça ? » autrement que par « on verra bien ».

Ce que fait le banc

  • Importe un workflow et l’exécute sur une instance n8n dédiée, en partant de n’importe quel déclencheur avec une charge de test
  • Anime le graphe nœud par nœud et montre ce que chaque nœud a réellement produit
  • Fait passer tous les appels sortants par un proxy : enregistrement, rejeu simulé où rien ne sort, ou mode réel encadré. Il dit aussi ce qui échappe à cette promesse (un nœud Postgres ou SMTP ne passe pas par le proxy)
  • Rattache chaque appel sortant au nœud qui l’a émis, grâce aux traces OpenTelemetry de n8n
  • Juge le résultat avec des assertions déterministes : conforme, non conforme ou « non mesuré », qui n’est jamais compté comme une réussite
  • Joue des suites de cas contre une version précise et montre ce qui a changé d’une version à l’autre

Les captures montrent un cas d’étude fictif, le traitement des demandes entrantes d’une agence immobilière : 24 nœuds (HubSpot, Slack, Brevo), 8 jeux de données, 5 jeux de stubs dont 4 pannes, et une suite de 11 cas.

Où en est le projet

37 chantiers sur 49. Les jalons observer, importer et paramétrer sont terminés. Le jalon en cours est le jugement : les suites se jouent déjà ; restent la régression, les agrégats, le coût et le rapport.

Technique

Backend Fastify et PostgreSQL, front React avec React Flow, proxy sortant maison, n8n 2.36 instrumenté via OpenTelemetry, le tout dans Docker Compose. Les définitions de test (jeux de données, stubs, assertions, suites) vivent en fichiers versionnés dans le dépôt. 550 tests unitaires.

Conçu pour tourner uniquement sur le poste de chaque développeur, le banc n’est pas mis en ligne.

En images

Le graphe d'une exécution : le chemin réellement parcouru en vert, les branches qui ne l'ont pas été en gris, la durée et le nombre d'items de chaque nœud.
Le graphe d'une exécution : le chemin réellement parcouru en vert, les branches qui ne l'ont pas été en gris, la durée et le nombre d'items de chaque nœud.
Chaque appel sortant rangé sous le nœud qui l'a émis. En simulé, les réponses viennent du jeu de stubs, et la page dit ce qui n'a pas pu être testé.
Chaque appel sortant rangé sous le nœud qui l'a émis. En simulé, les réponses viennent du jeu de stubs, et la page dit ce qui n'a pas pu être testé.
Ce qui change entre deux versions d'un workflow, jusqu'aux lignes de code modifiées, et le lancement avec son mode (simulé, enregistrement, réel encadré).
Ce qui change entre deux versions d'un workflow, jusqu'aux lignes de code modifiées, et le lancement avec son mode (simulé, enregistrement, réel encadré).
L'inventaire avant lancement : points de départ, credentials attendues et nœuds aux effets irréversibles.
L'inventaire avant lancement : points de départ, credentials attendues et nœuds aux effets irréversibles.
Les exécutions d'une campagne, cas par cas, sur deux versions du même workflow.
Les exécutions d'une campagne, cas par cas, sur deux versions du même workflow.