Systèmes d’exploitation

Comment automatiser la prévision des flux de trésorerie et la gestion des stocks

L’automatisation ne vous achète pas une meilleure prédiction. Elle raccourcit la distance entre le moment où un fait change et celui où vous savez ce qu’il change.

AmazeBase 12 min de lecture Stocks et trésorerie

Six entrées alimentent un moteur qui transforme le stock en prévision de trésorerie datée

La plupart des vendeurs qui posent cette question en posent en fait deux à la fois.

La première est mécanique : un logiciel peut-il faire les calculs à ma place ? Oui. Ce point est réglé depuis des décennies.

La seconde est celle qui compte : puis-je faire assez confiance à la réponse pour engager $40,000 dessus ?

L’automatisation ne gagne pas cette confiance en prédisant mieux. Elle la gagne en raccourcissant la distance entre le moment où un fait change et celui où vous savez ce que ce fait change.

Un fournisseur glisse de deux semaines. Un concurrent tombe en rupture et votre vitesse de vente double. Un conteneur arrive en avance. Chacun de ces événements change un chiffre — et toutes les décisions en aval. Dans un tableur, vous l’apprenez à la prochaine ouverture du fichier. Dans un système câblé, vous l’apprenez le jour même.

Voilà ce que l’automatisation achète. Pas la certitude. La vitesse de correction.

Voici comment la construire, dans l’ordre qui marche vraiment.

00Ce que veut vraiment dire « automatisé »

Un système qui automatise la trésorerie et le stock doit faire quatre choses, dans cet ordre. Sautez-en une et le reste est de la décoration.

  • Collecter — chaque fait arrive sans que vous le ressaisissiez.
  • Dater — chaque fait porte le jour où l’argent a bougé ou l’unité s’est vendue, pas le jour où vous l’avez remarqué.
  • Décider — le système transforme les faits en une action datée, pas en un chiffre sur un graphique.
  • Comparer — la réponse de la semaine dernière est gardée et confrontée à ce qui s’est passé.

La plupart des outils s’arrêtent à collecter et appellent le graphique une prévision. La valeur est dans les deux derniers.

Une prévision qui ne finit pas sur une date et une quantité n’est pas une prévision. C’est une humeur.

Branchez les six entrées

Prévoir la trésorerie et le stock demande exactement six entrées. Amazon en connaît trois. Les trois autres, vous seul les connaissez — et c’est pour cela que les outils génériques donnent des réponses génériques.

Ce qu’Amazon sait

  • 01Unités vendues, par SKU, par jourVotre vrai signal de demande — y compris les jours où vous étiez en rupture.
  • 02Argent entré et sorti au règlementVentes, remboursements, frais de commission, frais d’expédition FBA, stockage, versements — datés comme Amazon les a facturés.
  • 03Stock détenu et en transitDisponible, réservé, en transit, plus le registre de chaque mouvement.

Ce que vous seul savez

  • 04Coût rendu à destination par unitéFabrication, transport, douane, inspection — par unité, par lot. Pas une moyenne tapée une fois.
  • 05Délais de réapprovisionnement réelsJours entre vous avez passé la commande et Amazon l’a rendue vendable, par fournisseur, mesurés sur vos dernières commandes.
  • 06Conditions de paiement30 % à la commande, 70 % à l’expédition, 30 jours nets après l’arrivée. C’est ce qui transforme un bon de commande en sortie de trésorerie datée.

Les entrées 4 à 6 font tout le jeu. Un outil qui ne lit que votre compte Amazon sait vous dire ce qui s’est passé. Il ne sait pas vous dire ce que vous pouvez vous permettre, parce qu’il ignore ce que vous devez et quand.

Que faire

Saisissez coûts, délais et conditions de paiement une seule fois, au moment où vous passez la commande — pas en fin de mois. Ce qui n’est pas saisi à la création du bon de commande ne l’est jamais.

Rendez les chiffres honnêtes avant de les automatiser

Automatiser un chiffre faux ne fait que produire des réponses fausses plus vite. Quatre règles rendent les entrées fiables.

Calez-vous sur les données, pas sur le calendrier

Si votre dernier fichier de transactions s’arrête il y a 12 jours, vos « ventes quotidiennes » sont la moyenne de 12 jours réels et de 12 jours à zéro. Cela divise votre vitesse de vente par deux sans rien dire — et un système qui divise ensuite votre stock par cette vitesse vous annoncera une couverture deux fois plus longue qu’elle ne l’est.

Tout taux doit être calculé sur le dernier jour que les données couvrent réellement, et l’écran doit dire quel jour c’est. La fraîcheur n’est pas une note de bas de page ; c’est une condition préalable.

