Il y a quelque temps, je me suis lancé dans une quête pour découvrir s'il existait une norme API/EDI de transport unifiée utilisée par plusieurs entreprises de logistique. Sûrement, à notre époque, quelque chose comme ça doit exister, n'est-ce pas ? Un format d'API d'expédition universel ?

Eh bien, pour faire court, cela n'existe pas.

Ce qui s'en rapproche le plus est un fournisseur d'API qui a construit de nombreuses connexions API avec des transporteurs et qui propose ensuite son propre point d'accès API pour accéder à différents prestataires de services de transport.

Dans cet article, je vais aborder quelques API de transporteurs différentes, décrire brièvement leurs capacités et discuter des moyens de les mettre en œuvre.

NB ! Si vous recherchez simplement un protocole API de transport universel, voici un lien où vous pouvez réserver un appel rapide avec moi.

Quoi qu'il en soit, commençons par un...

Exemple de cas réel


Tout d'abord, définissons l'objectif.

Considérons un fabricant moyen avec des clients et des fournisseurs nationaux et internationaux. Les marchandises doivent être récupérées chez les fournisseurs et livrées sur le site de production, tandis que les produits finis doivent être expédiés aux clients.

Pour établir une chaîne d'approvisionnement fiable, un fabricant de taille moyenne typique aurait besoin de 10 à 20 partenaires de transport :
  • Un ensemble pour les colis nationaux
  • Un autre ensemble pour les palettes nationales
  • Un partenaire de fret offrant des prix compétitifs pour les pays voisins du nord pourrait ne pas proposer la même offre pour d'autres directions ou des distances plus longues.
  • Il en va de même pour le groupage, le LTL ou les chargements complets (FTL)
  • Pour les clients outre-mer, un ensemble de partenaires complètement différent pourrait être nécessaire
  • ... et ainsi de suite.

Gérer toutes ces relations est déjà assez complexe. Mais le vrai défi commence lorsque vous essayez d'intégrer leurs systèmes informatiques ! (puisqu'il n'existe pas de protocole API de fret unifié)

Deuxièmement, nous devons nous mettre d'accord sur la portée.

Toutes les entreprises de logistique n'offrent pas le même niveau de service. Certaines disposent d'API très sophistiquées offrant une tarification de fret instantanée, des réservations, des étiquettes, un suivi, des demandes de coursier, etc., tandis que d'autres n'ont qu'un portail où vous pouvez vous connecter et soumettre une réservation. Certaines n'ont aucun système informatique du tout - seulement le courrier électronique. Pour notre scénario cible, gardons les choses simples et visons simplement à :

  1. Soumettre une commande de transport
  2. Recevoir en retour les étiquettes de transport
  3. Peut-être obtenir le prix de transport estimé si nous avons de la chance !

Ça a l'air simple, non ? Oh, si seulement...

Connexions avec les transporteurs - bienvenue dans la jungle


La méthode manuelle de gestion des choses, qui semble être la norme de l'industrie pour la plupart des entreprises, implique l'utilisation de portails de transporteurs lorsque c'est possible et la communication par e-mail avec le reste des partenaires de transport. Dans notre exemple, nous supposons que les listes de prix de transport, les horaires, les délais de livraison et le traitement des factures sont gérés séparément. Pour les soumissions de réservations, nous visons à construire une connexion API de notre système ERP.

Supposons que nous ayons sélectionné la liste suivante d'entreprises de transport et que nous devions construire une connexion API directe à leurs systèmes depuis notre logiciel ERP. Cette sélection est aléatoire et ne couvre qu'une fraction des différentes API de transporteurs existantes.

