Aller au contenu principal

Gestion des erreurs

Une erreur dans un flux n'est pas un échec en soi : c'est un signal. Ce guide décrit le cycle de vie complet de la gestion des incidents dans Ecosystem — anticiper les pannes, capturer les erreurs, analyser les causes et résoudre les incidents — pour qu'aucune exécution échouée ne parte sans trace exploitable.

Le cycle de vie d'une erreur​

PhaseObjectifBrique Ecosystem
AnticiperEmpêcher la propagation de données corrompuesExtractors, nœud Condition
CapturerCentraliser la logique d'échecNœud On Error, option Stopper en cas d'échec
AnalyserComprendre l'état exact au moment de l'erreurTraces
RésoudreRelancer proprement après correctionRejeu de trace

1. Anticiper (prévention)​

Valider les réponses API avec les extractors​

Utilisez systématiquement des extractors (JSONPath) dans vos nœuds Requête HTTP(S). Si une donnée critique est absente de la réponse, le nœud échoue immédiatement au lieu de propager des données corrompues vers les nœuds suivants.

Le nœud HTTP injecte sa réponse dans context.lastResponse :

{
  "lastResponse": {
    "status": 201,
    "success": true,
    "headers": {
      "content-type": "application/json",
      "ratelimit-remaining": "49"
    },
    "data": {
      "id": "12345",
      "status": "created"
    }
  },
  "orderId": "12345"
}

Dans cet exemple, un extracteur JSONPath $.data.id a copié l'identifiant dans context.orderId. Sans cette valeur, le nœud échoue — et l'échec est alors géré par le nœud On Error.

Vérifier le contenu métier avec un nœud Condition​

Une API peut répondre 200 OK tout en renvoyant un contenu métier invalide (liste vide, champ manquant, valeur inattendue). Après chaque requête HTTP, placez un nœud Condition qui vérifie l'état de la réponse :

{{lastResponse.success}} === true && {{lastResponse.data.items.length}} > 0
  • Branche True : le traitement continue
  • Branche False : bascule vers une logique dédiée (alerte, fallback, nœud On Error)

2. Capturer (réaction)​

Le nœud On Error, filet de sécurité global​

Le nœud On Error est le filet de sécurité de votre flux : il centralise la logique d'échec (alerte par email, log dans un système externe, rollback) dès qu'un nœud du flux échoue. C'est un point de départ : on ne s'y connecte pas, il se déclenche automatiquement sur une erreur.

Il reçoit les informations d'erreur du nœud en échec :

{
  "error": {
    "message": "HTTP 503 Service Unavailable",
    "code": "HTTP_ERROR",
    "details": {}
  },
  "node": "Get_Customer_Profile",
  "lastResponse": {
    "status": 503,
    "success": false
  }
}

L'option « Stopper l'exécution en cas d'échec »​

Sur chaque nœud, l'option Stopper l'exécution du flux en cas d'échec décide si une erreur arrête tout le flux ou si l'exécution continue :

ValeurComportementUsage recommandé
true (défaut)Le flux s'arrête immédiatement — ou transmet l'erreur au nœud On Error connectéÉtapes critiques : paiement, mise à jour de stock, écriture en base
falseLe flux continue ; l'erreur reste disponible dans lastResponseÉtapes non bloquantes : enrichissement optionnel, log

3. Analyser (débogage)​

Lire une trace​

La trace d'exécution est la source de vérité pour le débogage : elle contient l'état exact du context et des data au moment de l'erreur, nœud par nœud. En cas d'incident, partez toujours du nœud en échec, consultez son message d'erreur, puis remontez le flux.

Anonymisation vs visibilité​

Par défaut, Ecosystem masque certaines données sensibles dans les traces. Si vous devez voir le détail d'une erreur technique complexe, vérifiez les paramètres d'anonymisation du nœud concerné (option Anonymize) : désactivez-la uniquement si nécessaire et de façon temporaire.

Prudence RGPD

Ne désanonymisez jamais des données personnelles (PII) : une trace non anonymisée contient le détail brut des données. Pour diagnostiquer, préférez une exécution de test ou un rejeu en mode Complet sur des données non sensibles.

4. Résoudre (remédiation)​

Rejouer une trace​

Depuis l'historique des traces, vous pouvez relancer une exécution échouée après avoir corrigé une configuration ou attendu qu'un service tiers soit de nouveau en ligne :

  1. Ouvrez la trace en échec
  2. Corrigez le flux ou les données d'entrée
  3. Cliquez sur Relancer le flux — le rejeu permet aussi de choisir un mode de traçage différent pour un diagnostic complet
  4. Vérifiez la nouvelle exécution dans l'historique

Checklist​

Avant de mettre en production
  • Chaque appel HTTP possède un extracteur sur les données critiques
  • Une condition vérifie lastResponse.success après chaque requête
  • Un nœud On Error centralise les alertes d'échec
  • Les étapes critiques ont l'option Stopper en cas d'échec activée
  • Les nœuds manipulant des PII restent anonymisés

Étapes suivantes​