Glossaire EDI : définitions des termes, messages et protocoles

A

AIAG (Automotive Industry Action Group)

Association américaine créée par des constructeurs pour harmoniser les standards logistiques, qualité et EDI dans l’industrie automobile.
L’AIAG publie des guides d’implémentation EDI basés sur ANSI X12 pour les documents comme :

• 830 (Planning de livraison – Forecast)
• 862 (Instruction livraison – JIT)
• 856 (Avis d’expédition)

Elle fournit aussi des standards de numérotation logistique (étiquettes, codes SSCC) et des modèles de conformité pour la supply chain nord-américaine.

ACK (Acknowledgment)

Message ou signal envoyé pour confirmer la réception correcte d’un message EDI. Un ACK signifie que le fichier a été reçu avec succès et, selon le protocole ou le type d’ACK, que sa structure est techniquement valide.

Il ne garantit pas forcément que les données métier sont acceptées, mais assure que le message a bien transité et qu’il est interprétable par le système destinataire.

ANSI X12 (American National Standards Institute)

Norme EDI développée par l’American National Standards Institute, principalement utilisée en Amérique du Nord. Elle définit la syntaxe et la structure de nombreux documents commerciaux (commande, facture, avis d’expédition, etc.). Chaque document est identifié par un numéro de transaction (par ex. : 850 = commande, 810 = facture). ANSI X12 est l’équivalent nord-américain d’EDIFACT.

APERAK (Application Error and Acknowledgement Message)

Message standard de la norme EDIFACT, utilisé pour envoyer un accusé de réception fonctionnel ou signaler une erreur d’application suite à la réception d’un message EDI.

Contrairement au message CONTRL (qui valide uniquement la structure syntaxique d’un fichier), APERAK indique si le contenu métier du message reçu est accepté, partiellement accepté ou rejeté, avec des motifs d’erreur explicites.

API (Application Programming Interface)

Une API est une interface logicielle qui permet à deux systèmes ou applications de communiquer entre eux automatiquement, via des requêtes structurées.

Dans le contexte EDI :

• Les API REST sont souvent utilisées pour échanger des données en temps réel, en complément ou en alternative à l’EDI traditionnel.
• Elles permettent une intégration plus flexible, notamment avec les ERP cloud, les applications mobiles ou les services SaaS.

Exemple : une API peut transmettre une commande ou mettre à jour un statut de livraison instantanément, sans attendre un fichier EDI batch.

AS2 (Applicability Statement 2)

Protocole de communication sécurisé basé sur HTTP/S permettant l’échange de documents EDI via Internet. Il garantit la confidentialité, l’intégrité, l’authentification et l’accusé de réception (MDN) grâce à l’utilisation de certificats numériques et de signatures électroniques. AS2 est particulièrement prisé dans les secteurs de la grande distribution et de la logistique, car il permet des échanges en temps réel et évite les intermédiaires comme les VANs.

AS4 (Applicability Statement 4)

Protocole de communication sécurisé pour les échanges EDI, basé sur le standard ebMS 3.0 (ebXML Messaging Service) et conçu pour répondre aux besoins modernes en matière de fiabilité, sécurité et conformité.

Il succède à AS2 et s’inscrit dans les efforts de standardisation promus par l’Union européenne pour des échanges dématérialisés sûrs, notamment dans le cadre de PEPPOL ou de la facturation électronique réglementaire.

B

Batch EDI (EDI en mode lot)

Méthode de traitement EDI où les messages sont regroupés et envoyés à intervalles réguliers, plutôt qu’en temps réel.
Couramment utilisée pour les systèmes legacy ou les plateformes à faible fréquence de mise à jour.

BGM (Beginning of Message)

Segment EDIFACT situé en début de message, qui indique le type de document (ex. : facture, commande), son numéro unique et son statut (original, duplicata, etc.).
C’est un segment obligatoire dans la majorité des messages EDIFACT (INVOIC, ORDERS, DESADV…).

Blockchain & EDI

Technologie émergente utilisée pour renforcer la traçabilité, l’intégrité et l’authenticité des échanges EDI.
Exemples d’usage : validation de factures, registre partagé des expéditions, preuve d’origine.
À ce jour, l’intégration EDI + blockchain reste exploratoire mais prometteuse dans certains secteurs (pharma, luxe, agroalimentaire).

Bon de Livraison (DESADV / ASN)

Document EDI envoyé par le fournisseur pour informer de l’expédition de marchandises. Dans EDIFACT, il s’agit du message DESADV ; dans ANSI X12, de l’ASN (Advanced Shipping Notice – 856). Il contient des informations détaillées sur les produits expédiés, les quantités, les palettes, les numéros de lot et de série, souvent utilisées pour la réception automatisée en entrepôt (cross-docking, scan code SSCC).

