Logiciel d'optimisation du e-commerce

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 de revendications audacieuses de magie pilotée par l’IA, mais un regard attentif sous le capot révèle que seuls quelques fournisseurs tiennent vraiment la promesse d’optimiser conjointement les stocks, les prix et les assortiments avec une technologie de pointe. Dans cette étude, nous évaluons les solutions de pointe pour le e-commerce pur (détaillants en ligne sans magasins physiques) et classons les fournisseurs les plus pertinents - y compris Lokad, RELEX Solutions, Blue Yonder et ToolsGroup - en fonction de leurs mérites techniques et de 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 tempérées par la complexité de l’IA en boîte noire et les bagages hérités, respectivement. ToolsGroup fournit une optimisation des stocks éprouvée basée sur des mathématiques solides mais fait face à des défis d’intégration alors qu’il se développe dans la tarification et l’assortiment. Tout au long, nous appliquons une lentille profondément sceptique : en coupant à travers le fluff marketing, en scrutant les revendications des fournisseurs contre des preuves indépendantes, et en soulignant les réserves souvent non dites (par exemple, l’échec à optimiser les décisions de manière holistique, ou la dépendance à des architectures coûteuses). L’objectif est une analyse technique axée sur le récit qui met la vérité au-dessus du battage publicitaire, afin que les acteurs du e-commerce puissent comprendre qui fait véritablement avancer l’état de l’art - et qui est à la traîne.

Les critères de référence : Optimisation conjointe & Technologie avancée

N’importe quel fournisseur peut se vanter de l’IA ou des big data, mais optimiser véritablement une entreprise de e-commerce nécessite de répondre à un niveau élevé de critères techniques et fonctionnels. Le plus important est l’optimisation conjointe : la capacité d’optimiser simultanément les niveaux de stocks, la tarification et les décisions d’assortiment de produits. Les traiter isolément - comme le font de nombreux systèmes plus anciens - est fondamentalement erroné, car ils sont étroitement interdépendants (la tarification affecte la demande qui affecte les stocks, les changements d’assortiment affectent les deux, etc.). Une solution d’optimisation du e-commerce doit coordonner les trois ; par exemple, elle pourrait décider de stocker moins d’un produit et de le réduire plus tôt si les prévisions révèlent des ventes lentes, ou d’augmenter les prix de certains articles pour éviter les ruptures de stock. Les solutions qui optimisent les stocks mais ignorent la tarification, ou vice versa, laissent de l’argent sur la table et sont sous-optimales par conception.

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

Prévision probabiliste : Plutôt que des prévisions de demande à un seul point, utilisez des distributions de probabilité pour capturer l’incertitude de la demande. C’est crucial pour le e-commerce avec ses modèles de demande volatils et sa “longue queue” de SKU. Les outils traditionnels (par exemple, les anciens modules SAP ou Oracle) qui produisent un nombre et un stock de sécurité jugent souvent mal la véritable variabilité ¹ ². Les principaux fournisseurs mettent désormais l’accent sur les modèles probabilistes ou “stochastiques” qui quantifient la gamme des résultats.
Optimisation économique : Les décisions devraient être guidées par des objectifs économiques (profit, coût, objectifs de taux de service) et non pas seulement par des règles heuristiques. Par exemple, un système véritablement optimisé prendra en compte les marges de profit et les coûts de détention des produits lors de la décision des niveaux de stocks et des prix. Il priorisera les actions qui maximisent le profit attendu ou minimisent le coût total, plutôt que d’atteindre aveuglément un taux de remplissage. Cela nécessite l’intégration de 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 des données à grande échelle sans coûts matériels exorbitants ou des performances lentes. Les architectures qui conservent naïvement tout en mémoire (RAM) peuvent devenir prohibitivement coûteuses à grande échelle. Les conceptions modernes utilisent judicieusement le cloud computing, par exemple le traitement distribué, les magasins de données basés sur disque et les algorithmes efficaces. Une solution qui nécessite une ferme de serveurs géante ou des plateformes coûteuses (comme une utilisation excessive du cloud de données de Snowflake) pourrait éroder le ROI. À l’inverse, une ingénierie astucieuse peut traiter des ensembles de données de l’ordre 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 tenir compte de l’impact des produits sur la demande des autres. Par exemple, si deux produits sont de proches substituts, l’élimination de l’un d’eux déplacera la demande vers l’autre (un effet de cannibalisation). Cela nécessite plus qu’une simple analyse OLAP ou des groupes de produits définis manuellement ; il faut des modèles qui apprennent 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 conduit à des erreurs à la fois dans la prévision et la planification de l’assortiment. Un fournisseur de pointe devrait explicitement modéliser de telles relations (par exemple, en utilisant l’apprentissage automatique sur les données de transaction pour déduire les affinités de produits).
Impacts du marché et de la concurrence : Les acteurs purs du e-commerce sont souvent influencés par les dynamiques du marché - par exemple, la concurrence sur Amazon ou eBay, les vendeurs tiers, etc. Le logiciel d’optimisation devrait idéalement incorporer des signaux tels que les prix des concurrents ou les ruptures de stock sur le marché. Peu le font bien. 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 votre prix ou vos dépenses publicitaires en conséquence. De même, si vous vendez à la fois en direct et sur des marchés, le système devrait optimiser les canaux (évitant, par exemple, de surstocker pour votre propre site lorsque le produit se vend via Amazon FBA).
Capacités multi-canal et omni-canal : Même sans magasins physiques, un marchand de e-commerce peut avoir plusieurs canaux en ligne (son propre site web, des marchés, peut-être des sites régionaux). Le moteur d’optimisation devrait gérer la demande et les stocks multi-canaux de manière holistique - reconnaissant, par exemple, que les stocks sont partagés ou que les décisions de tarification sur un canal pourraient affecter un autre. La planification “de bout en bout” n’est pas qu’un buzzword ; cela signifie que le logiciel voit l’ensemble du tableau (des fournisseurs aux clients, à travers tous les flux de ventes).
Haut degré d’automatisation (“robotisation”) : La promesse ultime de ces systèmes est la prise de décision autonome. Ils devraient théoriquement être capables de fonctionner sans surveillance, produisant des commandes de réapprovisionnement, des mises à jour de prix, etc., sans que les utilisateurs aient à tourner les boutons tous les jours. En réalité, tous les fournisseurs permettent encore la configuration par l’utilisateur, mais nous favorisons ceux qui minimisent le besoin d’ajustement humain. Méfiez-vous des solutions qui se vantent d’automatisation mais exposent des dizaines de boutons (paramètres, facteurs de pondération, règles) - c’est une contradiction interne. La véritable automatisation vient du fait de laisser les algorithmes trouver les réglages optimaux, et non de demander aux utilisateurs de recalibrer constamment. Les meilleurs systèmes utilisent des techniques comme les modèles auto-apprenants qui s’ajustent à mesure que de nouvelles données arrivent, de sorte qu’avec le temps, les décisions restent optimales sans intervention manuelle ⁵. Plus il y a de réglages “pilotes” qu’un utilisateur doit maintenir, plus l’automatisation est crédible.
Architecture robuste et rentable : Nous avons abordé l’efficacité coût, mais il vaut la peine de le noter explicitement : certaines solutions modernes ont adopté des entrepôts de données cloud (comme Snowflake) pour passer à l’échelle. Cela peut supprimer les maux de tête d’infrastructure, mais cela introduit un modèle de coût basé sur l’utilisation. Si un outil de planification nécessite de traiter d’énormes données sur une plateforme comme Snowflake, les coûts peuvent grimper en flèche (à l’instar de la tarification basée sur les MIPS d’IBM dans les années 1990, où une utilisation plus importante du CPU signifiait des frais exponentiellement plus élevés). Une solution idéale gère les big data avec des algorithmes intelligents pour maintenir l’utilisation du cloud (et donc le coût) raisonnable ⁴. De même, les solutions construites par acquisitions pourraient finir par être un patchwork de modules sur différentes piles technologiques, entraînant des coûts d’intégration élevés pour le client (soit en argent, soit en latence du système). Être native du cloud et intégrée dès le départ est un avantage, mais seulement si l’architecture élimine vraiment les mouvements de données redondants sans introduire de nouveaux goulets d’étranglement.

Avec 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 ci-dessus. L’analyse est narrative - se concentrant sur la façon dont chaque fournisseur aborde le problème et où le scepticisme est justifié - plutôt qu’une liste de fonctionnalités. De manière importante, nous nous appuyons sur des preuves crédibles (et des citations directes) chaque fois que possible, évitant le piège courant de prendre les affirmations des fournisseurs pour argent comptant.

1. Lokad - Optimisation Quantitative Unifiée avec Infrastructure Probabiliste

Lokad se distingue comme un 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 comme un ensemble de modules (prévision, MRP, etc.) à ajuster, mais plutôt comme une plateforme programmatique où une logique d’optimisation unifiée est mise en œuvre pour chaque client. Cette approche, qu’ils appellent “la Supply Chain Quantitative”, peut nécessiter plus de science des données en amont, mais elle donne une solution adaptée à l’optimisation de toutes les décisions ensemble - stocks, tarification, réapprovisionnement, 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 prix fixer) en tenant compte de toutes les contraintes et des arbitrages économiques.

Au cœur de cette approche se trouve la prévision probabiliste. Lokad a été un pionnier 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. Dans la prestigieuse compétition de prévision M5 (2020), une équipe de Lokad s’est classée 6ème au niveau mondial sur 909 équipes ⁶ - une validation impressionnante de leur technologie étant donné que M5 se concentrait sur des données de détail granulaires (le genre de données auxquelles les entreprises de e-commerce sont confrontées). Notamment, M5 nécessitait des prévisions probabilistes (quantiles), 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 étaient parmi les meilleures, ce qui sous-tend toute optimisation des stocks et de la tarification. De plus, le PDG de l’entreprise a souligné qu’au-delà d’un certain point, les gains de précision de prévision offrent des rendements décroissants par rapport à une meilleure modélisation des décisions ⁷. En d’autres termes, Lokad insiste sur l’optimisation des décisions (quantités de commandes, allocations, etc.) en utilisant les prévisions probabilistes, plutôt que de poursuivre une petite amélioration de la précision des prévisions qui peut ne pas affecter matériellement les résultats. Cette perspective est rafraîchissante et importante pour le e-commerce : elle reconnaît que la gestion des ruptures de stock, de la demande intermittente et des effets de substitution est souvent plus importante qu’une petite amélioration en pourcentage d’une métrique de prévision ⁷.

