Orchestrer agents et LLM avec n8n et Dify

n8n excelle sur l’intégration système (webhooks, API, cron, GLPI). Dify excelle sur les apps IA (RAG, agents, prompts versionnés). Les combiner couvre 80 % des cas agentiques en entreprise.

Rôles respectifs

Outil	Force
n8n	Triggers, ETL, notifications, gestion d’erreurs, 400+ connecteurs
Dify	Chaînes LLM, knowledge bases, agents avec outils, UI de test

Pattern courant : n8n déclenche et route ; Dify raisonne et génère.

Architecture type

Cron / Webhook (n8n)
  → Récupérer données (RSS, ticket, CSV)
  → Appel API Dify (completion ou agent)
  → Post-traitement (format, validation)
  → Action (email, GLPI, rebuild site, Slack/SMS)

Bonnes pratiques n8n

Idempotence : même entrée → même effet (éviter doublons).
Error workflow : branche dédiée + alerte.
Credentials centralisés, jamais en clair dans les nœuds.
Sub-workflows pour les blocs réutilisables (ex. « appeler Dify + parser JSON »).

Bonnes pratiques Dify

Une app par cas d’usage (veille, support, rédaction).
Knowledge base séparée par domaine.
Prompt système versionné ; tester dans l’UI avant branchement n8n.
Exposer via API (/v1/chat-messages ou workflow run).

Lier les deux

Créer une app Dify avec clé API.
Dans n8n : nœud HTTP Request → POST vers Dify avec Authorization: Bearer ….
Parser la réponse JSON ; gérer timeout et retry (429, 5xx).
Logger conversation_id / message_id pour le debug.

Cas AI-Automate

Notre stack utilise ce duo pour :

pipeline veille (collecte n8n → synthèse Dify → wiki) ;
enrichissement glossaire ;
notifications et rebuild Astro via scripts shell appelés depuis n8n.

Le portail unifié regroupe l’accès opérationnel : portail.ai-automate.fr.

MCP en complément

Pour des outils dynamiques (fichiers, bases, APIs custom), exposez-les via MCP plutôt que de multiplier les nœuds HTTP. Dify et les agents Hermes peuvent consommer les mêmes serveurs MCP.