Business Document Header

Nom générique désignant la partie en-tête d’un document EDI (EDIFACT, X12 ou XML), contenant les métadonnées : identifiant message, date, version, type, etc.
Essentiel pour le routage, le contrôle et l’archivage des flux.

Bottleneck (goulot d’étranglement EDI)

Nom générique désignant la partie en-tête d’un document EDI (EDIFACT, X12 ou XML), contenant les métadonnées : identifiant message, date, version, type, etc.
Essentiel pour le routage, le contrôle et l’archivage des flux.

C

CAAM
(China Association of Automobile Manufacturers) /
CPCA
(China Passenger Car Association)

Deux organismes majeurs représentant l’industrie automobile chinoise. Bien qu’ils ne soient pas exclusivement centrés sur l’EDI, ils participent à la structuration des échanges interentreprises, à la normalisation des données véhicules et au pilotage des plateformes numériques utilisées dans les flux B2B.
Ils collaborent avec ZETA sur des projets EDI structurants pour la filière.

CII (Cross Industry Invoice)

Modèle de facture électronique générique développé par l’UN/CEFACT, utilisable dans tous les secteurs industriels. Il structure les données d’une facture en s’appuyant sur des standards universels, dans une logique d’interopérabilité internationale. Le CII est parfois préféré à UBL pour des projets impliquant des échanges transfrontaliers ou des grandes entreprises multi-sectorielles.

Compliance (Conformité EDI)

Capacité d’une entreprise à envoyer/recevoir des messages EDI selon les spécifications techniques et commerciales exigées par ses partenaires. Cela implique le respect strict des formats, des segments obligatoires, de la ponctuation, des protocoles d’échange, et des délais. L’absence de conformité peut entraîner des pénalités, des rejets de commande ou l’interruption de la relation commerciale.

CONTRL

Message EDIFACT confirmant la réception technique d’un fichier EDI et sa conformité syntaxique. Équivalent au message 997 dans ANSI X12.

D

DESADV (EDIFACT) / 856 (X12)

Message d’avis d’expédition (voir Bon de Livraison).

DELFOR (EDIFACT) / 830 (X12)

Prévision de livraison. Utilisé pour planifier la production et les approvisionnements, notamment dans l’automobile.

DELJIT (EDIFACT) / 862 (X12)

Instruction de livraison plus précise que le DELFOR. Précise les dates et quantités exactes à livrer.

Document EDI

Unité de base des échanges EDI, correspondant à un acte commercial ou logistique formalisé. Il peut s’agir d’une commande (ORDERS/850), d’un avis d’expédition (DESADV/856), d’une facture (INVOIC/810), etc. Chaque document suit une structure normalisée selon une syntaxe définie (EDIFACT, X12, etc.) et des conventions métier spécifiques.

E

EANCOM (EAN + Communication)

EANCOM est une implémentation sectorielle de la norme EDIFACT, développée par l’organisation GS1. Elle adapte les messages EDIFACT aux besoins spécifiques du commerce et de la distribution, en simplifiant leur structure tout en assurant une compatibilité totale avec les standards internationaux.

Concrètement, EANCOM sélectionne et restreint les segments EDIFACT aux champs réellement utilisés par les acteurs de la chaîne logistique (producteurs, distributeurs, logisticiens…), ce qui facilite l’interopérabilité et réduit les risques d’erreur.

ebMS (ebXML Messaging Service)

Protocole de messagerie basé sur XML/Web Services, développé dans le cadre du projet ebXML (Electronic Business using XML).
Il est utilisé pour échanger des messages B2B sécurisés et standardisés, notamment dans des architectures ouvertes (API + EDI).

AS4, par exemple, repose sur ebMS 3.0.

Fonctions clés :

• Chiffrement et signature numérique
• Accusé de réception (reliable messaging)
• Extensibilité (plug-in de sécurité, enveloppes multiples…)

EDI (Échange de Données Informatisé)

L’EDI désigne le transfert automatisé de documents commerciaux entre deux systèmes d’information d’entreprises, sans intervention humaine et dans un format standardisé.

Au lieu d’échanger des bons de commande, factures ou avis d’expédition par e-mail ou papier, l’EDI permet une transmission directe et sécurisée des données entre partenaires commerciaux (clients, fournisseurs, transporteurs…).

Objectifs :

• Réduire les erreurs de saisie
• Accélérer les traitements logistiques et comptables
• Renforcer la traçabilité et la conformité
• Diminuer les coûts administratifs

Fonctionnement :

L’EDI repose sur trois éléments clés :

1. Standards de message (ex : EDIFACT, ANSI X12, UBL)
2. Protocoles d’échange (ex : AS2, SFTP, OFTP2, VAN)
3. Mapping entre les formats EDI et les données internes (ERP, WMS…)

