Formats EDI en logistique : EDIFACT, XML, API et fichiers plats

Pierre BOIREL Publié le 4 juin 2025 Mis à jour le 30 août 2026 8 min de lecture

Comprendre les échanges de données en logistique au travers de l’interfaçage des fichiers

Dans la logistique moderne et de façon générale en Supply Chain, les entreprises ne travaillent plus en silo : transporteurs, fournisseurs, entrepôts, clients, plateformes e-commerce… Tous doivent échanger des informations rapidement et de façon précise. Ces échanges permettent par exemple :

  • de suivre les commandes en temps réel,
  • d’automatiser les expéditions,
  • de fluidifier l’ensemble des flux d’informations constitutifs d’un pilotage efficace de la supply chain

Mais pour que cela fonctionne, encore faut-il parler la même langue d’un système à un autre. Autrement dit, que l’interopérabilité fonctionne entre les différents systèmes et/ou logiciels. Pour cela, des protocoles existent. Ils concernent soit le format des informations (EDIFACT par exemple) et/ou concernent le type de transport des informations (FTP / SFTP pour déposer les fichiers sur des serveurs partagés par exemple).

Le mapping : pierre angulaire de tout échange

Quel que soit le moyen technologique utilisé (fichier, API, nous le détaillerons plus loin dans cet article), le mapping des données est essentiel. Le mapping est le processus qui permet de faire correspondre le format de données d’un système source à celui d’un système cible. C’est l’étape de traduction en quelque sorte.

Exemple concret en logistique :

Un WMS indique une date d’expédition au format AAAA-MM-JJ, alors que le TMS attend JJ/MM/AAAA. Le mapping permet de convertir et d’aligner les formats, champs et valeurs.
Il s’agit donc de parfaitement faire correspondre les données entre deux systèmes informatiques pour que les données « parlent le même langage » de bout en bout.

Sans un bon mapping, les systèmes ne se comprennent pas : une erreur de correspondance peut entraîner un colis mal acheminé, une rupture de stock, ou une mauvaise facturation.
C’est la phase critique de tout projet d’échanges de données. Et même si elle revêt un caractère technique, le succès de cette phase repose nénamoins sur la qualité d’interaction humaine entre les personnes engagées.

A noter par ailleurs qu’aucune technologie ou bon mapping ne peut compenser des données de mauvaise qualité ; un autre facteur critique de tout projet logistique.
Car peu importe la qualité du mapping ou la technologie utilisée, une donnée erronée reste une mauvaise donnée. Et cette non qualité de la DATA peut avoir les même conséquences qu’un mauvais mapping. L’information transmise ne correspondra pas à l’information attendue.

Exemple : un code postal erroné dans une adresse de destination présente dans le WMS transmettra la mauvaise information au TMS même si le mapping est correct.

D’où l’importance d’une gouvernance des données solide (nettoyage, validation, contrôle qualité) en marge du travail de mapping.

Les technologies d’interfaçage de données : tour d’horizon

Il existe plusieurs manières de faire communiquer les systèmes d’information entre eux. Voici les principales :

1. Les fichiers plats

Un fichier plat, c’est un fichier simple comme un fichier Excel, CSV ou texte (.txt) contenant des données strictement organisées en lignes avec des séparateurs de champ. Tout changement de format nécessite des adaptations manuelles. Cette technologie est cependant encore couramment rencontrée dans les systèmes informatiques. Elle a l’avantage d’être simple, robuste cependant rigide.

Exemple d’un fichier contenant les expéditions de la journée :

Commande;Client;Date;Poids
1234;Dupont;01/05/2025;25kg
1235;Martin;01/05/2025;12kg

Avantages :
  • Facile à créer et à lire. Peu coûteux et rapide à mettre en œuvre.
  • Peut être échangé par e-mail ou via FTP.
  • Peu de dépendance technique à des compétences IT pointues
Inconvénients :
  • Pas en temps réel strict même si des routines de lecture des fichiers peut tendre vers une forte réactivité. L’échange de données est, de fait, asynchrone.
  • Risque d’erreur lors de l’échange ou du formatage.
  • Nécessite souvent une étape d’import manuel.

Les formats de fichiers EDI que vous croiserez

Le format, c’est la grammaire du message : l’ordre des champs, leur longueur, la façon dont on sépare une ligne de commande de la suivante. Le protocole de transport, lui, décide seulement de la manière dont le fichier voyage. Confondre les deux fait perdre du temps en réunion de cadrage, parce qu’on croit négocier une seule chose là où il y en a deux.

Format Où on le rencontre Ce qu’il implique pour vous
EDIFACT Norme des Nations unies, dominante en Europe : grande distribution, industrie, transport Le plus structuré et le plus contraignant. Vos partenaires imposeront souvent leur sous-ensemble de la norme, ce qui explique qu’un même message diffère d’un donneur d’ordre à l’autre
ANSI X12 Équivalent nord-américain d’EDIFACT À prévoir dès que vous travaillez avec des partenaires aux États-Unis ou au Canada, il ne se substitue pas à EDIFACT
GS1 XML Déclinaison XML des standards GS1, en croissance dans la distribution Plus lisible et plus souple qu’EDIFACT, plus verbeux aussi, donc des fichiers plus lourds
XML propriétaire Éditeurs de WMS, TMS et ERP, échanges entre logiciels d’un même groupe Souple, mais chaque partenaire a le sien : c’est là que la charge de mapping explose
JSON Format natif des API modernes, en particulier des solutions hébergées Léger et pratique côté développement, il suppose en revanche une intégration par API et pas un simple dépôt de fichier
CSV et fichiers plats Partout, encore aujourd’hui, notamment entre PME Le plus accessible et le plus fragile : un séparateur qui change ou une colonne déplacée casse l’échange sans prévenir
IDoc Format interne de SAP Vous le rencontrerez si un partenaire est sous SAP, il se convertit vers EDIFACT ou XML

