Logiciel d'optimisation du e-commerce, février 2025

Par Léon Levinas-Ménard

Dernière modification : 2 février 2025

Introduction

Le marché des logiciels d’optimisation du e-commerce est rempli d’affirmations audacieuses d’une magie pilotée par l’IA, mais un examen approfondi révèle que seuls quelques fournisseurs tiennent véritablement la promesse d’optimiser conjointement les stocks, les tarifs et les assortiments avec une technologie de pointe. Dans cette étude, nous évaluons les solutions leaders pour le pure-play e-commerce (commerçants en ligne sans magasins physiques) et classons les fournisseurs les plus pertinents – y compris Lokad, RELEX Solutions, Blue Yonder et ToolsGroup – selon leurs mérites techniques et leurs écueils. Lokad se distingue en tant que leader grâce à son approche unifiée et probabiliste et à son haut degré d’automatisation, tandis que RELEX et Blue Yonder offrent des suites complètes atténuées par la complexité opaque de l’IA et des bagages hérités, respectivement. ToolsGroup fournit une optimisation de stocks éprouvée, fondée sur des mathématiques solides, mais fait face à des défis d’intégration en s’étendant à la tarification et à l’assortiment. Tout au long, nous adoptons un regard profondément sceptique : trancher à travers le battage marketing, examiner les affirmations des fournisseurs à la lumière de preuves indépendantes et mettre en évidence les mises en garde souvent implicites (par exemple, l’incapacité à optimiser les décisions de manière holistique, ou la dépendance à des architectures coûteuses). L’objectif est une analyse technique narrée qui privilégie la vérité avant le battage, afin que les acteurs du e-commerce puissent comprendre qui fait réellement progresser l’état de l’art – et qui échoue.

Les critères du gold standard : optimisation conjointe & technologie avancée

Tout fournisseur peut se vanter de l’IA ou du big data, mais optimiser véritablement une entreprise de le e-commerce requiert de satisfaire à un haut niveau de critères techniques et fonctionnels. Le point primordial est l’optimisation conjointe : la capacité d’optimiser simultanément les décisions de niveaux de stocks, de tarification et d’assortiment de produits. Traiter ces éléments isolément – comme de nombreux anciens systèmes le font – est fondamentalement erroné, car ils sont étroitement interdépendants (la tarification affecte la demande qui affecte les stocks, les changements d’assortiment influent sur les deux, etc.). Une solution d’optimisation du e-commerce doit coordonner les trois ; par exemple, elle pourrait décider de stocker moins un produit et de lui accorder une remise plus tôt si les prévisions révèlent des ventes lentes, ou d’augmenter les tarifs de certains articles pour éviter les ruptures de stocks. Les solutions qui optimisent les stocks tout en ignorant la tarification, ou inversement, laissent de l’argent sur la table et sont sous-optimales par conception.

Au-delà de l’optimisation conjointe, les solutions véritablement à la pointe devraient tirer parti des techniques et architectures modernes:

Prévision probabiliste : Plutôt que de produire des prévisions de demande à un point unique, utilisez des distributions de probabilité pour capter l’incertitude de la demande. Ceci est crucial pour le e-commerce avec ses modèles de demande volatils et sa « longue traîne » de SKU. Les outils traditionnels (par exemple, d’anciens modules SAP ou Oracle) qui produisent un seul chiffre et un stock de sécurité se trompent souvent sur la véritable variabilité ¹ ². Les fournisseurs de premier plan mettent désormais l’accent sur des modèles probabilistes ou « stochastiques » qui quantifient l’éventail des résultats.
Optimisation économique : Les décisions doivent être guidées par des objectifs économiques (profit, coût, cibles de taux de service) et non simplement par des règles heuristiques. Par exemple, un système véritablement optimisé prendra en compte les marges bénéficiaires et les coûts de détention des produits lors de la détermination des niveaux de stocks et des tarifs. Il priorisera les actions qui maximisent le profit attendu ou minimisent le coût total, plutôt que de viser aveuglément un taux de remplissage. Cela nécessite d’intégrer les paramètres de coût/revenu dans les algorithmes.
Scalabilité et rentabilité : Les données du e-commerce sont massives (potentiellement des millions de SKU, des transactions quotidiennes, plusieurs canaux). Le logiciel doit gérer ces données à grande échelle sans coûts matériels exorbitants ni performances médiocres. Les architectures qui conservent naïvement tout en mémoire (RAM) peuvent devenir prohibitivement coûteuses à grande échelle. Les conceptions modernes utilisent le cloud computing de manière judicieuse, par exemple via un traitement distribué, des bases de données sur disque et des algorithmes efficaces. Une solution nécessitant une immense ferme de serveurs ou des plateformes coûteuses (comme l’usage excessif du data cloud de Snowflake) pourrait éroder le ROI. Inversement, une ingénierie astucieuse peut traiter des ensembles de données à l’échelle du téraoctet en quelques heures sur des instances cloud standard ³ ⁴.
Effets de cannibalisation et de substitution : Dans les décisions d’assortiment et de tarification, le système doit prendre en compte que les produits influencent réciproquement leur demande. Par exemple, si deux produits sont de proches substituts, abandonner l’un fera dévier une partie de la demande vers l’autre (un effet de cannibalisation). Gérer cela requiert plus qu’une simple analyse OLAP ou des groupes de produits définis manuellement ; il faut des modèles capables d’apprendre les élasticités croisées ou les taux d’attachement. De nombreux outils hérités supposent que la demande de chaque produit est indépendante, ce qui entraîne des erreurs tant en prévision qu’en planification d’assortiment. Un fournisseur à la pointe devrait modéliser explicitement de telles relations (par exemple, en utilisant le machine learning sur des données de transaction pour en déduire les affinités entre produits).
Impacts des places de marché et de la concurrence : Les acteurs purement e-commerce sont souvent influencés par les dynamiques des places de marché – par exemple, la concurrence sur Amazon ou eBay, les vendeurs tiers, etc. Le logiciel d’optimisation devrait idéalement intégrer des signaux tels que la tarification des concurrents ou les ruptures de stocks sur ces places. Peu le font correctement. C’est une frontière complexe mais de plus en plus pertinente : par exemple, si un concurrent est en rupture de stock sur un article populaire, votre système devrait détecter cette opportunité et ajuster en conséquence votre tarif ou vos dépenses publicitaires. De même, si vous vendez à la fois en direct et sur des places de marché, le système devrait optimiser sur l’ensemble des canaux (en évitant, par exemple, de surstocker sur votre propre site alors que le produit se vend via Amazon FBA).
Capacités multi-canal et omni-canal : Même sans magasins physiques, un commerçant e-commerce peut disposer de plusieurs canaux en ligne (site propre, places de marché, éventuellement des sites régionaux). Le moteur d’optimisation doit gérer la demande et les stocks multi-canal de façon holistique – en reconnaissant, par exemple, que les stocks sont partagés ou que les décisions de tarification sur un canal peuvent affecter un autre. La planification « end-to-end » n’est pas qu’un mot à la mode ; cela signifie que le logiciel appréhende l’ensemble du panorama (des fournisseurs aux clients, à travers tous les canaux de vente).
Haut degré d’automatisation (« robotisation ») : La promesse ultime de ces systèmes est la prise de décision autonome. Théoriquement, ils devraient pouvoir fonctionner sans surveillance, générant des commandes de réapprovisionnement, des mises à jour de tarifs, etc., sans que les utilisateurs aient à ajuster les réglages quotidiennement. En réalité, tous les fournisseurs permettent encore une configuration par l’utilisateur, mais nous privilégions ceux qui minimisent la nécessité d’interventions humaines. Méfiez-vous des solutions qui se vantent de leur automatisation tout en exposant des dizaines de réglages (paramètres, coefficients, règles) – c’est une contradiction en soi. La véritable automatisation naît du fait de laisser les algorithmes trouver les réglages optimaux, plutôt que d’exiger des utilisateurs qu’ils recalibrent constamment. Les meilleurs systèmes utilisent des techniques telles que des modèles auto-apprenants qui s’ajustent à mesure que de nouvelles données arrivent, de sorte que, sur le long terme, les décisions demeurent optimales sans intervention manuelle ⁵. Moins un utilisateur doit maintenir des réglages “driver”, plus l’automatisation est crédible.
Architecture robuste et économique : Nous avons évoqué l’efficacité en termes de coûts, mais il convient de le préciser explicitement : certaines solutions modernes ont adopté les entrepôts de données cloud (comme Snowflake) pour évoluer. Cela peut éliminer les soucis d’infrastructure, mais cela introduit un modèle de coût à l’usage. Si un outil de planification nécessite de traiter d’énormes volumes de données sur une plateforme telle que Snowflake, les coûts peuvent s’envoler (à l’image de la tarification MIPS d’IBM dans les années 1990, où une utilisation accrue du CPU entraînait des frais exponentiellement plus élevés). Une solution idéale gère le big data avec des algorithmes intelligents afin de maintenir une utilisation du cloud computing (et donc des coûts) raisonnable ⁴. De même, des solutions issues d’acquisitions peuvent se retrouver sous la forme d’un patchwork de modules sur différentes technologies, conduisant à des coûts d’intégration importants pour le client (que ce soit en termes financiers ou de latence système). Être cloud-native et intégré dès le départ est un avantage, mais seulement si l’architecture élimine véritablement tout transfert redondant de données sans introduire de nouveaux goulets d’étranglement.

Fort de ces critères établis, nous nous tournons maintenant vers les fournisseurs. Nous classons Lokad, RELEX, Blue Yonder et ToolsGroup comme les acteurs les plus pertinents pour l’optimisation du e-commerce, et nous évaluons chacun d’eux par rapport aux critères évoqués ci-dessus. L’analyse adopte un style narratif – mettant l’accent sur la manière dont chaque fournisseur aborde le problème et sur les points nécessitant du scepticisme – plutôt qu’une simple liste de fonctionnalités. Il est important de noter que nous nous appuyons sur des preuves crédibles (et des citations directes) dès que possible, évitant ainsi le piège courant de prendre les affirmations des fournisseurs pour argent comptant.

1. Lokad – Optimisation Quantitative unifiée avec une assise probabiliste

Lokad se distingue en tant que fournisseur explicitement construit autour de l’idée d’optimisation conjointe en utilisant une technologie de pointe. Contrairement aux logiciels traditionnels de supply chain, Lokad ne se présente pas sous la forme d’un ensemble de modules (prévision, MRP, etc.) à ajuster, mais plutôt comme une plateforme programmatique où une logique d’optimisation unifiée est implémentée pour chaque client. Cette approche, qu’ils qualifient de “Quantitative Supply Chain”, peut nécessiter davantage de data science en amont, mais elle aboutit à une solution adaptée à l’optimisation de toutes les décisions ensemble – stocks, tarification, réapprovisionnement, le tout en un. La philosophie de Lokad est que les prévisions ne sont qu’un moyen pour atteindre une fin; le véritable objectif est d’optimiser les décisions (par exemple, combien acheter, quel tarif appliquer) en tenant compte de toutes les contraintes et compromis économiques.

Au cœur se trouve la prévision probabiliste. Lokad a été l’un des pionniers dans l’utilisation de distributions de probabilité complètes pour la demande, et a même prouvé son efficacité dans l’arène neutre des compétitions de prévision. Lors de la prestigieuse M5 Forecasting Competition (2020), une équipe de Lokad s’est classée 6ème mondiale sur 909 équipes ⁶ – une validation impressionnante de leur technologie, étant donné que le M5 se concentrait sur des données de vente au détail granulaires (le type de données auquel sont confrontées les entreprises de le e-commerce). Il est à noter que M5 exigeait des prévisions probabilistes (au quantile), ce qui correspond à la force de Lokad. Ce résultat indique non seulement une compétence académique, mais aussi une pertinence pratique : leurs prévisions figuraient parmi les meilleures, ce qui soutient toute optimisation des stocks et de tarification. De plus, le PDG de l’entreprise a souligné qu’au-delà d’un certain seuil, les gains en précision de prévision offrent des rendements décroissants comparativement à une meilleure modélisation des décisions ⁷. En d’autres termes, Lokad insiste sur l’optimisation des décisions (quantités commandées, allocations, etc.) en utilisant les prévisions probabilistes, plutôt que de courir après une petite amélioration de précision susceptible de ne pas affecter de manière significative les résultats. Cette approche est rafraîchissante et importante pour le e-commerce : elle reconnaît que gérer des situations telles que les ruptures de stocks, la demande intermittente et les effets de substitution compte souvent plus qu’une amélioration de quelques pourcentages d’une métrique de prévision ⁷.