Exemples de documents échangés en EDI :

• Commande (ORDERS / 850)
• Avis d’expédition (DESADV / 856)
• Facture (INVOIC / 810)
• Prévision de livraison (DELFOR / 830)
• Inventaire (INVRPT / 846)

EDI hébergé

L’EDI hébergé est un modèle intermédiaire entre SaaS et on-premise. L’infrastructure EDI est hébergée et gérée par un prestataire spécialisé, mais peut être dédiée à un client ou personnalisée selon ses besoins.

Ce modèle permet :

• D’externaliser la complexité technique
• De garder un niveau élevé de configuration et de contrôle
• D’intégrer des systèmes spécifiques via VPN, certificats, tunnels SFTP, etc.

Utilisé notamment par les grandes entreprises souhaitant déléguer l’infrastructure EDI sans migrer vers un SaaS standardisé.

EDI On-Premise

L’EDI On-Premise est un modèle dans lequel la solution EDI est installée et gérée directement sur les serveurs de l’entreprise (ou dans son data center privé).

Particularités :

• Contrôle total sur l’infrastructure, la sécurité et les processus
• Nécessite des compétences internes (supervision, maintenance)
• Préféré par les grands groupes industriels avec des exigences fortes en matière d’intégration

Longtemps dominant dans l’EDI classique, ce modèle tend à être progressivement remplacé par des solutions cloud / hybrides.

EDI SaaS (Software as a Service)

L’EDI SaaS est un modèle de déploiement où la solution EDI est hébergée dans le cloud par un prestataire, accessible via Internet, souvent via un abonnement mensuel.

Avantages :

• Aucune infrastructure à gérer
• Mises à jour automatiques
• Accès à distance 24/7
• Idéal pour les PME ou les projets agiles

L’utilisateur consomme le service via une interface web ou des API. Ce modèle est de plus en plus courant pour l’EDI moderne (EDI as a Service)

EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport)

Standard EDI international défini par les Nations Unies via le CEFACT. Très répandu en Europe, EDIFACT est utilisé dans de nombreux secteurs : distribution (EANCOM), transport (IFTM), automobile (ODETTE), santé, etc. Il structure les messages en segments (lignes) et éléments (données), et impose une syntaxe très stricte avec des séparateurs définis (segment = ‘, élément = +, composant = :).

EDIFICE

Communauté internationale centrée sur l’électronique et les télécommunications, qui développe des recommandations d’implémentation EDI spécifiques au secteur (commandes, RMA, livraisons, etc.).

F

Facture – INVOIC (EDIFACT) / 810 (X12)

Message transmis par le fournisseur pour facturer une commande. Contient les lignes de produits, prix, remises, taxes, et informations de règlement.

Flux (EDI ou B2B)

Un flux désigne un échange automatisé de données structurées entre deux systèmes. Dans le cadre de l’EDI, un flux correspond à une transaction EDI (commande, facture, livraison…).

Exemples de flux :

• Flux ORDERS (commande client)
• Flux DESADV (avis d’expédition)
• Flux INVOIC (facture)

Chaque flux suit un cycle de vie (émission → transmission → réception → intégration → accusé).

FTP/SFTP/FTPS

Protocoles de transfert de fichiers utilisés pour l’échange de messages EDI :

• FTP : File Transfer Protocol – non sécurisé.
• SFTP : FTP sur SSH – sécurisé par chiffrement.
• FTPS : FTP sur SSL/TLS – également sécurisé.
  Ces protocoles sont souvent utilisés en alternative à AS2, notamment dans les environnements legacy ou à faible volume.

G

GALIA (Groupement pour l’Amélioration des Liaisons dans l’Industrie Automobile)

Organisation française regroupant les acteurs de la filière automobile (constructeurs, équipementiers, logisticiens), dont la mission est de standardiser les échanges de données techniques et logistiques, notamment via l’EDI.

GALIA adapte et publie des recommandations EDI basées sur EDIFACT, spécifiques au secteur automobile français :

• Messages logistiques (DELFOR, DELJIT, DESADV)
• Étiquetage transport (label GALIA)
• Numérotation SSCC et identification palette

GALIA est membre d’ODETTE et travaille en étroite collaboration avec JAMA, AIAG et d’autres instances internationales du secteur.

Gateway EDI

Passerelle logicielle ou service permettant de centraliser, traduire et router les messages EDI entre les systèmes internes (ERP, WMS, TMS) et les partenaires externes. Une gateway peut être sur site ou dans le cloud, et inclure des fonctions de mapping, d’envoi sécurisé (AS2/SFTP), de journalisation, de monitoring et d’alertes.

Global Message (terme utilisé dans certains environnements EDI)