Argent entré, argent sorti — rien de réparti

Un P&L qui cherche à rattacher chaque coût à un produit vous fera passer votre vie à arbitrer des répartitions qui ne changent aucune décision. Pour prévoir la trésorerie, un coût est un coût le jour où l’argent a bougé. À quel ASIN il revient est une autre question, posée par un autre écran.

Cette seule règle supprime l’essentiel du travail de rapprochement qui fait abandonner aux vendeurs leurs propres chiffres.

Étiquetez la certitude ; ne la blanchissez jamais

Tous les dollars à venir ne sont pas également réels. Trois bandes suffisent :

ConfirméPayé, avec une date sur le reçu.
ProgramméNon payé, mais le déclencheur et l’échéance sont connus.
HypothèseUn coût dont on sait qu’il existe, sans calendrier, daté par défaut.

Affichez-les séparément et empilez-les. Un graphique de trésorerie qui les mélange dans une seule barre vaut moins que pas de graphique du tout, parce qu’il a l’air d’un savoir.

Quand les faits se contredisent, c’est l’humain qui tranche

Deux enregistrements se contrediront : votre compte de réception contre celui d’Amazon, votre facture de transport contre l’expédition à laquelle elle se rattache. Un logiciel qui désigne un gagnant en silence est un logiciel que vous finirez par ne plus croire.

La bonne conduite est de montrer le conflit, de refuser de le noyer dans une moyenne et de mettre une barrière devant la mauvaise réponse — en laissant la décision à celui qui sait.

Stock : transformez les unités en décision datée

Passons au calcul. Notez l’ordre : la date vient avant la quantité.

La vitesse de vente, sur une fenêtre défendable

Prenez des fenêtres glissantes exactes — 7, 30, 60, 90 jours — calées sur la dernière date de données. Pesez la fenêtre récente plus lourd que la longue (du genre 60/40 entre 7 et 30 jours) pour qu’une vraie tendance apparaisse en jours plutôt qu’en mois, et repliez-vous sur des fenêtres plus longues quand un SKU vend trop peu pour être lu.

N’utilisez jamais une moyenne depuis le lancement. Un produit qui vendait 20/jour en janvier et 80/jour en mars ne vend pas 47/jour.

Les jours de couverture, et la date de rupture

couverture        = stock disponible / vitesse de vente
couverture (net)  = (stock disponible + en transit) / vitesse de vente
date de rupture   = dernière date de données + couverture

La ligne du transit compte plus que les vendeurs ne le croient. Des unités sur un bateau ne sont pas du stock, et ne sont pas rien.

Le délai : mesurez-le, ne le tapez pas

La première source d’erreur sur la date de commande est un délai de réapprovisionnement que quelqu’un a tapé une fois, par optimisme, une autre année.

Mesurez-le sur votre propre historique : date de commande → date où les unités sont devenues vendables, par fournisseur, et gardez la moyenne et le pire cas. L’écart entre les deux n’est pas un détail — c’est exactement la taille du stock de sécurité qu’il vous faut.

Le stock de sécurité est un niveau de service acheté, pas du « rab »

jours de sécurité ≈ (délai pire cas − délai moyen)
                    + tampon de variabilité de la demande

point de commande = vitesse × (délai moyen + jours de sécurité)

date de commande  = dernière date de données
                    + (couverture − délai moyen − jours de sécurité)

Si la date de commande est passée, la commande est en retard, et le système doit le dire avec ce mot-là.

Alors seulement, la quantité

quantité suggérée = vitesse × (délai + couverture cible)
                    − stock disponible − en transit

La couverture cible est un choix d’entreprise — combien de jours de stock vous voulez avoir quand l’expédition arrive. Quand vous avez un vrai coût de transport par commande et un vrai coût de possession, la quantité économique de commande vous dit si votre taille de commande habituelle vous coûte de l’argent :

Q* = √( 2 × demande annuelle × coût de passation
        / coût de possession annuel par unité )

Traitez l’EOQ comme un contrôle de votre instinct, pas comme un ordre. Elle suppose une demande régulière, et la vôtre ne l’est pas.

Montrez la composition, pas seulement le chiffre

« Commandez 1,400 unités » ne se vérifie pas. « 1,400 = 62/jour × (45 jours de délai + 60 jours de couverture cible) − 3,100 en stock − 1,200 en transit » est un chiffre qu’un vendeur peut contester — le seul genre sur lequel il vaille la peine d’agir.

Trésorerie : transformez un P&L en calendrier daté

Un compte de résultat vous dit si l’entreprise fonctionne. Il ne vous dit pas si vous pouvez payer le conteneur. Ce sont deux questions différentes et elles demandent deux écrans différents.

