L'EDI entre distributeurs et fournisseurs : le plus dur n'est pas le fichier

Deux cartons de jus d'orange

Un acheteur commande deux cartons de jus d'orange. Dans son logiciel, un carton contient douze bouteilles : il en attend donc vingt-quatre. Chez le fournisseur, le même carton en contient six. L'entrepôt prépare deux cartons, le camion part avec douze bouteilles, et personne ne s'est trompé. Chacun a appliqué sa propre fiche article.

La facture arrive ensuite. Elle ne correspond ni à la commande ni à ce que le magasin pense avoir reçu, et quelqu'un passe un moment au téléphone pour comprendre. Répétez la scène sur quelques centaines d'articles et quelques dizaines de fournisseurs : c'est le quotidien d'un service achats qui travaille sans référentiel commun.

L'EDI ne règle pas ce problème. Il le fait remonter dès le premier fichier, ce qui est une bonne chose si l'on s'y est préparé.

L'EDI, en clair

EDI veut dire échange de données informatisé. Au lieu d'envoyer un bon de commande par fax, par courriel ou en PDF, le logiciel du distributeur envoie un fichier structuré que le logiciel du fournisseur lit directement. Personne ne ressaisit la commande. Chaque information a une place et un code précis, si bien que les deux logiciels la comprennent de la même façon.

Ces règles ont un nom. La grammaire s'appelle UN/EDIFACT et elle est entretenue par une commission des Nations unies. Pour le commerce et la distribution, GS1, l'organisation qui attribue les codes-barres, en a tiré un sous-ensemble appelé EANCOM. GS1 publie aujourd'hui une édition appelée EANCOM 2002, mais beaucoup d'échanges reposent encore sur l'édition précédente, bâtie sur la version D.96A du répertoire EDIFACT, qui date de 1996. Ces messages sont vieux, austères, et ils marchent : c'est pour cela qu'on les utilise toujours.

Quatre mots suffisent pour suivre la suite :

GTIN

Le numéro sous le code-barres, que beaucoup appellent encore « code EAN » ou « gencod ». Il y en a un par niveau d'emballage : la bouteille a le sien, le carton de six a le sien.

PCB

« Par combien » : le nombre d'unités de vente (celles que le client passe en caisse) que contient un carton.

GLN

Un numéro GS1 de treize chiffres qui désigne un lieu ou un service : le siège de l'acheteur, l'entrepôt qui reçoit, le service qui paie les factures.

SSCC

Le numéro de dix-huit chiffres imprimé sur l'étiquette d'une palette.

Trois messages font l'essentiel du travail

Plusieurs types de messages peuvent circuler entre un distributeur et un fournisseur. Trois portent l'essentiel : la commande, l'avis d'expédition et la facture. D'après GS1, quelque 126 000 entreprises utilisaient EANCOM en 2020, et ces trois messages étaient les plus échangés.

La commande (ORDERS)

La commande part du distributeur. Elle dit qui commande, où livrer, quand, et pour chaque ligne quel article, en quelle quantité et à quel prix. Chez le fournisseur, elle entre directement dans le logiciel de gestion. Il n'y a plus de saisie, donc plus de faute de frappe, et une commande envoyée à six heures peut être en préparation à sept.

Voici à quoi ressemble une commande EANCOM, un peu simplifiée. Tous les numéros sont fictifs : ils commencent par 952, un préfixe que GS1 réserve aux exemples.

UNB+UNOC:3+9520000000011:14+9520000000028:14+260406:0600+CDE0001'
UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+CDE0001+9'
DTM+137:202604060600:203'
DTM+2:20260408:102'
NAD+BY+9520000000011::9'
NAD+DP+9520000000035::9'
NAD+SU+9520000000028::9'
LIN+1++9520000000103:EN'
PIA+1+JO1L:SA'
QTY+21:24:PCE'
QTY+59:6'
PRI+AAA:1.15:::1:PCE'
LIN+2++9520000000110:EN'
PIA+1+BIS200:SA'
QTY+21:48:PCE'
QTY+59:12'
PRI+AAA:0.82:::1:PCE'
UNS+S'
UNT+19+1'
UNZ+1+CDE0001'

