Stocks et variabilité : le niveau optimal n'existe pas, il se calcule

Stock = symptôme (30 secondes)

Votre stock est-il trop élevé ? Trop bas ? La plupart des directions industrielles répondent en comparant aux années précédentes ou au taux de rotation moyen du secteur. Ce sont les deux pires façons de le savoir.

Le stock optimal ne se compare pas. Il se calcule — à partir de la variabilité de la demande, de la variabilité du lead time, et d’un taux de service cible assumé.

La plupart des ETI industrielles que nous auditons sur-stockent de 30 à 50 % non pas par négligence, mais parce que personne n’a jamais mesuré les deux choses qui dictent le niveau optimal : la variabilité de la demande et la variabilité du lead time.

Le stock est un buffer contre la variabilité

Si la demande était parfaitement prévisible et les délais fournisseurs parfaitement tenus, le stock idéal serait nul (ou plutôt, juste de quoi couvrir le lead time). Vous commanderiez à l’avance la quantité exacte, et elle arriverait au moment exact.

Vous savez que ce n’est pas comme ça. La demande fluctue, les fournisseurs dérapent, les clients annulent, les imports sont bloqués en douane.

Le stock sert à absorber ces fluctuations. Son niveau optimal est fonction de quatre paramètres :

La variabilité de la demande — comment elle fluctue autour de sa moyenne
La variabilité du lead time — combien les délais fournisseurs dérapent
Votre tolérance aux ruptures — service level cible
Le coût de détenir vs le coût d’une rupture

Aucun de ces quatre paramètres n’est visible dans un ERP standard. Tous les quatre doivent être mesurés explicitement.

Les formules de base

EOQ — Quantité économique de commande (Wilson)

Combien commander à chaque réapprovisionnement pour minimiser le coût total ? La formule de Wilson (1913) :

$Q^* = \sqrt{\frac{2 \times D \times S}{H}}$

où :

$D$ = demande annuelle (unités/an)
$S$ = coût de passation d’une commande (€/commande)
$H$ = coût de possession annuel par unité (€/unité/an)

Exemple : demande 12 000 unités/an, coût commande 80 €, coût possession 3 €/unité/an.

$Q^* = \sqrt{\frac{2 \times 12000 \times 80}{3}} = \sqrt{640000} \approx 800 \text{ unités}$

Limite importante : Wilson suppose une demande constante et un lead time nul. Dans la réalité, c’est faux — mais Wilson reste un bon ordre de grandeur du lot optimal, pas un optimum absolu.

Safety stock — le vrai sujet

C’est ici que la variabilité entre. Le stock de sécurité protège contre les fluctuations combinées de demande et de lead time :

$SS = z \times \sqrt{L \times \sigma_D^2 + \bar{D}^2 \times \sigma_L^2}$

où :

$z$ = coefficient du service level visé (1.65 pour 95 %, 2.33 pour 99 %)
$L$ = lead time moyen (en périodes)
$\sigma_D$ = écart-type de la demande par période
$\bar{D}$ = demande moyenne par période
$\sigma_L$ = écart-type du lead time (en périodes)

Cas simplifié (lead time constant, $\sigma_L = 0$ ) :

$SS = z \times \sigma_D \times \sqrt{L}$

Reorder point — point de commande

Quand faut-il passer commande ?

$ROP = \bar{D} \times L + SS$

Dès que le stock disponible passe sous $ROP$ , on commande $Q^*$ .

Exemple complet

Demande moyenne 200 unités/semaine, $\sigma_D = 60$ , lead time 3 semaines, $\sigma_L = 0.5$ semaine, service level 95 % ( $z = 1.65$ ) :

$SS = 1.65 \times \sqrt{3 \times 3600 + 40000 \times 0.25} = 1.65 \times \sqrt{10800 + 10000}$ $SS \approx 1.65 \times 144 \approx 238 \text{ unités}$

$ROP = 200 \times 3 + 238 = 838 \text{ unités}$

Vous commandez $Q^*$ dès que le stock descend sous 838.

Pourquoi la loi normale ment

Les formules ci-dessus supposent que la demande et le lead time suivent une loi normale. C’est une hypothèse forte et souvent fausse en industrie.

Asymétrie — la demande ne ressemble pas à une cloche

Dans la vraie vie, la demande industrielle est asymétrique : beaucoup de petites commandes, quelques grosses. La distribution ressemble plus à une log-normale ou à une loi Gamma qu’à une normale.

