Accueil / Guide EDI / Guide EDI, liste de contrôle

Que contient un guide EDI, et comment le vérifier ?

Un guide EDI décrit les messages qu'attend votre partenaire, dans quel format, avec quelles mentions obligatoires et par quel protocole. En anglais, on parle de Message Implementation Guide (MIG), en français aussi de guide d'implémentation ou de cahier des charges EDI. Le lire attentivement avant le début du projet évite la plupart des questions et des boucles de test. La liste de contrôle ci-dessous aide à ne rien oublier.

Mise à jour 18 octobre 2026 · fokus it solutions, Jens Musleh

Ce qu'est un guide d'implémentation

Les normes comme EDIFACT sont très larges. Une commande (ORDERS) connaît des centaines d'informations possibles, dont la plupart ne servent à aucune entreprise en particulier. Les organisations professionnelles restreignent donc la norme dans des sous-ensembles (subsets). EANCOM, par exemple, est le sous-ensemble de GS1 pour la distribution ; GS1 le décrit comme une partie d'UN/EDIFACT qui ne contient que les éléments nécessaires.

Le guide EDI de votre partenaire va encore un cran plus loin. Il fixe les segments qu'il lit réellement chez lui, les codes qu'il attend et la manière dont il signale les erreurs. Deux distributeurs qui envoient tous deux des commandes EANCOM peuvent différer nettement dans le détail. C'est pourquoi c'est toujours le guide du partenaire qui s'applique, pas la norme générale. Plus d'informations sur la norme elle-même dans EDIFACT expliqué.

Un guide EDI typique contient :

  • une vue d'ensemble des types de messages et du circuit, souvent sous forme de schéma
  • pour chaque message, une liste des segments avec leur statut (obligatoire, facultatif, conditionnel)
  • pour chaque segment, les qualifiants et codes autorisés
  • des messages d'exemple
  • des informations sur les identifiants, le protocole de transmission, les tests et les interlocuteurs

Liste de contrôle en 20 points pour votre guide EDI

Parcourez le guide avec cette liste et notez pour chaque point la page où figure la réponse. Ce que vous ne trouvez pas, demandez-le au partenaire en une seule fois.

  1. Types de messages : quels messages circulent dans quel sens ? Par exemple commande (ORDERS) en entrée, avis d'expédition (DESADV) et facture (INVOIC) en sortie. Un aperçu figure dans la page Types de messages.
  2. Standard et version : EDIFACT, EANCOM, VDA, un format Global selon une recommandation VDA ou un XML propre ? Pour EDIFACT, aussi le répertoire, par exemple D.96A ou D.01B.
  3. Sous-ensemble et version du guide : quel sous-ensemble s'applique, et de quelle version du guide disposez-vous ? Les guides sont révisés ; travaillez avec la version actuelle.
  4. Syntaxe et jeu de caractères : quel identifiant de syntaxe figure dans l'en-tête (par exemple UNOC), quels séparateurs, et un segment UNA est-il prévu ?
  5. Segments obligatoires : repérez tous les segments et éléments de données au statut obligatoire. S'il en manque un, le système du partenaire rejette souvent le message.
  6. Informations conditionnelles : certaines informations ne sont obligatoires que sous condition, par exemple un numéro de lot seulement pour certains articles. Notez la condition.
  7. Qualifiants et listes de codes : quels codes le partenaire attend-il, par exemple pour les types de date, les rôles des intervenants ou les unités de mesure ? N'utilisez que les valeurs citées dans le guide.
  8. Identifiants des intervenants : vous et le partenaire êtes identifiés par des numéros, souvent GLN, identifiant Odette ou numéro de fournisseur. Détails dans GLN et autres identifiants.
  9. Références articles : le partenaire travaille-t-il avec le GTIN, avec sa propre référence ou avec la vôtre ? Souvent, deux d'entre elles sont exigées en même temps.
  10. Protocole de transmission : AS2, OFTP2, SFTP ou un réseau ? Voir Protocoles de transmission.
  11. Paramètres de connexion et certificats : identifiant AS2, identifiant Odette, adresses, ports, chiffrement, signature, échange et durée de validité des certificats.
  12. Accusés de réception : des accusés techniques sont-ils attendus, par exemple le MDN en AS2 ou l'EERP en OFTP2 ?
  13. Contrôle syntaxique (CONTRL) : le partenaire exige-t-il un message CONTRL ? Il confirme ou rejette un interchange au niveau syntaxique. Il est demandé via un champ de l'en-tête UNB.
  14. Retour applicatif (APERAK) : le partenaire envoie-t-il des APERAK en cas d'erreur de traitement, et devez-vous en envoyer vous-même ? APERAK signale des erreurs de l'application, pas de la transmission.
  15. Plages de numérotation : comment les numéros de document, les références et le numéro de contrôle de l'en-tête doivent-ils être construits ? Peuvent-ils se répéter ?
  16. Liens entre messages : quelle référence relie l'avis d'expédition et la facture à la commande, par exemple le numéro de commande et le numéro de ligne ?
  17. Étiquettes et SSCC : chaque palette ou chaque colis doit-il porter un SSCC, et l'étiquette doit-elle correspondre à l'avis d'expédition ? GS1 décrit le SSCC comme un numéro unique au monde pour les unités logistiques.
  18. Données de référence : lieux de livraison, points de déchargement, correspondances d'articles et prix sont souvent à convenir à l'avance.
  19. Déroulement des tests et délais : combien de cycles de test, avec quelles données, dans quel environnement ? Pour quand la production doit-elle démarrer ?
  20. Interlocuteurs et incidents : qui est responsable sur le plan métier et technique, et quelle est la procédure en cas de panne ou de message erroné ?

