Concevoir des workflows qui échouent avec élégance

L’automatisation traditionnelle fonctionne ou ne fonctionne pas. Un zap Zapier déplace les données de A vers B — si l’appel API échoue, il retente. La sortie est la même à chaque fois.

Les workflows IA sont différents. Un modèle peut timeout sous charge. Une limite de débit peut throttler vos requêtes. La sortie peut être valide mais manquer la cible. Et parce que les workflows IA ont souvent plusieurs étapes, un échec à l’étape 3 ne devrait pas perdre les résultats réussis des étapes 1 et 2.

Concevoir pour ces réalités est la différence entre des workflows auxquels votre équipe fait confiance et des workflows qu’elle abandonne après la première mauvaise expérience.

Retries automatiques avec backoff

JieGou retente automatiquement les étapes de Recipe en échec avec un backoff exponentiel. Quand une étape échoue à cause d’une erreur transitoire — limites de débit (429), erreurs serveur (502, 503) ou timeouts — le système attend et retente, avec un backoff exponentiel (2s, 4s, 8s, jusqu’à 30s) avec un jitter aléatoire pour éviter les problèmes de ruée.

Vous configurez le nombre maximum de retries par étape. Pour la plupart des Recipes, 2-3 retries gère les erreurs transitoires sans retarder significativement le workflow. Pour les workflows à haut volume où les limites de débit sont courantes, vous pouvez définir des compteurs de retry plus élevés.

Les erreurs permanentes — entrée invalide, échecs d’authentification, refus de modèle — sautent les retries entièrement. Il n’y a aucun intérêt à retenter une requête qui échouera de la même façon à chaque fois.

La classification des erreurs est importante

Tous les échecs ne se valent pas. JieGou classifie les erreurs en catégories pour que le workflow puisse répondre de manière appropriée :

• Erreurs transitoires (retentables) : Limites de débit, surcharges serveur, timeouts réseau. Elles se résolvent d’elles-mêmes avec les retries.
• Erreurs permanentes (non retentables) : Entrée incorrecte, échecs d’authentification, violations de politique de contenu. Elles nécessitent une intervention humaine ou des changements d’entrée.
• Succès partiel : L’IA a renvoyé une sortie, mais elle ne correspond pas entièrement au schéma attendu. Le workflow peut continuer avec ce qu’il a ou signaler le problème pour revue.

Cette classification est automatique. Vous n’avez pas besoin d’écrire de logique de gestion d’erreurs — l’exécuteur sait quels codes de statut HTTP sont transitoires et lesquels sont permanents.

Les portes d’approbation comme filets de sécurité

Les étapes d’approbation ne sont pas seulement pour la validation des processus métier. Ce sont aussi des points de contrôle de fiabilité.

Placez une porte d’approbation après toute étape où la qualité de sortie est importante pour les étapes en aval. Par exemple :

1. Rechercher le prospect (étape Recipe)
2. Revoir la qualité de la recherche (porte d’approbation)
3. Rédiger la prise de contact basée sur la recherche (étape Recipe)

Si l’étape de recherche renvoie des résultats pauvres — peut-être que l’entreprise est petite et qu’il y a peu d’informations publiques — la porte d’approbation permet à un humain de décider s’il faut continuer avec ce qui est disponible ou fournir du contexte supplémentaire avant le brouillon de prise de contact.

Sans la porte, l’étape de prise de contact générerait un email basé sur une recherche incomplète, produisant un message générique qui annule l’intérêt de l’automatisation.

Les étapes de condition pour la validation de sortie

Utilisez des étapes de condition pour vérifier la qualité de sortie avant de poursuivre :

1. Extraire les données de facture (étape Recipe)
2. Condition : Si total_amount existe et line_items n’est pas vide (étape condition)
   • Alors : Continuer vers la vérification des écarts
   • Sinon : Signaler pour traitement manuel

Cela détecte les cas où l’IA a échoué à extraire des champs clés — peut-être que le format de facture était inhabituel ou que le texte était mal scanné. Au lieu de passer des données incomplètes à l’étape suivante, le workflow les route vers un humain.

Notifications webhook en cas d’échec

Les workflows peuvent envoyer des notifications webhook quand ils se terminent — avec succès ou avec des erreurs. Configurez un webhook de sortie pour notifier votre équipe quand un workflow échoue :

• Publier dans un canal Slack quand un workflow planifié rencontre une erreur
• Envoyer à PagerDuty pour les workflows critiques nécessitant une attention immédiate
• Mettre à jour un tableau de bord de statut avec la santé des workflows

Le payload du webhook inclut l’identifiant d’exécution, le statut, quelle étape a échoué et les détails de l’erreur. Votre équipe obtient des informations actionnables, pas simplement « quelque chose a cassé ».

Exécution parallèle et échecs partiels

Les étapes parallèles exécutent plusieurs branches simultanément. Si une branche échoue, les autres branches continuent. C’est intentionnel — un échec dans une branche indépendante ne devrait pas bloquer le travail non lié.

Après la fin de l’exécution parallèle, vous pouvez vérifier quelles branches ont réussi et lesquelles ont échoué. Une étape de condition après le bloc parallèle peut router le workflow selon que toutes les branches se sont terminées ou que certaines ont échoué.

Concevoir pour le 95e percentile

La plupart des appels IA réussissent au premier essai. La plupart des sorties correspondent au schéma attendu. La plupart des workflows s’exécutent sans problème. Mais « la plupart » ne suffit pas quand vous exécutez des workflows quotidiennement pour une équipe qui dépend des résultats.

Concevez vos workflows pour le cas des 5 % :

• Ajoutez des retries à chaque étape de Recipe. Le coût de quelques appels API supplémentaires en cas d’échec est négligeable comparé au coût d’une exécution de workflow échouée.
• Ajoutez des portes d’approbation avant les sorties à enjeux élevés. Si le workflow génère du contenu qui va aux clients ou aux dirigeants, un humain devrait le vérifier.
• Ajoutez des vérifications de condition après les étapes d’extraction. Vérifiez que l’IA a réellement extrait les données dont vous avez besoin avant de les transmettre.
• Configurez les notifications webhook pour les workflows planifiés et déclenchés. Si personne ne surveille l’UI, vous avez besoin d’alertes quand les choses tournent mal.

L’objectif est des workflows qui dégradent avec élégance — faisant remonter les problèmes aux humains au lieu de produire silencieusement de mauvaises sorties.