Technologiquement, Lokad est à la pointe et très axé sur l’ingénierie. Ils ont construit leur propre pile technologique native du cloud (y compris un langage spécifique au domaine personnalisé appelé “Envision” pour écrire des scripts d’optimisation). Cette pile est conçue pour traiter de grandes 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 client (commandes, clics, etc.) en quelques heures pendant la nuit, pour produire les décisions du lendemain ⁸ ³. Pour ce faire, ils évitent de charger tout dans la RAM ; à la place, ils utilisent des fichiers mappés en mémoire et un stockage en colonnes sur disque, permettant à des ensembles de données plus grands que la mémoire d’une machine d’être gérés de manière transparente en débordant sur des SSD rapides ³ ⁹. Ils notent explicitement que Envision (leur moteur) supporte des ensembles de données plus grands que la mémoire de l’ensemble du cluster en “débordant intelligemment sur les disques NVMe”, et que les opérations parallèles embarrassantes sont automatiquement distribuées sur les cœurs/machines ³. L’effet net : Lokad peut passer à des assortiments de SKU extrêmement grands sans nécessiter que le client investisse dans des quantités absurdes de RAM ou des appareils spécialisés. En fait, ils insistent sur le fait qu’ils nécessitent peu de matériel pour fonctionner - évitant des situations où “cliquer sur un bouton de démarrage coûte des centaines de dollars” en frais de cloud ⁴. C’est un point subtil mais crucial : cela les différencie de certains systèmes d’entreprise lourds qui pourraient techniquement gérer de grandes données, mais à un coût élevé. L’approche de Lokad est plus proche d’un pipeline de big data optimisé, à l’image d’un Apache Spark ou d’un Google BigQuery, mais spécialement conçu pour les calculs de supply chain. Cette focalisation sur l’efficacité rend la solution rentable à mesure qu’elle évolue - un gros plus pour les e-commerçants avec des millions d’enregistrements.

La gestion des prix et de l’assortiment par Lokad ne se fait pas via des modules séparés mais via la même logique d’optimisation. Comme la plateforme est essentiellement pilotée par code, on peut modéliser les interactions. Par exemple, on peut écrire un script qui dit : “pour chaque produit, considérez la demande probabiliste à différents niveaux de prix, tenez compte de la disponibilité des stocks et du délai de réapprovisionnement, puis choisissez le prix qui maximise la marge attendue moins le coût de détention, sous réserve de ne pas être en rupture de stock trop souvent” - c’est une description simplifiée, mais elle illustre que le prix et les stocks peuvent être décidés ensemble. Si un produit est surstocké, le code pourrait décider d’une remise pour accélérer les ventes ; s’il est rare, il pourrait augmenter le prix pour allouer les stocks aux clients les plus payants. Peu d’autres fournisseurs permettent ce niveau d’interaction. La solution de Lokad génère essentiellement ses propres politiques de décision adaptées aux données du commerçant.

Les effets de cannibalisation et de substitution sont gérés naturellement si vous fournissez les bonnes données. Par exemple, on peut incorporer une entrée de “si l’article A n’est pas disponible, combien de sa demande se reporte sur l’article B” - de telles relations peuvent être apprises à partir de données historiques (en analysant les ruptures de stock passées ou les changements d’assortiment) et ensuite intégrées dans l’optimisation. Comme Envision est un langage de programmation complet, ces dynamiques de demande complexes peuvent être codées. La littérature de Lokad indique qu’ils le font activement : le système “découvre des corrélations entre les produits, les canaux et les périodes de temps” et prend des décisions en conséquence, plutôt que de supposer que chaque SKU est indépendant ¹⁰. Il ne se repose 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 stock, des changements de saisonnalité, etc. ¹¹. En capturant ces facteurs (y compris lorsque la demande a été perdue en raison d’une rupture de stock), Lokad évite le classique problème des déchets dans la prévision sur des données de ventes biaisées.

Un autre domaine où Lokad brille est l’intelligence compétitive et l’intégration de données externes. La plateforme peut ingérer toutes les données pertinentes - par exemple, les prix des concurrents, le trafic web, voire les calendriers des campagnes marketing - comme signaux d’entrée supplémentaires. Ils mentionnent explicitement la capacité d’incorporer “des signaux externes tels que les prix des concurrents” et les calendriers marketing, et d’expérimenter facilement avec de nouveaux algorithmes ou entrées grâce à la conception programmatique ¹². Dans un sens pratique, si une entreprise de e-commerce a, disons, des données grattées sur les prix des concurrents ou sait qu’un niveau de stock d’un partenaire de marketplace est un indicateur, elle peut intégrer cela dans le modèle de Lokad pour affiner les décisions. C’est beaucoup plus flexible que la plupart des solutions clé en main qui ne gèrent peut-être que les données internes. Cela témoigne d’une approche de “boîte de verre” : plutôt que de cacher la logique, Lokad vous permet de l’adapter. Cela dit, l’approche de Lokad nécessite un Supply Chain Scientist pour la configurer - ce n’est pas une interface utilisateur point-and-click pour un novice. Cela pourrait être perçu comme un inconvénient pour certains ; cependant, la récompense est une solution qui correspond exactement à l’entreprise et qui peut vraiment automatiser les décisions en tenant compte des règles uniques de l’entreprise.

Automatisation et autonomie : Lokad est sans doute le plus proche d’un planificateur de supply chain “entièrement robotisé” dans ce groupe. La philosophie est qu’une fois que les scripts (logique) sont mis en place et validés, le système peut fonctionner quotidiennement (ou intra-journalier) et produire des décisions recommandées sans intervention humaine. De nombreux utilisateurs de Lokad font effectivement confiance au système pour produire des ordres d’achat et des suggestions de prix que les planificateurs examinent ensuite brièvement ou même exécutent automatiquement. Comme le système est auto-adaptatif (il réentraîne les prévisions chaque jour avec les dernières données et réoptimise en conséquence), il ne nécessite pas de réglage manuel des paramètres. En fait, Lokad critique plutôt pointilleusement l’habitude de l’industrie de l’ajustement sans fin - ils soulignent que leur système “ne repose pas sur des méthodes simplistes de séries temporelles” et fonctionne sans ajustement manuel constant de la part des utilisateurs ¹⁰. Le gros du travail d’ajustement pour la saisonnalité, les événements, la demande erratique est effectué par les algorithmes, et non par les planificateurs qui ajustent les prévisions. Un aspect clé est l’actionnabilité : Lokad produit 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 de “tour de contrôle”), il recommandera directement une quantité de commande ou un changement de prix pour y remédier. Il vise à “recommander des actions correctives plutôt que de simplement clignoter une alerte”, ce qui est crucial si vous voulez une opération non surveillée ¹³. Dans un environnement de e-commerce en rapide évolution, un système qui vous dit simplement qu’il y a un problème ne suffit pas - vous voulez qu’il vous dise quoi faire à ce sujet, ou même le faire. Lokad est conçu pour faire ce dernier.

Compte tenu de ces éloges, où faut-il être sceptique à propos de Lokad ? La principale mise en garde est que l’approche de Lokad est très personnalisée et technique. Ce n’est pas un SaaS plug-and-play où vous l’allumez et voyez immédiatement une belle interface utilisateur avec toutes les réponses. Il exige un certain niveau de maturité des données et de confiance dans les méthodes quantitatives de la part de l’entreprise utilisatrice. Il y a aussi une dépendance implicite à l’équipe de Lokad (“Supply Chain Scientists”) surtout lors de la mise en place initiale - en effet, ils agissent comme votre équipe étendue pour mettre en œuvre la solution. C’est un modèle différent de, disons, l’installation d’un logiciel bien défini. Si un client n’est pas prêt à s’engager dans ce processus collaboratif et axé sur l’ingénierie, il pourrait avoir des difficultés. Cependant, ce modèle est également ce qui permet la profondeur de l’optimisation. C’est un classique compromis : flexibilité et puissance vs. facilité d’utilisation. Lokad optimise clairement pour la puissance et la flexibilité.

D’un point de vue marketplace, la proposition de valeur de Lokad semble particulièrement alignée sur les besoins du e-commerce. Les entreprises de e-commerce jonglent avec de nombreux défis - ruptures de stock, surstocks, pics de demande volatils dus aux promotions ou aux coups de projecteur des influenceurs, etc. - et elles ont souvent recours à 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 la couche spécialisée qui prend en compte tous ces signaux et produit un plan quasi-optimal. Ils se distinguent explicitement des outils simplistes fournis par les marketplaces ou les ERP, notant que ceux-ci “n’adressent qu’une fraction” de ce à quoi les entreprises de e-commerce sont confrontées ¹⁴ ¹⁵. Par exemple, une marketplace Amazon pourrait vous donner une prévision de la demande pour la semaine prochaine - mais elle n’intégrera pas vos coûts de supply chain ou votre inventaire multi-entrepôts. La technologie de Lokad est conçue pour gérer chaque signal pertinent jusqu’au niveau SKU, sans se casser, et sans que les utilisateurs aient à jongler manuellement avec des tableurs ¹⁶. C’est une forte proposition de valeur si elle est livrée comme annoncé.

Pour résumer Lokad : Il se classe en tête de notre liste pour sa capacité d’optimisation holistique et sa technologie avancée. Il répond de front au critère d’optimisation conjointe - les stocks, les prix, et plus encore peuvent être optimisés ensemble via sa plateforme programmatique. Il exploite la prévision probabiliste et les moteurs économiques (ils faisaient des prévisions quantiles avant que ce ne soit cool, comme en témoigne leur succès dans le concours M5 ⁶) et ne recule pas devant des effets complexes comme la substitution ou les corrélations multi-canal. Son architecture est évolutive et soucieuse des coûts, évitant le piège du calcul en mémoire à la force brute ³ ⁴. L’automatisation est très élevée, avec un minimum de réglage manuel nécessaire et un accent mis sur la production de décisions, pas seulement d’insights ¹³. Le scepticisme que l’on pourrait appliquer à Lokad concerne moins la question de savoir si la technologie fonctionne - les preuves suggèrent qu’elle le fait - mais plutôt de savoir si une organisation est prête à adopter une solution aussi axée sur la science des données. Il y a aussi la question du bilan à plus grande échelle ; Lokad est plus petit que certains concurrents, bien qu’il ait des clients notables (par exemple, des distributeurs de pièces de rechange industrielles, des eTailers de mode, etc., selon leurs études de cas). Compte tenu de tout ce qui précède, Lokad obtient un classement de premier plan en tant que fournisseur d’optimisation de e-commerce véritablement à la pointe de la technologie dans notre étude.

2. RELEX Solutions - Optimisation du Retail Alimentée par l’IA (avec des Réserves)

RELEX Solutions est un fournisseur né en Finlande qui a rapidement gravi les échelons dans l’espace de la planification du retail, souvent mentionné dans le même souffle que les géants historiques pour la prévision et le réapprovisionnement. RELEX offre une plateforme unifiée 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 des prix et des promotions. Leur force principale a été dans l’épicerie et le retail (y compris le brick-and-mortar), mais ils commercialisent activement auprès des acteurs du e-commerce également, en mettant en avant leur capacité à planifier à travers les canaux en ligne et hors ligne. Pour les utilisateurs purement e-commerce, la valeur de RELEX réside dans sa planification de bout en bout - assurer le bon stock au bon endroit, avec le bon prix et les bonnes promotions, en utilisant des algorithmes avancés pour réagir aux changements de demande.