Un court exemple

Voici le début d'une commande au format EANCOM qu'un distributeur envoie à son fournisseur. Les GLN sont des numéros d'exemple fictifs :

UNB+UNOC:3+9520000000028:14+9520000000011:14+261016:0930+00042++++1'
UNH+1+ORDERS:D:96A:UN:EAN008'
NAD+BY+9520000000028::9'
NAD+SU+9520000000011::9'

L'en-tête UNB contient l'émetteur, le destinataire, la date, l'heure et un numéro de contrôle. Le 1 à la fin du segment UNB demande un accusé de réception. Dans les segments NAD, les qualifiants BY (acheteur) et SU (fournisseur) associent chaque GLN à un rôle. Ce sont précisément ces détails que règle le guide EDI.

Les pièges classiques

  • Version périmée. Le partenaire a révisé son guide, vous travaillez avec un ancien PDF.
  • L'exemple pris pour la règle. Les messages d'exemple montrent un cas, pas tous. Ce qui manque dans l'exemple peut quand même être obligatoire.
  • Références inversées. Votre propre référence article atterrit dans le champ prévu pour celle du client, ou l'inverse.
  • Unités de mesure. Votre ERP compte en cartons, le partenaire commande à la pièce. Sans conversion, quantités et prix sont faux.
  • Accusés oubliés. La transmission fonctionne, mais le partenaire attend un CONTRL ou un APERAK et considère leur absence comme une erreur.
  • Étiquette et avis d'expédition discordants. Le SSCC sur la palette ne correspond pas à celui du DESADV, la réception bloque.
  • Données de test issues de la production. De vraies commandes utilisées en test peuvent déclencher de vrais processus chez le partenaire. Clarifiez quel environnement et quels identifiants valent pour les tests.

Comment edi-service.eu aide avec le guide EDI

Lors de l'onboarding d'edi-service.eu, vous déposez précisément ce guide, avec le courrier d'accompagnement et les fichiers d'exemple. Une IA y lit les types de messages, le standard et la version, les identifiants, le protocole de transmission et le déroulement des tests, puis vous présente le résultat pour confirmation. Vous ne corrigez que ce qui est faux ; les points ouverts sont consignés sous forme de questions au lieu d'être devinés. Ce que comprend le prix fixe est expliqué dans les questions fréquentes. Si vous disposez d'un guide EDI et voulez savoir s'il correspond à notre offre, vous pouvez nous envoyer une demande.

Questions fréquentes

Qu'est-ce qu'un guide EDI ?

Un guide EDI est la spécification technique de votre partenaire pour l'échange de données informatisé. Il fixe les types de messages, le format, les mentions obligatoires, les codes, les identifiants et le protocole de transmission. On parle aussi de guide d'implémentation, de Message Implementation Guide ou de spécification EDI.

Où obtenir le guide EDI de mon client ?

Demandez-le à votre interlocuteur achats ou EDI chez le client. Les grandes entreprises le mettent souvent à disposition dans un portail fournisseurs ou l'envoient avec la demande de connexion EDI. Demandez aussi des fichiers d'exemple et les identifiants de test.

Quelle est la différence entre CONTRL et APERAK ?

CONTRL confirme ou rejette un interchange reçu au niveau de la syntaxe. APERAK indique si l'application du destinataire a pu traiter le message et signale les erreurs métier. Le guide EDI précise lequel des deux votre partenaire utilise.

Combien de temps faut-il pour mettre en œuvre un guide EDI ?

Cela dépend du périmètre, du format et du processus de test du partenaire. Des articles spécialisés citent trois à quatre mois pour la connexion à un grand client dans un projet classique. Le cycle de test avec le partenaire occupe souvent la plus grande partie du temps. Plus d'informations sur l'effort et les coûts dans Combien coûte l'EDI ?.

Sources

Nous contacter · Questions fréquentes · Tous les articles du guide