Agence marketplace

Arrêter de promettre, figer les faits et réparer chaque commande avant de rouvrir le stock

Jérémy Chomel Dawap
  • Publié le : 6 août 2026
  • Mis à jour le : 4 août 2026
  • Temps de lecture : 16 minutes
  1. Qualifier la survente et son horloge
  2. Installer le commandement d’incident
  3. Confiner sans effacer les preuves
  4. Figer une photographie réconciliable
  5. Calculer l’exposition réelle
  6. Prioriser les commandes affectées
  7. Corriger le stock à la bonne source
  8. Piloter les actions par canal
  9. Réparer la promesse client
  10. Encadrer remboursements et coûts
  11. Erreurs fréquentes de réconciliation qui prolongent la survente
  12. Rouvrir avec des portes techniques, client et business
  13. Appliquer le runbook à un cas concret
  14. Plan d’action après incident : convertir la timeline en prévention mesurable
  15. Guides complémentaires : empêcher la récidive dans la chaîne stock
  16. Conclusion : réparer avant de relancer
Portrait de Jérémy Chomel

À 10 h 17, une marketplace signale douze commandes alors que l’entrepôt ne trouve que sept unités. Le flux de stock affiche encore quinze pièces, la campagne sponsorisée continue et trois autres canaux acceptent des commandes. Chaque minute transforme un écart technique en promesses client impossibles à tenir.

La douleur n’est pas seulement le remboursement. Elle touche le classement vendeur, les pénalités, le support, la confiance, la publicité déjà dépensée et parfois la capacité à vendre pendant plusieurs jours. Un signal faible existait souvent plus tôt : réservations vieillissantes, accusés manquants, stock négatif toléré ou latence de publication qui dépasse le temps moyen entre deux commandes.

Le vrai enjeu consiste à arrêter l’expansion sans détruire la preuve, puis à décider quelle promesse peut encore être tenue. Vous allez comprendre comment ordonner les horloges, les owners et les portes de sortie afin que correction de stock, communication client et réouverture racontent la même histoire.

Une agence marketplace relie ce runbook aux enjeux de marge, de réputation et de disponibilité. L’accompagnement de run et supervision marketplace vendeur transforme ensuite chaque alerte en décision exécutable, réconciliée et mesurable.

Qualifier la survente et démarrer une horloge commune

Une survente existe dès que la quantité promise dépasse la quantité qu’il est encore raisonnable de rendre disponible avant l’échéance client. Attendre un stock négatif dans l’ERP retarde le diagnostic : une unité peut être physiquement présente mais bloquée, endommagée, réservée ou impossible à expédier dans le délai annoncé.

Distinguer signal, incident et impact

Le signal peut venir d’un opérateur, d’une commande rejetée, d’un écart WMS, d’un canal ou d’un contrôle automatique. L’incident commence à la première promesse potentiellement non tenable ; l’impact couvre commandes, acheteurs, pays, vendeurs, campagnes et obligations de délai effectivement exposés.

Consignez quatre temps : première divergence plausible, première détection, début du confinement et fin de propagation. Cette chronologie sépare durée cachée, temps de réaction et temps de maîtrise. Elle évite qu’une correction rapide fasse oublier trois heures de commandes déjà acceptées.

Attribuer une sévérité avant de connaître toute la cause

La sévérité dépend du nombre de promesses, de la valeur, du délai restant, des canaux, de la substituabilité et du risque contractuel. Elle peut monter ou descendre au fil des faits, mais son premier niveau doit déjà déclencher les bons rôles et empêcher une discussion interminable sur la racine.

Un incident majeur combine propagation active et décision client proche. Un incident limité peut concerner une seule offre isolée avec stock alternatif prouvé. Dans les deux cas, la règle reste la même : contenir d’abord ce qui agrandit l’exposition, analyser ensuite la cause sans contaminer les faits.

Par exemple, si l’écart dépasse le seuil de 2 SKU ou 5 % de la quantité promise, alors la sévérité monte automatiquement et le confinement multicanal devient prioritaire avant l’analyse détaillée.

Installer un commandement qui tranche, journalise et communique

Le responsable d’incident possède la décision opérationnelle, pas nécessairement la connaissance la plus technique. Il maintient périmètre, sévérité, prochaine échéance et liste d’actions. Stock, marketplace, entrepôt, service client, finance et acquisition nomment chacun un interlocuteur capable d’engager son domaine.

Séparer décision, exécution et validation

