PREVISION RETAIL : LA REGLE DES 28 JOURS

CHRONOS – 2 EN PREVISION RETAIL

La réponse au démarrage à froid

Nickson Mwonsojo — Data Scientist, Aquila Data Enabler — Juin 2026

Les modèles de fondation pour séries temporelles ouvrent un compromis nouveau en prévision de la demande. Cet article s’adresse aux équipes qui envisagent Chronos-2 pour leur système de prévision et qui veulent savoir, sans habillage marketing, où il apporte de la valeur et où il n’en apporte pas.

Voici notre conclusion, tirée d’une évaluation sur 30 490 SKUs Walmart du benchmark M5 (horizon 28 jours, métrique WRMSSE, trois cutoffs saisonniers). Un pipeline Chronos-2 correctement configuré atteint un WRMSSE de 0,7969, soit 51 % de mieux que la baseline saisonnière naïve. Un LightGBM entièrement optimisé fait mieux encore sur les séries à historique complet, à 0,6198. Nous le disons d’emblée parce que ça compte. Mais il y a un régime où LightGBM est tout simplement aveugle : les produits qui viennent d’être lancés, avec moins de 28 jours d’historique. Et ce régime n’a rien de marginal. C’est même le problème que le reste du pipeline passe son temps à contourner.

La prévision retail est un problème de démarrage à froid déguisé

On parle en général de prévision de la demande à propos des produits matures : gros volumes, plusieurs années d’historique, saisonnalité bien installée. Ces cas-là sont maîtrisés. Un gradient boosting correctement paramétré, avec des features de lag, les traite sans difficulté.

Le vrai point dur, c’est le lancement. Un retailer de taille moyenne introduit plusieurs centaines de références par mois ; un acteur fast-fashion renouvelle tout son assortiment à chaque saison. À chaque fois, le pipeline ML classique se heurte au même mur : il ne sait prévoir que ce qu’il a vu à l’entraînement. Or un produit lancé aujourd’hui n’a ni lag, ni statistiques glissantes, ni target encoding. Autrement dit, il lui manque tout ce sur quoi reposent les modèles à base d’arbres.

Que fait-on en pratique ? On attend. On laisse passer quelques semaines, le temps d’accumuler assez de données, puis on intègre le produit au prochain ré-entraînement. Pendant ce temps, le demand planner estime au jugé et la supply chain sur-commande par précaution. Le sur-stock, lui, se paie.

C’est exactement ce cycle que les modèles de fondation cassent. Chronos-2 arrive pré-entraîné sur des centaines de millions de séries temporelles variées. Un nouveau SKU ne déclenche aucun entraînement : le modèle connaît déjà l’espace des comportements de demande dans lequel vivent les produits retail. On lui présente une série, même très courte, et il rend une prévision dès le premier jour. C’est là toute sa proposition de valeur. Pas qu’il batte tous les modèles classiques sur toutes les séries — il ne le fait pas —, mais qu’il fonctionne sans le prérequis en données qui rend ces modèles inutilisables au démarrage d’un produit.

Un benchmark honnête : le prix de la précision

Impossible de vanter un workflow sans le confronter à l’alternative évidente. Nous avons donc monté un LightGBM global sur les mêmes 30 490 séries, avec 37 features artisanales : lags de 28 à 42 jours, statistiques glissantes ancrées au lag-28, prix, indicateurs SNAP, variables calendaires, moyennes de ventes encodées par magasin, département et État. Objectif tweedie, une vingtaine d’essais Optuna pour l’optimisation des hyperparamètres.

Le verdict brut :

Modèle	WRMSSE (géo-mean 3 cutoffs)
LightGBM global (37 features)	0,6198
Chronos-2 (pipeline complet, OLS)	0,7969

LightGBM gagne de 22 %. Ce n’est pas du bruit d’arrondi, et nous n’allons pas prétendre le contraire. Deux précisions s’imposent toutefois.

