API de suivi ou API d'expédition : de laquelle votre stack e-commerce a-t-elle besoin (ou des deux) ?

Utilisez une API d’expédition lorsque votre infrastructure e-commerce doit créer des expéditions et générer des étiquettes d’expédition. Utilisez une API de suivi lorsqu’elle doit suivre les expéditions après leur envoi et transformer les mises à jour des transporteurs en informations opérationnelles ou destinées aux clients. Vous avez besoin des deux fonctionnalités si votre logiciel doit gérer la création des expéditions et la visibilité après l’achat, mais vous n’avez pas nécessairement besoin de deux fournisseurs ni de deux intégrations distinctes.

La décision revient à la personne responsable de votre architecture de gestion des expéditions : généralement un responsable des opérations e-commerce travaillant avec une équipe d’ingénierie. Commencez par identifier ce que votre boutique, votre entrepôt ou votre partenaire logistique prend déjà en charge. L’ajout d’une autre API doit combler une lacune précise, et non dupliquer un flux de travail qui fonctionne déjà.

Quelle est la différence entre une API de suivi et une API d’expédition ?

La distinction concerne principalement la fonction remplie par chaque API, et non une frontière stricte entre les catégories de produits. Une plateforme d’expédition peut inclure des points de terminaison de suivi, tandis qu’un service de suivi peut fournir des outils pour les notifications et les mises à jour de livraison destinées aux clients. Évaluez les points de terminaison documentés et le comportement des événements plutôt que de vous fier au nom du produit.

La documentation des transporteurs illustre cette séparation. FedEx documente la création d’expéditions dans sa documentation de l’API Ship et les fonctionnalités de suivi dans sa documentation de l’API de suivi. Il s’agit d’exemples de responsabilités techniques différentes, et non d’une recommandation de choisir un transporteur particulier.

Créer une expédition n’est pas la même chose que suivre son acheminement

Une réponse réussie à une demande de création d’expédition indique à votre logiciel qu’une demande d’expédition a été traitée. Elle ne prouve pas que le transporteur a physiquement reçu le colis. De même, un numéro de suivi peut exister avant que le déplacement n’apparaisse dans l’historique de suivi.

Votre système de gestion des commandes doit donc distinguer la création de l’étiquette, la remise au transporteur par l’entrepôt, l’acceptation par le transporteur et la livraison. Traiter tous ces éléments comme un seul événement « expédié » peut entraîner des messages prématurés aux clients et dissimuler des colis qui n’ont pas réellement quitté l’entrepôt.

Choisissez la fonctionnalité qui résout votre goulot d’étranglement actuel

Choisissez une API d’expédition lorsque l’envoi est l’élément manquant

Une API d’expédition est le point de départ approprié lorsque votre propre application doit transformer les données de commande en expédition. Par exemple, une équipe d’entrepôt peut recopier manuellement les adresses dans les portails des transporteurs, ou un système personnalisé de gestion des commandes peut être incapable de générer des étiquettes.

Avant de choisir une intégration, définissez le flux réel d’expédition. Avez-vous seulement besoin de créer des expéditions, ou également de récupérer les tarifs, d’annuler des expéditions, de demander des enlèvements, de générer des documents douaniers ou de gérer les opérations de fin de journée ? Ces fonctions peuvent correspondre à des API distinctes, dépendre du transporteur ou nécessiter des autorisations supplémentaires sur le compte. Ne supposez pas qu’un produit appelé « API d’expédition » inclut toutes les opérations d’expédition.

Pas idéale comme seule solution : une intégration de création d’étiquettes qui oblige votre équipe du service client à consulter les sites individuels des transporteurs. Elle peut résoudre l’envoi tout en laissant la visibilité sur la livraison largement inchangée.

Choisissez une API de suivi lorsque la création des expéditions fonctionne déjà

Une API de suivi est plus adaptée lorsque les étiquettes sont déjà créées par votre système de gestion d’entrepôt, votre partenaire logistique, votre marketplace ou une intégration d’expédition existante, mais que les informations de livraison sont fragmentées.