Une personne ordonne la suspension des offres, une autre l’exécute, une troisième confirme le résultat sur chaque canal. Cette séparation légère empêche qu’une commande API acceptée soit confondue avec une publication réellement visible. Le journal conserve auteur, heure, objet, résultat et preuve associée.

Le canal d’incident ne remplace pas le registre. Les messages servent à coordonner ; une timeline structurée sert à décider et à auditer. Chaque hypothèse porte son statut : proposée, testée, confirmée ou rejetée. Une intuition ne devient jamais une cause racine parce qu’elle a été répétée plusieurs fois.

Fixez un rythme de point court selon la sévérité, ainsi qu’une heure de prochaine communication interne et client. L’équipe peut alors travailler entre les points sans répondre continuellement aux mêmes demandes. Toute décision irréversible exige owner, bénéfice attendu et condition de repli explicite.

Confiner les nouvelles promesses sans effacer les preuves

Le confinement vise les écritures qui peuvent augmenter l’exposition : quantité publiée, réservation, campagne, import de commande, règle de substitution et automatisation de réapprovisionnement. Couper indistinctement tous les flux peut pourtant masquer des accusés et empêcher de savoir quelles commandes sont réellement entrées.

Choisir le geste minimal qui arrête la propagation

Fermez l’offre ou publiez zéro lorsque le canal le confirme rapidement. Si la publication est lente, suspendez aussi les campagnes et bloquez localement l’acceptation. Une marge de sécurité négative ne suffit pas lorsqu’un cache, un flux différé ou une deuxième source continue d’annoncer l’ancienne quantité.

Conservez la réception des événements en lecture ou dans une file immuable. Un message arrivé pendant le confinement doit être marqué et rapproché, non supprimé. La file morte, les retries automatiques et les tâches planifiées sont inventoriés : ils peuvent réintroduire la valeur fautive après la première correction.

Le critère de confinement n’est pas « bouton cliqué ». Il exige zéro nouvelle commande attribuable après l’heure attendue de propagation, des accusés pour tous les canaux et une surveillance supérieure à leur pire latence récente. Une offre fermée sur l’interface mais encore achetable par API reste ouverte.

Figer une photographie réconciliable avant toute correction

Avant de modifier les quantités, capturez le stock physique, les emplacements, le disponible WMS, les réservations OMS, les commandes ouvertes, les expéditions, les retours attendus et les quantités publiées. Chaque valeur porte source, unité, horodatage et identifiant de produit.

Préserver les versions qui ont fabriqué la promesse

Archivez payloads entrants et sortants, réponses canal, mappings SKU, règles d’ATP, coefficients de pack et jobs exécutés. Sans ces versions, le stock final pourra être juste sans expliquer pourquoi douze acheteurs ont vu une disponibilité incompatible avec sept unités.

La photographie doit être répétable. Un export manuel sans requête, timezone ni périmètre ne constitue pas une preuve. Préférez un bundle signé ou au minimum un dossier horodaté dont chaque extrait décrit la commande ayant produit les lignes et le nombre attendu d’enregistrements.

Évitez la tentation de « remettre le bon chiffre » dans toutes les bases. Une correction simultanée détruit l’ordre causal et peut déclencher des synchronisations croisées. Désignez d’abord la source autoritaire, mettez les projections en quarantaine et conservez l’écart comme objet à réconcilier.

Calculer l’exposition réelle, commande par commande

La quantité manquante ne suffit pas. Deux unités disponibles peuvent sauver quatre commandes si certains paniers contiennent des substituts, si une réception ferme arrive avant l’échéance ou si un acheteur accepte une livraison partielle. Inversement, dix unités physiques ne valent rien si elles sont bloquées qualité.

Construire un ledger des promesses

Pour chaque ligne, enregistrez ordre d’acceptation, délai promis, canal, service, valeur, marge, statut de paiement, coût de pénalité, possibilité de substitution et prochaine décision irréversible. Reliez-la à une unité réelle, une réception prouvée ou un déficit explicite.

Classez l’exposition en trois groupes : tenable sans changement, tenable avec action vérifiée, impossible selon les faits actuels. Le second groupe ne repose jamais sur une espérance vague. Une réception n’est utilisable que si quantité, date, transport, contrôle et allocation sont confirmés par leurs owners.

Publiez deux nombres distincts : commandes potentiellement affectées et commandes dont la promesse est déjà impossible. Le premier pilote la prudence ; le second déclenche la réparation client. Les confondre provoque soit des annulations excessives, soit une communication trop tardive.