Concept utilisé dans certaines plateformes EDI (notamment en environnement SaaS multistandard) pour désigner un modèle de message générique et agnostique, capable de s’adapter aux différents standards EDI (EDIFACT, X12, XML, JSON…) via un moteur de conversion.

Usage courant :

• Dans les solutions cloud B2B ou iPaaS (Integration Platform as a Service)
• Permet de définir une seule structure logique de message, qui sera ensuite mappée vers le bon format selon le partenaire

Objectif : simplifier le développement, la maintenance et l’onboarding en évitant de dupliquer les formats par norme/partenaire.

Exemple :

Un “Global Message” de type commande client peut être transformé :

• En ORDERS (EDIFACT) pour Carrefour
• En 850 (X12) pour Walmart
• En UBL pour un portail public européen
• En JSON pour une API ERP

GS1

Organisation internationale à but non lucratif responsable de la normalisation des codes à barres, des identifiants produits (GTIN), et des formats de messages EDI sectoriels, comme EANCOM, une implémentation d’EDIFACT adaptée à la distribution.
GS1 assure la cohérence entre les identifiants physiques (articles, palettes, emplacements) et les données échangées électroniquement.

H

HTTP (HyperText Transfer Protocol)

Protocole de communication utilisé sur le web pour transférer des données entre un client (navigateur ou application) et un serveur. Dans le contexte de l’EDI, HTTP est la base technique de protocoles comme AS2, qui utilisent Internet pour échanger des fichiers de manière directe et automatisée.

Cependant, HTTP seul ne chiffre pas les données : les échanges sont envoyés en clair, ce qui n’est pas sécurisé pour des données sensibles (comme les documents EDI).

HTTPS (HyperText Transfer Protocol Secure)

Version sécurisée du protocole HTTP, dans laquelle les données sont chiffrées à l’aide de SSL/TLS. HTTPS garantit :

• La confidentialité (personne ne peut lire les données)

• L’intégrité (les données n’ont pas été altérées)

• L’authenticité (on sait à qui on parle grâce aux certificats)

C’est le socle sécurisé utilisé dans les échanges EDI par AS2, AS4 ou les portails WebEDI. Tout fichier (commande, facture, etc.) transmis via AS2/HTTPS bénéficie ainsi d’un haut niveau de protection.

I

IFTMIN (EDIFACT) / 204 (X12)

Instruction de transport. Message logistique adressé au transporteur pour lui transmettre les détails d’un chargement ou d’une livraison.

INVOIC / 810

Message EDI de facture envoyé par le fournisseur au client. Il comprend les lignes de facturation, les montants HT/TTC, les conditions de paiement, les taxes, et parfois des informations sur la commande d’origine. Dans EDIFACT, c’est INVOIC, dans ANSI X12 c’est 810. Il peut être accompagné d’un message de réponse (APERAK, CONTRL).

INSDES (EDIFACT) / 940 (X12)

Ordre d’expédition ou de préparation adressé à un prestataire logistique (3PL).

iPaaS (Integration Platform as a Service)

Acronyme de Integration Platform as a Service, une plateforme cloud permettant de connecter différentes applications, systèmes et partenaires de manière centralisée, automatisée et évolutive.

Dans le contexte de l’EDI, un iPaaS permet de :

• Intégrer l’EDI avec des ERP, CRM ou applications SaaS
• Mélanger des flux EDI, API, fichiers plats, JSON/XML dans une logique unifiée
• Superviser les échanges en temps réel
• Créer des workflows métiers visuels sans développement lourd

Avantages d’un iPaaS pour l’EDI :

• Rapidité d’onboarding des partenaires
• Connexion native avec des applications cloud (Salesforce, SAP S/4HANA Cloud, etc.)
• Support des formats hybrides : EDI + API + webhooks
• Supervision centralisée des échanges et alertes

ISO (International Organization for Standardization)

Organisme de normalisation qui définit des normes transversales utilisées dans les systèmes EDI, notamment en matière de structure de données (ex : ISO 9735 pour EDIFACT), de sécurité, ou de qualité des processus d’échange électronique. ISO ne crée pas de messages EDI métier, mais fournit les fondations techniques.

J

JAMA (Japan Automobile Manufacturers Association) / JAPIA (Japan Auto Parts Industries Association)

Organisations japonaises représentant les constructeurs (JAMA) et les équipementiers (JAPIA). Elles ont développé des spécifications EDI très rigoureuses, souvent propriétaires, basées sur VDA ou EDIFACT, mais adaptées aux exigences locales.
JAMA/JAPIA sont à l’origine de formats spécifiques pour les processus logistiques complexes (livraison séquencée, kanban électronique, gestion des lots).

Ils influencent aussi l’adoption du protocole OFTP2, et pilotent des référentiels qualité intégrés aux flux EDI (PPAP, ASN, etc.).

