Guide de création de workflows automatisés avec OpenFang : du simple agent à l'équipe d'agents

Slug : openfang-workflow-automation-guide Catégorie : usage-guides (Guides d'utilisation) Mots-clés cibles : workflow OpenFang, processus d'automatisation OpenFang, orchestration Multi-Agent OpenFang Intention de recherche : Informationnelle (l'utilisateur souhaite construire des processus d'automatisation d'agents complexes) Nombre de mots cible : ~2000 mots Langue : fr

Pourquoi utiliser des workflows ?

Les tâches qu'un agent unique peut accomplir sont limitées. Lorsque vous avez besoin d'un processus de bout en bout tel que "rechercher un sujet → rédiger un article → vérifier les faits → publier → surveiller les retours", vous devez orchestrer plusieurs agents au sein d'un workflow.

Le moteur de workflow d'OpenFang prend en charge trois modes d'orchestration : le pipeline séquentiel (Pipeline), la distribution parallèle (Fan-out) et le branchement conditionnel (Conditional). Vous pouvez assembler des Hands et des agents comme des briques LEGO pour créer des processus d'automatisation complexes.

Cet article vous accompagne à travers quatre cas réels pour maîtriser la création de workflows OpenFang, du plus simple au plus complexe.

Concepts clés des workflows

Avant d'entrer dans les cas pratiques, familiarisons-nous avec quelques concepts fondamentaux :

Concept	Description
Task	L'unité d'exécution minimale du workflow, une tâche correspond à un Hand ou un Agent
Pipeline	Enchaîne plusieurs tâches, la sortie de la tâche précédente devient automatiquement l'entrée de la suivante
Fan-out	Distribue une tâche à plusieurs agents pour un traitement parallèle, puis agrège les résultats
Trigger	La source d'événement qui déclenche le workflow : planification, Webhook, modification de fichier, commande de message
Context	État partagé transmis entre les étapes du workflow, similaire à la portée des variables dans les langages de programmation

Cas n°1 : Revue de presse quotidienne (Pipeline simple)

Il s'agit du workflow Pipeline le plus simple : générer automatiquement une revue de presse chaque matin :

[[workflows]]name = "daily_industry_briefing"description = "Génère une revue de presse quotidienne à 8h"[workflows.trigger]type = "schedule"cron = "0 8 * * 1-5"             # 8h du matin en semaine[[workflows.tasks]]id = "monitor"hand = "collector"config = { keywords = ["AI agent", "Rust framework"], sources = ["news", "github"] }timeout = 300[[workflows.tasks]]id = "summarize"hand = "researcher"config = { depth = "shallow", focus = "summary" }depends_on = ["monitor"]timeout = 600[[workflows.tasks]]id = "notify"channel = "slack"config = { channel = "#industry-news", format = "rich_text" }depends_on = ["summarize"][workflows.output]format = "slack_message"save_to = "workspace/briefings/{{date}}.md"

L'exécution du workflow est : Collecte (Collector) → Résumé (Researcher) → Notification Slack. depends_on définit les relations de dépendance entre les tâches.

Cas n°2 : Surveillance et alertes concurrentielles (Parallèle + Agrégation)

Ce workflow surveille simultanément les activités de plusieurs concurrents et agrège les résultats collectés en parallèle pour analyse :

[[workflows]]name = "competitor_monitor"description = "Surveillance parallèle de 5 sites concurrents, agrégation et envoi d'alertes"[workflows.trigger]type = "schedule"cron = "0 */6 * * *"# Étape 1 : Collecte parallèle (Fan-out)[[workflows.tasks]]id = "check_competitor_a"hand = "collector"config = { target = "competitor-a.com", mode = "diff" }[[workflows.tasks]]id = "check_competitor_b"hand = "collector"config = { target = "competitor-b.com", mode = "diff" }[[workflows.tasks]]id = "check_competitor_c"hand = "collector"config = { target = "competitor-c.com", mode = "diff" }# Étape 2 : Agrégation et analyse (attend la fin de toutes les collectes)[[workflows.tasks]]id = "aggregate"hand = "researcher"config = { action = "merge_and_prioritize" }depends_on = ["check_competitor_a", "check_competitor_b", "check_competitor_c"]# Étape 3 : Jugement conditionnel — notifier uniquement en cas de changement important[[workflows.tasks]]id = "check_significance"hand = "predictor"config = { action = "assess_impact" }depends_on = ["aggregate"]# Étape 4 : Notification conditionnelle[[workflows.tasks]]id = "alert_high"channel = "telegram"config = { chat_id = "-100xxx", priority = "high" }depends_on = ["check_significance"]condition = "ctx.significance_score > 0.7"[[workflows.tasks]]id = "alert_low"channel = "email"config = { to = "[email protected]", priority = "low" }depends_on = ["check_significance"]condition = "ctx.significance_score <= 0.7"

Les modèles clés ici sont :

Fan-out : Les 5 tâches de collecte de l'étape 1 s'exécutent en parallèle, sans depends_on.
Barrier : La tâche Aggregate de l'étape 2 dépend de la réussite des 5 collectes.
Conditional : L'étape 4 choisit différents canaux de notification selon le score d'importance.

Cas n°3 : Pipeline de production de contenu (Collaboration multi-agents)

C'est le scénario classique de collaboration multi-agents : rédaction par IA, vérification par IA, illustration par IA :

[[workflows]]name = "content_pipeline"description = "Pipeline de production de contenu entièrement automatisé, du sujet à la publication"[workflows.trigger]type = "webhook"endpoint = "/webhook/content/new"secret = "${WEBHOOK_SECRET}"# Étape 1 : Recherche[[workflows.tasks]]id = "research"hand = "researcher"config = {  depth = "deep",  source_types = ["academic", "news", "social"],  target_length = "3000_words"}timeout = 900# Étape 2 : Rédaction (utilisation de différents modèles)[[workflows.tasks]]id = "draft"hand = "researcher"              # Réutilisation du Hand Researcher, mais avec un prompt différentconfig = {  model = "claude-opus-4-8",  instruction = "draft_article",  style = "professional_yet_approachable"}depends_on = ["research"]# Étape 3 : Vérification des faits[[workflows.tasks]]id = "fact_check"hand = "researcher"config = {  model = "claude-haiku-4-5",   # Utilisation d'un modèle rapide pour la vérification  action = "verify_claims",  strictness = "high"}depends_on = ["draft"]# Étape 4 : Génération d'image de couverture[[workflows.tasks]]id = "generate_cover"hand = "clip"config = {  action = "generate_cover_image",  style = "modern_tech",  resolution = "1280x720"}depends_on = ["draft"]           # Ne dépend pas de la vérification des faits, peut être parallèle# Étape 5 : Optimisation SEO[[workflows.tasks]]id = "seo_optimize"hand = "researcher"config = { action = "seo_optimize", target_keyword = "{{.keyword}}" }depends_on = ["fact_check"]# Étape 6 : Publication[[workflows.tasks]]id = "publish"channel = "webhook"config = { url = "{{.cms_endpoint}}", method = "POST" }depends_on = ["seo_optimize", "generate_cover"]# Étape 7 : Promotion[[workflows.tasks]]id = "promote"channel = "twitter"config = { action = "post_thread", hashtags = ["#AI", "#Automation"] }depends_on = ["publish"]

Notez que generate_cover à l'étape 4 ne dépend que de draft et non de fact_check — cela signifie que la génération d'image et la vérification des faits s'exécutent en parallèle, réduisant le temps d'attente global.

Cas n°4 : Classification et escalade du support client (Routage conditionnel)

Il s'agit d'un workflow de support client intelligent qui route automatiquement les demandes vers les processus de traitement appropriés selon le type de problème :

[[workflows]]name = "support_triage"description = "Support client intelligent : Classification → Routage → Traitement → Escalade"[workflows.trigger]type = "message"channel = "whatsapp"pattern = "/help *"# Classification[[workflows.tasks]]id = "classify"hand = "researcher"config = {  model = "claude-haiku-4-5",  action = "classify_intent",  categories = ["billing", "technical", "feature_request", "complaint"]}# Facturation → Système de requête[[workflows.tasks]]id = "handle_billing"channel = "webhook"config = { url = "https://billing-api.company.com/lookup" }depends_on = ["classify"]condition = "ctx.intent == 'billing'"# Technique → Recherche dans la base de connaissances[[workflows.tasks]]id = "search_kb"hand = "researcher"config = { action = "search_knowledge_base", max_results = 3 }depends_on = ["classify"]condition = "ctx.intent == 'technical'"# Demande de fonctionnalité → Enregistrement dans Product Board[[workflows.tasks]]id = "log_feature"channel = "webhook"config = { url = "https://productboard-api.company.com/notes" }depends_on = ["classify"]condition = "ctx.intent == 'feature_request'"# Plainte → Escalade immédiate vers un humain[[workflows.tasks]]id = "escalate"channel = "slack"config = { channel = "#urgent-support", mention = "@oncall" }depends_on = ["classify"]condition = "ctx.intent == 'complaint'"# Réponse finale[[workflows.tasks]]id = "reply"channel = "whatsapp"config = { reply_to = "{{.original_message.id}}" }depends_on = ["handle_billing", "search_kb", "log_feature", "escalate"]

Débogage et test de workflow

Avant le déploiement en production, il est recommandé d'utiliser le mode Dry Run pour tester vos workflows :

# Dry run (n'exécute pas réellement les actions externes)openfang workflow run competitor_monitor --dry-run# Exécuter uniquement jusqu'à une tâche spécifiqueopenfang workflow run content_pipeline --until draft# Voir l'historique d'exécution du workflowopenfang workflow history competitor_monitor --limit 10# Voir les logs détaillés d'une exécution spécifiqueopenfang workflow inspect competitor_monitor --run-id abc123

Bonnes pratiques pour les workflows

Définir des délais d'expiration (timeout) raisonnables : Chaque tâche doit avoir un timeout pour éviter qu'une étape ne bloque tout le processus.
Ajouter des mécanismes de réessai : Pour les tâches de requête réseau, configurez retry = 3 avec un backoff exponentiel.
Utiliser des conditions : Évitez l'exécution de tâches inutiles pour économiser les coûts d'appels API.
Enregistrer les logs d'exécution : Configurez log_level = "debug" pour le dépannage.
Surveiller la santé du workflow : Intégrez les métriques de workflow à Prometheus/Grafana.

FAQ

Combien de tâches un workflow peut-il supporter au maximum ?

Il n'y a pas de limite stricte. Cependant, il est conseillé de limiter un workflow à 20 tâches pour garantir sa maintenabilité. Les processus plus complexes doivent être divisés en sous-workflows.

Comment gérer l'échec d'une tâche ?

Chaque tâche peut configurer indépendamment une stratégie d'échec :

``toml [workflows.tasks.fallback] on_failure = "continue" # continue / retry / abort / escalate retry_count = 3 retry_delay_seconds = 60 fallback_task = "manual_review" # Tâche de secours après échec``

Les workflows peuvent-ils s'appeler entre eux ?

Oui. Utilisez trigger.type = "workflow" pour permettre à un workflow d'en déclencher un autre. Combiné avec des conditions, cela permet de réaliser une logique imbriquée complexe.

Comment transmettre des paramètres dynamiques dans un workflow ?

Utilisez la syntaxe de template {{.variable_name}}. Les variables de contexte proviennent des données transmises par le déclencheur, de la sortie des tâches précédentes et des variables de configuration globales.

Prochaines étapes

Guide de configuration des Hands OpenFang : Apprenez la configuration détaillée de chaque Hand.
Bonnes pratiques de sécurité OpenFang : Protégez vos workflows d'automatisation.