Prioriser les commandes avec une politique défendable

Servir simplement la plus forte marge expose l’entreprise à l’injustice et au non-respect d’engagements. Servir uniquement le premier arrivé peut ignorer une commande urgente déjà promise. La politique doit être connue avant de révéler le nom du client qui bénéficiera de la dernière unité.

Appliquer des contraintes avant les préférences

Protégez d’abord obligations légales, commandes expédiées, engagements contractuels, délais non récupérables et clients vulnérables identifiés. Arbitrez ensuite selon heure d’acceptation, possibilité de remplacement, valeur relationnelle et coût total de réparation, avec une raison codifiée.

Une dérogation exige auteur, motif, durée et commandes déplacées. Elle ne modifie jamais silencieusement le rang. Le ledger garde rang initial, règle appliquée, override et résultat afin que le postmortem distingue faiblesse de politique et intervention exceptionnelle.

Si deux commandes portent la même échéance, alors servez d’abord celle dont la substitution est impossible ; en revanche, différez celle dont l’acheteur a accepté une alternative prouvée plutôt que d’improviser une préférence commerciale.

Simulez la liste avant exécution : quelles commandes changent si une réception glisse de vingt-quatre heures, si deux unités échouent au contrôle ou si un canal refuse la livraison partielle ? Une priorité robuste ne s’effondre pas au premier aléa prévisible.

Corriger le stock à la source qui possède le fait

Le WMS possède généralement le fait physique, l’OMS les réservations et le canal la quantité publiée. Aucun chiffre isolé n’est « le stock ». La correction rétablit les relations entre ces objets plutôt qu’une égalité artificielle dans trois tables.

Passer par des mouvements compensatoires traçables

Créez inventaire, annulation de réservation ou reclassement avec un motif d’incident, jamais une mise à jour SQL sans mouvement. Le correctif porte identifiant, valeur avant, delta, valeur après, source de preuve et approbateur. Les projections se reconstruisent depuis ces événements.

Contrôlez unités, packs, variantes et emplacements. Une conversion carton-unité ou un mapping SKU dupliqué peut recréer la survente après un inventaire exact. Testez aussi le signe des retours et transferts : une quantité en transit ne devient disponible qu’au jalon choisi par la promesse.

Contrairement à ce que suggère un tableau de stock redevenu positif, la correction n’est pas terminée tant que réservations, accusés de canal et commandes en file ne convergent pas vers cette nouvelle valeur.

Après correction, rejouez une cohorte fermée dans un environnement ou une file contrôlée. Comparez l’état attendu à chaque projection avant de réactiver le flux général. L’objectif n’est pas seulement une valeur finale juste, mais une convergence déterministe sans double mouvement.

Piloter les actions selon les contraintes de chaque canal

Les marketplaces ne partagent ni latence, ni mécanisme de fermeture, ni possibilité de modifier une commande. Le runbook conserve un tableau par canal : action, endpoint ou écran, accusé attendu, temps maximal, fallback et owner.

Vérifier depuis l’extérieur de la chaîne interne

Une réponse API acceptée ne prouve pas le résultat visible. Contrôlez la fiche, le panier et si possible une requête de disponibilité indépendante. La vérification évite qu’un cache, une règle de stock minimum ou une republication partenaire maintienne l’offre après le gel.

Suspendez les campagnes liées et notez l’heure effective, sans effacer leurs données. Le trafic payant peut continuer à pousser une offre indisponible et aggraver coûts puis frustration. La reprise publicitaire possède sa propre porte, postérieure à la stabilité du stock.

Pour chaque commande, récupérez identifiant canal, identifiant interne et statut de paiement. Les actions de correction doivent être idempotentes : une seconde tentative d’annulation, de remboursement ou de message ne doit ni doubler l’effet ni créer une réponse différente sans alerte.

Réparer la promesse client avant que le silence ne l’aggrave

Un acheteur informé tôt peut accepter un délai, une substitution ou une livraison partielle. Informé après l’échéance, il subit l’incident et le silence. La communication commence donc dès que l’impossibilité est suffisamment probable, sans attendre la cause racine complète.

Proposer des options que les opérations peuvent réellement tenir

Le message nomme commande, ligne, situation, prochaine échéance et choix disponibles. Chaque option est prévalidée par stock, logistique, finance et canal. Ne promettez pas une réception fournisseur estimée comme une nouvelle date ferme pour gagner quelques heures.