Techniquement, Lokad est à la pointe et fortement axé sur l’ingénierie. Ils ont construit leur propre stack technologique cloud-native (y compris un langage spécifique, “Envision”, destiné à écrire des scripts d’optimisation). Cette stack est conçue pour traiter de grandes quantités de données de manière efficace et économique. Par exemple, le système de Lokad traite régulièrement des gigaoctets à des téraoctets de données clients (commandes, clics, etc.) en quelques heures durant la nuit, pour produire des décisions pour le lendemain ⁸ ³. Pour ce faire, ils évitent de tout charger en RAM; ils utilisent à la place des fichiers mappés en mémoire et un stockage en colonnes sur disque, permettant de gérer, de manière transparente, des ensembles de données plus volumineux que la mémoire d’une machine en se déversant intelligemment sur des SSD rapides ³ ⁹. Ils notent explicitement qu’Envision (leur moteur) supporte des ensembles de données dépassant même la mémoire de l’ensemble du cluster en “déversant astucieusement sur des disques NVMe”, et que les opérations en parallélisme flagrant sont automatiquement réparties sur l’ensemble des cœurs/machines ³. L’effet net : Lokad peut évoluer vers des assortiments de SKU extrêmement vastes sans que le client ait à investir dans des quantités absurdes de RAM ou dans des appliances spécialisées. En fait, ils insistent sur le fait qu’il faut peu de matériel pour faire fonctionner le système – évitant ainsi des situations où “cliquer sur un bouton de lancement coûte des centaines de dollars” en frais de cloud computing ⁴. Ce point, subtil mais crucial, les différencie de certains systèmes d’entreprise lourds qui pourraient techniquement gérer le big data mais à un coût élevé. L’approche de Lokad se rapproche davantage d’un pipeline big data optimisé, comparable à Apache Spark ou Google BigQuery, mais conçu spécifiquement pour les calculs de supply chain. Cette focalisation sur l’efficacité permet de maintenir la solution rentable à mesure de son évolution – un grand avantage pour les e-tailers avec des millions d’enregistrements.

La gestion par Lokad de la tarification et de l’assortiment ne se fait pas via des modules séparés, mais grâce à une unique logique d’optimisation. Étant donné que la plateforme est essentiellement pilotée par le code, il est possible de modéliser les interactions. Par exemple, on peut écrire un script qui dit : “pour chaque produit, considérer la demande probabiliste à différents niveaux de prix, tenir compte de la disponibilité des stocks et du délai de réapprovisionnement, puis choisir le tarif qui maximise la marge attendue moins le coût de détention, tout en évitant les ruptures de stocks trop fréquentes” – il s’agit d’une description simplifiée, mais qui illustre que la tarification et l’optimisation de stocks peuvent être décidées ensemble. Si un produit est surstocké, le code pourrait décider d’appliquer une remise pour accélérer les ventes; s’il est rare, il pourrait augmenter le tarif pour allouer les stocks aux clients les mieux rémunérés. Peu d’autres fournisseurs permettent un tel niveau d’interaction. La solution de Lokad génère en fait ses propres politiques de décision adaptées aux données du marchand.

Les effets de cannibalisation et de substitution sont gérés naturellement si vous fournissez les bonnes données. Par exemple, on peut intégrer une donnée indiquant “si l’article A est indisponible, quelle part de sa demande se transfère vers l’article B” – de telles relations peuvent être apprises à partir des données historiques (en analysant les ruptures de stocks passées ou les changements d’assortiment) puis intégrées dans l’optimisation. Étant donné qu’Envision est un langage de programmation complet, ces dynamiques complexes de la demande peuvent être encodées. La documentation de Lokad indique qu’ils le font activement : le système “découvre des corrélations entre produits, canaux et périodes” et calcule les décisions en conséquence, plutôt que de supposer que chaque SKU est indépendant ¹⁰. Il ne se fonde pas sur une extrapolation simpliste des séries temporelles; il calcule des distributions de probabilité complètes pour la demande, qui tiennent compte des promotions, des ruptures de stocks, des variations saisonnières, etc. ¹¹. En capturant ces facteurs (y compris lorsque la demande a été perdue en raison d’une rupture de stocks), Lokad évite le problème classique du garbage-in posé par des prévisions basées sur des données de vente biaisées.

Un autre domaine où Lokad excelle est l’intelligence concurrentielle et l’intégration de données externes. La plateforme peut ingérer toute donnée pertinente – par exemple, les prix des concurrents, le trafic web, voire les calendriers de campagnes marketing – comme signaux d’entrée supplémentaires. Ils mentionnent explicitement la capacité d’incorporer “external signals such as competitor pricing” et les calendriers marketing, et d’expérimenter aisément avec de nouveaux algorithmes or inputs grâce à la conception programmatique ¹². Dans un sens pratique, si une entreprise de le e-commerce dispose, par exemple, de données extraites concernant les prix des concurrents ou sait qu’un niveau de stock d’un partenaire de marketplace est un indicateur, elle peut brancher cela dans le modèle de Lokad pour affiner les décisions. Ceci est bien plus flexible que la plupart des solutions prêtes à l’emploi qui pourraient ne gérer que des données internes. Cela illustre une approche “glass box” : plutôt que de masquer la logique, Lokad vous permet de l’adapter. Cela dit, l’approche de Lokad requiert un Supply Chain Scientist pour la configurer – ce n’est pas une interface point-and-click pour un novice. Cela pourrait être perçu comme un inconvénient pour certains ; cependant, le bénéfice est une solution qui correspond exactement aux besoins de l’entreprise et qui peut véritablement automatiser les décisions en fonction des règles uniques de celle-ci.

Automation and autonomy: Lokad est sans doute le planificateur de supply chain le plus robotisé de ce groupe. La philosophie est qu’une fois les scripts (logique) configurés et validés, le système peut fonctionner quotidiennement (ou en intra-day) et produire des décisions recommandées sans intervention humaine. De nombreux utilisateurs de Lokad font effectivement confiance au système pour générer des bons de commande et des suggestions de tarification que les planificateurs examinent brièvement ou exécutent même automatiquement. Étant donné que le système est auto-adaptatif (il réentraîne les prévisions chaque jour avec les dernières données et re-optimise en conséquence), il ne requiert pas de réglages manuels des paramètres. En fait, Lokad critique de manière assez nette l’habitude de réglages sans fin dans l’industrie – ils soulignent que leur système “does not rely on simplistic time-series methods” et fonctionne sans constant manual “tuning” from users ¹⁰. L’essentiel du travail d’ajustement pour la saisonnalité, les événements et la demande erratique est réalisé par les algorithmes, et non par des planificateurs qui modifient les prévisions. Un aspect clé est l’actionability : Lokad fournit des décisions (ou des recommandations actionnables) plutôt que de simples diagnostics. Par exemple, au lieu de simplement signaler qu’un certain article pourrait être en rupture de stock (comme le font certains tableaux de bord “control tower”), il recommandera directement une quantité de commande ou une modification de prix pour y remédier. Il vise à “recommend corrective actions rather than simply flashing an alert”, ce qui est crucial si vous souhaitez une exploitation sans surveillance ¹³. Dans un environnement de le e-commerce en évolution rapide, un système qui se contente d’indiquer qu’il y a un problème ne suffit pas – vous voulez qu’il vous dise ce qu’il faut faire à ce sujet, voire qu’il le fasse lui-même. Lokad est conçu pour faire cela.

Compte tenu de ces éloges, où peut-on rester sceptique à l’égard de Lokad ? La principale mise en garde est que l’approche de Lokad est très custom and technical. Ce n’est pas un SaaS plug-and-play que l’on active et qui affiche immédiatement une interface utilisateur agréable avec toutes les réponses. Il exige un certain niveau de maturité des données et une confiance dans les méthodes quantitatives de la part de l’entreprise utilisatrice. Il existe également une implicit dependency on Lokad’s team (“Supply Chain Scientists”) notamment lors de la configuration initiale – en effet, ils agissent comme votre équipe étendue pour mettre en œuvre la solution. Cela constitue un modèle différent de, par exemple, l’installation d’un logiciel bien défini. Si un client n’est pas prêt à s’engager dans ce processus collaboratif et technique, il pourrait rencontrer des difficultés. Cependant, ce modèle est aussi ce qui permet d’atteindre une optimisation poussée. Il s’agit d’un compromis classique : flexibilité et puissance contre facilité d’utilisation. Lokad optimise clairement en faveur de la puissance et de la flexibilité.

Du point de vue marketplace, la proposition de valeur de Lokad semble particulièrement alignée sur les besoins de le e-commerce. Les entreprises de le e-commerce font face à de nombreux défis – ruptures de stocks, surstocks, pics de demande volatiles provoqués par des promotions ou l’impact d’influenceurs, etc. – et elles recourent souvent à l’assemblage d’outils (tableaux de bord BI, scripts Python ad hoc, etc.) pour combler les lacunes laissées par leur ERP ou WMS. Lokad se positionne essentiellement comme the couche spécialisée qui capte tous ces signaux et fournit un plan quasi-optimal. Ils se distinguent explicitement des outils simplistes proposés par les marketplaces ou les ERP, en notant que ceux-ci “address only a fraction” de ce à quoi les entreprises de le e-commerce sont confrontées ¹⁴ ¹⁵. Par exemple, une marketplace Amazon pourrait vous fournir une prévision de la demande pour la semaine suivante – mais elle n’intégrera pas vos coûts de supply chain ni vos stocks multi-entrepôts. La technologie de Lokad est conçue pour gérer every signal pertinent jusqu’au niveau SKU, sans faillir, et sans que les utilisateurs aient à manipuler manuellement des tableurs ¹⁶. Il s’agit d’une proposition de valeur forte, si elle est fournie telle que annoncée.

Pour résumer Lokad : Il se classe en tête de notre liste grâce à sa holistic optimization capability and advanced technology. Il meets the joint optimization criterion head-on – les stocks, la tarification, et plus encore peuvent être optimisés ensemble via sa plateforme programmatique. Il utilise la probabilistic forecasting and economic drivers (ils réalisaient des prévisions quantiles avant que ce soit à la mode, comme en témoigne leur succès lors de la compétition M5 ⁶) et n’hésite pas à s’attaquer à des effets complexes tels que le remplacement ou les corrélations multi-canal. Son architecture est scalable et cost-conscious, évitant le piège de l’informatique en mémoire par force brute ³ ⁴. Le degré d’automatisation est très élevé, avec un réglage manuel minimal requis et un accent mis sur la production de décisions, et non seulement sur les insights ¹³. Le scepticisme que l’on pourrait exprimer à l’égard de Lokad porte moins sur la fonctionnalité de la technologie — les preuves suggèrent qu’elle fonctionne — que sur la capacité d’une organisation à adopter une solution aussi data-science-heavy. Il y a également la question du track record à plus grande échelle ; Lokad est plus petite que certains concurrents, bien qu’elle compte des clients notables (par exemple, des distributeurs industriels aftermarket, des fashion eTailers, etc., d’après leurs études de cas). Compte tenu de tout ce qui précède, Lokad obtient un classement de premier plan en tant que truly state-of-the-art eCommerce optimization vendor dans notre étude.

2. RELEX Solutions – AI-Powered Retail Optimization (with Caveats)

