Voici mon verdict d'emblée : neuf fois sur dix, ce sont les données.
J'ai vu ce film trop de fois en vingt ans d'entreposage. Un DC dépense une somme considérable dans un module de prévision de la demande basé sur l'AI, le modèle est mis en production, et trois mois plus tard le réapprovisionnement repose toujours sur l'instinct d'un planificateur chevronné. Le premier réflexe de l'informatique est toujours : « le modèle est mauvais, essayons un autre algorithme ». Le mien est toujours le même : ne touchez pas encore au modèle — sortez les données que vous lui avez fournies et regardez-les bien. Presque à chaque fois, c'est là que vit le problème.
Un modèle n'est qu'un étudiant très appliqué. Donnez-lui un manuel plein de pages manquantes et de coquilles, et vous ne pouvez pas le blâmer d'échouer à l'examen.
Première question : vos données sont-elles même complètes ?
Beaucoup de projets de prévision meurent à la première étape : les données de base des SKU sont un désordre total.
Il y a quelques années, j'ai visité une plateforme 3PL à Ontario, en Californie — bien plus de cent mille pieds carrés, plus de vingt mille SKU — qui avait déployé une prévision de réapprovisionnement basée sur le ML. Six mois plus tard, la précision était misérable. Nous avons creusé et découvert que des champs comme la catégorie de produit, l'indicateur de saisonnalité et les relations de substitution étaient vides pour une énorme part du catalogue. Les nouveaux articles restaient des mois dans le système sans aucune catégorie attribuée. Qu'est-ce que le modèle était censé apprendre de ça ? Du vent ?
Puis il y a l'étiquetage incohérent : le même produit étiqueté « winter style » dans un DC, « Winter-2023 » dans un autre, et laissé vide dans un troisième. Le modèle voit trois produits différents et apprend de mauvais schémas pour chacun.
Le contrôle est simple : tirez 200 SKU au hasard et regardez les champs catégorie, saisonnalité, statut du cycle de vie et substitution. Si les taux de valeurs nulles dépassent vingt pour cent, arrêtez de parler de modèles et allez réparer vos données de base. C'est un travail ingrat, mais si vous le sautez, tout ce qui suit est de l'effort gaspillé.
Deuxième question : mesurez-vous seulement la bonne chose ?
C'est le mode d'échec le plus sournois que je connaisse. Les « ventes historiques » sur lesquelles votre modèle s'entraîne ne sont souvent pas du tout la vraie demande.
Cas classique : un SKU en rupture de stock pendant deux semaines en novembre dernier, donc le système a enregistré zéro vente. Le modèle a appris « personne ne veut ce SKU en novembre » et l'a sous-approvisionné cette année — sauf que cette année il n'y a pas eu de rupture, la demande s'est présentée comme d'habitude, et l'étagère s'est vidée. Un zéro pendant une rupture n'est pas de la demande. C'est le plafond de ce que vous pouviez fournir. Apprenez au modèle à confondre le plafond avec le plancher et il ne peut pas avoir raison.
Autre exemple : les transferts entre entrepôts. Le DC A est à court, donc 500 unités sont transférées depuis le DC B, et le journal des sorties du DC B enregistre 500 unités de « ventes ». Le modèle voit une forte demande au DC B pour ce SKU et vous dit de stocker — de stocker sur une demande fantôme qui n'était en fait qu'un transfert interne. Mélanger la vraie demande et les mouvements internes en un seul chiffre fausse chaque prévision.
Et n'oubliez pas les retours. En préparation de commandes e-commerce, le brut et le net des ventes peuvent différer énormément. Entraînez sur le brut et le modèle surestimera chroniquement.
Le contrôle : trouvez le document qui définit votre indicateur de ventes — s'il existe — et posez trois questions. Comment les périodes de rupture sont-elles traitées — quelqu'un a-t-il reconstruit la vraie demande ? Les expéditions de transfert sont-elles exclues ? Brut ou net ? Si personne ne peut répondre, ou si la réponse est « on n'a jamais traité ça », vous avez trouvé la cause racine. Avec un indicateur flou, plus le modèle est intelligent, plus il se trompe avec assurance.
Une chose qui mérite d'être dite : pas mal d'entrepôts alimentent les données de ventes directement depuis l'ERP, et les enregistrements de sortie de l'ERP ne distinguent pas « vendu à un client » de « expédié à notre DC sœur ». Personne ne fait cette étape de nettoyage, donc le modèle étudie de la fausse demande toute la journée. Je demande généralement à l'équipe données de d'abord découper une année d'enregistrements de sortie en ventes, transferts et rebuts. Cette seule étape réduit souvent sensiblement la « demande historique » de plusieurs SKU — et chaque unité qui disparaît était du bruit.
Troisième question : quelqu'un a-t-il étiqueté les événements ?
Les modèles de prévision détestent les pics inexpliqués. Les ventes ont doublé un mois l'an dernier, le modèle a mémorisé le schéma, et cette année il a stocké le double — sauf que le pic de l'an dernier était une grande promotion et que cette année il n'y en a aucune. Vous voilà assis sur du stock mort.
Promotions, opérations de déstockage, pics portés par des influenceurs, météo exceptionnelle, rupture d'un concurrent — si rien de tout cela n'est étiqueté, le modèle les absorbe comme de la « demande naturelle ». Ce qu'il apprend n'est pas un schéma. C'est du bruit.
Le pire cas que j'ai vu : trois ans de données de stockage panique de l'époque du Covid dans le jeu d'entraînement, sans aucune annotation. Le modèle a traité ces pics anormaux comme la référence, a maintenu le stock de sécurité quotidien en permanence élevé, et le stock mort a rempli deux allées entières. Une fois cette période étiquetée et dépondérée, la prévision est revenue à la réalité.
Il y a aussi une dimension facile à rater : les événements côté approvisionnement. Une livraison tardive d'un fournisseur, une grève portuaire qui repousse l'arrivage de trois semaines — cela creuse des trous inexplicables dans la courbe des ventes. Le modèle ne peut pas comprendre « on n'a pas pu vendre parce que la marchandise n'est jamais arrivée ». Il apprend juste « personne ne voulait ce SKU ce mois-là ». Votre calendrier d'événements ne peut donc pas se limiter aux promotions. Enregistrez aussi les principales perturbations d'approvisionnement et les anomalies d'arrivage. Étiquetez les deux côtés ou l'image reste incomplète.
Le contrôle : prenez les dix couples SKU-mois aux variations historiques les plus sauvages et demandez à l'équipe métier ce qui s'est passé. S'ils peuvent expliquer plus de la moitié d'entre eux mais que le système n'en enregistre aucun, votre calendrier d'événements est vide. Capturer les étiquettes d'événements prend dix minutes à décrire pour le métier et peut-être deux semaines à implémenter pour l'équipe données — chaque heure en vaut la peine.
Alors, quand est-ce vraiment la faute du modèle ?
Une fois que les données passent les trois contrôles — données de base complètes, indicateurs propres, événements étiquetés — et que la prévision rate toujours, alors oui, parlons modèles. Je serai le premier à être d'accord.
Les vrais problèmes de modèle ressemblent à ceci : les données sont propres, mais les modèles simples et complexes obtiennent à peu près les mêmes résultats, parfois avec le simple légèrement en tête. Ou la distribution de la demande a structurellement changé — disons que l'activité est passée du gros au détail, ou du magasin physique au en ligne — et l'ancien modèle a appris les règles d'un monde qui n'existe plus.
Et puis l'ingénierie des variables est insuffisante. Ne fournir au modèle qu'une série temporelle de ventes, en laissant de côté le prix, la position de stock et le délai d'approvisionnement — les variables sur lesquelles l'activité tourne vraiment. C'est moins un « mauvais algorithme » qu'un « le modélisateur ne comprend pas l'entreposage ». Changer d'algorithme n'aidera pas ; faire venir quelqu'un qui comprend le réapprovisionnement, oui.
D'après mon expérience, les variables battent les algorithmes dans ce domaine presque à chaque fois. Un planificateur qui comprend la logique de réassort plus une simple régression surpassera généralement un modèle sophistiqué réglé par quelqu'un qui n'a jamais mis les pieds sur un quai d'entrepôt. Les moteurs de la demande d'entrepôt sont concrets : le calendrier des promotions, les commandes ouvertes, la saisonnalité, la variabilité des délais fournisseurs. Transformez-les en variables et vous irez plus loin qu'avec n'importe quel changement d'architecture.
Ma règle de pouce est simple : si trois modèles différents obtiennent à peu près le même score sur le même jeu de données propre, le goulot d'étranglement n'est pas le modèle. Régler le choix du modèle sur des données sales n'est qu'un travail coûteux et inutile.
Une checklist de préparation des données réellement utilisable
Diagnostic terminé — maintenant, faites le ménage. Dans cet ordre, sans sauter d'étape :
- Données de base : champs catégorie, saisonnalité, cycle de vie et substitution pour chaque SKU, taux de valeurs nulles sous cinq pour cent
- Indicateurs : reconstruisez la vraie demande pour les périodes de rupture (au minimum, signalez-les), retirez les expéditions de transfert, entraînez sur les ventes nettes
- Événements : construisez un calendrier d'événements — promotions, déstockage, météo exceptionnelle, commandes ponctuelles en gros, tout étiqueté
- Granularité : assurez-vous que la granularité de la prévision (SKU-DC-semaine) correspond à celle de vos décisions de réapprovisionnement ; la bonne prévision à la mauvaise granularité est inutile
- Backtest : lancez un backtest de trois mois sur les données nettoyées et étudiez la distribution des erreurs avant toute mise en production
La plupart des entrepôts qui terminent ces cinq étapes découvrent quelque chose de drôle : leur ancien modèle est soudain devenu « plus intelligent ». Il n'a jamais été bête. Il lisait juste un manuel plein de coquilles.
Une question d'auto-test à emporter : dans les ventes historiques que vous fournissez à votre modèle de prévision en ce moment, pouvez-vous dire quelles lignes sont de la vraie demande, lesquelles sont des ruptures, et lesquelles sont des transferts internes ? Si vous ne pouvez pas les distinguer, ne vous précipitez pas pour changer de modèle — séparez d'abord ces trois-là. Une fois cette question résolue, la plupart du mystère autour des mauvaises prévisions se dissipe.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