Le fichier paraît illisible, mais il est très régulier. Remarquez la ligne QTY+59:6 : le PCB voyage dans la commande. GS1 précise qu'il sert à confirmer une valeur convenue à l'avance, pas à la changer. Si le distributeur et le fournisseur n'ont pas le même chiffre, le problème est donc déjà dans le fichier, avant même que le camion parte.

L'avis d'expédition (DESADV)

Quand le camion part, le fournisseur envoie un avis d'expédition. Il rappelle le numéro de la commande et décrit le chargement comme une poupée russe : l'envoi contient des palettes, chaque palette porte un SSCC, chaque palette contient des cartons, chaque carton contient des bouteilles. Il peut aussi indiquer les numéros de lot et les dates limites.

À l'arrivée, l'entrepôt scanne l'étiquette de la palette. Son logiciel sait déjà ce qu'elle contient : les quantités sont préremplies, il ne reste qu'à confirmer ou corriger. Le pointage carton par carton, bon de livraison papier à la main, disparaît.

UNH+1+DESADV:D:96A:UN:EAN005'
BGM+351+EXP0001+9'
DTM+137:202604071600:203'
DTM+2:20260408:102'
RFF+ON:CDE0001'
NAD+SU+9520000000028::9'
NAD+BY+9520000000011::9'
NAD+DP+9520000000035::9'
CPS+1'
CPS+2+1'
PAC+1++201'
PCI+33E'
GIN+BJ+095200000000000011'
LIN+1++9520000000103:EN'
QTY+12:24:PCE'
LIN+2++9520000000110:EN'
QTY+12:48:PCE'
UNT+18+1'

La facture (INVOIC)

La facture EDI reprend les numéros de la commande et de l'avis d'expédition. C'est ce qui permet au logiciel du distributeur de faire seul ce qu'un comptable faisait à la main : comparer ce qui a été commandé, ce qui a été reçu et ce qui est facturé. On appelle cela le rapprochement. Quand les trois concordent, la facture part en paiement sans que personne n'y touche. Quand elles divergent au-delà d'une tolérance fixée à l'avance, la facture est bloquée et quelqu'un doit la regarder.

C'est là que l'EDI fait gagner de l'argent. Une facture qui se rapproche toute seule ne coûte presque rien à traiter. Une facture bloquée coûte un appel, un courriel, parfois un avoir, et un paiement en retard. Les administrations de cinq États membres qui ont mesuré l'effet du passage à la facture électronique ont vu le coût de traitement baisser de plus de moitié.

UNH+1+INVOIC:D:96A:UN:EAN008'
BGM+380+FAC0001+9'
DTM+137:20260408:102'
RFF+ON:CDE0001'
RFF+AAK:EXP0001'
NAD+SE+9520000000028::9'
NAD+BY+9520000000011::9'
NAD+DP+9520000000035::9'
NAD+IV+9520000000011::9'
CUX+2:EUR:4'
LIN+1++9520000000103:EN'
IMD+F++:::JUS ORANGE 1L'
QTY+47:24:PCE'
MOA+203:27.60'
PRI+AAA:1.15:::1:PCE'
TAX+7+VAT+++:::10'
LIN+2++9520000000110:EN'
IMD+F++:::BISCUITS 200G'
QTY+47:48:PCE'
MOA+203:39.36'
PRI+AAA:0.82:::1:PCE'
TAX+7+VAT+++:::10'
UNS+S'
MOA+125:66.96'
MOA+124:6.70'
MOA+128:73.66'
UNT+27+1'

Et la facture électronique de 2026 ?

Les formats EDI de la distribution sont plus anciens que les réformes de la facture électronique. Celles-ci s'appuient sur une norme européenne, l'EN 16931, qui ne décrit pas un fichier mais une liste d'informations : ce qu'une facture doit pouvoir contenir, et ce que chaque information veut dire. Deux syntaxes XML, c'est-à-dire deux manières d'écrire le même contenu dans un fichier, la mettent en forme. UBL est publiée par l'organisme de normalisation OASIS. CII vient de l'UN/CEFACT, la même famille que l'EDIFACT.

Factur-X est un format hybride : un PDF qui se lit comme une facture ordinaire, avec à l'intérieur un fichier XML CII que les logiciels lisent. Il existe en plusieurs niveaux de détail, appelés profils, du plus succinct (MINIMUM) au plus complet (EXTENDED). MINIMUM et BASIC WL n'ont pas de lignes et ne respectent pas la norme ; BASIC est le premier profil qui porte les lignes de la facture et la respecte, EN 16931 en reprend tout le contenu, EXTENDED y ajoute des informations qui en sortent.