Journalisation EDI (Logging)

Processus de suivi, d’enregistrement et d’archivage des échanges EDI. Permet d’assurer la traçabilité, de faciliter le diagnostic des erreurs et de prouver la bonne transmission ou réception d’un message en cas de litige ou de contrôle réglementaire.

JSON (JavaScript Object Notation)

Format de données léger et lisible, principalement utilisé dans les API REST, mais de plus en plus présent dans les plateformes EDI modernes. Contrairement à XML, JSON est plus concis et facile à traiter par les applications web. Certains fournisseurs d’EDI proposent aujourd’hui des connecteurs ou des mappings EDI-to-JSON pour les intégrations hybrides (ex. : EDI ↔ ERP Cloud via API).

JSON-EDI

Terme désignant les structures EDI exprimées en format JSON. Non standardisé de façon formelle, mais utilisé dans les solutions iPaaS ou EDI « as-a-Service » pour encapsuler des messages EDI dans des formats adaptés au web. Cela permet de connecter l’EDI traditionnel avec les architectures modernes (API, microservices).

K

Keep-alive

Mécanisme réseau utilisé dans certains protocoles EDI comme AS2 ou OFTP2 pour maintenir la connexion active entre deux systèmes. Il permet de détecter rapidement une déconnexion et d’éviter les interruptions silencieuses dans les transferts de messages.

Kanban EDI

Application du concept de flux tirés dans les échanges EDI, notamment via les messages DELJIT ou KANBAN. Utilisé dans l’automobile et l’industrie pour signaler à un fournisseur qu’une quantité précise doit être livrée immédiatement, souvent en lien avec des bacs physiques.

Key Management

Dans le contexte EDI sécurisé (AS2, AS4), gestion des certificats numériques et clés de chiffrement pour assurer l’authentification, la confidentialité et l’intégrité des échanges. Peut inclure le renouvellement automatique ou la rotation de clés.

L

Loop (Boucle) – ANSI X12

Structure répétable dans les messages ANSI X12. Elle regroupe des segments logiquement liés (ex. : lignes de commande) qui peuvent apparaître plusieurs fois dans un même message. Les boucles permettent une organisation hiérarchique et la répétition structurée d’informations.

M

Mapping EDI

Processus de transformation des données entre un format interne (ERP, CSV, XML, etc.) et une norme EDI standard (EDIFACT, X12, etc.). Le mapping assure la traduction structurée des données métier, en respectant les règles syntaxiques et les spécifications propres à chaque partenaire commercial.

Message EDI

Unité logique d’un échange EDI, définie selon une norme (ORDERS, DESADV, INVOIC, etc.). Chaque message contient des segments et éléments hiérarchisés décrivant une transaction commerciale ou logistique.

N

NAK (Negative Acknowledgment)

Message ou signal de rejet utilisé dans les échanges EDI (et plus largement dans les protocoles de communication) pour indiquer que le message reçu contient une erreur ou qu’il n’a pas pu être traité correctement.

Contrairement à un ACK (Acknowledgment) qui confirme une réception valide, le NAK signale que :

• La syntaxe du message est incorrecte
• Le message est incomplet ou invalide
• Il ne respecte pas les règles attendues (structure, segments requis, valeurs attendues)

En EDI :

• • En X12, un message 997 peut contenir un NAK segment pour désigner un rejet
  • En EDIFACT, l’équivalent fonctionnel est souvent exprimé via CONTRL ou APERAK

Normes EDI

Ensemble de règles définissant le format, la structure et la syntaxe des messages EDI. Exemples :

• EDIFACT : international, piloté par l’ONU
• ANSI X12 : Amérique du Nord
• ODETTE : industrie automobile
• TRADACOMS : distribution au Royaume-Uni
• EANCOM : distribution – déclinaison d’EDIFACT

O

OASIS (Organization for the Advancement of Structured Information Standards)

Consortium mondial à l’origine de nombreux standards ouverts, dont UBL (Universal Business Language). OASIS travaille sur l’interopérabilité des formats de données, la sécurité, et les services web. Très actif dans les domaines de l’e-invoicing, de la facturation publique, et des architectures orientées services (SOA).

ODETTE (Organisation for Data Exchange by Tele Transmission in Europe)

Consortium européen qui définit des standards EDI et logistiques pour l’industrie automobile. ODETTE soutient des formats comme DELFOR, DELJIT, et le protocole OFTP2, tout en publiant des guides pratiques de mise en œuvre EDI entre équipementiers et constructeurs.

OFTP2 (Odette File Transfer Protocol 2)

Protocole de communication sécurisé conçu spécifiquement pour l’échange de fichiers EDI entre entreprises, notamment dans l’industrie automobile et manufacturière. Il s’agit de l’évolution du protocole OFTP (version 1.3), développé par l’organisation ODETTE.