RELEX met fortement en avant son utilisation de l’IA et du machine learning. En fait, son PDG Mikko Kärkkäinen est un fervent défenseur de l’IA “pragmatique” dans le retail. Selon Kärkkäinen, “les systèmes de gestion des stocks alimentés par l’IA traitent des centaines de facteurs influençant la demande” pour augmenter la précision des prévisions ¹⁷. Il souligne même que quelque chose comme les données météorologiques n’est pas un facteur mais “des centaines de facteurs différents” (température, humidité, etc.) que leurs modèles de machine learning prennent en compte ¹⁸. Cela illustre l’approche de RELEX : jeter un large filet pour les signaux prédictifs (météo, promotions, jours fériés, tendances des médias sociaux, etc.) et utiliser le ML pour les corréler aux ventes. L’avantage est que le système peut détecter des motifs complexes (par exemple, comment une vague de chaleur soudaine affecte la demande de certaines boissons en combinaison avec le fait qu’il s’agit d’un week-end de vacances). La vision sceptique, cependant, est que vanter “des centaines de facteurs” pourrait être plus du marketing qu’une amélioration significative. En prévision, après un certain point, l’ajout de plus d’entrées donne des rendements décroissants ou peut même dégrader la précision si le modèle surajuste le bruit. Cela rend également le modèle opaque - il est pratiquement impossible pour un humain de comprendre un modèle qui utilise réellement des centaines de variables. RELEX tente de contrer le problème de la boîte noire en prônant une approche “boîte de verre” (transparence dans l’IA). Ils ont parlé de fournir une visibilité sur les prévisions et pas seulement un résultat, permettant aux planificateurs de voir les facteurs clés. Mais en réalité, un réseau neuronal ou un modèle de boosting de gradient avec des centaines de caractéristiques ne sera pas entièrement interprétable. Les planificateurs devront faire confiance au système. C’est un compromis général avec l’IA/ML : RELEX est du côté de “lancer beaucoup de données sur le problème et laisser les algorithmes le résoudre”.

Cela donne-t-il des résultats ? Les clients de RELEX signalent souvent une amélioration des prévisions et moins de ruptures de stock, en particulier dans les situations promotionnelles et saisonnières où les méthodes traditionnelles ont eu du mal. Par exemple, RELEX intègre les prévisions météorologiques et a revendiqué jusqu’à 75% de réduction de l’erreur de prévision pour certains produits sensibles à la météo lors de conditions météorologiques inhabituelles ¹⁹. Nous prenons de telles affirmations spécifiques avec un grain de sel - elles pourraient être choisies avec soin. Néanmoins, l’approche de RELEX ajoute probablement de la valeur à la prévision à court terme (“détection de la demande”) en ajustant les prévisions en fonction des dernières informations. En essence, leurs modèles ML affinent continuellement la prévision de base avec de nouveaux signaux de données. C’est ce que certains appellent la détection de la demande (utilisation de données quasi en temps réel pour mettre à jour les prévisions à court terme). RELEX, dans ses documents, fusionne la détection de la demande dans sa prévision ML plus large plutôt que de la traiter comme un module séparé. Ils défendent “la re-prévision continue et automatisée” à mesure que les situations changent.

Sur le front de l’optimisation conjointe, comment RELEX couvre-t-il le prix et l’assortiment en plus des stocks ? Historiquement, RELEX était le plus fort en réapprovisionnement et allocation (assurer que les magasins ou les centres de distribution ne tombent pas en rupture de stock). La planification de l’assortiment (décider quels produits vont dans quels magasins ou quels SKU à avoir) faisait également partie de leur suite, tout comme l’optimisation du planogramme (planification de l’espace). L’optimisation des prix était un manque jusqu’à récemment - mais en 2022, RELEX a introduit une capacité d’optimisation des prix pilotée par l’IA ²⁰ ²¹. 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 interface utilisateur, de sorte qu’un détaillant peut planifier une promotion et le système peut recommander la profondeur de réduction optimale, le timing, etc., puis les implications sur les stocks sont automatiquement prises en compte. Cela se dirige certainement vers une optimisation conjointe. Cependant, il n’est pas clair si RELEX optimise vraiment le prix et les stocks ensemble ou s’il le fait toujours séquentiellement (d’abord décider du prix, puis ajuster le flux des stocks). Dans une optimisation conjointe idéale, vous prendriez en compte les contraintes de stock lors de la fixation des prix (par exemple, ne pas promouvoir agressivement un article si l’approvisionnement est limité). La plateforme intégrée de RELEX permet probablement une telle réflexion transversale - par exemple, leur système remarquerait “nous n’avons pas assez de stock dans le centre de distribution pour soutenir cette promotion dans tous les magasins” et pourrait le signaler ou l’ajuster. Ils mentionnent l’alignement des prix et des promotions avec la supply chain pour s’assurer que les plans sont exécutables ²². Ainsi, RELEX est conscient de la nécessité de briser les silos.

Un point de vue interne : l’attrait de RELEX est qu’il rassemble tout (demande, approvisionnement, opérations) sur une seule plateforme pour l’utilisateur. Par exemple, les planificateurs de marchandises peuvent voir les prévisions et les contraintes partagées entre les départements ²². Cela signifie qu’un planificateur peut comprendre l’impact qu’une décision de prix aura sur la supply chain et vice versa. Cette visibilité est une grande amélioration par rapport aux outils cloisonnés. Mais la visibilité n’est pas la même chose que l’optimisation entièrement algorithmique. 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 être séquentielle. L’optimisation des prix pourrait produire un prix idéal, puis le module des stocks planifie autour de celui-ci. L’intégration étroite garantit qu’ils ne sont pas en conflit, mais elle ne résout pas nécessairement un seul problème d’optimisation qui maximise le profit en tenant compte des coûts des stocks simultanément. Atteindre ce dernier est complexe et peu de fournisseurs (sauf peut-être Lokad, comme discuté) tentent explicitement de le faire.

D’un point de vue architecture technologique, RELEX est assez avancé. Ils ont construit leur propre moteur de base de données en mémoire dans les premiers jours (une base de données columnaire optimisée pour les séries temporelles et les données hiérarchiques) qui leur a permis de calculer des prévisions pour des milliers de magasins x SKU rapidement. De nombreuses études de cas citent RELEX remplaçant les tableurs et les systèmes hérités et étant immédiatement capable de gérer beaucoup plus de granularité de données (comme passer d’une planification hebdomadaire à une planification quotidienne, ou d’une planification spécifique au magasin au lieu d’une taille unique). Pour le e-commerce, cela signifie que RELEX peut probablement gérer les prévisions au niveau des SKU pour un magasin en ligne mondial sans problème. Ils ont des déploiements dans le cloud et peuvent se développer. Nous n’avons pas trouvé de plaintes spécifiques sur le coût de la technologie de RELEX ; si quoi que ce soit, ils se vantent d’un calcul efficace (leurs fondateurs universitaires ont beaucoup optimisé les algorithmes). Une chose qu’ils ont est un concept de “base de données en direct” en mémoire, qui, si mal configuré, pourrait nécessiter beaucoup de RAM - mais c’est spéculatif. En général, la capacité de RELEX à passer à l’échelle n’a pas été un drapeau rouge sur le marché ; ils servent d’énormes chaînes d’épiceries avec des dizaines de milliers de SKU et de nombreux magasins, ce qui est analogue ou plus grand volume de données que beaucoup de e-commerçants ont.

L’automatisation et le rôle des planificateurs : RELEX parle souvent de “planification autonome” mais aussi de “décisions augmenté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 - par exemple, leur interface utilisateur, les 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 dans les premières étapes de l’adoption). RELEX a un concept d’“exceptions de prévision” où si la prévision de l’IA dévie trop en raison d’une anomalie, elle le signale. Ils ont également une capacité de simulation où les planificateurs peuvent voir pourquoi le système suggère quelque chose (au moins en termes généraux, comme “parce que le temps était chaud, nous prévoyons une augmentation de +50%”). Mikko Kärkkäinen a déclaré : “les solutions de pointe exploitent l’IA pragmatique et la puissance de calcul pour optimiser les tâches… de manière autonome sans intervention humaine” ²³, et il décrit également “la planification autonome du commerce de détail qui est auto-apprenante et auto-ajustable brise les silos” ⁵. Donc, au moins en vision, RELEX vise un système largement autonome. Nous restons légèrement sceptiques quant à l’autonomie complète ici : les grands détaillants qui utilisent RELEX ont toujours des équipes de planification. Mais ces équipes gèrent probablement par exception maintenant, ce qui est 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 comment fonctionnent les règles de tarification, ou ajuster les modèles de prévision), mais ils prétendent également qu’il s’auto-ajuste. Il y a une tension : si un utilisateur peut manuellement outrepasser beaucoup de choses, le système en pratique pourrait dépendre de ces paramètres manuels. S’ils font vraiment confiance à l’IA, ils devraient avoir à outrepasser de moins en moins. La référence de RELEX à l’“auto-ajustement” implique ce dernier - que le système aura besoin de moins en moins d’ajustements de paramètres manuels au fil du temps ⁵. Nous avons vu mentionner que l’approche de RELEX fait des planificateurs plus des superviseurs. Par exemple, un article a noté que le système de RELEX a libéré les planificateurs des tâches manuelles pour se concentrer sur les mouvements stratégiques ²⁴. Cependant, une source de SelectHub a rassemblé des critiques disant que certains utilisateurs ont trouvé des parties de RELEX “lourdes” et ont eu des problèmes comme la prévision de certaines contraintes (limites de fret) nécessitant des solutions de contournement ²⁵. Cela indique que tout n’est pas magique ; les utilisateurs rencontrent encore des limites où ils doivent intervenir ou où l’outil n’est pas aussi fluide.

Problèmes ou préoccupations connus : Il n’y a pas de cas de “défaillance” documentés publiquement pour RELEX comme il y en a pour certains (pas de titres de poursuites judiciaires). L’entreprise a généralement un buzz positif. Cependant, les bavardages anonymes de l’intérieur mentionnent parfois que la mise en œuvre de RELEX dans des environnements très grands et complexes peut faire surface à des problèmes. Par exemple, l’intégration des 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 le blâme va soit à l’outil, soit aux données). De plus, la croissance agressive de RELEX (ils ont embarqué de nombreux clients rapidement) signifie que certains clients pourraient ne pas obtenir le même accompagnement que, disons, Lokad fournit. Ce n’est pas une critique du logiciel en soi, mais des résultats réels : combien de projets RELEX répondent aux KPI promis ? Les fournisseurs aiment citer les améliorations de cas idéaux (“réduction des stocks de X% chez le client Y !”), mais mentionnent rarement les cas où les chiffres n’ont pas matérialisé. Nous soupçonnons que RELEX, comme tous les fournisseurs, a eu quelques projets qui ont sous-performé, peut-être en raison d’une mauvaise gestion du changement ou du fait que le détaillant ne fait pas assez confiance au système pour agir dessus. Lors d’un sommet de partenaires, même Blue Yonder a admis que la gestion inefficace du changement et les problèmes de données sont la cause de la plupart des échecs de projets ²⁶ - la même chose s’applique probablement aux mises en œuvre de RELEX.