Conséquence : si vous utilisez la loi normale pour dimensionner, vous sous-estimez la queue droite — c’est-à-dire la probabilité des événements rares mais gros. Votre service level réel est inférieur à celui que vous pensez obtenir.

Événements rares à l’échelle du catalogue

Une rupture sur 20 commandes (service level 95 %) paraît rare. Mais si vous avez 1 000 références et 100 commandes hebdomadaires par référence, cela fait potentiellement 5 000 ruptures hebdomadaires sur le catalogue. Les événements rares deviennent fréquents à l’échelle — et aucune dashboard ERP ne les montre.

Demandes discrètes — Poisson, pas normale

Pour les pièces de faible rotation (1 à 10 unités par mois), la loi normale est absurde — on ne peut pas vendre 3.7 unités. La bonne distribution est Poisson pour les arrivées de commandes, ou binomiale négative si la variance dépasse la moyenne (cas fréquent en industrie).

Safety stock Poisson

Pour une demande Poisson de moyenne $\lambda$ par période, le stock de sécurité visant un service level $\alpha$ se calcule via l’inverse de la fonction de répartition cumulée :

$SS = F^{-1}_{\text{Poisson}}(\alpha, \lambda \times L) - \lambda \times L$

Pas de formule fermée, mais facile à calculer en Python (scipy.stats.poisson.ppf). La plupart des ETI ne savent pas que pour leurs SKU à faible rotation, la formule normale les sur-stocke de 40 à 60 %.

Service level — choisir son taux de rupture

Le service level $\alpha$ détermine directement le niveau de stock. Plus il est élevé, plus le stock l’est. Mais le rapport n’est pas linéaire :

Service level	$z$	Stock de sécurité relatif
90 %	1.28	78 %
95 %	1.65	100 % (baseline)
97.5 %	1.96	119 %
99 %	2.33	141 %
99.5 %	2.58	156 %
99.9 %	3.09	187 %

Passer de 95 % à 99 % coûte 41 % de stock supplémentaire. Passer de 99 % à 99.9 % en coûte encore 33 %. C’est une courbe exponentielle — plus on veut de service, plus chaque point coûte cher.

La vraie question n’est pas « quel service level viser », c’est « à partir de quel niveau le coût marginal du stock dépasse le coût marginal d’une rupture ». Cette analyse est rarement faite.

Coût de rupture — la grande inconnue

Pour calculer l’optimal, il faudrait connaître le coût d’une rupture :

Perte de vente immédiate ?
Retard de production chez le client ?
Pénalité contractuelle ?
Perte de client à long terme ?

La plupart des ETI ne calculent jamais ce coût. Elles fixent un service level par habitude (souvent 95 % ou 98 %) et absorbent le stock que ça impose. Un audit BCUB3 typique révèle que ce choix n’est quasiment jamais rationalisé.

Cas concret — distributeur industriel, 3 200 SKU

Un distributeur de pièces techniques, 3 200 SKU actives, CA 18 M€. Situation initiale :

Stock moyen : 4.2 M€
Taux de rotation : 4.3
Service level observé : ~ 94 % (mesuré, pas estimé)
Ruptures mensuelles : 130 à 180

Audit BCUB3 — ce qu’on a découvert en 2 semaines :

Aucune mesure de $\sigma_D$ par SKU. Le stock avait été dimensionné « à la louche », 3 mois de couverture pour tout.
Lead time réel non mesuré. Le délai annoncé par le fournisseur principal (4 semaines) était dépassé dans 35 % des cas, parfois jusqu’à 9 semaines.
Asymétrie forte de la demande. 80 % des SKU avaient $\sigma_D > \bar{D}$ — loi de Poisson plus adaptée que loi normale.
Le service level « cible » n’était pas documenté. Chacun faisait selon son jugement.

Actions :

Segmentation ABC/XYZ (les SKU de classe A stables méritent moins de SS que les C erratiques)
Mesure effective de $\sigma_D$ et $\sigma_L$ sur 6 mois d’historique
Safety stock recalculé avec la bonne loi (Poisson pour SKU à faible rotation, normale pour hauts volumes)
Service level différencié : 98 % pour classe A, 95 % pour classe B, 90 % pour classe C

Résultats à 6 mois :

Indicateur	Avant	Après	Delta
Stock moyen	4.2 M€	2.8 M€	−33 %
Taux de rotation	4.3	6.4	+49 %
Service level effectif	94 %	97 %	+3 pts
Ruptures mensuelles	150	60	−60 %