Dans cette situation, remplacer le flux de création des étiquettes peut ajouter un travail de migration sans résoudre le problème central. Connectez plutôt les numéros de suivi générés en amont à une couche de visibilité que votre système de gestion des commandes, vos outils d’assistance et vos communications clients pourront utiliser.

Dans cette catégorie, 17TRACK Tracking API constitue une option d’intégration pertinente. Sa documentation officielle de l’API décrit l’enregistrement des numéros de suivi et les flux de données de suivi, notamment les notifications push. Évaluez ces flux en fonction des transporteurs, des types d’expédition et de l’architecture de votre application. Il s’agit d’une considération relative à la couche de suivi, et non d’une preuve que le service remplace une intégration de génération d’étiquettes.

Pas idéale comme seule solution : une API de suivi lorsque votre logiciel ne dispose toujours d’aucun moyen de créer les expéditions dont il est responsable. La visibilité sur le suivi ne résout pas l’absence d’exécution de l’expédition.

Utilisez les deux lorsque votre application gère l’envoi et la visibilité sur la livraison

Les deux fonctionnalités sont appropriées lorsque votre infrastructure doit générer des étiquettes, puis maintenir une vue fiable de la progression des expéditions. Elles peuvent provenir d’une seule plateforme, de services distincts ou d’une combinaison d’intégrations de transporteurs et d’une couche de suivi.

Privilégiez une seule intégration lorsque ses fonctions d’expédition et de suivi répondent à vos exigences documentées sans imposer de compromis inutiles. Envisagez des intégrations distinctes lorsqu’un flux d’expédition existant mérite d’être conservé ou lorsque les exigences de suivi diffèrent sensiblement de ce que ce flux fournit. Un fournisseur de suivi distinct n’est pas automatiquement meilleur ; il doit justifier l’intégration, la facturation et la responsabilité opérationnelle supplémentaires.

Comment les deux API s’intègrent dans une infrastructure e-commerce

Une conception pratique conserve la commande, l’expédition et l’événement de suivi sous forme d’enregistrements distincts. Une commande peut donner lieu à plusieurs colis, et chaque colis peut avoir son propre historique de suivi. Le statut de commande présenté au client doit être dérivé de ces enregistrements d’expédition plutôt que de les remplacer.

1. La commande est prête à être traitée. La boutique ou le système de gestion des commandes envoie les données de traitement requises à l’entrepôt responsable.
2. Le flux d’expédition crée l’expédition. L’application enregistre l’identifiant d’expédition, le numéro de suivi, le transporteur, le service et la référence de l’étiquette renvoyés.
3. L’entrepôt effectue la remise. La confirmation de l’entrepôt et l’acceptation par le transporteur restent des événements distincts.
4. Le flux de suivi commence. Votre application enregistre ou transmet le numéro de suivi conformément aux exigences de l’intégration sélectionnée.
5. Les mises à jour de suivi parviennent à votre application. Les webhooks, l’interrogation périodique ou une combinaison prise en charge alimentent l’enregistrement d’expédition.
6. Les règles métier déterminent la suite. Votre système met à jour le statut visible par le client, crée une tâche opérationnelle ou envoie un message lorsque les conditions pertinentes sont réunies.

Par exemple, un commerçant utilisant un entrepôt logistique tiers peut n’avoir besoin que des étapes quatre à six dans son propre logiciel. L’entrepôt gère déjà la création des expéditions. Un commerçant exploitant son propre entrepôt peut avoir besoin du flux complet.

Désignez un responsable pour chaque action en aval

Si les deux intégrations fournissent des mises à jour de suivi, désignez le système qui contrôle les notifications clients et le statut d’expédition affiché dans votre boutique. Sinon, les clients peuvent recevoir des messages en double ou voir des statuts de livraison contradictoires.

Vous pouvez conserver les données secondaires à des fins d’analyse sans autoriser chaque source à déclencher un e-mail. Conservez l’événement original du transporteur avec votre correspondance de statuts internes afin que le personnel d’assistance puisse comprendre pourquoi le système a classé une expédition d’une manière donnée.

