Une recette gère une tâche. Un workflow chaîne des tâches ensemble. Mais certaines automatisations dépassent un seul workflow — elles s’exécutent pendant des minutes ou des heures, coordonnent plusieurs flux de travail parallèles et doivent survivre aux pannes gracieusement.
Les playbooks sont la réponse de JieGou à cela. Ils exécutent des workflows comme agents de fond asynchrones avec checkpointing intégré, reprise après crash et contrôle de concurrence.
Ce qui rend les playbooks différents
L’exécution standard de workflow s’exécute de manière synchrone. Le client attend le résultat. Cela fonctionne bien pour les workflows qui se terminent en quelques secondes à quelques minutes. Mais pour une automatisation à 30 étapes qui traite un lot de documents, enrichit les données de trois sources externes, attend une approbation et génère un rapport final — l’exécution synchrone atteint des limites pratiques.
L’exécution de playbook est asynchrone. Vous démarrez le playbook et obtenez un ID d’exécution immédiatement. L’exécution continue en arrière-plan. Vous pouvez vérifier la progression à tout moment, et le système vous notifie quand c’est terminé.
Checkpointing au niveau nœud
La différence architecturale clé est le checkpointing. Après la complétion réussie de chaque étape, le playbook persiste son état — toutes les sorties d’étapes, la position actuelle dans le graphe d’exécution et tout contexte de boucle ou de branche.
Si un playbook crashe en cours d’exécution — un redémarrage de serveur, une panne d’infrastructure transitoire, un timeout sur un service externe — il ne redémarre pas à zéro. Il reprend depuis le dernier checkpoint, continuant là où il s’est arrêté. Les étapes déjà terminées ne sont pas ré-exécutées.
C’est important pour les automatisations de longue durée où ré-exécuter les étapes terminées gaspille du temps et de l’argent (les appels LLM ne sont pas gratuits) et peut causer des effets de bord (vous ne voulez pas envoyer le même email deux fois).
Contrôle de concurrence
Les playbooks gèrent les branches parallèles en toute sécurité. Quand un playbook atteint une étape parallèle, chaque branche s’exécute indépendamment avec une gestion appropriée de la concurrence. Les verrous de ressources empêchent les opérations conflictuelles, et le playbook suit quelles branches sont terminées pour s’assurer que l’étape parallèle ne se termine que quand toutes les branches sont complètes.
Streaming de progression
Pendant qu’un playbook s’exécute en arrière-plan, l’UI diffuse des mises à jour de progression en temps réel. Vous pouvez voir :
- Quelle étape est en cours d’exécution
- Quelles étapes sont terminées (avec des aperçus de sortie)
- Quelles étapes sont en attente
- Le temps restant estimé basé sur les données d’exécution historiques
C’est la même vue de progression utilisée pour les workflows synchrones, mais elle se met à jour de manière asynchrone via polling plutôt qu’une connexion de longue durée.
Réessai et reprise
Quand une étape de playbook échoue, le système applique la stratégie de réessai standard (backoff exponentiel, nombre maximum de tentatives configurable). Si les réessais sont épuisés et que l’étape échoue de manière permanente, le playbook se met en pause avec un statut d’erreur.
Depuis l’état en pause, vous avez trois options :
- Réessayer l’étape échouée (après avoir corrigé le problème sous-jacent, comme une clé API révoquée)
- Ignorer l’étape échouée et continuer à la suivante
- Annuler le playbook entièrement
La capacité de reprendre après un échec — plutôt que de redémarrer depuis le début — est ce qui rend les playbooks pratiques pour les automatisations complexes et multi-étapes.
Quand utiliser les playbooks vs. les workflows
Utilisez les workflows standard quand :
- L’exécution se termine en moins de 5 minutes
- Vous avez besoin du résultat immédiatement (réponse synchrone)
- Le workflow est déclenché par une action utilisateur et l’utilisateur attend la sortie
Utilisez les playbooks quand :
- L’exécution prend plus de quelques minutes
- L’automatisation implique de nombreuses étapes ou de gros volumes de données
- La reprise après crash est importante (le coût de redémarrage est élevé)
- L’automatisation s’exécute en arrière-plan (planifiée, déclenchée ou fire-and-forget)
Partage et analytique
Les exécutions de playbook supportent le même modèle de partage que les exécutions de workflow — visibilité privée, département, compte ou groupe. Les membres de l’équipe peuvent voir la progression, inspecter les sorties d’étapes et revoir les exécutions terminées selon leur niveau d’accès.
L’analytique des playbooks montre la fréquence d’exécution, les taux de succès, la durée moyenne et le coût par exécution. Cela vous aide à identifier quels playbooks sont les plus précieux et lesquels nécessitent une optimisation.
Les playbooks sont disponibles sur les plans Enterprise. En savoir plus sur les playbooks ou contactez-nous pour un accès Enterprise.