La chaîne d’approvisionnement du vélo reçoit tout en même temps : forte demande, composantes rares et transport sous pression. Au bout de la chaîne, la question reste simple : « Quand est-ce que ça arrive? » La date affichée n’a de valeur que si on sait quel événement l’a produite.

Une ligne de commande passe par plusieurs systèmes. L’ERP crée le bon de commande. Le fournisseur envoie un accusé par portail, API ou message EDI. La production confirme une quantité. Un transporteur associe les boîtes à un conteneur, puis publie des jalons. L’entrepôt confirme finalement la réception. Chaque message possède son horloge et son identifiant.

commande → accusé fournisseur → production → réservation transport
         → départ → transbordement → arrivée port → livraison → réception

Je conserverais les événements au lieu d’écraser une seule colonne DateLivraison :

CommandeLigne: PO-4182-03
Événement:     DEPART_PORT
HeureSource:   2021-07-08T22:14Z
ReçuLe:        2021-07-09T03:02Z
Source:        Transporteur-A
Quantité:      120
Référence:     EVT-991827
Confiance:     confirmée

L’état courant est une projection de cet historique. Un événement en retard peut arriver après une mise à jour plus récente; le système l’insère dans l’historique sans ramener le statut en arrière. EVT-991827 est unique pour qu’un retry ne double pas la quantité. Les heures source et réception distinguent ce qui s’est passé de ce que notre intégration savait à ce moment.

Une date prévue devrait garder sa provenance et une plage. Supposons que les 50 dernières expéditions comparables ont pris une médiane de 28 jours, avec 80 % entre 23 et 41 jours. Si le conteneur n’a pas encore quitté, annoncer « dans 28 jours » cache une longue queue de retards. Je montrerais 23–41 jours, confiance moyenne, basé sur départ non confirmé. Après un départ scanné, la plage peut se resserrer.

Le calcul doit utiliser les bons jalons. Mélanger commande-acceptation et départ-arrivée donne un délai sans sens. Les jours fériés, ports, mode de transport et fournisseur changent la distribution. La moyenne est sensible à quelques retards extrêmes; médiane et percentiles racontent souvent mieux la promesse possible.

Les quantités rendent le flux moins propre

Une commande de 500 unités peut être acceptée pour 400, produite en deux lots et livrée dans trois conteneurs. Le modèle doit relier ligne de commande, allocations, expéditions et réceptions sans supposer une relation un-à-un. Je réconcilie à chaque étape :

1. quantité commandée;
2. quantité acceptée par le fournisseur;
3. quantité produite confirmée;
4. quantité affectée aux expéditions;
5. quantité reçue et inspectée;
6. écart, dommage ou annulation avec raison.

Une panne d’API ne signifie pas que le bateau s’est arrêté. Elle rend seulement notre visibilité périmée. Le tableau affiche l’heure du dernier message et une alerte de fraîcheur. Les événements restent dans une file durable et sont rejoués avec leurs identifiants. Une correction manuelle ne supprime pas la valeur source; elle ajoute un ajustement signé et réversible.

Les fournisseurs ne devraient voir que leurs commandes. Les jetons d’intégration ont des droits limités, les documents de transport peuvent contenir des renseignements commerciaux sensibles et les exports sont journalisés. Une source compromise ne peut pas, à elle seule, confirmer la réception physique; l’entrepôt demeure propriétaire de cette étape.

La visibilité ne fabrique pas de pièces. Elle permet de promettre avec un intervalle, de trouver un remplacement plus tôt et de mesurer quelles sources sont fiables. Ma pratique serait de commencer par cinq états définis, conserver les événements et afficher la fraîcheur. Une date précise viendra seulement lorsqu’un jalon et une distribution la rendent réellement défendable.