Orchestration de Workflows

Ce que contient ce pack

Ce pack rassemble les huit moteurs de workflow niveau-prod que les équipes IA utilisent quand un prompt-en-boucle ne suffit plus. Chacun résout le même trio — planifier, retry, observer — avec une ergonomie différente. Choisissez selon où vit déjà votre équipe (Python, Node, no-code, JVM).

Tous open source et auto-hébergeables. La plupart ont un tier SaaS, mais ce pack documente d'abord le chemin OSS.

Pourquoi l'orchestration compte pour les agents IA

Les prompts sont déterministes la première fois et un coup de dés après. Ajoutez une action réelle — appel API, écriture DB, message Slack — et « ça a échoué une fois à 3h du matin » devient un événement hebdomadaire. Un moteur de workflow résout trois choses :

1. Idempotence. Les steps peuvent rejouer en sécurité. Si l'appel LLM a réussi mais le step suivant a crashé, le retry ne re-facture pas l'API.
2. Backoff et dead-letter. Les steps en échec retentent en backoff exponentiel, puis tombent en DLQ pour inspection humaine.
3. Observabilité. Chaque step est enregistré avec inputs, outputs, latence, coût. Quand l'agent fait un truc bizarre, vous rejouez le contexte exact qu'il a vu.

Sans ça, votre agent est un Jupyter notebook avec des steps en plus. Avec ça, c'est un service.

Installer en une commande

# Installe le pack entier (manifestes des 8 moteurs)
tokrepo install pack/workflow-orchestration

# Ou choisir celui que votre équipe utilise
tokrepo install n8n
tokrepo install prefect
tokrepo install inngest

Le manifeste TokRepo vous donne des points de départ Docker Compose / Helm plus des défauts agent-friendly (clés d'idempotence, politiques de retry, hooks d'observabilité). Lancez tokrepo uninstall <slug> pour retirer.

Pièges courants

• Traiter les retries comme infinis. Les counts par défaut sur la plupart sont 3–5. Si votre fournisseur LLM a une mauvaise heure, vous brûlez le budget et échouez quand même. Cap à 3 pour appels LLM payants et routez l'échec vers un fallback plus lent.
• Clés d'idempotence mal faites. Erreur commune : utiliser request_id qui change à chaque retry. Utilisez un hash d'input pour que les retries déduplique contre la même tâche logique.
• Observabilité du coût des tokens manquante. Les orchestrateurs vanilla enregistrent la latence mais pas la dépense LLM. Wrappez l'appel modèle pour émettre tokens_in / tokens_out / cost_usd par step, sinon vous explosez le budget sans savoir quel workflow l'a fait.
• Mauvaise granularité de scheduler. Les moteurs cron-based (n8n, Activepieces) galèrent avec triggers sub-minute. Pour event-driven sub-seconde, utilisez Inngest, Trigger.dev ou Temporal.
• Héberger le moteur sur le même nœud que l'agent. Un agent emballé OOM-era l'orchestrateur. Lancez le moteur sur un nœud ou container séparé avec limites mémoire dures.

Quand ce pack seul ne suffit pas

L'orchestration de workflow est la couche durabilité. Elle ne donne pas l'agent lui-même, ni le gateway LLM, ni l'eval. Combinez avec :

• Python Agent Frameworks pour le code agent qui tourne dans chaque step
• MCP Server Stack si vous voulez que les triggers d'orchestrateur soient appelables par des agents IA via MCP
• LLM Eval & Guardrails pour intégrer un step d'eval dans chaque workflow avant que la sortie n'atteigne la prod

Ensemble ces quatre packs sont le stack minimum pour tout workflow IA que vous laisseriez tourner sans surveillance.