Commandes en double dues aux nouvelles tentatives d'API : comment les doubles expéditions se produisent et comment les arrêter

Je vais vous dire quelque chose. Quinze ans derrière le volant, et j'ai vu bien des choses étranges sur la route. Mais il y a un genre d'étrangeté qui me fait toujours de la peine pour l'expéditeur : exactement le même fret, expédié deux fois.

Fin novembre dernier, juste après le Black Friday, j'attendais dans la file pour charger dans un entrepôt de distribution à Rancho Cucamonga. Le vieux Wang, le responsable de l'entrepôt, s'est approché et a dit : "Shifu, ce chargement à toi a l'air bizarre." J'ai jeté un œil aux papiers : même ligne, même adresse de livraison (un magasin de pièces auto à Phoenix), même SKU (plaquettes de frein, 48 cartons), même les numéros de commande semblaient presque identiques — sauf les horodatages. Une commande est arrivée à 9:41 AM, l'autre à 9:45 AM. Quatre minutes d'écart. Le système avait généré deux ordres de sortie, imprimé deux étiquettes d'expédition, et les préparateurs avaient déjà mis en scène deux palettes identiques sur le quai.

"Poussé deux fois ?" ai-je demandé. Wang a juste souri amèrement. "L'API de la plateforme a eu un hoquet, n'a jamais reçu l'accusé de réception, alors elle a poussé à nouveau."

Ce jour-là, j'ai conduit de Rancho Cucamonga à Phoenix avec deux chargements identiques de plaquettes de frein à destination de la même adresse. J'ai obtenu deux signatures. Le réceptionnaire était perplexe : "Nous n'avons passé qu'une seule commande." Le chargement en trop a été refusé et ramené tout au long du chemin. Cet aller-retour de fret gaspillé a coûté des centaines de dollars à l'expéditeur, pour absolument rien.

Et ce n'était pas ma première fois. À l'été 2024, je chargeais dans un entrepôt d'articles de maison à Fontana, et la cheffe d'équipe, Xiao Li, s'est confiée à moi : en haute saison, leur système crachait des centaines de "commandes en double suspectées" chaque mois — même acheteur, même adresse, même produit, commandés à quelques minutes d'intervalle. Le premier travail d'une spécialiste chaque matin consistait à les traquer manuellement, en signalant cinquante ou soixante par jour pendant les grandes ventes. Celles qu'elle attrapait étaient les chanceuses. Celles qu'elle manquait ? Expédiées deux fois. Récupérer le fret, c'est une autre histoire — le client le refuse ou le retourne, l'argent du fret est perdu de toute façon, et la marchandise revient éraflée de la route.

Alors comment cela se produit-il vraiment ? Laissez-moi expliquer

Cela fonctionne exactement comme un appel téléphonique.

Vous appelez l'entrepôt : "Salut Wang, envoie 100 unités à Phoenix." Au milieu de la phrase, l'appel coupe. Vous ne savez pas s'il vous a entendu, alors vous rappelez et répétez : "Envoie 100 unités à Phoenix." Il entend ça et pense — compris, deux commandes, envoie deux camions.

C'est ce qui se passe entre une plateforme de vente et un système d'entrepôt, sauf qu'ils appellent ça une poussée de commande par API. Le flux est le suivant : un client passe une commande sur la plateforme, la plateforme la pousse vers le système d'entrepôt via une API, et le système d'entrepôt répond : "Reçu." Mais parfois le réseau saccade, ou le système d'entrepôt est débordé, et l'accusé de réception ne revient pas à temps. La plateforme suppose que la commande n'est jamais arrivée — alors elle la pousse à nouveau. La même commande, à quelques minutes d'intervalle.

Si le système d'entrepôt n'a pas le réflexe de demander : "Ne l'ai-je pas déjà vue, celle-là ?", il traite les deux poussées comme deux commandes distinctes : deux ordres de sortie, deux étiquettes, deux préparations, deux expéditions. Quand le chauffeur charge, l'adresse, le SKU et la quantité sont tous corrects sur les papiers. Rien ne semble anormal. Et comme ça, le même fret est expédié deux fois. C'est là que beaucoup de gens se trompent : ce n'est pas la faute du préparateur. Les préparateurs suivent les papiers. Le système dit de préparer deux commandes, ils préparent deux commandes. La cause racine se situe un niveau au-dessus, dans l'intégration — personne n'a demandé, au moment où la commande est arrivée : "Ai-je déjà vu cette commande ?"

Combien coûte vraiment une double expédition ? Faisons le calcul

Beaucoup de gens pensent : bon, une expédition en plus — qu'on la renvoie. Laissez-moi détailler ce qu'une commande en double de petit colis brûle réellement.

Ça n'a pas l'air de grand-chose, n'est-ce pas ? Mais le volume fait les dégâts. Prenez un entrepôt qui traite 5,000 commandes par jour. Même avec un taux de doublons prudent de 0.5 %, cela fait 25 doubles expéditions par jour. À $35 pièce, c'est $875 par jour — sur 300 jours ouvrés, $260,000 par an. Et cela sans compter les coûts cachés : quand un client reçoit deux exemplaires de tout, sa première pensée n'est pas "quel vendeur généreux". C'est "ce vendeur est un vrai bazar". Mauvais avis, commandes annulées, clients qui ne reviennent jamais — ces pertes ne rentrent pas dans un tableur.

