Qu'est-ce que l'EDI ?

L'Electronic Data Interchange désigne l'échange structuré, automatique et standardisé de documents commerciaux entre les systèmes informatiques de deux organisations distinctes, sans intervention humaine sur le contenu transactionnel.

Définition

On parle d'EDI dès lors qu'un document commercial — bon de commande, accusé de réception, avis d'expédition, facture, état de stock — est généré automatiquement par un système d'information, transmis dans un format structuré que le système destinataire sait interpréter sans ambiguïté, puis traité par celui-ci sans intervention humaine sur le contenu transactionnel. Le contenu suit une syntaxe normalisée — EDIFACT sous l'égide des Nations Unies, X12 sous l'égide de l'ANSI américain, cXML dans l'écosystème Ariba/SAP, UBL/PEPPOL en facturation électronique européenne — et transite via un protocole de transport sécurisé : AS2, OFTP2, SFTP, AS4 ou réseau à valeur ajoutée (VAN).

Le périmètre de l'EDI est volontairement commercial : il couvre les flux transactionnels entre acheteurs et fournisseurs, entre donneurs d'ordre et transporteurs, entre payeurs et fournisseurs de soins, entre administrations et déclarants. Il ne couvre pas les communications inter-applicatives à l'intérieur d'une même organisation (qui relèvent de l'EAI ou du bus applicatif) ni les flux de contenu non transactionnel — la documentation produit, le marketing, les fichiers plats arbitraires.

Origine historique

Le concept d'EDI naît à la fin des années 1960 dans le transport ferroviaire et routier nord-américain. Les transporteurs s'échangent depuis longtemps des manifestes d'expédition par télex ou par formulaire papier ; ils cherchent alors un moyen d'automatiser ces transmissions à un volume croissant. Edward A. Guilbert, surnommé le « père de l'EDI », pilote dès 1965 chez DuPont les premiers échanges automatisés de listes de cargaisons par télex avec un transporteur, dans un format propriétaire : c'est l'ancêtre direct de ce que nous appelons EDI aujourd'hui.

Amérique : TDCC puis ASC X12

Dans les années 1970, le besoin de standardiser ces échanges devient pressant. Le Transportation Data Coordinating Committee (TDCC) publie en 1975 le premier standard EDI multi-acteurs aux États-Unis, dédié au transport. L'American National Standards Institute (ANSI) confie en 1979 à un comité accrédité — l'Accredited Standards Committee X12 — la mission d'élargir la démarche à tous les secteurs économiques. Le premier set de transactions X12 (la version 003010) est ratifié en 1983, suivi de 004010 en 1997 — la version qui reste, en 2026, la plus déployée dans le retail nord-américain malgré l'arrivée de 005010 (mandatée par HIPAA en santé) et de 006020.

Europe : EDIFACT et UN/CEFACT

En Europe, plusieurs standards nationaux émergent en parallèle dans les années 1970-80 — TRADACOMS au Royaume-Uni, GENCOD en France, SEDAS en Allemagne. La Commission économique des Nations Unies pour l'Europe (UNECE) lance en 1986 le projet UN/EDIFACT (EDI For Administration, Commerce and Transport) pour unifier ces approches. La syntaxe est gravée dans ISO 9735 dès 1988, et l'annuaire des messages est mis à jour deux fois par an depuis 1993, avec des releases nommées D.<YY>A au printemps et D.<YY>B à l'automne — de D.93A en 1993 à D.24B en 2024. Le gardien de l'évolution est désormais l'UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business), qui réunit des délégations nationales et sectorielles bénévoles.

Les trois caractéristiques distinctives

L'EDI ne se définit pas par le seul fait qu'un document soit envoyé en informatique : trois propriétés conjuguées le distinguent d'un simple échange de fichiers.

1. Structure normalisée

Un message EDI n'est pas une chaîne arbitraire mais une structure publiée et versionnée par un organisme de normalisation. En EDIFACT D.96A, un segment BGM+220+ORDER789+9 n'est pas un texte libre : BGM est le Beginning of Message, 220 est la valeur « Order » dans la liste UN/EDIFACT 1001, ORDER789 est le numéro métier, et 9 indique « Original » dans la liste 1225. Tout intégrateur, n'importe où dans le monde, peut lire et interpréter exactement de la même façon ce segment en se référant aux annuaires UN/CEFACT ; il en va de même d'une transaction X12, d'un document cXML ou d'une facture UBL. C'est cette portabilité de jure qui différencie l'EDI d'un export CSV propriétaire entre deux entreprises particulières.

2. Identification mutuelle

Chaque partie à un échange EDI est identifiée par un code stable, persistant et international, qui n'est ni un email ni une URL. Les schémas les plus répandus sont le GLN (Global Location Number, GS1, ICD 0088) en distribution, le DUNS (Dun & Bradstreet, ICD 0060) dans l'industrie nord-américaine, le SIRET en France pour les flux publics, ou l'identifiant PEPPOL sous forme iso6523-actorid-upis::<ICD>:<value> pour la facturation européenne. La conséquence pratique est qu'un message reste interprétable même quand le partenaire change de système d'information, d'opérateur ou de domaine email : l'identifiant économique survit aux changements d'infrastructure.

3. Acquittement bidirectionnel

L'EDI exige enfin un retour formalisé. En EDIFACT, ce retour s'appelle CONTRL pour l'accusé syntaxique (le destinataire confirme que l'interchange est bien arrivé et bien formé) et APERAK pour l'accusé applicatif (le moteur métier confirme que le message a été pris en compte ou rejeté avec un motif). En X12, c'est la transaction 997 (Functional Acknowledgment, historique) ou 999 (Implementation Acknowledgment, récente, schéma 5010+) qui joue ce rôle. Au-dessus de ces accusés métier, le protocole de transport AS2 ajoute un MDN (Message Disposition Notification) cryptographique qui donne une preuve de non-répudiation de la réception (NRR). Aucun échange EDI ne se conçoit sans cette boucle — c'est elle qui distingue l'EDI d'un simple dépôt SFTP « dans l'espoir que ça arrive ».

Ce que l'EDI n'est pas

Quelques erreurs fréquentes méritent d'être désamorcées dès l'entrée :

• Un email avec une pièce jointe XML n'est pas de l'EDI — il manque l'acquittement formalisé, l'identification mutuelle stable et, le plus souvent, la conformité à un standard public.
• Un dépôt SFTP régulier de fichiers CSV n'est pas non plus de l'EDI — le transport est correct mais la structure n'est pas normalisée et il n'y a pas d'acquittement.
• L'EDI n'impose pas une syntaxe particulière : EDIFACT à segments, X12 à segments, cXML XML, UBL XML, ou demain un payload JSON — tous peuvent être de l'EDI dès lors que les trois caractéristiques ci-dessus sont réunies.
• L'EDI n'est pas l'B2B tout entier : tout EDI est un échange B2B, mais une bonne moitié des échanges B2B modernes (API REST, portails fournisseurs, marketplaces) ne sont pas structurés comme de l'EDI. Le sujet est traité en détail sur la page suivante.

Pour aller plus loin

Trois portes naturelles pour poursuivre :

• B2B vs EDI — la frontière exacte entre le périmètre commercial B2B et le périmètre strict de l'EDI.
• Parcours d'un interchange — les étapes concrètes, ERP par ERP, d'un ORDERS qui sort, voyage et est acquitté.
• EDIFACT ORDERS D.96A — la page canonique du message le plus échangé sur la planète.
• Validateur EDIFACT — pour tester par la pratique sur un message réel.