Sécurité des flux EDI 2026 : panorama défense en profondeur

La sécurité d'un flux EDI ne se résume jamais au choix d'AS2 contre SFTP. La réponse moderne repose sur cinq couches qui se renforcent mutuellement : transport, signature applicative, repos, audit, et préparation post-quantique. Cette page cadre les invariants.

Principe : défense en profondeur

La défense en profondeur consiste à multiplier les couches de contrôle de sorte qu'aucune faille isolée ne compromette la confidentialité, l'intégrité ou la disponibilité du flux. Pour un échange EDI, le principe se décline en cinq couches :

• Sécurité du transport (TLS, AS2, AS4, OFTP2 over TCP/IP).
• Signature et chiffrement du payload applicatif.
• Sécurité des données au repos (chiffrement disque, archivage légal).
• Audit et traçabilité (qui a fait quoi, quand, sur quel ordre).
• Préparation cryptographique post-quantique.

Aucune des cinq ne suffit isolément. Une transmission TLS sur un payload non signé permet à un attaquant interne au destinataire de réinjecter une facture. Une signature payload sans archivage légal ne tient pas en contentieux. L'analyse doit être systémique.

Couche transport

La couche transport est aujourd'hui standardisée. Les options principales en 2026 :

• AS2 (RFC 4130) — HTTP/HTTPS avec S/MIME pour signature et chiffrement. Le MDN (Message Disposition Notification) signé fournit une preuve de non-répudiation de réception (NRR) qui n'existe pas en HTTP standard.
• AS4 (OASIS ebMS 3.0) — Web Services SOAP avec WS-Security. Recommandé pour PEPPOL eDelivery et plus moderne qu'AS2.
• OFTP2 (RFC 5024) — encore dominant dans l'automotive européen, repose sur TLS pour le transport et propose signature et compression natives.
• SFTP (SSH File Transfer Protocol) — robuste, simple, utilisé massivement ; mais ne fournit pas par défaut de non-répudiation cryptographique au niveau message. À combiner avec signature payload.
• HTTPS REST — utilisable pour les APIs et webhooks EDI modernes, à condition d'ajouter une couche d'authentification mutuelle (mTLS, OAuth 2.0 + signed JWT) et un mécanisme de non-répudiation applicatif.

Pour TLS, les recommandations 2026 (basées sur les guides ANSSI, NIST et BSI) convergent sur TLS 1.3 obligatoire en nouvelle configuration, TLS 1.2 toléré jusqu'à 2027 pour les partenaires legacy, et désactivation stricte de SSLv3, TLS 1.0 et TLS 1.1.

Signature et chiffrement du payload

La signature du payload (indépendamment du transport) garantit l'intégrité et l'authentification de l'émetteur de bout en bout. En pratique :

• S/MIME pour AS2 et plus largement les messages MIME. Signature par certificat X.509 de l'émetteur, chiffrement par certificat du destinataire. Le couple SHA-256 + AES-256 reste recommandé en 2026.
• XML-DSig et XML-Encryption pour les payloads XML structurés (UBL, FatturaPA, BIS Billing, CII). Permettent une signature détachée ou enveloppée, et un chiffrement à granularité élément.
• CAdES, XAdES, PAdES — extensions ETSI de signature avancée avec horodatage (long-term validation, LTV). Obligatoires pour les factures électroniques dans plusieurs juridictions (Italie SdI, Espagne Facturae).
• JWS / JWE pour les payloads JSON dans les APIs modernes. Permet une signature et un chiffrement compatibles avec OAuth 2.0.

Données au repos

Le payload archivé est typiquement le résultat le plus exposé. Les pratiques pertinentes :

• Chiffrement disque transparent (LUKS, BitLocker, AWS KMS, Azure Disk Encryption, GCP Customer-Managed Encryption Keys) — couche minimale.
• Chiffrement applicatif — chiffrer le payload avec une clé spécifique avant stockage, et conserver la clé dans un HSM ou un KMS distinct du stockage. Utile pour les données ultra-sensibles.
• Archivage légal certifié — pour les factures et flux légaux, hébergement en coffre-fort numérique certifié (NF Z42-013 en France, ISO 14641, ou équivalents nationaux).
• Politique de rétention — 10 ans typiquement pour les factures TVA en Europe, 7 ans pour les claims HIPAA aux États-Unis, plus pour certains secteurs (santé jusqu'à 30 ans). Doit être documentée et auditable.

Audit et traçabilité

L'audit EDI repose sur trois piliers :

• Logs d'événements applicatifs — émission/réception message, validation, transformation, livraison. Recommandé en format structuré (JSON), centralisé (ELK, Loki, Splunk), avec rétention réglementaire.
• MDN/receipt cryptographiques archivés — la preuve de non-répudiation de réception (NRR) doit être stockée en parallèle du message émis. AS2 archive le couple message + MDN, AS4 le couple ebMS message + receipt.
• Accès et modifications tracés — qui a accédé à quel message, quand, depuis quelle IP. Important pour les enquêtes a posteriori et pour la conformité RGPD (droit d'accès aux logs d'accès).

Roadmap post-quantique

Le NIST a publié en août 2024 ses trois standards de cryptographie post-quantique (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA). La transition est désormais en cours dans les bibliothèques cryptographiques et chez les CA. Pour les flux EDI, l'horizon réaliste :

• 2026-2027 — inventaire des algorithmes utilisés en production, identification des bibliothèques, sandbox sur les implémentations PQC.
• 2027-2028 — déploiement de certificats hybrides (classique + PQC), test partenaires non critiques.
• 2028-2030 — bascule progressive vers PQ-only, alignée sur les évolutions des CA racines.

Le détail de la roadmap PQC EDI est traité dans l'article Cryptographie post-quantique appliquée à l'EDI.

Pour aller plus loin

• Protocoles EDI — vue détaillée des protocoles de transport.
• Cryptographie post-quantique appliquée à l'EDI — la roadmap détaillée.
• AS2, AS4 et OFTP2 modernes — comparatif des protocoles établis.
• Standard AS2 — la page canonique du protocole le plus déployé.