Ce que vaut une journée de rayon vide.
marql repère les SKU tombés à zéro qui se vendaient encore et chiffre l'absence à partir de vos propres ventes, pas du coût. Ce playbook pousse ce chiffre des deux crans que l'écran ne franchit pas — par la marge, puis par la substitution — et pose les trois options réelles côte à côte : payer pour être livré plus tôt, absorber le trou, ou contourner par un substitut.
En jeu
381 €
par semaine — dont 38 € rachetables
- chiffré sur les ventes, pas le coût
- tourne avec une caisse et un flux de stock
- récupérable ≠ en jeu
Écrans du marché démo Mercado Claro, capturés le 1er septembre 2026. L'interface y est en mode sombre et marql AI répond en espagnol sur ce tenant ; le playbook 01 montre un autre marché en mode clair. Les chiffres sont générés et le tenant avance sa propre horloge : ce sont des instantanés, pas des constantes.
Le rayon est vide. La demande, non.
Chez Mercado Claro une référence est à zéro à Madrid · Malasaña — Granola artesanal, deux jours de suite — et marql la chiffre comme elle chiffre tout : à partir des ventes du magasin lui-même. L'incident affiche ≈381 € par semaine en jeu jusqu'au réassort. C'est là que le produit s'arrête et que la décision commence, parce que 381 €, ce n'est pas ce que la chaîne perd, et ce n'est surtout pas ce que vaut un coursier. Deux multiplications séparent le chiffre de l'écran du chiffre sur lequel un acheteur peut agir, et toutes deux le réduisent.
- 381 €
- ventes hebdomadaires en jeu
- 223 €
- de marge à l'intérieur
- 38 €
- à payer au plus pour deux jours
- 2
- jours de suite
D'un rayon à zéro à une décision chiffrée.
Quatre étapes, et la troisième est celle qu'on saute d'habitude : les options n'ont pas le même prix, et la moins chère est souvent de ne rien faire et de l'écrire.
Un SKU qui se vendait est maintenant à zéro.
Un scan quotidien croise l'instantané de stock avec l'historique de ventes et remonte les SKU qui ont fait du chiffre sur les 30 derniers jours et n'ont plus de stock aujourd'hui. Les lignes se regroupent en un incident par magasin, et non un par SKU, et arrivent triées en couloirs selon la nature de l'argent en jeu — une fuite hebdomadaire récurrente, des ventes qui s'épuisent, du capital immobilisé — la barre sous chaque ligne indiquant combien. La rupture occupe son propre couloir à 381 €, sous trois fuites qui valent davantage par semaine et au-dessus du surstock dont traite le premier playbook de cette bibliothèque.
Scan quotidien · un incident par magasin · longueur de barre = argent en jeu
Une journée d'absence reçoit un montant, tiré des ventes et non du coût.
Le taux vient des ventes récentes du SKU lui-même, ni d'une moyenne de catégorie ni d'un prix de tarif. C'est ce qui fait de ce playbook le seul à tourner avec une caisse et un flux de stock : jusqu'ici, aucune donnée de coût n'est nécessaire. Le chiffre est hebdomadaire parce que c'est la période que porte l'incident. Le ramener à la journée reste le travail du lecteur, pas un nombre que le produit invente.
Chiffré sur les ventes du SKU · sans donnée de coût
Il distingue une référence qui s'est arrêtée d'une référence qui s'est éteinte.
marql regarde si quelque chose est en commande, si le même SKU est en stock ailleurs sur le réseau, et si ce magasin s'est déjà vidé auparavant. Une répétition à la même adresse est un problème d'approvisionnement déguisé en problème de rayon, et le produit fait remonter le décompte au lieu de le laisser à la mémoire — c'est la différence entre régler une rupture et payer pour la même chaque mois.
En commande · ailleurs sur le réseau · nombre de répétitions
Disponibilité rétablie n'est pas chiffre d'affaires récupéré.
Une fois l'action confirmée, marql fige la période de référence et la fenêtre de mesure, et cette fenêtre doit survivre au pic de réassort : les premiers jours après le remplissage écoulent la demande accumulée pendant le vide et flattent toute décision mesurée contre eux. Autant être précis sur l'endroit où cela vit : sur ce tenant, le registre d'impact est un rapport daté rangé parmi les vues enregistrées, avec des données au 10 août 2026, et non une surface vivante qui se met à jour sous vos yeux. Une revue qu'il faut ouvrir reste une revue ; une revue que personne n'ouvre, non.
Rapport daté · référence figée à la validation · fenêtre au-delà du pic
Zéro peut être le bon chiffre.
L'arithmétique n'est pas en cause : le SKU se vendait et il n'a plus de stock. Ce qui est en cause, c'est de savoir si quelqu'un doit agir. Dans cinq situations ordinaires, le rayon vide est l'état voulu, et l'acheteur qui paie pour avancer la livraison dans l'une d'elles paie un surcoût pour défaire la décision d'un autre.
La référence est écoulée volontairement
Un SKU déréférencé atteint zéro exactement comme prévu, et le plan vit dans la tête d'un acheteur ou dans un tableur que le produit n'a jamais vu. Le signal lit une référence qui s'est bien vendue pendant 28 jours puis s'est arrêtée, ce qui est précisément l'allure d'un écoulement maîtrisé vu des données.
Y a-t-il quelque chose en commande, et un remplaçant se vend-il déjà dans la même sous-catégorie ? Un écoulement planifié n'a ni commande ouverte ni trou dans le chiffre de la sous-catégorie — le successeur l'absorbe déjà.
La saison est finie et la fenêtre n'a pas suivi
Le taux lit les ventes récentes du SKU. Sur une référence saisonnière, cette fenêtre chevauche la fin de saison et continue de citer une demande déjà partie. Le rayon est vide parce que personne n'achète, pas parce que rien n'est arrivé.
Même SKU, mêmes semaines l'an dernier. Si le rythme chutait alors comme il chute maintenant, la saison est finie. Si l'an dernier vendait encore à ce stade, elle ne l'est pas.
Le remplaçant est déjà en rayon sous un autre code
Un changement de format, un changement de fournisseur ou une reformulation donnent au même produit un nouveau SKU. L'ancien code tombe à zéro et y reste, à juste titre, tandis que la demande se poursuit intacte un code-barres plus loin.
Le chiffre de la sous-catégorie sur les mêmes jours. Si la sous-catégorie est stable pendant que le SKU est à zéro, la demande n'est pas partie : elle s'est déplacée, et il n'y a rien à récupérer.
Une série limitée qui ne devait jamais être réapprovisionnée
Un achat ponctuel, une fin de série fournisseur, une collaboration avec une date de fin imprimée. L'épuisement est le résultat pour lequel l'achat a été conçu, et l'alerte est une description du succès.
Le réassort a-t-il jamais été possible ? Existe-t-il une fiche fournisseur avec un délai, ou la commande initiale était-elle le tout ? Un SKU sans voie de réassort ne s'accélère à aucun prix.
Le rayon est vide, la réserve non
Le scan lit le comptage enregistré, et ce comptage est strictement nul. Du stock physiquement en réserve, non saisi, ou saisi sur la mauvaise implantation se lit exactement comme du stock qui n'existe pas. C'est le plus fréquent des cinq dans une vraie chaîne, et le moins cher à résoudre.
Y a-t-il encore des ventes sur un SKU que le système donne à zéro ? Cette combinaison est impossible et tranche la question sans que personne quitte le bureau. Si les ventes se sont arrêtées aussi, la vérification consiste à ce que quelqu'un aille en réserve — et la réponse va au registre, parce qu'un zéro fantôme non consigné revient chaque semaine.
En bref
Aucun de ces cas ne fait réapparaître le chiffre d'affaires là où il était réellement en jeu. Ce qui change, c'est que quatre des cinq transforment l'action en « ne rien faire, et écrire pourquoi », et le cinquième en « aller voir » plutôt qu'en « payer pour accélérer ». marql ne peut reconnaître un motif que lorsque le motif est dans les données : une commande ouverte, une sous-catégorie stable, une fiche fournisseur. Un écoulement qui vit dans la tête d'un acheteur lui est invisible, et la dérogation qui consigne cet écoulement est l'artefact utile.
Le rayon était vide. La décision a raté quand même.
Cinq façons de se tromper une fois le signal juste, dans l'ordre où elles surviennent : le mauvais argent, la mauvaise urgence, la mauvaise adresse, la mauvaise victoire et la mauvaise comptabilité. Ces scénarios sont construits, pas observés : aucun chiffre d'une chaîne réelle ne les sous-tend.
Payer un surcoût contre le chiffre d'affaires au lieu de la marge
381 € par semaine rendent un coursier à 100 € évident. Mais la décision ne récupère pas 381 € : elle récupère la marge brute des unités qui, sinon, n'auraient pas été vendues du tout — environ 223 € aux marges de ce tenant — et de cela, seulement la part qui ne part pas vers un autre produit en gagnant sa marge quand même. Racheter deux jours sur une semaine de sept vaut environ 38 €. Le coursier perd de l'argent, et rien à l'écran ne le dit.
Multipliez avant de décider : ventes en jeu, par la marge, par la part qui ne se reporterait pas, par les jours réellement gagnés divisés par sept. Ce résultat est le plafond du surcoût. Sur cette référence, il vaut le dixième du chiffre affiché, pas la moitié.
Accélérer une demande déjà partie
Un produit de base est absent depuis neuf jours. Le surcoût est payé le huitième jour, la palette arrive le neuvième, et les clients venus le chercher la première semaine ont déjà reconstitué leur panier ailleurs. Les unités arrivent ; la demande ne revient pas avec elles. Accélérer rachète les jours retirés au début du trou, pas ceux déjà consommés.
Jours gagnés, pas jours d'absence. Si la livraison devait arriver le vendredi et que le surcoût la ramène au mercredi, l'arithmétique porte sur deux jours. Et sur une référence absente depuis plus longtemps qu'un cycle d'achat, retenez un taux de récupération inférieur à la valeur par défaut du calculateur, pas identique.
Réparer au rayon quand la cause est en amont
Un magasin se vide, reçoit un transfert, et se vide de nouveau trois semaines plus tard. Chaque réponse individuelle était juste et aucune n'a touché la raison : une quantité de commande inférieure au rythme réel du magasin, un délai laissé à une valeur par défaut que personne n'a vérifiée, ou une tournée de livraison qui saute cette adresse. Le surcoût est payé tous les mois et le défaut n'apparaît jamais, parce que chaque événement se clôt de son côté.
Comptez les événements par magasin sur 30 jours avant de choisir l'action. Une répétition n'est pas une rupture : c'est un défaut d'achat ou de logistique qui se présente comme telle, et l'accélérer chaque mois revient à s'abonner au symptôme.
Substituer vers un produit moins bon et appeler cela un gain
Le client est orienté vers l'article voisin, le total de caisse de la journée tient, et l'incident se clôt comme traité. Mais le substitut porte moins de marge, et la chaîne a échangé une absence à forte marge contre une présence à faible marge sans que personne note la différence. La ligne de chiffre d'affaires est restée plate, ce qui est précisément pourquoi personne n'a regardé la ligne de marge.
La substitution est une action légitime et elle a un prix : l'écart de marge unitaire entre les deux SKU, multiplié par les unités. Si cet écart est inconnu faute de prix de revient, alors la substitution est une action non chiffrée et doit être consignée comme telle, pas comme une victoire.
Mesurer à cheval sur le pic de réassort
Le rayon se remplit et les premiers jours écoulent la demande accumulée pendant le vide. Mesurée contre ces jours-là, toute action ressemble à un triomphe. Mesurée sur le mois suivant, la référence est revenue où elle était et le registre a déjà comptabilisé la récupération.
Référence et fenêtre figées à la validation de l'action, jamais une fois les chiffres connus, et fenêtre assez longue pour contenir des cycles hebdomadaires entiers plutôt que les jours qui suivent immédiatement le remplissage. Le registre d'impact doit pouvoir renvoyer « aucun effet » et « données insuffisantes » : un registre qui ne dit jamais que « prouvé » ne mesure rien.
En bref
Quatre des cinq sont une mauvaise action choisie à partir d'un bon chiffre, et le cinquième est une bonne action consignée malhonnêtement — la même forme que dans le playbook 01, parce que c'est le même manque de nerf au même point du cycle. Les deux qui pèsent le plus sont le premier et le troisième : l'un fait reposer une décision sur un argent qui n'est pas vraiment là, l'autre continue de résoudre un problème à la mauvaise adresse.
Commencez par celle qui compte
Parmi les rayons vides d'aujourd'hui, lesquels valent la peine d'être réassortis plus tôt ?
Des anomalies sur les 7 derniers jours ?
1 anomalie détectée — aucune alerte active.
DATA FRESHNESS · POS synced 6 min ago · accounting 4 h ago
- 01Quels SKU sont à zéro aujourd'hui alors qu'ils ont fait du chiffre sur les 30 derniers jours ?
- 02Combien rapporte chacun par jour de vente, et quelle est la marge dessus ?
- 03Lesquels ont quelque chose en commande, et pour quand ?
- 04Lesquels sont en stock dans un point assez proche pour un transfert ?
- 05Quels magasins se sont vidés plus d'une fois sur les 30 derniers jours, et sur quoi ?
- 06Rédigez le plan : action, responsable, échéance et fenêtre de jugement.
Ce qu'il faut pour chiffrer une journée d'absence.
Stock disponible par SKU × point de vente
Un instantané quotidien, pas un comptage en direct. Sans lui ce playbook ne tourne pas du tout — et une connexion uniquement caisse ne le porte souvent pas, ce qui est la première chose à vérifier plutôt que la dernière.
Ventes par SKU × point de vente
Quantité, montant et date, sur au moins les 28 jours précédents. C'est ce qui met un prix sur la journée, et c'est pourquoi le playbook tourne sans donnée de coût.
Marge brute du SKU
Sans elle, l'absence se compte toujours et se classe par chiffre d'affaires, mais le plafond de ce que vaut son raccourcissement ne se calcule pas — la colonne de décision reste donc vide plutôt qu'estimée à partir d'une moyenne réseau.
Délai de livraison et commandes en cours
Fournisseur, commandes ouvertes et date de livraison observée. Ils déterminent combien de jours un surcoût achète réellement, et c'est le multiplicateur dont dépend toute la décision.
Comment ce chiffre a été calculé
Le scan, la fenêtre et l'arithmétique.
Les mots du produit lui-même, tirés du bloc qu'il imprime sous l'incident : le scan parcourt les lignes journalières par produit — ventes, coût, stock — et nomme les SKU exacts derrière l'argent, de sorte que chaque élément listé porte sa propre contribution en € et non une part d'un total.
Lignes journalières par SKU, typiquement une fenêtre de 7 à 28 jours selon le contrôle ; les contrôles de tendance comparent deux fenêtres adjacentes de même longueur. Le chiffre est exprimé par semaine parce que c'est la période que porte l'incident.
- marge en jeu par semaine = ventes hebdomadaires en jeu × marge brute
- récupérable = marge en jeu par semaine × (1 − taux de substitution)
- à payer au plus pour gagner un jour = récupérable ÷ 7 × jours gagnés
- Synchronisation caisse / ERP
- product_sales_daily · inventory_daily
- scan par SKU
- incident, regroupé par magasin
- inventory_daily
- qty_in_stock
- product_sales_daily
- product_ext_id, revenue
Deux choses que ce bloc ne lissera pas. D'abord, le coût n'apparaît pas dans les colonnes que lit le contrôle, ce qui est exactement pourquoi ce playbook tourne avec une caisse et un flux de stock — et tout autant pourquoi l'étape de marge ci-dessous est le chiffre du lecteur et non celui du produit. Ensuite, les deux surfaces ne concordent pas : le 1er septembre 2026, l'incident affichait ≈381 € par semaine sur Granola artesanal tandis que marql AI, interrogée sur le même SKU dans la même minute, répondait ~316,80 € par semaine — environ 53 € par jour pour une demande journalière moyenne de 9,6 unités à 5,50 € en rayon, multipliés par six jours et non par sept. Soit environ 65 € d'écart sur un chiffre de 381 €. Aucun des deux nombres n'est inventé et cette page ne va pas désigner un favori ; ce qu'elle fait, c'est noter qu'une décision de cette taille ne devrait pas se prendre sur un chiffre qui bouge d'un sixième selon l'écran où on le lit.
Vérifiez-le sur vos propres chiffres
Les trois équations ci-dessus, champs à découvert. Le calculateur s'ouvre sur les chiffres de ce playbook : la première chose qu'il imprime, ce sont les 381 € du chapeau transformés en le nombre sur lequel on décide réellement — changez un champ et l'arithmétique suit.
- Marge en jeu par semaine
- 223 €
- À payer, au plus
- 38 €
Deux de ces quatre champs sont des hypothèses, pas des relevés. La marge s'ouvre à 58,5 %, la moyenne mêlée de ce tenant, parce que l'incident ne porte pas de colonne de coût pour ce SKU : utilisez la vôtre. Le taux de substitution s'ouvre à 40 % parce qu'un chiffre plausible est plus utile qu'un blanc, et c'est le seul nombre ici que personne ne peut aller chercher sans données de lignes de ticket. Le calculateur ne chiffre pas le surcoût : cela vient d'un devis de votre fournisseur ou de votre transporteur. Et il ignore si les jours saisis sont des jours d'absence ou des jours gagnés — le mode de défaillance 02 est précisément cette différence.
Trois options, trois bureaux différents.
Les trois actions de ce playbook appartiennent à trois périmètres différents, et aucun ne peut prendre les deux autres. C'est inhabituel — la plupart des décisions se concentrent — et cela explique pourquoi un rayon vide reçoit si souvent la réponse que la personne la plus proche est capable de donner plutôt que la bonne. Le produit ne s'en remet pas à l'usage : la feuille de commande ci-dessous porte la quantité, l'horodatage du buffer dont elle provient, et la phrase « seul le propriétaire ou le directeur des opérations peut créer un brouillon de commande ». Le périmètre est appliqué, pas suggéré.
Responsable de magasin
Ses magasins uniquement, et le seul périmètre qui détient un fait qu'aucun autre n'a : savoir si le rayon et la réserve sont d'accord.
- Le contre-cas 05 : aller en réserve, et consigner ce qui s'y trouvait.
- La substitution en rayon — orienter la demande vers le SKU vivant le plus proche, et dire lequel.
- Si la référence est physiquement vendable : abîmée, mal étiquetée, périmée.
Le surcoût d'accélération et le transfert. Les deux sont des coûts engagés hors de ce périmètre contre un bénéfice mesuré dedans, et ni l'un ni l'autre n'apparaît dans cette boîte de réception.
Le nombre de jours entre le zéro enregistré et le rayon réassorti, et si les zéros fantômes signalés sont restés signalés.
Responsable de région
Un groupe de magasins, et le premier périmètre capable de voir le même SKU en stock à une adresse et absent à une autre.
- Le transfert, parce que c'est le premier périmètre qui en voit les deux extrémités.
- L'arbitrage entre déplacer du stock et attendre — la comparaison qui doit inclure la journée que coûte le transfert lui-même.
- Quel rayon vide est un problème du réseau et lequel est local.
L'achat qui a créé le trou et le délai contre lequel il a été passé. Une région peut déplacer le stock qu'elle détient déjà ; elle ne peut pas en faire arriver davantage.
Les jours d'absence sur le groupe, et la part refermée en déplaçant du stock plutôt qu'en payant pour la vitesse.
Propriétaire
Le réseau entier, et le seul périmètre qui voit le même magasin se vider de façon répétée plutôt qu'un magasin se vider une fois.
- Le surcoût d'accélération : la seule action ici qui dépense de l'argent pour acheter du temps.
- La quantité de commande et le délai derrière le mode de défaillance 03 — la cause, pas le symptôme.
- La décision d'absorber un trou et de la consigner comme une décision, pas comme un oubli.
Le seul fait que détient le plus petit périmètre : savoir si la palette est en réserve. Tout surcoût payé sur un zéro fantôme a été autorisé à ce niveau et n'aurait pu être évité qu'à l'autre bout.
Surcoût dépensé contre marge récupérée, et si les magasins qui se sont vidés deux fois se sont vidés une troisième.
NETWORK REVENUE · LAST 30 DAYS
354 000 €−1.2%
Rivoli
54 000 €−0%−2%Bastille
39 900 €+2%−0%Lyon Part-Dieu
39 500 €−16%−17%—En bref
Ce sont les trois périmètres que livre le produit, pas une affirmation sur la façon dont une chaîne devrait être organisée. Une chaîne dotée d'une cellule centrale de réassort a un poste qu'aucun des trois ne décrit, et ce playbook ne va pas l'inventer. Faites correspondre vos propres intitulés aux périmètres plutôt que l'inverse — et notez que sur cette décision l'action la moins chère appartient au plus petit périmètre, ce qui est l'inverse de l'ordinaire et la raison pour laquelle on la saute.
Tout ce qui précède, sur un tableur.
Rien de tout cela n'exige marql. Ce que le produit automatise, c'est le scan quotidien de tous les SKU et de tous les points de vente ; la méthode tient en trois décisions et une vingtaine de champs, et pour un magasin elle se fait à la main en une après-midi. Prenez-la. Si l'arithmétique continue de changer ce que vous auriez fait, voilà l'argument pour l'automatiser.
Est-ce le rayon qui est vide, ou l'enregistrement ?
Le contre-cas 05 et les modes de défaillance 02 et 03 réunis dans un arbre. Il se parcourt avant toute discussion d'argent, parce que trois de ses quatre issues ne coûtent rien.
Ce SKU a-t-il vendu quoi que ce soit depuis que le comptage est passé à zéro ?
- OuiC'est l'enregistrement qui est faux, pas le rayon. Retrouvez le stock, corrigez le comptage et consignez la cause : un zéro fantôme non consigné revient chaque semaine et coûte un surcoût à chaque fois.
- NonLe rayon est réellement vide. Continuez.
L'un des contre-cas de la section 03 s'applique-t-il — un écoulement volontaire, une saison finie, un remplaçant sous un autre code, une référence qui ne devait pas revenir ?
- OuiConsignez lequel, qui l'a décidé et quand la décision doit être revue. N'agissez pas. C'est cette trace qui empêche la chose d'arriver comme une surprise chaque semaine.
- NonLa demande est réelle et non servie. Continuez.
Combien de fois ce magasin est-il tombé à zéro sur les 30 derniers jours ?
- Plus d'une foisTraitez le schéma, pas l'événement. Comparez la quantité de commande au rythme réel du magasin et le délai au délai observé avant de dépenser quoi que ce soit en vitesse — c'est le mode de défaillance 03.
- Une foisUn événement isolé. Passez à la partie 02.
Le même SKU est-il en stock dans un point assez proche pour un transfert sans mettre ce point à découvert ?
- OuiComparez le transfert au surcoût dans la partie 03 — le transfert coûte lui aussi une journée, et la couverture du point expéditeur doit y survivre.
- NonLe choix est : accélérer ou absorber. Allez à la partie 02.
Une issue parmi cinq : corriger le comptage, consigner un motif et ne rien faire, corriger la cause en amont, transférer, ou chiffrer l'attente dans la partie 02.
Ce que vaut une journée d'absence
Le mode de défaillance 01 en version tableur : les trois multiplications entre le chiffre affiché et le chiffre sur lequel on décide. Chaque ligne est plus petite que la précédente, et c'est tout l'intérêt.
- Ventes hebdomadaires en jeu, telles que l'incident les imprime
- Directement depuis l'incident, ou depuis un export de ventes. Aucune donnée de coût n'est nécessaire jusqu'ici : le contrôle qui déclenche l'alerte ne lit pas de colonne de coût.
- Demande journalière moyenne et prix de vente
- Notez les deux. Sur le SKU de la démo, c'est 9,6 unités par jour à 5,50 €, d'où les ~53 € par jour — et c'est en faisant ce produit que vous découvrirez si le chiffre hebdomadaire de votre écran a utilisé six jours ou sept.
- Ventes hebdomadaires en jeu, réconciliées
- Demande journalière par le prix, par sept. Si cela ne correspond pas au chiffre imprimé par l'incident, vous avez trouvé le même désaccord que ce playbook : notez lequel vous utilisez et pourquoi, car tout ce qui suit en hérite.
- Marge brute du SKU
- La marge du SKU lui-même, pas celle de la catégorie ni celle de la chaîne. Si les prix de revient manquent, arrêtez-vous ici et classez par chiffre d'affaires : une marge estimée transforme un plafond en une supposition portant une décimale.
- Marge en jeu par semaine
- Ventes en jeu par la marge. L'accélération récupère ceci, jamais la ligne au-dessus.
- Part de la demande qui se reporte
- C'est une hypothèse et elle doit être étiquetée comme telle sur la feuille. Personne ne peut la consulter sans données de lignes de ticket. Les produits de base qui ont un voisin proche en rayon se reportent beaucoup. Une référence de destination, celle pour laquelle les gens se sont déplacés exprès, ne se reporte presque pas.
- Marge récupérable par semaine
- Marge en jeu par un moins la part qui se reporte. Divisez par sept et multipliez par les jours que le surcoût achète réellement : c'est ce produit, et non cette ligne, auquel le surcoût se compare.
Un chiffre : ce qu'une semaine de rayon vide coûte réellement en marge récupérable — et le taux journalier en dessous.
Arriver plus tôt vaut-il ce que cela coûte ?
La bifurcation elle-même. Trois options, une comparaison, et une quatrième ligne que presque personne n'écrit : ne rien faire a un prix, et c'est souvent le plus bas de la page.
- Date de livraison sans intervention
- La date observée, pas la date contractuelle. Si les trois dernières livraisons sont arrivées en retard, l'observée est la vraie.
- Date de livraison avec le surcoût payé
- Confirmée avec le fournisseur ou le transporteur, pas supposée. Une date non confirmée n'achète rien.
- Jours réellement gagnés
- L'écart entre les deux lignes précédentes. Pas les jours déjà passés en rupture : ceux-là sont perdus à n'importe quel prix, c'est le mode de défaillance 02.
- Plafond du surcoût
- Marge récupérable par semaine, issue de la partie 02, divisée par sept et multipliée par les jours gagnés. Tout devis au-dessus de cette ligne perd de l'argent même quand il fonctionne. Sur le SKU de la démo, cela fait environ 38 € pour deux jours, face aux 381 € affichés.
- Surcoût devisé
- Coût total de l'arrivée anticipée, y compris ce qu'ajoute la tournée accélérée : un lot partiel, une livraison hors horaires, un chauffeur.
- Coût du transfert, s'il est possible
- Le transport, plus la journée qu'il prend, plus la marge risquée au point expéditeur. Un transfert qui vide un autre rayon a déplacé le problème, pas résolu.
- La décision, et son prix
- Accélérer, transférer, substituer ou absorber — et le nombre qui en a fait la moins chère des quatre. Absorber est une décision avec un prix, et écrire ce prix est ce qui en fait une.
Une action choisie avec l'arithmétique qui l'a choisie, et un prix consigné pour l'option écartée.
Fixez la mesure avant d'agir.
Le mode de défaillance 05 en version tableur, et la seule partie avec une échéance : chaque champ se remplit avant l'action, parce qu'une fois le résultat connu aucun ne peut plus être choisi honnêtement. Les indications nomment ce qu'exige le registre de marql, de sorte qu'un tableur tenu à ce standard et le produit répondent à la même question.
- L'action, en une phrase
- Ce qui est fait, sur quel SKU, dans quel point de vente, à quel coût.
- Responsable
- Un nom détenant un périmètre capable de prendre réellement l'action — section 07. Sur cette décision, les trois options appartiennent à trois périmètres différents.
- Référence, figée maintenant
- Le chiffre contre lequel l'effet sera mesuré, écrit et non recalculé ensuite. Sur un tableur, le figer veut dire coller la valeur plutôt que laisser une formule qui bougera.
- Fenêtre de mesure
- Dates exactes, choisies maintenant. Elle doit commencer après le pic de réassort et non pendant, et couvrir des cycles hebdomadaires entiers : mesurer à cheval sur le remplissage, c'est le mode de défaillance 05.
- La métrique
- Jours de rupture sur ce SKU dans ce point de vente. Une seule métrique : la seconde est la façon dont on choisit après coup le résultat qui arrange. Le chiffre d'affaires est un mauvais choix ici, car il bouge pour des raisons que cette action n'a pas causées.
- Témoins appariés
- Des points de vente comparables n'ayant pas reçu l'action. marql ne déclare pas une ligne prouvée en dessous de quatre magasins témoins appariés ; sans pairs, il retombe sur la volatilité propre de l'unité, ce qui est une affirmation plus faible et doit être étiquetée comme telle.
- Ce qui invaliderait la fenêtre
- Une promotion sur le SKU ou son substitut le plus proche, un changement de prix, un changement de fournisseur, ou une seconde rupture à l'intérieur de la fenêtre. Avec l'un de ces événements, le verdict honnête est « non concluant », pas « prouvé ».
- Ce qui compte comme aucun effet, et comme pire
- Les deux, écrits avant de les connaître. Ici « pire » est atteignable : un surcoût payé qui a acheté moins de jours que devisé a dépensé de l'argent pour rien.
Une ligne qui peut se clore dans six directions — trouvé, en mesure, prouvé, aucun effet, non concluant, pire. Si les trois dernières sont inatteignables dans votre version, les trois premières ne valent rien.
En bref
Voilà toute la méthode. Ce que marql ajoute n'est pas une meilleure équation : il fait tourner le scan chaque jour sur tous les SKU et tous les points de vente plutôt que sur le rayon devant lequel quelqu'un est passé, regroupe les lignes par magasin pour qu'une répétition apparaisse comme un schéma et non comme neuf incidents séparés, et tient le registre pour qu'une ligne close ne puisse pas être rouverte discrètement et améliorée. L'arithmétique ci-dessus est la même dans les deux cas — et le taux de substitution est un nombre qu'aucun de nous deux ne peut mesurer.
09 · Là où la preuve s'arrête
Chiffre d'affaires en jeu
≠ récupération prouvée.
381 €, ce sont des ventes hebdomadaires en jeu sur un SKU dans un point de vente — le chiffre que porte l'incident lui-même, visible sur l'écran en haut de cette page. Ce n'est pas une perte : une partie de cette demande achète autre chose dans la même visite et gagne sa marge quand même. Quelle part exactement est le seul nombre de ce playbook que personne ne peut mesurer sans données de lignes de ticket, et marql ne le détient pas — c'est pourquoi le calculateur le demande au lieu de l'imprimer.
Ce n'est pas non plus de la marge. L'accélération récupère la marge brute des unités qui, sinon, n'auraient pas été vendues du tout — environ 223 € aux marges de ce tenant — et la part récupérable de cela, sur les jours qu'un surcoût achète réellement, tourne autour de 38 €. Le chiffre affiché et le chiffre sur lequel un acheteur peut agir diffèrent ici d'un facteur dix, et toujours dans le même sens.
Et ce n'est pas un effet prouvé. Celui-ci n'est enregistré qu'une fois l'action exécutée, la référence figée et la fenêtre de contrôle refermée au-delà du pic de réassort. Lorsque les données sont insuffisantes ou qu'un facteur extérieur a faussé le résultat, le registre d'impact marque l'effet comme non prouvé. Le tenant démo avance sa propre horloge : chaque chiffre ici est un instantané, pas une constante.
Ce que le produit fait, en revanche — et l'écran ci-dessous en est l'exemple le plus net — c'est imprimer les conditions à côté du relevé : quelle part de la journée s'est réellement écoulée face à celle attendue à cette heure, et combien de points de vente ont seulement remonté leurs données. Un chiffre de rythme sans ces deux lignes est illisible, et la plupart des tableaux de bord omettent les deux.
D'où viennent ces écrans
Les trois surfaces traversées par la décision
Prêt à voir
les euros qu'il a trouvés ?
La démo s'appuie sur les caisses et la comptabilité que vous utilisez déjà. Laissez vos coordonnées et choisissez un créneau.