Le paysage des standards EDI

Cinq standards de messages couvrent en 2026 plus de 95 % des flux EDI mondiaux. Cette page en dresse la carte — géographique, sectorielle et fonctionnelle — pour qu'on puisse choisir, devant un projet d'intégration, le standard qui correspond réellement aux contraintes de marché.

Cinq familles, deux mondes

Le paysage se laisse appréhender par une fracture géographique d'abord. À l'ouest de l'Atlantique, le standard dominant est ANSI ASC X12, né en 1979. Partout ailleurs — Europe, Asie, Amérique latine, Afrique — c'est UN/EDIFACT, né en 1987 sous l'égide des Nations Unies, qui structure les flux. À côté de ces deux poids lourds historiques, trois standards plus jeunes ont chacun colonisé un périmètre fonctionnel ou sectoriel précis : cXML pour l'e-procurement transactionnel, SAP OCI pour le punchout catalogue, UBL/PEPPOL pour la facturation électronique européenne obligatoire à partir de 2025/2026. On les passe en revue.

EDIFACT — Europe et reste du monde

UN/EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) est maintenu par l'UN/CEFACT, le centre des Nations Unies pour la facilitation des échanges. Sa syntaxe est gravée dans ISO 9735 (depuis 1988) et son annuaire de messages — dit « directory » — est mis à jour deux fois par an selon une nomenclature stable D.<YY>A (printemps) et D.<YY>B (automne). Le directory dominant historiquement reste D.96A (1996) en distribution et en logistique européennes ; D.01B (2001) est second ; D.16B (2016) est référencé par EN 16931 (e-facturation EU) ; D.24B est la release la plus récente.

Un message EDIFACT est composé de segments à trois lettres séparés par des apostrophes : BGM (Beginning of Message), NAD (Name & Address), LIN (Line Item), DTM (Date/Time), QTY (Quantity), etc. Une vingtaine de types de messages couvrent les cas d'usage transactionnels : ORDERS (commande), ORDRSP (réponse de commande), DESADV (avis d'expédition / ASN), INVOIC (facture), CONTRL (accusé syntaxique), IFTMIN (booking transport).

EDIFACT est partout structuré par des subsets sectoriels qui restreignent ou enrichissent le directory officiel : EANCOM (GS1) en distribution, Odette en automobile européenne, CEFIC en chimie, EDIFICE en électronique, PIDX en pétrochimie, EDIFER en sidérurgie. Chaque subset publie ses propres règles d'implémentation : un ORDERS EANCOM n'est pas le même qu'un ORDERS Odette, même si tous deux sont conformes au directory D.96A. C'est la raison principale pour laquelle un projet EDI commence toujours par identifier le subset attendu.

X12 — Amérique du Nord