Comparez l’adéquation opérationnelle, pas les intitulés des fonctionnalités

Vérifiez les transporteurs et les services que vous utilisez réellement

La prise en charge des transporteurs ne se résume pas à une question de oui ou de non. Un service peut prendre en charge le suivi d’un transporteur sans prendre en charge la création d’étiquettes pour ce même transporteur. La création d’étiquettes peut également dépendre du pays d’origine, de la configuration du compte transporteur ou de l’éligibilité du service.

Établissez une liste de tests à partir de vos itinéraires d’expédition réels. Incluez les colis nationaux, les expéditions internationales et tout transfert entre partenaires de transport. Confirmez l’opération requise pour chacun : créer une expédition, la suivre ou les deux. Une déclaration de couverture étendue est moins utile que des tests réussis sur les services dont votre entreprise dépend.

Examinez la signification des événements et l’exhaustivité des données

Pour le suivi, testez ce qui se passe avant le premier scan, pendant une exception de livraison, après une tentative de livraison infructueuse et au moment de la livraison. Vérifiez si les horodatages incluent les informations de fuseau horaire et si les descriptions originales du transporteur restent disponibles.

N’interprétez pas un statut normalisé comme la garantie de données identiques pour chaque transporteur. Les dates de livraison estimées, les détails de localisation et les informations de preuve de livraison peuvent dépendre du transporteur et de l’expédition concernés. Déterminez le comportement de votre interface lorsque ces champs sont absents.

Vérifiez la récupération après incident des deux côtés

Pour l’expédition, un délai d’attente pendant la création d’une expédition mérite une attention particulière : la demande peut avoir abouti même si votre application n’a pas reçu la réponse. Vérifiez les mécanismes pris en charge par le fournisseur pour éviter les doublons et effectuer les rapprochements avant de relancer aveuglément.

Pour le suivi, testez les notifications en double, les événements retardés, l’échec de livraison des webhooks et les pannes temporaires des points de terminaison. Confirmez l’authentification, le comportement des nouvelles tentatives et les options de récupération dans la documentation concernée. Concevez le traitement des événements de manière à ce que la relecture d’une mise à jour n’envoie pas à nouveau la même notification au client.

Comparez le coût total d’exploitation sans supposer un modèle tarifaire

Distinguisez les frais d’API des frais d’affranchissement et des frais liés au compte transporteur. Les services d’expédition et de suivi peuvent utiliser des unités de facturation différentes, et une plateforme combinée peut regrouper les fonctionnalités autrement. Demandez un devis ou consultez le forfait applicable au flux exact que vous prévoyez d’exécuter.

Demandez comment l’utilisation facturable est définie, si les demandes infructueuses sont comptabilisées, comment sont traitées les soumissions de suivi répétées et ce qui se passe lorsque l’utilisation dépasse un quota. Incluez la maintenance technique, l’effort d’assistance et le coût nécessaire pour maintenir la cohérence de deux intégrations. Sans composition définie des expéditions et sans conditions commerciales actuelles, déclarer une catégorie moins chère serait trompeur.

Examinez la sécurité et la conservation des données

Les intégrations d’expédition peuvent traiter les adresses des destinataires et les informations douanières. Les intégrations de suivi peuvent également traiter les identifiants d’expédition et les données clients associées. Confirmez les champs requis, limitez les identifiants aux accès nécessaires et gardez les secrets hors du code exécuté côté navigateur.

Examinez la conservation, la suppression et les contrôles d’accès au regard de vos exigences métier. Une intégration pratique ne devrait pas nécessiter l’envoi d’informations client dont le flux n’a pas besoin.

Un plan de validation pratique avant de vous engager

Réalisez une preuve de concept à l’aide d’expéditions représentatives plutôt que d’un seul exemple réussi provenant d’un guide de démarrage rapide. Définissez les critères d’acceptation avec les équipes des opérations, de l’ingénierie et du service client.