Priorisez un contact humain pour valeur, urgence ou dépendance critique ; automatisez les cas homogènes avec suivi d’accusé. Le script laisse une marge de décision au support sans l’obliger à inventer une compensation. Toute préférence client retourne dans le ledger de promesse.

Mesurez délai entre confirmation du risque et premier contact, taux de réponse, option choisie, seconde rupture de promesse et contact répété. La réparation réussie n’est pas l’envoi d’un email ; c’est une nouvelle promesse tenue et compréhensible.

Encadrer remboursements, compensations et coût complet

Annulation, remboursement et geste commercial suivent des événements différents. Une autorisation de paiement peut être libérée, un encaissement doit être remboursé et une facture peut exiger un avoir. Le canal impose parfois ordre, délai ou plafond.

Réconcilier la réparation avec le settlement

Chaque mouvement financier porte commande, ligne, motif, devise, montant, taxe, identifiant PSP et preuve canal. Le rapprochement recherche doublons, frais non restitués et paiements restés capturés après annulation. Une confirmation client ne remplace pas la preuve de settlement.

Le coût d’incident additionne marge perdue, compensation, pénalité, publicité inutile, traitement support, transport urgent, correction technique et risque de classement. Cette vue évite de choisir une livraison express à cinquante euros pour sauver une commande dont la valeur relationnelle n’a jamais été évaluée.

Les seuils de compensation sont préparés avant incident et peuvent être dérogés avec approbation. Ils distinguent dommage subi, délai, valeur et récidive. Une règle uniforme paraît simple mais traite de la même manière un retard récupérable et une commande professionnelle bloquant une activité.

Erreurs fréquentes de réconciliation qui prolongent la survente

La fin de propagation ne signifie pas fin d’incident. Une commande peut rester dans une file, un remboursement attendre le PSP, une réservation survivre à l’annulation ou un canal republier une quantité depuis un cache. La réconciliation suit toutes les obligations ouvertes.

Comparer des invariants métier, pas seulement des totaux

Vérifiez que chaque commande possède une issue, que toute unité est physique, réservée ou disponible une seule fois, que toute annulation libère sa réservation et que tout remboursement correspond à un encaissement. Un total global équilibré peut cacher deux erreurs qui se compensent.

Les écarts sont classés par type, ancienneté et risque. Ils possèdent un owner et une échéance ; aucun ne disparaît sous une ligne « résiduel ». Les jobs automatiques restent suspendus tant qu’ils peuvent transformer un écart connu en nouvelle publication.

Le compteur de commandes exposées doit descendre de manière monotone. Toute remontée indique une propagation persistante, un périmètre initial incomplet ou une correction qui crée de nouvelles obligations. Le commandement réouvre alors la phase de confinement au lieu de négocier la métrique.

Par exemple, si une réservation reste ouverte 3 jours après son annulation, alors le seuil de clôture est refusé : l’équipe corrige son mouvement source avant de considérer le total global comme équilibré.

Rouvrir avec des portes techniques, client et business

La pression commerciale pousse à republier dès que le stock paraît positif. Une réouverture sûre exige pourtant une source autoritaire réconciliée, aucun événement inconnu, une quantité de sécurité et des canaux capables d’accuser la nouvelle valeur.

Réactiver par cohorte et dans le bon ordre

Commencez par un SKU, un canal et une quantité plafonnée. Réactivez publication avant publicité, observez commandes et réservations, puis élargissez. Les retries anciens sont purgés ou rejoués avant cette étape ; aucun message antérieur au correctif ne doit écraser la valeur réparée.

Ouvrez une cohorte limitée plutôt que le catalogue entier ; si son délai de convergence dépasse le seuil accepté, alors refermez-la et corrigez la dépendance avant tout élargissement.

La porte client vérifie que toutes les personnes affectées ont une nouvelle promesse ou une issue. La porte finance vérifie mouvements et remboursements lancés. La porte business accepte le risque résiduel, la marge de sécurité et la durée de surveillance renforcée.

Préparer un rollback de la réouverture

Définissez seuil de divergence, délai d’accusé, volume anormal et nouvelle commande impossible qui referment automatiquement la cohorte. Le rollback doit pouvoir stopper les ventes sans perdre les événements déjà reçus. Un owner garde cette autorité jusqu’à la fin de la fenêtre d’observation.

