Intégration ERP : standards EDI, EDIFACT, AS2, SFTP et PEPPOL

Table des matières :

Clarifier les couches : EDI ≠ EDIFACT ≠ AS2/SFTP ≠ PEPPOL

Parler d’« intégration ERP » en citant EDI, EDIFACT, AS2, SFTP et PEPPOL mélange souvent plusieurs couches qui n’ont pas le même rôle. EDI (Electronic Data Interchange) décrit un principe : échanger des documents métiers (commandes, factures, avis d’expédition) entre systèmes sans saisie manuelle. Derrière, il y a une syntaxe (EDIFACT, X12, XML UBL…), un transport (AS2, SFTP, AS4…), et des règles métier (guidelines sectorielles, profils, contraintes de validation).

EDIFACT n’est donc pas un protocole réseau : c’est une grammaire de message. À l’inverse, AS2 et SFTP ne disent rien du contenu métier : ils transportent des fichiers/payloads de manière sécurisée. PEPPOL ajoute encore une couche : un réseau et un framework d’interopérabilité (documents + transport + gouvernance) qui vise la compatibilité multi-acteurs, notamment pour l’e-procurement public/privé en Europe.

Pour éviter les discussions « de sourds » en atelier (IT, commerce, compta, partenaires), une matrice simple aide à cadrer :

Couche	Exemples	Répond à la question…	Ne résout pas…
Métier (processus)	commande, expédition, facture, avoir, catalogue	« Quel document, à quel moment, avec quel statut ? »	la syntaxe et le transport
Syntaxe	EDIFACT, UBL, CSV propriétaire	« Comment le document est structuré ? »	la sécurité réseau, les accusés techniques
Transport	AS2, SFTP, AS4	« Comment ça circule, chiffré et tracé ? »	la cohérence des champs métier
Réseau/gouvernance	PEPPOL	« Comment trouver l’autre et parler “compatible” ? »	les règles internes ERP (numérotation, compta)

Côté PrestaShop (8.1/8.2 et 9.x en 2026, PHP 8.2–8.3 selon stack), le point important est que le cœur n’a pas été conçu comme un hub EDI. Il expose des APIs et des hooks, mais la robustesse EDI (accusés techniques, idempotence, rejouabilité, corrélation, gestion de versions de mapping) doit être construite. Pour cadrer la « source de vérité » et les flux (catalogue, prix, stock, commandes, factures), il est plus sain de partir d’un design de flux explicite que d’empiler des exports/imports opportunistes : voir PrestaShop intégration ERP PIM : définir la source de vérité et les flux et Intégration ERP : choisir API, webhooks, ETL ou iPaaS.

Un mini-scenario typique en Europe (retail B2B) illustre bien les couches :

vous recevez des ORDERS EDIFACT via AS2 d’un grand compte (exigence de MDN signé),
vous envoyez des DESADV EDIFACT via SFTP à un logisticien historique (batch nocturne),
et pour certains clients secteur public, l’ERP envoie des factures via PEPPOL (interop et conformité).
Ce ne sont pas trois projets différents : c’est un même système d’intégration avec trois canaux et des règles d’exploitation distinctes.

EDIFACT : structure, messages clés et pièges de mapping