Un calendrier de trésorerie demande quatre flux, chacun daté.

Entrées

  • Versements Amazon — votre solde de règlement, libéré au rythme d’Amazon, qui retarde sur la vente. Modélisez ce retard ; ne faites pas comme si la date de vente était la date d’encaissement.
  • Tout chiffre d’affaires hors Amazon.

Sorties

  • Échéances fournisseurs — pilotées par les déclencheurs de paiement du bon de commande : à la commande, à l’expédition, N jours après l’expédition, à date fixe. C’est celle-là qui ruine les trimestres.
  • Les prélèvements d’Amazon — frais, publicité, stockage — qui se déduisent le plus souvent du versement au lieu d’arriver comme une facture.
  • Frais généraux — ceux qui ne tiennent à aucun produit : logiciels, assistants, agences, votre propre rémunération.

Partez d’un solde d’ouverture connu à une date connue. Un graphique de trésorerie sans solde de départ est un graphique d’écarts qui se fait passer pour une position.

La sortie tient alors en une ligne : votre solde projeté, semaine par semaine, avec le point le plus bas et la date où il tombe mis en avant. Ce point bas est le chiffre qui décide si une commande est possible.

La jointure : une commande que vous ne pouvez pas financer n’est pas un plan

C’est la partie que presque tous les outils sautent, et c’est là que les deux moitiés de cet article deviennent un seul système.

Votre module de stock dit : commandez 1,400 unités de SKU-A avant le 14, et 900 de SKU-B avant le 22.
Votre calendrier de trésorerie dit : votre solde touche le fond à $8,200 le 19.

Séparément, les deux sont justes. Ensemble, ils font une décision :

  • Passer les deux commandes à l’heure fait passer le point bas en négatif le 19.
  • Retarder SKU-B de neuf jours coûte à peu près six jours de rupture — un nombre d’unités et de dollars de marge que l’on peut compter — et garde le point bas positif.
  • Couper SKU-A en deux expéditions renchérit le transport par unité mais aplatit la sortie d’argent.

Cette comparaison — la commande à passer contre la trésorerie que vous aurez vraiment — est toute la raison de relier les deux systèmes.

Classer, c’est allouer le capital. Quand vous ne pouvez pas tout financer, financez les SKU au plus fort rendement par dollar et par an : marge de contribution par unité × unités vendues par an ÷ dollars immobilisés. Un produit à 40 % de marge qui tourne deux fois par an perd contre un produit à 20 % qui tourne six fois.

Que faire

Ne regardez jamais une liste de réapprovisionnement sans le point bas de trésorerie sur le même écran. Une suggestion de commande qui ignore votre solde bancaire est une liste de souhaits.

Les scénarios, et à quoi ils servent vraiment

Les outils de scénarios se vendent comme des moteurs de prédiction. Ils ne le sont pas, et prétendre le contraire est la meilleure façon de se brûler.

Leur vrai rôle est le test de fragilité : trouver quelle hypothèse, si elle est fausse, fait le plus mal.

Faites tourner votre plan avec :

  • le délai à sa pire valeur observée, pas à sa moyenne
  • la vitesse de vente à ±30 %
  • une échéance fournisseur qui tombe deux semaines plus tôt que promis
  • le coût publicitaire par vente en hausse de 20 %

Lisez ensuite la sortie comme un classement, pas comme une prévision : mon plan survit à une erreur de demande, pas à une erreur de délai. Cela vous dit où acheter de l’assurance — un complément en fret aérien, un acompte renégocié, une première commande plus petite.

Le bouton de scénario le plus utile n’est pas le prix. C’est le taux de conversion. Vous ne pouvez pas mesurer si de nouvelles photos marchent, mais vous pouvez mesurer ce qu’un point de conversion en plus fait à votre couverture et à votre point bas de trésorerie — et ce chiffre dépasse en général de loin ce que les vendeurs imaginent.

Prévu contre réel : la boucle qui se paie toute seule

Tout ce qui précède ne vaut rien si personne ne tient le score.

Chaque semaine, gardez ce que le système a prédit : vitesse de vente par SKU, date de rupture prévue, date de commande suggérée, point bas de trésorerie prévu. Comparez ensuite avec ce qui s’est passé.

Trois questions, posées à date fixe :

  1. Où la vitesse de vente s’est-elle trompée, et dans quel sens ? Une erreur toujours orientée dans le même sens est un problème de réglage, pas de malchance.
  2. Où le délai s’est-il trompé ? Chaque bon de commande terminé est une mesure gratuite. Renvoyez-la automatiquement.
  3. Où la trésorerie s’est-elle trompée ? Presque toujours un paiement dont la date de déclenchement n’a jamais été saisie.

