Parcours d'un interchange EDI

Sept étapes séparent la sortie d'une commande dans un ERP acheteur de l'accusé syntaxique renvoyé par le SI fournisseur. Cette page suit chacune d'elles, horodatage à l'appui, sur un ORDERS EDIFACT D.96A transporté en AS2.

Vue d'ensemble — sept étapes

Le parcours d'un interchange EDI se décompose en sept opérations enchaînées par deux SI distincts, le réseau servant de fil entre eux. Quatre opérations sont côté émetteur, trois sont côté récepteur, et la dernière étape — la réponse métier — peut être suivie symétriquement dans la direction inverse :

1. Génération du document métier depuis l'ERP.
2. Enveloppement EDIFACT : UNB/UNH ajoutés autour du message.
3. Mise en MIME et signature S/MIME : chiffrement et signature cryptographique.
4. Transport par AS2 (ou OFTP2, SFTP, AS4) sur Internet.
5. Réception et MDN : le récepteur accuse cryptographiquement la réception.
6. Désenveloppement et parsing : déchiffrement, vérification de signature, tokenisation EDIFACT.
7. Accusé CONTRL puis réponse métier : ORDRSP renvoyé, voyage inverse.

1. Génération depuis l'ERP

L'utilisateur d'ACME Retail valide une commande dans son ERP — SAP, Oracle Fusion, Microsoft Dynamics, Sage X3, peu importe. L'ERP enrichit la commande avec les données partenaires (GLN du fournisseur, conditions de livraison, contrat-cadre référencé), puis appelle un module de mapping qui transforme le modèle interne ERP en structure EDIFACT D.96A. Ce mapping est habituellement maintenu par un intégrateur EDI : GXS/OpenText, Generix, B2BRouter, Cleo, Edicom, Pagero, Stedi, Tenor — ou par une brique interne dans les groupes les plus matures. Le résultat est une chaîne de caractères respectant la syntaxe ISO 9735.

2. Enveloppement EDIFACT

Le message ORDERS proprement dit est encadré par deux niveaux d'enveloppe :

• Niveau message : les segments UNH (Message Header) et UNT (Message Trailer) délimitent un message individuel et portent son type, sa version (ici ORDERS:D:96A:UN:EAN008) et son numéro de référence local.
• Niveau interchange : les segments UNB (Interchange Header) et UNZ (Interchange Trailer) délimitent l'enveloppe extérieure. UNB porte le jeu de caractères (UNOC:3), les identifiants GLN émetteur et destinataire avec leur qualifier (14 = GLN/EAN), la date et l'heure de production, et le numéro de contrôle d'interchange — ici CTRL000042, unique par paire d'identifiants.

Une service string advice UNA:+.? ' peut précéder l'UNB pour redéfinir les séparateurs si la donnée transportée comporte des apostrophes, des plus ou des deux-points dans des chaînes libres. Le résultat typique pour notre commande :

UNA:+.? '
UNB+UNOC:3+5410000000123:14+5410000000456:14+260514:0930+CTRL000042++ORDERS'
UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+ORDER789+9'
DTM+137:202605140929:203'
DTM+2:20260520:102'
NAD+BY+5410000000123::9++ACME RETAIL SA'
NAD+SU+5410000000456::9++DELTA SUPPLY GMBH'
RFF+CT:CONTRACT-2026-Q2'
LIN+1++3520000001234:EN'
IMD+F++:::CARTON CHOCOLAT NOIR 100G'
QTY+21:24'
PRI+AAA:1.20'
UNS+S'
CNT+2:1'
UNT+12+1'
UNZ+1+CTRL000042'

3. Mise en MIME et signature S/MIME

L'agent AS2 (Cleo Harmony, IBM Sterling B2B Integrator, OpenAS2, BizManager, etc.) récupère le fichier EDI sortant et le transforme en charge utile MIME. RFC 4130 §4.2 énumère les types MIME admissibles ; pour EDIFACT, c'est application/EDIFACT qui doit être déclaré dans le Content-Type. L'agent signe ensuite la charge utile avec la clé privée du couple ACME-Retail / Delta et la chiffre avec la clé publique S/MIME de Delta. Le résultat est un multipart/signed RFC 1847, optionnellement réencapsulé dans un application/pkcs7-mime chiffré (CMS, RFC 3851/3852).

4. Transport AS2 (ou OFTP2, SFTP, AS4)

L'agent émetteur ouvre une connexion TCP/443 vers l'URL AS2 du partenaire — typiquement https://as2.delta-supply.example/edi/receive — et envoie un POST HTTP/1.1 portant les en-têtes AS2 obligatoires (RFC 4130 §6) :

• AS2-Version: 1.1
• AS2-From: "ACME-RETAIL"
• AS2-To: "DELTA-SUPPLY"
• Message-Id: <20260514093001@acme-retail.example>
• Disposition-Notification-To: as2@acme-retail.example
• Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha256