UN/EDIFACT est officiellement l’acronyme de « United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport » (UN/CEFACT). Concrètement, vous manipulez des messages structurés en segments, avec des séparateurs (par défaut + pour les éléments, : pour les composants, ' pour fin de segment). L’enveloppe standard fait intervenir UNB/UNZ (interchange), UNH/UNT (message) et éventuellement des segments d’accusés (CONTRL).

Deux détails « terrain » qui expliquent beaucoup de bugs d’intégration :

Le fichier peut contenir une ligne UNA (Service String Advice) qui change les séparateurs. Si votre parseur suppose systématiquement +/:/', vous aurez des erreurs intermittentes selon les partenaires.
Les contraintes d’encodage et de jeu de caractères (ASCII/UNOA, UNOB…) sont rarement documentées côté métier, mais déterminantes quand des libellés (articles, adresses) contiennent accents, caractères spéciaux ou longues lignes.

Pour un e-commerce B2B adossé à un ERP, les trois messages EDIFACT qui reviennent le plus sont : ORDERS (commande), INVOIC (facture) et DESADV (avis d’expédition). Selon les secteurs, vous verrez aussi :

ORDRSP (réponse à commande : acceptée/partielle/substitutions),
INVRPT (inventaire/stock),
PRICAT (catalogue/prix),
APERAK ou CONTRL pour des retours techniques/structurels selon les conventions.

Côté PrestaShop, le mapping n’est jamais 1–1 : vous devez trancher sur les règles de conversion (unités, TVA, incoterms, adresses multi-lignes, références article vs références fournisseur). Exemple minimaliste (très incomplet) d’une ligne de commande :

UNH+1+ORDERS:D:96A:UN:EAN008'
BGM+220+PO2026-000123+9'
DTM+137:20260811:102'
NAD+BY+123456789::9'
LIN+1++SKU-ABC123:SA'
QTY+21:2'
PRI+AAA:19.90'
UNT+8+1'

Un point concret de gouvernance : qui “possède” la référence produit ? En B2B, le client attend parfois sa référence interne, alors que votre ERP attend votre SKU. Sans convention claire, vous finissez avec des LIN ambigus et des litiges (« pas le bon produit ») impossibles à diagnostiquer. Une pratique robuste est de décider explicitement :

référence commerciale affichée (PrestaShop),
référence logistique (ERP/WMS),
référence client (si contractuelle),
et d’indiquer quelle référence est utilisée dans quel segment/qualifier (selon guideline).

Le piège classique est de traiter EDIFACT comme un simple export texte. En réalité, la qualité d’intégration se joue sur (1) la validation syntaxique (parsing, séparateurs, jeu de caractères), (2) la validation métier (codes TVA, codes pays, unités), (3) la gestion de versions (96A vs D01B, profils EANCOM, conventions client).

Pour éviter une dette de mapping, gardez une checklist de décisions avant de coder :

Unités : vos quantités PrestaShop (pièces) doivent-elles sortir en PCE, EA, ou unité contractuelle ?
TVA : taux, exemptions, autoliquidation, arrondis (ligne vs total).
Adresses : normalisation (champ address1/address2, lignes multiples), codes pays ISO, téléphone.
Montants : prix HT/TTC, remises, frais de port, écotaxes éventuelles, devise.
Timing : date de commande (validation), date de livraison souhaitée, fuseau horaire (DTM).
Réconciliation : comment rattacher une réponse ORDRSP / un DESADV à une commande PrestaShop ?

Sur PrestaShop, vous avez aussi des décisions structurantes : la commande est-elle créée dans PrestaShop puis envoyée à l’ERP (B2C classique), ou créée dans l’ERP puis injectée dans PrestaShop (cas portail client B2B) ? Ce point impacte les clés de corrélation (référence ERP, id_order, références transporteur) et votre stratégie d’idempotence. Par exemple, si l’ERP est source de vérité, vous aurez souvent besoin de stocker une référence externe immuable au niveau commande (et idéalement au niveau ligne) plutôt que de déduire la corrélation via des champs « métier » fragiles (numéro de panier, date).

Autre limite réelle : le modèle de données PrestaShop est historiquement orienté « panier → commande → paiement », alors qu’en EDI on doit parfois gérer des statuts intermédiaires et des exceptions (commande partiellement acceptée, substitution produit, reliquats). Si vous forcez tout à rentrer dans order_state sans table de journal, vous perdez l’historique de négociation et vous rendez le support impossible. Une approche simple consiste à journaliser tous les événements EDI (entrant/sortant) avec : partner_id, type de message, message_id, référence fonctionnelle (ex. numéro de commande), statut, horodatage, et lien vers le payload brut.

AS2 : transport HTTP sécurisé, MDN et non-répudiation

AS2 est un standard de transport très utilisé en retail pour faire transiter de l’EDI sur Internet avec des garanties de sécurité et d’audit. Le document de référence côté IETF est le RFC dont le titre est explicite : « MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) » (RFC 4130). Dans la pratique, vous envoyez un payload (souvent EDIFACT ou X12) encapsulé en MIME, signé et/ou chiffré via S/MIME, sur HTTPS.

La différence critique par rapport à un « simple POST » est l’MDN (Message Disposition Notification) : un accusé de réception technique AS2, synchrone ou asynchrone, qui peut être signé. L’MDN est votre pièce de non-répudiation : sans MDN signé et archivé, vous n’avez pas de preuve qu’un partenaire a reçu (ou rejeté) le message. Il faut donc stocker au minimum : Message-ID, date/heure, certificats utilisés (empreinte), statut MDN, payload hash, et lien vers le fichier original.

Deux erreurs fréquentes côté exploitation :

considérer « HTTP 200 » comme une réussite métier : en AS2, le succès se prouve par le MDN (et son contenu) ;
ne pas gérer les MDN asynchrones : certains partenaires renvoient un MDN différé (callback), ce qui exige un endpoint dédié et une corrélation solide.

Exemple de points de contrôle concrets sur un connecteur AS2 (qu’il soit une librairie Java type OpenAS2, un service managé, ou un module maison) :