OFTP2 est optimisé pour des échanges volumineux, critiques et internationaux, avec des fonctionnalités robustes adaptées aux flux B2B modernes.

Onboarding fournisseur (EDI)

Protocole de communication sécurisé conçu spécifiquement pour l’échange de fichiers EDI entre entreprises, notamment dans l’industrie automobile et manufacturière. Il s’agit de l’évolution du protocole OFTP (version 1.3), développé par l’organisation ODETTE.

OFTP2 est optimisé pour des échanges volumineux, critiques et internationaux, avec des fonctionnalités robustes adaptées aux flux B2B modernes.

ORDERS (EDIFACT) / 850 (X12)

Commande client. Transmise par l’acheteur pour déclencher une transaction d’achat. Contient articles, quantités, prix, adresses, dates.

ORDRSP (EDIFACT) / 855 (X12)

Réponse à commande. Confirme ou modifie les termes de la commande initiale.

P

Partenaire EDI (Trading Partner)

Entreprise ou organisme avec laquelle une relation EDI est établie. Chaque partenaire a des spécifications propres (format, protocole, fréquence d’échange), documentées dans un accord de partenariat EDI.

PEPPOL (Pan-European Public Procurement Online)

Réseau international soutenu par la Commission européenne, visant à standardiser les échanges électroniques dans la commande publique (factures, commandes, bons de livraison) via des formats comme UBL et des connecteurs conformes. Très utilisé en Europe, notamment pour les obligations de facturation électronique.

PIP (Partner Interface Process)

Dans le cadre de RosettaNet, un PIP est un scénario métier structuré décrivant comment deux entreprises doivent interagir électroniquement autour d’un processus précis (commande, livraison, inventaire, retour, etc.).
Chaque PIP définit :

• Le rôle des partenaires (fournisseur, acheteur, logisticien…)
• Les messages échangés
• La séquence d’échange (workflow)
• Les formats XML à utiliser

Exemples de PIPs :

• PIP 3A4 : Création de commande d’achat
• PIP 4A1 : Notification d’expédition
• PIP 3B2 : Création de facture

Objectif : Harmoniser les processus métier électroniques entre entreprises de secteurs complexes comme l’électronique, les semi-conducteurs ou les télécoms. Contrairement aux standards EDI classiques (EDIFACT/X12), les PIPs intègrent la logique métier, le contenu et le déroulement dans un seul cadre.

RosettaNet est souvent utilisé dans les secteurs high-tech, pharmaceutiques et logistique avancée.

PRICAT (EDIFACT) / 832 (X12)

Catalogue de prix et d’articles. Utilisé pour transmettre des listes produits, descriptions, prix unitaires, conditionnements.

Protocole d’échange

Méthode technique utilisée pour transférer les fichiers EDI entre deux systèmes :

• AS2, AS4 (sécurisés, Internet)
• FTP, SFTP, FTPS (transfert de fichiers)
• OFTP2 (automobile)
• VAN (réseau à valeur ajoutée)

Q

Quality Check (Contrôle Qualité EDI)

Étape de vérification systématique de la qualité des messages EDI avant leur envoi ou après leur réception : conformité au mapping, vérification des valeurs métier, présence des segments obligatoires. Cela réduit les rejets ou erreurs chez le partenaire.

QR Code & EDI

Certains processus logistiques intègrent des QR codes embarquant des données EDI (ex. : code SSCC, ID de palette, lien vers un ASN). L’EDI n’est pas un format visuel, mais ces codes facilitent la liaison physique ↔ numérique.

Query Message

Demande d’information ou de statut via EDI. Exemples : demande de disponibilité produit, statut d’expédition, ou interrogation sur une facture. Ces fonctions sont de plus en plus utilisées via EDI/API hybrides.

R

REMADV (EDIFACT) / 820 (X12)

Avis de règlement. Permet à un client de notifier à son fournisseur le règlement d’une ou plusieurs factures.

RosettaNet

RosettaNet est un standard d’échange de données interentreprises (B2B) basé sur XML, conçu pour automatiser les processus métiers complexes entre partenaires de la chaîne d’approvisionnement. Créé à l’origine par de grands acteurs de l’électronique et de l’informatique, ce standard est aujourd’hui géré par le consortium GS1 US.

Contrairement aux normes classiques comme EDIFACT ou X12, RosettaNet ne définit pas seulement des formats de message, mais propose des scénarios métier complets, appelés PIP (Partner Interface Processes), qui décrivent :

• Qui fait quoi (rôles)
• Quand (ordre des échanges)
• Comment (formats XML spécifiques)

Domaines d’application typiques :

