La plupart des marques de vente en gros découvrent l’EDI de la même manière : un acheteur d’un grand revendeur envoie un e-mail annonçant qu’à partir de la saison prochaine, les commandes seront transmises par EDI et que les fournisseurs devront être conformes. Il y a une date limite, un PDF de spécifications techniques et le nom d’un prestataire dont vous n’avez jamais entendu parler.

Cet e-mail mérite d’être pris au sérieux, mais aussi qu’on y réponde avec discernement. L’EDI est réellement obligatoire pour certaines relations commerciales et totalement superflu pour d’autres, et l’écart se chiffre en milliers d’euros par an, sans compter des mois de mise en œuvre. Les fournisseurs se trompent dans les deux sens : soit ils considèrent l’exigence d’un seul revendeur comme une raison de refondre toute leur réception des commandes, soit ils l’ignorent jusqu’à ce que le compte soit menacé.

Ce guide explique ce qu’est réellement l’EDI, quels documents vous devrez prendre en charge, ce qu’implique concrètement la mise en place, en quoi l’EDI diffère d’une intégration API, et comment déterminer laquelle des deux solutions convient à votre entreprise.

Qu’est-ce que l’EDI ?

EDI signifie Electronic Data Interchange (échange de données informatisé). Il s’agit d’une méthode standardisée permettant à deux entreprises d’échanger des documents commerciaux (bons de commande, confirmations de commande, avis d’expédition, factures) d’ordinateur à ordinateur, dans un format fixe, sans que personne n’ait à saisir quoi que ce soit ni à envoyer le moindre e-mail.

Le concept est antérieur à Internet. Les grands détaillants et les fabricants devaient faire transiter des millions de commandes entre leurs ordinateurs centraux ; le secteur s’est donc accordé sur des formats de documents stricts : chaque champ à une position définie, chaque type de document identifié par un numéro. Le système du fournisseur génère un fichier dans ce format exact, l’envoie via un canal sécurisé, et le système du revendeur le lit sans aucune intervention humaine.

C’est pourquoi l’EDI domine encore dans l’alimentaire, la pharmacie, le bricolage, l’automobile et les grandes surfaces. Ce n’est pas une technologie moderne, et personne ne la concevrait ainsi aujourd’hui, mais elle est fiable, auditée et déjà intégrée aux systèmes de toutes les grandes chaînes de distribution. Lorsqu’un acheteur vous dit « nous avons besoin que vous passiez à l’EDI », cela signifie que son ERP n’acceptera les commandes que dans ce format et que la saisie manuelle des commandes de son côté n’est pas envisageable.

Les documents EDI que l’on vous demandera réellement

Deux normes sont couramment utilisées. ANSI X12 est principalement utilisée en Amérique du Nord et désigne les documents par un numéro. UN/EDIFACT est la norme internationale, répandue dans toute l’Europe, et les désigne par un nom. Les revendeurs vous indiqueront celle qu’ils utilisent, et vous n’aurez généralement besoin que de quatre ou cinq types de documents.

L’EDI 850 n’est rien d’autre qu’un bon de commande sous une forme lisible par une machine : mêmes informations, même valeur commerciale, seul l’habillage change. Si vous comprenez déjà comment un bon de commande circule dans votre entreprise, vous comprenez déjà l’essentiel de ce que fait l’EDI.

C’est généralement l’avis d’expédition qui prend les fournisseurs au dépourvu. Il vous oblige à décrire précisément comment l’envoi est conditionné : quels articles se trouvent dans quel carton, sur quelle palette, chacun étiqueté avec un serial shipping container code (SSCC). Il s’agit d’un changement de processus en entrepôt, pas seulement d’un format de données, et c’est la raison la plus fréquente pour laquelle les projets EDI prennent plus de temps que prévu.

Comment fonctionne l’EDI en pratique

Trois éléments doivent être en place avant que la moindre commande puisse circuler.

