Envoyer des mises à jour de statut intermédiaires à l'utilisateur sans nœuds Chat supplémentaires ?

Questions
, , , , , , , ,
1

Bonjour à tous,

J’ai actuellement un workflow AI/chat plus important dans n8n où certaines requêtes peuvent prendre un peu plus de temps à se terminer.

Pour améliorer l’UX, j’ai ajouté plusieurs nœuds Chat qui envoient des mises à jour de statut intermédiaires comme :

  • « Recherche d’articles en cours… »

  • « Traitement de la requête en cours… »

  • « Plusieurs correspondances trouvées… »

Le problème est que chaque nœud Chat supplémentaire augmente notablement le temps d’exécution du workflow.
Dans mon cas, le temps d’exécution a augmenté d’environ 20 % simplement à cause de ces messages intermédiaires.

Ma question est donc :

Y a-t-il un moyen d’envoyer des mises à jour de progression/statut intermédiaires à l’utilisateur pendant l’exécution du workflow SANS utiliser de nœuds Chat supplémentaires ?

Maybe via:

  • Nœud Code

  • Streaming de réponse webhook

  • événement frontend personnalisé

  • SSE/WebSocket

  • hooks d’exécution

  • ou une autre approche légère ?

Mon objectif est essentiellement :

  • maintenir le workflow réactif

  • fournir un retour de progression en direct

  • éviter de ralentir significativement le workflow

Comment gérez-vous cela dans les workflows AI/chat plus importants ?

Merci beaucoup !

2

Bonjour @Leon22
Dans mon expérience, dans le chat natif de n8n je n’ai pas encore vu de moyen générique d’envoyer un statut intermédiaire sans nœuds Chat ou streaming pris en charge ; quand j’ai besoin de quelque chose de plus léger, j’ai l’habitude de déplacer la progression vers un frontend externe via polling/SSE/WebSocket.

3

Ajouter un nœud de code n’aidera pas vraiment ici. Il faudra toujours faire le même appel sous-jacent avec la même surcharge.

Si vous préférez rester dans l’interface de chat native de n8n, la solution la plus rapide est d’être sélectif, en passant de 5 mises à jour de statut à environ 2. Si cela se fait à des points de contrôle significatifs, cela récupérera la plupart de ces 20% sans avoir besoin de grands changements architecturaux.

Si vous contrôlez votre frontend, SSE est la solution à long terme correcte que vous avez mentionnée. Comment est votre configuration actuelle? Cela déterminera quel chemin est le plus réaliste.