Voici la même facture qu'au-dessus, en UBL. Les informations sont les mêmes, rangées autrement : le GTIN est devenu StandardItemIdentification, le GLN de l'entrepôt se trouve dans Delivery.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" …>
  <cbc:CustomizationID>urn:cen.eu:en16931:2017</cbc:CustomizationID>
  <cbc:ID>FAC0001</cbc:ID>
  <cbc:IssueDate>2026-04-08</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cac:OrderReference><cbc:ID>CDE0001</cbc:ID></cac:OrderReference>
  <cac:DespatchDocumentReference><cbc:ID>EXP0001</cbc:ID></cac:DespatchDocumentReference>
  <!-- vendeur et acheteur : nom, adresse, identifiants légaux -->
  <cac:Delivery>
    <cac:DeliveryLocation><cbc:ID schemeID="0088">9520000000035</cbc:ID></cac:DeliveryLocation>
  </cac:Delivery>
  <!-- TVA et totaux : 66.96 hors taxes, 6.70 de TVA, 73.66 à payer -->
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62">24</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">27.60</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Jus d'orange 1 L</cbc:Name>
      <cac:StandardItemIdentification>
        <cbc:ID schemeID="0160">9520000000103</cbc:ID>
      </cac:StandardItemIdentification>
      <!-- catégorie et taux de TVA de la ligne -->
    </cac:Item>
    <cac:Price><cbc:PriceAmount currencyID="EUR">1.15</cbc:PriceAmount></cac:Price>
  </cac:InvoiceLine>
  <!-- deuxième ligne : les biscuits -->
</Invoice>

Le mouvement est européen : depuis avril 2025, le paquet ViDA permet à chaque État membre d'imposer la facture électronique sur son territoire, et elle deviendra la règle pour les échanges entre États membres en 2030. Ce que la réforme de 2026 change pour un distributeur et ses fournisseurs dépend de leur organisation. Une facture EANCOM peut continuer à circuler entre partenaires, et beaucoup de plateformes de facturation savent la convertir, mais les formats de référence de la réforme sont UBL, CII et Factur-X. Une chose ne change pas : une plateforme de facturation vérifie que la facture est complète et conforme. Savoir si le fournisseur facture le bon article au bon prix reste l'affaire des deux entreprises, et de leur référentiel.

Le vrai chantier : le référentiel

On pourrait croire qu'un projet EDI est un projet informatique : choisir un prestataire, ouvrir une connexion, tester des fichiers. Cette partie existe, mais elle est la plus courte et elle est bien outillée. Dans la plupart des projets, le temps part ailleurs : à vérifier article par article que les deux entreprises parlent de la même chose.

Le référentiel, c'est l'ensemble des fiches que chaque entreprise tient dans son logiciel : articles, clients, fournisseurs, lieux de livraison, prix. Le message EDI n'invente aucune donnée, il transporte celles de ces fiches. Une fiche fausse produit une commande fausse, parfaitement conforme à la norme.

Le problème n'a rien de marginal. Une étude sectorielle de 2009, menée avec GS1 et une école de commerce, trouvait des données produit incohérentes entre distributeurs et fournisseurs dans plus de 80 % des cas examinés.

Voici ce qui doit être identique des deux côtés avant le premier message.

Le GTIN de chaque niveau d'emballage

La bouteille et le carton ont chacun leur GTIN. Si le distributeur commande avec celui de la bouteille alors que le fournisseur attend celui du carton, l'article est « inconnu ». Les logiciels gardent souvent plusieurs GTIN par article avec des dates de validité : un changement de code-barres mal daté, et c'est l'ancien qui part. Autre piège courant, le code interne saisi à la place d'un GTIN. Il a parfois le bon nombre de chiffres, mais pas la bonne clé, et aucun partenaire ne peut le retrouver. Le dernier chiffre d'un GTIN se calcule à partir des autres ; GS1 propose un calculateur en ligne, et un contrôle automatique dans le fichier de saisie évite bien des surprises.

Le PCB et les unités