RELEX Solutions est un fournisseur d’origine finlandaise qui a rapidement émergé dans l’espace de la planification retail, souvent mentionné aux côtés des géants historiques de la prévision et du réapprovisionnement. RELEX propose une unified platform couvrant la prévision de la demande, le réapprovisionnement des stocks, l’allocation, l’assortiment, la planification de la main-d’œuvre, et récemment l’optimisation de la tarification et des promotions. Leur force principale a été dans le grocery and retail (y compris les magasins physiques), mais ils ciblent activement également les acteurs de le e-commerce, en mettant l’accent sur leur capacité à planifier à travers les canaux en ligne et hors ligne. Pour les utilisateurs purement de le e-commerce, la valeur de RELEX réside dans sa end-to-end planning – garantissant le bon stock au bon endroit, au bon prix et avec les bonnes promotions, en utilisant des algorithmes avancés pour réagir aux changements de la demande.

RELEX promeut fortement son utilisation de AI and machine learning. En fait, son PDG Mikko Kärkkäinen est un partisan éminent de “pragmatic AI” dans le retail. Selon Kärkkäinen, “AI-driven inventory management systems process hundreds of demand-influencing factors” pour améliorer la précision des prévisions ¹⁷. Il souligne même que des données telles que la météo ne constituent pas un seul facteur, mais “hundreds of different factors” (température, humidité, etc.) que prennent en compte leurs modèles de machine learning ¹⁸. Cela illustre l’approche de RELEX : lancer un large filet pour capter des signaux prédictifs (météo, promotions, jours fériés, tendances sur les réseaux sociaux, etc.) et utiliser le ML pour les corréler aux ventes. L’avantage est que le système peut détecter des schémas complexes (par exemple, comment une vague de chaleur soudaine affecte la demande pour certaines boissons en combinaison avec le fait que ce soit un week-end férié). La skeptical view, toutefois, est que vanter “hundreds of factors” pourrait être plus du marketing qu’une réelle amélioration. En prévision, au-delà d’un certain point, ajouter plus d’inputs entraîne des rendements décroissants ou peut même détériorer la précision si le modèle surajuste le bruit. Cela rend également le modèle une boîte noire – il est pratiquement impossible pour un humain de comprendre un modèle qui utilise réellement des centaines de variables. RELEX tente de contrer cette préoccupation en faveur d’une approche “glass box” (transparence en AI). Ils ont évoqué la fourniture de visibilité sur les prévisions et pas seulement sur un résultat, permettant aux planificateurs de voir les leviers clés. Mais, en réalité, un réseau de neurones ou un modèle de gradient boosting avec des centaines de features ne sera pas entièrement interprétable. Les planificateurs devront faire confiance au système. Il s’agit d’un compromis général avec l’AI/ML : RELEX penche pour “throw lots of data at the problem and let the algorithms figure it out.”

Cela donne-t-il des résultats ? Les clients de RELEX rapportent souvent une amélioration des prévisions et moins de ruptures de stocks, notamment dans des situations promotional and seasonal où les méthodes traditionnelles peinaient. Par exemple, RELEX intègre les prévisions météo et a revendiqué jusqu’à une réduction de 75 % de l’erreur de prévision pour certains produits sensibles aux conditions météorologiques lors de phénomènes inhabituels ¹⁹. Nous prenons de telles affirmations spécifiques avec précaution – elles pourraient être cherry-picked. Néanmoins, l’approche de RELEX apporte vraisemblablement de la valeur dans la prévision à court terme (“demand sensing”) en ajustant les prévisions en fonction des informations les plus récentes. En substance, leurs modèles de ML affinent continuellement la prévision de base avec de nouveaux signaux de données. Cela se rapproche de ce que certains appellent le demand sensing (utiliser des données near-real-time pour mettre à jour les prévisions sur court terme). RELEX, dans ses documents, intègre le demand sensing dans sa prévision ML globale plutôt que de le traiter comme un module séparé. Ils défendent le concept de “continuous, automated re-forecasting” à mesure que les situations évoluent.

Du côté de l’joint optimization, dans quelle mesure RELEX couvre-t-il la tarification et l’assortiment en plus des stocks ? Historiquement, RELEX était le plus fort en réapprovisionnement et en allocation (en veillant à ce que les magasins ou centres de distribution ne soient pas en rupture). La planification de l’assortiment (décider quels produits vont dans quels magasins ou quels SKUs conserver) faisait également partie de leur offre, tout comme l’planogram optimization (planification de l’espace). L’optimisation de la tarification était une lacune jusqu’à récemment – mais en 2022, RELEX a introduit une capacité d’AI-driven price optimization ²⁰ ²¹. Ils la positionnent comme étant parfaitement unifiée avec leur planification des promotions. Par exemple, leur outil de planification des promotions et leur outil d’optimisation des prix partagent les mêmes données et la même interface utilisateur, de sorte qu’un détaillant peut planifier une promotion et le système peut recommander la profondeur de remise optimale, le moment idéal, etc., puis les implications sur les stocks sont automatiquement prises en compte. Cela s’oriente certainement vers une optimisation conjointe. Cependant, il n’est pas clair si RELEX optimise vraiment la tarification et les stocks ensemble ou si cela se fait toujours de manière séquentielle (d’abord décider du prix, puis le flux de stocks s’ajuste). Dans une optimisation conjointe idéale, vous prendriez en compte les contraintes de stocks lors de la fixation des prix (par exemple, ne pas promouvoir un article de manière agressive si l’approvisionnement est limité). La plateforme intégrée de RELEX permet vraisemblablement une telle réflexion transversale – par exemple, leur système remarquerait “we don’t have enough stock in the DC to support this promotion in all stores” et pourrait le signaler ou l’ajuster. Ils mentionnent l’alignement de la tarification et des promotions avec la supply chain pour garantir que les plans soient exécutables ²². Ainsi, RELEX est conscient de la nécessité de briser les silos.

Un point de vue d’initié : L’attrait de RELEX réside dans le fait qu’il intègre tout (demande, supply, operations) dans une seule plateforme for the user. Par exemple, merchandise planners peuvent voir des prévisions partagées et des contraintes inter-départements ²². Cela signifie qu’un planificateur peut comprendre l’impact qu’une décision de tarification aura sur la supply chain et vice versa. Cette visibility représente une nette amélioration par rapport aux outils cloisonnés. Mais visibility is not the same as fully algorithmic optimization. Nous soupçonnons que, bien que RELEX offre une expérience utilisateur et un modèle de données très cohérents, une partie de la prise de décision pourrait encore se faire par étapes. L’optimisation de la tarification pourrait sortir un prix idéal, puis le module de stocks planifierait autour de celui-ci. La forte intégration assure qu’ils ne se contredisent pas, mais cela ne résout pas nécessairement un problème d’optimisation unique visant à maximiser le profit en tenant compte simultanément des coûts liés aux stocks. Réaliser cela est complexe et peu de fournisseurs (excepté peut-être Lokad, comme discuté) tentent explicitement de le faire.

Du point de vue de l’technology architecture, RELEX est assez avancé. Ils ont construit leur propre moteur de base de données en mémoire dès les débuts (une base de données en colonnes optimisée pour les séries temporelles et les données hiérarchiques) ce qui leur a permis de calculer les prévisions pour des milliers de magasins x SKUs rapidement. De nombreuses études de cas évoquent RELEX remplaçant des tableurs et des systèmes legacy et étant immédiatement capable de gérer une granularité de données bien plus fine (comme passer d’une planification hebdomadaire à quotidienne, ou adopter une planification spécifique par magasin plutôt qu’une approche unique pour tous). Pour le e-commerce, cela signifie que RELEX peut probablement gérer des prévisions au niveau SKU pour une boutique en ligne globale sans problème. Ils disposent de déploiements cloud et peuvent monter en charge. Nous n’avons trouvé aucune plainte spécifique concernant les coûts de la technologie de RELEX ; au contraire, ils se targuent d’une computation efficiente (leurs fondateurs académiques ont beaucoup optimisé les algorithmes). Une chose qu’ils proposent est un concept de “Live database” en mémoire, qui, s’il est mal configuré, pourrait nécessiter beaucoup de RAM – mais cela relève de la spéculation. De manière générale, la scalabilité de RELEX n’a pas été un signal d’alerte sur le marché ; ils desservent d’énormes chaînes de grande distribution avec des dizaines de milliers de SKUs et de nombreux magasins, ce qui équivaut ou représente un volume de données supérieur à celui de nombreux e-tailers.

Automatisation et le rôle des planificateurs : RELEX parle souvent de “planification autonome” mais aussi de “décisions assistées.” Ils ne positionnent pas leur outil comme une boîte noire qui élimine le planificateur. En fait, ils mettent l’accent sur la facilité d’utilisation – p. ex. leur UI, des tableaux de bord configurables, et la gestion des exceptions. Le système générera automatiquement des bons de commande ou des recommandations de transfert, mais généralement un planificateur les examine et les approuve (surtout aux premiers stades d’adoption). RELEX a un concept d’“exceptions de prévision” où, si la prévision de l’IA s’écarte trop en raison d’une anomalie, elle la signale. Ils disposent également d’une capacité de simulation où les planificateurs peuvent voir pourquoi le système suggère quelque chose (du moins de manière générale, par exemple “parce qu’il faisait chaud, nous prévoyons une augmentation de +50%”). Mikko Kärkkäinen a déclaré : “les solutions de premier ordre tirent parti d’une IA pragmatique et de la puissance de calcul pour optimiser les tâches… de manière autonome sans intervention humaine” ²³, et il décrit également “une planification de la distribution autonome, auto-apprenante et auto-ajustante qui brise les silos” ⁵. Ainsi, du moins en vision, RELEX vise un système largement autonome. Nous restons quelque peu sceptiques quant à une autonomie totale ici : les grands distributeurs utilisant RELEX disposent toujours d’équipes de planification. Mais ces équipes gèrent probablement désormais par exception, ce qui représente une forme d’autonomie partielle.

L’une des contradictions à surveiller avec RELEX (et des fournisseurs similaires) est la promesse à la fois d’une flexibilité extrême et d’une automatisation extrême. Ils prétendent que le système est très flexible (par exemple, on peut configurer le fonctionnement des règles de tarification, ou ajuster les modèles de prévision), tout en affirmant qu’il s’auto-ajuste. Il y a une tension : si un utilisateur peut trop souvent contourner manuellement, le système pourrait en pratique dépendre de ces réglages manuels. S’il fait réellement confiance à l’IA, il devrait devoir intervenir de moins en moins. La référence de RELEX à “self-tuning” implique ce dernier point – que le système nécessitera moins d’ajustements manuels des paramètres au fil du temps ⁵. Nous avons vu mentionner que l’approche de RELEX transforme les planificateurs en superviseurs. Par exemple, un article notait que le système de RELEX libérait les planificateurs des tâches manuelles pour se concentrer sur des mouvements stratégiques ²⁴. Pourtant, une source issue d’agrégats d’avis sur SelectHub indiquait que certains utilisateurs trouvaient certaines parties de RELEX « maladroites » et rencontraient des problèmes comme la prévision de certaines contraintes (limites de fret) nécessitant des solutions de contournement ²⁵. Cela indique que ce n’est pas de la magie ; les utilisateurs se heurtent encore à des limites où ils doivent intervenir ou où l’outil n’est pas aussi fluide.