Stock divisé par 1.5, service level en hausse, ruptures divisées par 2.5. Pas de nouvelle IA, pas d’ERP changé — juste du calcul statistique propre.

Comment l’IA aide vraiment

L’IA ne remplace pas la statistique des stocks — elle lève les obstacles qui empêchaient de la faire à grande échelle.

Obstacle	Solution IA	Lien
Prévision de demande hétérogène	Forecasting ML hybride (Prophet + LightGBM) par segment	ML industriel
Détection de dérive du $\sigma_D$	Cartes EWMA + ARIMA résiduelle	SPC
Optimisation multi-échelon (usine + DC + magasins)	Simulation Monte Carlo + métaheuristiques	DOE
Clustering automatique ABC/XYZ	K-means + features (volume, CV, saisonnalité)	Agrégation
Estimation du coût de rupture	Régression sur historique pertes de CA	Tests stats

Mais le plus grand gain ne vient pas de l’IA. Il vient de mesurer vraiment $\sigma_D$ et $\sigma_L$ et d’appliquer la bonne formule à la bonne loi de distribution. La plupart des ETI n’en sont pas encore là.

graph TD
    A["Stock jugé trop élevé / trop bas"] --> B{"σ_D mesuré par SKU ?"}

    B -->|Non| C["Mesurer σ_D sur 6 mois d'historique"]
    B -->|Oui| D{"σ_L mesuré ?"}

    D -->|Non| E["Mesurer σ_L réel (pas annoncé)"]
    D -->|Oui| F{"Loi adaptée ? (Poisson si faible rotation)"}

    F -->|Non| G["Recalculer SS avec bonne loi"]
    F -->|Oui| H{"Service level documenté par classe ?"}

    H -->|Non| I["Segmenter ABC/XYZ + différencier α"]
    H -->|Oui| J["Optimisation continue par IA"]

    C --> D
    E --> F
    G --> H
    I --> J

    style A fill:#2C3E42,color:#FDFBF8,stroke:#7DB5A5
    style B fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style C fill:#E99971,color:#FDFBF8,stroke:#2C3E42
    style D fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style E fill:#E99971,color:#FDFBF8,stroke:#2C3E42
    style F fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style G fill:#E99971,color:#FDFBF8,stroke:#2C3E42
    style H fill:#566569,color:#FDFBF8,stroke:#2C3E42
    style I fill:#E99971,color:#FDFBF8,stroke:#2C3E42
    style J fill:#7DB5A5,color:#FDFBF8,stroke:#2C3E42

Lien avec les articles précédents

Les trois articles de cette série racontent la même histoire par trois angles différents :

One Piece Flow — fluidifier le flux : l’idéal théorique, les 7 prérequis, le compromis du small batch flow
Heijunka — équilibrer avant de fluidifier : le premier combat, souvent oublié, contre mura
Stock et variabilité (cet article) — dimensionner les buffers qui restent quand on n’a pas encore tout lissé

Le fil rouge : dans un monde idéal, le stock tend vers zéro et le flux tend vers le batch = 1. Dans le monde réel, les stocks et les lots sont des paris sur la variabilité. Mieux mesurer la variabilité = mieux parier = moins de stock pour le même niveau de service.

L’ordre logique d’attaque d’une transformation est donc :

Mesurer la variabilité (demande, lead time, charge) — article #3
Lisser ce qui peut l’être (heijunka) — article #2
Réduire les buffers qui étaient justifiés par la variabilité résiduelle — article #3 encore
Fluidifier ce qui reste (small batch flow, puis OPF) — article #1

En résumé

Le stock est un buffer contre la variabilité, pas un actif à minimiser aveuglément.
Deux variabilités dictent le niveau optimal : la demande et le lead time. Mesurez-les — c’est rarement fait.
La loi normale ment pour la plupart des demandes industrielles. Asymétrie + événements rares = utilisez Gamma, log-normale ou Poisson selon le cas.
Le service level n’est pas gratuit. Passer de 95 % à 99 % coûte 41 % de stock en plus. Assumez le choix.
Les formules classiques (Wilson, safety stock normal) sont un bon point de départ, pas une vérité absolue.
L’IA aide à faire à grande échelle ce que la statistique permet déjà à petite échelle. Mais commencez par mesurer.

Ce n’est pas votre stock qui est trop élevé. C’est votre modèle de variabilité qui est inexistant.