n8n : router, réparer et générer les workflows, avec des garde-fous

L'horloge (article précédent) remarque ; cet article agit. Deux workflows de notre réseau changent seuls l'état des machines : l'un aiguille une demande vers le bon modèle, l'autre répare un modèle qui a planté. Chacun est utile exactement tant que ses garde-fous tiennent.

1. Router : des mots simples au bon modèle

Un agent ou une personne demande en mots simples : « charge quelque chose de bon pour lire un très long document ». Le workflow :

1. Vérifie la signature. L'appelant signe le corps avec une clé HMAC partagée ; le nœud Crypto de n8n la recalcule sur le corps brut et refuse tout écart. Un webhook non signé est une porte.
2. Interroge le juge (Homelab 14) pour classer la demande dans une courte liste d'usages : code, long document, réponse rapide, vision… La classe de données est privée par défaut, donc rien ne part vers un modèle hébergé.
3. Applique des règles fixes : réutiliser ce qui sert déjà, ne jamais prendre la carte qu'utilise un jeu, refuser pendant qu'un modèle charge.
4. Agit, puis vérifie que le bon modèle répond vraiment. Sinon, une seule reprise après 25 secondes, jamais une boucle.
5. Écrit un événement avec l'issue, failed comme une erreur.

2. Réparer : recharger ce qui a planté, dans des limites

Quand le conteneur d'un modèle s'arrête, un événement le dit. Un workflow tourne chaque minute, lit les nouveaux événements avec un curseur (il se souvient du dernier traité, et garde 60 secondes de retard sur le plus récent pour ne pas lire des lignes à moitié écrites), et décide modèle par modèle. Ses règles viennent de l'action, pas de la confiance de qui que ce soit :

• une seule action est permise : recharger le modèle qui était déclaré, ce qui est réversible ;
• trois recharges du même modèle par heure au plus, puis un disjoncteur et l'appel à un humain ;
• si un autre modèle a été déclaré depuis, la perte est périmée : on l'ignore ;
• si un jeu tient la carte, on attend ;
• après chaque recharge, on vérifie, et on écrit healed ou failed.

3. Des workflows écrits par du code

Assembler des workflows à la souris dans l'éditeur ne passe pas à l'échelle, et ne se relit pas. Les plus importants des nôtres sont générés par de petits scripts Python qui écrivent le JSON du workflow : nœuds, connexions, le JavaScript des nœuds Code sous forme de simples chaînes. Un changement, c'est un diff dans un script, relu comme n'importe quel code ; le JSON est importé dans n8n, et chaque version est gardée dans un dossier de sauvegarde daté. Les reconstruire sur un n8n neuf, c'est relancer les scripts ; les workflows plus simples sont gardés en JSON exporté.

Pièges que nous avons payés

Le bac à sable des expressions de n8n refuse certains noms : un champ appelé caller a fait échouer un workflow. Renommez les champs plutôt que de lutter contre le bac à sable.

Un nœud qui se replie en silence est pire qu'un nœud qui échoue. Notre nœud de juge exigeait un champ que nous n'envoyions pas ; au lieu d'une erreur, la demande est partie par un autre chemin sans que personne le voie. Validez les entrées dans un nœud Code avant l'appel, et testez chaque branche.

Lancer un workflow depuis la ligne de commande de n8n échoue pendant que le serveur tourne (ils partagent un port). Testez par le webhook, ou par l'horloge.

Dans notre version, changer l'état actif d'un workflow ne prenait pas toujours effet avant un redémarrage de n8n. Après un changement, vérifiez que le workflow tourne vraiment.

Utile ? Dites-nous ce qu'il faut mesurer ensuite.