Flux d'exception et matrice d'escalade
Quand quelque chose se passe mal — et quelque chose finit toujours par mal se passer — il faut savoir qui prévenir, sous quel délai, et comment fermer la boucle.
Problème
Une intégration EDI génère, en exploitation, plusieurs catégories d'incidents :
- Le message ne passe pas la validation syntaxique.
- Le partenaire renvoie un CONTRL/997 en rejet.
- Le partenaire renvoie un ORDRSP/855 négatif.
- Aucun ACK ne revient dans le SLA contractuel.
- L'envoi est en DLQ après épuisement des retentes.
- Un certificat partenaire arrive à expiration dans 30 jours.
- Le volume reçu d'un partenaire est anormalement bas (anomalie statistique).
Sans matrice explicite, chaque type d'incident est traité par convention orale ou par habitude, et finit dans le mail de l'opérateur EDI qui se réveille le lundi avec 400 erreurs et aucune priorisation. L'effet métier est lourd : factures non envoyées, commandes perdues, paiements retardés.
Forces
- Asymétrie des conséquences. Un 997 syntaxique sur un message de catalogue n'a pas le même impact qu'un MDN manquant sur une facture B2G — l'un demande un ticket dans la semaine, l'autre une alerte immédiate.
- Multiplicité des acteurs concernés. Selon l'incident, l'escalade vise les ops EDI, l'équipe sécurité (cert), l'équipe achat ou vente (commande), la finance (facture), ou directement le partenaire.
- Diversité des seuils SLA. Un partenaire stratégique a des seuils plus serrés qu'un partenaire long-tail. La matrice doit paramétrer par partenaire.
- Coût des fausses alertes. Trop d'alertes finissent ignorées. Il faut un filtre cohérent, des seuils calibrés et des mécanismes d'auto-fermeture quand l'incident se résout seul.
Solution : classifier puis escalader
Le pattern Invalid Message Channel de Hohpe & Woolf (2003) en pose la base : dédier une file séparée aux messages invalides, avec un opérateur humain en bout. Le pattern flux d'exception étend cette idée en EDI :
- Classer chaque incident par axe (technique vs métier), par sévérité (warning, error, critical) et par origine (interne, partenaire).
- Associer chaque classe à un destinataire et un délai d'escalade par défaut : opérateur EDI (1h), responsable partenaire (4h), métier (24h), direction (48h).
- Définir les actions de fermeture : retry manuel, correction côté émetteur, escalade au partenaire, abandon documenté.
- Mesurer le MTTR (Mean Time To Resolution) par classe d'incident, pour calibrer dans la durée.
Matrice d'escalade
| Incident | Sévérité | Premier destinataire | Délai escalade | Action attendue |
|---|---|---|---|---|
| Validation syntaxique IN — échec | Error | Émetteur partenaire | 2h ouvrées | Correction côté émetteur, renvoi sous nouvelle référence |
| CONTRL/997 reçu — action 7 (rejet) | Error | Ops EDI | 2h ouvrées | Analyse cause, correction mapping ou côté partenaire |
| ORDRSP/855 reçu — rejet métier total | Error | Équipe Achat | 4h ouvrées | Décision métier : réémettre ou abandonner la commande |
| ORDRSP/855 reçu — rejet partiel | Warning | Équipe Achat | 8h ouvrées | Validation business du delta accepté vs envoyé |
| MDN/Receipt absent dans SLA partenaire | Warning → Error si 2× SLA | Ops EDI puis responsable partenaire | SLA + 30 min | Vérifier état partenaire, retenter, escalader si KO |
| Envoi en DLQ — max-attempts atteint | Critical | Ops EDI + responsable partenaire | 1h | Triage manuel, replay ou abandon documenté |
| Certificat partenaire — expire dans 30 jours | Warning | Équipe Sécurité | 5 jours ouvrés | Demander le nouveau certificat au partenaire |
| Certificat partenaire — expire dans 7 jours | Error | Équipe Sécurité + Ops EDI | 24h | Escalade urgente au partenaire, planification rollover |
| Volume reçu — ‑50 % sur 7 jours glissants | Warning | Responsable partenaire | 24h | Vérifier : panne partenaire, fin de saison, perte commerciale ? |
| Circuit breaker partenaire — Open > 30 min | Critical | Ops EDI + partenaire | Immédiat | Diagnostic, communication client si nécessaire |
SLA et seuils par partenaire
La matrice ci-dessus est un défaut générique. En pratique, chaque partenaire a son propre profil :
- Walmart, par exemple, attend un 997 sous 1 heure sur tout 856 ASN et impose des pénalités pour 997 hors délai. Le seuil doit être resserré pour ce flux.
- OEM automobile sur OFTP2, les fichiers DELJIT sont critiques — un EERP manquant impacte une chaîne JIT. Le seuil d'alerte y est de minutes, pas d'heures.
- PEPPOL eDelivery, l'Access Point doit confirmer réception sous 5 minutes par règle réseau. Au-delà, le mécanisme de reception awareness AS4 déclenche les retentes.
Le couplage matrice × profil partenaire se modélise dans un fichier de config (YAML ou table en base) qui paramètre les seuils, les destinataires et les délais — pour qu'ils soient versionnés et auditables comme du code.
Console d'exploitation — l'autre moitié du pattern
La matrice ne vaut rien sans interface d'exploitation. Une bonne console EDI offre :
- Vue triée par sévérité et délai d'escalade. Les Criticals en haut, les Warnings en bas.
- Drill-down sur un envoi. Voir les trois niveaux d'ACK (cf. pattern Acquittements), l'historique des retentes, le contenu du payload (avec contrôle d'accès).
- Actions one-click. Replay, marquer comme abandonné avec motif, escalader manuellement à un autre destinataire.
- Annotations persistantes. Chaque incident porte un fil de commentaires audit-loggables — qui a fait quoi quand, pour les audits.
- Export vers ticketing. Un Critical doit pouvoir générer un ticket Jira/ServiceNow sans copier-coller.
Anti-patterns
- Une seule classe « Error ». Tout est Error, personne ne sait trier. À la fin, tout est ignoré.
- Mail à
edi-ops@…. Une boîte partagée non structurée. Pas de SLA, pas de tracking, pas de revue. - Pas de fermeture automatique. Un partenaire qui remonte ne déclenche pas la fermeture des alertes ouvertes — les opérateurs traitent manuellement des incidents déjà résolus.
- Pas de seuils par partenaire. Le seuil générique masque les vrais incidents pour les flux critiques et bruite pour les flux secondaires.
- Alerte = escalade. Confondre une alerte ops avec une escalade direction. Une alerte ops est un signal de file, pas un incident majeur — la matrice doit distinguer.
Patterns liés
- Acquittements — la source des incidents « ACK manquant » ou « ACK négatif ».
- Retry & backoff — la DLQ est la principale entrée du flux d'exception.
- Idempotence — un replay manuel depuis la console nécessite la même clé.
- Modèle canonique — l'invalidation du canonique est un type d'incident à classer.
Sources
- Hohpe G., Woolf B. — Enterprise Integration Patterns, patterns Invalid Message Channel, Dead Letter Channel, Detour. enterpriseintegrationpatterns.com — Invalid Message Channel
- Google SRE Book, chapitre Monitoring Distributed Systems. La distinction Symptoms vs Causes, et la règle des Four Golden Signals, transposables aux flux EDI. sre.google/sre-book/monitoring-distributed-systems
- Walmart Supplier Center — Pénalités 997. Public reference des SLA partenaire : ACK sous 1h, sinon pénalité. supplier.walmart.com/edi
- OpenPEPPOL — Reception Awareness. Mécanique réseau-wide pour la détection des MDN manquants en AS4.