Une connexion. Les documents transitent par un canal sécurisé, généralement AS2, SFTP ou un réseau à valeur ajoutée (VAN, Value Added Network) qui fait office de bureau de poste géré entre partenaires commerciaux. La plupart des fournisseurs y accèdent par l’intermédiaire d’un prestataire EDI plutôt que de le mettre en place eux-mêmes.

Un mapping. La façon dont votre système représente une commande et celle dont le revendeur la représente doivent être traduites l’une dans l’autre, champ par champ. C’est là que se situe le vrai travail, et il est propre à chaque partenaire commercial : chaque revendeur applique la norme de façon légèrement différente, avec ses propres champs obligatoires, ses propres codes, ses propres particularités. Être « prêt pour l’EDI » avec un revendeur ne vous rend pas prêt pour le suivant.

Une certification. Avant la mise en production, vous envoyez des documents de test que l’équipe du revendeur vérifie au regard de ses spécifications. Prévoyez plusieurs allers-retours. Les grands revendeurs gèrent des programmes de conformité formels, et certains appliquent des pénalités lorsque les documents sont en retard, mal formés ou ne correspondent pas à la livraison physique.

Les délais varient fortement selon le revendeur et le prestataire, mais une première connexion EDI prend couramment de six à douze semaines entre le lancement et la mise en production, les partenaires suivants étant plus rapides une fois votre côté en place. Les coûts combinent généralement des frais de mise en place par partenaire, un abonnement mensuel à la plateforme et parfois une facturation par document ou par kilocaractère. Demandez un devis complet incluant le deuxième et le troisième partenaire commercial : le premier est rarement le plus coûteux.

EDI ou API : quelle est la différence ?

Les deux font circuler des données entre systèmes sans saisie humaine. La différence tient à leur âge, à leur forme et au public pour lequel ils ont été conçus.

La distinction concrète : l’EDI est le moyen par lequel un grand client vous impose un format, tandis qu’une API vous permet de connecter vos propres systèmes entre eux. Ils répondent à des problèmes différents et, pour la plupart des marques de vente en gros, la réponse honnête est que vous aurez besoin d’un peu des deux : l’EDI pour les deux ou trois comptes qui l’exigent, et l’intégration API pour le reste de votre stack technologique B2B.

Quand l’EDI devient réellement nécessaire

La mise en place de l’EDI se justifie lorsqu’au moins une de ces conditions est remplie :

• Un revendeur en a fait une condition de la relation commerciale, et ce compte pèse significativement dans votre chiffre d’affaires

• Vous vendez dans l’alimentaire, la pharmacie, le bricolage ou une autre catégorie où les programmes de conformité et les pénalités sont la norme

• Vous approvisionnez un distributeur ou une centrale d’achat qui regroupe les commandes de nombreux magasins

• Votre volume de commandes avec un partenaire est suffisamment élevé pour que le traitement manuel représente un véritable coût, et non un simple désagrément

Le critère est simple : l’EDI se justifie par une relation commerciale précise, et non par une envie générale d’automatiser davantage. Si vous ne pouvez pas nommer le partenaire commercial qui l’exige, vous n’en avez probablement pas encore besoin.

Quand une API ou un portail B2B est la meilleure réponse

De nombreux fournisseurs lancent un projet EDI alors que leur vrai problème se situe au niveau de la réception des commandes : des commandes qui arrivent par e-mail, en PDF, par téléphone et sous forme de tableur, envoyées par une longue traîne de revendeurs indépendants qui n’enverront jamais le moindre document EDI de leur vie.

L’EDI n’y change rien. Ces acheteurs ont besoin d’un endroit où commander, pas d’une norme documentaire. Un portail B2B à vos couleurs donne à chaque revendeur un accès personnel avec ses propres prix, son assortiment et ses stocks, et la commande arrive structurée parce qu’elle a été passée de manière structurée : c’est le même résultat que celui de l’EDI, obtenu par l’autre bout. Pour les commandes qui arrivent encore par e-mail ou en pièce jointe, la conversion des commandes par IA les transforme en commandes structurées, sans ressaisie manuelle.

