Protocoles EDI — quel transport pour quel cas ?

Cinq familles dominent en 2026 le transport des messages EDI : AS2, AS4, OFTP2, SFTP et VAN. Chacune correspond à un compromis différent entre sécurité, latence, coût, gouvernance et conformité sectorielle. Cette page outille la décision.

Cinq familles de transport EDI

Le transport est le maillon faible de tout projet EDI : un mauvais choix se paie ensuite pendant dix ans en certificats à renouveler, partenaires à migrer et audits à passer. On commence par poser ce que recouvre chaque famille, puis on confronte les critères.

AS2 — la référence Internet

AS2 (Applicability Statement 2) est un applicability statement IETF spécifié par RFC 4130 en juillet 2005 par D. Moberg (Cyclone Commerce) et R. Drummond (Drummond Group). Il décrit comment des standards existants — HTTP/1.1, MIME, S/MIME, MDN — s'assemblent pour échanger « structured business data » entre deux partenaires connus. Concrètement, une charge utile EDI (EDIFACT, X12, XML ou tout type MIME) est signée S/MIME, optionnellement chiffrée, envoyée en POST HTTPS, et acquittée par un MDN (Message Disposition Notification) signé contenant un MIC (Message Integrity Check). C'est ce MIC, recalculé identiquement des deux côtés, qui donne la non-répudiation de réception (NRR, RFC 4130 §2.3.1).

AS2 est aujourd'hui dominant en distribution (Walmart impose AS2 à tous ses fournisseurs depuis 2002, Target, Carrefour, Lowe's font de même), dans la santé américaine (les échanges HIPAA transitent massivement par AS2), et dans la logistique. La page dédiée AS2 détaille l'anatomie complète d'un échange, la mécanique sync/async des MDN et le rôle de la certification Drummond.

AS4 — successeur SOAP, fondation PEPPOL

AS4 est un profil OASIS publié en 2013 sur la base de la spécification ebMS 3.0 (ebXML Messaging Services). Là où AS2 vit sur HTTP brut + MIME, AS4 vit sur HTTP/SOAP 1.2 avec WS-Security pour la signature et le chiffrement, et WS-ReliableMessaging pour les garanties de livraison. Cela apporte deux choses nouvelles par rapport à AS2 : une réceptionniste fiabilisée (livraison exactly-once avec retentes contrôlées par la spec, et non par le client) et une interopérabilité native avec l'écosystème WS-* (politiques de sécurité déclaratives, Web Services Description Language pour décrire les points d'entrée).

AS4 est devenu obligatoire en 2018 dans le réseau PEPPOL eDelivery (modèle 4-corner pour la facturation électronique européenne), et il s'impose progressivement à mesure que les obligations e-invoicing nationales convergent — Belgique 1^er janvier 2026, France septembre 2026, Allemagne 2025. Hors PEPPOL, AS4 reste minoritaire face à AS2, qui est plus simple à mettre en œuvre.

OFTP2 — l'automobile européenne

OFTP2 (Odette File Transfer Protocol version 2) est spécifié par RFC 5024 (mai 2007) sous l'égide d'Odette International, l'organisation de standardisation de l'automobile européenne. Il succède à OFTP 1.3 (RFC 2204, 1997) qui vivait sur X.25 et ISDN ; OFTP2 a porté le protocole sur TCP/IP et l'a doté de chiffrement et signature basés sur les CMS (RFC 3852). Les opérations supportées vont au-delà du simple envoi de fichier : OFTP2 sait gérer la reprise sur interruption (un point crucial pour les gros fichiers automobiles), le routage multi-saut entre boîtes aux lettres (utile dans les chaînes de sous-traitance automobile à plusieurs niveaux), et des accusés de livraison signés (EERP, End-to-End Response).