Rotation et expiration des certificats : alerte à J-30, publication des nouveaux certs aux partenaires, support du chevauchement.
Paramètres crypto : éviter les algos faibles, imposer TLS à jour, désactiver le downgrade.
Tolérance réseau : retry exponentiel, timeouts agressifs, séparation des erreurs 4xx/5xx.

Ajoutez un contrôle simple mais décisif : un tableau de bord par partenaire (même minimal) avec :

MDN reçus / en attente,
taux d’échecs sur 24h/7j,
latence médiane d’obtention du MDN,
backlog (messages non acquittés).
C’est ce qui permet de répondre vite à un client « je n’ai pas reçu votre commande » sans fouiller des logs bruts.

Sur PrestaShop, ne faites pas tourner le client AS2 dans le front web « au moment de valider la commande ». Vous allez coupler votre tunnel de conversion à la disponibilité du partenaire, ce qui est un anti-pattern. Utilisez une file (queue) et un worker (CLI) pour émettre en asynchrone, avec un statut d’export et une possibilité de rejouer (replay) sur un Message-ID constant. Pour la mise en œuvre d’une queue robuste côté Symfony, la base est déjà posée dans Symfony Messenger : configuration avancée, choix du transport et performances.

SFTP : le « batch sécurisé » qui revient toujours (et ses angles morts)

SFTP (SSH File Transfer Protocol) reste omniprésent pour des intégrations ERP parce qu’il est simple à opérer, traverse bien les réseaux, et s’insère dans des processus historiques (dépôt de fichiers à heure fixe). Sur le terrain, SFTP sert autant à transporter des messages EDI (EDIFACT) qu’à transporter des exports CSV/flat file « propriétaires » d’ERP. La bonne nouvelle : c’est trivial à automatiser. La mauvaise : c’est trivial à bricoler, et les bricolages coûtent cher quand on doit auditer.

D’un point de vue technique, vous devez traiter SFTP comme un système de messages, pas comme un partage de fichiers. Ça implique : conventions de nommage (horodatage + identifiant fonctionnel), atomicité (upload dans un répertoire inbox/tmp puis rename), verrous (lock files) et surtout idempotence (un fichier re-uploadé ne doit pas créer 2 commandes). Côté PrestaShop, cela se traduit par une table de journal (ex. edi_inbound_file) avec checksum SHA-256, date de traitement, statut, erreurs, et référence(s) d’objets créés.

Un pattern simple et robuste (et largement compréhensible par des équipes non EDI) :

dépôt du fichier dans in/ avec extension temporaire (ex. .part),
renommage atomique vers .edi quand l’upload est fini,
création côté émetteur d’un fichier « marqueur » .done (optionnel mais utile),
déplacement côté récepteur vers archive/ok ou archive/ko après traitement.
Ce pattern évite le grand classique : le job d’import lit un fichier en cours d’upload, parse un contenu tronqué, et vous obtenez des erreurs « aléatoires ».

La sécurité est souvent sous-estimée : SFTP chiffre le transport, mais pas le contenu une fois posé sur disque. Si vous déposez des factures ou des données personnelles, ajoutez du chiffrement applicatif (PGP) et gérez vos clés proprement. Sur une infra conteneurisée, évitez de stocker des clés privées dans l’image : injectez-les via un gestionnaire de secrets. Si vous êtes sur Kubernetes, la démarche « propre » ressemble à celle décrite dans External Secrets Operator : synchroniser les secrets Kubernetes avec OVHcloud OKMS.

Enfin, SFTP ne donne pas d’accusé métier standard : au mieux vous avez un ACK « fichier reçu » implicite. Si votre partenaire exige un accusé (CONTRL, 997, ou équivalent), il faudra un flux retour séparé (un autre dossier, ou un autre canal). C’est précisément là que beaucoup de projets se cassent : un dépôt de fichier n’est pas une transaction ; c’est un échange de blobs. Sans corrélation formelle, vous n’avez ni SLA réaliste, ni support exploitable. Dans les contrats d’échange, imposez au minimum : quel fichier correspond à quoi, comment il est identifié, et quelle est la règle en cas de doublon (rejet / écrasement / dédoublonnage par checksum).

PEPPOL : réseau, Access Points, AS4 et e-facturation conforme

PEPPOL n’est pas juste « un format de facture ». C’est un ensemble : identification des acteurs (Participant IDs), annuaire/lookup, règles d’interop, profils de documents (BIS), et transport basé sur des Access Points. Dans l’écosystème européen, PEPPOL est très souvent associé à la facturation électronique et à l’e-procurement, avec des documents basés sur UBL et un transport de type AS4/ebMS3.

