Un acheteur commande lundi à 16 h 42 et lit « livré mercredi ». Le vendeur ferme son entrepôt à 16 h, le transporteur ne collecte pas le mardi férié dans ce département et le produit exige deux jours de préparation. La date était calculée avec un simple « aujourd’hui + 2 » sans connaître aucune de ces contraintes.
Le problème devient visible jeudi : le colis vient seulement d’être remis au transporteur. Le support parle de retard transport, le vendeur affirme avoir respecté ses conditions et le checkout conserve pourtant une promesse ferme. Chacun mesure un délai différent, donc personne ne possède la rupture.
Le vrai enjeu d’un SLA de livraison dans une marketplace opérateur est de composer des capacités indépendantes dans une date opposable. Contre-intuitivement, ajouter une marge uniforme ne protège pas la promesse : elle dégrade les offres fiables et reste insuffisante sur les corridors fragiles.
Vous allez comprendre comment relier stock expédiable, préparation, cut-off, calendrier, transport, destination et capacité, puis réviser la prévision après chaque événement. Entrées, sorties, owners, seuils, dépendances, instrumentation, monitoring, retry, file d’exception et rollback maintiennent un calcul explicable.
Décomposer la promesse client
Séparer engagement et estimation
L’engagement est la fenêtre annoncée au moment de l’achat selon les données disponibles. L’estimation évolue ensuite avec la préparation et le transport. Le parcours montre les deux sans réécrire l’engagement initial lorsqu’un événement décale la date.
« Expédié sous 48 h » ne signifie pas « livré sous 48 h ». La promesse complète inclut date de remise au réseau et date de livraison. Elle précise jours ouvrés, plage éventuelle et conditions qui nécessitent une prise de rendez-vous.
Attribuer chaque segment
Le vendeur possède disponibilité, préparation et remise. Le transporteur possède collecte et acheminement selon son service. La marketplace possède le calcul affiché et la cohérence des données. L’acheteur peut posséder une action, comme choisir un créneau ou fournir un accès.
Le contrat de calcul nomme inputs, source, version, fallback et owner. Une date ne sort pas d’un algorithme sans responsabilité. En cas d’écart, la timeline sait quel segment a dépassé sa durée et quelle action doit suivre.
Définir horloges et calendriers
Calculer dans la timezone utile
Commande, entrepôt, cut-off et destination peuvent appartenir à des fuseaux différents. Le calcul convertit l’instant dans la timezone du site d’expédition pour décider le jour de préparation, puis dans celle du service pour présenter la fenêtre.
Le changement d’heure, les commandes à la seconde du cut-off et les timestamps sans offset sont testés. Une date civile n’est jamais stockée comme un instant UTC arbitraire. L’interface cite la timezone lorsque plusieurs pays sont concernés.
Composer les jours ouvrés
Le calendrier du vendeur décrit ouverture, fermeture exceptionnelle et jours de préparation. Celui du transporteur décrit collecte et livraison par zone. Les jours fériés dépendent du site et de la destination, pas seulement du pays de l’opérateur.
Chaque calendrier possède source, périmètre, version et date de rafraîchissement. Une absence de donnée n’est pas remplacée silencieusement par lundi-vendredi. Le moteur choisit un fallback approuvé ou élargit la fenêtre avec un code raison.
Confirmer le stock expédiable
Distinguer disponible et attribuable
Le stock affiché peut inclure unités en contrôle, réservées, en transfert ou physiquement éloignées. Le SLA utilise l’available-to-promise du site capable d’expédier la commande. Une quantité positive globale ne garantit pas une préparation immédiate.
Le verdict porte sku, site, quantité, instant, allocation et expiration. Les bundles vérifient chaque composant. Une commande multi-vendeurs calcule chaque colis séparément avant de présenter la fenêtre globale ou les livraisons fractionnées.
Une offre en dropshipping ne doit pas hériter du stock de l’entrepôt opérateur. Sa source et son délai fournisseur restent propres au seller. Lorsque plusieurs sites possèdent l’article, l’algorithme évalue la quantité complète avant de créer un split : gagner quelques heures sur une ligne peut ajouter un colis, un coût et une seconde probabilité de retard que le client n’a jamais demandés.
Réserver pendant la commande
Une réservation temporaire évite que deux checkouts promettent la même unité. Son expiration et sa conversion en allocation sont idempotentes. L’abandon libère la quantité, tandis qu’un paiement en timeout conserve un état explicite.
Les entrées sont sku, quantité, site et commande ; les sorties hold, version et expiry. Inventory est owner. Verrou, retry, file d’expiration, réconciliation et monitoring préviennent la survente sans bloquer tout le catalogue lors d’un incident isolé.
Modéliser la préparation vendeur
Mesurer par profil d’offre
Une référence stockée, une personnalisation et une palette B2B n’ont pas le même lead time. Le profil associe méthode, quantité, site et service. Le vendeur déclare une base que les observations viennent calibrer.
La distribution compte plus qu’une moyenne. Si 90 % des petites commandes partent en un jour mais les vingt dernières unités prennent trois jours, la quantité influence la promesse. Le modèle choisit un percentile conforme au niveau de confiance décidé.
Le profil est recalibré sur des événements contrôlés : commande acceptée, prête et manifestée. Une saisie manuelle tardive ne doit pas faire croire à une préparation lente si le colis attendait seulement son scan. À l’inverse, déclarer toutes les commandes « prêtes » dès impression de l’étiquette masque la file physique ; la revue compare un échantillon aux collectes réellement constatées.
Appliquer capacité et cut-off
Le cut-off n’ajoute un jour que si la file de préparation peut encore accepter la commande avant la collecte. Un vendeur saturé à midi ne doit pas promettre le même jour sous prétexte que son cut-off statique affiche 17 h.
La capacité quotidienne réserve des unités de travail par profil. Les commandes confirmées la consomment. Une annulation libère selon l’état réel. Les overrides seller sont bornés, tracés et comparés au temps de remise observé.
Qualifier les services transport
Conserver un contrat par corridor
Un service dépend origine, destination, poids, dimensions, produit dangereux, valeur, jour et option. Le libellé « express 24 h » ne suffit pas. Le contrat décrit collecte possible, transit, livraison, exclusions et besoin de rendez-vous.
Les zones transporteur sont versionnées. Une API de rate card peut indiquer prix sans garantir capacité. Le moteur sépare service éligible, tarif disponible et promesse calculable, puis expose une raison lorsqu’un niveau manque.
Les formats sont normalisés sans perdre la valeur source : code produit, unité de transit, garantie, jours de remise et restrictions. Un connecteur qui reçoit « end of day » ne le traduit pas arbitrairement par 18 h. Le contrat d’adaptation possède des fixtures par transporteur et une alerte à tout champ nouveau ou enum inconnu, avant que la réponse ne contamine les dates du checkout.
Calibrer avec la performance observée
Les temps réels sont segmentés par corridor, jour, service et période. Les scans manquants ne deviennent pas automatiquement des retards. La cohorte exige un volume minimal ; sinon le contrat ou une fenêtre prudente reste la référence.
Par exemple, un service annoncé J+1 atteint 97 % sur Paris-Lyon mais 78 % vers la Corse avec moins de trente colis. Le moteur conserve J+1 sur le premier corridor et affiche J+2 à J+4 sur le second jusqu’à une preuve plus robuste.
Intégrer la capacité quotidienne
Réserver collecte et injection
Un transporteur peut accepter le corridor mais plafonner les enlèvements d’un entrepôt. Les slots de collecte, quotas et manifestes font partie de la capacité. Une promesse calculée sans place au camion repose sur une possibilité théorique.
Le site réserve un slot lors de l’allocation ou choisit une collecte suivante. Les commandes prioritaires utilisent une règle transparente. Le système ne repousse pas silencieusement les commandes moins rentables après leur confirmation.
Réagir aux pics et restrictions
Black Friday, météo, grève et embargo réduisent capacité par zone et fenêtre. Une restriction possède début, fin, source, services et facteur appliqué. Elle ne remplace pas définitivement le contrat nominal.
Si l’utilisation d’un slot dépasse 90 % ou si le taux de collecte manquée dépasse 2 % sur deux jours, alors le moteur retire le départ le plus proche. L’owner transport confirme la réouverture après observation et réconciliation des colis déplacés.
Calculer une fenêtre de livraison
Composer les segments sans double marge
Le calcul trouve d’abord site et stock, puis fin de préparation, collecte éligible, transit et jours de livraison. Chaque segment renvoie earliest, latest et confiance. Le moteur compose la fenêtre en respectant les calendriers.
Une marge déjà incluse dans le temps vendeur ne doit pas être ajoutée une seconde fois au niveau global. Les buffers sont nommés et attribués à un risque. La trace explique pourquoi mardi-vendredi a été retenu plutôt qu’une date unique.
Arbitrer plusieurs routes
Plusieurs sites et transporteurs peuvent servir la commande. L’optimisation compare promesse, coût, carbone, risque de split et capacité. Le plus rapide n’est pas toujours le meilleur si sa probabilité de tenue est faible.
La policy pondère les objectifs et garde la route choisie. Un seller peut interdire certains services. Toute substitution après commande respecte le latest promis ou déclenche une notification et une décision de compensation.
Pour une commande de trois lignes, le calcul compare aussi une livraison groupée vendredi à deux colis mercredi et jeudi. Il présente le choix lorsque coût et expérience diffèrent matériellement. Si l’acheteur choisit le groupage, promise_id conserve cette préférence ; un optimiseur nocturne ne revient pas au split pour économiser un trajet d’entrepôt sans demander son accord.
Afficher et figer la date
Calculer avec le contexte final
La fiche produit présente une estimation sans adresse ni quantité complète. Le panier affine avec destination. Le checkout recalcule après allocation et option transport. Chaque étape nomme le degré d’engagement.
La date expire lorsque stock, slot ou tarif n’est plus réservé. Un compte à rebours ne prolonge pas une capacité libérée. Au paiement, un promise_id snapshotte inputs, route, version et fenêtre affichée.
Éviter les promesses divergentes
Web, application, API et support appellent le même service. Les réponses embarquées dans un cache portent version et expiration. Un partenaire ne continue pas à afficher un SLA ancien après une restriction.
Le contrôle synthétique teste chaque heure des paniers représentatifs. Il compare canaux et conserve les inputs, pas seulement le libellé affiché. Toute divergence sur latest bloque le canal concerné plutôt que de choisir la date la plus avantageuse.
Réviser après les événements
Passer de promesse à prévision
Acceptation vendeur, fin de préparation, manifeste, collecte, scans et rendez-vous révisent l’ETA. La promesse initiale reste visible. Un retard probable est communiqué avant que le latest ne soit dépassé.
L’événement doit être plausible et relié au colis. Un scan futur, dupliqué ou appartenant à un numéro réutilisé rejoint une file. Le moteur ne dégrade pas une commande sur une donnée externe non validée.
Orchestrer rattrapage et notification
Lorsqu’un segment dérive, l’orchestrateur évalue collecte alternative, upgrade, split ou contact vendeur. Il calcule coût et nouvelle confiance. L’owner décide selon montant et impact, avec un plafond d’action automatique.
Les entrées sont promise_id, événements et routes restantes ; les sorties ETA, action et message. Transport Operations possède la reprise. Instrumentation, dépendances, retry, dead-letter queue, timeout et rollback protègent la commande contre les doubles actions.
Mesurer fiabilité et dérive
Mesurer le respect par segment
Le tableau compare préparation promise/réelle, collecte, transit et livraison. Il suit on-time-in-full, early, late, largeur de fenêtre et précision de l’ETA. Les résultats sont segmentés par seller, site, corridor et service.
La ponctualité seule peut être manipulée en élargissant toutes les dates. Le pilotage rapproche fiabilité, vitesse, conversion, annulation et coût. Une fenêtre de six jours tenue ne vaut pas une fenêtre de deux jours tenue au même taux.
La revue hebdomadaire lit les distributions, pas uniquement un score rouge ou vert. Elle identifie à quel jour et à quelle heure les écarts apparaissent, puis sélectionne dix commandes pour rejouer leur calcul. Une baisse de conversion après élargissement peut justifier un investissement de capacité ; elle ne justifie jamais le raccourcissement artificiel du latest sans changement opérationnel.
Détecter données et modèles obsolètes
Le monitoring signale calendrier expiré, seller sans observation, corridor qui dérive, capacité non consommée et scans manquants. Chaque alerte cite population, owner et action. Les seuils sont revus en saison.
Une réconciliation quotidienne part des commandes confirmées et retrouve promise_id, allocation, route, événements et verdict. Les manquants sont réparés par backfill idempotent. Un écart financier ou client reste ouvert jusqu’à la correction de son effet.
Gérer incidents et modes dégradés
Choisir un fallback explicite
Si l’API transport est indisponible, le moteur peut utiliser un contrat versionné encore valide, masquer le service ou élargir la fenêtre selon risque. Il ne renvoie pas zéro jour parce qu’un champ manque.
Le mode dégradé porte reason_code et validité. Le checkout informe sans détail technique. Les commandes prises ainsi sont marquées pour réconciliation lorsque la dépendance revient, avec une priorité adaptée à leur date promise.
Un fallback est évalué comme une policy de production. Son taux d’usage, sa largeur ajoutée et sa ponctualité sont suivis séparément. S’il reste actif plus de quatre heures ou couvre plus de 10 % des commandes, l’astreinte confirme explicitement le maintien, limite les corridors risqués ou suspend le service. Le retour nominal se fait par canary afin de ne pas rejouer brutalement toutes les requêtes en attente.
Tester rollback et reprise
Un canary compare ancien et nouveau calcul sans exposer toute la population. Si plus de 0,5 % des fenêtres se raccourcissent sans explication ou si deux commandes deviennent impossibles, alors le trafic revient à l’ancienne version.
L’exercice provoque stock en timeout, calendrier absent, slot saturé et événement dupliqué. La reprise rejoue les commandes depuis leurs inputs immuables. Les notifications déjà envoyées ne sont jamais annulées silencieusement ; une correction explique la nouvelle date.
Adapter la méthode et éviter les erreurs
Pour qui le SLA de livraison convient
Il devient essentiel dès que plusieurs vendeurs, sites ou transporteurs composent la date. Une marketplace naissante peut commencer avec calendriers, profils de préparation et contrats de transit, puis ajouter calibration et capacité dynamique.
Inventory possède le stock, Seller Operations la préparation, Transport les corridors, Produit l’affichage et Platform le calcul. Support traite les dérives depuis promise_id. Chaque input a une source et une fraîcheur attendue.
Erreurs fréquentes du SLA livraison
Ajouter un nombre de jours fixe, ignorer cut-off et fériés, utiliser le stock global, confondre prix transport et capacité, écraser la promesse par l’ETA et mesurer seulement la moyenne sont les erreurs majeures.
Une autre erreur consiste à surprotéger avec une marge uniforme. Enfin, afficher la date avant l’adresse sans signaler son caractère estimatif crée une fausse garantie. Le modèle doit expliquer autant qu’il prédit.
Plan d’action pour construire le SLA livraison
Semaines 1 à 4 : contrats de temps
La première semaine prélève cent commandes et reconstruit stock, préparation, collecte, transit et livraison. La deuxième définit horloges, calendriers, profils, corridors et owners. Les écarts sont attribués au segment réellement en retard.
Les semaines trois et quatre développent le calcul versionné et promise_id. Les fixtures couvrent cut-off, fuseau, férié, bundle, quantité, split, zone et calendrier absent. Le support doit reproduire chaque date depuis les inputs visibles.
Semaines 5 à 8 : capacité et exploitation
La cinquième semaine relie holds de stock et slots ; la sixième ajoute ETA, alertes et rattrapage. L’instrumentation suit fiabilité, largeur, conversion, calendrier périmé, capacité et événements manquants avec runbooks et seuils.
Les semaines sept et huit exécutent un canary sur 5 % des commandes, simulent pannes et pic, puis comparent ancien et nouveau calcul. Le go exige réconciliation, aucun double hold, rollback reproductible et quatre parcours repris par l’astreinte.
Le paquet de run contient matrices de calendriers, versions de contrats, corpus de commandes, décisions de fallback et procédures de correction. Une personne extérieure au projet doit expliquer dix dates, identifier le segment responsable et rejouer un promise_id. La revue vérifie aussi les messages réellement montrés sur fiche, panier, checkout et suivi, car une bonne date mal qualifiée reste une mauvaise promesse.
- À faire d’abord : décomposer stock, préparation, collecte, transit et livraison.
- À tester ensuite : calendrier, saturation, split, événement tardif, fallback et rollback.
- À différer : le machine learning tant que les contrats et événements restent incomplets.
- À refuser : toute date ferme sans inputs versionnés ni capacité réservée.
Ressources complémentaires pour l’opérateur
Borner offres et ouverture
Le MVP marketplace avant ouverture aide à choisir les premières promesses transport.
La méthode pour ouvrir une première catégorie crée une cohorte mesurable.
Structurer données et actions
Le catalogue PIM marketplace porte les propriétés logistiques fiables.
Les écrans du back-office opérateur outillent diagnostic et reprise.
Conclusion : promettre ce qui sera tenu
Un SLA de livraison crédible compose chaque segment depuis une source, un calendrier et une capacité.
La promesse reste figée tandis que l’ETA évolue avec des événements contrôlés et des actions de rattrapage.
Mesure segmentée, réconciliation et modes dégradés empêchent le checkout de vendre une date imaginaire.
Dawap peut vous accompagner pour construire ce calcul dans votre marketplace opérateur.