Le couple émetteur-récepteur peut aussi avoir négocié un canal alternatif : OFTP2 (RFC 5024) chez les constructeurs automobiles, SFTP pour les flux à faible volume entre partenaires de confiance, AS4 (OASIS ebMS 3.0) au sein du réseau PEPPOL eDelivery. Le principe — chiffrement, signature, accusé — reste le même.

5. Réception et MDN

L'agent AS2 du fournisseur reçoit le POST. Il vérifie la signature S/MIME contre la clé publique enregistrée pour le partenaire ACME-RETAIL, déchiffre la charge utile si elle est chiffrée, et calcule un MIC (Message Integrity Check) sur le contenu reçu. Il renvoie ensuite un MDN (Message Disposition Notification) signé contenant ce MIC. Si l'émetteur retrouve le même MIC que celui qu'il avait calculé à l'envoi, il a une preuve cryptographique de non-répudiation de la réception (NRR, RFC 4130 §2.3.1).

Le MDN peut être synchrone (corps de la réponse HTTP du POST initial, simple à corréler) ou asynchrone (nouveau POST entrant quelques secondes plus tard, à réconcilier via Original-Message-ID). Le choix est négocié à l'enrôlement.

6. Désenveloppement et parsing

Le payload EDIFACT clair est ensuite passé au moteur EDI du fournisseur. Trois passes successives s'enchaînent :

1. Tokenisation syntaxique — un parseur lit segment par segment en respectant les séparateurs déclarés par l'UNA ou par défaut (', +, :, ? en escape).
2. Validation d'enveloppe — vérification de la cohérence UNB/UNZ (référence de contrôle identique, compteur d'interchanges) et UNH/UNT (référence de message identique, compteur de segments).
3. Validation sémantique — vérification que tous les segments présents sont licites pour le type de message ORDERS dans l'annuaire D.96A (segments obligatoires présents, segments interdits absents, codes de qualifier valides). C'est précisément le rôle du validateur EDIFACT d'ediverse, qui propose ces trois passes en local dans le navigateur.

7. Accusé CONTRL et réponse métier

Si toutes les validations passent, le moteur émet immédiatement — typiquement dans la seconde — un message CONTRL de réception positive. CONTRL est le message d'accusé syntaxique défini par ISO 9735 partie 4. Le segment UCI rappelle la référence de l'interchange acquitté (ici CTRL000042), et le code 7 en composant 0083 signale un « Interchange received ».

UNB+UNOC:3+5410000000456:14+5410000000123:14+260514:0931+CTRL000043'
UNH+1+CONTRL:D:96A:UN'
UCI+CTRL000042+5410000000123:14+5410000000456:14+7'
UCM+1+ORDERS:D:96A:UN+7'
UNT+4+1'
UNZ+1+CTRL000043'

Dans un second temps — quelques secondes à quelques minutes plus tard, le temps que l'application métier qualifie la commande contre son catalogue, son stock et son encours client — le SI fournisseur émet un message ORDRSP qui voyage dans la direction inverse, suivant exactement les mêmes étapes 2 à 6 mais dans l'autre sens. La boucle de l'interchange est alors fermée.

Exemple chronométré

Sur un échange nominal entre partenaires opérationnels, la latence « commande validée → CONTRL reçu » est typiquement comprise entre 3 et 15 secondes. La latence « commande validée → ORDRSP reçu » dépend du SI fournisseur et de la complexité du qualifiant : quelques minutes à quelques heures.

Erreurs aux jointures

Les ennuis se logent presque toujours à la jointure entre deux étapes :

• Étape 2 → 3 — Un caractère non-ASCII (è, é, ç) dans une donnée libre alors que le jeu déclaré dans UNB est UNOC:3 (ISO 8859-1). Le récepteur peut, selon sa tolérance, rejeter syntaxiquement.
• Étape 4 → 5 — Mauvais certificat. La signature S/MIME ne vérifie pas : l'agent récepteur renvoie un MDN d'erreur, l'émetteur ne reçoit jamais de CONTRL, et le SI acheteur attend.
• Étape 6 → 7 — Compteur UNT incorrect (nombre de segments faux), ou référence UNH qui ne correspond pas à celle de UNT. Le validateur émet un CONTRL négatif ; à corriger côté mapping.
• Étape 7 → ORDRSP — Délai applicatif trop long et délai d'ORDRSP expiré côté acheteur, qui déclenche une relance manuelle. Le ratio des partenaires « hors SLA » est typiquement le KPI le plus suivi dans une cellule d'exploitation EDI.

Pour aller plus loin

• EDIFACT ORDERS D.96A — la structure complète du message utilisé en exemple.
• EDIFACT CONTRL D.96A — la structure de l'accusé syntaxique.
• AS2 — le détail du protocole de transport et de la boucle MDN.
• Protocoles, en bref — la comparaison AS2 / OFTP2 / SFTP / AS4 / VAN.
• Validateur EDIFACT — pour tester chaque étape sur votre propre message.