API vs EDI : différence pour connecter un transporteur

API et EDI font circuler les mêmes données : adresses, colis, étiquettes, statuts, factures. Mais pas pour les mêmes besoins, ni au même endroit de votre chaîne logistique.

Le débat API vs EDI se résume souvent à « temps réel contre différé ». C'est faux.

Voici ce qui change vraiment quand un e-commerçant doit connecter sa boutique à un transporteur, et comment évaluer l'effort d'intégration avant de signer.

En bref

2 modes pour relier une boutique à un transporteur : API et EDI. Ils ne s'opposent pas, ils se complètent.
L'API sert les interactions immédiates : points relais, desserte, étiquette, suivi, modification de livraison.
L'EDI industrialise les volumes : milliers d'ordres de transport, manifestes, statuts, factures vers l'ERP.
« API = temps réel, EDI = différé » : faux. Une API peut tourner par lots, un EDI peut circuler toutes les 15 minutes.
« API disponible » ne veut rien dire seul. Une API peut se limiter à la création d'étiquette.
6 points à vérifier par écrit avant de vous engager sur un mode d'intégration.

API et EDI : deux façons de faire circuler les données

L'API est un échange à la demande entre deux logiciels, en requête/réponse. L'EDI est un échange de fichiers dans un format structuré, défini à l'avance.

Le comparatif ci-dessous résume les écarts qui pèsent réellement dans un projet d'intégration transporteur e-commerce.

Critère	API	EDI
Principe	Votre système demande, le transporteur répond	Un fichier structuré est déposé, puis lu par l'autre système
Déclencheur	Votre logiciel, au moment où il en a besoin	Un événement métier ou un planning (fin de journée, départ de tournée)
Format	JSON ou XML, défini par le transporteur	Format normé : UN/EDIFACT, ANSI X12
Canal	HTTPS, authentification par clé API ou OAuth	AS2, SFTP, réseau VAN, avec accusé de réception
Granularité	Un objet par appel : un colis, une adresse, un suivi	Un lot : 500, 5 000 ou 50 000 documents
Usage e-commerce typique	Checkout, choix du point relais, étiquette, suivi client	Ordres de transport de masse, manifestes, statuts, factures
Effort d'intégration	Quelques jours à quelques semaines, souvent via un module	Plusieurs semaines à plusieurs mois : mapping, tests, certification
Coût	Généralement inclus dans le contrat transporteur	Frais de mise en place, licence, parfois intégrateur

À retenir : l'API branche votre boutique. L'EDI branche votre système d'information. Ce ne sont pas les mêmes interlocuteurs, ni les mêmes délais.

L'API : l'échange à la demande

Une API (interface de programmation applicative) est un ensemble de règles qui permet à deux logiciels de communiquer. Votre boutique envoie une requête, le transporteur répond immédiatement.

Le mécanisme, en 4 éléments

Un endpoint par fonction : une URL pour l'étiquetage, une autre pour le suivi, une autre pour les points relais.
Une authentification : clé API, jeton OAuth, parfois certificat client.
Un format d'échange : JSON dans la majorité des cas, XML pour les API plus anciennes de type SOAP.
Un code de retour : la réponse indique si l'appel a réussi, et pourquoi il a échoué sinon.

À cela s'ajoute un mécanisme souvent décisif : le webhook. Le transporteur pousse lui-même l'événement vers votre système dès qu'un statut change. Vous n'avez plus à interroger l'API toutes les heures pour savoir si le colis est livré.

5 cas d'usage concrets

Points relais autour d'une adresse - l'API renvoie les points disponibles, leurs horaires et leur distance. C'est elle qui alimente la carte du checkout.
Vérification de la desserte d'une destination - avant d'afficher une promesse de livraison, l'API confirme que la zone est couverte et indique le délai réel.
Génération d'étiquette - l'API renvoie le fichier d'étiquette imprimable, avec le numéro de suivi associé.
Récupération du suivi - votre service client et vos e-mails de notification lisent le statut à la source, sans ressaisie manuelle.
Modification de livraison - changement de point relais, correction d'adresse, report de livraison : l'API applique la demande dans le système du transporteur.

Quand l'API est indispensable

Checkout : afficher les points relais et les délais suppose un appel en direct, au moment où le client renseigne son adresse.
CMS : PrestaShop, Shopify, WooCommerce ou Magento ne peuvent proposer un module transporteur que si une API transporteur existe derrière.
WMS : éditer l'étiquette depuis l'ordre de préparation évite une double saisie et les erreurs de colis.
Logiciel d'expédition : la consolidation de plusieurs transporteurs dans un seul outil repose entièrement sur des API.

Une API transporteur qui n'expose pas les points relais bloque purement et simplement l'option livraison en relais. Le reste du comparatif devient secondaire.

L'EDI : l'échange de fichiers structurés