Un point pratique qui revient dans tous les projets : le format n’est presque jamais votre choix. Il est imposé par le partenaire le plus gros de la relation. La vraie question n’est donc pas « lequel prendre », mais « combien de formats différents vais-je devoir gérer, et qui les maintient ».

Le transport du fichier, l’autre moitié du sujet

Une fois le message écrit dans le bon format, il faut l’acheminer. Les protocoles employés en logistique sont peu nombreux et leurs différences se résument à la sécurité et à la preuve de remise.

  • SFTP, le dépôt de fichier sur un serveur, chiffré. Le plus répandu, le plus simple à mettre en place, sans accusé de réception applicatif : vous savez que le fichier est déposé, pas qu’il a été traité.
  • AS2, transport par HTTP avec signature et accusé de réception. Il apporte la preuve de remise que SFTP n’a pas, ce qui explique qu’il soit exigé par la grande distribution.
  • OFTP2, hérité du secteur automobile, encore imposé par les constructeurs et leurs rangs de fournisseurs.
  • API en HTTPS, qui fusionne transport et échange dans le même appel. Pas de fichier, pas de dépôt, une réponse immédiate.
  • La messagerie électronique reste utilisée entre petites structures. Elle fonctionne, elle ne trace rien, et elle rend tout incident indémontrable.

Ce que le dirigeant doit trancher, et ce qu’il peut déléguer

Le choix du format et du protocole se délègue : c’est une décision technique, contrainte par vos partenaires. Trois questions restent en revanche des décisions de direction, parce qu’elles engagent de l’argent et de la dépendance.

Faites-vous vous-même, ou passez-vous par un opérateur EDI ? Un prestataire spécialisé prend en charge les conversions et la surveillance des flux contre un abonnement souvent indexé sur le volume de messages. Vous y gagnez de ne pas avoir la compétence en interne, vous y perdez en autonomie et en visibilité sur ce qui se passe quand un flux tombe. Sur un petit nombre de partenaires stables, l’internalisation se défend ; au-delà, l’opérateur devient difficile à battre.

Qui surveille les flux, et selon quelle procédure ? Un échange EDI tombe en silence. Le fichier n’arrive pas, personne ne s’en aperçoit, et on découvre le problème quand un client réclame sa livraison. La question à poser au projet n’est pas « comment ça marche » mais « comment je suis prévenu quand ça ne marche plus, et sous quel délai ».

À qui appartient le mapping ? Les règles de correspondance entre vos champs et ceux de vos partenaires représentent, au bout de quelques années, un capital réel. Vérifiez qu’elles vous sont restituables dans un format exploitable si vous changez de prestataire ou de logiciel. Sans cette clause, changer d’opérateur EDI revient à tout refaire.

Les messages EDIFACT eux-mêmes, DESADV en tête, sont détaillés sur notre page consacrée à l’EDI en supply chain.

2. Les API (Application Programming Interface)

Une API est une interface (sorte de portail ouvert à l’échange avec un système tiers) qui permet à deux systèmes de s’interroger en temps réel via un système de requêtage installé. Par exemple : un TMS (Transport Management System) qui demande au WMS (Warehouse Management System) les détails d’une date d’expédition.

Dans ce terme, nous pouvons distinguer 2 notions différentes :

API REST (REpresentational State Transfer) : plus légère, plus rapide, elle utilise généralement le format JSON. Très utilisée dans les applications web et mobiles. Un format typiquement consacré par les outils métiers développés en SAAS.

API SOAP (Simple Object Access Protocol) : plus robuste, elle est souvent utilisée dans les contextes nécessitant une forte sécurité ou des transactions complexes, au prix d’une structure initiale plus lourde en XML.

Analogie Blogistics ? REST, c’est un SMS rapide ; SOAP, c’est une lettre recommandée avec accusé de réception.

Avantages des API :
  • C’est du temps réel. Les données sont synchrones entre les systèmes
  • Format propice à une automatisation potentiellement massive
Inconvénients des API :
  • Cela requiert la mobilisation de compétences spécifiques pour la mise en oeuvre (développement, tests, maintenance)
  • Le coût initial est plus conséquent et souvent plus long que l’autre technologie des fichiers plats
  • L’adaptation nécessite le recours à des experts techniques. L’autonomie est donc moins grande si l’entreprise ne dispose pas de ces compétences facilement.
En substance

Dans un monde logistique de plus en plus interconnecté, choisir la bonne solution d’échange de données n’est donc pas qu’une affaire de technologie. Même s’il existe plusieurs options techniques pouvant correspondre à différents usages.

Il demeure en effet central de mobiliser les énergies sur le mapping et la qualité des données qui sont les 2 piliers de tout projet EDI… quel que soit le choix technologique finalement retenu par l’entreprise.

 

Par Pierre

Pierre BOIREL

Expert logistique et supply chain. Fondateur de SCOD, principal rédacteur de blogistics.fr. Formé à l'ESSCA en master Logistique & Achats, Pierre pratique la supply chain depuis plus de vingt ans : technicien, chef d'équipe, responsable, directeur, puis fondateur de SCOD en 2018. Il a mené les projets métier et le management d'équipe avant de les conseiller.

Tous ses articles

Partager LinkedIn X E-mail Mots-clés : Cybersécurité · digitalisation · EDI · ETL · flux · métier · processus