OFTP2 reste la norme de facto entre constructeurs (Renault, Stellantis, Volkswagen, BMW, Mercedes-Benz) et leurs fournisseurs de rang 1 à 3 en Europe. Le transport porte des messages EDIFACT au format Odette (un subset d'EDIFACT) pour les flux JIT (Just-In-Time) et synchrones (DELJIT, DELFOR). Hors automobile européenne, son usage est extrêmement marginal.

SFTP — la simplicité opérationnelle

SFTP (SSH File Transfer Protocol) est défini par les drafts IETF secsh-filexfer et porté par tout serveur SSH conforme à RFC 4253 (the SSH Transport Layer Protocol). C'est un transport de fichiers générique, chiffré par SSH, authentifié par mot de passe ou par clé publique — pas par certificat S/MIME comme AS2 ou OFTP2. SFTP ne sait rien des messages EDI : il transporte des fichiers opaques. Toute la sécurité applicative (signature de payload, accusé applicatif) doit alors être ajoutée par convention bilatérale : un fichier orders-CTRL000042.edi est déposé dans un répertoire, un fichier de contrôle orders-CTRL000042.ok ou .contrl revient — pas de standardisation universelle.

Malgré cette pauvreté fonctionnelle, SFTP représente une part significative des échanges EDI réels en 2026, surtout pour les flux à faible volume, les flux internes à un groupe, les flux de reporting et les déploiements rapides où une infrastructure AS2 complète serait surdimensionnée. C'est le protocole par défaut dès qu'on sort des grandes obligations sectorielles.

VAN — l'intermédiation historique

Un VAN (Value-Added Network) est un opérateur tiers qui prend en charge l'acheminement EDI entre partenaires. Né dans les années 1980 — IBM Information Network, GE Information Services, AT&T EDI*Net — le modèle VAN consiste pour chaque partenaire à se connecter à sa boîte aux lettres VAN par n'importe quel protocole (X.25 historiquement, FTP, AS2, SFTP aujourd'hui), et à laisser le VAN gérer le routage interne entre partenaires connectés. L'opérateur facture à l'octet ou à la transaction.

Les VAN historiques (IBM Sterling, OpenText/GXS, BT INS) coexistent en 2026 avec des plateformes plus modernes (Cleo, Edicom, Pagero, Stedi) qui assument une fonction similaire mais sont commercialement positionnées comme « cloud EDI » ou « EDI-as-a-service ». Le VAN reste la norme dans certains secteurs réglementés (santé US, banque) et chez les grands comptes qui privilégient un opérateur unique pour mille partenaires. Son coût marginal et sa latence supplémentaire restent son principal handicap face au transport direct AS2 ou OFTP2.

Matrice de décision

Critères de choix

Quelques règles pratiques pour orienter le choix :

• Vous êtes fournisseur de la grande distribution nord-américaine ou européenne : AS2 est attendu, sauf si votre acheteur impose un VAN particulier. Drummond certification recommandée.
• Vous êtes fournisseur automobile en Europe : OFTP2 est attendu pour les flux JIT, AS2 admis pour les flux secondaires. Renault, Stellantis, VW l'imposent à leur rang 1.
• Vous émettez ou recevez des factures B2B/B2G en Europe : vous devrez tôt ou tard rejoindre PEPPOL eDelivery sur AS4. La directive est convergente (FR 2026, BE 2026, DE 2025, ES 2026-2027).
• Volume faible, partenaire unique, projet de durée limitée : SFTP est parfaitement adapté, avec une convention bilatérale claire pour l'accusé.
• Mille partenaires, secteur réglementé, exigence d'audit centralisé : un VAN moderne (Stedi, Cleo, Edicom, Pagero) absorbe la complexité de l'orchestration multi-protocoles et offre un journal unifié.
• Vous échangez via cXML (Ariba, Coupa, SAP Business Network) : le transport est HTTPS direct avec authentification mutuelle TLS et signatures cXML — pas d'AS2 ni d'OFTP2. Le payload cXML porte ses propres réponses.

RFC et spécifications de référence

Chaque famille s'appuie sur des documents publics consultables verbatim :

• RFC 4130 — AS2, MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP. Le texte canonique d'AS2 ; rfc-editor.org/rfc/rfc4130.txt (99 857 octets, archivé dans content/_sources/rfc/rfc4130_AS2.txt).
• RFC 5024 — OFTP 2, ODETTE File Transfer Protocol 2.0 ; rfc-editor.org/rfc/rfc5024.txt (276 953 octets, archivé dans content/_sources/rfc/rfc5024_OFTP2.txt).
• RFC 3335 — AS1, le prédécesseur SMTP d'AS2. Encore référencé pour certains MDN asynchrones par courrier électronique ; rfc-editor.org/rfc/rfc3335.txt (59 687 octets, archivé dans content/_sources/rfc/rfc3335_AS1.txt).
• OASIS ebMS 3.0 / AS4 Profile — la spécification d'AS4 et son profil PEPPOL ; docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile.
• RFC 4253 — The Secure Shell (SSH) Transport Layer Protocol, base cryptographique de SFTP. rfc-editor.org/rfc/rfc4253.
• RFC 3274, RFC 5402, RFC 6362 — compléments à AS2 (compression CMS, compression EDI, attachements multiples).

Pour aller plus loin

• AS2 — anatomie détaillée avec exemples HTTP réels.
• Parcours d'un interchange — où ces protocoles s'insèrent dans le flux complet.
• PEPPOL — pour le contexte AS4 + facturation européenne.
• Glossaire — VAN · Glossaire — EDIINT · EDIFACT ORDERS D.96A.
• Validateur EDIFACT — pour valider la charge utile portée par n'importe lequel de ces protocoles.