L'EDI (échange de données informatisé) remplace les documents papier par des messages électroniques structurés et normés. Deux systèmes échangent des fichiers dans un format défini à l'avance, sans intervention humaine.

Le mécanisme, en 4 étapes

Votre système génère un message dans le format attendu par la norme et le partenaire.
Le fichier part par un canal sécurisé : AS2, SFTP, réseau à valeur ajoutée (VAN).
Le récepteur l'intègre automatiquement dans son système, selon un mapping préétabli.
Un accusé de réception confirme la bonne réception - et, en cas d'anomalie, permet de rejouer le lot.

Les standards à connaître

UN/EDIFACT : norme internationale portée par l'ONU, dominante en Europe et à l'international.
ANSI X12 : norme nord-américaine, très répandue chez les transporteurs et chargeurs américains.
Messages transport EDIFACT : IFTMIN (instruction de transport), IFTSTA (statut de transport), INVOIC (facture).
Transactions X12 : 204 (ordre de transport), 214 (statut d'expédition), 210 (facture transport).

Cas d'usage

Milliers d'ordres de transport : un envoi groupé après la clôture de la journée remplace des milliers d'appels unitaires.
Manifeste : la liste des colis d'une tournée part en un seul fichier vers le transporteur.
Statuts de livraison : les remontées de statut alimentent automatiquement votre ERP et votre service client.
Factures : l'intégration directe dans l'ERP supprime la ressaisie et accélère le rapprochement de fin de mois.

Ce que l'EDI exige en retour

Un format imposé, versionné, limité à un sous-ensemble de segments acceptés par le transporteur.
Une phase de test obligatoire avant la mise en production.
Une certification délivrée par le transporteur.
Un volume minimal, contractuel.

Un EDI transporteur ne se paramètre pas comme un plugin. C'est un projet, avec des allers-retours, un interlocuteur technique et une date de mise en service.

Pourquoi « API = temps réel, EDI = différé » est faux

L'opposition est trompeuse : une API peut être appelée par lots, et un EDI peut circuler à un rythme très rapide. La vraie différence n'est pas la vitesse, c'est la manière dont les systèmes communiquent et s'intègrent dans vos opérations.

Une API peut fonctionner par lots. Un script planifié chaque nuit appelle 4 000 fois l'endpoint d'étiquetage. Chaque réponse est instantanée, le traitement global est différé. La latence vient de votre organisation, pas de la technologie.

Un EDI peut circuler en flux quasi continu. Des transporteurs échangent des statuts IFTSTA ou X12 214 toutes les quinze minutes. Le format est normé, la fréquence ne l'est pas.

Ce qui change réellement :

Point	API	EDI
Qui déclenche	Votre logiciel, à la demande	Un planning ou un événement métier
Qui impose le format	Le transporteur, via sa documentation	La norme, puis le mapping du partenaire
Où se gère l'erreur	Dans l'appel, par un code de retour	Dans l'accusé de réception, sur le lot entier
Qui porte la responsabilité	Vous, appel par appel	Les deux systèmes, selon le contrat d'échange

Poser la question « temps réel ou différé ? » fait perdre le vrai sujet. La bonne question : « qui déclenche l'échange, et qui corrige quand ça casse ? ».

Dans la pratique : les grandes organisations utilisent les deux

Les organisations qui expédient en volume utilisent l'API pour les interactions immédiates et l'EDI pour industrialiser les échanges de masse. Le choix est presque jamais binaire.

L'API, côté expérience d'achat :

Affichage du délai de livraison sur la fiche produit
Choix du point relais au checkout
Édition de l'étiquette à l'unité depuis le WMS
Notification client à chaque changement de statut

L'EDI, côté industrialisation :

Envoi groupé des ordres de transport après la clôture
Transmission quotidienne ou infra-quotidienne des statuts
Réception des factures transporteur directement dans l'ERP

Un e-marchand qui expédie 200 colis par jour vit très bien avec la seule API. Celui qui en expédie 20 000 par jour, sur plusieurs entrepôts et plusieurs transporteurs, industrialise une partie de ses flux en EDI - et garde l'API pour ce que le client voit.

Aucun e-marchand sérieux ne choisit « API ou EDI ». Il attribue une fonction à chaque mode : l'interaction au client d'un côté, le volume de l'autre.

Derrière « API disponible », des réalités très différentes

Une API annoncée dans une grille tarifaire ne dit rien de ses fonctions réelles. Deux transporteurs qui couvrent les mêmes destinations peuvent demander des efforts d'intégration très différents.

Ce que l'API expose réellement

Création d'étiquette seule, sans recherche de point relais
Points relais limités à la France métropolitaine
Aucune gestion des retours
Suivi résumé à trois statuts, sans détail d'acheminement
Pas de webhook : il faut interroger l'API à intervalle régulier

L'accès à la documentation

Documentation publique avec exemples et environnement de test : intégration possible en quelques jours.
Documentation sous compte client, contrat signé ou accord de confidentialité : comptez plusieurs semaines avant la première ligne de code.
Aucune documentation publique, validation technique imposée et intégrateur agréé obligatoire : le projet sort du périmètre d'une équipe e-commerce.

L'EDI : des prérequis non négociables

Format précis, version précise, segments limités à ceux validés par le transporteur
Phase de test obligatoire, avec jeux de données de référence
Certification à obtenir avant toute mise en production
Volume minimal contractuel, parfois assorti de frais de mise en place

Deux transporteurs peuvent afficher la même couverture géographique et les mêmes tarifs, tout en étant séparés par six semaines d'intégration. La question n'est jamais « livrent-ils chez moi ? » mais « me laissent-ils brancher mon système, et à quel coût ? ».

Comment évaluer la complexité d'intégration d'un transporteur

Six points suffisent pour classer les transporteurs par effort d'intégration réel. Posez-les par écrit, pas au téléphone.

Point à vérifier	Question à poser	Signal d'alerte
1. Fonctions exposées par l'API	L'API gère-t-elle points relais, retours, suivi détaillé et modification de livraison ?	Réponse vague, ou « bientôt disponible »
2. Accès à la documentation	Puis-je consulter la documentation technique avant de signer ?	Documentation accessible seulement après signature
3. Prérequis techniques	Clé API, IP fixe, certificat, compte marchand validé ?	Validation manuelle de chaque compte, IP blanche exigée
4. Modules CMS compatibles	Existe-t-il un module officiel pour mon CMS ?	Un simple export CSV à importer manuellement
5. Certification et volume minimum (EDI)	Quel volume minimal, et quel délai de certification ?	Certification à la charge du marchand, sans durée annoncée
6. Besoin d'un intégrateur	Puis-je intégrer seul, ou faut-il un partenaire agréé ?	Intégrateur imposé par le transporteur

Trois signaux d'alerte ou plus : budgétez un intégrateur externe et un délai de mise en production mesuré en semaines, pas en jours.

Vous n'avez pas à trancher API ou EDI dans l'absolu. Vous avez à trancher une seule question : ce transporteur me laisse-t-il brancher mon checkout et mon WMS dans un délai acceptable ?

FAQ

Quelle est la différence entre API et EDI en une phrase ?

L'API est un échange en requête/réponse déclenché par votre logiciel ; l'EDI est un échange de fichiers structurés dans un format normé, défini à l'avance. La première sert l'interaction immédiate, le second l'industrialisation des volumes.

Faut-il choisir l'un ou l'autre ?

Non, dans la plupart des cas. Une boutique connecte son checkout et son WMS en API, puis industrialise ses échanges de masse en EDI quand les volumes le justifient. Le basculement se fait sur des seuils de volume, pas sur une préférence technologique.

Qu'est-ce qu'un EDI en logistique ?

C'est l'échange de messages normés entre un chargeur et un transporteur : ordre de transport (IFTMIN en EDIFACT, X12 204), statut d'acheminement (IFTSTA, X12 214), facture (INVOIC, X12 210). Les fichiers circulent par canal sécurisé, avec accusé de réception et traitement automatique de bout en bout.

Une API transporteur est-elle gratuite ?

L'accès à l'API est généralement inclus dans le contrat transporteur. Ce qui se facture, c'est la mise en production : module CMS payant, heures d'intégrateur, éventuels frais d'activation. Demandez le coût total d'intégration, jamais le « prix de l'API ».

Quel mode d'intégration pour une petite boutique ?

L'API, presque toujours, et via un module CMS existant quand il existe. L'EDI n'a de sens qu'à partir de volumes qui justifient le mapping, la phase de test et la certification. En dessous, le retour sur investissement est négatif.

Sources utiles

Définitions officielles

INSEE - Échange de données informatisé (EDI), définition - définition de référence de l'EDI
IBM - Qu'est-ce que l'EDI ? - fonctionnement et usages de l'échange de données informatisé
IBM - EDI et API : différences et avantages - comparaison technique des deux modes
SAP - Qu'est-ce que l'EDI ? - EDI dans les chaînes logistiques et les ERP

Normes EDI

OQLF - Norme EDIFACT - définition officielle de la norme EDIFACT
ASC X12 - organisme de normalisation à l'origine des transactions X12 utilisées en transport

Documentation API de transporteurs

La Poste - API Suivi v2 (catalogue développeur) - suivi Colissimo, Chronopost et courrier suivi
La Poste - Colissimo, web services (catalogue développeur) - étiquetage, livraison, documents douaniers
Colissimo - Documentation technique SLS - génération d'étiquettes et expédition
Colissimo - Documentation livraison et points de retrait - choix du point relais et options de livraison

API, définition et exemples publics

data.gouv.fr - Catalogue des API publiques - exemples d'API documentées, avec environnements de test