Si ce qui vous pèse, ce sont les tableurs et les copier-coller plutôt que l’exigence d’un revendeur, un portail associé à une API vous mènera au but plus rapidement et à moindre coût que l’EDI, tout en améliorant l’expérience d’achat, et pas seulement le format des données.

Le vrai frein, ce sont vos données produit

Les projets EDI butent rarement sur la technologie. Ils butent sur les données produit, car l’EDI ne tolère aucune approximation sur les identifiants, ce que l’e-mail n’a jamais exigé.

Chaque produit doit disposer d’un code-barres GTIN ou EAN stable, identique à celui enregistré dans le système du revendeur. Vos SKU doivent être cohérents et uniques pour chaque variante. Les conditionnements, les quantités par carton et les unités de mesure doivent être exacts et identiques des deux côtés. Les sites doivent disposer de codes GLN. Si l’un de ces éléments est approximatif, les commandes seront rejetées et les factures ne pourront pas être rapprochées ; or, dans un régime de pénalités, cela coûte de l’argent.

Il faut y voir une bonne nouvelle. Nettoyer vos données produit est rentable, que vous alliez de l’avant avec l’EDI ou non : cela améliore votre catalogue, votre gestion des commandes et chacun de vos canaux de vente. C’est la seule partie d’un projet EDI qui n’est jamais perdue.

Comment l’EDI, les API et un portail B2B s’articulent

Ces trois solutions ne sont pas concurrentes. Dans une organisation de vente en gros saine, chacune couvre un segment de clientèle différent, et un système unique, en arrière-plan, centralise les produits, les prix, les stocks et les commandes.

L’EDI gère la poignée de grands comptes qui l’exigent. Votre portail B2B gère la longue traîne d’indépendants qui commandent en autonomie. Votre équipe commerciale gère les commandes de showroom et de salons professionnels via une application de vente. Les commandes reçues par e-mail et en PDF sont converties automatiquement. Les quatre aboutissent dans le même flux de commandes et se synchronisent avec votre ERP grâce à l’intégration API : c’est exactement à cela que ressemble une stratégie de vente B2B multicanale bien construite.

L’écueil consiste à gérer chaque canal comme un îlot isolé, avec une liste de produits distincte et un tableur de prix distinct pour chaque circuit de vente. C’est là que le travail manuel refait surface, quelle que soit la part techniquement automatisée.

La place d’Orderchamp Cloud

Orderchamp Cloud n’est pas un prestataire EDI : si un revendeur exige l’EDI, vous travaillerez toujours avec un spécialiste EDI ou votre partenaire ERP pour cette connexion. Le rôle d’Orderchamp Cloud est de faire en sorte que l’EDI n’ait à couvrir que les comptes qui l’exigent réellement.

Le B2B Portal offre à tous les autres revendeurs un espace de commande en libre-service, avec leurs propres prix et leur propre assortiment. La Sales App enregistre numériquement les commandes passées en showroom et sur les salons professionnels. AI Order Convert transforme les commandes reçues par e-mail et en PDF en commandes structurées. Enfin, les intégrations avec votre ERP, votre PIM et votre WMS assurent la synchronisation des produits, des stocks et des commandes sur l’ensemble de ces canaux, y compris les données produit dont dépend votre connexion EDI. Découvrez comment huit marques ont restructuré leur réception des commandes, ou apprenez-en davantage sur ce que couvre une solution e-commerce B2B complète.

Vous souhaitez réduire la part de vos commandes qui doit passer par l’EDI ? Découvrez Orderchamp Cloud ou réservez une démo.

Questions fréquentes

Que signifie EDI ?

Qu’est-ce qu’un EDI 850 ?

L’EDI est-il encore utilisé en 2026 ?

Les petites marques de vente en gros ont-elles besoin de l’EDI ?

Quelle est la différence entre l’EDI et une API ?