La définition simple de l'EDI
L'échange de données informatisé est l'échange d'ordinateur à ordinateur de documents d'affaires entre deux entreprises, dans un format électronique normalisé. Les mots clés sont normalisé et d'ordinateur à ordinateur. Avant l'EDI, un bon de commande vivait sur papier ou dans un courriel : l'acheteur l'imprimait ou le tapait, un commis chez le fournisseur le lisait et ressaisissait les lignes dans son propre système de commandes, et chaque ressaisie ajoutait du délai et un risque de faute de frappe. Avec l'EDI, le système de l'acheteur génère le bon de commande comme un document électronique structuré, le transmet, et le système du fournisseur le lit et crée la commande client automatiquement. Pas de télécopie, pas de PDF en pièce jointe, pas de saisie de données.
Ce qui fait fonctionner tout cela, c'est que les deux parties s'entendent d'avance sur le format. Un document EDI n'est pas un fichier libre; chaque champ, le numéro de compte de l'acheteur, les identifiants d'articles, les quantités, la date de livraison, occupe une position définie régie par une norme publiée. Cette rigidité est toute la valeur de l'EDI : parce que le format est convenu, un fournisseur en Ontario peut échanger des documents avec un détaillant en Arkansas sans que ni l'un ni l'autre n'ait jamais à regarder le logiciel de l'autre. L'EDI est antérieur au web, et les grandes chaînes d'approvisionnement du détail, de l'épicerie, de l'automobile et de la logistique ont des décennies de processus bâtis dessus, ce qui explique pourquoi il demeure la langue par défaut du commerce B2B à fort volume, même en 2026.
Le fonctionnement réel des documents EDI : 850, 810 et les autres
Les documents EDI s'appellent des jeux de transactions, et chaque document d'affaires courant a un type numéroté. En Amérique du Nord, la norme dominante est ANSI X12, où un bon de commande est un 850, une facture un 810 et un préavis d'expédition un 856. À l'international, la norme EDIFACT de l'ONU joue le même rôle avec des types de messages nommés (ORDERS, INVOIC, DESADV) au lieu de numéros. Les deux normes n'interopèrent pas directement, alors les entreprises qui commercent dans les deux mondes s'appuient généralement sur un logiciel de traduction ou sur un fournisseur qui parle les deux.
Un cycle de commande de détail typique enchaîne plusieurs de ces documents. Le détaillant envoie un bon de commande 850. Le fournisseur répond couramment par un accusé 855 confirmant ce qu'il peut livrer, puis envoie un préavis d'expédition 856 au moment où la marchandise quitte l'entrepôt, pour que le quai de réception du détaillant sache exactement ce qu'il y a dans le camion, et enfin une facture 810. Un petit reçu technique appelé accusé de réception fonctionnel 997 confirme généralement que chaque transmission est arrivée et a été lue correctement. Le transport entre partenaires passait historiquement par des réseaux à valeur ajoutée (VAN), essentiellement des services de boîtes aux lettres sécurisées, tandis que beaucoup de partenaires commerciaux acceptent maintenant aussi des connexions directes par des protocoles comme AS2 ou SFTP. La combinaison exacte de documents varie selon le partenaire commercial, mais le schéma est constant.
| Document X12 | Ce que c'est | Qui l'envoie habituellement |
|---|---|---|
| 850 | Bon de commande | Acheteur (détaillant, distributeur) |
| 855 | Accusé de réception de bon de commande | Fournisseur |
| 856 | Préavis d'expédition (ASN) | Fournisseur, au départ de la marchandise |
| 810 | Facture | Fournisseur |
| 940 / 945 | Ordre d'expédition d'entrepôt / avis d'expédition | Marques travaillant avec des entrepôts 3PL |
| 997 | Accusé de réception fonctionnel (reçu) | L'une ou l'autre partie, automatiquement |
EDI vs ERP vs API : trois choses différentes qu'on confond
Ces trois acronymes voyagent ensemble et se font mélanger constamment, alors voici la séparation nette. Un ERP est votre système de référence interne : le logiciel où vivent vos commandes, votre inventaire, votre comptabilité et vos clients. L'EDI est une norme de communication entre entreprises : le format convenu que deux entreprises distinctes utilisent pour échanger des documents. Une API est un moyen générique pour deux logiciels de se parler en temps réel, et c'est le mécanisme derrière la plupart des intégrations modernes. Demander « EDI ou ERP », c'est un peu comme demander « service postal ou classeur » : l'un transporte des documents entre organisations, l'autre les stocke et les traite à l'intérieur de la vôtre. Ce ne sont pas des solutions de rechange; une entreprise qui commerce par EDI a quand même besoin d'un endroit où ces documents atterrissent, et cet endroit est habituellement l'ERP.
EDI vs API est la comparaison la plus légitime, parce que les deux déplacent des données entre systèmes. L'EDI fonctionne par lots, prend la forme de documents et est normalisé à travers des milliers de partenaires commerciaux; une API est typiquement en temps réel, flexible et propre à celui qui l'a construite. Les grands détaillants conservent l'EDI parce qu'il leur permet d'intégrer n'importe quel fournisseur contre une seule spécification publiée au lieu de bâtir des intégrations API sur mesure avec chaque vendeur. Les plateformes modernes offrent de plus en plus des API en parallèle de l'EDI, et bien des chaînes d'approvisionnement font tourner les deux, mais quand le guide de partenaire commercial d'une grande surface atterrit sur votre bureau, il sera presque toujours rédigé en termes d'EDI.
- ERP : votre système de référence interne pour les commandes, les stocks et la comptabilité.
- EDI : le format de documents normalisé échangé entre entreprises distinctes.
- API : le mécanisme logiciel-à-logiciel en temps réel derrière la plupart des intégrations modernes.
- En pratique : les documents EDI entrent et sortent, et c'est dans l'ERP qu'ils sont traités.
Comment l'EDI s'intègre à un ERP comme Odoo
L'EDI ne vaut son coût que lorsque les documents alimentent directement vos flux de travail. Un 850 traduit que quelqu'un doit encore retaper dans l'écran de commande n'a rien fait économiser. Dans une configuration intégrée, un 850 entrant crée automatiquement une commande client dans l'ERP, avec le bon client, la bonne liste de prix et la bonne adresse de livraison; la confirmation de l'expédition génère le 856 à partir des quantités réellement préparées; et la validation de la facture produit le 810. L'ERP est la source de vérité, et la couche EDI, qu'il s'agisse d'un fournisseur géré, d'un service de traduction ou d'une connexion directe, n'est que de la tuyauterie en périphérie. Dans nos travaux d'intégration avec Odoo, cela se construit typiquement soit par un fournisseur EDI géré qui expose une API à laquelle Odoo peut parler, soit par des connecteurs sur mesure, et le mappage entre la spécification de chaque partenaire commercial et les champs de commande d'Odoo est là où réside l'essentiel du véritable effort de projet.
Le déclencheur le plus fréquent que nous voyons est la conformité au commerce de détail et aux grandes surfaces. Quand un producteur alimentaire de taille moyenne décroche son premier référencement auprès d'une grande bannière d'épicerie, ou qu'une marque grand public reçoit un bon de commande d'une chaîne nationale, l'entente de partenaire commercial impose typiquement l'EDI dès le premier jour : les commandes arrivent en 850, les expéditions doivent être annoncées par un 856 avec étiquetage au niveau du carton, et les factures doivent concorder, sinon le fournisseur s'expose à des pénalités de conformité qui grugent directement la marge. Le même schéma s'applique aux fournisseurs qui travaillent avec de grands distributeurs et aux marques qui expédient via des entrepôts 3PL, où la paire 940/945 garde l'inventaire de l'ERP synchronisé avec le plancher de l'entrepôt. Nous avons couvert l'angle du détail canadien en particulier dans notre guide sur l'intégration EDI Odoo pour le B2B et le commerce de gros canadiens, et notre service d'intégration est l'équipe qui bâtit ces connexions.
Ce que coûte un logiciel EDI, et quand une entreprise en a réellement besoin
La tarification EDI passe beaucoup par des soumissions, mais la structure est connaissable. Les coûts s'empilent typiquement en trois couches : des frais de mise en place ou d'intégration par partenaire commercial (la spécification de chaque détaillant doit être mappée et testée), un abonnement récurrent au fournisseur EDI ou au VAN, souvent gradué selon le volume de documents ou le nombre de partenaires commerciaux, et le travail d'intégration qui relie les documents à votre ERP. Les portails web-EDI entièrement gérés se situent au bas de l'échelle des prix, mais vous laissent retaper les données à la main, ce qui annule tout l'intérêt passé une poignée de commandes; l'EDI intégré coûte plus cher au départ, puis élimine entièrement la main-d'oeuvre par commande. En règle générale, plus vous avez de partenaires commerciaux et plus votre volume de commandes est élevé, plus une configuration intégrée se rentabilise vite.
Quant à savoir si vous en avez besoin du tout : l'EDI est un achat dicté par une exigence, pas une aspiration. Si aucun partenaire commercial ne l'impose et que votre volume de commandes se gère par courriel et saisie au portail, vous pouvez vous en passer sans culpabilité. Les vrais déclencheurs sont un contrat de détaillant ou de distributeur qui exige la conformité EDI, un volume de commandes assez élevé pour que la saisie manuelle produise des erreurs et des pénalités, ou une relation avec un 3PL qui a besoin de messagerie d'entrepôt automatisée. Si l'un de ces cas vous décrit, la prochaine question pratique est ce que coûterait votre configuration précise, et nous avons construit un outil gratuit exactement pour cela : il passe en revue vos partenaires commerciaux, vos types de documents et votre volume, puis produit un portrait de préparation et une estimation de coûts pour une configuration EDI intégrée à Odoo.
Lancer l'estimateur gratuit de préparation et de coûts EDI Odoo →