Problèmes ou préoccupations connus : Il n’existe pas de cas de « défaillances » documentés publiquement pour RELEX comme c’est le cas pour certains (aucun titre de procès). L’entreprise bénéficie généralement d’une bonne réputation. Cependant, des discussions anonymisées entre initiés mentionnent parfois que la mise en œuvre de RELEX dans des environnements très grands et complexes peut faire émerger des problèmes. Par exemple, l’intégration de données peut être un défi (garbage in, garbage out – si les données du client sont un désordre, RELEX pourrait produire de mauvais plans, et la faute est imputée soit à l’outil, soit aux données). De plus, la croissance agressive de RELEX (ils ont intégré de nombreux clients rapidement) signifie que certains clients pourraient ne pas bénéficier du même accompagnement qu’offert, par exemple, par Lokad. Ce n’est pas une critique du logiciel en soi, mais des résultats concrets : combien de projets RELEX atteignent les KPI promis ? Les fournisseurs aiment citer les meilleures améliorations (« réduction des stocks de X% chez Y client ! »), mais mentionnent rarement des cas où les chiffres ne se sont pas matérialisés. Nous soupçonnons que RELEX, comme tous les fournisseurs, a eu quelques projets qui n’ont pas satisfait aux attentes, possiblement en raison d’une gestion du changement médiocre ou du fait que le distributeur ne faisait pas suffisamment confiance au système pour agir en conséquence. Lors d’un sommet partenaires, même Blue Yonder a admis que la gestion inefficace du changement et les problèmes de données causaient la majorité des échecs de projets ²⁶ – il en est vraisemblablement de même pour les implémentations de RELEX.

Un autre aspect noté : RELEX tend à incorporer beaucoup de données externes, y compris des éléments comme Google Trends, des données de localisation mobile pour prédire l’affluence, etc. Pour un acteur du eCommerce, certains de ces éléments (comme l’affluence) sont hors de propos, mais d’autres (la météo, les tendances) ne le sont pas. On peut se demander : ai-je vraiment besoin de tous ces flux de données ? Pour certaines entreprises électroniques, de simples modèles basés sur l’historique des ventes pourraient être presque aussi efficaces. RELEX vendra certainement l’idée que plus de données produisent de meilleures prévisions. Les résultats de la compétition M5 (à laquelle RELEX n’a pas participé publiquement, à notre connaissance) ont montré que des modèles sophistiqués battaient les modèles plus simples, mais souvent par de faibles marges. Les meilleures méthodes étaient souvent des ensembles de nombreux modèles, semblables à ce que RELEX pourrait faire en interne. Mais de manière intéressante, une approche pure en machine learning n’écrasait pas catégoriquement les méthodes traditionnelles dans ces concours – une combinaison de modèles statistiques soigneusement ajustés tendait à l’emporter. Ainsi, si nous recoupions les affirmations de RELEX avec des benchmarks comme M5 : nous constatons que la prévision probabiliste est effectivement précieuse (ce qu’ils font), mais nous constatons également qu’il n’existe pas de sauce secrète unique parmi les meilleures approches – c’est une question de modélisation minutieuse. En l’absence de publication de la précision de RELEX sur de tels ensembles de données standards, nous restons prudents. Le conseil du sceptique à quiconque envisage RELEX est : demander des preuves spécifiques d’amélioration et définir une base de référence claire. Par exemple, si RELEX dit “nous avons amélioré la précision des prévisions de 30%”, précisez “30% par rapport à quel indicateur et quelle base de référence ?” Bien des fois, les fournisseurs mesurent l’amélioration par rapport à un scénario qui flatte leur outil (par exemple, comparé à des prévisions naïves ou à une mauvaise année). La recommandation de cette étude : exiger de la clarté sur les bases de référence pour toute affirmation de performance.

En résumé, RELEX Solutions se classe parmi les meilleurs fournisseurs car il aborde de manière intégrée les domaines clés (demande, stocks, tarification) et utilise largement des techniques modernes d’IA/ML. Parmi ses points forts, on compte une prévision très granulaire qui prend en compte une myriade de facteurs, de solides capacités de promotion et de planification saisonnière, ainsi qu’une plateforme unifiée offrant à toutes les parties prenantes une source unique de vérité. Il coche la case de la scalabilité (prouvée dans le grand retail), de la gestion de la cannibalisation (via des modèles de prévision avancés qui considèrent les effets interproduits ²⁷), du marketplace/omni-channel (le système peut planifier simultanément pour le en ligne et le hors-ligne et probablement intégrer des données de concurrents si fournies). RELEX se dirige également vers l’automatisation, avec des promesses de modèles auto-ajustants et de décisions autonomes, bien qu’en pratique une certaine supervision par l’utilisateur demeure. Les principales mises en garde concernent la complexité et l’opacité qui accompagnent son approche fortement axée sur l’IA – les utilisateurs doivent faire confiance à la boîte noire dans une certaine mesure – et la nécessité de distinguer le battage médiatique de la réalité dans son marketing. Nous classons RELEX hautement, mais avec un astérisque : c’est un outil puissant, mais qui nécessite une mise en œuvre soigneuse et une culture axée sur les données pour en tirer pleinement parti. Nous encourageons également les utilisateurs potentiels à se méfier du “AI washing” dans l’industrie ; le message de RELEX est parmi les plus crédibles (puisqu’ils disposent bel et bien d’une véritable technologie sous le capot), mais même les déclarations de Mikko concernant “des centaines de facteurs” ¹⁷ doivent être considérées comme un enthousiasme pour l’IA plutôt que comme une garantie de résultats bien meilleurs qu’un concurrent. Dans un contexte eCommerce, RELEX peut certainement faire le travail, il suffit de mesurer ses résultats rigoureusement et de vérifier si toutes ces fonctionnalités sophistiquées sont réellement utilisées dans votre cas ou si elles restent simplement inactives dans le logiciel.

3. Blue Yonder – Le mastodonte historique en transformation (Promesses vs. Réalité)

Blue Yonder (anciennement connu sous le nom de JDA Software) est un géant des logiciels de supply chain, avec des décennies d’histoire dans les systèmes de planification pour la distribution et la fabrication. Il propose une suite complète qui couvre la prévision, le réapprovisionnement, la gestion d’entrepôt, le transport, la gestion des effectifs, et la tarification (après avoir acquis le spécialiste de la tarification Revionics en 2020). Pour les acteurs du eCommerce, Blue Yonder offre des solutions initialement conçues pour de grands distributeurs et des entreprises de produits de grande consommation – pensez-y comme le mastodonte de l’entreprise dans ce domaine. Cependant, avec cet héritage viennent à la fois des points forts (fonctionnalité robuste, scalabilité, expertise sectorielle) et des faiblesses significatives (technologie obsolète dans certaines parties, problèmes d’intégration dus à de multiples acquisitions, et un palmarès comprenant quelques échecs retentissants).

En termes d’optimisation conjointe, l’histoire de Blue Yonder est quelque peu mitigée. Ils ont effectivement des composants pour toutes les parties : par exemple, leur Luminate Demand Edge pour la prévision, Luminate Allocation/Replenishment pour les stocks, et Revionics pour la tarification. Sur le papier, vous pourriez utiliser les trois et atteindre une stratégie coordonnée – par exemple, la prévision alimente à la fois le plan de stocks et les modèles d’optimisation des prix, et l’optimisation des prix peut prendre en compte l’élasticité de la demande (ce qui revient essentiellement à prévoir la demande à différents niveaux de prix). Blue Yonder commercialise certainement l’idée d’un système de bout en bout, « de la planification à l’exécution » unifié sous leur plateforme Luminate. En pratique, cependant, beaucoup de ces modules ont évolué séparément et n’ont été réunis que récemment. Le moteur d’optimisation des prix de Revionics, par exemple, a son propre héritage et a été intégré après acquisition. Le défi pour Blue Yonder est de faire en sorte que cela paraisse comme une solution cohérente. L’entreprise a reconnu qu’historiquement elle disposait d’une suite fragmentée; en conséquence, en 2023, elle a annoncé une transformation architecturale majeure : passer à un « modèle de données unique et une plateforme applicative » sur le cloud Snowflake ²⁸. C’est une étape majeure – en substance, réingénierie de leurs produits pour qu’ils puissent tous lire/écrire depuis un grand répertoire de données cloud (Snowflake) afin que les silos de données disparaissent. Le PDG a déclaré une vision d’« un système d’exploitation de la supply chain pour le monde » où toutes les applications BY partagent les données de manière fluide ²⁸.

Nous considérons cette vision à la fois prometteuse et problématique. Prometteuse car, si elle est réalisée, elle permettrait effectivement de résoudre de nombreux problèmes d’intégration (fini les interfaces batch entre la planification de la demande et la tarification, par exemple – ils consultent littéralement les mêmes données dans Snowflake). Problématique car elle est extrêmement ambitieuse et risquée. Même le cabinet de conseil partenaire de Blue Yonder a noté, « Bien que visionnaire, nous pensons que supprimer complètement les intégrations pourrait être trop optimiste pour la plupart des clients. » ²⁹. Les clients disposent de données dans de nombreux endroits, tout ne sera pas soigneusement logé dans Snowflake, donc une intégration personnalisée sera toujours nécessaire pour les systèmes qui ne sont pas de Blue Yonder ²⁹. En bref, la stratégie de Blue Yonder est un travail en cours – une réponse à la perception de son statut de « legacy ». Ils ont explicitement déclaré qu’ils ne forceront pas des « événements de rupture » (abandonner la vieille technologie du jour au lendemain) mais qu’ils vont progressivement transformer les modules legacy en microservices, permettant aux clients de migrer à leur propre rythme ³⁰ ³¹. Cela signifie qu’actuellement, un client de Blue Yonder pourrait encore utiliser, par exemple, l’ancienne planification de demande JDA en local, avec une intégration à Revionics dans le cloud. La plateforme entièrement unifiée pourrait mettre quelques années avant d’être disponible pour le grand public. En attendant, l’optimisation conjointe est plus manuelle avec Blue Yonder : vous pouvez utiliser leurs outils en tandem, mais il revient souvent à l’utilisateur de coordonner (par exemple, s’assurer que les actions de l’équipe de tarification sont intégrées dans le plan de stocks).

Blue Yonder coche de nombreuses cases technologiques sur le papier : ils intègrent désormais le machine learning dans la prévision (en s’appuyant sur la technologie de la société Blue Yonder GmbH qu’ils ont acquise en 2018, spécialisée dans l’IA pour le retail). Ils prétendent utiliser « une IA explicable, le machine learning, et même l’IA générative » dans diverses applications ³². Ils disposent assurément d’algorithmes avancés pour des aspects tels que l’optimisation du réapprovisionnement, l’allocation, etc., développés sur plusieurs décennies. Mais il faut rester sceptique car Blue Yonder a également beaucoup de dette technique. Beaucoup de leurs algorithmes de base ont été développés dans les années 90 ou au début des années 2000 par i2 Technologies ou JDA. Ils ont été améliorés, certes, mais jusqu’à la récente réécriture pour le cloud, une grande partie fonctionnait sur de vieilles architectures (certaines solutions nécessitaient des bases de données Oracle, etc.). Ainsi, lorsque Blue Yonder fait la promotion de « la planification cognitive pilotée par le ML », il convient de se demander : s’agit-il vraiment d’une technologie nouvelle ou simplement d’un nouveau nom commercial ? Par exemple, leur planification de la demande utilise peut-être maintenant le ML pour estimer les rehaussements de prévision pour les jours fériés, ce qui est positif, mais l’architecture sous-jacente exploite-t-elle vraiment la puissance de calcul du cloud actuel, ou est-elle limitée par le fait d’être intégrée dans un système legacy ?

Un problème historique concret : Blue Yonder (JDA) a acquis i2 Technologies en 2010. i2 était réputé pour ses solutions fortement axées sur l’optimisation, mais également pour ses implémentations ratées par moments. Notamment, après l’achat de i2 par JDA, Dillard’s (un grand grand magasin) a remporté un procès de 246M$ alléguant que le logiciel d’i2 n’avait pas tenu ses promesses ³³ ³⁴. Ce fut un énorme coup dur – en substance, le logiciel et le projet ont tellement échoué que le client a obtenu des dommages dépassant 30 fois ce qu’il avait payé pour le logiciel. Cette saga, bien qu’il y ait 15 ans, souligne que même les fournisseurs très réputés peuvent avoir des échecs majeurs si la technologie sur-promet ou n’est pas bien implémentée. Blue Yonder a dû absorber ce coût et en a tiré des leçons (on l’espère). Cela souligne la raison pour laquelle nous restons sceptiques : les grands fournisseurs peuvent vanter des « produits de classe mondiale » mais il existe des preuves qu’ils ne fonctionnent pas comme annoncé dans certains cas. Chaque fournisseur a des échecs ; Blue Yonder a au moins eu l’un d’eux traîné devant les tribunaux publics.

