Voici mon verdict d'entrée : de tous les projets de prévision IA pour entrepôt que j'ai vus mourir, aucun n'est mort à cause du choix du modèle.
Ces derniers temps, de plus en plus d'exploitants d'entrepôts me posent des questions sur la « prévision IA » — prédiction de la demande, suggestions de réapprovisionnement, estimations pour la planification de la main-d'œuvre. Les démos se ressemblent toujours. L'équipe enchaîne les modèles — gradient boosting, Prophet, ce qui est à la mode — en réglant les hyperparamètres à la quatrième décimale. Puis je pose une seule question : quelles caractéristiques alimentez-vous au modèle ? Le tableur qui revient n'a généralement que trois colonnes : date, SKU, ventes.
Ces projets sont morts-nés. Le modèle est le chef ; les caractéristiques sont les ingrédients. Donnez à un chef un panier de légumes pourris et le plat aura le même goût, quel que soit le cuisinier. En prévision, le vrai travail se situe hors du prompt — dans cette corvée ingrate que personne ne veut faire avant que les données n'atteignent le modèle : l'ingénierie des caractéristiques.
Neuf dixièmes des données d'entrepôt ne sont pas prêtes pour le modèle
En 2023, j'ai visité un 3PL de 120 000 pieds carrés à Ontario, en Californie. Ils avaient payé bon prix pour un modèle de prévision des ventes. Trois mois après le lancement, il ne battait toujours pas l'instinct du superviseur des opérations — un vétéran avec plus d'une décennie sur le terrain. « Ce modèle ne sait même pas ce qu'est le Black Friday », m'a-t-il dit.
Le diagnostic : le modèle n'était entraîné que sur le volume historique des commandes. Black Friday ? Aucun calendrier promo dans le système. La rentrée scolaire ? Rien. La congestion portuaire qui retarde l'arrivée des marchandises de deux semaines et fait exploser toutes les prévisions de réapprovisionnement ? Certainement rien.
C'est le premier piège. Le jeu de données le plus complet d'un entrepôt — les ventes historiques — est aussi la caractéristique la plus pauvre. Il vous dit ce qui s'est passé, jamais pourquoi. Un modèle qui ne lit que les courbes de ventes ne fait que décalquer la forme d'hier et deviner celle de demain. Dès que quelque chose de structurel change — une promotion, une rupture de stock, le lancement d'un nouveau SKU — il s'effondre.
Alors avant de toucher à un modèle, remettez la maison des données en ordre. Voici la liste que je remets aux clients :
Ventes quotidiennes par SKU et par site — deux ans minimum, trois c'est mieux. Le calendrier des promotions : qui l'a décidé, quelle profondeur, combien de jours, chaque événement. Les relevés de ruptures de stock — les jours avec de la demande mais sans inventaire ne sont pas des jours à zéro vente, même si votre système enregistre les deux comme 0. Fêtes et vacances scolaires (Thanksgiving change de date chaque année). Données météo — les intempéries font beaucoup bouger l'aiguille pour les centres de distribution du commerce local. Congestion portuaire et du transport longue distance — pour les opérations d'importation, c'est ce qui décide quand la marchandise en transit devient du stock disponible. Retours par SKU — là où les taux de retour sont élevés, les ventes brutes et nettes racontent deux histoires différentes.
Plus de la moitié de cette liste ne vit pas dans votre WMS. Elle vit dans les tableurs du marketing, dans la tête du responsable des opérations, dans les e-mails du transitaire. Avant l'IA, il faut aller la chercher, la structurer et la faire atterrir dans une seule table. Il n'y a pas de raccourci, et aucun grand modèle de langage ne le fera pour vous.
Les ingrédients propres à l'entrepôt
Les tutoriels génériques vous apprendront les caractéristiques de retard, les moyennes mobiles, les indicateurs de jour de semaine. Faites tout cela. Mais les entrepôts ont leur propre saveur, et quelques caractéristiques n'apparaissent jamais dans ces tutoriels.
Quantité en transit. L'« inventaire » dans le système et la « marchandise que vous pouvez vendre » sont souvent deux choses différentes. Pour une opération d'importation, un conteneur passe 30 jours sur l'eau ; pendant ces 30 jours, l'inventaire du système affiche zéro, mais la planification des ventes ne peut pas le traiter comme zéro. Donnez en caractéristique le volume en transit « commandé mais pas encore reçu », pour que le modèle apprenne la différence entre « stock bas, pas de panique » et « stock bas, vrai danger ». Pendant les déviations de la mer Rouge de 2024, un entrepôt d'articles pour la maison a vu le transit maritime s'étirer de 35 à 60 jours — pendant que son modèle continuait à conseiller « aucun réapprovisionnement nécessaire ». Les marchandises étaient encore sur les bateaux.
Vitesse de slotting. Le même SKU se vend différemment depuis une zone de picking dorée que depuis le rack du haut — l'efficacité du picking pousse la vitesse d'exécution, la vitesse pousse le réachat. Peu de gens y pensent : « distance moyenne de déplacement en picking sur les 30 derniers jours », ou simplement « était-il sur une tête de gondole promo ». Cela absorbe une bonne partie des fluctuations de ventes autrement mystérieuses.
Taux de retour glissant. Les centres de distribution d'habillement et de chaussures peuvent voir des taux de retour de vingt et quelques ou trente et quelques pour cent. Un modèle entraîné sur les ventes brutes surestime systématiquement la demande réelle. Donnez-lui « le taux de retour de ce SKU sur les 8 dernières semaines » et laissez le modèle apprendre à le décoter en conséquence.
L'indicateur de rupture de stock. La caractéristique la plus négligée et la plus impactante. Un jour à zéro vente — était-ce par manque de demande, ou par manque d'inventaire ? Votre système enregistre les deux comme 0. Sans un indicateur binaire « l'inventaire vendable était-il à zéro ce jour-là », le modèle apprend « personne ne veut ce SKU » à partir des ruptures et recommande encore moins de stock de sécurité la fois suivante — la spirale de la mort.
Les trois bêtes de somme : retards, fenêtres glissantes et alignement
Caractéristiques choisies ; maintenant la construction. La prévision d'entrepôt repose sur trois bêtes de somme, et le diable est dans la façon de régler chacune.
D'abord, les caractéristiques de retard : utiliser les ventes des N derniers jours pour prédire l'avenir. À sept jours, le modèle ne voit que le rythme hebdomadaire ; à quatre-vingt-dix jours, les caractéristiques deviennent bruyantes. Commencez par 7, 14 et 28 ; vérifiez quel palier apporte le plus sur l'ensemble de validation, puis affinez. Ne balancez pas 365 jours complets dès le premier jour — trop de caractéristiques et le modèle commence à mémoriser au lieu d'apprendre. C'est la rampe d'accès au surapprentissage.
Ensuite, les fenêtres glissantes : moyenne des 4 dernières semaines, maximum des 8 dernières semaines, écart-type des 12 dernières semaines. Les fenêtres glissantes captent la tendance. Mais les fenêtres de 4, 8 et 12 semaines sont fortement corrélées — c'est dire trois fois la même chose. Une ou deux suffisent.
Troisième — la plus typée entrepôt — l'alignement temporel : faire coïncider les causes avec les effets. La promotion commence le 20 novembre, mais la décision de stockage a été prise fin octobre — l'horodatage de la caractéristique doit refléter le moment de la décision, pas celui de l'événement. Ces alignements diffèrent pour chaque entrepôt ; on les cartographie en s'asseyant avec les opérations et les achats, un par un. La partie la plus précieuse de l'ingénierie des caractéristiques, et la moins copiable.
La façon la plus discrète de mourir : la fuite de données
Voilà le « comment ». Maintenant le « comment meurent les projets ». La fuite de données est le tueur le plus discret du travail de prévision, et elle meurt en gardant bonne figure — une précision de validation si élevée que tout le monde célèbre, puis un effondrement total en production.
La fuite classique : utiliser « la profondeur réelle de la promo de ce mois » pour prédire « les ventes de ce mois ». À l'entraînement, ça marche à merveille — promo profonde, ventes élevées. Mais au moment de la prédiction, la profondeur de la promo du mois prochain n'a pas encore été décidée. Vous alimentez le modèle avec des données du futur. C'est du voyage dans le temps, pas de la prévision. La correction : utiliser la promo planifiée (connue au moment de la décision), ou diviser la caractéristique en versions connue et inconnue.
Une autre fuite se cache dans les fenêtres glissantes : prédire décembre avec une « moyenne des 8 dernières semaines » qui inclut discrètement la première semaine de décembre — des données qui n'existent pas encore au moment de la prédiction. La vérification est bête mais efficace : pour chaque ligne d'entraînement, demandez-vous « au moment de la prédiction, aurais-je vraiment pu avoir ce chiffre ? » Si non, supprimez-la.
Puis la fuite de normalisation : calculer les statistiques de mise à l'échelle sur l'ensemble du jeu de données, validation incluse. Ça semble trivial, mais sur les SKU à petits échantillons, ça gonfle les scores de validation de plusieurs points. Calculez les statistiques sur l'entraînement uniquement ; appliquez-les à la validation et au test.
Plus, est-ce toujours mieux ? Parlons compromis
Voici un verdict impopulaire : plus de caractéristiques, ce n'est pas mieux.
J'ai vu un jour un modèle à 200 caractéristiques battre son petit frère à 30 caractéristiques de deux points en validation. Le client était ravi. Puis j'ai compté : soixante de ces caractéristiques dépendaient de flux externes — API météo, indices de congestion, signaux sociaux. Un flux tombe, change de format ou devient payant, et vous refaites le pipeline. Un pipeline à 200 caractéristiques nécessite un ingénieur de données dédié ; à 30 caractéristiques, l'équipe des opérations s'en sort seule.
Deux points de précision valent-ils une embauche à temps plein ? À 400 000 commandes par mois, peut-être. À 30 000, non. L'objectif n'est pas le modèle le plus précis — c'est le modèle le plus précis que l'organisation peut se permettre de maintenir en vie. Lancez d'abord avec 20 à 30 caractéristiques de base ; mettez en production, validez, mesurez l'impact business, puis décidez s'il faut en ajouter. Un modèle à 30 caractéristiques qui tourne de façon fiable pendant deux ans bat un modèle à 200 caractéristiques que personne ne maintient après trois mois.
Au moment de la recette, ne fixez pas un seul chiffre de précision. Je fais vérifier trois choses aux clients. D'abord, battre la référence — surpasser clairement les alternatives bêtes comme « même période l'an dernier » ou « moyenne des 4 dernières semaines », ou ne pas livrer. Ensuite, découper — noter séparément les meilleures ventes, la longue traîne et les nouveaux SKU ; les moyennes mentent, et les modèles excellent souvent sur les meilleures ventes tout en devinant sur la traîne. Enfin, prouver la valeur business — cinq points de précision, ça fait combien de ruptures en moins, combien de stock mort en moins ? Une métrique qui n'atteint pas le P&L est de la vanité.
Pour revenir à la phrase d'ouverture : le mauvais modèle vous tue rarement ; les mauvaises caractéristiques, toujours. La prochaine fois que quelqu'un vous présente de la prévision IA pour entrepôt, ne demandez pas quel modèle il utilise — demandez à quoi ressemble sa table de caractéristiques. S'il ne sait pas répondre, le projet est encore au stade de la « belle démo ». Le vrai savoir-faire a toujours vécu au-delà du prompt.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