Une erreur systématique est un défaut réparable. Une erreur aléatoire est le prix du métier. Vous ne pouvez pas les distinguer sans le relevé.

Ce qu’il ne faut jamais automatiser

L’automatisation doit raccourcir la distance entre un fait et une décision — pas prendre la décision.

Automatisez : la collecte, la datation, le calcul, les alertes, la boucle qui tient le score.

N’automatisez jamais — passer la commande
Une rupture vous coûte des ventes. Un bon de commande de $40,000 à côté de la plaque vous coûte le trimestre.
N’automatisez jamais — trancher entre deux enregistrements contradictoires
Montrez le conflit ; laissez décider celui qui sait.
N’automatisez jamais — inventer une donnée que vous n’avez pas
Si le transport par commande n’a jamais été mesuré, la sortie honnête est « non mesuré » — pas une valeur par défaut plausible qui fait le calcul en silence.

Un écran vide qui vous dit ce qui manque vaut plus qu’un écran plein bâti sur des hypothèses.

Une séquence de 30 jours pour mettre cela en place

  1. Semaine 1 — La vérité. Chargez les transactions et le registre des stocks FBA. Confirmez la dernière date de données. Corrigez les écarts de stock. Rien en aval n’est réel tant que cela ne l’est pas.
  2. Semaine 2 — Les coûts. Saisissez vos bons de commande en cours avec les vrais coûts rendus à destination, les vrais déclencheurs de paiement et les vraies dates. Reprenez les trois derniers bons de commande terminés pour donner au délai quelque chose à mesurer.
  3. Semaine 3 — Les décisions. Activez les dates de commande et les jours de couverture. Fixez la couverture cible par SKU délibérément. Confrontez la composition de chaque suggestion à votre propre jugement — vous calibrez le système, vous ne lui obéissez pas.
  4. Semaine 4 — La trésorerie. Saisissez un solde d’ouverture. Montez le calendrier. Trouvez le point bas. Mettez ensuite la liste de réapprovisionnement à côté et voyez laquelle de vos commandes prévues survit.

À partir de là, c’est un rythme hebdomadaire : ce qui a changé, ce qui est en retard, ce qui est finançable, et où je me suis trompé la semaine dernière.

Questions fréquentes

Peut-on automatiser entièrement la prévision de trésorerie pour une entreprise Amazon ?

La collecte, la datation et le calcul, oui. Les entrées, non : les coûts rendus à destination, les conditions de paiement fournisseur et votre solde d’ouverture n’existent que dans vos propres registres. Comptez une heure de mise en place par fournisseur, puis quelques minutes par bon de commande.

De quelles données ai-je besoin avant de pouvoir prévoir quoi que ce soit ?

Six choses : les unités vendues par jour, l’argent entré et sorti au règlement, le stock détenu et en transit, le coût rendu à destination par unité, les délais fournisseurs mesurés et les conditions de paiement. Les trois premières viennent d’Amazon ; les trois dernières viennent de vous.

Quelle est la précision d’une prévision de stock automatisée ?

Assez précise pour battre un tableur, jamais assez pour lui faire confiance les yeux fermés. Le gain mesurable n’est pas la précision de la prévision — c’est le temps gagné entre un changement et votre réaction, et la disparition des erreurs de calcul dans cette réaction.

Quelle différence entre un P&L et une prévision de trésorerie ?

Un P&L vous dit si l’entreprise est rentable sur une période. Une prévision de trésorerie vous dit si vous pouvez payer quelque chose un jour précis. Une entreprise Amazon rentable peut très bien manquer de trésorerie — c’est le mode d’échec normal, pas le cas exotique.

Comment calculer un point de commande ?

Vitesse de vente × (délai moyen + jours de sécurité), où la vitesse est une moyenne glissante récente calée sur votre dernière date de données, et où les jours de sécurité viennent de l’écart entre votre délai moyen mesuré et votre pire cas. Calculez la date d’abord ; la quantité en découle.

Pourquoi ma prévision annonce-t-elle toujours plus de stock que je n’en ai ?

En général l’une de trois choses : une vitesse calculée sur le calendrier au lieu de la dernière date de données, des unités en transit comptées comme vendables, ou un délai tapé une fois et jamais mesuré.

Plus rapides à corriger, pas meilleurs à prédire

Automatiser la prévision de trésorerie et de stock, ce n’est pas acheter une boule de cristal. C’est bâtir un système où chaque fait que vous avez déjà est daté, relié et pointé vers une décision — pour que, quand la réalité bouge, vous l’appreniez cette semaine plutôt qu’au trimestre suivant.

Les vendeurs qui font cela bien ne prédisent pas mieux. Ils corrigent plus vite.