Pour le crédit de Blue Yonder, ils sont devenus plus transparents quant à la résolution des problèmes. Lors de leur sommet partenaires de 2023, ils ont ouvertement discuté des « projets rouges » (implémentations problématiques) et constaté que les principales causes n’étaient pas les algorithmes en soi, mais « une gestion du changement inefficace et des problèmes de migration/intégration des données » ²⁶. Ils ont noté que disposer de données fiables et soutenir le client dans l’adaptation des processus étaient essentiels. Cette introspection est positive – elle signifie que Blue Yonder n’est pas aveugle aux raisons des échecs de projets. Elle s’aligne également avec le thème général de notre analyse : souvent, ce n’est pas que les mathématiques sont incorrectes, c’est l’intégration dans le monde réel qui est difficile. Le fait que Blue Yonder identifie les défis de l’intégration des données est révélateur : cela reflète la complexité de leur suite. Car si leurs modules étaient véritablement intégrés de manière transparente, la migration des données ne serait pas un tel casse-tête. Le fait que ce soit le cas implique que les clients ont peut-être dû effectuer une importante réconciliation des données pour utiliser la suite complète. La couche unifiée de données Snowflake vise à résoudre ce problème, mais comme indiqué, il est encore tôt.

Examinons les capacités actuelles de Blue Yonder pour un scénario eCommerce:

Prévisions de la demande: Blue Yonder Luminate Demand (notamment avec Demand Edge) utilise machine learning pour intégrer de nombreux facteurs (météo, événements, tarification). Ils se sont également orientés vers des prévisions probabilistes ; au moins, ils supportent l’utilisation d’intervalles de confiance ou de quantiles dans la planification. Un exemple tiré de leur blog : ils n’utilisent pas l’IA simplement pour superposer des facteurs sur une base de référence, mais pour reconstruire la prévision depuis zéro chaque jour en utilisant les données les plus récentes, tenant automatiquement compte de choses telles que les décalages calendaires et s’auto-corrigeant à mesure que de nouvelles valeurs réelles arrivent ³⁵ ³⁶. Ils affirment que cela supprime la nécessité pour les planificateurs de maintenir des ajustements manuels ou des profils pour la saisonnalité – le modèle les apprend et s’adapte ³⁶. Cela est tout à fait conforme aux pratiques de prévision à la fine pointe de la technologie. L’approche de Blue Yonder ici est théoriquement solide : apprentissage continu, reconnaissance de l’incertitude (ils évoquent le risque de surestimation/sous-estimation et les compromis de coûts ³⁷), et utilisation du ML pour détecter des relations complexes (par exemple, comment différentes conditions météorologiques ou promotions stimulent la demande, sans qu’un humain ne code explicitement ces relations).
Stocks & Réapprovisionnement: Cela a longtemps été un point fort de JDA/Blue Yonder. Ils offrent une optimisation de stocks multi-niveaux (MEIO), c’est-à-dire qu’ils peuvent optimiser les niveaux de stocks dans les DC et les centres de traitement pour le eCommerce, en tenant compte des délais, de la variabilité de la demande, etc., afin d’atteindre des taux de service cibles. Les outils de Blue Yonder peuvent générer des quantités de commande recommandées, des stocks de sécurité, etc. Historiquement, ces algorithmes étaient plus basés sur des règles/heuristiques ou utilisaient la programmation linéaire pour des problèmes spécifiques. Ils sont vraisemblablement désormais complétés par des prévisions basées sur ML, mais l’optimisation de base est probablement un mélange de recherche opérationnelle et de simulation. BY peut certainement gérer une planification SKU à grande échelle ; nombreux sont les détaillants Fortune 500 qui utilisaient JDA pour le réapprovisionnement en magasin, ce qui est analogue, en termes d’échelle, à un grand entrepôt e‑comm servant des clients.
Assortiment: Blue Yonder dispose d’outils de gestion de catégorie qui aident à décider des assortiments (quel mix de produits dans quels magasins). Pour un acteur uniquement eCommerce, la planification de l’assortiment peut signifier décider quels nouveaux produits lister ou retirer. Les outils de BY peuvent utiliser des attributs et des données de performance pour évaluer les changements d’assortiment. Toutefois, il s’agit généralement d’un processus stratégique périodique, et non continu.
Optimisation des prix: Avec l’acquisition de Revionics, Blue Yonder a gagné un moteur robuste d’optimisation des prix, largement utilisé dans le commerce de détail (notamment dans les chaînes d’épicerie et de marchandises générales) pour fixer les prix de base, les remises promotionnelles et les déstockages. Revionics utilise l’IA pour modéliser l’élasticité des prix et même les impacts de la tarification concurrentielle, puis recommande des modifications de prix qui atteignent des objectifs tels que la croissance des marges ou du chiffre d’affaires tout en tenant compte des règles de tarification (par exemple, finir les prix par .99, etc.). Dans le cadre de Blue Yonder, Revionics est désormais connu sous le nom de Luminate Pricing. En théorie, ce moteur, combiné aux prévisions de la demande de Blue Yonder, boucle le circuit – vous pouvez simuler l’impact d’une modification de prix sur la demande et les stocks, et choisir un prix optimal. Blue Yonder présente cela comme “autonomous pricing powered by AI”, capable de fonctionner aussi souvent que nécessaire (même en intrajournalier pour le e‑commerce si désiré).

Une grande question : Dans quelle mesure ces éléments fonctionnent-ils réellement ensemble aujourd’hui ? Blue Yonder affirme que c’est le cas. Par exemple, ils pourraient dire que leur solution de tarification peut intégrer les prévisions de leur solution de demande et produire des prix que la solution de stocks utilise ensuite pour planifier les commandes. Mais si ces intégrations ne sont pas en temps réel ou nécessitent un travail informatique personnalisé, le circuit ne sera peut-être pas aussi serré qu’on pourrait l’espérer. De manière réaliste, un utilisateur eCommerce de Blue Yonder en 2023 pourrait utiliser l’outil de tarification séparément de l’outil de supply, peut-être avec des mises à jour groupées hebdomadaires de l’élasticité des prévisions. Ce serait de la planification conjointe, mais pas le saint Graal de l’optimisation conjointe instantanée.

Sur les affirmations en matière d’IA/ML, Blue Yonder souffre parfois d’un excès de jargon dans son marketing. Ils utilisent des termes comme “cognitive”, “machine learning-driven”, etc. Nous devrions vérifier s’il y a une véritable substance. Il existe quelques preuves de substance : par exemple, Blue Yonder (la filiale allemande à l’origine) avait développé des algorithmes dont on a parlé dans des publications (leur équipe avait remporté une compétition précoce de prévisions dans le retail en 2014 en utilisant des réseaux de neurones). De plus, le portefeuille de brevets de Blue Yonder est important (plus de 400 brevets), indiquant une forte activité de R&D ³⁸. Cependant, la quantité de brevets n’égale pas la qualité du produit – cela montre simplement qu’ils ont expérimenté de nombreuses techniques. La perspective sceptique est de demander à Blue Yonder des résultats spécifiques : par exemple, ont-ils participé à M5 ou à un benchmark neutre ? Pas publiquement. Existe-t-il des études de cas avec des chiffres concrets avant/après ? Ils en ont, mais souvent, les études de cas fournies par le fournisseur sont optimistes et manquent de repères clairs. Blue Yonder avance des propos tels que “X détaillant a vu son profit augmenter de Y% en utilisant notre tarification” – mais sans contexte, ce n’est que du marketing.

Il faut également tenir compte du coût et de la complexité avec Blue Yonder. Il s’agit de grands systèmes d’entreprise. La mise en œuvre peut prendre de nombreux mois, voire des années, et impliquer non seulement la configuration logicielle, mais aussi la refonte des processus métier. Blue Yonder requiert généralement soit ses services professionnels, soit le recours à une entreprise partenaire pour l’implémentation. Le coût total de possession peut être très élevé (licence + services + IT). Pour un acteur purement eCommerce, en particulier une entreprise de taille moyenne, Blue Yonder pourrait s’avérer excessif ou trop lent à mettre en œuvre par rapport à des solutions SaaS plus agiles. Même les grandes entreprises rechignent parfois : un événement marquant de l’industrie fut Lidl (le grand détaillant mondial) annulant un projet SAP de 500 M€ en 2018 après que celui-ci n’ait pas répondu aux besoins ³⁹. Il s’agissait de SAP, pas de Blue Yonder, mais cela illustre que d’énormes projets peuvent échouer, engloutissant des budgets considérables. Les projets de Blue Yonder sont tout aussi complexes ; en effet, leur partenaire JBF Consulting a noté que le concurrent Manhattan Associates avait adopté une approche différente (exigeant une réimplémentation pour leur nouvelle plateforme), tandis que BY tente une migration plus douce ⁴⁰. Le fait que Manhattan ait opté pour une “réimplémentation pour passer à une nouvelle technologie” suggère que ces transitions ne sont pas anodines. Blue Yonder essaie d’éviter des mises à niveau cauchemardesques en évoluant progressivement – mais cela signifie aussi que les clients pourraient avoir affaire à une technologie pas tout à fait moderne actuellement, en attendant les nouveautés.

Du point de vue de l’automatisation, Blue Yonder est aujourd’hui probablement moins automatisé que ce que Lokad ou RELEX ambitionnent d’être. De nombreux clients de BY utilisent les outils pour générer des recommandations que les planificateurs approuvent ou ajustent ensuite. Blue Yonder met en avant le concept de “supply chain autonome” (d’autant plus que, depuis son acquisition par Panasonic en 2021, ils parlent de connecter les données IoT à des décisions automatisées) ⁴¹. Cependant, il est certain qu’une grande partie de leur clientèle est encore en mode hybride : faisant confiance au système pour certaines décisions, et intervenant manuellement pour d’autres. Par exemple, il n’est pas rare que le système propose des commandes et qu’un planificateur vérifie les exceptions (tout comme avec RELEX). Ou bien, le système de tarification propose des modifications de prix, mais un responsable merchandising les examine, rejetant peut-être celles qui ne s’alignent pas avec la stratégie de marque. Le logiciel peut accomplir de nombreuses tâches, mais les entreprises disposent de processus établis qui ne changent pas du jour au lendemain.

Veille concurrentielle et marketplaces: La solution de tarification de Blue Yonder (Revionics) intègre des données de prix concurrentiels – elle dispose d’une fonctionnalité de réaction concurrentielle et peut intégrer les prix de vos rivaux pour ajuster les vôtres ⁴². Ainsi, pour l’eCommerce, si vous disposez d’un flux de tarification de concurrents, Revionics peut l’inclure dans son optimisation (par exemple, en évitant de fixer un prix supérieur à celui d’un concurrent de plus de X% afin de maintenir l’image de prix, ou en égalant le prix le plus bas si nécessaire). C’est un atout pour l’optimisation conjointe de la tarification. Sur les marketplaces, Blue Yonder ne propose pas spécifiquement de module de gestion des marketplaces comme certains fournisseurs spécialisés e‑comm (tels que des outils de type channel advisor pour Amazon). Ainsi, on pourrait utiliser Blue Yonder pour la planification de base tout en ayant besoin d’un outil séparé afin de gérer les tactiques spécifiques aux marketplaces (publicité, buy-box, etc.). Cela sort du cadre de Blue Yonder et n’est pas une critique à son encontre, c’est simplement de noter que l’eCommerce comporte des facettes que ces fournisseurs traditionnels ne traitent pas (pour être juste, Lokad ou RELEX ne couvrent pas non plus les enchères publicitaires, etc.).

