B2B vs EDI

Tout EDI est du B2B. La réciproque est fausse. Cette page trace la frontière exacte entre les deux périmètres, et donne des règles pratiques pour savoir si votre projet d'intégration relève de l'EDI au sens strict — ou simplement d'un échange B2B classique.

B2B — un périmètre large

Le sigle B2B (Business-to-Business) couvre, par convention économique, toute relation commerciale dont les deux extrémités sont des organisations — par opposition au B2C (Business-to-Consumer) qui adresse un individu, et au B2G (Business-to-Government) qui adresse une administration. Dans cette acception, le périmètre B2B est volontairement large : il englobe tout autant l'envoi d'un email avec une pièce jointe que l'appel d'une API REST entre deux SI partenaires.

Le sujet de cette page est plus technique : dans le périmètre B2B, quels échanges relèvent réellement de l'EDI, et lesquels n'en relèvent pas ? Pour y répondre, il faut classer les modalités d'échange.

Trois familles d'échanges B2B

On peut ranger l'écrasante majorité des flux B2B techniques modernes en trois grandes familles. Chacune correspond à un mode d'intégration, à un niveau de standardisation et à un degré différent d'automatisation.

1. L'échange de fichiers (file-share)

La modalité la plus ancienne et la plus simple : un fichier est déposé par l'émetteur sur un répertoire partagé (SFTP, FTPS, S3, OneDrive, partage SMB) et récupéré ou poussé vers le destinataire. Le format peut être CSV, XLSX, XML libre, PDF — le contenu n'est pas contraint par un standard public et la lecture machine dépend d'une convention bilatérale documentée hors-flux. Il n'y a généralement pas d'accusé de réception formalisé : si quelque chose se passe mal, on s'en aperçoit à la prochaine astreinte. Ce mode est encore très répandu pour les flux internes, les flux de reporting et les rapprochements asynchrones.

Est-ce de l'EDI ? Pas au sens strict. Aucune des trois caractéristiques de l'EDI — structure normalisée, identification mutuelle, accusé bidirectionnel — n'est mécaniquement garantie par un dépôt SFTP. Cela peut tendre vers l'EDI si les conventions sont rigoureuses, mais ça reste alors une convention privée.

2. L'API (REST, GraphQL, SOAP)

Depuis le début des années 2010, l'API REST a colonisé le périmètre B2B. Un partenaire expose une URL, l'autre l'appelle en POST/GET avec un payload JSON ou XML, reçoit une réponse synchrone, et la chaîne se poursuit. La modalité est application-to-application par essence, donc machine-lisible ; elle inclut typiquement un acquittement synchrone (le code HTTP 200/4xx/5xx) et souvent une authentification mutuelle solide (OAuth 2.0, mTLS, JWT). C'est l'option par défaut pour toutes les marketplaces récentes, les fournisseurs de paiement, les flux de catalogue temps réel, et la plupart des intégrations SaaS-à-SaaS.

Est-ce de l'EDI ? Pas automatiquement, mais ça peut l'être. Le cas cXML est précisément celui-là : une API HTTPS qui transporte des documents au format XML normalisé par Ariba, avec identification mutuelle par Network Identity et accusé via cXMLResponse. PEPPOL, sur sa partie eDelivery, est également une API au sens architectural (du SOAP sur AS4), et c'est de l'EDI. À l'inverse, une API REST custom de marketplace n'est généralement pas de l'EDI parce que la structure du payload est propre à l'éditeur.

3. L'EDI au sens strict

L'EDI est la sous-famille où les trois propriétés sont réunies :

1. Le contenu est structuré par un standard public — EDIFACT, X12, cXML, UBL — versionné et maintenu par un organisme de normalisation indépendant des éditeurs (UN/CEFACT, ANSI ASC X12, OASIS, OpenPEPPOL).
2. Les parties sont identifiées par un schéma international stable — GLN, DUNS, SIRET, identifiant PEPPOL — qui survit aux changements d'éditeur ou d'infrastructure.
3. Chaque message reçoit un accusé bidirectionnel formalisé : CONTRL en EDIFACT, 997/999 en X12, cXMLResponse en cXML, ApplicationResponse en UBL — doublé d'un MDN cryptographique au niveau transport pour AS2.

Cela peut emprunter un canal de transport très différent — SFTP, AS2, AS4, OFTP2, HTTPS API — mais le payload, l'identification et l'accusé restent normalisés.

L'EDI comme sous-ensemble du B2B

Visuellement, on peut représenter l'EDI comme le cœur dur du B2B technique : un sous-ensemble où la formalisation est maximale, l'automatisation totale, et la portabilité entre éditeurs garantie. Plus on s'éloigne du centre, plus on rencontre d'échanges B2B au sens large qui restent légitimes mais qui ne sont pas de l'EDI au sens du jargon métier de cette industrie.

Quand choisir quoi ?

Les cas d'erreur fréquents

• « On fait de l'EDI » — alors qu'on fait du SFTP de CSV. Ce raccourci de vocabulaire ne pose pas problème en interne mais devient toxique quand un acheteur exige un véritable EDI : il s'attend à des CONTRL, à des messages EDIFACT ou X12, et à un protocole sécurisé qualifié.
• « Notre API REST remplace l'EDI ». Vrai dans certains cas (cXML, PEPPOL AS4), faux dans la plupart : une API REST custom n'est pas un standard d'industrie. Si votre partenaire grand distributeur exige un 850 X12, votre POST /orders JSON ne le remplace pas.
• « On a un mapping, donc on a un standard ». Un mapping d'intégration n'a de valeur que pour le couple émetteur-destinataire ; un standard est ce qui se réutilise avec un troisième partenaire sans renégocier le format.

Pour aller plus loin

• Qu'est-ce que l'EDI ? — la définition canonique et les trois propriétés détaillées.
• Paysage des standards — la carte mondiale des standards pour orienter le choix.
• Glossaire — B2B · Glossaire — VAN · Glossaire — EDIINT.
• EDIFACT ORDERS D.96A — l'exemple canonique d'un message EDI strict.
• Validateur EDIFACT — pour tester la conformité d'un message réel.