La clôture opérationnelle intervient seulement lorsque stock, commandes, clients et finance sont stables pendant la durée prévue. Les actions préventives peuvent rester ouvertes, mais leur transfert possède responsable, date et preuve attendue ; elles ne vivent pas dans un compte rendu oublié.

Dans quel cas appliquer le runbook : quinze ventes pour neuf unités

Une marque partage neuf unités entre quatre marketplaces. Un retry republie quinze après une réception partielle mal convertie. En vingt-deux minutes, onze commandes arrivent ; quatre autres existaient déjà. Le stock physique est correct, mais le disponible publié et les réservations ne racontent plus la même chose.

Les trente premières minutes

Le responsable ferme les quatre offres, suspend les campagnes et garde les événements entrants. L’équipe fige WMS, OMS, mappings et réponses canal. Neuf unités sont rattachées aux commandes selon délai et ordre d’acceptation ; deux commandes disposent d’une substitution confirmée.

Quatre commandes restent impossibles. Le support contacte les acheteurs avant l’échéance, propose délai ou remboursement et journalise leur choix. L’OMS corrige la conversion par mouvement versionné, puis reconstruit le disponible sans réutiliser le payload erroné.

La réouverture et la preuve de sortie

Une seule marketplace rouvre avec deux unités et sans publicité. Après deux heures sans divergence, les autres suivent par cohortes. Les quatre remboursements sont rapprochés au settlement ; les onze promesses tenables sont confirmées et aucune réservation orpheline ne demeure.

Le runbook ne fait pas disparaître l’incident, mais il limite son coût : propagation vingt-deux minutes, clients informés en moins d’une heure, zéro seconde promesse rompue. Le postmortem peut alors traiter la conversion de pack et le retry avec des preuves, pas avec des souvenirs.

Plan d’action après incident : convertir la timeline en prévention mesurable

Le postmortem décrit le système qui a autorisé l’échec, non la personne qui a exécuté la dernière action. Il relie condition latente, déclencheur, barrières absentes, détection, propagation et facteurs ayant limité l’impact.

Les entrées du plan sont la timeline, les écarts et les coûts ; ses sorties sont des contrôles vérifiables. Chaque action nomme un owner, un seuil d’acceptation, une dépendance et un repli si la correction dégrade le service.

Chercher les contrôles qui auraient changé la trajectoire

Un test de conversion aurait-il empêché le payload ? Un plafond de variation aurait-il bloqué quinze ? Un accusé observé aurait-il détecté le retry ? Un stock de sécurité aurait-il absorbé la différence ? Chaque action répond à un point précis de la timeline et possède une mesure de vérification.

Classez les actions en prévention, détection, confinement et réparation. Ajouter uniquement une alerte laisse la propagation possible ; ajouter uniquement un correctif peut déplacer l’erreur. La défense utile combine limite de variation, idempotence, invariant de réservation et exercice régulier du runbook.

Suivre des indicateurs qui annoncent la prochaine survente

Surveillez âge des réservations, fréquence des corrections, écarts WMS-OMS-canal, latence de publication, réponses sans accusé et commandes reçues après fermeture. Segmentez par SKU, canal, job et version pour distinguer bruit récurrent et dérive concentrée.

La mise en œuvre relie instrumentation, monitoring et journalisation à une file de retry idempotente. La responsabilité de validation reste séparée de l’exécution, et un test de rollback prouve le retour au dernier état sûr.

Exercez un scénario trimestriel avec un faux SKU ou un environnement contrôlé : fermeture, snapshot, priorisation, message, remboursement simulé puis réouverture. Le temps de détection compte, mais la vraie maturité se mesure au temps nécessaire pour prouver que plus aucune promesse inconnue ne subsiste.

  1. D’abord, confiner les écritures et lancer une horloge commune sans supprimer les événements entrants.
  2. Ensuite, figer les versions et construire un ledger qui rattache chaque commande à une unité ou à un déficit.
  3. Puis, réparer clients, stock et finance avec des mouvements idempotents, approuvés, traçables et entièrement réconciliés.
  4. À faire enfin : rouvrir par cohorte sous plafond, surveiller la convergence et transformer la timeline en contrôles testables.

Guides complémentaires : empêcher la récidive dans la chaîne stock

Le runbook traite l’incident déclaré. La prévention dépend de la qualité du stock promettable, de l’allocation entre canaux et de la capacité à détecter la première divergence avant qu’elle ne devienne une promesse client.

Relier disponibilité, arbitrage et diagnostic