Étant donné l’ampleur et l’héritage de Blue Yonder, il convient également de scruter les contradictions internes dans leur communication. Par exemple, Blue Yonder pourrait vanter la “personnalisation et tarification en temps réel” sur sa plateforme de commerce, alors que ses solutions de planning fonctionnaient historiquement par cycles groupés (planification nocturne, réajustements hebdomadaires, etc.). Ils se dirigent vers une utilisation plus en temps réel des données (leur partenariat avec Snowflake vise en partie à permettre un partage quasi en temps réel des données). Mais si un fournisseur affirme “tarification dynamique en temps réel et optimisation de stocks”, il faut se demander : entendent-ils par là que le système se recalcule en continu, ou simplement qu’il peut réagir rapidement lorsqu’il est déclenché ? Et avez-vous réellement besoin du temps réel pour les décisions d’assortiment ? Probablement pas – cela relève davantage de la stratégie. Ainsi, une oreille critique percevra quand le langage marketing est incohérent. Le marketing étendu de Blue Yonder tombe parfois dans le piège de promettre tout (de la stratégie à long terme à l’exécution instantanée). Il est judicieux de délimiter quelles fonctions sont véritablement en temps réel (par exemple, leur routage de transport pourrait réagir à une commande en quelques minutes) par rapport à celles qui sont intrinsèquement groupées (comme la planification d’assortiment qui est saisonnière).

Problème de coût avec Snowflake: Il convient de souligner un point subtil mais important : le fait que Blue Yonder se base sur Snowflake pourrait modifier le modèle de coût pour les clients. Au lieu des licences traditionnelles, les clients pourraient finir par payer pour l’utilisation du cloud (crédits Snowflake) en fonction du volume de données et de la fréquence des requêtes. Si les applications de Blue Yonder effectuent des traitements intensifs sur Snowflake, la facture Snowflake du client pourrait grimper fortement. Cela est analogue à l’ancienne facturation des mainframes IBM par MIPS – vous payez davantage selon votre utilisation, ce qui peut dissuader d’exploiter pleinement le système. Blue Yonder et Snowflake ont vraisemblablement défini certains tarifs, mais l’utilisateur doit se méfier du “bill shock” si les scénarios de planification s’exécutent très fréquemment sur de grandes quantités de données. C’est une considération bien réelle, car la planification de la supply chain peut être gourmande en calcul (surtout lorsqu’il s’agit de simulations de scénarios ou de calculs probabilistes). Un processus inefficace sur Snowflake pourrait consommer beaucoup de crédits. Blue Yonder a sans doute pris cela en compte (ils doivent en faire un modèle commercial viable), mais c’est un point à surveiller. Un modèle de coût mal aligné avec la valeur commerciale (comme facturer en fonction des données traitées plutôt que sur le résultat) rappelle les écueils des époques précédentes.

En conclusion, Blue Yonder se positionne juste en dessous des solutions pure-play plus récentes en termes de réalisation de la vision « next-gen ». Il possède indéniablement une fonctionnalité riche et de nombreux déploiements réussis, mais d’un point de vue technique sceptique, nous constatons une entreprise en transition. Ils tentent de se moderniser et, ce faisant, ils parlent avec conviction de l’IA, de l’intégration et de l’automatisation. Pourtant, tant que cette transformation ne sera pas pleinement concrétisée, les clients devraient rester prudents quant aux écarts entre les modules et à l’effort réel requis pour obtenir les résultats promis. La panoplie d’outils de Blue Yonder peut certainement supporter les opérations eCommerce (de nombreux grands détaillants ayant une activité omnicanal utilisent également BY pour leur volet e‑com), et son étendue est inégalée (aucun des autres fournisseurs n’a une portée aussi large, y compris des aspects tels que la logistique). Cependant, si une entreprise eCommerce n’a besoin que d’optimiser la demande et le supply, Blue Yonder pourrait être trop lourd à moins qu’elle n’ait spécifiquement besoin de cette robustesse d’entreprise ou qu’elle l’utilise déjà dans d’autres domaines. Notre étude sceptique trouve les affirmations de Blue Yonder en matière de technologie de pointe quelque peu louches jusqu’à preuve du contraire – la technologie a du pedigree, mais il leur incombe de démontrer que ce logiciel vieux de plusieurs décennies est réellement devenu “AI-first” et unifié. À l’heure actuelle, nous conseillons de considérer Blue Yonder comme une option puissante mais lourde, que l’on choisit si l’on a besoin d’une solution très complète et dispose des ressources pour l’implémenter, et peut-être pas comme premier choix si l’agilité et un ROI rapide sont primordiaux.

4. ToolsGroup – Pionnier de l’optimisation de stocks s’étendant au retail complet

ToolsGroup est un vétéran dans le domaine de la planification de la supply chain, connu particulièrement pour son expertise en prévision de la demande et optimisation de stocks. Sa solution phare, historiquement appelée SO99+ (Service Optimizer 99+), était largement utilisée pour la planification de stocks orientée taux de service et l’optimisation multi-niveaux. En termes simples, ToolsGroup excellait à aider les entreprises à déterminer « quel est le stock minimum nécessaire à chaque site pour atteindre un taux de service donné ? » en situation d’incertitude – un problème crucial tant pour la distribution que pour l’eCommerce. ToolsGroup fut parmi les premiers à mettre en œuvre commercialement la prévision probabiliste, et il prônait depuis longtemps l’abandon des prévisions déterministes au profit de l’utilisation de la distribution complète de la demande ⁴³ ². Cette approche est parfaitement alignée avec ce que nous considérons comme étant à la pointe de la technologie aujourd’hui (et qu’ont adopté par la suite d’autres fournisseurs).

Dans un contexte eCommerce, la force de ToolsGroup signifie qu’il peut gérer un grand nombre de SKU avec une demande erratique, tout en produisant des objectifs de stocks optimaux. De nombreux e‑tailers disposent d’articles « longue traîne » qui se vendent rarement – les modèles probabilistes de ToolsGroup sont naturellement adaptés pour planifier ces articles (en capturant le caractère sporadique de la demande plutôt qu’en la moyennant de façon inappropriée). Ils gèrent aussi les lancements de nouveaux produits, la saisonnalité et les promotions via leurs modèles de prévision qui intègrent machine learning. Par exemple, ils pourraient utiliser des analogies (trouver l’historique d’un article similaire) ou une modélisation basée sur les attributs pour prévoir un nouveau SKU.

Bien que ToolsGroup se soit historiquement concentré sur les stocks et la demande, ces dernières années, il a reconnu que la tarification, les promotions et l’assortiment sont des éléments complémentaires qu’il n’offrait pas. Pour y remédier, ToolsGroup a acquis une entreprise nommée JustEnough en 2018/2019 (JustEnough fut par la suite intégré à Mi9 Retail avant d’être vendu à ToolsGroup). Le logiciel de JustEnough couvrait la planification financière des marchandises, la planification d’assortiment, l’allocation et l’optimisation des déstockages – en d’autres termes, les fonctions de marchandisage retail incluant les déstockages tarifaires. Grâce à cette acquisition, ToolsGroup a élargi son empreinte, passant d’une approche purement supply chain à ce que l’on pourrait appeler la planification retail. Ils commercialisent désormais une suite intégrée capable de tout couvrir, de la planification stratégique à l’exécution, grâce à la combinaison des capacités de SO99+ et de JustEnough.

Cependant, l’intégration de ces produits est un point clé de scepticisme. Fusionner deux plateformes logicielles différentes n’est pas une mince affaire. ToolsGroup a travaillé à intégrer des modèles de données (ils évoquent avoir « le même modèle de données pour la planification tactique et opérationnelle » pour garantir une seule version de la vérité ⁴⁴). Ils ont même lancé quelque chose baptisé “Real-Time Retail” qui connecte le système de planification de JustEnough à un Inventory Hub pour obtenir des flux de données presque en temps réel ⁴⁵ ⁴⁶. L’idée est que, à mesure que les ventes se réalisent (ou que les stocks se déplacent), ces événements s’intègrent instantanément dans le système de planification, qui peut alors re-planifier l’allocation ou le réapprovisionnement à la volée. Cela suggère que ToolsGroup tente de permettre une planification plus dynamique et continue plutôt que des cycles périodiques fixes – un objectif similaire à celui d’autres fournisseurs modernes.

Mais décomposons cela : le fait que ToolsGroup appelle sa solution “Real-Time Retail, the only solution that responds to shopping behavior in the moment” ⁴⁵ est une affirmation forte. Cela implique essentiellement qu’ils peuvent ajuster le plan dès qu’un changement survient. Peut-être que le système peut déclencher automatiquement un transfert de stock ou accélérer une commande si les ventes explosent de manière inattendue aujourd’hui. Si c’est vrai, c’est puissant – cela brouille la frontière entre la planification et l’exécution. Cependant, la position sceptique est que « real-time » est probablement limitée à certaines fonctions (comme la réaffectation de stocks, qui est plus facile à réaliser rapidement) et non à d’autres (comme la ré-optimisation complète d’un assortiment, ce que l’on ne ferait pas en temps réel). Il convient également de noter que tous les fournisseurs utilisent désormais « real-time » dans leur marketing (signifiant souvent un rafraîchissement toutes les quelques minutes voire chaque heure, ce qui est acceptable). La PDG de ToolsGroup a elle-même noté que les détaillants doivent pivoter rapidement pour éviter l’érosion des marges lorsque la demande évolue ⁴⁷, ce qui est vrai. Le système recalculerait et recommanderait automatiquement des commandes ou des transferts dès l’arrivée de nouvelles informations ⁴⁸.

À supposer que ToolsGroup ait efficacement intégré JustEnough, un utilisateur de leur système pourrait, par exemple, planifier un assortiment par magasin ou canal en utilisant le module JustEnough, puis faire en sorte que cela alimente les cibles de stocks dans SO99+, et également planifier la tarification markdown pour les produits en fin de vie en utilisant leur optimisation. Cela couvre les aspects d’optimisation conjointe – surtout si les prévisions de demande et les paramètres de stocks tiennent compte du calendrier des remises prévu. Il s’agit probablement encore d’un processus séquentiel (d’abord décider des remises, puis observer le résultat sur les stocks) à moins qu’ils n’aient construit un modèle d’optimisation combinée (ce qui est peu probable à une telle échelle). Mais c’est une solution unifiée en termes de flux de données.

Où ToolsGroup répond clairement aux critères de pointe, c’est dans la prévision probabiliste et l’optimisation du taux de service. Ils n’ont cessé d’affirmer pendant des années que des prévisions à valeur unique sont insuffisantes et qu’il faut planifier avec des probabilités. Par exemple, ils produiront non seulement « expected demand = 100 » mais aussi une courbe montrant qu’il y a 10 % de chances que la demande dépasse 120, etc. Leur optimisation utilise ensuite ces données pour décider des niveaux de stocks de sorte qu’environ 95 % du temps, la demande puisse être satisfaite ⁴⁹ ⁵⁰. Cette approche gère intrinsèquement l’incertitude et même la cannibalisation dans une certaine mesure (surtout si vous utilisez leur modélisation pour des articles corrélés). Un aspect intéressant : ToolsGroup présentait souvent que l’utilisation de la prévision probabiliste pouvait prolonger la durée de vie des systèmes ERP de planification hérités (comme SAP APO) en leur fournissant de meilleures informations ¹ ⁵¹. Cela souligne que le différenciateur principal de ToolsGroup résidait dans la mathématique de la prévision et des stocks plutôt que dans une interface de planification tout-en-un.