D’abord, ce que ce résultat a coûté. Les 37 features supposent une vraie connaissance métier — savoir quelles fenêtres de lag comptent pour un cycle retail hebdomadaire ne s’improvise pas. Il faut aussi de l’infrastructure : cache de features, gestion des cutoffs de calibration et des checkpoints, campagnes d’HPO. Et beaucoup de débogage. Le pipeline Chronos, à côté, s’est résumé à un sweep de longueurs de contexte, un booléen à activer et quelques régressions OLS. Les deux donnent des résultats solides, mais l’écart d’effort est considérable. Les équipes que Chronos sert le mieux sont celles qui, autrement, passeraient des semaines à reconstruire ce que LightGBM exige avant même de sortir un premier chiffre exploitable.

Ensuite, ce dont LightGBM est incapable. Il a été entraîné sur des données où chaque série testée disposait de son historique complet. En production, ce confort disparaît : de nouveaux SKUs surgissent qu’il n’a jamais rencontrés. À ce moment précis, lag_28 est indéfini, lag_42 aussi, et cinq des sept statistiques glissantes également. Le modèle bascule alors sur sa branche « valeur manquante ». Le problème, c’est que cette branche a été apprise pour gérer des ruptures de stock passagères, pas de véritables nouveautés.

On nous demande souvent si un blend des deux modèles ne réglerait pas la question. Nous l’avons essayé. Sur les séries à historique complet, le blend optimal converge vers du LightGBM presque pur : Chronos n’ajoute rien que LightGBM ne capture déjà. Son terrain de jeu est ailleurs.

Construire le workflow Chronos : du naïf à 0,80

Bonne nouvelle pour qui n’a pas d’infrastructure ML lourde : avec Chronos, atteindre une précision de production tient surtout à la configuration, pas à l’entraînement. Trois réglages font l’essentiel du travail.

Le premier, et le plus déterminant, est la longueur de contexte. À CL=1, avec une seule observation, Chronos reproduit à l’identique la naïve (1,6310) : un bon test de cohérence si vous doutez de votre pipeline. À CL=7, soit une semaine, il attrape le cycle hebdomadaire. Passé CL=14, ça se dégrade sur les séries bruitées, le modèle se met à traiter les pics passés comme un signal de fond. Ne déployez jamais sans avoir balayé {1, 4, 7, 14, 28}.

Le deuxième réglage est plus surprenant. Deux mécanismes apportent du contexte entre séries : les covariables exogènes (prix, promotions, SNAP, calendrier) et l’attention cross-séries, activée par cross_learning=True. On s’attendrait à ce qu’ils se cumulent. C’est le contraire : ils se substituent. Dans un batch global où tout est mélangé, activer le cross-learning en plus des covariables fait baisser la performance, parce que l’attention rapproche des séries dont les expositions événementielles n’ont rien à voir. La règle pratique : avec des covariables riches, coupez le cross-learning au global.

Ce qui nous amène au troisième point, car le cross-learning n’est pas à jeter — il faut simplement l’employer au bon endroit. Segmentez l’inférence par département, et la donne change. Dans un batch de 100 séries FOODS_1, toutes partagent la même éligibilité SNAP et des rythmes de vente comparables ; l’attention cross-séries travaille alors sur des voisins réellement similaires et en extrait un signal de groupe utile. Le gain vaut environ 0,04 de WRMSSE, davantage que la plupart des autres paramètres pris isolément.

Un mot sur la segmentation elle-même, parce que le choix de l’axe pèse autant que la décision de segmenter. Nous en avons testé trois. La classification par type de demande (smooth, erratic, intermittent, lumpy) marche, mais ajoute une étape de prétraitement et colle mal à la métrique. La segmentation géographique par magasin, elle, fait pire que ne rien faire : les dix magasins Walmart partagent la même saisonnalité et ne diffèrent que par le volume. Le bon axe, sans discussion, est le tier de volume, par quartiles de contribution au WRMSSE. Simple à calculer, aligné sur la métrique, et cohérent avec la façon dont le modèle se sert du contexte. À retenir : on segmente par comportement de demande, jamais par géographie ou organigramme.

