Ce qui casse un workflow en production
Il ne casse presque jamais sur sa logique : celle-ci a été testée. Il casse sur l'extérieur.
Un service qui répond en erreur passagère, une limite d'appels atteinte, un fichier au format inattendu, un champ vide là où l'on attendait une valeur. Ces événements sont rares à l'unité et certains à l'échelle de milliers d'exécutions.
Un workflow qui n'a pas prévu l'échec s'arrête au milieu, et c'est le pire endroit.
L'arrêt au milieu, le vrai problème
Un enchaînement typique : recevoir une commande, créer le client, créer la facture, envoyer le courriel, mettre à jour le tableau de suivi.
Un échec à la troisième étape laisse un client créé, aucune facture, aucun courriel. Une relance naïve recrée le client : vous avez maintenant un doublon.
Deux notions règlent cela, et elles valent bien au-delà du no-code.
L'idempotence : refaire l'opération ne change pas le résultat. On l'obtient en utilisant une clé stable, par exemple « créer ou mettre à jour le client dont l'adresse est X » plutôt que « créer un client ».
Le point de reprise : savoir à quelle étape on s'est arrêté. En pratique, écrire l'avancement quelque part, ne serait-ce qu'une colonne d'état dans le tableau source.
Configurer les relances correctement
La plupart des plateformes proposent une relance automatique. Trois réglages comptent.
Le nombre d'essais. Trois suffit presque toujours. Au-delà, ce n'est plus une erreur passagère.
L'attente croissante entre les essais. Relancer immédiatement un service saturé le sature davantage. Une attente qui double à chaque tentative est le comportement souhaitable.
Ce qui mérite une relance. Une erreur de communication ou une indisponibilité temporaire, oui. Une erreur de validation, non : le même envoi échouera cent fois. Relancer sur ce type d'erreur consomme votre quota sans aucune chance de succès.
La file d'échecs
Après les relances, il reste des cas définitivement en échec. Ils ne doivent pas disparaître.
Le motif utile : une file de rattrapage, en pratique un tableau ou un canal où atterrissent les exécutions échouées avec leur contexte, et que quelqu'un regarde chaque jour.
Sans ce mécanisme, les échecs sont silencieux, et vous découvrez trois semaines plus tard que quarante commandes n'ont jamais été traitées.
Les déclencheurs en double
Un piège spécifique au no-code : les webhooks sont souvent renvoyés par l'émetteur s'il ne reçoit pas d'accusé rapide. Votre workflow s'exécute alors deux fois pour le même événement.
La parade tient en trois étapes : conserver l'identifiant de l'événement, vérifier au démarrage s'il a déjà été traité, et sortir sans rien faire si c'est le cas.
C'est cinq minutes de configuration, et c'est ce qui évite les factures en double.
À retenir
Prévoyez l'échec extérieur, il est certain à l'échelle. Rendez les étapes idempotentes avec des clés stables, relancez trois fois avec attente croissante, et seulement sur les erreurs passagères. Une file d'échecs regardée chaque jour, et une déduplication sur l'identifiant d'événement.