DHL Express - utilise un portail appelé MyDHL, qui a également des capacités API. Cependant, il utilise différentes API pour les branches Freight, Express et Global Forwarding, et différentes approches API dans diverses régions. L'accès au service web nécessite un protocole SOAP, des services RESTful ou du XML simple, et les développeurs doivent être familiers avec XML/JSON et avoir une compréhension de base des services web. La spécification de l'API fait à elle seule 457 pages. Elle est approfondie, mais votre développeur vous facturera les heures passées simplement à la lire. Une fois mise en œuvre, vous devriez déclencher en moyenne 5 à 12 requêtes par expédition, en commençant par l'authentification jusqu'aux validations d'adresses, aux vérifications de disponibilité et aux demandes d'étiquettes.

Schenker - utilise différentes solutions API/EDI dans diverses régions. Le plus souvent, il utilise un protocole SOAP avec un format XML. Le message lui-même est simple, à condition que toutes les erreurs possibles soient correctement gérées. Les développeurs ont besoin d'un accès personnalisé pour implémenter l'API. Selon votre localisation, on pourrait vous demander d'implémenter une solution EDIFACT à la place, que je couvrirai plus tard.

DSV - a récemment migré vers leur portail compatible API appelé MyDSV. Étant donné que l'API est assez récente, elle tire parti de certaines des approches les plus récentes et les plus modernes dans le monde des API. Malgré la complexité lors de l'authentification et de la navigation dans leur catalogue de produits, l'approche est simple. Encore une fois, selon votre localisation, EDIFACT pourrait être préféré.

FedEx et TNT - cela peut être amusant. Tout d'abord, vous devez déterminer si vous utilisez les services TNT ou FedEx. Bien qu'ils auraient dû être la même entreprise depuis plusieurs années, la migration est toujours en attente. Si votre contrat est avec TNT, on vous demandera très probablement d'implémenter l'API TNT Express Connect. L'implémentation elle-même est de complexité moyenne. L'inconvénient est que cette API est considérée comme obsolète et sera éventuellement arrêtée. L'API FedEx, quant à elle, est plus complexe et offre plusieurs options selon la région où vous êtes basé. Chez Cargoson, nous avons implémenté l'API FedEx Compatible, qui offre des fonctionnalités supplémentaires très intéressantes mais n'est disponible que pour les partenaires FedEx Compatible.

UPS - utilise une API basée sur JSON et OAuth pour l'authentification, ce qui signifie qu'il y a pas mal de requêtes que vous devriez déclencher avant d'obtenir votre réservation et vos étiquettes en retour.

Ensuite, nous avons EDIFACT, utilisé par de nombreuses entreprises de transport telles que DSV, Maersk, DB Schenker, Kuehne + Nagel, C.H. Robinson, CEVA Logistics, etc. C'est une norme très ancienne, et même s'il peut sembler que vous pourriez vous en sortir avec une seule intégration API pour plusieurs entreprises de logistique, détrompez-vous. Le plus gros inconvénient est qu'il s'agit d'une connexion basée sur l'échange de fichiers, ce qui signifie que vous devriez générer un fichier physique réel, puis le transmettre via FTP et littéralement espérer que tout va bien car il y a un retour d'information très lourd sur les erreurs et les avertissements.

Similaire à EDIFACT est FORTRAS, une connexion basée sur des fichiers avec les mêmes inconvénients. Il est plus utilisé en Allemagne et dans les pays voisins. Non seulement l'échange de fichiers est difficile, mais le format de fichier lui-même est difficile à lire et, par conséquent, très long à déboguer en cas d'erreurs. Parmi les entreprises bien connues qui l'utilisent, on peut citer Dachser, Schenker, Kuehne + Nagel, Hellmann Worldwide Logistics, GLS, Hermes, Gebrüder Weiss, etc.

Même après avoir implémenté toutes les intégrations mentionnées ci-dessus, la question demeure :

Que faites-vous avec les entreprises de transport qui n'ont aucun système informatique ou portail, et encore moins une API pour accepter les commandes de transport ?