Deux fausses bonnes idées, pour finir. Le fine-tuning global détruit le signal pré-entraîné en moins de dix pas de gradient — un cas d’école de catastrophic forgetting —, donc on ne fine-tune pas un TSFM sur des données retail intermittentes sans surveiller de très près le nombre de pas. Quant au modèle BASE, plus gros, il fait moins bien que le small sur ces séries courtes et hachées : sa capacité supplémentaire a été calibrée pour du long et du continu, pas pour ça. Nous détaillons ces impasses, y compris un bug PEFT silencieux qui a invalidé plusieurs runs LoRA, dans la version étendue de l’article.

La recette finale et l’origine des gains

Le meilleur résultat marie deux composants via une calibration OLS légère. D’un côté, un ensemble de modèles fine-tunés par tier de volume, qui capte les motifs temporels fins de chaque segment. De l’autre, le zero-shot segmenté par département avec cross-learning, qui apporte un apprentissage de représentation entre catégories que le fine-tuning par tier, entraîné en vase clos, ne voit jamais. Une régression OLS par département, validée en leave-one-cutoff-out, laisse ces deux apports se combiner sans réglage manuel et corrige au passage un biais d’échelle bien identifié sur FOODS_1.

Le tableau ci-dessous montre où se fabrique le gain :

Étape	WRMSSE	Gain vs naïve
Saisonnière naïve	1,6310	—
Meilleur ZS global (CL=7 + covariables)	1,0776	−34 %
ZS segmenté par dept + cross-learning	1,0325	−37 %
Ensemble tier (matrice de blend optimisée)	0,8180	−50 %
Pipeline complet (tier + ZS + OLS)	0,7969	−51 %

Ce qui saute aux yeux, c’est que l’essentiel du chemin se fait avant tout fine-tuning, par les seuls choix de configuration zero-shot (de 1,6310 à 1,0325). L’ensemble tier et la calibration ne font que la dernière ligne droite. En clair : une équipe atteint environ 1,08 en une journée, descend vers 0,98 avec une calibration légère, et n’a besoin du fine-tuning que si cette précision-là ne suffit pas.

L’avantage qui change tout : la règle des 28 jours

Reste à vérifier la promesse de départ sur le cold-start. Pour la mesurer sans détour, nous avons calculé le RMSSE non pondéré de chaque série, en regroupant les séries par longueur d’historique actif — le nombre de jours écoulés depuis la première vente non nulle. Le choix du non-pondéré est délibéré : le WRMSSE, qui privilégie les gros volumes, écraserait précisément le signal « nouveaux produits » qui nous intéresse ici.

Historique actif	RMSSE LGBM	RMSSE Chronos	Gagnant	Chronos gagne
< 28 jours	1,059	1,019	Chronos	59 %
28 – 90 jours	0,812	0,847	LGBM	40 %
90 – 365 jours	0,735	0,871	LGBM	20 %
365 – 730 jours	0,712	0,836	LGBM	20 %
730+ jours	0,664	0,772	LGBM	23 %

Le basculement est franc, et il se situe à 28 jours. En dessous, Chronos l’emporte sur 59 % des séries et affiche un RMSSE médian plus bas. Sur le cutoff d’automne, celui qui concentre le plus de lancements, il gagne même 72 % des nouveaux SKUs.

Pourquoi 28 jours, précisément ? Parce que lag_28 est la feature la plus prédictive de LightGBM : la demande du même jour, quatre semaines plus tôt, qui encode directement la saisonnalité hebdomadaire. En dessous de 28 jours, cette feature n’est pas une estimation approximative ni une valeur qu’on pourrait imputer. Elle n’existe pas. Chronos-2 n’a pas cette contrainte : une observation lui suffit pour produire une prévision, sept pour saisir le cycle hebdomadaire. Là où le modèle classique cale, lui commence à travailler.

