Votre grand client de la grande distribution vient d’envoyer un cahier des charges de 40 pages pour l’intégration EDI : AS2, EDIFACT ORDERS/ORDRSP/DESADV, délai de mise en production sous 90 jours. En parallèle, votre nouveau partenaire e-commerce vous demande une API REST avec webhooks, authentification OAuth 2.0 et documentation OpenAPI. Les deux sont signés dans le même trimestre.
Le DSI qui doit arbitrer se retrouve face à une vraie question d’architecture : continuer à investir dans l’infrastructure EDI héritée, passer aux API modernes, ou gérer les deux protocoles depuis une couche de médiation ? Ce choix conditionne des budgets sur 3 à 5 ans, des délais d’ouverture de nouveaux partenaires, et la capacité à répondre aux exigences réglementaires européennes comme la facture électronique obligatoire.
Ce guide compare les deux mondes avec les données réelles disponibles, détaille les cas où chaque protocole s’impose, et propose une matrice de décision applicable dès aujourd’hui.
Pourquoi les échanges B2B avec l’ERP restent un sujet ouvert en 2026
La multiplicité des standards : EDIFACT, ANSI X12, Peppol, cXML, JSON/REST
Le marché n’a jamais convergé vers un protocole universel. Selon les secteurs et les zones géographiques, coexistent plusieurs standards incompatibles entre eux :
- EDIFACT : standard ONU pour le commerce international, dominant en Europe, Asie et Amérique latine. Structuré en segments (UNH, BGM, DTM…), il couvre des dizaines de types de messages normalisés.
- ANSI X12 : standard américain, imposé par Walmart, Amazon Vendor Central, les grandes enseignes nord-américaines. Non interopérable nativement avec EDIFACT.
- Peppol (Pan-European Public Procurement On-Line) : infrastructure de routage européenne utilisant le protocole AS4. Le réseau compte désormais 4,4 millions de participants enregistrés dans plus de 100 pays, dont environ 890 000 en France (e-invoice.be, statistiques OpenPeppol, juin 2026).
- cXML : standard de commerce électronique utilisé par les plateformes d’achat SAP Ariba et Coupa, très présent dans les processus P2P des grandes entreprises.
- JSON/REST et OpenAPI : les API modernes utilisées par les plateformes SaaS, les marketplaces e-commerce et les fintech.
Le paradoxe de 2026 : Peppol, qui devait unifier les échanges via la facturation électronique, utilise lui-même une infrastructure de transport (AS4) distincte des API REST classiques, même s’il expose des endpoints API pour les accès techniques.
Les flux typiques concernés
Les échanges inter-ERP B2B suivent un cycle documentaire bien défini. En EDIFACT, les messages correspondants sont normalisés depuis les années 1990 :
| Flux métier | Message EDIFACT | Message ANSI X12 |
|---|---|---|
| Commande d’achat | ORDERS | 850 |
| Accusé de réception de commande | ORDRSP | 855 |
| Avis d’expédition (ASN) | DESADV | 856 |
| Facture | INVOIC | 810 |
| Accusé de réception message | CONTRL | 997 |
| Catalogue produits | PRICAT | 832 |
Ce sont ces flux que le DSI doit faire transiter entre son ERP et ses partenaires, quelle que soit la méthode de transport retenue.
L’EDI classique : forces, limites et quand encore le choisir
Fonctionnement d’un VAN EDI et d’un flux AS2
L’infrastructure EDI classique repose sur deux modèles de transport :
Le VAN (Value Added Network) : réseau privé géré par un opérateur tiers (OpenText Business Network, SPS Commerce, Axway…). Chaque partenaire dispose d’une boîte aux lettres électronique sur le VAN. L’ERP dépose un message, l’opérateur achemine et notifie le destinataire. Avantage : un seul contrat pour accéder à des milliers de partenaires déjà raccordés. Inconvénient : coût par transaction et per-mailbox.
AS2 (Applicability Statement 2) : protocole de transport point à point via HTTPS, sans intermédiaire. L’ERP émetteur envoie directement sur l’endpoint AS2 du partenaire, avec signature numérique et accusé de réception (MDN). Amazon Vendor Central, Carrefour et la majorité des grandes enseignes mondiales l’imposent pour leurs échanges EDIFACT directs.
Avantages : robustesse éprouvée et standards sectoriels imposés
L’EDI n’est pas mort parce qu’il répond à des contraintes que les API REST ne couvrent pas nativement :
- Standards sectoriels obligatoires : en grande distribution (GS1/EANCOM), en automobile (ODETTE, basé sur EDIFACT), en aérospatiale (ATA Spec 2000), en pharmacie (HL7/EDIFACT) et dans la logistique maritime, l’EDI est le standard imposé par les donneurs d’ordres. Refuser l’EDI, c’est refuser le client.
- Robustesse transactionnelle : les flux AS2 incluent des mécanismes de non-répudiation (signatures numériques, MDN signés) qui ont une valeur juridique reconnu dans les litiges commerciaux.
- Réseau de partenaires existant : les VAN opèrent des annuaires de dizaines de milliers de partenaires pré-connectés. Un nouveau fournisseur identifié dans cet annuaire peut être raccordé sans infrastructure spécifique de son côté.
Limites : coûts, délais et rigidité
Les limites de l’EDI classique sont documentées et réelles :
Délais d’ouverture : raccorder un nouveau partenaire EDI via un VAN traditionnel prend entre 4 et 12 semaines, selon la complexité du mapping et les cycles de test (Orderful, EDI Partner Onboarding Guide, 2026). Les plateformes modernes (cloud-native) descendent à 9 jours en moyenne, mais cela reste supérieur à une intégration API REST.
Coût par transaction : les VAN facturent au document, avec un tarif typique de 0,01 à 1,00 dollar par transaction selon le volume et le type de message (BOLD VAN, EDI Cost per Transaction Guide). S’y ajoutent les frais de setup par partenaire, de l’ordre de 750 à 2 500 dollars pour la mise en place, le mapping et les tests (Orderful, EDI Pricing Guide 2026).
Rigidité des mappings : chaque partenaire a ses propres variantes du standard EDIFACT (segments optionnels obligatoires, qualificateurs propriétaires, règles métier spécifiques). Le mapping est un travail de configuration qui doit être maintenu à chaque montée de version ou changement de partenaire.
Traitement batch : l’EDI classique fonctionne en mode asynchrone, avec des échanges planifiés (toutes les heures, toutes les 4 heures, ou en J+1 pour les factures). Il ne produit pas de visibilité temps réel sur l’état des flux.
Les API REST modernes : souplesse, temps réel et coûts réduits
Webhooks, REST et event-driven : comment ça marche côté ERP
Les ERP modernes exposent des API REST nativement. Quelques exemples concrets :
- SAP S/4HANA : Business Partner API, Sales Order API, Invoice API, toutes documentées via SAP API Business Hub. Utilise OData v4 par défaut.
- Odoo : JSON-RPC natif + API REST sur les modèles de données via des endpoints
/web/dataset/call_kw. - Microsoft Dynamics 365 : OData endpoints sur l’ensemble des entités Finance & Operations, avec webhooks via Azure Event Grid.
- NetSuite : SuiteQL + REST Record API, documentation OpenAPI disponible.
Le modèle event-driven (webhooks) modifie la logique d’intégration : au lieu de poller toutes les heures, l’ERP émetteur notifie en temps réel l’ERP destinataire à chaque événement (commande confirmée, expédition créée, facture émise). La latence passe de H+1 ou J+1 à quelques secondes.
Peppol : le pont entre EDI et API modernes en Europe
Peppol mérite un traitement particulier car il est à la fois un standard de routage (AS4, proche de l’EDI) et un réseau qui s’interface avec les ERP via des API modernes.
Le réseau Peppol fonctionne comme un “réseau postal électronique” : chaque participant dispose d’un identifiant Peppol (basé sur le numéro SIRET ou TVA), et les messages transitent entre Access Points certifiés selon le protocole AS4. Pour un ERP, l’intégration se fait via l’API de l’Access Point (REST/SOAP), pas directement via AS4.
La croissance est spectaculaire : 4,4 millions de participants en juin 2026, avec 890 000 en France (source : OpenPeppol SMP via e-invoice.be). La Belgique, avec 2,1 millions de participants, a montré que les mandats nationaux peuvent créer une adoption massive en quelques mois : leur obligation B2B entrée en vigueur en janvier 2026 a doublé les inscriptions en six mois.
La facturation électronique obligatoire en France (grande entreprise depuis septembre 2026, ETI depuis 2027) passe par Peppol ou par les PDP (Plateformes de Dématérialisation Partenaires). Ce basculement réglementaire rend le protocole incontournable pour les ETI françaises, qu’elles soient déjà sous EDI ou pas.
Limites des API REST en B2B
L’API REST n’est pas sans contraintes pour les flux ERP inter-entreprises :
- Gouvernance et versioning : imposer une API REST à ses partenaires nécessite une documentation maintenable, une politique de versioning (v1, v2, dépréciation), et un support des breaking changes. C’est une charge de gouvernance que les PME-partenaires n’ont pas toujours la capacité de gérer.
- Hétérogénéité des implémentations : contrairement à EDIFACT où les messages sont strictement normalisés, chaque ERP expose ses API REST différemment. Une intégration Odoo n’est pas réutilisable pour NetSuite.
- SLA moins rigide : les VAN EDI proposent des SLA de disponibilité (99,9 %) et des pénalités contractuelles. Les API B2B sans intermédiaire reportent la gestion des erreurs et des retry sur l’intégrateur.
Tableau comparatif : EDI classique vs API REST vs Architecture hybride
| Critère | EDI classique (VAN/AS2) | API REST | Architecture hybride |
|---|---|---|---|
| Délai ouverture partenaire | 4-12 semaines | 1-4 semaines | 2-8 semaines |
| Coût setup par partenaire | 750-2 500 $ | Quasi-nul si ERP natif | 1 000-5 000 $ |
| Coût par transaction | 0,01-1,00 $ | Quasi-nul | 0,01-0,30 $ |
| Standards sectoriels | EDIFACT, ANSI X12 | OpenAPI 3.x | Mixte |
| Temps réel | Non (batch H+1 à J+1) | Oui (webhooks) | Selon configuration |
| Non-répudiation juridique | Oui (MDN signé) | Partiel (logs API) | Oui (via AS2/AS4) |
| Adapté aux PME partenaires | Oui (annuaire VAN) | Partiel (capacité technique) | Oui |
| Maintenance | Élevée (mappings) | Modérée (versioning) | Complexe |
| Réglementation e-facture EU | Via Peppol/AS4 | Via Access Point API | Nativement |
Matrice de décision par secteur
Grande distribution et retail : EDI s’impose. GS1 impose EANCOM pour les commandes et les factures. Les enseignes (Carrefour, Casino, Leclerc, Auchan) raccordent leurs fournisseurs via VAN ou AS2 direct. Impossible de les convaincre de basculer sur API REST : leur infrastructure d’achat est centralisée sur des plateformes EDI consolidées depuis 20 ans.
Industrie automobile : EDI obligatoire (ODETTE, basé sur EDIFACT). La supply chain automobile est historiquement l’un des plus grands écosystèmes EDI du monde. Stellantis, Renault, BMW imposent leurs standards EDI à l’ensemble de leur réseau de fournisseurs de rang 1 et 2.
Industrie pharmaceutique et dispositifs médicaux : EDIFACT + HL7 pour les flux documentaires, Peppol pour la facturation électronique. Le dossier réglementaire impose une traçabilité stricte que l’EDI avec MDN signé fournit mieux qu’une intégration REST sans log centralisé.
E-commerce, marketplaces et SaaS : API REST domine. Shopify, Prestashop, Amazon MWS, Stripe, les ERP SaaS comme Pennylane ou Sellsy exposent des API REST documentées. Les partenaires sont des développeurs, pas des opérateurs EDI.
Services financiers et fintech : API REST + FAPI (Financial-grade API). La DSP2 et les API bancaires open banking sont nativement REST.
ETI multi-clients, secteurs mixtes : architecture hybride. Une ETI industrielle avec des clients grande distribution (EDI), des clients e-commerce (API REST) et des obligations Peppol (facture électronique) ne peut pas trancher en faveur d’un seul protocole.
L’architecture hybride : le choix croissant des ETI
iPaaS : la couche de médiation EDI/API
Les plateformes iPaaS (Integration Platform as a Service) permettent de gérer les deux protocoles depuis une interface unifiée avec monitoring centralisé. Les acteurs principaux sur le marché européen :
- Dell Boomi : historiquement fort sur l’EDI B2B, très utilisé dans la grande distribution et l’industrie. Intègre nativement EDIFACT, ANSI X12, Peppol et des connecteurs vers les principaux ERP.
- MuleSoft (Salesforce) : plus orienté API management, mais des connecteurs EDI existent. Adapté aux entreprises déjà dans l’écosystème Salesforce.
- Celigo : cloud-native, orienté PME/ETI, bon rapport fonctionnalité/coût pour les entreprises qui veulent unifier e-commerce (Shopify) et ERP (NetSuite, SAP) sans équipe d’intégration dédiée.
- Axway B2Bi (Business Integration) : spécialisé B2B, supporte AS2, AS4, SFTP, EDIFACT, ANSI X12 et REST. Historiquement utilisé dans la banque, les télécoms et l’industrie lourde.
L’iPaaS joue le rôle d’un traducteur universel : il reçoit un message EDIFACT côté partenaire historique, le transforme en objet JSON, et l’injecte via API REST dans l’ERP interne, ou l’inverse.
Exemples d’architectures hybrides en production
ETI industrielle avec 200 partenaires : flux AS2/EDIFACT pour les 30 grands donneurs d’ordres (grande distribution, automobile), API REST pour les 40 partenaires e-commerce et SaaS, Peppol pour toutes les factures fournisseurs et clients. Une seule plateforme iPaaS centralise le monitoring, les alertes et les reprises sur erreur.
Distributeur pharmaceutique : flux DESADV EDIFACT pour les livraisons vers les officines (standard imposé par les groupements), API REST pour les commandes en provenance des plateformes d’achat hospitalier, Peppol pour la facturation électronique depuis septembre 2026.
Peppol : le standard qui unifie progressivement les deux mondes
L’ambition de Peppol est précisément de résoudre le problème de fragmentation. Le réseau achemine des documents structurés (UBL, PEPPOL BIS Billing 3.0) via AS4, mais les Access Points exposent des API REST pour les ERP. Un ERP qui s’intègre à son Access Point Peppol parle REST, même si la transmission inter-Access-Point utilise AS4.
C’est un modèle d’abstraction élégant : l’ERP ignore le protocole de transport (AS4), il voit uniquement une API REST documentée. L’Access Point gère la conformité réseau.
Pour la France, ce modèle devient structurant avec l’obligation de facturation électronique B2B pour toutes les ETI à partir de 2027. Les ETI qui n’ont pas encore de connectivité Peppol doivent l’anticiper dans leur architecture d’intégration, qu’elles viennent du monde EDI ou du monde API.
5 questions décisives avant de trancher
1. Quels partenaires dominent votre réseau ?
Si vos 10 plus gros clients ou fournisseurs imposent l’EDI, la question ne se pose pas : vous devez maintenir une infrastructure EDI. L’API REST sera complémentaire, pas alternative.
2. Quel est votre secteur principal ?
Grande distribution, automobile, aérospatiale, pharma : EDI incontournable. E-commerce, SaaS, fintech : API REST natif. Industrie mixte ou distribution multi-secteur : hybride obligatoire.
3. Quel est votre volume mensuel de transactions B2B ?
En dessous de 1 000 transactions par mois, le coût par transaction EDI reste marginal. Au-delà de 50 000 transactions par mois, l’écart de coût entre EDI via VAN et API REST devient significatif sur 3 ans.
4. Avez-vous les capacités internes pour maintenir les deux protocoles ?
Maintenir une infrastructure EDI (mappings, versions de message, onboarding partenaires) nécessite une compétence spécialisée que beaucoup d’ETI n’ont plus en interne. Si l’équipe est sur les API modernes, déléguer l’EDI à un opérateur géré (EDI-as-a-service) est souvent plus économique que de reconstruire en interne.
5. Où en est votre conformité Peppol/facturation électronique ?
Si votre ERP n’est pas encore connecté à un Access Point Peppol et que votre ETI dépasse 250 M€ de chiffre d’affaires, la conformité 2027 devient votre contrainte prioritaire. Elle conditionne le choix de votre architecture d’intégration B2B globale, pas l’inverse.
Pour aller plus loin sur l’architecture d’intégration ERP, consultez notre guide opérationnel de la gouvernance API ERP et notre méthode de tests d’intégration ERP de J-90 à J+7. Si vous êtes en train d’arbitrer entre CRM natif ERP et CRM dédié, notre analyse des flux de données CRM-ERP complète la réflexion sur l’architecture d’intégration globale.