Maintenant, qu’en est-il de l’automatisation et de la facilité d’utilisation ? Selon certains utilisateurs, ToolsGroup était traditionnellement davantage un « moteur back-end » avec une interface utilisateur quelque peu maladroite. Ils ont depuis amélioré l’interface (nouvelle UI web, etc.). Mais, plus important encore, ils mettent l’accent sur l’automatisation dans la planification. Leurs supports affirment, par exemple, “built-in automation cuts the planning workload by up to 90%” ⁵². Ils citent également souvent des clients obtenant « 40-90% reduced planner workload » et « 20-30% inventory reduction » après avoir utilisé ToolsGroup ⁵³ ⁵⁴. Ce sont de gros chiffres. L’affirmation concernant la réduction des stocks est plausible si une entreprise était très inefficace auparavant ou détenait des buffers excessifs par manque de confiance dans les prévisions. La réduction de la charge de travail des planificateurs implique que le système fait beaucoup plus d’automatisation. Cela correspond à nos attentes : un système probabiliste devrait réduire le travail de gestion des imprévus (puisque vous planifiez l’incertitude, il y a moins de surprises, de sorte que les planificateurs n’ont pas à accélérer autant ou à réaffecter manuellement les stocks à la dernière minute). Cependant, un sceptique noterait qu’une réduction de 90% de la charge de travail est probablement le scénario extrême (peut-être un cas où une entreprise est passée de 10 planificateurs à 1 après l’implémentation – possible mais pas typique). Et 20-30% de stocks en moins pourrait résulter du fait qu’initialement l’entreprise détenait beaucoup trop de stocks « au cas où ». En supply chain, une fois l’optimisation faite, on observe souvent des réductions de l’ordre de 10-15% si les choses étaient modérément correctes auparavant. Nous soupçonnons donc que les fourchettes annoncées par ToolsGroup ⁵³ représentent des scénarios optimaux. Il est instructif qu’ils les présentent sous forme de fourchettes – cela implique que les résultats varient largement selon les clients.

Un point en faveur de ToolsGroup est la stabilité et la spécialisation. Ils optimisent la supply chain depuis 30 ans (fondé en 1993). Ils ne sont pas aussi grands que Blue Yonder ni aussi à la mode que RELEX, mais ils disposent d’une base de clients fidèles et d’une expertise approfondie dans le domaine. Pour une entreprise de le e-commerce principalement préoccupée par la rentabilité des stocks – c’est-à-dire, ne pas avoir trop de ruptures de stock ou de surstocks – la solution de ToolsGroup est très mature. Leur optimisation multi-échelons pourrait particulièrement bénéficier aux e-tailers disposant de plusieurs centres de distribution ou stockant également dans des entrepôts 3PL, etc. Elle permettra de pousser les stocks là où ils sont le plus nécessaires tout en maintenant des buffers centraux réduits.

Cependant, le point faible de ToolsGroup était l’optimisation des prix. L’acquisition de JustEnough leur a apporté l’optimisation des markdowns (la détermination des calendriers de remise pour les liquidations). Cela est utile pour le e-commerce avec des produits saisonniers ou de mode. Mais ils manquent encore d’une véritable optimisation de dynamic pricing qui se rapproche de ce que proposent Revionics/Blue Yonder ou certains fournisseurs spécialisés en tarification. L’optimisation des markdowns concerne les prix en fin de vie ou promotionnels. L’optimisation régulière des prix au quotidien (pour la marge ou le positionnement concurrentiel) n’est pas un point fort reconnu de ToolsGroup. Ils pourraient disposer de capacités de base ou s’appuyer sur des partenaires. Cela signifie que si l’optimisation conjointe des prix et des stocks est une priorité, ToolsGroup pourrait ne pas être aussi performant que Blue Yonder ou RELEX qui disposent de moteurs de tarification dédiés. ToolsGroup pourrait tout de même optimiser les stocks en supposant un prix donné, mais il ne vous indiquera pas le meilleur prix à fixer pour maximiser le profit (à part pour les scénarios de liquidation en fin de vie). C’est une distinction importante : leur “optimization” est principalement axée sur l’offre (niveaux de stocks, réapprovisionnement) plutôt que sur le façonnement de la demande (tarification, promotion) – malgré l’ajout de certains outils de façonnement de la demande via acquisition.

En termes de technology stack, ToolsGroup propose désormais une option SaaS en cloud et positionne même certaines de ses offres sous des noms accrocheurs tels que “Inventory Hub” et “Fulfill.io”. Cela montre qu’ils tentent de se moderniser et peut-être de séduire un marché plus large, y compris des entreprises de le e-commerce de taille moyenne. Le moteur sous-jacent utilise toujours des méthodes statistiques avancées, et probablement du C++ ou similaire pour les calculs. Nous n’avons pas entendu dire que ToolsGroup rencontre des problèmes de performance ; ils possèdent des références de clients avec des millions de combinaisons SKU-location. Si l’on en croit, le talon d’Achille de ToolsGroup pourrait être qu’il est considéré comme un « outil d’optimisation » – puissant mais nécessitant une configuration par des experts. Ils ont tenté de simplifier avec davantage de ML prêt à l’emploi. Par exemple, ils intègrent le demand sensing (utilisation des tendances à court terme pour ajuster les prévisions) et affirment utiliser le machine learning pour identifier quels facteurs influencent le plus la demande ⁵⁵. Ils ont également démystifié dans leur blog l’idée que les prévisions probabilistes ne pouvaient pas être ajustées par des humains – précisant qu’il est possible d’intégrer le jugement, mais que les mathématiques tiendront compte historiquement des biais ⁵⁶. Cela reflète une approche équilibrée : ils ne suppriment pas totalement l’humain, mais guident l’humain avec de meilleures informations.

Effets de cannibalisation : Le modèle probabiliste de ToolsGroup peut, s’il est configuré, capturer la cannibalisation (par exemple, si vous saisissez une relation de substitution, il peut modéliser des scénarios où, si un article est en rupture, une partie de la demande se détourne vers un autre). Cependant, cela nécessite probablement un effort pour établir les relations ou utiliser leur ML pour regrouper les articles. Il n’est pas clair dans quelle mesure cela est automatique. Mais ToolsGroup a mis l’accent sur la gestion de “long tail, intermittent demand, and more channels” dans un blog de 2017, indiquant essentiellement que ces conditions font échouer les outils traditionnels et requièrent des méthodes probabilistes ⁵⁷. Ils mentionnent spécifiquement “more channels to market, with aggregated demand coming from multiple streams” comme un scénario où les prévisions à valeur unique échouent, suggérant que leur solution gère mieux le multicanal ⁵⁷. Ainsi, un e-tailer vendant sur son site web et sur Amazon, par exemple, pourrait utiliser ToolsGroup pour planifier une demande combinée. L’outil produirait une prévision totale et permettrait peut-être d’allouer les stocks par canal de manière optimale (bien que l’allocation par canal soit souvent plus simple lorsque tout est expédié depuis les mêmes centres de distribution, mais dans le cas de pools de stocks séparés, cela importe).

Un aspect à surveiller avec ToolsGroup (comme avec tout fournisseur de suite acquis) est la cohérence de l’expérience utilisateur. Est-ce que les modules de prévision, de stocks et d’assortiment se trouvent désormais dans une seule UI, ou donne-t-il l’impression de devoir passer d’un système à l’autre ? Ils ont travaillé à unifier l’interface, mais des retours des utilisateurs seraient nécessaires. Ce n’est pas aussi unifié que la plateforme unique développée en interne par RELEX, vraisemblablement.

En termes de palmarès, ToolsGroup présente de nombreuses études de cas réussies, mettant souvent en avant la réduction des stocks et l’amélioration du taux de service. Ils n’ont pas connu de fiasco majeur publié, comme cela a pu être le cas pour SAP ou JDA. Ils sont plus petits, de sorte que chaque projet peut bénéficier d’une attention accrue. Cela dit, parce qu’ils vendaient souvent à des entreprises de fabrication/distribution, certains acteurs du retail/le e-commerce ne les connaissent pas aussi bien. Leur incursion dans le retail via JustEnough signifie que certains anciens clients de JustEnough utilisent désormais ToolsGroup. JustEnough lui-même avait des avis mitigés (il était correct en matière de planification mais peut-être limité en termes de scalability – ce qui reste flou). Ainsi, ToolsGroup a dû renforcer ces modules. En tant que sceptiques, nous conseillons de vérifier à quel point les analyses sont réellement intégrées. Par exemple, le système peut-il reconnaître automatiquement qu’une promotion planifiée dans le module JustEnough doit ajuster la prévision de demande dans SO99+ ? Probablement oui, ils auraient intégré des rehaussements promotionnels. Ils mentionnent “demand sensing insights help fine-tune the statistical forecast” ⁵⁸ ce qui implique qu’ils prennent en compte des éléments tels que les promotions ou les tendances récentes pour ajuster les prévisions de base.

Pour résumer l’évaluation de ToolsGroup : Il est très fort dans sa niche d’origine (prévision et stocks) – sans doute le meilleur de sa catégorie en optimisation probabiliste des stocks – et il s’élargit pour couvrir la tarification et l’assortiment, bien que ces nouvelles capacités ne rivalisent peut-être pas encore avec des concurrents spécialisés. ToolsGroup répond à bon nombre de nos critères de pointe :

Prévisions probabilistes ? Oui, ils en sont les champions ⁴⁹ ⁴³.
Optimisation économique ? Implicitement oui pour les stocks (ils optimisent en fonction du compromis entre service et coût), bien que ce ne soit pas explicite sur le profit comme le fait Lokad. Il s’agit davantage de « atteindre le taux de service cible avec un minimum de stocks », ce qui est une forme d’optimisation des coûts.
Scalabilité ? Généralement oui, sans signaux d’alarme. Et leur approche est efficace (pas une force brute).
Cannibalisation ? Peut-être, via une modélisation avancée, mais ce n’est pas leur principal argument de vente.
Marché/concurrentiel ? Pas intrinsèquement – cela se gère en externe ou via des données d’entrée. ToolsGroup ne va pas analyser les prix des concurrents pour vous ou autre.
Automatisation ? Oui, élevée. Une fois configuré, de nombreuses tâches de planification peuvent être automatisées, le système émettant des propositions de commande que les planificateurs n’ont plus qu’à approuver. Ils vantent d’importantes réductions de charge de travail et moins de biais humains.
Scepticisme envers les affirmations du fournisseur : Le marketing de ToolsGroup est en réalité assez modéré comparé à celui d’autres, mis à part ces statistiques d’amélioration que nous avons déjà prises avec précaution. Ils se concentrent sur ce que la technologie fait (leurs blogs sur la planification probabiliste sont substantiels, et non du simple blabla). Mais ils se laissent désormais emporter par le battage médiatique autour de l’IA, qualifiant tout de « AI-powered ». Nous remarquons cependant qu’ils gardent un pied dans la recherche opérationnelle traditionnelle (OR) et un autre dans le ML, ce qui constitue un mélange sain.

Un point de donnée externe : Les analyses d’entreprises telles que Gartner placent souvent ToolsGroup en position de leader en matière de Supply Chain Planning, mais ils pourraient commenter que la capacité de ToolsGroup est plus profonde que large, et que l’UI était historiquement moins moderne. Cela est partiellement résolu à présent (nouvelle UI, intégration).

Pour un pure player du e-commerce, la décision de choisir ToolsGroup dépendrait probablement de si l’optimisation des stocks est le principal point de douleur et de s’ils ont besoin d’une solution éprouvée et quelque peu autonome pour cela. Si c’est le cas, ToolsGroup pourrait être un excellent choix, offrant des succès rapides en réduction de stocks et en amélioration du taux de service. Cependant, si l’entreprise de le e-commerce cherche également à optimiser fortement la tarification ou à mettre en œuvre des stratégies de markdown omnicanal de pointe, ToolsGroup pourrait ne pas être aussi riche en fonctionnalités que Blue Yonder, RELEX ou un outil de tarification dédié. Cela pourrait nécessiter de s’associer à une autre solution de tarification, ce qui entraînerait alors des défis d’intégration. (Fait intéressant, ToolsGroup pourrait ne pas s’y opposer – ils coexistaient historiquement parfois avec d’autres, se concentrant sur les stocks tandis qu’un autre système gérait la tarification.)