Dans un projet réel, PEPPOL « ajoute » surtout :

un mécanisme de découverte (SML/SMP) pour trouver l’Access Point du destinataire,
des contraintes de conformité (profils BIS, règles de validation),
une gouvernance (certificats, onboarding, responsabilités).

Pour cadrer le périmètre légal, il faut distinguer : (1) la sémantique de facture (modèle de données), (2) la syntaxe (ex. UBL), (3) la transmission (PEPPOL), (4) les obligations nationales. Au niveau européen, le référentiel sémantique est encadré par la norme dont le titre officiel est « EN 16931-1:2017 — Electronic invoicing — Part 1: Semantic data model of the core elements of an electronic invoice ». En parallèle, la Directive 2014/55/EU pose le cadre d’adoption côté secteur public (EUR-Lex).

Côté implémentation, ne sous-estimez pas le coût « périphérique » : vous aurez besoin d’un Access Point PEPPOL (opéré par vous ou via un prestataire), de certificats, d’une stratégie d’archivage probante, et d’un mapping facture stable (taxes, avoirs, acomptes, frais de port, arrondis). Si votre objectif est « envoyer les factures PrestaShop dans PEPPOL », attention : PrestaShop n’est pas un outil comptable, et la facture PrestaShop n’est pas une facture au sens ERP dans beaucoup d’organisations (numérotation, immutabilité, gestion des écritures). Dans les architectures réalistes, PrestaShop alimente l’ERP, et l’ERP produit la facture comptable puis l’envoie vers PEPPOL.

Pour une coloration « locale » sans sur-promettre : en France (comme dans d’autres pays), la réforme de la facturation électronique implique souvent plusieurs briques (ERP/compta, opérateurs, canaux de transmission, contrôles). Dans ce contexte, PEPPOL peut être un levier d’interopérabilité selon les cas d’usage (secteur public, partenaires déjà PEPPOL-ready), mais il ne remplace pas à lui seul les exigences nationales (workflow de validation, archivage, piste d’audit).

En termes de documentation, partez des spécifications officielles PEPPOL (profils BIS, règles de transport) plutôt que de billets de blogs. Les versions et profils (ex. BIS Billing 3.x) sont indispensables pour éviter de « réussir à envoyer » tout en étant rejeté par le destinataire.

Architecture d’intégration autour de PrestaShop : pipeline, files, rejouabilité

Une intégration ERP/EDI/PEPPOL saine autour de PrestaShop se conçoit comme un pipeline : capture des événements, sérialisation en modèle canonique, mapping vers le format cible (EDIFACT/UBL), transport (AS2/SFTP/AS4), puis réconciliation (accusés, statuts, retours). Essayer de « générer du EDIFACT directement depuis les objets PrestaShop » est une recette pour la dette technique : vous couplez votre mapping au schéma PrestaShop et vous rendez tout changement (upgrade, module, multiboutique) dangereux.

La notion clé est le modèle canonique : une représentation interne stable de vos documents (commande, facture, expédition), indépendante de PrestaShop et indépendante du format cible. Même si vous ne formalisez pas un schéma complet, définissez au moins un noyau invariant (identifiants, parties, lignes, taxes, montants) pour que le mapping EDIFACT/UBL reste un module remplaçable.

Exemple (très condensé) de structure canonique de ligne de commande, utile pour tracer et rejouer:

{
  "order_ref": "PO2026-000123",
  "line_no": 1,
  "sku": "SKU-ABC123",
  "qty": 2,
  "uom": "PCE",
  "unit_price": 19.90,
  "currency": "EUR",
  "tax_rate": 0.20
}

Sur PrestaShop 9 (Symfony 6.4), vous pouvez vous appuyer sur une approche event-driven via Messenger pour découpler la boutique de l’intégration. Exemple de routage conceptuel (à adapter selon votre stack) :

# config/packages/messenger.yaml
framework:
  messenger:
    transports:
      async_edi: '%env(MESSENGER_TRANSPORT_DSN)%'
    routing:
      'App\\Message\\ExportOrderToEdi': async_edi
      'App\\Message\\ImportEdiAcknowledgement': async_edi

L’idée n’est pas « Messenger partout », mais : (1) émission asynchrone, (2) retries contrôlés, (3) DLQ (dead letter queue) ou table d’erreurs pour support, (4) corrélation forte (Message-ID, id_order, référence ERP). Pour les projets API-first, vous pouvez aussi externaliser une partie de l’intégration via l’Admin API et un service dédié ; l’article PrestaShop Admin API : environnement de développement Docker et Swagger donne une base utile pour industrialiser ce genre de composant.

