Gestion des erreurs n8n : reprendre un dossier sans perdre son état

Associez chaque demande à un identifiant stable provenant de la source. Conservez séparément l'identifiant d'événement, celui de l'opération métier et celui de l'exécution n8n. Deux exécutions peuvent traiter la même opération; deux commandes légitimes peuvent contenir exactement les mêmes produits. Une empreinte du contenu ne suffit pas toujours à les distinguer.

Décrivez ensuite les états attendus : demande reçue, écriture demandée, résultat confirmé, résultat incertain, intervention requise. Une automatisation CRM et ERP devrait permettre aux opérations de retrouver les dossiers incertains sans parcourir chaque détail technique. Précisez qui possède la décision de reprise et le délai acceptable avant intervention.

Prenons un distributeur fictif. L'événement COM-248 demande la création d'une commande. Le CRM enregistre la commande C-906, puis la réponse réseau se perd. Le workflow ignore le numéro C-906 et classe le résultat comme incertain. Il interroge alors le CRM avec la référence COM-248 avant toute nouvelle création. Cet exemple illustre une architecture proposée, sans décrire un essai réalisé.

Si une commande correspond exactement à la référence et au contenu attendus, la reprise enregistre son identifiant et poursuit le parcours. Si aucune commande n'apparaît, le système doit encore tenir compte du délai de visibilité de l'API. Si plusieurs correspondances apparaissent, il suspend le dossier et demande une vérification humaine. Une absence momentanée dans une recherche ne prouve pas que l'écriture a échoué.

Lorsque l'API propose une clé d'idempotence, appliquez son contrat précis : portée, durée et comportement en cas de contenu différent. Sans cette capacité, recherchez une référence unique contrôlée par le système destinataire ou une écriture conditionnelle. Un verrou local n'empêche pas une autre intégration de créer le même objet. La garantie dépend des deux systèmes.

La documentation n8n sur les erreurs décrit un workflow d'erreur déclenché par Error Trigger, à sélectionner dans les paramètres du workflow principal. Cette voie peut notifier une équipe. La notification doit fournir une référence de dossier et une action attendue, avec le minimum de renseignements nécessaire.

Un message utile indique le système concerné, la dernière étape confirmée et le caractère certain ou incertain du résultat. Évitez de transmettre une facture complète, un jeton ou les données personnelles du client dans une alerte. Le dossier d'investigation peut conserver davantage de détails, avec des accès et une durée de conservation adaptés.

Le statut technique ne clôt pas l'incident. Un workflow peut terminer après avoir envoyé un courriel d'alerte pendant que la commande demeure absente. Tenez un registre métier des opérations ouvertes, avec un responsable. Un CRM et ERP sur mesure peut exposer cette file de rapprochement lorsque les outils existants ne la fournissent pas.

Les scénarios suivants forment un protocole de recette à exécuter dans un environnement isolé. Utilisez des comptes et données d'essai, un service destinataire contrôlé et un mécanisme pour simuler les réponses. Aucune injection de panne n'a été réalisée pour cet article. L'objectif est d'obtenir une preuve distincte pour chaque comportement avant d'autoriser les opérations réelles.

Fixez un nombre maximal de tentatives et une durée totale de traitement. Une erreur d'autorisation exige une correction d'accès; une entrée invalide exige une correction de données. Réessayer ces erreurs en boucle charge l'API et retarde les dossiers valides. Pour une limitation temporaire, respectez les indications du fournisseur et évitez que tous les dossiers reprennent au même instant.

Le nœud Wait permet une attente dans un parcours. Choisissez les branches selon votre version n8n et les garanties de l'API. Une pause ne réserve aucune ressource chez le fournisseur. Au retour, revérifiez les conditions métier qui ont pu changer, dont l'annulation d'une demande.

Traitez séparément les effets secondaires. Si la création réussit et que le courriel échoue, conservez la commande puis reprenez seulement la notification. Une annulation compensatoire mérite sa propre règle, particulièrement lorsqu'une autre équipe a déjà commencé le travail. Une application web sur mesure peut présenter ces décisions et leurs preuves aux personnes autorisées.

Pour chaque scénario, relevez la version du workflow, les entrées simulées, l'état final dans le CRM et les actions effectivement réalisées. Comptez les objets créés chez le destinataire, puis comparez-les aux opérations attendues. Notez aussi le temps de diagnostic et les interventions manuelles, sans convertir un exercice réussi en promesse de disponibilité.

La personne responsable des opérations valide le dossier métier; l'équipe technique explique les écarts. Conservez les cas problématiques pour la prochaine modification. Le livrable utile comprend un registre de rapprochement et un journal de recette rempli après exécution.