L'ANSI ASC X12 est l'organisme américain équivalent d'UN/CEFACT : il publie le standard X12, accrédité par l'American National Standards Institute depuis 1979. Les transactions sont identifiées par un numéro à trois chiffres : 850 Purchase Order, 855 PO Acknowledgment, 856 Ship Notice (ASN), 810 Invoice, 820 Payment / Remittance, 997 Functional Acknowledgment (l'équivalent CONTRL).

Les releases sont semestrielles et se cumulent : 003040, 004010 (la plus déployée historiquement en retail US), 005010 (mandatée par HIPAA pour la santé américaine), 006020, 007030, 008010. Chaque version est un sur-ensemble de la précédente ; la migration entre versions est rare mais lourde quand elle survient. Le standard est partagé entre six sous-comités : X12M (Supply Chain), X12N (Insurance, dont HIPAA), X12I (Transportation), X12F (Finance), X12C (Communications & Controls), X12J (Technical Assessment).

X12 est sous copyright strict d'ANSI X12 ; les implementation guides (TR3) sont payants. Ediverse documente les concepts et les structures sans redistribuer les specs payantes — cf. disclaimer.

cXML — Ariba et SAP Business Network

cXML (commerce eXtensible Markup Language) est le standard d'Ariba, racheté par SAP en 2012 et désormais cœur technique du SAP Business Network. Né en 1999, c'est un standard XML couvrant six grandes catégories transactionnelles : Setup (ProfileRequest pour la découverte de capacités), Punchout (PunchOutSetupRequest, PunchOutOrderMessage pour le retour de panier), Commercial (OrderRequest, ConfirmationRequest, ShipNoticeRequest, InvoiceDetailRequest), Catalog (Supplier, Contract, Index), StatusUpdate, Quote.

Versions notables : 1.0 en 1999, 1.1.x entre 2000 et 2004, 1.2.x depuis 2005, 1.2.069 en circulation aujourd'hui. cXML est documenté via des DTD publiques publiées sur xml.cxml.org ; ediverse archive les six DTD principales (cXML.dtd, Fulfill.dtd, InvoiceDetail.dtd, Catalog.dtd, PaymentRemittance.dtd, Quote.dtd) dans content/_sources/cxml/1.2.061/ avec citations de ligne pour chaque assertion. C'est le standard à privilégier dès qu'un acheteur opère sur SAP Ariba, Coupa, Jaggaer ou Ivalua avec intégration Business Network.

SAP OCI — punchout vers SRM/Ariba

SAP OCI (Open Catalog Interface) est un mécanisme de punchout standardisé par SAP : depuis un système acheteur (SAP SRM, Ariba Buyer, autre), un utilisateur « saute » dans le catalogue web d'un fournisseur, sélectionne des articles, et le contenu du panier est posté en retour sous forme de NEW_ITEM-<FIELD> dans un POST HTML. Le mécanisme est purement HTTP, pas un format de message à proprement parler — c'est sa simplicité et son universalité qui ont fait son succès.

Versions principales : 2.0B (vers 2000), 4.0 (vers 2004, encore largement déployée), 5.0 (vers 2014, federated search). Les champs dominants sont NEW_ITEM-DESCRIPTION, NEW_ITEM-MATNR, NEW_ITEM-QUANTITY, NEW_ITEM-UNIT (référencé UNECE Rec 20), NEW_ITEM-PRICE, NEW_ITEM-CURRENCY (ISO 4217), plus les codes vendeur et catalogue. OCI ne couvre pas le post-commande — c'est cXML, EDIFACT ou X12 qui prennent ensuite le relais pour le bon de commande proprement dit. OCI est donc complémentaire des standards transactionnels, pas un substitut.

UBL et PEPPOL — facturation européenne

UBL (Universal Business Language) est le standard XML de l'OASIS pour les documents commerciaux. UBL 2.1 (2013) puis 2.4 définissent une vingtaine de documents — Invoice, Order, OrderResponse, Catalogue, DespatchAdvice, ReceiptAdvice, CreditNote, ApplicationResponse — couvrant tout le cycle commande-livraison-facture sous une sémantique unifiée.

PEPPOL est l'écosystème opérationnel qui rend UBL utilisable dans la pratique. OpenPEPPOL maintient des profils business (BIS — Business Interoperability Specifications) qui contraignent UBL pour des cas d'usage précis. Le profil le plus utilisé est BIS Billing 3.0, qui transpose la norme européenne EN 16931 (sémantique d'une facture électronique européenne, 165 termes business + 150 règles) en syntaxe UBL utilisable. À côté : BIS Catalogue 3.0, BIS Despatch Advice 3.0, BIS Order Only 3.0.

L'enjeu réglementaire est central en 2026 :

• Belgique : PEPPOL BIS Billing 3.0 obligatoire B2B depuis le 1^er janvier 2026.
• France : réception obligatoire de toutes les factures B2B en septembre 2026 (PPF + plateformes agréées), émission obligatoire pour les grandes entreprises en septembre 2027. Formats admis : Factur-X (CII), UBL, EDIFACT INVOIC.
• Allemagne : réception obligatoire depuis le 1^er janvier 2025 (XRechnung ou ZUGFeRD).
• Italie : FatturaPA via SdI déjà obligatoire.
• Espagne : Facturae + hub national 2026-2027.
• Pologne : KSeF février 2026 puis 2027.

À côté de UBL pur, le format hybride Factur-X (FR) / ZUGFeRD (DE) combine un PDF/A-3 humainement lisible avec un XML structuré au format Cross Industry Invoice (CII, UN/CEFACT) ; c'est une syntaxe différente d'UBL, mais qui implémente la même norme EN 16931.

Comparaison synthétique

Arbre de décision

Pour orienter le choix face à un projet d'intégration concret, on peut suivre l'arbre suivant :

1. Le flux est-il une facture B2B/B2G en Europe ? → PEPPOL BIS Billing 3.0 (UBL ou CII via Factur-X). Aucune autre option viable à moyen terme, compte tenu des mandats nationaux convergents.
2. Le flux passe-t-il par SAP Ariba, Coupa, Jaggaer, Ivalua ou un autre marketplace B2B ? → cXML pour les transactions, OCI pour le punchout catalogue. L'écosystème impose le standard.
3. Le partenaire est-il en Amérique du Nord et imposes un format ANSI ? → X12 (version selon le partenaire : 004010 en distribution, 005010 en santé HIPAA, 006020+ en migration).
4. Le partenaire est-il en automobile européenne ? → EDIFACT subset Odette sur OFTP2. Renault, Stellantis, VW, BMW imposent ce duo.
5. Le partenaire est-il en distribution européenne ? → EDIFACT subset EANCOM (GS1) sur AS2 ou OFTP2.
6. Sinon, l'EDIFACT reste l'option par défaut hors Amérique du Nord pour les flux transactionnels commande-livraison-facture. Le directory pivote en D.96A par tradition, D.01B en récent, D.16B/D.21B quand l'acheteur est moderne.

Autres standards à connaître

• RosettaNet — PIPs (Partner Interface Processes) sectoriels en électronique et semi-conducteur ; format XML. Site officiel chez GS1 US.
• OAGi BODs — Business Object Documents, framework d'intégration applicative générique en XML porté par OAGi.
• TRADACOMS — standard historique UK en retail, en déclin mais encore présent dans certaines chaînes de distribution britanniques.
• HL7 v2 (pipe-délimité, EDIFACT-like) et HL7 FHIR (REST/JSON moderne) — santé hors HIPAA US.
• SWIFT MT (legacy) et ISO 20022 / MX (moderne) — messages financiers entre banques. Migration globale vers ISO 20022 en cours.

Pour aller plus loin

• Page d'accueil des standards — les hubs détaillés EDIFACT, X12, cXML, OCI, PEPPOL, AS2.
• EDIFACT ORDERS D.96A — la page canonique du message le plus échangé sur la planète.
• Parcours d'un interchange — comment un message voyage entre les deux SI, indépendamment du standard.
• Protocoles — le choix de transport associé à chaque standard.
• Glossaire — EDI · Glossaire — B2B · Validateur EDIFACT.