• Commande et confirmation d’achat
• Livraison, expédition, réception
• Gestion des stocks et retours
• Facturation et règlement
• Support technique et service après-vente

Structure technique :

• Messages au format RNIF (RosettaNet Implementation Framework)
• Utilise XML, avec schémas (XSD) rigoureux
• Compatible avec les architectures orientées services (SOA) et API modernes

Routing (Routage EDI)

Processus consistant à orienter automatiquement les fichiers EDI vers les bons destinataires ou applications internes, en fonction de règles de gestion, de l’identifiant du partenaire, ou du type de message. Le routage peut être dynamique ou statique.

RVA (Réseau à Valeur Ajoutée)

Infrastructure intermédiaire qui facilite les échanges EDI entre partenaires commerciaux. Le RVA agit comme une plateforme sécurisée assurant la transmission, la traçabilité, l’archivage et parfois la traduction des messages EDI. Il simplifie la gestion des connexions multiples (multipoint) en jouant un rôle de hub.
Certains acteurs historiques du marché proposent des solutions de RVA avec des services étendus (supervision, alerting, compliance). Synonyme anglais : VAN (Value-Added Network).

S

Segment

Ligne de données dans un message EDI, identifiée par un code (ex : UNH, NAD, LIN). Chaque segment regroupe des éléments de données qui ont un sens logique. Exemple : le segment NAD contient les informations de nom et adresse.

SOA (Architecture Orientée Services)

Ligne de données dans un message EDI, identifiée par un code (ex : UNH, NAD, LIN). Chaque segment regroupe des éléments de données qui ont un sens logique. Exemple : le segment NAD contient les informations de nom et adresse.

SSL (Secure Sockets Layer)

Protocole de sécurité conçu à l’origine pour chiffrer les échanges de données sur Internet, notamment entre un navigateur et un serveur. SSL établit un canal sécurisé via des certificats numériques et des clés de chiffrement.

Dans un contexte EDI, SSL a longtemps été utilisé pour sécuriser des protocoles comme HTTPS, AS2, FTPS, etc.

SSL est aujourd’hui obsolète (versions 2.0 et 3.0) et a été remplacé par TLS, plus moderne et plus sûr.

Syntaxe EDI

Règles qui définissent la manière dont les segments, éléments et séparateurs doivent être structurés dans un message EDI. Exemple : EDIFACT utilise « + » pour séparer les éléments, « : » pour les composants,  » ‘  » pour clôturer un segment.

T

TRADACOMS

Ancien standard EDI britannique utilisé dans la distribution, remplacé progressivement par EDIFACT/EANCOM. Il est encore en usage dans certaines chaînes retail au Royaume-Uni.

Test EDI (ou Qualification)

Phase de validation préalable à la mise en production d’un flux EDI, permettant de vérifier la conformité du mapping, le bon enchaînement des messages et la compatibilité entre partenaires.

TLS (Transport Layer Security)

Évolution sécurisée du protocole SSL, TLS est aujourd’hui le standard de référence pour le chiffrement des données sur Internet.

Il garantit :

• Confidentialité : personne ne peut intercepter le contenu
• Authentification : vérification des identités via certificat
• Intégrité : les données ne sont pas altérées pendant le transfert

TLS est utilisé dans la majorité des protocoles EDI sécurisés :

• HTTPS (AS2, WebEDI)
• FTPS
• OFTP2
• AS4

Types de messages EDI

L’EDI repose sur l’échange structuré de documents appelés messages. Chaque message correspond à une transaction métier (commande, facture, livraison…). Ces messages sont normalisés selon les standards EDIFACT ou ANSI X12, chacun avec ses codes spécifiques. Voici les principaux types de messages utilisés dans les échanges commerciaux :

Message	Code EDIFACT	Code X12	Fonction
Commande	ORDERS	850	Transmet une commande d’achat du client au fournisseur
Confirmation de commande	ORDRSP	855	Confirme, modifie ou refuse la commande initiale
Avis d’expédition	DESADV	856	Indique que les marchandises ont été expédiées
Facture	INVOIC	810	Détaille les produits livrés, les montants et conditions de paiement
Réception de marchandises	RECADV	861	Confirme la réception physique des produits commandés

U

UBL (Universal Business Language)

Standard ouvert basé sur XML, développé par l’OASIS, conçu pour modéliser des documents commerciaux types (factures, bons de commande, bons de livraison…). UBL est souvent utilisé dans les projets de facturation électronique et dans les portails publics ou gouvernementaux (notamment en Europe). Il facilite l’interopérabilité entre systèmes hétérogènes et peut être mappé vers EDIFACT ou X12 selon les besoins

UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business)

