Disaster Recovery pour stacks EDI : RTO, RPO, patterns et runbooks

Une panne d'AS4 chez l'opérateur PEPPOL en 2026 = factures en suspens, pénalités contractuelles, audit fiscal négatif. Pourtant 60 % des hubs EDI européens n'ont pas de plan DR documenté ni testé. Voici le cadre méthodologique.

Pourquoi un DR dédié pour EDI

Le disaster recovery est une discipline ancienne (ISO 22301 Business Continuity, ITIL, NIST SP 800-34), mais les hubs EDI ont des caractéristiques qui justifient un cadre spécifique :

• Contraintes contractuelles partenaires : la majorité des manuels EDI partenaires (Walmart Supplier Guidelines, Stellantis OFTP2 Specs, Carrefour B2B Charter) imposent des SLA de bout-en-bout (typiquement 99,5 % uptime, MTTR < 4h) avec pénalités financières.
• Conformité fiscale : une INVOIC envoyée mais perdue avant archivage = problème d'audit potentiel. La rétention 10 ans doit survivre à toute panne.
• Asymétrie partenaires : certains partenaires (grande distribution, automobile) tolèrent des retransmissions; d'autres (banques, e-invoicing fiscal) refusent les doublons. Le DR doit gérer les deux.
• Multi-régions implicite : un hub européen peut ingérer des partenaires APAC et LATAM, ce qui impose une présence multi-régions pour latence et résilience.

RTO et RPO réalistes

RTO (Recovery Time Objective) : temps maximal pour restaurer le service après sinistre. RPO (Recovery Point Objective) : quantité maximale de données perdues acceptable.

Ne pas confondre RTO/RPO du hub EDI lui-même avec ceux des partenaires. Exemples typiques 2026 par segment :

• Banque ISO 20022 (paiements correspondants) : RTO ≤ 30 min, RPO ≤ 0 (zéro perte tolérée — chaque pacs.008 doit être conservé). Implique active-active multi-régions synchrone.
• e-invoicing fiscal (Italie SdI, France PDP, Pologne KSeF) : RTO ≤ 1h, RPO ≤ 5 min. La facture doit être réémise dans le délai légal.
• Grande distribution (Walmart, Carrefour) EDI commercial : RTO ≤ 4h, RPO ≤ 15 min. Le partenaire retransmet en cas de doute.
• Automotive OFTP2 (Stellantis, BMW) : RTO ≤ 2h, RPO ≤ 5 min. Les DELFOR/DELJIT ont des cadences fines (12-24 fois/jour).
• Santé HL7v2/FHIR : RTO ≤ 15 min pour ADT temps-réel, RPO ≤ 0. Vie humaine en jeu.
• Cargo IATA Cargo-XML / ONE Record : RTO ≤ 1h, RPO ≤ 15 min.

Topologies DR cible 2026

Quatre topologies courantes, classées par coût croissant :

Cold standby (backup-restore)

Une région secondaire vide, déclenchée manuellement lors d'un sinistre. On restaure depuis les sauvegardes (S3 cross-region replicas, snapshots PostgreSQL). RTO 4-24h, RPO selon fréquence backup (typiquement 1-24h). Coût marginal. Acceptable pour des flux non-critiques uniquement.

Warm standby (pilot light)

La région secondaire tourne en mode minimal : les briques data (PostgreSQL streaming replication, Kafka mirror maker 2, Redis Cluster cross-region) sont actives, mais les services compute sont à l'échelle minimale. En cas de basculement, on scale up. RTO 30 min - 2h, RPO ≤ quelques minutes. Coût modéré (~30 % de la prod). Le mode par défaut recommandé pour un hub EDI moderne.

Hot standby (active-passive)

Région secondaire à pleine échelle, prête à prendre le trafic, mais bascule explicite (DNS, load balancer, GSLB). RTO 5-15 min, RPO ≤ 1 min. Coût élevé (~75 % de la prod). Réservé aux flux critiques (banques, fiscal).

Active-active multi-régions