C'est l'une des sources d'écarts les plus fréquentes. Les règles varient d'un fournisseur à l'autre. Un fournisseur peut, par exemple, livrer une quantité ajustée quand le PCB de la commande est plus grand que le sien, et ne pas livrer du tout la ligne quand il est plus petit.

Les produits vendus au poids compliquent encore les choses. Un distributeur peut avoir réglé son PCB sur le poids du colis, 14 kilos, quand le fournisseur compte en pièces, deux par colis. Une commande de 42 kilos devient alors, selon qui la lit, trois colis, six pièces, ou une commande illisible qu'un opérateur corrige ligne par ligne. Même la norme brouille les pistes : dans la commande, le PCB s'écrit QTY+59 ; dans la facture, QTY+52.

Il faut décider ensemble, par article et par niveau d'emballage, quelle est l'unité de commande, l'unité de livraison et l'unité de facturation, et l'écrire dans la fiche. Quand un fournisseur change le contenu d'un carton, les règles de GS1 lui imposent d'ailleurs de donner un nouveau GTIN à ce carton : c'est le signal qu'il faut mettre la fiche à jour des deux côtés.

Les références article

Chaque ligne porte en général deux identifiants, le GTIN et la référence du fournisseur, et le distributeur a son propre code. Ces trois numéros forment une table de correspondance qui bouge : un article change de format, un fournisseur renumérote son catalogue, une référence reste à zéro parce que personne ne l'a remplie. Avant d'envoyer le moindre message, cherchez les références vides ou à zéro et corrigez-les en masse.

Les lieux et les services (GLN)

Une commande porte souvent trois GLN différents : l'acheteur, le lieu de livraison, le service facturé. Il suffit que l'un d'eux soit inconnu chez le partenaire pour que la commande ou la facture soit rejetée à l'entrée du logiciel. Échanger la liste des GLN est la première étape de tout raccordement, avant même de parler d'articles.

Les prix

Un écart de prix entre commande et facture bloque le rapprochement et renvoie la facture au service achats. La cause est rarement une erreur de calcul. Le plus souvent, un tarif a été mis à jour d'un côté et pas de l'autre, ou une promotion est gérée dans un outil à part qui ne rejoint jamais la fiche. Si les prix ont deux sources, ils finiront par diverger.

Les règles de calcul

Arrondir ou tronquer, calculer la TVA ligne par ligne ou sur le total, donner un signe positif ou négatif à un avoir, tolérer un écart de quelques centimes avant de bloquer une facture : ces choix paraissent mineurs. Un profil de facture publié par GS1 prend l'exemple d'un prix de 0,595 qui devient 0,60 si l'on arrondit et 0,59 si l'on tronque. Sur des milliers de lignes, ces centimes font des factures qui ne se rapprochent jamais. Ces règles s'écrivent dans l'accord d'interchange, le document signé par les deux entreprises qui fixe les règles de leurs échanges. Sans cela, chacune a raison dans son propre logiciel.

Comment s'y prendre

Rien de tout cela n'exige d'outil sophistiqué. Ce qui marche, dans l'ordre :

1. Échanger les GLN des deux entreprises et de tous les lieux concernés.
2. Construire la table des articles : GTIN de chaque niveau, référence du fournisseur, code du distributeur, PCB, unités de commande et de facturation, prix et dates de validité. Un tableur qui contrôle la clé des GTIN suffit pour commencer ; beaucoup de plateformes EDI fournissent un fichier de saisie qui fait ce travail.
3. Faire valider cette table par les deux entreprises, et par chacun des services concernés.
4. Écrire l'accord d'interchange : quels messages, quels champs, quelles règles d'arrondi et de tolérance.
5. Tester sur de vrais articles, en incluant les cas difficiles : poids variable, articles gratuits, promotions, lots, articles remplacés.
6. Démarrer sur un seul site, en gardant l'ancien circuit en parallèle quelques semaines, puis généraliser.

Pour les entreprises qui échangent beaucoup de fiches article, GS1 a même construit un réseau dédié à leur synchronisation, le GDSN.

Un projet réussi ne se voit pas

Quand l'EDI fonctionne, il ne se passe rien de remarquable. Les camions sont réceptionnés en quelques minutes et les factures se paient seules. Ce calme ne doit pas grand-chose au fichier. Il doit tout aux semaines passées à aligner, ligne à ligne, ce que deux entreprises appellent un carton de jus d'orange.