EDIFACT, EANCOM, XML ou JSON : quel format EDI utiliser ?
EDIFACT signifie Electronic Data Interchange for Administration, Commerce and Transport. Ce standard des Nations Unies structure des messages métiers utilisés dans de nombreux échanges B2B. EANCOM est un sous-ensemble sectoriel fondé sur UN/EDIFACT, fréquemment utilisé dans la grande distribution et les échanges de produits.
XML et JSON sont des syntaxes de données qui peuvent être imposées par un partenaire ou un hub d’échange. Ils ne remplacent pas automatiquement les règles métier du message : il faut encore définir les champs obligatoires, les codes, les statuts, les contrôles et les règles de version.
Le bon format est donc celui qui respecte le standard ou le cahier des charges du partenaire tout en restant compatible avec les systèmes internes. Un mapping documenté permet de transformer les références, unités, dates, statuts et identifiants sans perdre le sens de l’échange.
Comment connecter l’EDI à un ERP, un WMS ou un logiciel métier ?
Un ERP, Enterprise Resource Planning, gère généralement les commandes, les articles, les stocks, les factures et les référentiels. Un WMS, Warehouse Management System, porte plutôt les opérations d’entrepôt, les réceptions, les préparations et les expéditions. L’EDI doit relier ces responsabilités sans créer une seconde version contradictoire des données.
L’architecture définit quel système crée et conserve chaque information. L’ERP peut produire ORDERS et INVOIC, tandis que le WMS contribue à DESADV ou RECADV. Un logiciel métier peut ensuite exploiter les statuts, les écarts et les documents sans devenir propriétaire de toutes les données.
L’intégration peut passer par une plateforme EDI, une couche d’intégration, des fichiers structurés ou des API complémentaires. Le choix dépend des interfaces disponibles, du volume, de la criticité et des exigences de chaque partenaire.
EDI, API ou portail fournisseur : quelle solution choisir ?
Une API, Application Programming Interface, est une interface générique permettant à des applications d’échanger directement des données ou de déclencher des actions. L’EDI répond à une intention plus spécialisée : transmettre des documents B2B structurés selon un standard, un protocole et un cahier des charges partenaire.
Un portail fournisseur est une interface utilisée directement par une personne. Il convient lorsqu’un partenaire doit consulter une commande, déposer un document ou confirmer une livraison sans disposer d’une connexion automatisée. EDI et portail fournisseur peuvent donc coexister selon la maturité et le volume de chaque partenaire.
Le bon arbitrage porte sur la fréquence des échanges, le niveau de standardisation, les délais attendus, la capacité informatique du partenaire et la nécessité de conserver une trace structurée du cycle de vie du document.
AS2, AS4 ou SFTP : comment transporter les messages EDI ?
AS2 et AS4 sont des protocoles ou mécanismes de transport B2B, pas des formats de données. Ils encadrent notamment l’authentification, le chiffrement, la signature et les accusés de réception nécessaires à un échange fiable entre partenaires.
SFTP, SSH File Transfer Protocol, peut convenir lorsque le partenaire échange des fichiers déposés dans un espace sécurisé. Il faut alors traiter correctement le nommage, le dépôt, la récupération, les doublons, les fichiers incomplets et la conservation des traces.
Le transport ne suffit pas à garantir la qualité métier. Un message bien transmis peut rester rejeté si une référence, une unité, un identifiant ou une règle de partenaire n’est pas conforme. Les contrôles de contenu et les accusés de réception doivent donc être suivis ensemble.
Comment onboarder un nouveau client ou fournisseur EDI ?
L’onboarding EDI commence par les exigences du partenaire : messages attendus, versions, identifiants, transport, certificats, environnement de test, calendrier et règles de rejet. Ces éléments doivent être comparés aux capacités réelles de l’ERP, du WMS et des applications internes.
Nous définissons ensuite le mapping, les contrôles, les données de test et les responsabilités de correction. Les essais doivent couvrir les cas nominaux mais aussi les quantités partielles, les changements de date, les articles inconnus, les avoirs, les rejets et les nouvelles tentatives.
La mise en production est validée lorsque les messages circulent dans les deux sens attendus, que les statuts sont compréhensibles et que les équipes savent qui intervient lorsqu’un échange ne passe pas.
Comment superviser les flux EDI et traiter les rejets ?
La supervision EDI doit donner une lecture par flux, partenaire, message et statut. Elle doit permettre de savoir si un document a été généré, transporté, reçu, accepté, rejeté ou placé en attente de correction.
Un rejet peut être technique, par exemple un certificat expiré ou un fichier illisible, ou métier, par exemple une référence inconnue, un montant incohérent ou une donnée obligatoire absente. Le traitement doit conserver le message, la réponse du partenaire, le motif et l’action réalisée.
Les alertes doivent être liées à une action : corriger la donnée, renouveler un certificat, relancer un traitement, demander une validation ou escalader le problème au partenaire. Une liste de logs sans responsable ni procédure ne suffit pas pour exploiter un flux critique.
Comment éviter les doublons et garantir l’intégrité des échanges EDI ?
Un même message peut être reçu plusieurs fois après un délai réseau, une nouvelle tentative ou une reprise manuelle. L’intégration doit utiliser des identifiants de message, numéros de document et références de corrélation pour reconnaître ce qui a déjà été traité.
L’idempotence, c’est-à-dire la capacité à rejouer une opération sans créer un doublon, doit être prévue sur les étapes sensibles. Les contrôles portent aussi sur les totaux, les lignes, les unités, les montants, les relations entre commande et livraison et les statuts du cycle de vie.
La traçabilité complète relie enfin le document source, le message transformé, la réponse du partenaire et l’écriture créée dans l’ERP ou le logiciel métier. Cela facilite les audits, les corrections et la recherche de la cause lorsqu’un écart apparaît.
Facturation électronique 2026 : quel impact sur les flux EDI ?
Depuis le 1er septembre 2026, toutes les entreprises françaises concernées doivent pouvoir recevoir des factures électroniques. À cette même date, les grandes entreprises et les entreprises de taille intermédiaire doivent émettre leurs factures électroniquement et transmettre les données d’e-reporting prévues par la réforme. Les PME et microentreprises devront émettre électroniquement à partir du 1er septembre 2027.
Une intégration EDI ne remplace pas une plateforme agréée dans le cadre de la facturation électronique française. Elle peut alimenter ou compléter les systèmes de gestion, préparer les données nécessaires et maintenir les flux avec les partenaires, mais le circuit réglementaire doit rester relié à l’acteur habilité correspondant au dispositif.
La DGFiP est devenue l’Autorité Peppol pour la France le 8 juillet 2025. Les référentiels français à prendre en compte comprennent notamment XP Z12-012 pour les formats et profils de factures et statuts, XP Z12-013 pour les API d’interfaçage avec les plateformes agréées et XP Z12-014 pour les cas d’usage B2B. Koragence n’est pas présentée ici comme plateforme agréée, partenaire fiscal DGFiP ou prestataire Peppol certifié.
Comment sécuriser des échanges EDI ?
La sécurité concerne le transport, les certificats, les clés, les accès techniques et les données contenues dans les messages. Les comptes d’intégration doivent disposer uniquement des droits nécessaires et les secrets doivent pouvoir être renouvelés sans interrompre tout le dispositif.
Les échanges peuvent s’appuyer sur le chiffrement, la signature, l’authentification des partenaires, des réseaux restreints, la séparation des environnements et une journalisation adaptée. Les copies de fichiers et les exports intermédiaires doivent également être limités, conservés pendant la durée utile puis supprimés selon les règles de l’entreprise.
Le niveau de contrôle dépend des données, du secteur, des partenaires et de la criticité du processus. Une facture, une commande ou un document logistique doit rester traçable sans exposer plus d’informations que nécessaire.
Combien coûte la mise en place d’un projet EDI ?
Le coût dépend du nombre de partenaires, des messages à gérer, des formats, des systèmes connectés, du transport, des règles de mapping, des tests et du niveau de supervision attendu. Un seul flux ORDERS vers un ERP existant ne demande pas le même travail qu’un dispositif couvrant commandes, expéditions, réceptions, factures et plusieurs partenaires.
Le budget doit distinguer le cadrage initial, la construction des mappings, les développements ou paramétrages, les environnements de test, l’onboarding des partenaires et l’exploitation récurrente. Cette séparation évite de confondre le coût ponctuel d’une mise en place avec celui du maintien des flux.
Une première version peut cibler un partenaire et un processus critique, puis s’étendre lorsque les contrôles, les rejets et les responsabilités sont stabilisés. Le bon périmètre est celui qui réduit un risque ou une ressaisie réelle, pas celui qui accumule les formats dès le départ.
Prestataire EDI, plateforme SaaS ou développement interne : que choisir ?
Une plateforme EDI SaaS peut accélérer l’accès à des connecteurs, des formats et des outils de supervision déjà disponibles. Elle est intéressante lorsque les besoins sont proches de son périmètre et que les conditions de rétention, d’hébergement, de support et de réversibilité sont acceptables pour l’entreprise.
Le développement interne donne davantage de contrôle mais transfère aussi la responsabilité des mappings, des protocoles, des certificats, de la supervision, des mises à jour et de l’astreinte éventuelle. Il peut être pertinent lorsque les volumes, les compétences et la criticité justifient cette capacité durable.
Un prestataire EDI peut enfin cadrer l’architecture, reprendre des flux existants et coordonner les partenaires sans obliger l’entreprise à choisir entre une plateforme entièrement standard et une équipe interne complète. Le modèle retenu doit rester documenté et réversible.
Comment Koragence structure une intégration EDI ?
Nous commençons par cartographier les partenaires, messages, systèmes, responsabilités et contraintes de transport. Cette lecture permet de distinguer les flux réellement nécessaires, les données qui font autorité et les points où une API ou un portail fournisseur est plus adapté que l’EDI.
Nous définissons ensuite les mappings, règles de validation, identifiants, scénarios de rejet et tests de bout en bout. Les échanges sont connectés à l’ERP, au WMS ou au logiciel métier sans effacer la responsabilité de chaque système.
Le déploiement suit une chaîne contrôlée : cadrage, mapping, développement ou paramétrage, tests partenaires, pilote, mise en production, supervision et documentation. Les flux peuvent ensuite être enrichis progressivement sans transformer chaque nouveau partenaire en projet isolé.
Onctuo
Good is Merch
Comment connecter l’EDI à un ERP, un WMS ou un logiciel métier ?
Un ERP, Enterprise Resource Planning, gère généralement les commandes, les articles, les stocks, les factures et les référentiels. Un WMS, Warehouse Management System, porte plutôt les opérations d’entrepôt, les réceptions, les préparations et les expéditions. L’EDI doit relier ces responsabilités sans créer une seconde version contradictoire des données.
L’architecture définit quel système crée et conserve chaque information. L’ERP peut produire ORDERS et INVOIC, tandis que le WMS contribue à DESADV ou RECADV. Un logiciel métier peut ensuite exploiter les statuts, les écarts et les documents sans devenir propriétaire de toutes les données.
L’intégration peut passer par une plateforme EDI, une couche d’intégration, des fichiers structurés ou des API complémentaires. Le choix dépend des interfaces disponibles, du volume, de la criticité et des exigences de chaque partenaire.