La douleur d'une migration TNT vers FedEx apparaît rarement dans le premier test de label. Elle arrive quand un ancien flux Express Web Services XML continue de nourrir le WMS, quand un nouveau flux FedEx REST alimente le support, et quand personne ne sait plus quel identifiant prouve l'expédition réelle.
Le risque n'est pas seulement technique. Un consignment TNT peut encore être connu par l'entrepôt, un shipment FedEx peut être visible côté portail, un tarif peut changer de logique, un tracking peut perdre sa correspondance, et une facture peut arriver sans que la finance sache relire l'historique.
Le signal faible se voit vite: deux outils affichent deux statuts, un vieux mapping XML reste branché sur un batch, une équipe support cherche encore le numéro TNT, ou un transporteur est remplacé dans le checkout sans que les règles de cut-off, de compte et de document aient été rejouées. Chaque symptôme crée une dette de preuve.
Contrairement à ce que l'on croit, une bonne intégration TNT FedEx ne consiste pas à remplacer un endpoint par un autre. Vous allez comprendre quoi inventorier, quoi mapper, quoi faire tourner en parallèle, quand bloquer une bascule, puis comment prouver qu'un colis historique reste lisible après passage aux APIs FedEx.
Dawap traite ce sujet comme une intégration API de migration reliée aux flux logistique et shipping. La page intégrateur TNT FedEx présente l'accompagnement possible pour relier un historique TNT XML, un OMS, un WMS, un TMS, une marketplace et les APIs FedEx sans perdre la continuité opérationnelle.
Pour qui la migration TNT vers FedEx devient critique
Cette migration devient critique pour les organisations qui ont automatisé TNT depuis longtemps: comptes historiques, labels imprimés dans un WMS, pricing calculé par ExpressConnect, tracking TNT exposé au support, exports finance, tableaux de bord transport et scripts internes écrits autour du vocabulaire TNT.
Le sujet devient encore plus sensible lorsque FedEx devient le flux cible pour les nouveaux départs. Les APIs FedEx modernes ne portent pas automatiquement les mêmes clés, les mêmes événements, les mêmes services ou les mêmes documents. Le SI doit donc créer une continuité explicite.
Le coût caché se loge dans la période de coexistence. Un colis parti en ancien flux doit rester traçable, une commande vendue avant bascule peut être remboursée après bascule, une preuve de livraison peut être demandée plusieurs semaines plus tard, et un contrôle finance peut arriver quand les équipes ont déjà oublié le mapping d'origine.
Le signal de priorité est simple: si un changement TNT vers FedEx peut modifier un service vendu, une promesse de délai, un numéro de suivi, un rapprochement facture, un dossier SAV ou un litige marketplace, la migration doit être pilotée comme une chaîne de preuve. Le transporteur change; le run ne doit pas devenir amnésique.
1. Inventorier les flux TNT XML encore vivants
Repérer les appels qui ne se voient plus
Les TNT Express Web Services peuvent couvrir shipping, pricing, tracking, routing labels ou lookup. Dans beaucoup de SI, ces appels ne sont plus documentés au même endroit que les outils modernes. Ils vivent dans un batch, un module WMS, un connecteur e-commerce ou un job d'export que personne ne touche tant qu'il fonctionne.
Le premier travail consiste à lister les consommateurs réels: checkout, OMS, WMS, TMS, support, finance, marketplace, portail client, outil de retours et scripts de rapprochement. Chaque consommateur peut dépendre d'un champ différent, même si tous parlent vaguement du même transporteur.
L'inventaire doit préciser l'endpoint, le compte TNT, le format XML, le type de réponse, les documents générés, les clés stockées, les erreurs connues, le propriétaire métier et la personne capable de couper le flux. Sans cette carte, la migration commence avec des angles morts. Il faut aussi identifier les exports indirects, car un fichier déposé chaque nuit peut continuer de nourrir une facturation ou un portail client longtemps après l'arrêt apparent du connecteur.
Un bon arbitrage consiste à ne pas migrer ce qui n'a pas été observé. Si un appel semble inutile mais produit encore une donnée finance ou support, le supprimer peut créer une rupture invisible pendant plusieurs semaines.
Distinguer historique, actif et transitoire
Tous les flux TNT ne méritent pas le même traitement. Certains doivent rester en lecture historique, certains doivent continuer jusqu'à une date de bascule, et certains doivent être remplacés par un flux FedEx REST avant toute nouvelle commande. Cette classification évite les coupures brutales.
Le statut d'un flux doit être visible: actif, en double-run, en lecture seule, en arrêt planifié, archivé ou supprimé. Une intégration ancienne sans statut explicite finit souvent par redevenir active au pire moment, parce qu'un job planifié la relance sans prévenir. Le statut doit donc être porté dans un registre partagé, pas seulement dans une tâche technique.
Le runbook doit aussi dire quoi faire pour une commande créée avant bascule mais livrée après bascule. Ce cas traverse les deux mondes: le commercial voit l'ancien service, l'entrepôt peut créer un nouveau shipment, et le support doit expliquer l'historique sans contradiction.
Par exemple, si 14 appels TNT XML restent actifs en 7 jours alors que le canal est censé utiliser FedEx REST, alors, en priorité, l'équipe doit isoler les consommateurs avant d'ouvrir un nouveau service. Ce seuil protège la marge, le délai et la charge support.
2. Mapper consignment TNT et shipment FedEx
Créer une table de correspondance lisible
La migration se joue dans les identifiants. Un flux TNT peut parler de consignment, de collection, de label et de tracking avec ses propres clés. FedEx expose ses comptes, shipments, tracking numbers, packages, documents et services. Le modèle interne doit relier ces objets sans les confondre.
La table de correspondance doit porter l'ancien identifiant TNT, le nouvel identifiant FedEx, la commande, le colis, le compte, le service, la date de création, la version du mapping, le canal et le statut de migration. Elle doit être consultable par le support, pas seulement par la technique. Elle doit aussi garder l'état de confiance du rapprochement: automatique, validé manuellement, incertain ou refusé, pour éviter de publier une correspondance encore fragile.
Le point délicat concerne les colis déjà partis. Il ne faut pas réécrire leur histoire. Un dossier TNT historique peut rester TNT dans la preuve, même si l'interface moderne affiche une lecture FedEx. La migration doit enrichir l'historique, pas le maquiller.
Un bon arbitrage consiste à refuser les conversions silencieuses. Si une clé TNT n'a pas d'équivalent FedEx certain, le dossier doit rester en état transitoire avec une action support claire. Une fausse correspondance est plus dangereuse qu'un trou assumé.
Normaliser sans effacer la nuance transporteur
Normaliser les statuts aide le support, mais une normalisation trop agressive détruit la preuve. Un statut TNT, un statut FedEx et un statut interne ne doivent pas être réduits trop vite à une seule phrase client. Il faut garder le code brut, la traduction et la décision métier.
La différence compte pendant les litiges. Un colis peut être en attente de collecte, déclaré, scanné, en transit, partiellement livré, en exception ou retourné. Si le vocabulaire TNT et le vocabulaire FedEx ne sont pas rapprochés avec méthode, le support répond avec une certitude qui n'existe pas.
Le mapping doit être versionné. Une règle valable pendant la première semaine de migration peut être corrigée plus tard après observation terrain. Si la version n'est pas stockée, rejouer un ancien dossier donnera une lecture différente de celle disponible le jour de l'incident.
Le test de recette doit reprendre un colis TNT ancien, un shipment FedEx récent et une commande transitoire. Si les trois dossiers affichent une source, une clé, une version et une action autorisée, la table de correspondance commence à tenir.
3. Comparer pricing TNT et rating FedEx sans surprise
Ne pas confondre prix historique et devis cible
Le pricing TNT et le rating FedEx ne doivent pas être comparés comme deux réponses identiques. Les comptes, services, options, adresses, dimensions, devises, taxes, surcharges, cut-offs et règles commerciales peuvent changer. Le connecteur doit conserver les hypothèses qui produisent chaque prix.
La période de transition doit donc garder deux lectures: le prix TNT utilisé pour les flux encore actifs et le devis FedEx destiné aux nouveaux départs. Mélanger les deux peut créer un checkout incohérent, une marge fausse ou une facture impossible à expliquer. Cette séparation doit rester visible dans les exports, car la finance lit souvent les écarts en fin de mois, quand le contexte opérationnel du départ n'est plus frais dans les mémoires.
La finance doit pouvoir relire l'origine d'un écart: ancien compte, nouveau compte, service remplacé, poids requalifié, adresse modifiée, surcharge différente ou changement de promesse. Cette lecture doit être construite avant le premier rapprochement mensuel.
Le bon arbitrage consiste à ne pas vendre une économie tant que le dossier n'a pas été comparé en conditions réelles. Un tarif FedEx plus favorable sur un scénario peut être moins bon sur une destination, un poids ou une option documentaire.
Tester les paniers qui déforment la marge
La recette doit viser les profils qui coûtent vraiment: colis volumineux, multi-colis, service express international, adresse résidentielle, pickup tardif, retour, document douane, destination sensible et commande marketplace. Le cas moyen ne suffit pas à prouver la bascule.
Chaque scénario doit produire une comparaison claire: prix TNT, devis FedEx, service retenu, cause d'écart, décision de vente, message client et impact marge. Sans cette grille, l'équipe verra seulement un chiffre différent et cherchera la cause trop tard.
Par exemple, si 9 paniers sur 60 changent de marge après simulation en 7 jours, alors, en priorité, il faut bloquer la bascule du canal concerné et corriger les règles de rating. Ce seuil relie recette, marge et décision de lancement.
Une migration propre peut accepter certains écarts. Le sujet n'est pas d'obtenir le même prix partout, mais de savoir quel écart est attendu, quel écart est commercialement accepté et quel écart impose une revue avant publication.
4. Migrer tracking, événements et preuves support
Garder la chronologie avant et après bascule
Le tracking est souvent le point où la migration se voit le plus. Un client ne se soucie pas du passage XML vers REST, mais il veut savoir où est son colis. Le support, lui, doit savoir si le numéro vient de TNT, de FedEx ou d'un dossier en transition.
La chronologie doit garder les événements bruts, leur source, leur horodatage, le statut métier, le colis concerné et la règle de publication client. Écraser un ancien événement TNT avec une traduction FedEx trop large peut rendre un litige impossible à relire.
Le connecteur doit aussi distinguer le message client et la preuve interne. Une interface client peut afficher une phrase simple, tandis que le portail support conserve la source, le code, le mapping, la preuve de livraison et la prochaine action autorisée.
Si l'équipe ne retrouve pas l'événement d'origine en moins de 10 minutes, le problème n'est pas la couleur du tracking. Le problème est la perte de granularité entre l'ancien flux TNT, le nouveau flux FedEx et la lecture métier.
Préserver les preuves de livraison et les dossiers anciens
Les preuves de livraison, factures, documents d'expédition, labels et historiques de tracking doivent survivre à la bascule. Un client peut contester après migration un colis créé avant migration. Le support doit retrouver le dossier original, même si le nouveau flux est déjà en production.
La conservation doit préciser où vivent les preuves, combien de temps elles restent accessibles, qui peut les consulter, quelle donnée est masquée et quel identifiant permet de les retrouver. Ces choix paraissent administratifs, mais ils évitent de dépendre d'un ancien outil ou d'un accès personnel.
Le dossier support doit donc afficher l'origine de la preuve: TNT historique, FedEx cible, import manuel, rapprochement finance ou correction technique. Cette origine aide à expliquer pourquoi deux dossiers proches ne se lisent pas exactement de la même manière. Elle aide aussi à décider si l'équipe doit ouvrir un litige transporteur, corriger un mapping interne ou expliquer au client qu'il consulte un dossier antérieur à la bascule.
Par exemple, si 8 preuves de livraison historiques restent introuvables en 7 jours de recette, alors, en priorité, la bascule doit attendre l'archivage et la table de recherche. Ce seuil protège le support, la conformité et la confiance client.
5. Créer un double-run avant la bascule
Comparer sans créer deux expéditions réelles
Le double-run ne doit pas créer deux colis transporteurs. Il doit comparer les décisions: ancien flux TNT, nouveau flux FedEx, tarif attendu, service choisi, statut simulé, document requis, pickup possible et message client. Le but est de prouver la cohérence avant de couper l'ancien chemin.
Cette phase peut se faire avec des simulations, des appels non producteurs ou des jeux de données anonymisés selon le périmètre disponible. Ce qui compte, c'est de mesurer les écarts métier, pas de multiplier les appels réels au transporteur.
Le double-run doit produire des décisions visibles. Un écart peut être accepté, corrigé, bloqué, surveillé ou laissé en revue. S'il produit seulement un rapport technique, il ne prépare pas le support au jour de bascule. Chaque écart doit donc ressortir avec une cause, un owner, une prochaine action et un effet attendu sur prix, délai, tracking ou preuve.
La règle d'or consiste à ne jamais comparer uniquement les statuts nominaux. Il faut rejouer les adresses difficiles, les retours, les colis volumineux, les erreurs XML, les timeouts REST, les documents manquants et les dossiers historiques.
Définir les seuils de sortie du double-run
Les seuils de sortie doivent être décidés avec les équipes métier. Par exemple, la bascule peut être autorisée si le taux d'écart non expliqué reste sous un seuil, si le support retrouve les preuves, si la finance sait rapprocher les prix et si le WMS sait imprimer sans revenir à l'ancien module.
Les seuils doivent aussi nommer les blocages absolus: double expédition possible, tracking non retrouvable, document introuvable, prix sans cause d'écart, pickup non maîtrisé, retour sans lien d'origine ou compte mal configuré. Ces cas ne doivent pas passer par optimisme.
Le mode contrôlé doit permettre une bascule progressive par pays, canal, entrepôt, service ou catégorie de colis. Une migration TNT FedEx réussie ouvre les périmètres qui tiennent déjà leurs preuves, puis garde les autres en observation.
Si 5 dossiers critiques restent sans cause d'écart en 7 jours, alors, en priorité, il faut prolonger le double-run plutôt que forcer la date. Ce seuil protège le lancement, la marge, le support et la confiance des équipes terrain.
6. Erreurs fréquentes dans une migration TNT FedEx
Les pièges qui cassent la continuité
- Remplacer un endpoint TNT par un endpoint FedEx sans table de correspondance consignment, shipment et colis.
- Couper l'ancien tracking avant d'avoir archivé les preuves et les événements encore utiles au support.
- Comparer les prix sans conserver compte, service, adresse, dimensions, pickup, devise et règle commerciale.
- Faire un double-run qui mesure seulement le cas nominal et ignore erreurs, retours, documents et dossiers anciens.
- Ne pas nommer le propriétaire des écarts, puis laisser support, finance, WMS et technique se renvoyer l'incident.
Ces erreurs sont fréquentes parce que la migration peut sembler réussie pendant quelques jours. Les nouveaux labels sortent, les commandes partent, les dashboards sont verts, et les problèmes n'apparaissent qu'au moment d'un litige ou d'un rapprochement facture.
L'erreur de fond consiste à confondre migration technique et continuité opérationnelle. Un appel REST moderne ne garantit pas que l'historique TNT reste lisible, que le support sait répondre, ou que la finance retrouve la cause d'un écart.
La correction consiste à écrire les décisions avant de migrer: conserver, convertir, simuler, bloquer, archiver, reprendre, publier ou supprimer. Chaque action doit avoir un owner, une preuve, un seuil et une date de revue.
Le pilotage doit aussi distinguer incident de migration et incident transport. Un retard FedEx réel ne se corrige pas comme une clé TNT mal rapprochée. Si cette différence n'est pas visible, les équipes ouvrent des tickets techniques pour des problèmes d'exploitation et perdent le temps utile de résolution.
Garder certains flux en lecture seule
Certains flux ne doivent pas être coupés trop vite. Un ancien tracking, une preuve de livraison, un document d'expédition, une facture ou un export d'audit peut rester indispensable en lecture seule même si aucune nouvelle commande ne passe par TNT.
Cette lecture seule doit être contrôlée. Elle doit indiquer que le flux n'accepte plus de nouvelles expéditions, mais reste disponible pour recherche, litige, support et finance. Sans ce statut, l'équipe risque de relancer un ancien chemin par erreur.
Le mode lecture seule doit avoir une date de revue et une condition de retrait. On peut fermer un flux quand les dossiers historiques sont archivés, que les preuves sont accessibles ailleurs et que les consommateurs restants ont été confirmés.
Si un flux TNT en lecture seule reçoit encore 20 appels en 7 jours, alors, en priorité, il faut identifier le consommateur fantôme avant de supprimer l'accès. Ce seuil évite une rupture silencieuse après la bascule.
7. Scénario terrain: tracking TNT introuvable après bascule
Rejouer le dossier avant le go-live
Prenons un cas courant: une commande B2B part avec un ancien flux TNT quelques jours avant bascule. Le client contacte le support après bascule, alors que l'interface principale affiche désormais les nouveaux flux FedEx. Le conseiller cherche le tracking dans le mauvais système.
Si la correspondance n'existe pas, le ticket devient une enquête. L'entrepôt confirme le départ, la finance voit une ligne transport, le client demande une preuve, et la technique doit relire les anciens logs XML pour retrouver le consignment.
Le scénario de recette doit produire un résultat simple: le support saisit l'ancien numéro, retrouve la commande, voit la source TNT, obtient la preuve disponible, comprend pourquoi le dossier n'est pas FedEx REST et sait quelle réponse donner au client.
Cette expérience protège la bascule. Le client ne doit pas payer le changement d'architecture par une perte de suivi. Le nouveau portail peut devenir la porte d'entrée unique, mais il doit savoir reconnaître les dossiers historiques.
Décider ce qui bloque le lancement
Avant le go-live, il faut écrire les situations qui bloquent vraiment la bascule. Un tracking historique introuvable, un prix non rapproché, un document absent ou un compte mal configuré doivent rester bloquants si le support en dépend.
Un seuil de sortie peut être strict: aucun flux actif sans owner, aucun dossier historique sans recherche, aucun mapping sans version, aucun prix sans hypothèses, aucun tracking sans source et aucun rollback sans procédure écrite.
Le scénario doit être joué avec au moins trois profils: commande historique TNT, nouvelle commande FedEx et commande transitoire créée avant bascule mais livrée après. Si l'équipe ne sait pas expliquer ces trois profils, le lancement doit rester limité.
Le bon lancement est parfois partiel. Il vaut mieux basculer un entrepôt, un pays ou un canal prouvé que couper tous les flux en une nuit et découvrir ensuite que le support n'a plus la mémoire des colis.
8. Plan d'action TNT FedEx avant go-live
Cadrer objets, responsabilités et preuves
La première étape consiste à lister les objets critiques: compte TNT, compte FedEx, consignment, shipment, colis, label, pickup, tarif, document, tracking, preuve, retour, facture et ticket support. Pour chacun, il faut définir la source de vérité et l'owner.
La matrice doit préciser la visibilité. Un objet peut être technique, support, finance, entrepôt, marketplace ou client. Une donnée utilisée par la finance ne doit pas disparaître parce qu'elle n'est pas utile à l'impression du label.
Le livrable doit rester exploitable pendant l'incident: ancien identifiant, nouvel identifiant, source, statut, version de mapping, preuve, action autorisée et propriétaire. Une page lisible vaut mieux qu'une documentation exhaustive que personne ne consulte sous pression.
La recette doit vérifier les écrans réels. Une correspondance visible dans une table technique peut rester invisible dans le portail support ou dans l'outil finance. Le go-live doit être jugé sur la lecture des équipes, pas seulement sur la présence des données.
- D'abord, à valider: tous les flux TNT actifs ont un owner, un consommateur et une règle de retrait.
- Ensuite, à bloquer: tout nouveau flux FedEx qui ne relie pas shipment, colis, tracking, document et preuve.
- Puis, à corriger: les écarts de prix, statut ou tracking qui ne trouvent pas leur cause en moins de 10 minutes.
- En priorité, à différer: les pays, canaux ou options qui n'améliorent ni traçabilité, ni marge, ni charge support.
Tester les scénarios qui coûtent vraiment
La recette doit couvrir les cas coûteux: tracking historique, retour après bascule, prix différent, double label potentiel, document introuvable, pickup modifié, compte refusé, multi-colis, timeout REST et ancien batch qui continue d'appeler TNT.
La mise en œuvre doit documenter les entrées, sorties, contrats de statut, versions de mapping, règles de retry, seuils de rollback, files de quarantaine et procédures support. Sinon, l'alerte indique une erreur sans dire quelle décision prendre.
Le test doit également inclure une coupure volontaire: ancien flux indisponible, nouveau flux refusé, preuve absente ou mapping incomplet. Une migration qui ne sait pas ralentir proprement pendant la recette ne saura pas protéger les équipes quand l'incident arrivera en production.
Par exemple, si 30 dossiers de recette révèlent 4 trackers historiques introuvables et 3 prix non rapprochés en 7 jours, alors, en priorité, il faut corriger recherche et pricing avant de couper TNT. Ce seuil relie preuve, marge et décision de bascule.
- À valider: historique TNT, nouveau FedEx, transitoire, retour, document, facture, multi-colis et exception tracking.
- À refuser: toute recette qui prouve le nouveau label sans prouver la continuité des dossiers anciens.
- À corriger: les écrans où support et finance ne retrouvent pas source, preuve et cause sans solliciter la technique.
Préparer rollback et mode contrôlé
Le rollback doit être préparé avant la bascule. Il peut réactiver temporairement un flux TNT, bloquer un canal FedEx, placer les commandes en revue, suspendre une destination, revenir à un ancien module d'impression ou geler une règle de pricing.
Les seuils doivent être écrits avec le métier. Si plus de 2 % des commandes perdent leur tracking en 7 jours, si trois doubles labels apparaissent en 24 heures, ou si la finance ne rapproche pas les prix en fin de journée, le périmètre doit revenir au mode contrôlé.
La file de quarantaine doit garder l'entrée initiale, l'ancien identifiant, le nouvel identifiant, la version de mapping, l'erreur, le seuil franchi, l'action autorisée et le runbook. Cette instrumentation transforme un incident de migration en décision opérationnelle.
Le test de bascule doit être joué avec support, finance, logistique et technique. Si ces équipes savent retrouver un ancien tracking, expliquer un prix, bloquer un canal et relancer un flux sans improviser, le mode contrôlé protège vraiment le lancement.
9. Indicateurs des 30 premiers jours
Mesurer la continuité plus que le volume
Les premiers indicateurs doivent mesurer la continuité entre ancien TNT et nouveau FedEx. Un volume de labels FedEx peut monter rapidement tout en masquant des dossiers historiques introuvables, des prix non rapprochés ou des retours mal reliés.
Il faut suivre les appels TNT restants, les commandes en double-run, les mappings sans équivalence, les trackers non retrouvés, les documents introuvables, les prix divergents, les retours transitoires, les doubles labels évités et les tickets sans propriétaire.
La lecture quotidienne doit produire des décisions. Une hausse des appels TNT restants peut révéler un consommateur caché, un pic de prix divergents peut bloquer un canal, et des preuves manquantes peuvent prolonger l'archivage avant suppression.
- Taux de commandes dont ancien identifiant, nouveau shipment, colis, document et tracking sont rapprochés par canal.
- Délai entre commande, label, premier événement, preuve, facture et résolution support pour dossiers transitoires.
- Volume d'appels TNT résiduels, mappings incomplets, prix divergents, preuves introuvables et rollbacks par owner.
Si 15 dossiers en 7 jours demandent une recherche manuelle entre TNT et FedEx, alors, en priorité, l'équipe doit renforcer la table de correspondance avant d'ouvrir un nouveau périmètre. Ce seuil relie délai, support et décision de migration.
Comparer promesse vendue et preuve disponible
Les 30 premiers jours doivent comparer ce qui a été vendu au client, ce qui a été créé dans le transporteur et ce qui est encore prouvable dans les outils internes. Ces trois lectures peuvent diverger pendant la migration.
La comparaison doit être faite par pays, entrepôt, canal, compte, service et date de commande. Un écart concentré sur les commandes créées avant bascule peut révéler un problème d'archive; un écart concentré sur un pays peut révéler une règle de service mal transposée.
Le signal faible devient visible quand les mêmes dossiers reviennent en support sans erreur technique claire. Dans ce cas, la priorité n'est pas un retry supplémentaire, mais une preuve plus lisible et une consigne support plus directe.
Si 10 commandes transitoires par semaine perdent leur preuve client, alors le périmètre doit revenir au mode contrôlé sur le canal concerné. Ce seuil protège la confiance et évite que la migration soit perçue comme une dégradation de service.
Transformer les seuils en priorités
Les seuils doivent guider les corrections. Si les appels TNT résiduels dominent, la priorité est l'inventaire. Si les écarts de prix dominent, la priorité est le rating. Si les preuves manquent, la priorité est l'archivage et la recherche support.
Si les erreurs viennent d'un ancien batch, il faut le couper ou l'isoler. Si elles viennent d'un mapping incomplet, il faut versionner la règle. Si elles viennent d'une mauvaise lecture support, il faut changer l'écran et la consigne, pas seulement le code.
- À corriger avant extension: les dossiers où source, identifiant, preuve et action support ne sont pas visibles.
- À bloquer immédiatement: les cas où l'ancien et le nouveau flux peuvent créer deux expéditions réelles.
- À différer sans regret: les services qui augmentent la couverture mais diminuent la preuve opérationnelle.
Après un mois, l'équipe doit pouvoir dire quels flux TNT sont fermés, lesquels restent en lecture seule, quels flux FedEx sont stables et quelles exceptions restent en mode contrôlé. Cette réponse vaut plus qu'un simple compteur de labels.
Le dernier arbitrage concerne la conservation: durée d'archive, droits d'accès, purge, justificatifs, journaux de consultation et documentation de version. Ces éléments évitent qu'un dossier ancien dépende d'un accès TNT oublié ou d'une capture d'écran isolée.
Questions fréquentes sur TNT FedEx
Existe-t-il encore des flux API TNT à traiter ? Oui, des organisations peuvent encore porter des intégrations TNT Express Web Services XML pour shipping, pricing ou tracking, tout en préparant une migration vers les APIs FedEx REST selon leur pays, leur compte et leur contexte opérationnel.
Pourquoi ne pas remplacer directement TNT par FedEx ? Parce que les identifiants, les statuts, les documents, les tarifs, les cut-offs, les comptes et les preuves support ne se transposent pas automatiquement. Une bascule directe peut casser la traçabilité.
Dawap peut-il accompagner une migration TNT vers FedEx API ? Oui. Dawap accompagne l'audit des flux TNT, le mapping vers FedEx APIs, le double-run, les tests de non-régression, l'idempotence, la supervision, la bascule progressive et la passation support.
Guides complémentaires pour la migration TNT
La ressource API logistique et shipping prolonge ce sujet avec une lecture plus large des flux transport, des preuves de run et des responsabilités entre boutique, entrepôt, transporteur, finance et support.
La ressource WMS, TMS et API logistique aide à relier la migration TNT FedEx aux contraintes d'entrepôt, d'impression, de colisage, de tracking, de pickup et de source de vérité quand plusieurs outils créent ou lisent la même expédition.
La ressource versioning API complète la réflexion sur les contrats transitoires, tandis que mapping de données API détaille la manière de garder les identifiants, statuts et référentiels lisibles pendant la bascule.
La ressource retries, backoff et circuit breaker API devient utile dès qu'une migration produit des erreurs transitoires, des appels hérités ou des reprises qui ne doivent pas recréer un shipment déjà accepté. La landing API logistique et shipping relie ce chantier à l'offre métier correspondante, tandis que la page intégrateur TNT FedEx précise le service proposé pour auditer l'existant, préparer la migration, sécuriser le double-run et accompagner la passation support.
Conclusion: migrer TNT sans trou de preuve
Une migration TNT FedEx réussie ne se mesure pas au premier label FedEx généré. Elle se mesure à la capacité de l'équipe à retrouver un ancien consignment, expliquer un nouveau shipment, rapprocher un prix, relire un tracking et produire une preuve support sans fouiller les anciens logs.
L'ordre de travail reste clair: inventorier les flux XML, classer actif et historique, mapper les identifiants, comparer pricing et rating, préserver les preuves, créer un double-run, définir les seuils de sortie, puis basculer par périmètre maîtrisé.
La meilleure bascule est souvent progressive. Un pays, un entrepôt ou un canal peut passer en FedEx REST pendant qu'un ancien flux TNT reste en lecture seule pour les litiges et la finance. Cette discipline évite de confondre modernisation technique et perte de mémoire métier, surtout quand les commandes ouvertes traversent encore les deux modèles de preuve. Le support doit pouvoir relire cette traversée sans reconstituer l'histoire depuis les logs.
Si vous devez faire évoluer un historique TNT vers les APIs FedEx sans perdre la mémoire opérationnelle de vos colis, notre accompagnement en intégration API peut cadrer l'audit, le mapping, les tests, l'observabilité et la bascule pour garder une preuve fiable de l'ancien flux au nouveau run.
