Un stock ERP de 120 unités ne signifie pas que 120 unités peuvent être promises sur Amazon, Fnac, Cdiscount et Mirakl. Certaines sont déjà réservées, d’autres attendent un contrôle qualité, quelques-unes servent le site direct et les dernières arriveront après le délai affiché au client.
Le problème devient visible avec des surventes, des ruptures artificielles, des corrections manuelles et une marge dégradée par les annulations. Un signal faible apparaît plus tôt : le stock publié oscille sans mouvement physique tandis que les réservations anciennes ne se libèrent plus.
Le vrai enjeu n’est pas de diffuser un nombre plus frais, mais de décider quelle quantité peut être tenue pour un SKU, un lieu, un canal et une fenêtre temporelle. Vous allez comprendre comment calculer cette promesse, choisir ses protections et retrouver l’écart qui l’a rendue intenable.
Une agence marketplace doit relier cette promesse aux opérations et à la marge. La spécialisation réapprovisionnement marketplace permet ensuite d’ajuster sécurité, disponibilité et exposition selon les contraintes réelles de chaque canal.
Définir l’ATP marketplace comme une décision
L’ATP n’est pas le dernier nombre reçu d’un entrepôt. C’est le résultat versionné d’une politique qui sélectionne les quantités éligibles, déduit les engagements, protège une réserve et tient compte du moment où la promesse devra être exécutée.
Séparer présence physique et droit de promettre
Une unité peut être physiquement présente mais bloquée, endommagée, affectée à une commande, réservée au SAV ou interdite sur un canal. Inversement, une unité en transit peut devenir promettable si sa date d’arrivée, son risque et le délai client autorisent cette anticipation.
La décision utile répond donc à cinq questions : quelle quantité, pour quel SKU vendable, depuis quel nœud logistique, sur quel canal et jusqu’à quelle heure de calcul. Sans ces dimensions, deux nombres identiques peuvent porter des risques radicalement différents.
Nommer chaque population avant de calculer. Le périmètre minimal distingue stock en main, stock libérable, réservations fermes, allocations de canal, retours inspectables, approvisionnements confirmés et quantités indisponibles. Chaque population possède une source, un horodatage et une règle d’éligibilité.
Conserver l’identité du SKU et du nœud
Le rapprochement s’effectue sur un identifiant vendable stable, pas seulement sur un EAN partagé par plusieurs packs ou états. L’entrepôt, le propriétaire du stock, le lot, la date d’expiration et le pays peuvent modifier la capacité à servir une offre marketplace précise.
Une table de correspondance versionnée relie identifiants ERP, WMS, PIM, OMS et canaux. Toute ambiguïté part en quarantaine plutôt que d’additionner silencieusement deux populations incompatibles sous une référence commerciale rassurante mais fausse.
Écrire une formule ATP opposable
Une formule de base peut s’écrire ainsi : ATP = stock libéré − réservations fermes − sécurité − allocations protégées + réceptions confirmées dans la fenêtre. Chaque terme doit être défini avec le métier, observable dans les données et reproductible après incident.
Calculer un exemple sans masquer les hypothèses
Un SKU possède 120 unités libérées, 18 commandes confirmées, 12 paniers encore réservés, 20 unités de sécurité et 15 unités protégées pour le canal direct. Une réception de 40 unités est confirmée demain, mais la promesse marketplace exige une expédition aujourd’hui.
L’ATP immédiat vaut 55 unités : 120 − 18 − 12 − 20 − 15. Les 40 unités entrantes alimentent une fenêtre future distincte. Les ajouter au disponible courant créerait une promesse dépendante d’une réception qui ne peut pas encore servir l’engagement affiché.
Par exemple, si cinq commandes supplémentaires arrivent avant l’accusé de la marketplace, alors leurs réservations diminuent immédiatement la prochaine sortie ATP. Le nombre publié attend le cycle suivant, mais le moteur refuse déjà de le réutiliser pour une autre promesse.
Dimensionner le stock de sécurité par risque
Une sécurité fixe de dix unités paraît simple, mais elle protège mal un produit très volatil et immobilise inutilement une référence à rotation lente. La réserve doit refléter délai de réapprovisionnement, variance de demande, fiabilité fournisseur, criticité commerciale et coût d’une annulation.
Utiliser service cible et incertitude observée
Le calcul peut combiner demande moyenne pendant le délai, erreur de prévision et niveau de service cible. Un lancement, une promotion ou une dégradation fournisseur déclenche un régime spécifique plutôt qu’une simple extrapolation de l’historique récent.
La réserve conserve sa justification : données d’entrée, méthode, date d’effet, owner et expiration. Une protection sans date de révision devient progressivement un stock dormant ; une protection supprimée sans preuve transforme l’amélioration apparente de disponibilité en risque client.
Gouverner le cycle de vie des réservations
La réservation protège une intention entre la capture de commande et l’engagement définitif. Elle doit posséder une clé idempotente, un statut, une quantité, une origine, une échéance et une raison de libération pour éviter les doubles déductions comme les stocks fantômes.
Distinguer panier, commande et allocation
Un panier ne mérite pas toujours la même priorité qu’un paiement autorisé. La politique définit durée et rang de chaque réservation, tandis qu’un job d’expiration libère les intentions abandonnées sans toucher aux engagements encore en cours de confirmation.
Chaque transition produit un événement corrélé. Une répétition du webhook de commande ne consomme pas deux fois le stock ; une annulation libère exactement la réservation d’origine ; un remplacement de SKU crée une nouvelle trace au lieu de réécrire l’historique.
Intégrer les délais dans la quantité promettable
L’ATP dépend de l’heure de cut-off, du calendrier entrepôt, du transport, des jours fériés, du pays et de la capacité de préparation. Une quantité disponible demain ne doit pas soutenir une promesse d’expédition aujourd’hui, même si le stock agrégé devient positif.
Construire des fenêtres temporelles distinctes
Le moteur calcule un ATP immédiat, puis des quantités par jour ou semaine selon les réceptions confirmées. Chaque fenêtre porte une confiance issue de la fiabilité fournisseur et de la variance historique entre date annoncée et date réellement libérée.
La date client résulte ensuite de la fenêtre, du nœud choisi et de la promesse du canal. Une marketplace qui n’accepte qu’une quantité globale reçoit la borne conservatrice correspondant au service réellement soutenable pendant la prochaine période de synchronisation.
Mesurer la fraîcheur et la qualité des flux
Un calcul exact sur une donnée vieille de trois heures reste dangereux. Chaque source expose son dernier événement reçu, son retard attendu, son taux de rejet, sa profondeur de file et le dernier rapprochement complet réussi avec le système maître.
Associer une confiance à la disponibilité
La quantité publiée peut être réduite lorsque la fraîcheur dépasse un seuil, lorsqu’un entrepôt ne répond plus ou lorsque le nombre de mouvements non réconciliés augmente. La règle est graduée avant de devenir une coupure totale.
Le dashboard ne montre pas seulement un feu rouge. Il indique SKU et canaux concernés, âge de la donnée, événement manquant, ATP avant protection, quantité finalement publiée, owner de l’incident et prochaine action autorisée.
Contre-intuitivement, publier moins peut donc augmenter le chiffre d’affaires net : une quantité prudente évite l’annulation qui détruit conversion, classement et confiance, puis remonte automatiquement dès que la source redevient conforme.
Appliquer des règles de canal explicables
Une fois l’ATP global établi, l’allocation répartit la capacité entre canaux selon contribution, demande, rang stratégique, pénalités, promesse et contraintes de marque. Elle ne doit jamais recréer plus de promesses que la quantité protégée en amont.
Combiner quotas, planchers et plafond dynamique
Un quota réserve une capacité ; un plancher maintient une offre active ; un plafond borne l’exposition d’un canal risqué. Les unités non consommées peuvent être réattribuées après une fenêtre définie, avec une trace de la règle et de la décision.
Les priorités permanentes sont interdites sans owner ni date d’expiration. Une campagne rentable peut recevoir davantage de stock pendant quatre jours, mais la règle revient ensuite au régime nominal pour éviter qu’une urgence commerciale devienne une dette invisible.
La plateforme Ciama pour piloter les ventes marketplace peut rapprocher disponibilité, commandes et contribution afin que l’arbitrage commercial reste lié aux résultats réellement encaissés plutôt qu’au seul volume exposé.
Distribuer les responsabilités entre ERP, WMS et OMS
L’ERP porte souvent propriété et valorisation, le WMS l’état physique, l’OMS les commandes et réservations, tandis que le moteur ATP calcule la promesse. Chaque décision possède une seule autorité, même si plusieurs systèmes en détiennent une projection.
Publier des événements idempotents et rejouables
Les mouvements partagent SKU, nœud, quantité signée, type, identifiant source, version et horodatage métier. Le consommateur ignore un doublon, refuse une version incohérente et peut reconstruire un état à partir d’un snapshot puis d’événements ordonnés.
Une API de lecture expose quantité, fenêtre, confiance et décomposition. L’écriture reste limitée aux autorités nommées ; un opérateur corrige l’événement causal ou crée un ajustement audité plutôt que modifier directement le nombre servi aux canaux.
L’entrée du calcul regroupe snapshots, réservations et réceptions ; la sortie publie quantité, confiance et fenêtre. Le contrat fixe owner, dépendances, seuil d’acceptation, idempotence et responsabilité de correction pour chaque événement rejeté.
Tester les invariants avant chaque publication
Les invariants bloquants vérifient ATP non négatif, somme des allocations inférieure ou égale à l’ATP, réservation unique par engagement, cohérence des unités, fenêtre compatible avec le cut-off et fraîcheur sous le seuil défini.
Comparer calcul, publication et résultat
Un test de contrat rejoue des scénarios connus ; un canari compare l’ancien et le nouveau moteur ; une réconciliation rapproche ATP calculé, quantités envoyées, accusés des marketplaces, commandes reçues et stock WMS restant.
La différence n’est pas automatiquement une erreur : elle peut provenir d’une vente concurrente ou d’un délai de canal. Elle devient toutefois une anomalie attribuée lorsqu’elle dépasse la tolérance ou ne se résorbe pas dans la fenêtre attendue.
Le monitoring associe chaque seuil à un owner et à un runbook. Une file en retard déclenche le repli conservateur ; une divergence durable bloque l’extension ; un rollback restaure la dernière version de règle dont la réconciliation complète reste prouvée.
Éviter les erreurs fréquentes de calcul et de publication
Une survente peut venir d’une réservation tardive, d’un doublon, d’un mauvais mapping, d’un flux bloqué ou d’une quantité acceptée puis ignorée par le canal. Une sous-exposition peut cacher une sécurité excessive, une libération manquante ou une réception jamais activée.
Un deuxième signal faible apparaît lorsque le disponible baisse sans commande nouvelle puis remonte après une relance de file. Cette oscillation révèle souvent un ordre d’événements instable avant que les annulations ne deviennent visibles.
Trouver le premier écart de promesse
Le diagnostic compare une vente affectée et un témoin du même SKU : état WMS, événement, snapshot, formule, allocation, payload envoyé, accusé reçu et commande. Le premier écart borné désigne la couche à corriger.
En mode dégradé, le moteur réduit la publication, gèle certaines allocations ou ferme un canal selon l’incertitude. Il conserve la dernière vérité sûre et refuse une remontée manuelle globale qui masquerait la cause sans protéger les nouvelles commandes.
Un cas concret concerne une annulation reçue deux fois : si la libération n’est pas idempotente, alors le système recrée du disponible et prépare une future survente. La preuve attendue relie les deux messages à une seule réservation consommée.
Piloter l’ATP avec des preuves business
Le taux de rupture ou de survente ne suffit pas. Le pilotage relie quantité exposée, disponibilité de l’offre, conversion, contribution, annulations, retard, pénalités, âge des données et unités immobilisées par sécurité ou réservation expirée.
Mesurer contre une baseline et un témoin
Une cohorte de SKU compare quatre semaines avant et après, à saison et campagnes documentées. Les résultats distinguent valeur créée par exposition supplémentaire, pertes évitées par réduction et coût opérationnel des exceptions encore traitées manuellement.
Le succès exige une amélioration conjointe : moins d’annulations, davantage de sessions avec offre achetable, marge protégée et diminution du stock inutilement bloqué. Un seul indicateur favorable ne justifie jamais l’extension générale.
Attribuer décisions, exceptions et changements
Supply définit la sécurité, opérations gouverne les réservations, commerce propose les priorités, finance contrôle la contribution et la tech garantit calcul, contrats et observabilité. Un owner unique arbitre les conflits de politique et assume leur expiration.
Versionner chaque règle commercialement sensible
Une modification de quota, sécurité ou délai précise motif, population, valeur attendue, risque, approbateur, date d’effet et rollback. Le moteur conserve la version utilisée pour chaque quantité envoyée afin d’expliquer une commande plusieurs semaines plus tard.
Le comité hebdomadaire examine uniquement les écarts hors seuil, les règles proches de leur expiration et les décisions qui nécessitent un arbitrage. Les incidents simples restent dans le runbook et ne consomment pas le temps de gouvernance.
Traiter un cas multi-entrepôts et multi-canaux
Une marque opère deux entrepôts. Le premier détient 300 unités avec cut-off tardif ; le second en possède 90, mais sert mieux le sud de l’Europe. Amazon, le site direct et deux marketplaces spécialisées partagent la même référence.
Décider sans agréger trop tôt
Le moteur calcule l’ATP de chaque nœud, protège les commandes directes, puis affecte les canaux selon promesse et coût de service. Une panne de synchronisation du second entrepôt réduit seulement sa contribution au lieu de fermer tout le SKU.
Après six semaines, les annulations baissent, la disponibilité progresse sur les canaux rentables et le stock de sécurité diminue sur les références stables. La preuve vient des commandes réconciliées, pas du seul volume de stock publié.
Plan d’action : déployer un ATP en six semaines
Le déploiement commence sur une population bornée, avec un seul entrepôt et deux canaux suffisamment représentatifs. L’objectif consiste à fermer la boucle complète avant d’ajouter les exceptions de tout le catalogue.
Semaines 1 et 2 : prouver les populations
Inventoriez états, identités, réservations, délais et événements. Rejouez vingt commandes et documentez chaque divergence entre stock physique, stock libéré, quantité calculée, valeur publiée et résultat du canal.
La sortie attendue comprend un dictionnaire d’états, une matrice des autorités, dix scénarios reproductibles et une baseline des annulations, corrections, écarts de fraîcheur et unités bloquées sans justification active.
Semaines 3 et 4 : calculer en parallèle
Exécutez le moteur sans publier, comparez-le au dispositif courant et qualifiez les écarts. Fixez seuils de fraîcheur, sécurité, règles de réservation, confiance et procédures de rollback avec les owners opérationnels.
Chaque divergence reçoit un verdict : amélioration volontaire, défaut du nouveau calcul, anomalie historique ou donnée indécidable. Seuls les écarts expliqués rejoignent la configuration du canari ; les autres restent bloqués avec une action attribuée.
Semaines 5 et 6 : ouvrir puis réconcilier
Activez dix SKU canaris, observez chaque payload et rapprochez les commandes quotidiennement. Étendez par famille seulement après plusieurs fenêtres conformes, un mode dégradé testé et une preuve business lisible.
La porte d’extension exige zéro réservation dupliquée, une fraîcheur sous le seuil convenu, une réconciliation fermée et un rollback exécuté. Une hausse de disponibilité sans ces garanties ne suffit pas à ouvrir le catalogue suivant.
- D’abord, séparer les états physiques, commerciaux et temporels au lieu de recopier un stock agrégé vers chaque canal.
- Ensuite, écrire la formule, les réservations, la sécurité et les règles de fraîcheur avec leurs sources et propriétaires.
- Puis, comparer calcul et publication sur une cohorte canari avec réconciliation, témoin et rollback réellement exécuté.
- À faire enfin : étendre par famille de risque, mesurer la valeur nette et retirer les anciens chemins de publication non gouvernés.
Guides complémentaires : relier ATP, allocation et architecture
Le calcul ATP fournit la borne fiable ; l’allocation choisit ensuite où l’utiliser, tandis que l’architecture garantit que commandes et mouvements restent réconciliables dans la durée.
Approfondir l’allocation entre canaux
La méthode d’allocation de stock cross-marketplaces arbitre marge, buy box et promesse sans multiplier les unités. Le cahier des charges OMS marketplace transforme ces règles en exigences de commande, retour et supervision.
L’ATP borne la quantité sûre ; l’allocation ne peut que répartir cette borne. Cette séparation facilite les tests, empêche une priorité de canal de créer du stock et attribue chaque écart à la bonne politique.
Sécuriser les systèmes sources
L’architecture d’un connecteur ERP marketplace attribue PIM, ERP, OMS et WMS. Le plan de redressement relie ensuite stock, prix, catalogue et commandes à une trajectoire opérationnelle mesurable.
- À faire : exposer avec chaque ATP son horodatage, sa fenêtre, sa confiance, sa version de règle et sa décomposition vérifiable.
- À différer : l’optimisation avancée tant que réservations, identités, fraîcheur et réconciliation ne produisent pas une vérité stable.
- À refuser : toute correction directe du disponible publié qui ne laisse ni événement causal, ni owner, ni expiration, ni preuve de retour à la normale.
Conclusion : promettre sans improviser
Un ATP marketplace fiable ne maximise pas mécaniquement la quantité exposée. Il transforme les états du stock, les engagements et le temps en une promesse que les opérations peuvent réellement tenir.
La sécurité protège l’incertitude, les réservations protègent les commandes et la fraîcheur protège la décision. Leur version et leur réconciliation rendent chaque quantité explicable après publication.
L’amélioration durable apparaît lorsque disponibilité, marge et service progressent ensemble, tandis que les corrections manuelles et le stock inutilement immobilisé diminuent sur des cohortes comparables.
Pour mettre en place ce pilotage, l’agence marketplace Dawap vous accompagne de la vérité WMS jusqu’à une promesse de stock datée, réconciliée et rentable sur chaque canal.