Un autre aspect noté : RELEX a tendance à incorporer beaucoup de données externes, y compris des choses comme Google Trends, des données de localisation mobile pour les prédictions de fréquentation, etc. Pour un acteur du e-commerce, certaines de ces données (comme la fréquentation) sont sans pertinence, mais d’autres (météo, tendances) le sont. On devrait se poser la question : ai-je vraiment besoin de tous ces flux de données ? Pour certaines entreprises de e-commerce, des modèles simples sur l’historique des ventes pourraient être presque aussi bons. RELEX vendra certainement l’idée que plus de données donnent de meilleures prévisions. Les résultats du concours M5 (auquel RELEX n’a pas participé publiquement, à notre connaissance) ont montré que les modèles sophistiqués ont surpassé les plus simples, mais souvent de petites marges. Les meilleures méthodes étaient souvent des ensembles de nombreux modèles, pas différent de ce que RELEX pourrait faire en interne. Mais curieusement, une approche pure de machine learning n’a pas écrasé catégoriquement les méthodes traditionnelles dans ces concours - une combinaison de modèles statistiques soigneusement ajustés tendait à gagner. Donc, si nous vérifions les affirmations de RELEX contre des benchmarks comme M5 : nous voyons que la prévision probabiliste est en effet précieuse (ce qu’ils font), mais nous voyons aussi qu’il n’y a pas de sauce secrète unique parmi les meilleures approches - il s’agit de modélisation soignée. En l’absence de publication par RELEX de leur précision sur de tels ensembles de données standard, nous restons sur nos gardes. Le conseil du sceptique à quiconque envisage RELEX est : demandez des preuves spécifiques d’amélioration, et définissez une base de référence claire. Par exemple, si RELEX dit “nous avons amélioré la précision de la prévision de 30%”, clarifiez “30% par rapport à quelle métrique et quelle base de référence ?” De nombreuses fois, les fournisseurs mesurent l’augmentation par rapport à un scénario qui flatte leur outil (disons, comparé à des prévisions naïves ou à une mauvaise année). Le conseil de cette étude : exigez de la clarté sur les bases de référence pour toute revendication de performance.

En résumé, RELEX Solutions se classe parmi les meilleurs fournisseurs car il aborde les domaines clés (demande, stocks, tarification) de manière intégrée et utilise largement les techniques modernes d’IA/ML. Ses points forts incluent des prévisions très granulaires qui tiennent compte de nombreux facteurs, de solides capacités de planification promotionnelle et saisonnière, et une plateforme unifiée qui offre à toutes les parties prenantes une seule source de vérité. Il coche la case de l’évolutivité (prouvée dans le commerce de détail de grande taille), de la gestion de la cannibalisation (via des modèles de prévision avancés qui prennent en compte les effets croisés des produits ²⁷), du marketplace/omni-canal (le système peut planifier en ligne et hors ligne simultanément et probablement ingérer les données des concurrents si elles sont fournies). RELEX pousse également vers l’automatisation, avec des revendications de modèles auto-ajustables et de décisions autonomes, bien qu’en pratique une certaine supervision de l’utilisateur reste nécessaire. Les principales réserves sont la complexité et l’opacité qui accompagnent son approche lourde en IA - les utilisateurs doivent faire confiance à la boîte noire dans une certaine mesure - et la nécessité de séparer 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 soignée et une culture axée sur les données pour être pleinement exploité. Nous encourageons également les utilisateurs potentiels à se méfier du “lavage d’IA” dans l’industrie ; le message de RELEX est parmi les plus crédibles (puisqu’ils ont une véritable technologie sous le capot), mais même les déclarations de Mikko sur “des centaines de facteurs” ¹⁷ doivent être vues comme un enthousiasme pour l’IA plutôt qu’une garantie de résultats nettement meilleurs qu’un concurrent. Dans un contexte de e-commerce, RELEX peut certainement faire le travail, assurez-vous simplement de mesurer rigoureusement ses résultats et de garder un œil sur l’utilisation réelle de toutes ces fonctionnalités sophistiqué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 du logiciel de supply chain, avec des décennies d’histoire dans les systèmes de planification du commerce de détail et de la fabrication. Il dispose d’une suite complète qui couvre la prévision, le réapprovisionnement, la gestion des entrepôts, le transport, la main-d’œuvre et la tarification (après avoir acquis le spécialiste de la tarification Revionics en 2020). Pour les acteurs du e-commerce, Blue Yonder propose des solutions initialement conçues pour les grands détaillants et les entreprises de biens de consommation - pensez à lui comme le mastodonte de l’entreprise dans cet espace. Cependant, avec cet héritage viennent à la fois des forces (fonctionnalité robuste, évolutivité, expérience de domaine) et des faiblesses significatives (technologie obsolète par endroits, problèmes d’intégration dus à de multiples acquisitions, et un bilan qui comprend quelques échecs très médiatisés).