Toutes les régions traitent simultanément, routage par DNS géographique ou load balancer mondial. RTO ~zéro (l'incident sur une région n'interrompt pas le service), RPO ≤ quelques secondes. Coût très élevé (200 % de la prod). Mais introduit la complexité de la cohérence distribuée — voir notre pattern Raft et consistent hashing. Réservé aux paiements ISO 20022 et aux exigences extrêmes.

Messages en vol et idempotence

Le piège classique du DR EDI : ce qui se passe pour les messages « en vol » (ingérés dans la région primaire mais pas encore traités quand elle tombe). Trois principes :

• Persister tôt : dès qu'un message AS4 est reçu, l'inscrire dans la queue répliquée (Kafka cross-region, RabbitMQ mirroring) avant tout traitement. Le NRR (Non-Repudiation of Receipt) AS4 ne doit être renvoyé au partenaire qu'après cette persistance.
• Idempotence partout : chaque consumer downstream doit être idempotent (cf Idempotent Receiver EDI et Transactional Inbox). En cas de bascule DR, des messages peuvent être rejoués — la chaîne doit les absorber sans double effet.
• Replay traçable : les outils ops doivent permettre de rejouer un range d'offset Kafka explicite après bascule, avec reporting (combien re-traités, combien rejetés en doublon).

Runbook de bascule type

Un runbook DR EDI doit être lisible à 3h du matin par un astreinte qui n'a pas conçu le système. Structure type :

• Détection : critères automatiques (health-check région primaire KO > 5 min, perte connectivity ingress AS4 > 3 vérifs successives, alerte SLO partenaire critique).
• Décision : qui peut décider la bascule ? Un seul nom + suppléants. Critère « si pas de réponse en 15 min, bascule automatique ».
• Notification : pipeline d'alerte vers ops, partenaires critiques (auto-mail), management.
• Bascule : séquence commandes / Terraform / scripts à exécuter, par ordre, avec validation à chaque étape. Idéalement automatisable via un outil (Spinnaker, Argo Workflows, AWS Systems Manager Run Command).
• Vérification : smoke tests (ping AS4, parser EDIFACT, ingestion fichier test, accusé partenaire revient). Critères go/no-go explicites.
• Communication partenaires : certains partenaires (banques surtout) doivent être notifiés du changement de point d'extrémité (URL AS4/SFTP). Préparer le mail type, le contact RH/CSM.
• Bascule retour (failback) : une fois la région primaire restaurée, replay des messages reçus en région secondaire, validation cohérence, retour progressif.
• Post-mortem : blameless, sous 48-72h. RCA, timeline, mesures correctives. Mise à jour du runbook.

Game day : tester sans casser

Le DR non-testé n'existe pas. Un game day est un exercice contrôlé où on simule un sinistre : arrêt brutal de la région primaire, perte d'un broker Kafka, corruption d'une table critique. Calendrier minimum : 2 game days par an, dont au moins un en mode « surprise » pour l'équipe d'astreinte.

Méthodologie : s'inspirer de Netflix Chaos Monkey et de la pratique Chaos Engineering (Rosenthal et al. 2020). Outils : Gremlin, AWS Fault Injection Simulator, Chaos Mesh (CNCF), Litmus (CNCF). En 2026, ces outils sont matures et permettent d'injecter des pannes contrôlées en production sans risque opérationnel majeur.

Pour aller plus loin

• Stack monitoring EDI — préalable indispensable pour détecter une panne.
• Capacity planning pour pics B2B — pour dimensionner la région DR correctement.
• Métriques EDI — pour mesurer le RTO/RPO réels.
• ISO 22301:2019 — Security and resilience — Business continuity management systems. iso.org
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems. csrc.nist.gov
• Rosenthal C., Jones N. — Chaos Engineering: System Resiliency in Practice, O'Reilly 2020.
• AWS Well-Architected Framework — Reliability Pillar, sections sur DR strategies. docs.aws.amazon.com
• Google SRE Workbook — chap. 9 « Incident Response ». sre.google