# Comment fonctionne l'intégration EDI avec l'ERP ? Pour l'intégration EDI avec l'ERP, trois voies sont courantes : une interface de programmation (API), des tables d'interface dans une base de données ou l'échange de fichiers. Le choix dépend le plus souvent de l'ERP : ce qu'il propose déjà revient presque toujours moins cher que de construire quelque chose de nouveau. Plus importante que la voie technique est souvent la correspondance des données de référence, c'est-à-dire quel numéro d'article, quel client et quelle unité sont désignés de part et d'autre. ## La place de la connexion ERP dans le circuit EDI Une solution EDI a deux faces. Vers l'extérieur, elle dialogue avec le partenaire, dans son format et par son protocole de transmission (voir [Protocoles de transmission](https://edi-service.eu/fr/guide/protocoles-transmission-edi/)). Vers l'intérieur, elle dialogue avec votre ERP. Entre les deux se trouve le mapping, qui traduit une commande EDIFACT dans la structure que comprend votre ERP et, à l'inverse, une facture de l'ERP en INVOIC pour le partenaire. Le partenaire ne voit rien du côté ERP. Pour lui, seul compte que les messages arrivent à temps et complets. Pour vous, c'est le côté ERP qui détermine si les commandes deviennent des commandes clients sans intervention manuelle et si avis d'expédition et factures sont produits automatiquement. Certains prestataires facturent donc la connexion à l'ERP à part ; EDI+EXPERTS, par exemple, renvoie dans sa grille tarifaire à une offre individuelle. ## Trois voies pour l'intégration EDI et ERP ### Par API ou webhook De nombreux ERP récents proposent une interface de programmation via HTTP, souvent une API REST. La solution EDI crée alors une commande directement par un appel, et l'ERP répond immédiatement par un succès ou une erreur. Pour le sens inverse, l'ERP peut déclencher un webhook : lors d'un événement, par exemple « livraison enregistrée », il appelle une adresse du logiciel EDI. La gestion des répétitions est essentielle. Si la connexion tombe après l'envoi, la solution EDI ne sait pas si la commande a été créée. La norme HTTP (RFC 9110) distingue donc les méthodes idempotentes, dont la répétition a le même effet qu'un appel unique. En pratique, chaque commande a besoin d'une clé unique, pour qu'une seconde tentative ne crée pas de commande en double. ### Par tables d'interface (staging en base de données) Beaucoup d'ERP, notamment anciens ou sectoriels, disposent de leurs propres tables d'import. Le logiciel EDI écrit une commande sous forme d'enregistrements dans ces tables, souvent en-tête et lignes séparés, et renseigne un champ de statut. Un programme de l'ERP récupère les enregistrements, les contrôle, crée la commande et écrit le résultat en retour. L'avantage : l'ERP garde la maîtrise de ses règles de contrôle, et le statut de chaque enregistrement est traçable. L'inconvénient : la solution EDI a besoin d'un accès à la base de données, et le programme de récupération de l'ERP doit tourner. N'écrivez jamais directement dans les tables de commandes proprement dites de l'ERP. Vous contourneriez ses contrôles, et une mise à jour de l'ERP pourrait casser la connexion sans que personne ne le remarque. ### Par fichiers Presque tous les ERP savent lire et produire des fichiers, le plus souvent en CSV, XML ou JSON. Le logiciel EDI dépose un fichier dans un répertoire, sur un serveur de fichiers ou via SFTP, et l'ERP l'importe à intervalles réguliers. Dans l'autre sens, l'ERP exporte bons de livraison ou factures sous forme de fichier, que la solution EDI récupère. Les fichiers sont robustes et faciles à vérifier, car on peut les ouvrir et les lire. En revanche, les retours arrivent avec un délai, et les erreurs d'import n'apparaissent souvent que dans le journal de l'ERP. Convenez donc de règles fixes : noms de fichiers uniques, écriture sous un nom temporaire puis renommage, répertoires séparés pour les succès et les erreurs. ### Le cas particulier de l'IDoc Dans les environnements SAP, l'IDoc (Intermediate Document) est répandu. SAP le décrit comme un conteneur pour l'échange de données entre systèmes SAP et systèmes tiers, composé d'un en-tête, de segments de données et d'enregistrements de statut. Un IDoc est donc plutôt un format qu'une voie à part ; selon la configuration, il est transmis sous forme de fichier ou via une interface. ## Les trois voies comparées | | API ou webhook | Tables d'interface | Fichier | |---|---|---|---| | Retour | immédiat | dès que l'ERP a traité l'enregistrement | différé, souvent via un journal | | Recherche d'erreurs | codes de réponse et journaux | statut par enregistrement dans la table | lecture du fichier, répertoire d'erreurs | | Prérequis dans l'ERP | API documentée | tables d'import et programme de récupération | fonction d'import et d'export | | Accès pour le logiciel EDI | réseau et identifiants de l'API | accès à la base, si possible limité à ces tables | répertoire ou compte SFTP | | Éviter les commandes en double | clé unique par opération | clé unique dans la table | noms de fichiers uniques, archivage après import | | Adapté à | ERP modernes, ERP en cloud | ERP disposant déjà de tables d'import | presque tous les ERP, même anciens | ## La correspondance des données de référence, le vrai travail La plupart des erreurs d'intégration EDI et ERP ne viennent pas de la technique, mais de la correspondance des numéros et des unités. - Références articles : le partenaire commande avec sa propre référence ou avec le GTIN, votre ERP connaît votre propre référence. GS1 décrit le GTIN comme le numéro par lequel une entreprise identifie de façon unique ses unités commerciales. Il vous faut une table de correspondance tenue à jour, dans l'ERP ou dans la solution EDI. - Partenaires et lieux de livraison : le partenaire désigne l'acheteur, le lieu de livraison et le destinataire de la facture le plus souvent par GLN. Votre ERP travaille avec des numéros de client et des adresses de livraison. Chaque GLN doit être associé à un enregistrement, sinon la marchandise part au mauvais endroit. Plus d'informations dans [GLN et autres identifiants](https://edi-service.eu/fr/guide/gln-identifiants-edi/). - Unités : le partenaire commande à la pièce, votre ERP gère l'article en cartons de douze. Sans conversion, quantités et prix sont faux. - Prix et conditions : si le prix de la commande diffère de celui de l'ERP, il faut avoir fixé lequel prévaut et qui est prévenu. ## Gestion des erreurs et tests Prévoyez un traitement pour chaque erreur. Une commande avec un numéro d'article inconnu ne doit ni disparaître ni être créée à moitié. Elle va dans une liste d'erreurs avec le fichier d'origine et un message en clair, pour que quelqu'un puisse la corriger et la réinjecter. Qui reçoit quel message doit être fixé avant le démarrage. Testez la connexion d'abord sur une société de test ou un environnement de test de l'ERP. Faites-y passer de vrais exemples tirés du guide EDI du partenaire, y compris les cas désagréables : annulations, livraisons partielles, articles inconnus, messages en double. Ce n'est que lorsque ces cas passent correctement que la connexion a sa place dans la société de production. Les points du guide EDI importants pour cela figurent dans la [liste de contrôle du guide EDI](https://edi-service.eu/fr/guide/guide-edi-liste-de-controle/). ## Ce qu'edi-service.eu propose côté ERP edi-service.eu connecte votre ERP via trois adaptateurs génériques : un adaptateur REST et webhook, des tables d'interface dans une base de données et un adaptateur de fichiers pour CSV, XML ou JSON. Un adaptateur prêt à l'emploi pour un progiciel ERP précis ne fait pas partie du périmètre, pas plus que des adaptations dans l'ERP lui-même. L'IA met en place la correspondance d'abord en mode TEST ; elle ne passe en production qu'après votre validation. Ce que comprend le prix fixe figure sous [Prix](https://edi-service.eu/fr/#preis). Si vous voulez vérifier que votre ERP offre l'une des trois voies, vous pouvez [nous envoyer une demande](https://edi-service.eu/fr/demande/). ## Questions fréquentes ### De quelle interface mon ERP a-t-il besoin pour l'EDI ? Votre ERP doit pouvoir recevoir des commandes et produire des livraisons ou des factures : par une API, des tables d'import ou une interface de fichiers. Presque tous les ERP proposent au moins l'import de fichiers. Les voies disponibles figurent dans la documentation de l'ERP, ou votre intégrateur ERP les connaît. ### L'ERP doit-il lui-même comprendre EDIFACT ? Non. La traduction entre EDIFACT ou VDA et le format de l'ERP est assurée par le logiciel EDI. L'ERP ne voit que sa propre structure, par exemple un fichier CSV ou un appel d'API. ### Qu'est-ce que le staging en base de données ? Le staging en base de données signifie que les messages sont transmis via des tables intermédiaires de la base. La solution EDI y écrit, un programme de l'ERP les lit, les contrôle et les enregistre. Les règles de contrôle de l'ERP restent ainsi en vigueur. ### Comment éviter les commandes en double ? Chaque message a besoin d'une clé unique, par exemple partenaire plus numéro de commande. Le logiciel EDI et l'ERP vérifient avant la création si cette clé existe déjà. Cela protège aussi lorsqu'un partenaire envoie deux fois la même commande. ## Sources - IETF : « RFC 9110, HTTP Semantics », (consulté le 16 octobre 2026) - SAP : « IDocs (SAP Library) », (consulté le 16 octobre 2026) - GS1 : « Global Trade Item Number (GTIN) », (consulté le 16 octobre 2026) - GS1 : « Global Location Number (GLN) », (consulté le 16 octobre 2026) - EDI-Experts Service GmbH : « Preise », (consulté le 16 octobre 2026)