Organe de l’ONU chargé d’harmoniser les échanges de données dans le commerce international. Il pilote le développement du standard EDIFACT et d’autres spécifications comme CII (Cross Industry Invoice). Son objectif est de simplifier, normaliser et automatiser les échanges commerciaux transfrontaliers.
C’est l’un des principaux référents internationaux en matière d’EDI et de dématérialisation des documents.

UN/EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport)

Version internationale standardisée des formats EDI maintenue par l’ONU (UN/CEFACT). Utilisée dans la majorité des projets EDI intercontinentaux. Chaque message commence par UNA / UNB / UNH (en-têtes) et se termine par UNT / UNZ.

V

VAN (Value-Added Network)

Fournisseur de services EDI qui agit comme un intermédiaire sécurisé entre partenaires. Il offre des fonctions de transmission, de stockage, de traçabilité, de supervision, et parfois de traduction ou de conformité.

VDA (Verband der Automobilindustrie)

Norme EDI allemande historique utilisée dans l’industrie automobile, notamment en Allemagne. Très structurée, mais progressivement remplacée par ODETTE/EDIFACT + OFTP2.

W

W3C (World Wide Web Consortium)

Organisme qui définit les standards du web, notamment XML, SOAP, XSLT, JSON-LD, et d’autres technologies utilisées dans les solutions EDI modernes ou hybrides. Son influence se fait sentir dans l’évolution de l’EDI vers des architectures API/cloud natives.

WebEDI

Interface web permettant à une entreprise non équipée d’EDI de saisir ou consulter manuellement des documents EDI (commandes, factures, ASN…). Alternative simple et économique pour les petits fournisseurs.

Workflow EDI

Suite d’étapes automatisées définissant le traitement d’un message EDI depuis sa réception jusqu’à son intégration complète dans le système (ERP, WMS, etc.), ou son émission depuis une application métier.

Un workflow EDI peut inclure :

• La vérification du format
• Le routage interne
• Le mapping
• Les accusés de réception
• Les alertes ou relances en cas d’erreur

Un bon workflow assure la fluidité, la traçabilité et la supervision des échanges EDI, avec un minimum d’intervention humaine.

X

X12

Voir ANSI X12.

X400

Ancien protocole de messagerie électronique normalisé par l’UIT-T, largement adopté en Europe avant l’essor d’Internet. Utilisé dans certains environnements EDI institutionnels et gouvernementaux pour la transmission sécurisée de documents. Bien qu’obsolète aujourd’hui, il a joué un rôle historique dans les premières implémentations d’EDI formel.

XML (Extensible Markup Language)

Langage structuré permettant de décrire des données sous forme hiérarchique à l’aide de balises personnalisées. Conçu comme un standard ouvert par le W3C, XML est utilisé dans l’EDI moderne pour échanger des données lisibles par machines et humaines. Il facilite les intégrations hybrides EDI/API et est fréquemment employé dans les plateformes B2B, les échanges logistiques, ou les formats de e-facturation.

Y

YAML

Langage de structuration de données parfois utilisé dans les configurations de plateformes EDI modernes ou pour définir des mappings dynamiques. Bien que non standard EDI, YAML est utilisé côté back-end pour décrire des règles de transformation entre formats.

Y-connection (Topologie en Y)

Modèle d’intégration où un opérateur central (hub) connecte plusieurs fournisseurs ou partenaires via EDI. Typique des grands distributeurs ou prestataires logistiques intégrés. Optimise les flux multi-partenaires en centralisant les routes.

Yield Report

Rapport de productivité (généralement issu d’un fournisseur ou sous-traitant) transmis via EDI dans des secteurs comme l’électronique, l’agriculture ou la santé. Il contient des taux de rendement, des volumes de production ou des données de qualité.

Z

Zero Errors (Zéro erreur EDI)

Objectif de qualité dans les échanges EDI visant un taux de rejet nul, grâce à une validation rigoureuse en amont (mapping, contrôle syntaxique, simulation, tests continus). Les outils modernes d’EDI monitoring visent cet objectif avec alertes proactives.

ZETA (China Auto EDI Technical Association)

Organisation chinoise regroupant constructeurs, équipementiers et intégrateurs pour développer des standards EDI adaptés au marché automobile chinois.

ZETA définit des formats de message spécifiques et collabore avec les autorités pour assurer l’interopérabilité locale, notamment autour des processus de livraison, logistique et gestion fournisseur.

Zip EDI

Pratique consistant à compresser les messages EDI (souvent via ZIP, GZIP, etc.) avant transmission, pour optimiser les temps de transfert, notamment sur des liaisons lentes ou en AS2 avec de gros volumes.

ZUGFeRD

Standard de facturation électronique hybride utilisé en Allemagne. Combine une facture PDF lisible (PDF/A-3) avec une structure XML intégrée. Compatible EDI, ce format est un pont entre EDI pur et e-invoicing réglementaire.