La solution la plus simple est d'envoyer un simple e-mail. Bien que cela puisse sembler simple, examinons plus en détail. La mise en place de la connexion technique à votre serveur de messagerie est une chose, mais qu'en est-il des contacts ? Normalement, différentes directions sont gérées par différentes personnes de contact, et les gens changent de poste. Ainsi, vous devriez construire une matrice de contacts assez complète dans votre ERP.

Alors, quelles sont les alternatives à la lutte contre les différentes API de transporteurs et protocoles EDI disparates ?

Une option à considérer est une API multi-transporteurs. Essentiellement, il s'agit d'un fournisseur de services qui a construit toutes les connexions avec les transporteurs, qu'il s'agisse d'API modernes, d'anciens protocoles EDI basés sur EDIFACT ou FORTRAS ou d'intégrations par e-mail, et les a rendues disponibles via sa propre API d'expédition standardisée. Au lieu d'implémenter diverses API de transporteurs et de les maintenir à jour, vous pouvez implémenter une seule norme d'API multi-transporteurs et déclencher toutes vos commandes de transport à travers elle.

Mais nous sommes allés encore plus loin.

Logiciel multi-transporteurs - améliorer vos transporteurs existants ?


Différentes entreprises de logistique offrent des niveaux de service variés. Certaines fournissent une API de réservation, d'autres non ; certaines offrent des capacités de suivi, tandis que d'autres en sont dépourvues. Chez Cargoson, nous avons implémenté toutes les fonctionnalités qui comblent les lacunes de chaque entreprise de transport.

Par exemple, lorsqu'un transporteur n'offre pas de réservation en ligne, nous fournissons un portail pour cela. S'ils n'ont pas de suivi, nous l'ajoutons. Nous avons des systèmes pour télécharger la preuve de livraison (POD) et d'autres documents, une API multi-transporteurs complète, des estimations d'ETA, des calculs de prix de transport, des statistiques de performance, et même des chiffres d'émissions de CO2 pour le transport. En gros, tout ce qu'un transporteur n'a pas, nous l'avons construit pour que vous n'ayez pas à vous soucier des différences de niveau de service ou informatiques entre vos transporteurs.


Égalisation des niveaux de service entre différents transporteurs - norme API d'expédition universelle
Égalisation des niveaux de service entre différents transporteurs - norme API d'expédition universelle




Découvrez comment Cargoson améliore vos transporteurs existants

Voici un exemple concret : Les grands acteurs comme FedEx, TNT et DHL Express proposent une API de tarification. Cela signifie que lorsque vous déclenchez une demande de prix depuis Cargoson, les prix sont directement extraits du système du transporteur. Cependant, dans les cas où une entreprise comme DSV ne fournit pas d'API de tarification, la liste de prix Excel ou PDF fournie par DSV est téléchargée dans Cargoson, et le calcul du prix est effectué au sein de notre système. Nous disposons d'un puissant moteur de téléchargement et de calcul des prix de fret pour cela. La même approche peut être appliquée à toutes les autres entreprises de transport et est également applicable à d'autres fonctionnalités.

Notre objectif est simple : vous offrir une expérience cohérente et de haute qualité avec tous les transporteurs, même s'ils ne commencent pas tous avec les mêmes capacités. Une norme API de transporteur universelle de facto et une plateforme multi-transporteurs en un.

Si vous recherchez une meilleure façon de gérer vos intégrations de transporteurs, Cargoson peut vous aider. Notre plateforme fournit une API de transport unique et standardisée qui vous connecte à tous vos transporteurs, quelles que soient leurs capacités individuelles. Cela signifie que vous pouvez accéder à tous vos services d'expédition via une interface unifiée, sans vous soucier des différences techniques sous-jacentes.

Vous voulez voir comment cela pourrait fonctionner pour votre entreprise ? Faisons un appel rapide pour discuter de votre configuration actuelle et de vos défis d'intégration spécifiques. Nous pouvons examiner quelques exemples concrets de la façon dont Cargoson a aidé des entreprises dans des cas similaires au vôtre :

Planifiez une consultation gratuite de 30 minutes