Conseils pratiques pour les expéditeurs et les entrepôts

Après toutes ces années sur la route, j'ai compris une chose : la solution ne se trouve pas sur le quai de chargement. Elle est à l'informatique. Mais les expéditeurs et les exploitants d'entrepôts doivent savoir comment le demander à l'informatique — en langage clair. Sinon l'informatique pense que "le système tourne bien" pendant que l'équipe du quai éteint des incendies tous les jours. Voici la traduction.

Premièrement, chaque numéro de commande doit être unique — et le système doit réellement respecter cette unicité.

Chaque commande qui quitte la plateforme doit porter un numéro de commande globalement unique — comme un VIN sur un camion, jamais répété. Quand le système d'entrepôt reçoit une commande, son premier réflexe ne devrait pas être de générer un ordre de sortie. Il devrait vérifier : ai-je déjà vu ce numéro de commande ? Si oui, bloque ou fusionne le second. Si non, poursuis. Cela s'appelle la déduplication. Ça sonne chic, mais c'est juste "lire la plaque d'immatriculation".

Deuxièmement, la même demande envoyée trois fois doit avoir l'effet d'un envoi unique.

Les informaticiens appellent ça "l'idempotence". Un mot effrayant, un sens simple : que vous disiez "envoie 100 unités à Phoenix" une fois ou trois fois, le résultat devrait être 100 unités — pas 300. Quand vous parlez à l'informatique, dites-le comme ça : "Quand l'API expire et retente, la même commande poussée plusieurs fois ne doit jamais produire qu'une seule expédition." Laissez-leur le comment. Vous dites le quoi.

Troisièmement, les tentatives ont besoin d'un temps de refroidissement et d'un plafond.

Les tentatives elles-mêmes ne sont pas le méchant — si le réseau a un hoquet et que vous ne retentez pas, la commande est perdue, ce qui est pire. Mais les tentatives ne peuvent pas être aveugles et sans fin : poussez une fois, pas d'accusé de réception, attendez quelques dizaines de secondes, poussez à nouveau. Deux ou trois essais, et si ça échoue encore, passez la main à un humain au lieu de marteler sans arrêt. Beaucoup de commandes en double viennent d'une plateforme qui pousse la même commande cinq ou six fois en une minute, avec le système d'entrepôt qui accepte chacune d'elles.

Quatrièmement, l'entrepôt a besoin d'un filet de sécurité humain.

Les correctifs système prennent du temps. En attendant que l'informatique s'en charge, l'entrepôt devrait passer 15 minutes chaque matin à filtrer les "doublons suspectés" : même acheteur, même adresse, même SKU, commandés à moins de 30 minutes d'intervalle — signalez-les pour confirmation humaine. Cet entrepôt de Fontana ? Cette seule astuce a attrapé la plupart de leurs doublons en haute saison. Le filtrage manuel est rudimentaire, mais les outils rudimentaires sauvent la mise quand ça compte.

Une dernière chose, et c'est contre-intuitif : beaucoup d'indicateurs de performance d'entrepôt récompensent en fait la double expédition. Les entrepôts sont mesurés sur la vitesse de préparation — "sortie dans les 2 heures suivant la tombée de la commande". Quand deux commandes identiques apparaissent dans le système, le préparateur, qui court contre la montre, est ravi de simplement les préparer. Personne n'a le temps de se demander si ces deux commandes sont en réalité la même. Plus l'indicateur de vitesse est strict, plus les doublons passent entre les mailles. C'est un compromis : si vous voulez de la vitesse, le système doit faire la vérification pour vous. Si le système ne vérifie pas, la vitesse devient "vite et mal". Donc pendant que vous poussez le délai de traitement, vous devez budgéter du temps et des effectifs pour la vérification — sinon vous forcez la première ligne à jouer l'argent du client.

Encore une chose : ne vous dites pas "nous sommes trop petits pour que ça nous arrive". Les poussées en double se moquent de votre volume de commandes — un hoquet de réseau, un redémarrage de serveur, et un entrepôt de cinquante commandes par jour est frappé de la même façon. Et les petits entrepôts le ressentent davantage : une expédition en double mange une part plus grosse d'une marge mince.

Un vieux dicton pour conclure

Nous autres chauffeurs avons un vieux dicton : "Mieux vaut s'arrêter trois minutes que se précipiter une seconde."

Pareil ici : si le système passe une seconde de plus à demander "ai-je déjà vu cette commande", cela bat le fait de brûler des dizaines de dollars et une pile de maux de tête après coup. Vite ne veut pas dire conduire à l'aveugle. Quand vous parlez à l'informatique, apportez-leur ce dicton — ils comprendront.

Par Shifu Zhao, vétéran du transport routier (15 ans)

Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.