Un mot de prudence : le bucket des moins de 28 jours reste modeste, 43 séries réparties sur deux cutoffs. L’évidence empirique est donc une tendance, pas une preuve définitive. En revanche, l’argument structurel — lag_28 est une frontière nette, pas une zone grise — tient tout seul, indépendamment de la taille de l’échantillon.

Et l’enjeu est très concret. Pour un retailer qui sort des centaines de références par mois, ces quatre premières semaines sont justement celles où une erreur de réassort coûte le plus cher. Trop de stock, et l’on immobilise du capital sur un produit non encore validé ; trop peu, et l’on étouffe une référence prometteuse avant qu’elle ne trouve son public. C’est aussi le moment où le planner en sait le moins et se fie à son intuition. Avoir une prévision, même perfectible, dès le premier jour plutôt qu’une estimation à vue pendant un mois, ça déplace le curseur entre supply chain et category management.

Quand et comment utiliser Chronos

Le choix n’est pas tout ou rien. Chronos-2 et LightGBM répondent à des besoins distincts, et rien n’empêche un système de production de faire tourner les deux.

Si vous avez déjà un pipeline ML mature, voyez Chronos-2 comme votre couche de démarrage. Tout SKU sous les 28 jours d’historique passe par une prévision Chronos en zero-shot ; au-delà, vous rendez la main à votre modèle habituel. Une simple porte sur la longueur d’historique suffit à aiguiller l’un vers l’autre.

Si vous partez de zéro, commencez par Chronos-2. Le pipeline zero-shot se met en place en deux ou trois jours et donne un WRMSSE déjà compétitif avec les modèles de production de bien des enseignes. Vous reviendrez à LightGBM plus tard, quand l’équipe aura l’infrastructure de features et la connaissance métier pour le construire.

Et si vous avez besoin d’aller vite sans stack ML, c’est précisément l’atout de Chronos : ni feature store, ni gestion de données d’entraînement, ni calendrier de ré-entraînement. Il tourne à partir des poids du modèle et d’une fenêtre de contexte, point.

La montée en charge se fait par paliers. En une journée, un run zero-shot à CL=7 pose la baseline. En deux ou trois jours, un pipeline segmenté par catégorie — cross-learning dans les batches cohérents, covariables SNAP et calendrier, calibration OLS par catégorie — atteint la plage 0,98–1,08, ce qui est déjà un excellent point de départ pour la plupart des retailers. En une à deux semaines, l’ajout de l’ensemble tier (fine-tuning contrôlé, 25 pas maximum, poids de blend appris sans gradient) fait descendre vers 0,80. À ne tenter que si l’étape précédente ne suffit pas à votre cas d’usage.

Conclusion

Nous étions partis d’un problème, l’échec du cold-start en prévision classique. Nous finissons sur un constat mesuré : Chronos-2 prend l’avantage sur les produits lancés depuis moins de 28 jours, là, très exactement, où le ML classique n’a aucune feature valide à offrir.

Pour les enseignes qui disposent d’un pipeline ML mature et des moyens de l’entretenir, LightGBM restera plus précis sur le gros de l’assortiment. Nous ne cherchons pas à le cacher. Mais pour le flux de nouveautés qui arrive chaque semaine — celles que les planners estiment aujourd’hui à la main —, Chronos-2 est le seul outil opérationnel dès le premier jour. Ce n’est pas un détail : c’est le point aveugle autour duquel tout le reste du pipeline a été bâti.

La version étendue de cet article détaille le benchmark LightGBM complet, les impasses rencontrées en chemin (fine-tuning, LoRA, modèle BASE), la ventilation complète de la règle des 28 jours, et un cadre de décision pour la mise en œuvre. Elle est disponible sur notre Medium.

Chez Aquila, l’intégration de foundation models time series dans des stacks de prévision existants est un chantier actif. Si vous travaillez sur un sujet proche — cadrage d’architecture, benchmark sur vos données, accompagnement projet — écrivez-nous : contact@aquiladata.fr