Un point d’architecture souvent oublié : le pattern “outbox” (ou équivalent). Au lieu de « lire la commande et envoyer », vous enregistrez d’abord un événement d’export dans votre base (transactionnel), puis un worker le consomme et envoie. Résultat : vous réduisez drastiquement les exports « perdus » lors d’un crash, et vous pouvez prouver ce qui a été émis et quand.

Sur la partie performance/fiabilité, fixez des objectifs chiffrés. Exemple réaliste en B2B : 10 000 lignes de commande/jour, pics à 50 commandes/minute, et un SLA d’émission EDI < 2 minutes après validation commande. À ce niveau, ce n’est pas EDIFACT qui ralentit : ce sont les I/O (SFTP), la crypto (AS2), et les retries en chaîne quand un partenaire est instable. Dimensionnez vos workers, imposez une concurrence maximale par partenaire (throttling), et monitorer latence + backlog. Si votre infra PHP est déjà à la limite, corrigez le socle avant de blâmer l’EDI : voir Performance PHP LiteSpeed : optimiser LSAPI, cache opcode et concurrence et PHP OPcache : paramètres recommandés pour optimiser les performances.

Contrats d’échange, sécurité et observabilité : ce qui évite les incidents à 2h du matin

Avant même d’écrire une ligne de code, formalisez un contrat d’échange : types de messages, versions (EDIFACT D96A vs D01B, BIS 3.x), champs obligatoires, règles de TVA, stratégie d’arrondi, encodage, time zone, et surtout gestion des retours (ACK/MDN, rejets, erreurs métier). En EDI, l’absence de contrat se traduit par du « parsing au cas par cas », donc des bugs silencieux (pire que des erreurs bruyantes). Conservez ces contrats versionnés (Git) avec jeux d’exemples validés.

Un livrable simple qui fait gagner des semaines : une table de responsabilités par flux, même sur une page :

qui est responsable du mapping (vous / partenaire / ERP),
qui supporte le transport (certificats, accès SFTP, monitoring),
quel est le délai de traitement attendu,
quelle preuve fait foi (MDN signé, CONTRL, fichier retour, ticket).
C’est ce qui évite les ping-pongs entre équipes quand un message est « quelque part ».

Côté sécurité, appliquez les mêmes exigences que pour une API exposée : gestion des secrets, rotation, moindre privilège, durcissement. Sur SFTP : comptes dédiés, chroot, IP allowlist, clés SSH sans mot de passe, désactivation des algos legacy, journalisation. Sur AS2 : certificats X.509, TLS strict, stockage des MDN signés, horodatage fiable. Et surtout : traitez les payloads entrants comme non fiables (risques de zip-bomb, fichiers surdimensionnés, injections via parseurs, etc.). Pour une approche structurée côté PrestaShop, la logique d’hygiène (SBOM, WAF, CI/CD) est détaillée dans PrestaShop : sécuriser APIs et modules avec SBOM, WAF et CI/CD.

Enfin, l’observabilité n’est pas « nice to have » : c’est ce qui transforme une intégration EDI en système opéré. Exigez des métriques (messages envoyés/échoués, latence par partenaire, taux de retries, taille backlog), des logs corrélés (Message-ID partout), et des alertes actionnables (pas 200 emails « timeout »). Si votre orga n’a pas encore de monitoring cohérent, vous pouvez aligner les bases sur Prometheus : configuration des alertes, métriques et requêtes PromQL et compléter par une chaîne d’alerting vers Slack/Discord/email comme décrit dans PrestaShop : module d’alerting temps réel Slack, Discord et email.

Deux bonnes pratiques très pragmatiques pour réduire les incidents nocturnes :

Runbook “replay” : une procédure écrite (et testée) pour rejouer un message sans créer de doublon, avec les prérequis (idempotence, clé de corrélation, où retrouver le payload).
Journal fonctionnel lisible : un écran (ou rapport) qui dit « commande X → ORDERS envoyé (Message-ID Y) → MDN reçu → ORDRSP reçu → DESADV reçu ». Sans ça, le support dépend d’un développeur.

—

À retenir pour arbitrer rapidement : EDIFACT est un choix de syntaxe EDI robuste mais exigeant en mapping ; AS2 apporte l’audit et la non-répudiation au prix d’une complexité crypto/opérationnelle ; SFTP est simple mais pauvre en garanties transactionnelles ; PEPPOL est une approche réseau + conformité, particulièrement pertinente dès que l’e-facturation réglementée entre en jeu. Le reste, c’est de l’architecture : découplage, rejouabilité et supportabilité, pas un export de plus.