• Expédition : générez les formats d’étiquettes requis et confirmez que l’équipement de l’entrepôt peut les utiliser.
• Correspondance des commandes : testez les expéditions fractionnées, les colis multiples et les expéditions de remplacement sans perdre l’historique original.
• Suivi : vérifiez les séquences réelles d’événements pour les transporteurs et les itinéraires importants pour votre entreprise.
• Exceptions : vérifiez qu’un problème de livraison nécessitant une action parvient à la bonne équipe sans considérer automatiquement chaque scan inhabituel comme un échec.
• Récupération : interrompez une demande ou un point de terminaison webhook et démontrez comment l’application rapproche les informations manquantes.
• Communications : confirmez que seul le système désigné envoie chaque notification client.
• Adéquation commerciale : estimez les frais à partir de votre utilisation prévue et des définitions de facturation confirmées par le fournisseur.

Règle de décision : achetez d’abord la fonctionnalité manquante. Si l’envoi fonctionne déjà, évaluez une intégration de suivi sans reconstruire le traitement des expéditions. Si la création d’étiquettes est absente, résolvez d’abord l’exécution des expéditions. Si votre application gère tout le cycle de vie de l’expédition, validez les deux fonctionnalités et choisissez si une architecture combinée ou séparée est plus facile à exploiter pour votre équipe.

FAQ

Une API d’expédition inclut-elle toujours le suivi ?

Non. Certains services incluent les deux fonctionnalités, tandis que d’autres les exposent via des points de terminaison, des produits ou des forfaits distincts. Même lorsque le suivi est inclus, vérifiez le niveau de détail des événements, le mode de transmission des mises à jour, la prise en charge des transporteurs et les conditions d’utilisation avant de le considérer comme votre solution de suivi après achat.

Puis-je suivre des colis dont les étiquettes ont été créées par un partenaire logistique ?

Potentiellement, oui. Votre application a besoin des identifiants requis par l’intégration de suivi, généralement le numéro de suivi et, lorsque cela est nécessaire, un identifiant de transporteur ou des informations de vérification supplémentaires. Confirmez la prise en charge des transporteurs du partenaire et assurez-vous que les numéros de suivi sont transmis de manière fiable à votre système.

Une API de suivi permettra-t-elle aux scans du transporteur d’avoir lieu plus tôt ?

Elle ne peut pas créer de scans physiques chez le transporteur. Elle peut aider votre application à récupérer, organiser et distribuer les informations rendues disponibles par ses sources de suivi. Évaluez le comportement des mises à jour avec des expéditions réelles plutôt que de supposer qu’une API garantit une visibilité immédiate sur chaque déplacement.

Ai-je besoin de deux fournisseurs d’API pour utiliser les deux fonctionnalités ?

Non. Vous avez besoin des deux fonctions, pas nécessairement de deux fournisseurs. Utilisez un seul fournisseur lorsqu’il répond à vos exigences d’expédition et de suivi. Séparez-les lorsque cela permet de préserver un flux de travail fonctionnel ou de satisfaire une exigence précise que l’option combinée ne couvre pas.

Une API de suivi peut-elle remplacer un système de gestion des commandes ?

Non. Les données de suivi constituent une entrée du système de gestion des commandes, et non un substitut à l’allocation des stocks, aux décisions de traitement, à la gestion des paiements ou aux enregistrements de commandes. Votre application doit toujours associer chaque expédition à la bonne commande et décider de l’impact des événements d’expédition sur les flux métier.

Sources

• Documentation de l’API FedEx Ship — référence pour la création d’expéditions, les étiquettes et les exigences des flux d’expédition.
• Documentation de l’API de suivi FedEx — référence pour les demandes de suivi et les informations sur le statut des expéditions.
• 17TRACK Tracking API — référence officielle du produit pour la catégorie des intégrations de suivi.
• Documentation de l’API 17TRACK — référence pour l’enregistrement du suivi, les données de suivi et l’intégration des notifications push.