En termes d’optimisation conjointe, l’histoire de Blue Yonder est un peu mitigée. Ils ont des composants pour toutes les pièces : 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 (qui est essentiellement la prévision de la demande à différents niveaux de prix). Blue Yonder commercialise certainement l’idée d’une fin à fin, “de la planification à l’exécution” unifiée 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 sa propre histoire et a été intégré après acquisition. Le défi de Blue Yonder est de faire en sorte que cela ressemble à une solution cohérente. La société a reconnu qu’historiquement, elle avait une suite fragmentée ; en conséquence, en 2023, ils ont annoncé une transformation architecturale majeure : passer à un “modèle de données unique et plateforme d’application” sur le cloud Snowflake ²⁸. C’est une grande affaire - essentiellement la réingénierie de leurs produits pour tous lire/écrire à partir d’un grand dépôt 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 comme prometteuse et problématique. Prometteuse car si elle est réalisée, elle résoudrait en effet beaucoup de maux de tête d’intégration (plus d’interfaces par lots entre la planification de la demande et la tarification, par exemple - elles regarderaient 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 l’élimination complète des intégrations peut être trop optimiste pour la plupart des clients.” ²⁹. Les clients ont des données dans de nombreux endroits, tout ne sera pas soigneusement rangé dans Snowflake, donc une intégration personnalisée sera toujours nécessaire pour les systèmes non-Blue Yonder ²⁹. En bref, la stratégie de Blue Yonder est un travail en cours - une réponse à être considéré comme “legacy”. Ils ont explicitement dit qu’ils n’imposeront pas d’“événements de falaise” (abandon de l’ancienne technologie du jour au lendemain) mais microserviceront progressivement les modules legacy, permettant aux clients de migrer à leur propre rythme ³⁰ ³¹. Cela signifie qu’actuellement, un client de Blue Yonder pourrait encore utiliser, disons, l’ancienne planification de la demande de JDA sur site, avec une intégration à Revionics dans le cloud. La plateforme entièrement unifiée pourrait être disponible pour le grand public dans quelques années. En attendant, l’optimisation conjointe est plus manuelle avec Blue Yonder : vous pourriez utiliser leurs outils en tandem, mais c’est 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 l’apprentissage automatique dans la prévision (en exploitant la technologie de l’entreprise Blue Yonder GmbH qu’ils ont acquise en 2018, spécialisée dans l’IA pour le commerce de détail). Ils prétendent utiliser “l’IA explicable, l’apprentissage automatique, et même l’IA générative” dans diverses applications ³². Ils ont certainement des algorithmes avancés pour des choses comme l’optimisation du réapprovisionnement, l’allocation, etc., développés sur des décennies. Mais on doit être sceptique car Blue Yonder a aussi 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 dans le cloud, une grande partie fonctionnait sur de vieilles architectures (certaines solutions nécessitaient des bases de données Oracle, etc.). Donc, lorsque Blue Yonder commercialise une “planification cognitive, pilotée par ML”, on doit se poser la question : est-ce vraiment une nouvelle technologie ou simplement un nouveau branding ? Par exemple, leur planification de la demande pourrait maintenant utiliser ML pour estimer les augmentations de prévision pour les vacances, ce qui est bien, mais l’architecture sous-jacente exploite-t-elle vraiment la puissance de calcul du cloud d’aujourd’hui, ou est-elle contrainte par le fait d’être rétrofitée dans un système legacy ?

Un problème historique concret : Blue Yonder (JDA) a acquis i2 Technologies en 2010. i2 était connu pour ses solutions lourdes en optimisation, mais aussi pour ses implémentations ratées parfois. De manière célèbre, après que JDA ait acheté i2, Dillard’s (un grand magasin) a gagné un procès pour 246M$ alléguant que le logiciel de i2 n’a pas tenu ses promesses ³³ ³⁴. C’était un énorme coup dur - en gros, le logiciel et le projet ont échoué si lamentablement que le client a obtenu des dommages dépassant 30 fois ce qu’il avait payé pour le logiciel. Cette saga, bien qu’elle remonte à 15 ans, souligne que même les fournisseurs les plus réputés peuvent avoir de gros ratés si la technologie promet trop ou n’est pas bien mise en œuvre. Blue Yonder a dû absorber ce coût et tirer des leçons (on l’espère). Cela souligne pourquoi nous restons sceptiques : les grands fournisseurs peuvent se vanter de “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 un échec traîné devant les tribunaux publics.

À la décharge de Blue Yonder, ils sont devenus plus ouverts pour aborder les problèmes. Lors de leur sommet de partenaires 2023, ils ont ouvertement discuté des “projets rouges” (implémentations problématiques) et ont 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 l’exactitude des données et le soutien du client dans l’adaptation des processus étaient essentiels. Cette introspection est bonne - cela signifie que Blue Yonder n’est pas aveugle aux raisons des échecs de projets. Cela s’aligne également avec notre thème d’analyse globale : souvent, ce n’est pas que les mathématiques sont fausses, c’est que l’intégration dans le monde réel est difficile. Le fait que Blue Yonder pointe du doigt 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 vraiment intégrés de manière transparente, la migration des données ne serait pas un tel casse-tête. Le fait qu’elle le soit implique que les clients ont peut-être dû effectuer une importante réconciliation des données pour utiliser la suite complète. La couche de données unifiée de Snowflake vise à résoudre ce problème, mais comme dit, c’est encore tôt.

Examinons les capacités actuelles de Blue Yonder pour un scénario de e-commerce :

Prévision de la demande : Blue Yonder Luminate Demand (surtout avec Demand Edge) utilise l’apprentissage automatique pour incorporer de nombreux facteurs (météo, événements, tarification). Ils se sont également orientés vers des prévisions probabilistes ; au moins, ils soutiennent l’utilisation d’intervalles de confiance ou de quantiles dans la planification. Un exemple de leur blog : ils n’utilisent pas l’IA pour simplement superposer des facteurs sur une base, mais pour reconstruire la prévision de zéro chaque jour en utilisant les dernières données, en tenant automatiquement compte de choses comme les décalages de calendrier, et en se corrigeant automatiquement lorsque de nouvelles données réelles arrivent ³⁵ ³⁶. Ils affirment que cela supprime le besoin pour les planificateurs de maintenir des ajustements manuels ou des profils pour la saisonnalité - le modèle les apprend et s’adapte ³⁶. Cela est très en ligne avec la pratique actuelle de prévision. L’approche de Blue Yonder ici est solide en théorie : apprentissage continu, reconnaissance de l’incertitude (ils parlent du risque de sur/sous-prévision et des compromis de coût ³⁷), et utilisation de l’IA pour détecter des relations complexes (comme la façon dont différents temps ou promotions stimulent la demande, sans qu’un humain code explicitement ces relations).
Stocks & Réapprovisionnement : Cela a longtemps été une force de JDA/Blue Yonder. Ils offrent une optimisation multi-échelons des stocks (MEIO), ce qui signifie qu’ils peuvent optimiser les niveaux de stocks à travers les centres de distribution et les centres de traitement pour le e-commerce, en tenant compte des délais de livraison, de la variabilité de la demande, etc., pour atteindre les 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é, et ainsi de suite. 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 probablement maintenant augmentés avec des prédictions basées sur l’IA, mais l’optimisation de base est probablement un mélange de recherche opérationnelle et de simulation. BY peut certainement gérer la planification à grande échelle des SKU ; de nombreux détaillants du Fortune 500 ont utilisé JDA pour le réapprovisionnement des magasins, ce qui est analogue à l’échelle à un grand entrepôt de e-commerce fournissant des clients.
Assortiment : Blue Yonder dispose d’outils de gestion de catégorie qui aident à décider des assortiments (quel mélange de produits dans quels magasins). Pour un acteur uniquement e-commerce, la planification de l’assortiment pourrait signifier décider quels nouveaux produits lister ou supprimer. Les outils de BY peuvent utiliser des attributs et des données de performance pour évaluer les changements d’assortiment. Cependant, c’est généralement un processus stratégique périodique, pas continu.
Optimisation des prix : Avec l’acquisition de Revionics, Blue Yonder a gagné un moteur robuste d’optimisation des prix qui est largement utilisé dans le commerce de détail (en particulier les chaînes d’épicerie et de marchandises générales) pour fixer les prix de base, les remises promotionnelles et les démarques. Revionics utilise l’IA pour modéliser l’élasticité des prix et même les impacts de la tarification concurrentielle, puis recommande des changements de prix qui atteignent des objectifs tels que la croissance des marges ou des revenus tout en tenant compte des règles de prix (par exemple, des prix se terminant en .99, etc.). Dans le cadre de Blue Yonder, Revionics est maintenant connu sous le nom de Luminate Pricing. En théorie, ce moteur, combiné aux prévisions de demande de Blue Yonder, boucle la boucle - vous pouvez simuler comment un changement de prix affectera la demande et les stocks, et choisir un prix optimal. Blue Yonder commercialise cela comme “tarification autonome alimentée par l’IA”, capable de fonctionner aussi souvent que nécessaire (même intrajournalier pour le e-commerce si désiré).

Une grande question : Comment ces pièces fonctionnent-elles réellement ensemble aujourd’hui ? Blue Yonder prétend qu’elles le font. Par exemple, ils pourraient dire que leur solution de tarification peut prendre en compte 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é, la boucle peut ne pas être aussi serrée qu’on pourrait l’espérer. Réalistement, un utilisateur e-commerce 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 hebdomadaires par lots de l’élasticité des prévisions. C’est de la planification conjointe, mais pas le graal de l’optimisation conjointe instantanée.

Sur les revendications AI/ML, Blue Yonder souffre parfois de buzzword-bingo dans le marketing. Ils utilisent des termes comme “cognitif”, “piloté par l’apprentissage automatique”, etc. Nous devrions vérifier s’il y a de la substance. Il y a des preuves de substance : par exemple, Blue Yonder (la filiale allemande à l’origine) avait développé des algorithmes qui ont été publiés (leur équipe a remporté un concours de prévision de vente au détail en 2014 en utilisant des réseaux neuronaux). De plus, le portefeuille de brevets de Blue Yonder est important (plus de 400 brevets) indiquant beaucoup de R&D ³⁸. Cependant, la quantité de brevets n’équivaut pas à la qualité du produit - cela montre simplement qu’ils ont essayé de nombreuses techniques. La perspective sceptique est de demander à Blue Yonder des résultats spécifiques : par exemple, ont-ils participé à M5 ou à un autre benchmark neutre ? Pas publiquement. Y a-t-il des études de cas avec des chiffres concrets avant/après ? Ils en ont, mais souvent les études de cas des fournisseurs sont optimistes et manquent de clarté de base. Blue Yonder dit des choses comme “Le détaillant X a vu une augmentation de Y% de son bénéfice en utilisant notre tarification” - mais sans contexte, c’est du marketing.

Il faut également prendre en compte le coût et la complexité avec Blue Yonder. Ce sont de grands systèmes d’entreprise. La mise en œuvre peut prendre de nombreux mois ou années, et impliquer non seulement la configuration du logiciel mais aussi la refonte des processus métier. Blue Yonder nécessite généralement soit leurs services professionnels, soit une entreprise partenaire pour la mise en œuvre. Le coût total de possession peut être très élevé (licence + services + IT). Pour un pur acteur du e-commerce, en particulier de taille moyenne, Blue Yonder pourrait être excessif ou trop lent à mettre en œuvre par rapport à des solutions SaaS plus agiles. Même les grandes entreprises hésitent parfois : un événement marquant de l’industrie a été Lidl (le grand détaillant mondial) annulant un projet SAP de 500M€ en 2018 après qu’il n’a pas répondu aux besoins ³⁹. C’était SAP, pas Blue Yonder, mais cela illustre que d’énormes projets peuvent échouer, engloutissant d’énormes budgets. Les projets de Blue Yonder sont tout aussi complexes ; en effet, leur partenaire JBF Consulting a noté que le concurrent Manhattan Associates a adopté une approche différente (nécessitant une réimplémentation pour leur nouvelle plateforme), tandis que BY tente une migration plus douce ⁴⁰. Le fait que Manhattan ait choisi un chemin de “réimplémentation pour passer à une nouvelle technologie” suggère que ces transitions ne sont pas triviales. Blue Yonder essaie d’éviter les mises à niveau cauchemardesques en évoluant lentement - mais cela signifie aussi que les clients peuvent être sur une technologie pas tout à fait moderne maintenant, en attendant le nouveau matériel.

D’un point de vue automatisation, Blue Yonder est probablement moins automatisé que Lokad ou RELEX aspirent à l’être. De nombreux clients BY utilisent les outils pour générer des recommandations que les planificateurs approuvent ou ajustent ensuite. Blue Yonder promeut le concept de “supply chain autonome” (surtout depuis son acquisition par Panasonic en 2021, ils parlent de connecter les données IoT à des décisions automatisées) ⁴¹. Mais il est sûr de dire qu’une grande partie de leur clientèle est encore en mode hybride : faisant confiance au système pour certaines décisions, en outrepassant manuellement d’autres. Par exemple, un scénario courant est que le système suggère des commandes mais qu’un planificateur examine les exceptions (tout comme avec RELEX). Ou le système de tarification suggère des changements de prix, mais un responsable du merchandising les examine, rejetant peut-être certains qui ne sont pas en accord avec la stratégie de marque. Le logiciel peut faire beaucoup, mais les entreprises ont des processus établis qui ne changent pas du jour au lendemain.

Intelligence concurrentielle et marketplaces : La solution de tarification de Blue Yonder (Revionics) intègre bien les données de prix concurrentielles - elle a une fonction de réponse concurrentielle et peut ingérer les prix des rivaux pour ajuster les vôtres ⁴². Ainsi, pour le e-commerce, si vous avez un flux de tarification concurrentielle, Revionics peut l’inclure dans son optimisation (par exemple, ne pas tarifer au-dessus d’un concurrent de plus de X% pour maintenir l’image de prix, ou correspondre au prix le plus bas si nécessaire). C’est un plus dans l’optimisation conjointe de la tarification. Sur les marketplaces, Blue Yonder n’a pas spécifiquement un module de gestion de marketplace comme certains fournisseurs spécifiques au e-commerce (comme les outils de type conseiller de chaîne pour Amazon). On pourrait donc utiliser Blue Yonder pour la planification de base mais avoir encore besoin d’un outil séparé pour gérer les tactiques spécifiques à la marketplace (publicité, buy-box, etc.). Cela est en dehors du champ d’action de Blue Yonder et n’est pas un reproche à leur égard, juste une note que le e-commerce a des facettes que ces fournisseurs traditionnels n’abordent pas (Lokad ou RELEX ne couvrent pas non plus les enchères publicitaires, etc., pour être juste).

Étant donné l’échelle et l’héritage de Blue Yonder, il convient également de scruter les contradictions internes dans leur message. Par exemple, Blue Yonder pourrait vanter la “personnalisation et la tarification en temps réel” sur leur plateforme de commerce, alors que leurs solutions de planification fonctionnaient historiquement sur des cycles de lots (planification nocturne, replanification hebdomadaire, etc.). Ils se dirigent vers une utilisation des données plus en temps réel (leur partenariat avec Snowflake vise en partie à permettre le partage de données quasi en temps réel). Mais si un fournisseur prétend offrir une “tarification dynamique en temps réel et une optimisation des stocks”, demandez : est-ce qu’ils veulent dire que le système recalcule en continu, ou simplement qu’il peut réagir rapidement si déclenché ? Et avez-vous vraiment besoin du temps réel pour les décisions d’assortiment ? Probablement pas - c’est plus stratégique. Donc une oreille critique attrapera quand le langage marketing est incohérent. Le marketing large de Blue Yonder tombe parfois dans ce piège de tout promettre (de la stratégie à long terme à l’exécution instantanée). Il est sage de délimiter quelles fonctions sont vraiment 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 par lots (comme la planification de l’assortiment est saisonnière).

Préoccupation concernant le coût de Snowflake : Nous devrions souligner un point subtil mais important : le fait que Blue Yonder se construise sur Snowflake pourrait changer 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 font beaucoup de calculs sur Snowflake, la facture Snowflake du client pourrait augmenter. Cela est analogue à l’ancienne facturation des mainframes IBM par MIPS - vous payez plus plus vous l’utilisez, ce qui peut décourager l’utilisation complète du système. Blue Yonder et Snowflake ont probablement travaillé sur une tarification, mais l’utilisateur doit se méfier du “choc de facturation” si les scénarios de planification sont exécutés très souvent sur de grandes données. C’est une considération très réelle car la planification de la supply chain peut être computationnellement intensive (surtout si on fait des simulations de scénarios ou des calculs probabilistes). Un processus inefficace sur Snowflake pourrait brûler beaucoup de crédits. Blue Yonder y a probablement pensé (ils doivent le rendre commercialement viable), mais c’est quelque chose dont il faut être conscient. Un modèle de coût mal aligné sur la valeur commerciale (comme facturer par les données traitées plutôt que par le résultat) rappelle les pièges des époques précédentes.

En conclusion, Blue Yonder est classé juste en dessous des solutions plus récentes en termes de réalisation de la vision “next-gen”. Il a indéniablement une riche fonctionnalité et de nombreuses déploiements réussis, mais d’un point de vue technique sceptique, nous voyons une entreprise en transition. Ils essaient de se moderniser et dans ce processus, ils parlent beaucoup de l’IA, de l’intégration et de l’automatisation. Cependant, jusqu’à ce que cette transformation soit pleinement réalisée, les clients devraient être prudents quant aux écarts entre les modules et l’effort réel nécessaire pour obtenir les résultats promis. L’ensemble d’outils de Blue Yonder peut certainement soutenir les opérations de e-commerce (de nombreux grands détaillants avec des affaires omni-canal utilisent BY pour leur côté e-com), et sa portée est inégalée (aucun des autres fournisseurs n’a une portée aussi large, y compris des choses comme la logistique). Cependant, si une entreprise de e-commerce n’a besoin que de l’optimisation de la demande et de l’offre, Blue Yonder pourrait être trop lourd à moins qu’ils n’aient spécifiquement besoin de cette robustesse d’entreprise ou qu’ils l’utilisent déjà dans d’autres domaines. Notre étude sceptique trouve les affirmations de Blue Yonder d’être à la pointe de la technologie quelque peu douteuses jusqu’à preuve du contraire - la technologie a du pedigree, mais la charge leur revient de montrer que le logiciel vieux de plusieurs décennies est vraiment devenu “AI-first” et unifié. Pour l’instant, nous conseillons de considérer Blue Yonder comme une option puissante mais encombrante, que vous choisissez si vous avez besoin d’une solution très étendue et avez les ressources pour la mettre en œuvre, et peut-être pas le premier choix si l’agilité et un retour sur investissement rapide sont au premier plan.

4. ToolsGroup - Pionnier de l’optimisation des stocks s’étendant à la vente au détail complète

ToolsGroup est un vétéran de l’espace de planification de la supply chain, connu en particulier pour son expertise en prévision de la demande et optimisation des stocks. Sa solution phare, historiquement appelée SO99+ (Service Optimizer 99+), était largement utilisée pour la planification des stocks basée sur le niveau de service et l’optimisation multi-échelons. En termes plus simples, ToolsGroup excellait à aider les entreprises à déterminer “quel est le stock minimum dont j’ai besoin à chaque emplacement pour atteindre le niveau de service X ?” dans l’incertitude - un problème crucial pour la distribution et le e-commerce. ToolsGroup a été parmi les premiers à mettre en œuvre la prévision probabiliste commercialement, et il a longtemps plaidé pour s’éloigner des prévisions déterministes et utiliser la distribution complète de la demande ⁴³ ². Cette approche est très alignée sur ce que nous considérons comme étant à la pointe de la technologie aujourd’hui (et que d’autres fournisseurs ont adopté plus tard).

Dans un contexte de e-commerce, la force de ToolsGroup signifie qu’il peut gérer un grand nombre de SKU avec une demande erratique, et produire toujours des cibles de stock optimales. De nombreux e-commerçants ont des articles “longue traîne” qui se vendent rarement - les modèles probabilistes de ToolsGroup sont naturellement adaptés à la planification de ces articles (en capturant la nature sporadique de la demande plutôt qu’en la moyennant de manière incorrecte). Ils gèrent également les introductions de nouveaux produits, la saisonnalité et les promotions via leurs modèles de prévision qui intègrent l’apprentissage automatique. Par exemple, ils pourraient utiliser des analogies (trouver l’historique d’un article similaire) ou une modélisation basée sur des attributs pour prévoir un nouveau SKU.

Alors que ToolsGroup était historiquement axé sur les stocks et la demande, ces dernières années, il a reconnu que le prix, 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 appelée JustEnough en 2018/2019 (JustEnough faisait plus tard partie de Mi9 Retail puis a été vendu à ToolsGroup). Le logiciel de JustEnough couvrait la planification financière des marchandises, la planification de l’assortiment, l’allocation et l’optimisation des baisses de prix - essentiellement des fonctions de merchandising de détail, y compris les baisses de prix. Avec cette acquisition, ToolsGroup a étendu son empreinte de la supply chain pure à ce que l’on pourrait appeler la planification de détail. Ils commercialisent maintenant une suite intégrée qui peut tout faire, de la planification de haut niveau à l’exécution, avec 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 trivial. ToolsGroup a travaillé à intégrer les modèles de données (ils mentionnent 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 appelé “Real-Time Retail” qui connecte le système de planification de JustEnough avec un Hub d’Inventaire pour obtenir des flux de données en temps réel ⁴⁵ ⁴⁶. L’idée est que lorsque les ventes se produisent (ou lorsque les stocks bougent), ces événements s’écoulent instantanément dans le système de planification, et il peut replanifier l’allocation ou le réapprovisionnement à la volée. Cela suggère que ToolsGroup essaie 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éballons cela : ToolsGroup appelant leur solution “Real-Time Retail, la seule solution qui répond au comportement d’achat sur le moment” ⁴⁵ est une affirmation forte. Cela implique essentiellement qu’ils peuvent ajuster le plan dès qu’un changement se produit. Peut-être que le système peut automatiquement déclencher un transfert de stock ou accélérer une commande si les ventes augmentent de manière inattendue aujourd’hui. Si c’est vrai, c’est puissant - cela brouille la planification et l’exécution. Cependant, le point de vue sceptique est que “en temps réel” est probablement limité à certaines fonctions (comme la réaffectation des stocks, qui est plus facile à faire rapidement) et non à d’autres (comme la réoptimisation complète d’un assortiment, que vous ne feriez pas en temps réel). Il convient également de noter que chaque fournisseur utilise maintenant “en temps réel” dans le marketing (ce qui signifie souvent une actualisation toutes les quelques minutes ou toutes les heures, ce qui est bien). La PDG de ToolsGroup elle-même a noté que les détaillants doivent pivoter rapidement pour éviter l’érosion des marges lorsque la demande change ⁴⁷, ce qui est vrai. Le système recalcule et recommande automatiquement les commandes ou les transferts dès qu’une nouvelle information arrive ⁴⁸.

En supposant 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 avoir cela alimenté dans les cibles de stocks dans SO99+, et également planifier la tarification des baisses de prix 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 de baisse de prix prévu. Il s’agit toujours peut-être d’un processus séquentiel (d’abord décider des baisses de prix, puis voir le résultat des stocks) à moins qu’ils n’aient construit un modèle d’optimisation combiné (ce qui est peu probable sur cette largeur). Mais c’est une solution unifiée en termes de flux de données.

Là 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 ont martelé pendant des années que les prévisions à un seul chiffre sont insuffisantes et qu’il faut planifier avec des probabilités. Par exemple, ils produiront non seulement “demande attendue = 100” mais aussi une courbe montrant qu’il y a 10% de chances que la demande >120, etc. Ensuite, leur optimisation utilise cela pour décider des niveaux de stocks de telle sorte que, par exemple, 95% du temps la demande peut être satisfaite ⁴⁹ ⁵⁰. Cette approche gère intrinsèquement l’incertitude et même la cannibalisation à un certain degré (surtout si vous utilisez leur modélisation pour les articles corrélés). Un aspect intéressant : ToolsGroup a souvent soutenu que l’utilisation de la prévision probabiliste peut prolonger la durée de vie des systèmes de planification ERP hérités (comme SAP APO) en leur fournissant de meilleures informations ¹ ⁵¹. Cela souligne que le différentiateur de ToolsGroup était principalement dans les mathématiques de la prévision et des stocks plutôt que d’être une interface de planification tout-en-un.

Et qu’en est-il de l’automatisation et de la facilité d’utilisation ? ToolsGroup était traditionnellement plus un “moteur back-end” avec une interface utilisateur quelque peu maladroite, selon certains utilisateurs. Ils ont depuis amélioré l’interface (nouvelle interface web, etc.). Mais plus important encore, ils mettent l’accent sur l’automatisation dans la planification. Leurs documents prétendent, par exemple, que “l’automatisation intégrée réduit la charge de travail de planification jusqu’à 90%” ⁵². Ils citent également souvent des clients qui ont réalisé une “réduction de la charge de travail du planificateur de 40 à 90%” et une “réduction des stocks de 20 à 30%” après avoir utilisé ToolsGroup ⁵³ ⁵⁴. Ce sont de gros chiffres. La revendication de réduction des stocks est plausible si une entreprise était très inefficace auparavant ou si elle conservait des tampons excessifs en raison du manque de confiance dans les prévisions. La réduction de la charge de travail du planificateur implique que le système fait beaucoup plus automatiquement. Cela correspond à ce que nous attendons : un système probabiliste devrait réduire les interventions d’urgence (puisque vous planifiez pour l’incertitude, moins de surprises se produisent, donc les planificateurs n’accélèrent pas autant ou ne réaffectent pas manuellement les stocks à la dernière minute). Cependant, un sceptique noterait que la réduction de la charge de travail de 90% est probablement le maximum (peut-être un cas où une entreprise est passée de 10 planificateurs à 1 après la mise en œuvre - possible mais pas typique). Et 20-30% de moins de stocks pourrait être le résultat de l’entreprise qui transportait initialement beaucoup trop de “juste au cas où”. Dans la supply chain, une fois que vous optimisez, vous voyez souvent peut-être des réductions de 10 à 15% si les choses étaient modérément correctes auparavant. Nous soupçonnons donc que les gammes annoncées par ToolsGroup ⁵³ sont les meilleurs scénarios possibles. Il est instructif qu’ils les présentent comme des gammes - cela implique que les résultats varient considérablement d’un client à l’autre.

Une chose que ToolsGroup a pour elle, c’est la stabilité et une focalisation spécifique. Ils font de l’optimisation de la supply chain depuis 30 ans (fondée en 1993). Ils ne sont pas aussi grands que Blue Yonder ou aussi à la mode que RELEX, mais ils ont une base de clients fidèles et une expertise approfondie dans le domaine. Pour une entreprise de 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-commerçants avec plusieurs centres de fulfillment ou ceux qui stockent également dans des entrepôts 3PL, etc. Il poussera de manière appropriée les stocks là où ils sont le plus nécessaires tout en gardant les tampons centraux maigres.

Cependant, le point faible de ToolsGroup était l’optimisation des prix. L’acquisition de JustEnough leur a donné l’optimisation des prix de liquidation (décider des calendriers de réduction pour la liquidation). C’est utile pour le e-commerce avec des produits saisonniers ou de la mode. Mais ils manquent encore d’une véritable optimisation des prix dynamiques comme ce que Revionics/Blue Yonder ou certains fournisseurs de prix spécialisés ont. L’optimisation des prix de liquidation concerne les prix de fin de vie ou de promotion. L’optimisation régulière des prix de tous les jours (pour la marge ou le positionnement concurrentiel) n’est pas une force bien connue de ToolsGroup. Ils pourraient avoir des capacités de base ou tirer parti de partenaires. Cela signifie que si l’optimisation conjointe du prix + des stocks est une priorité, ToolsGroup pourrait ne pas être aussi fort que Blue Yonder ou RELEX qui ont des moteurs de tarification dédiés. ToolsGroup pourrait toujours optimiser les stocks en supposant un prix donné, mais il ne vous dira pas le meilleur prix à fixer pour maximiser le profit (à part les scénarios de liquidation de fin de vie). C’est une distinction importante : leur “optimisation” est principalement orientée vers l’approvisionnement (niveaux de stocks, réapprovisionnement) plutôt que vers la formation de la demande (tarification, promotion) - malgré l’ajout de certains outils de formation de la demande par acquisition.

En termes de pile technologique, ToolsGroup propose maintenant une option SaaS cloud et positionne même certaines de ses offres sous des noms cool comme “Inventory Hub” et “Fulfill.io”. Cela montre qu’ils essaient de se moderniser et peut-être de séduire un marché plus large, y compris les entreprises de e-commerce de taille moyenne. Le moteur sous-jacent utilise toujours des méthodes statistiques avancées, et probablement du C++ ou similaire pour le calcul. Nous n’avons pas entendu parler de ToolsGroup atteignant des murs de performance ; ils ont des références de clients avec des millions de combinaisons SKU-localisation. Si quoi que ce soit, le talon d’Achille de ToolsGroup pourrait être qu’il est vu comme un “outil d’optimiseur” - puissant mais nécessitant une configuration par des experts. Ils ont essayé de simplifier avec plus de ML prêt à l’emploi. Par exemple, ils intègrent la détection de la demande (utilisation des tendances à court terme pour ajuster les prévisions) et prétendent utiliser l’apprentissage automatique pour identifier quels facteurs influencent le plus la demande ⁵⁵. Ils ont également démenti un mythe dans leur blog selon lequel les prévisions probabilistes ne peuvent pas être ajustées par les humains - précisant qu’ils peuvent incorporer le jugement, mais que les mathématiques tiendront compte du biais historique ⁵⁶. Cela reflète une approche équilibrée : ils n’éliminent pas totalement l’humain, mais ils guident l’humain avec de meilleures informations.

Effets de cannibalisation : Le modèle probabiliste de ToolsGroup peut, si configuré, capturer la cannibalisation (par exemple, si vous entrez une relation de substitution, ils peuvent modéliser des scénarios où si un article est épuisé, une partie de la demande se déplace vers un autre). Cependant, cela nécessite probablement des efforts pour établir des relations ou utiliser leur ML pour regrouper des articles. Il n’est pas clair à quel point cela est automatique. Mais ToolsGroup a insisté sur le fait de traiter avec “longue queue, demande intermittente, et plus de canaux” dans un blog de 2017, disant essentiellement que ces conditions brisent les outils traditionnels et nécessitent des méthodes probabilistes ⁵⁷. Ils mentionnent spécifiquement “plus de canaux de marché, avec une demande agrégée provenant de plusieurs flux” comme un scénario où les prévisions à un seul chiffre se brisent, laissant entendre que leur solution gère mieux le multi-canal ⁵⁷. Ainsi, un e-commerçant vendant sur son site web et Amazon, par exemple, pourrait utiliser ToolsGroup pour planifier la demande combinée. L’outil produirait une prévision totale et permettrait peut-être de répartir les stocks par canal de manière optimale (bien que la répartition par canal soit souvent plus simple lorsqu’elle est expédiée à partir des mêmes centres de fulfillment, mais en cas de stocks séparés, cela compte).

Un aspect à surveiller avec ToolsGroup (comme avec tout fournisseur de suite acquise) est la cohérence de l’expérience utilisateur. Les modules de prévision, de stocks et d’assortiment sont-ils tous dans une seule interface utilisateur maintenant, ou cela donne-t-il l’impression de sauter entre les systèmes ? Ils ont travaillé à unifier l’interface, mais un retour d’information des utilisateurs serait nécessaire. Ce n’est pas aussi unifié que la plateforme unique de RELEX construite en interne, vraisemblablement.

En termes de bilan, ToolsGroup a 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 de fiasco majeur connu du public comme SAP ou JDA. Ils sont plus petits, donc chaque projet pourrait recevoir plus d’attention. Cela dit, parce qu’ils ont souvent vendu à des entreprises de fabrication/distribution, certaines personnes du secteur du commerce de détail/ecommerce ne les connaissent pas aussi bien. Leur incursion dans le commerce de détail via JustEnough signifie que certains anciens clients de JustEnough utilisent maintenant ToolsGroup. JustEnough lui-même avait des avis mitigés (il était correct pour la planification mais peut-être limité en termes de scalabilité - ce n’est pas clair). Donc ToolsGroup a dû renforcer ces modules. En tant que sceptiques, nous vous conseillerions de vérifier à quel point les analyses sont vraiment intégrées. Par exemple, le système peut-il automatiquement reconnaître qu’une promotion prévue dans le module JustEnough devrait ajuster la prévision de la demande dans SO99+ ? Probablement oui, ils auraient intégré les augmentations promotionnelles. Ils mentionnent que les “insights de détection de la demande aident à affiner la prévision statistique” ⁵⁸ ce qui implique qu’ils prennent en compte des éléments comme les promotions ou les tendances récentes pour ajuster les prévisions de base.

Pour condenser l’évaluation de ToolsGroup : Il est très fort dans son créneau d’origine (prévision & stocks) - sans doute le meilleur de sa catégorie en matière d’optimisation probabiliste des stocks - et s’élargit pour couvrir la tarification et l’assortiment, bien que ces nouvelles capacités ne rivalisent pas encore avec les concurrents spécialisés. ToolsGroup répond à beaucoup de nos critères d’état de l’art :

Prévisions probabilistes ? Oui, ils l’ont défendu ⁴⁹ ⁴³.
Optimisation économique ? Implicitement oui pour les stocks (ils optimisent par rapport aux compromis service vs. coût), bien que pas aussi explicitement sur le profit que Lokad. C’est plus “atteindre l’objectif de service avec un minimum de stocks” qui est une forme d’optimisation des coûts.
Scalabilité ? Généralement oui, pas d’alarmes. Et leur approche est efficace (pas de force brute).
Cannibalisation ? Possiblement, via une modélisation avancée, mais ce n’est pas leur principal argument de vente.
Marché/concurrentiel ? Pas intrinsèquement - vous géreriez cela en externe ou via des entrées. ToolsGroup ne va pas chercher les prix des concurrents pour vous ou autre chose.
Automatisation ? Oui, élevée. Après la configuration, de nombreuses tâches de planification peuvent être automatisées avec leur système émettant des propositions de commandes que les planificateurs approuvent simplement. Ils vantent d’énormes réductions de charge de travail et moins de biais humain.
Scepticisme vis-à-vis des revendications du fournisseur : Le marketing de ToolsGroup est en fait assez modéré comparé à d’autres, à part ces statistiques d’amélioration que nous avons déjà prises avec prudence. Ils se concentrent sur ce que fait la technologie (leurs blogs éducatifs sur la planification probabiliste sont substantiels, pas seulement du remplissage). Mais ils se joignent maintenant au jeu des buzzwords de l’IA, appelant tout “alimenté par l’IA”. Nous notons cependant qu’ils gardent un pied dans la recherche opérationnelle traditionnelle (OR) et un autre dans le ML, ce qui est un mélange sain.

Un point de données externe : Les revues de firmes d’analystes (comme Gartner) placent souvent ToolsGroup en tête pour la planification de la Supply Chain, mais ils pourraient commenter que la capacité de ToolsGroup est plus profonde que large, et que l’interface utilisateur était historiquement moins moderne. Ceci est partiellement résolu maintenant (nouvelle interface utilisateur, intégration).

Pour un pure-player du e-commerce, la décision d’opter pour ToolsGroup dépendrait probablement de savoir si l’optimisation des stocks est le principal point douloureux et s’ils ont besoin d’une solution éprouvée, quelque peu autonome pour cela. Si oui, ToolsGroup pourrait être un excellent choix, offrant des victoires rapides en termes de réduction des stocks et d’amélioration du service. Cependant, si l’entreprise de e-commerce cherche également à optimiser fortement les prix ou à mettre en œuvre des stratégies de démarquage omnicanal de pointe, ToolsGroup pourrait ne pas être aussi riche en fonctionnalités qu’un Blue Yonder ou RELEX ou un outil de tarification dédié. Il pourrait nécessiter de s’associer à une autre solution de tarification, ce qui pose alors des défis d’intégration. (Fait intéressant, ToolsGroup pourrait ne pas s’y opposer - ils ont historiquement parfois coexisté avec d’autres, se concentrant sur les stocks tandis qu’un autre système s’occupait de la tarification.)

En conclusion, ToolsGroup se classe comme un fournisseur spécialiste devenu suite technique solide. Nous apprécions sa rigueur d’ingénierie en matière de prévision et sa manière directe de s’attaquer à l’incertitude (ils ont depuis longtemps démystifié le problème “la prévision est toujours fausse” en planifiant avec des probabilités). Nous restons prudents quant à l’expansion récente : si leurs nouveaux modules de vente au détail intégrés performent au même niveau que leur cœur de métier. La contradiction interne que nous surveillons est leur affirmation d’être maintenant entièrement intégrés - si des fissures apparaissent (comme des données nécessitant une exportation/importation manuelle entre les modules), cela minerait le discours. Mais en l’état des informations disponibles, ToolsGroup semble offrir une expérience plus unifiée après JustEnough. Ils s’alignent même avec la tendance de l’utilisation des données en temps réel dans la planification, ce qui est louable.

Enfin, tout comme nous l’avons fait avec d’autres : examen critique des revendications du fournisseur pour ToolsGroup. Lorsqu’ils disent, par exemple, “90+% de disponibilité des produits, 20-30% moins de stocks, 40-90% de réduction de la charge de travail” ⁵³ ⁵⁴ - 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 hauts niveaux, et non d’un seul client atteignant tous simultanément. Personne ne devrait s’attendre à ce que ses stocks baissent de 30% tandis que le service passe à >90% et que les planificateurs sont réduits 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 entraîner une amélioration significative, mais nous conseillerions de fixer des objectifs réalistes et de mesurer au fur et à mesure. La bonne nouvelle est que l’accent de ToolsGroup sur les résultats mesurables (taux de service %, stocks $$) correspond à une approche de recherche de la vérité - il est très clair si cela fonctionne ou non en regardant ces métriques.

Démystifier le battage médiatique : Leçons et recommandations

Parmi ces fournisseurs, quelques thèmes communs de battage médiatique vs réalité ont émergé qu’un décideur du e-commerce devrait garder à l’esprit :

Méfiez-vous des mots à la mode : Des termes comme “AI-driven, cognitive, demand sensing, real-time, autonomous” sont utilisés à tort et à travers. Assurez-vous qu’ils sont soutenus par des capacités concrètes. Par exemple, “demand sensing” semble souvent génial - utiliser les ventes d’hier ou le bavardage sur les réseaux sociaux pour ajuster la prévision d’aujourd’hui - mais en pratique, cela peut seulement légèrement ajuster les chiffres et n’est essentiellement que de la prévision à court terme. Des experts de l’industrie ont qualifié le “demand sensing” de possible “mootware” - quelque chose qui existe mais n’apporte pas réellement de valeur au-delà de ce que fait déjà une bonne prévision ⁵⁹. Ne vous laissez pas séduire par des concepts “vaporware” sans preuve. Demandez au fournisseur : qu’est-ce que votre IA fait exactement que mon processus actuel ne peut pas faire, et pouvez-vous le prouver ? S’ils disent “nous considérons 300 facteurs”, mettez-les au défi de savoir si ces facteurs font vraiment bouger les choses ou ne font qu’une belle diapositive.
Base de référence et benchmarks : Établissez toujours une base de référence claire (par exemple, le taux de rotation des stocks de l’année dernière, le taux de réalisation, la marge brute) et voyez si le fournisseur accepte de mesurer l’amélioration par rapport à celle-ci. Beaucoup revendiquent des améliorations en pourcentage qui semblent énormes mais sont sans signification sans contexte. De plus, recherchez toute participation à des benchmarks externes (comme des compétitions de prévision ou des études de cas publiques avec des chiffres concrets). La compétition M5 était un tel benchmark qui a séparé le bon grain de l’ivraie en matière de prévision - notamment, aucun des grands fournisseurs traditionnels n’a publié de résultats là-bas, alors qu’un acteur plus petit (Lokad) l’a fait et a excellé ⁶⁰. Cela vous indique qui a confiance en sa technologie.
Complexité de l’intégration : Si un fournisseur a grandi par acquisitions (Blue Yonder, ToolsGroup), méfiez-vous des promesses selon lesquelles “c’est maintenant une seule plateforme”. Souvent, il faut des années pour intégrer réellement. Pendant ce temps, vous pourriez utiliser efficacement des systèmes séparés avec certaines interfaces. Il peut y avoir des coûts cachés dans la mise en œuvre pour relier les choses. De plus, deux composants acquis peuvent ne pas partager la même notion de certaines données (par exemple, l’un utilise des compartiments hebdomadaires, l’autre quotidien, ou différentes définitions de hiérarchie de produits). Cela peut conduire à des compromis ou à un désalignement. Il est judicieux de parler à des clients de référence de leur expérience d’intégration des modules.
Structure des coûts : Évaluez non seulement les coûts de licence/d’abonnement du logiciel, mais aussi les coûts d’exécution (le cas échéant) et l’infrastructure requise. Comme nous l’avons noté, une solution qui repose sur quelque chose comme Snowflake peut vous faire supporter ces coûts d’exécution dans le cloud. Ou une solution qui est très gourmande en mémoire pourrait vous forcer à entrer dans des instances cloud de haut niveau. Un fournisseur pourrait citer des frais d’abonnement plus élevés mais inclure tous les calculs ; un autre pourrait être moins cher mais vous devrez payer une grosse facture AWS/Azure pour le calcul nécessaire. Assurez-vous de comparer le coût total de possession. Nous avons mentionné comment le modèle de Snowflake pourrait faire écho aux pièges des mainframes IBM - gardez un œil sur les frais basés sur l’utilisation et exigez la transparence des fournisseurs utilisant ce modèle.
Chaque fournisseur a des échecs : Il est important de se rappeler que aucun fournisseur ne mettra en avant ses projets échoués, mais ils en ont tous. La mise en œuvre est aussi importante que l’outil. Nous avons vu comment même les meilleurs fournisseurs comme SAP ou i2 (maintenant sous Blue Yonder) ont eu des échecs de plusieurs millions de dollars ³⁹ ³³. Souvent, les raisons sont des données médiocres, des attentes mal alignées, ou l’entreprise n’adoptant pas les sorties du système. Lors de l’évaluation, demandez aux fournisseurs comment ils gèrent les projets qui n’atteignent pas les objectifs. Ont-ils des exemples (anonymisés) de leçons apprises ? Blue Yonder a fait preuve d’humilité en reconnaissant les causes communes d’échec ²⁶. Un fournisseur qui dit “nous avons un taux de réussite de 100%” n’est pas réaliste. Insistez pour des discussions sur ce qui pourrait mal se passer et comment ils l’atténuent.
Contradictions entre temps réel et profondeur des analyses : Comme nous l’avons noté, certaines analyses (comme la planification de l’assortiment à l’échelle du réseau) ne peuvent pas être vraiment en temps réel - elles nécessitent un traitement substantiel des données et une délibération commerciale. Si un fournisseur prétend à la fois une “réactivité en temps réel” et une “optimisation holistique”, vous devez discerner quelles parties de leur solution correspondent à quelle promesse. Par exemple, ToolsGroup peut mettre à jour les positions des stocks en temps réel, mais son optimisation de base pourrait être exécutée quotidiennement. RELEX peut ingérer des données en quasi-temps réel mais la planification de certaines choses (comme l’optimisation des prix basée sur l’IA) pourrait encore être un processus par lots pendant la nuit. Comprenez le rythme de chaque partie de la solution par rapport à vos besoins commerciaux. Le temps réel est crucial pour l’exécution (comme la mise à jour des stocks disponibles pour promettre ou la tarification dynamique à la volée), mais pour les décisions stratégiques, la profondeur et la rigueur sont plus importantes que la vitesse.
Intervention humaine vs Autonomie : Tous les fournisseurs revendiquent un certain niveau d’autonomie, mais aussi qu’ils permettent une intervention humaine. C’est un spectre. La question clé : Le système par défaut fonctionne-t-il en mode non surveillé avec seulement des exceptions signalées, ou par défaut nécessite-t-il une révision de l’utilisateur pour chaque décision ? Pour de véritables gains d’efficacité, vous voulez le premier. Un signal d’alarme est si le fournisseur met l’accent sur le nombre de leviers et d’options de configuration que l’utilisateur a - cela peut signaler que l’outil pourrait avoir besoin de beaucoup de surveillance pour obtenir de bons résultats (ce qui contredit la promesse d’automatisation). Idéalement, l’outil devrait s’auto-régler ces leviers (comme Blue Yonder éliminant le besoin de profils saisonniers définis manuellement en utilisant le ML ³⁶). Faites confiance mais vérifiez : lors des démonstrations ou des essais, voyez combien de réglages manuels ont été nécessaires pour que les résultats de la démonstration soient bons.
Spécificités de l’IA/ML : Creusez les affirmations du fournisseur sur l’IA. Demandez : Utilisent-ils l’apprentissage automatique pour les prévisions ? Quels algorithmes (s’ils peuvent le dire) ? Utilisent-ils des bibliothèques open-source (si tout est propriétaire, parfois c’est un signe qu’ils n’ont pas suivi les dernières techniques ; toutes les principales solutions d’IA intègrent des open-source comme TensorFlow/PyTorch ou au moins des algorithmes bien connus). Si un fournisseur fait des gestes vagues à propos d’un “moteur d’IA propriétaire” mais ne peut pas l’expliquer en termes simples, soyez sceptique. À l’inverse, s’ils peuvent articuler par exemple “nous utilisons le gradient boosting pour les prévisions de base et un modèle d’apprentissage par renforcement pour la tarification”, cela montre un investissement concret dans la technologie. Vérifiez également si leur équipe a publié ou participé à des forums académiques ou industriels sur leurs méthodes - un signe de sérieux.

Enfin, nous soulignons une mentalité en quête de vérité : insistez sur les données et les résultats des essais plutôt que sur les promesses alléchantes. Si possible, faites un pilote ou une preuve de concept où chaque fournisseur se voit attribuer un sous-ensemble de vos données pour faire des prévisions ou optimiser, et évaluez les résultats quantitativement. Par exemple, donnez deux ans d’historique et laissez-les prévoir la troisième année (pour laquelle vous avez des données réelles) - voyez qui s’approche le plus ou qui identifie les modèles de demande délicats. Ou faites-les optimiser un scénario puis simulez les résultats en termes de coût/service en utilisant votre demande réelle pour valider. Peu de fournisseurs proposeront spontanément un concours, mais les bons le feront souvent parce qu’ils croient en leur science. Lokad, par exemple, s’engage souvent par le biais de projets pilotes. Blue Yonder et RELEX font parfois des phases de “découverte” qui ressemblent à des pilotes. Assurez-vous simplement d’avoir des critères de réussite clairs pour ceux-ci.

En fin de compte, le marché des logiciels d’optimisation du e-commerce ne manque pas de soi-disant “miracles de l’IA”, mais en appliquant un scepticisme profond et en exigeant des preuves d’ingénierie, on peut filtrer le bruit. Cette étude a révélé que Lokad est en tête en matière d’innovation technique et de concentration, RELEX en matière de fonctionnalité de vente au détail unifiée (avec un peu de battage publicitaire à surveiller), Blue Yonder en matière de largeur et d’expérience (au milieu d’une refonte technologique difficile), et ToolsGroup en matière de forces d’optimisation spécialisées (avec une intégration croissante). Chacun peut apporter des avantages significatifs - mais aucun n’est une panacée plug-and-play. La vérité est que l’optimisation réussie provient du bon outil et de la bonne stratégie de mise en œuvre. Avec les points de vue et les mises en garde énoncés ci-dessus, une entreprise de e-commerce peut aborder ces fournisseurs avec un regard clair et faire un choix basé sur des faits et un raisonnement solide, et non pas seulement sur l’attrait du marketing.