La méthode d’ATP marketplace définit la quantité réellement promettable. L’allocation cross-marketplaces empêche ensuite plusieurs canaux concurrents de consommer simultanément la même unité disponible.

Le diagnostic du stock fantôme marketplace retrouve la première rupture entre fait physique, réservation et publication. Le réapprovisionnement probabiliste réduit enfin les pénuries futures sans transformer une réception incertaine en promesse ferme.

Ciama pour les opérations marketplace centralise les signaux de stock et les écarts de canal afin que le pilotage vendeur retrouve plus vite la première divergence et son périmètre réel.

Ensemble, ces pratiques créent une chaîne défendable : une unité n’est promise qu’une fois, son canal est choisi explicitement, chaque divergence possède une preuve et le prochain approvisionnement reste séparé du stock déjà disponible.

  • À prioriser : offres à forte vélocité, stock partagé, publication lente et réservations dont l’âge dépasse le délai de décision.
  • À surveiller : corrections manuelles répétées, variation brutale, retry sans clé, mapping de pack et commandes après fermeture.
  • À refuser : toute réouverture sans ledger des commandes, accusé de canal, quantité de sécurité et rollback exercé.

Conclusion : réparer la promesse avant de relancer la vente

Une survente devient majeure lorsque les nouvelles commandes continuent pendant que les équipes cherchent la cause. Le premier geste utile consiste donc à confiner les promesses et à préserver chaque événement nécessaire à la reconstruction.

Le ledger transforme ensuite un déficit global en décisions commande par commande. Stock, client, canal et finance avancent sur la même timeline ; chaque correction possède une source, un owner, un accusé et une condition de repli.

La réouverture n’est pas un retour à la normale déclaré. C’est une cohorte plafonnée qui prouve la convergence, puis une surveillance capable de refermer avant qu’un nouvel écart ne se transforme en seconde rupture de promesse.

Pour construire et exercer ce dispositif, l’accompagnement de notre agence marketplace relie vérité de stock, service client et contribution afin que chaque incident soit contenu, réparé et transformé en prévention mesurable.

Portrait de Jérémy Chomel

Vous cherchez une agence marketplace pour vendeurs ?

Dawap part du problème décrit ici pour identifier les flux, données et opérations à fiabiliser, protéger la marge et réduire les reprises manuelles.

Vous préférez échanger ? Planifier un rendez-vous

Articles recommandés

Traçage du stock entre ERP, WMS, OMS, réservations et marketplaces pour isoler une divergence de quantité Agence marketplace Stock fantôme marketplace : trouver la première divergence Lire l'article
  • 3 août 2026
  • Lecture ~13 min

Un stock fantôme n’est pas seulement un flux trop lent. Cette méthode reconstitue identité SKU, autorité, événements, réservations, délais et publications pour retrouver le premier état divergent, réconcilier les quantités sans surcorriger puis empêcher le retour des surventes, des ruptures artificielles et des corrections manuelles en boucle.

Calcul d’un stock ATP marketplace avec réservations, sécurité et qualité des flux Agence marketplace Calculer un ATP marketplace fiable Lire l'article
  • 2 août 2026
  • Lecture ~13 min

Le stock physique ne constitue jamais une promesse de vente exploitable. Cette méthode construit un ATP marketplace par SKU, entrepôt et canal avec réservations, stock de sécurité, délais, fraîcheur des flux et niveau de confiance, puis organise les contrôles qui réduisent simultanément survente et sous-exposition.

Allocation d’un stock partagé entre plusieurs marketplaces selon marge et promesse Agence marketplace Allouer chaque unité au bon canal Lire l'article
  • 1er août 2026
  • Lecture ~13 min

Diffuser le stock ERP sur tous les canaux transforme une quantité physique en plusieurs promesses concurrentes. Ce guide construit un stock allouable, des réserves, des quotas et un moteur explicable qui arbitre demande, contribution, buy box, capacité et niveau de service sans masquer les exceptions.

Stock central relié à des délais fournisseurs variables et à des niveaux de service distincts par canal marketplace Agence marketplace Réapprovisionnement probabiliste marketplace Lire l'article
  • 4 août 2026
  • Lecture ~16 min

Une moyenne de ventes et un délai fournisseur théorique ne suffisent pas à décider quand commander. Cette méthode estime la demande pendant une période de protection variable, distingue taux de service et disponibilité utile, simule ruptures puis surstocks, et transforme chaque commande en décision explicable par SKU, fournisseur et canal.