Diagnostiquer un échec de transmission

Objectif

Identifier la cause racine d'un échec sur l'un de vos flux et déterminer s'il provient de votre système, de la plateforme ou d'un partenaire.

Durée estimée : 5 à 10 minutes • Rôle requis : transaction-viewer ou audit-viewer

Trois points d'entrée

Signal	Point de départ
Un correlationId dans un ticket interne	Transmissions — barre de recherche
Une chute du taux de succès sur le tableau de bord	Tableau de bord → Transmissions
Un partenaire vous signale un échec	Transmissions filtrées sur ce partenaire

Étape 1 — Localiser la transmission

Avec un correlationId

Menu Suivi des activités ▸ Transmissions, collez l'identifiant dans la barre Rechercher un CorrelationId.

Sans correlationId

1. Ajustez la période (filtre en haut à droite) à l'intervalle suspect.
2. Cliquez sur Filtres pour restreindre :
   • Statut : cochez ERROR, TIMEOUT, CIRCUIT_OPEN, DENIED, PARTNER_ERROR, REJECTED.
   • Type (eventType) : mi-adjudication, mi-consultation-droits, mi-transmission.
   • Source ou Destination : si vous suspectez un partenaire précis.
3. Triez par Capturé à décroissant.

Étape 2 — Lire le statut

Le code technique (colonne Statut) et le libellé affiché dans la liste correspondent ainsi :

Code technique	Libellé UI	Sens	Cause probable
SUCCESS 🟢	Succès (sync) ou Accepté (batch)	Transaction aboutie.	—
ERROR 🔴	Erreur	Erreur technique côté plateforme (parsing, mapping).	Mapping ou format.
PARTNER_ERROR 🔴	Erreur partenaire	Erreur applicative du partenaire.	Règle métier côté partenaire.
REJECTED 🔴	Rejetée	Refusée par la plateforme (validation).	Donnée hors contrat.
DENIED 🔴	Refusée	Accès refusé.	Credential invalide ou révoqué.
TIMEOUT 🟠	Expirée	Délai dépassé.	Partenaire injoignable ou lent.
CIRCUIT_OPEN 🟠	Coupe-circuit ouvert	Coupe-circuit ouvert.	Échecs répétés sur la même destination.

« Succès » vs « Accepté »

Pour un statut technique SUCCESS, l'application affiche « Succès » sur les transmissions synchrones (REAL_TIME_SYNC) et « Accepté » sur les transmissions asynchrones / batch (REAL_TIME_ASYNC, BATCH) — la nuance reflète qu'en async, « accepté » signifie que la plateforme a pris en charge l'envoi mais pas encore confirmation finale du partenaire.

Étape 3 — Ouvrir le détail

Cliquez sur l'icône 👁️ à droite de la ligne. Le volet Détail de la transaction s'ouvre.

Le volet contient :

• Résumé — type, statut, source, destination, latence, capturé à.
• Payload request — corps JSON de la requête envoyée.
• Payload response — corps JSON de la réponse (si présente).
• Metadata — champs techniques : partnerResponseCode, circuitBreakerState, decision, processingDurationMs, reason.

Le champ reason dans les metadata est souvent le plus utile : il explique en clair la cause de l'échec.

Étape 4 — Identifier la cause racine

Symptôme	Cause probable	Action
DENIED + code 401/403	Credential invalide ou révoqué.	Renouveler le credential.
TIMEOUT répété	Partenaire saturé ou injoignable.	Contacter votre partenaire.
CIRCUIT_OPEN massif	Conséquence du précédent — la plateforme protège le partenaire.	Patientez (le circuit se referme automatiquement).
ERROR mentionnant un mapping	Règle de transformation cassée par un changement de format.	Onglet Mappings — vérifier la règle, puis support si besoin.
ERROR mentionnant un parsing	Format reçu inattendu.	Aligner avec votre partenaire ou avec votre équipe technique.
PARTNER_ERROR + code métier	Règle fonctionnelle (droit fermé, fournisseur inconnu, etc.).	Cas métier normal — pas un bug plateforme.
REJECTED avec reason = "validation"	Donnée d'entrée hors contrat.	Corriger la source.

Étape 5 — Vérifier que c'est isolé ou systémique

Avant d'escalader :

1. Revenez à la liste filtrée sur le même type ou la même destination.
2. Comptez les échecs sur les dernières 24 h.
3. Cas isolé → communiquez le correlationId à qui de droit.
4. Cas systémique → escaladez (voir Et ensuite).

Étape 6 — Recouper avec l'audit (optionnel)

Si vous suspectez qu'un changement récent a déclenché l'incident :

1. Menu Suivi des activités ▸ Pistes d'audit.
2. Filtrez sur les événements partner.service_config_updated, partner.credentials_updated, partner.mappings_updated sur la fenêtre précédant le premier échec.

Checklist de fin de parcours

• [ ] Cause racine identifiée (votre système, plateforme, partenaire).
• [ ] correlationId conservé pour le suivi.
• [ ] Action corrective décidée (renouveler credential / corriger mapping / contacter partenaire).
• [ ] Si action menée → vérification sur une nouvelle transmission SUCCESS.

Points d'attention

• Ne modifiez rien « pour voir » sur une configuration qui marche pour les autres flux. Comprenez d'abord, corrigez ensuite.
• Le correlationId est votre seul ticket universel — sans lui, le support met beaucoup plus de temps.
• Un TIMEOUT isolé n'est pas un bug. Les partenaires ont des pics. C'est la répétition qui fait la tendance.

Et ensuite ?

• Si le problème vient d'un credential → Renouveler un credential.
• Pour escalader → Support.