En conclusion, ToolsGroup se classe comme un fournisseur solide sur le plan technique, spécialisé devenu fournisseur de suite. Nous apprécions sa rigueur d’ingénierie en matière de prévision et son approche sans compromis face à l’incertitude (ils ont depuis longtemps réfuté l’idée selon laquelle « forecast is always wrong » en planifiant avec des probabilités). Nous restons prudents quant à l’expansion récente : à savoir si leurs modules retail nouvellement intégrés fonctionnent au même niveau que leur cœur de métier. La contradiction interne que nous observons est leur affirmation d’être désormais pleinement intégrés – si des fissures apparaissent (comme des données nécessitant une exportation/importation manuelle entre les modules), cela minerait leur argumentaire. Mais d’après les informations disponibles, ToolsGroup semble offrir une expérience plus unifiée après JustEnough. Ils s’alignent même sur la tendance de l’utilisation de données en temps réel dans la planification, ce qui est à saluer.

Enfin, comme nous l’avons fait avec d’autres : l’examen des affirmations des fournisseurs pour ToolsGroup. Lorsqu’ils disent, par exemple, “90+% product availability, 20-30% less stocks, 40-90% reduced workload” ⁵³ ⁵⁴ – un scepticisme sain consiste à considérer ces résultats comme réalisables mais non garantis. Ces chiffres proviennent probablement de différents clients atteignant chacun l’un de ces sommets, et non d’un seul client atteignant tous ces résultats simultanément. Personne ne devrait s’attendre à ce que ses stocks chutent de 30% alors que le taux de service monte à >90% et que le nombre de planificateurs soit réduit de 90% en même temps. La réalité implique généralement des compromis et une amélioration progressive. La méthodologie de ToolsGroup peut absolument engendrer une amélioration significative, mais nous conseillons de fixer des objectifs réalistes et de mesurer au fur et à mesure. La bonne nouvelle est que l’accent mis par ToolsGroup sur des résultats mesurables (taux de service, $$ de stocks) correspond à une approche fondée sur la recherche de la vérité – il est très clair, en observant ces indicateurs, si cela fonctionne ou non.

Percer le battage médiatique : Leçons et recommandations

Chez ces fournisseurs, quelques thèmes communs du battage médiatique par rapport à la réalité ont émergé, que tout décideur en e-commerce devrait garder à l’esprit:

Méfiez-vous des mots à la mode : Des termes tels que “AI-driven, cognitive, demand sensing, real-time, autonomous” sont utilisés à tort et à travers. Assurez-vous qu’ils reposent sur des capacités concrètes. Par exemple, “demand sensing” sonne souvent bien – utiliser les ventes d’hier ou les discussions sur les réseaux sociaux pour ajuster la prévision d’aujourd’hui – mais en pratique, cela ne fait qu’ajuster légèrement les chiffres et constitue essentiellement une prévision à court terme. Les experts de l’industrie ont qualifié le demand sensing de possiblement “mootware” – quelque chose qui existe mais n’apporte pas de valeur tangible au-delà de ce que fournit déjà une bonne prévision ⁵⁹. N’achetez pas les concepts de “vaporware” sans preuves. Demandez au fournisseur : qu’est-ce que votre IA fait exactement que mon processus actuel ne peut pas, et pouvez-vous le prouver ? S’ils disent “we consider 300 factors”, contestez-les en leur demandant si ces facteurs font vraiment bouger les choses ou s’ils ne servent qu’à embellir une présentation.
Base de référence et repères : Établissez toujours une base de référence claire (ex : les rotations de stocks de l’année précédente, le taux de réalisation, la marge brute) et vérifiez si le fournisseur accepte de mesurer l’amélioration par rapport à ces indicateurs. Beaucoup avancent des améliorations en pourcentage qui semblent énormes mais sont dénuées de sens sans contexte. Cherchez également toute participation à des repères externes (comme des compétitions de prévision ou des études de cas publiques avec des chiffres concrets). La compétition M5 fut l’un de ces repères qui a séparé le bon grain de l’ivraie en matière de prévision – notamment, aucun des grands fournisseurs traditionnels n’y a publié de résultats, alors qu’un petit acteur (Lokad) l’a fait et excelle ⁶⁰. Cela vous indique qui a confiance en sa technologie.
Complexité d’intégration : Si un fournisseur s’est développé par acquisitions (Blue Yonder, ToolsGroup), méfiez-vous des promesses selon lesquelles “it’s all one platform now”. Souvent, il faut des années pour une véritable intégration. Pendant ce temps, vous pourriez effectivement utiliser des systèmes séparés reliés par quelques interfaces. Des coûts cachés peuvent apparaître lors de la mise en œuvre pour interconnecter ces systèmes. De plus, deux composants acquis pourraient ne pas partager la même conception de certaines données (par exemple, l’un utilise des intervalles hebdomadaires, l’autre quotidiens, ou des définitions différentes de la hiérarchie des produits). Cela peut conduire à des compromis ou à un désalignement. Il est judicieux de discuter avec des clients de référence de leur expérience en intégrant ces modules.
Structure des coûts : Évaluez non seulement les coûts de licence/abonnement du logiciel, mais aussi les coûts d’exécution (le cas échéant) et l’infrastructure requise. Comme mentionné, une solution reposant sur quelque chose comme Snowflake pourrait vous répercuter ces coûts d’exécution cloud. Ou une solution nécessitant une très forte utilisation de la mémoire pourrait vous obliger à opter pour des instances cloud haut de gamme. Un fournisseur pourrait proposer des frais d’abonnement plus élevés en incluant toute la computation; un autre pourrait être moins cher, mais vous faire supporter une grosse facture AWS/Azure pour la puissance de calcul nécessaire. Assurez-vous de comparer le coût total de possession. Nous avons notamment évoqué comment le modèle de Snowflake pourrait rappeler les écueils des mainframes IBM – gardez un œil sur les frais basés sur l’utilisation et exigez de la transparence de la part des fournisseurs utilisant ce modèle.
Chaque fournisseur a ses échecs : Il est important de se rappeler que aucun fournisseur ne mettra en avant ses projets ratés, pourtant ils en ont tous. La mise en œuvre est aussi cruciale que l’outil. Nous avons vu comment même des leaders comme SAP ou i2 (désormais sous Blue Yonder) ont connu des échecs multimillionnaires ³⁹ ³³. Souvent, les raisons sont de mauvaises données, des attentes mal alignées ou le fait que l’entreprise n’adopte pas les sorties du système. Lors de l’évaluation, demandez aux fournisseurs comment ils traitent les projets qui n’atteignent pas leurs objectifs. Ont-ils des exemples (anonymisés) de leçons tirées ? Blue Yonder a fait preuve d’une certaine humilité en reconnaissant les causes communes d’échec ²⁶. Un fournisseur qui affirme “we have a 100% success rate” n’est pas réaliste. Insistez pour discuter de ce qui pourrait mal tourner et comment ils le compensent.
Contradictions entre réactivité en temps réel et profondeur analytique : Comme mentionné, certaines analyses (comme la planification de l’assortiment à l’échelle du réseau) ne peuvent pas être véritablement en temps réel – elles nécessitent un important traitement des données et une réflexion stratégique. Si un fournisseur affirme à la fois une “real-time responsiveness” et une “holistic optimization”, vous devez discerner quelles parties de leur solution correspondent à quelle promesse. Par exemple, ToolsGroup peut mettre à jour les positions de stocks en temps réel, mais son optimisation principale peut s’exécuter quotidiennement. RELEX peut ingérer des données en quasi temps réel, mais la planification de certains aspects (comme l’optimisation des prix basée sur l’IA) peut toujours se faire par lots pendant la nuit. Comprenez le rythme de chaque composant de la solution par rapport aux besoins de votre entreprise. Le temps réel est crucial pour l’exécution (comme la mise à jour des stocks disponibles à la promesse ou la tarification dynamique instantanée), mais pour les décisions stratégiques, la profondeur et la rigueur priment sur la rapidité.
Intervention humaine vs autonomie : Tous les fournisseurs prétendent offrir un certain niveau d’autonomie, tout en permettant une intervention humaine. C’est un spectre. La question clé est la suivante : le système opère-t-il par défaut en mode non surveillé, ne signalant que les exceptions, ou nécessite-t-il par défaut une révision par l’utilisateur pour chaque décision ? Pour obtenir de véritables gains d’efficacité, vous voudrez le premier cas. Un signal d’alarme apparaît si le fournisseur insiste sur le nombre de leviers et d’options de configuration dont dispose l’utilisateur – cela peut indiquer que l’outil requiert une surveillance importante pour obtenir de bons résultats (ce qui contredit la promesse d’automatisation). Idéalement, l’outil devrait s’auto-ajuster ces leviers (comme Blue Yonder qui élimine la nécessité de configurer manuellement les profils saisonniers grâce au ML ³⁶). Faites confiance, mais vérifiez : lors des démonstrations ou des essais, observez combien d’ajustements manuels ont été nécessaires pour obtenir des résultats convaincants.
Spécificités de l’IA/ML : Approfondissez les affirmations du fournisseur concernant son IA. Demandez : utilisent-ils le machine learning pour la prévision ? Quels algorithmes (s’ils peuvent le préciser) ? Utilisent-ils des bibliothèques open source (si tout est propriétaire, cela peut parfois indiquer qu’ils ne se tiennent pas au courant des dernières techniques ; toutes les solutions IA de premier plan intègrent des bibliothèques open source comme TensorFlow/PyTorch ou, à tout le moins, des algorithmes bien connus) ? Si un fournisseur se contente de brandir un “proprietary AI engine” sans pouvoir l’expliquer simplement, soyez sceptique. Inversement, s’il peut articuler, par exemple, “we use gradient boosting for baseline forecasts and a reinforcement learning model for pricing”, cela montre un investissement concret dans la technologie. Vérifiez également si son équipe a publié ou participé à des forums académiques ou industriels sur ses méthodes – c’est un signe de sérieux.

Enfin, nous soulignons l’importance d’un esprit en quête de vérité : insistez sur des données et des résultats d’essais plutôt que sur des promesses tape-à-l’œil. Si possible, réalisez un pilote ou une preuve de concept où chaque fournisseur se voit attribuer un sous-ensemble de vos données pour prévoir ou optimiser, et évaluez les résultats de manière quantitative. Par exemple, fournissez deux années d’historique et laissez-les prévoir la troisième année (pour laquelle vous disposez des valeurs réelles) – voyez qui se rapproche le plus ou qui identifie les schémas de demande complexes. Ou demandez-leur d’optimiser un scénario, puis simulez les résultats en termes de coût/taux de service en utilisant votre demande réelle pour validation. Peu de fournisseurs se proposent spontanément pour un bake-off, mais les bons le feront souvent parce qu’ils défendent leur science. Lokad, par exemple, s’engage souvent via des projets pilotes. Blue Yonder et RELEX réalisent parfois des phases de “discovery” qui ressemblent à des pilotes. Assurez-vous simplement de disposer de critères de réussite clairs pour ces projets.

En fin de compte, le marché des logiciels d’optimisation eCommerce ne manque pas de “miracles de l’IA” autoproclamés, mais en appliquant un scepticisme poussé et en exigeant des preuves techniques concrètes, on peut filtrer le superflu. Cette étude a révélé que Lokad est en tête en matière d’innovation technique et de focalisation, RELEX se distingue par une fonctionnalité unifiée pour le retail (avec un battage médiatique à surveiller), Blue Yonder par son ampleur et son expérience (dans un contexte de refonte technologique complexe), et ToolsGroup par ses points forts en optimisation spécialisée (avec une intégration en progression). Chacun peut offrir des avantages significatifs – mais aucun n’est une panacée plug-and-play. La vérité est que l’optimisation réussie découle du bon outil et de la bonne stratégie de mise en œuvre. Grâce aux enseignements et aux points de prudence présentés ci-dessus, une entreprise e-commerce peut aborder ces fournisseurs les yeux ouverts et faire un choix fondé sur des faits et un raisonnement solide, et non sur l’attrait du marketing.