Logiciel d'optimisation du eCommerce, février 2025

Par Léon Levinas-Ménard

Dernière modification: 2 février 2025

Introduction

Le marché du logiciel d’optimisation du eCommerce est rempli d’affirmations audacieuses de magie pilotée par l’IA, mais un examen approfondi révèle que seuls quelques fournisseurs tiennent véritablement la promesse de l’optimisation conjointe des stocks, des prix et des assortiments grâce à une technologie de pointe. Dans cette étude, nous évaluons les solutions de premier plan pour le pure-play eCommerce (commerçants en ligne sans magasins physiques) et classons les fournisseurs les plus pertinents – y compris Lokad, RELEX Solutions, Blue Yonder et ToolsGroup – selon leurs mérites techniques et leurs écueils. Lokad se distingue comme un leader en raison de son approche unifiée et probabiliste ainsi que de son haut degré d’automatisation, tandis que RELEX et Blue Yonder offrent des suites complètes tempérées par la complexité des boîtes noires d’IA et des reliques héritées, respectivement. ToolsGroup fournit une optimisation de stocks éprouvée, fondée sur des mathématiques solides, mais fait face à des défis d’intégration en s’étendant dans la tarification et les assortiments. Tout au long, nous appliquons un regard profondément sceptique : en coupant à travers le blabla marketing, en examinant minutieusement les affirmations des fournisseurs à la lumière de preuves indépendantes, et en soulignant les mises en garde souvent non dites (par exemple, le manque d’optimisation holistique des décisions, ou la dépendance à des architectures coûteuses). L’objectif est une analyse technique portée par le récit qui place la vérité avant le battage médiatique, afin que les acteurs du eCommerce puissent comprendre qui fait réellement progresser l’état de l’art – et qui échoue.

Les critères d’excellence : optimisation conjointe et technologies avancées

Tout fournisseur peut se vanter de l’IA ou du big data, mais optimiser véritablement une entreprise de eCommerce nécessite de satisfaire à des critères techniques et fonctionnels d’excellence. Le premier est l’optimisation conjointe : la capacité d’optimiser simultanément les décisions concernant les niveaux de stocks, la tarification et l’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 influence la demande qui impacte les stocks, les changements d’assortiment affectent les deux, etc.). Une solution d’optimisation de eCommerce doit coordonner les trois ; par exemple, elle pourrait décider de réduire le stock d’un produit et de le déprécier plus rapidement si les prévisions révèlent des ventes lentes, ou d’augmenter les prix de certains articles pour éviter les ruptures de stocks. Les solutions qui optimisent les stocks tout en ignorant la tarification, ou vice versa, laissent de l’argent sur la table et sont, par conception, sous-optimales.

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

Prévision probabiliste : Plutôt que des prévisions de demande à point unique, utilisez des distributions de probabilité pour saisir l’incertitude de la demande. Cela est crucial pour le eCommerce avec ses schémas de demande volatils et sa “long tail” de SKU. Les outils traditionnels (par exemple, les anciens modules SAP ou Oracle) qui produisent un chiffre et un stock de sécurité se trompent souvent sur la variabilité réelle ¹ ². Les fournisseurs leaders mettent désormais l’accent sur des modèles probabilistes ou « stochastiques » qui quantifient l’éventail des résultats.
Optimisation économique : Les décisions doivent être guidées par des objectifs économiques (profit, coût, cibles de taux de service) et non simplement par des règles empiriques. Par exemple, un système véritablement optimisé prendra en compte les marges bénéficiaires et les coûts de détention des produits lors de la détermination des niveaux de stocks et des prix. Il priorisera les actions qui maximisent le profit attendu ou minimisent le coût total, plutôt que de viser aveuglément un taux de remplissage. Cela nécessite d’intégrer des paramètres de coût/revenu dans les algorithmes.
Scalabilité et rentabilité : Les données du eCommerce sont immenses (potentiellement des millions de SKU, des transactions quotidiennes, de multiples canaux). Le logiciel doit gérer des données à grande échelle sans coûts matériels exorbitants ni performances médiocres. Les architectures qui gardent 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é, des stockages de données sur disque et des algorithmes efficaces. Une solution nécessitant une gigantesque ferme de serveurs ou des plateformes coûteuses (comme un usage excessif du cloud de données de Snowflake) pourrait faire fondre le retour sur investissement. À 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 du fait que les produits influent sur la demande des uns et des autres. Par exemple, si deux produits sont des substituts proches, l’abandon de l’un transfèrera la demande à l’autre (un effet de cannibalisation). Pour gérer cela, il faut plus qu’une simple analyse OLAP ou des groupes de produits définis manuellement ; cela nécessite 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 pour chaque produit est indépendante, ce qui entraîne des erreurs tant en prévision qu’en planification d’assortiment. Un fournisseur de pointe devrait modéliser explicitement ces relations (par exemple, en utilisant le machine learning sur des données de transaction pour déduire les affinités entre produits).
Impacts du marketplace et de la concurrence : Les acteurs purement eCommerce sont souvent influencés par la dynamique des marketplaces – par exemple, la concurrence sur Amazon ou eBay, les vendeurs tiers, etc. Le logiciel d’optimisation devrait idéalement intégrer des signaux tels que la tarification des concurrents ou les ruptures de stocks sur les marketplaces. Peu y parviennent efficacement. 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 directement et via des marketplaces, le système devrait optimiser sur les différents 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 commerçant eCommerce peut disposer de plusieurs canaux en ligne (son propre site web, des marketplaces, voire des sites régionaux). Le moteur d’optimisation doit gérer de manière holistique la demande et les stocks multi-canal – en reconnaissant, par exemple, que les stocks sont partagés ou que les décisions de tarification sur un canal peuvent affecter un autre. La planification « de bout en bout » n’est pas qu’un mot à la mode ; cela signifie que le logiciel voit l’ensemble du processus (des fournisseurs aux clients, à travers tous les flux de vente).
Haut degré d’automatisation (« robotisation ») : La promesse ultime de ces systèmes est la prise de décision autonome. Théoriquement, ils devraient pouvoir fonctionner en mode autonome, en générant des commandes de réapprovisionnement, des mises à jour de prix, etc., sans que les utilisateurs aient à ajuster des commandes quotidiennement. En réalité, tous les fournisseurs permettent encore une configuration par l’utilisateur, mais nous privilégions ceux qui minimisent le besoin d’ajustements manuels. Méfiez-vous des solutions qui se vantent de leur automatisation tout en exposant des dizaines de réglages (paramètres, coefficients de pondération, règles) – cela constitue une contradiction interne. La véritable automatisation provient du fait de laisser les algorithmes trouver les réglages optimaux, et non de demander aux utilisateurs de recalibrer sans cesse. Les meilleurs systèmes utilisent des techniques comme les modèles auto-apprenants qui s’ajustent à l’arrivée de nouvelles données, de sorte qu’avec le temps, les décisions restent optimales sans intervention manuelle ⁵. Moins un utilisateur doit maintenir de réglages « drivers », plus l’automatisation est crédible.
Architecture robuste et économique : Nous avons abordé la rentabilité, mais cela mérite d’être noté explicitement : certaines solutions modernes ont adopté des entrepôts de données cloud (comme Snowflake) pour évoluer. Cela peut éliminer les tracas liés à l’infrastructure, mais introduit un modèle de coût basé sur l’utilisation. Si un outil de planification doit traiter d’énormes volumes de données sur une plateforme comme Snowflake, les coûts peuvent exploser (semblable à la tarification basée sur le MIPS d’IBM dans les années 1990, où une utilisation accrue du CPU entraînait des frais exponentiellement plus élevés). Une solution idéale gère les big data avec des algorithmes intelligents pour maintenir l’utilisation du cloud (et donc les coûts) à un niveau raisonnable ⁴. De même, les solutions construites par acquisitions peuvent se retrouver comme un patchwork de modules sur différentes piles technologiques, entraînant des coûts d’intégration élevés pour le client (en argent ou en latence système). Être cloud-native et intégré dès le départ est un avantage, mais seulement si l’architecture élimine véritablement les mouvements de données redondants sans introduire de nouveaux goulots d’étranglement.

Une fois ces critères établis, nous nous tournons vers les fournisseurs. Nous classons Lokad, RELEX, Blue Yonder et ToolsGroup comme les acteurs les plus pertinents pour l’optimisation du eCommerce, et nous évaluons chacun d’entre eux en fonction des critères précédemment mentionnés. L’analyse est narrative dans son style – se concentrant sur la manière dont chaque fournisseur aborde le problème et sur les points où le scepticisme est de mise – plutôt que sur une simple liste de fonctionnalités. Il est important de souligner que nous nous appuyons, autant que possible, sur des preuves crédibles (et des citations directes), évitant ainsi le piège courant de prendre les affirmations des fournisseurs pour argent comptant.

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

Lokad se distingue en tant que fournisseur explicitement fondé sur l’idée de l’optimisation conjointe en utilisant une technologie de pointe. Contrairement aux logiciels traditionnels de supply chain, Lokad ne se présente pas sous forme d’un ensemble de modules (prévisions, 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 qualifient de « Supply Chain Quantitative », peut nécessiter davantage de science des données dès le départ, mais elle offre 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 parvenir à 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 compromis économiques.

Au cœur se trouve la prévision probabiliste. Lokad a été l’un des premiers pionniers à utiliser des distributions complètes de probabilité pour la demande, et a même prouvé son savoir-faire dans l’arène neutre des compétitions de prévision. Dans la prestigieuse M5 Forecasting Competition (2020), une équipe de Lokad a obtenu la 6ème place mondiale sur 909 équipes ⁶ – une validation impressionnante de leur technologie, étant donné que la M5 se concentrait sur des données de vente au détail granulaires (le type de données auquel sont confrontées les entreprises eCommerce). Il est à noter que la M5 nécessitait des prévisions probabilistes (quantiles), ce qui correspond à l’expertise de Lokad. Ce résultat démontre non seulement une excellence académique mais également une pertinence pratique : leurs prévisions figuraient 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 seuil, les gains en précision des prévisions rapportent des rendements décroissants comparés à une meilleure modélisation des décisions ⁷. Autrement dit, Lokad insiste sur l’optimisation des décisions (quantités de commande, allocations, etc.) en utilisant les prévisions probabilistes, plutôt que de courir après une infime amélioration de la précision des prévisions qui pourrait ne pas affecter les résultats de manière significative. Cette approche est rafraîchissante et importante pour le eCommerce : elle reconnaît que la gestion de problèmes comme les ruptures de stocks, la demande intermittente et les effets de substitution importe souvent plus qu’une petite amélioration en pourcentage d’une métrique de prévision.

Techniquement, Lokad est à la pointe de la technologie et fortement orienté ingénierie. Ils ont construit leur propre pile technologique cloud-native (incluant un langage spécifique, personnalisé, appelé “Envision” pour écrire des scripts d’optimisation). Cette pile est conçue pour traiter de grandes quantités de données de manière efficace et économique. Par exemple, le système de Lokad traite routinièrement de quelques gigaoctets à des téraoctets de données clients (commandes, clics, etc.) en quelques heures pendant la nuit, afin de produire des décisions pour le lendemain ⁸ ³. Pour ce faire, ils évitent de charger tout en RAM ; à la place, ils utilisent des fichiers mappés en mémoire et un stockage en colonnes sur disque, permettant de gérer de manière transparente des ensembles de données supérieurs à la mémoire d’une machine en débordant vers des SSD rapides ³ ⁹. Ils notent explicitement que Envision (leur moteur) supporte des ensembles de données plus volumineux que la mémoire de l’ensemble du cluster en « déversant astucieusement sur des disques NVMe », et que des opérations embarrassant parallèles sont automatiquement distribuées entre les cœurs et machines ³. L’effet net : Lokad peut évoluer vers des assortiments de SKU extrêmement volumineux sans exiger que le client investisse dans des quantités absurdes de RAM ou des appareils spécialisés. En fait, ils mettent l’accent sur le fait de nécessiter peu de matériel pour fonctionner – évitant des situations où « cliquer sur un bouton d’exécution 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 vastes données mais à un coût élevé. L’approche de Lokad se rapproche d’un pipeline de big data optimisé, semblable à Apache Spark ou Google BigQuery, mais conçu spécifiquement pour les calculs de supply chain. Cet accent sur l’efficacité maintient la solution rentable à mesure qu’elle évolue – un énorme avantage pour les eTailers avec des millions d’enregistrements.

La gestion par Lokad de la tarification et des assortiments 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 le code, il est possible de modéliser les interactions. Par exemple, on peut écrire un script qui dit : « pour chaque produit, considérer la demande probabiliste à différents niveaux de prix, tenir compte de la disponibilité des stocks et du délai de réapprovisionnement, puis choisir le prix qui maximise la marge attendue moins le coût de détention, à condition d’éviter trop souvent une rupture de stock » – il s’agit d’une description simplifiée, mais elle illustre bien que la tarification et les stocks peuvent être déterminés ensemble. Si un produit est en surstock, le code pourrait décider d’un rabais pour accélérer les ventes ; s’il est rare, il pourrait augmenter le prix pour attribuer le stock aux clients payant le plus. Peu de fournisseurs permettent un tel 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 l’on fournit les bonnes données. Par exemple, on peut intégrer une donnée telle que « si l’article A n’est pas disponible, quelle part de sa demande se tourne vers l’article B » – de telles relations peuvent être apprises à partir des données historiques (en analysant les ruptures de stock passées ou les changements d’assortiment) puis intégrées dans l’optimisation. Comme Envision est un langage de programmation complet, ces dynamiques complexes de la demande peuvent être codées. La documentation de Lokad indique qu’ils le font activement : le système « dévoile les corrélations entre les produits, les canaux et les périodes » et calcule les décisions en conséquence, plutôt que de supposer que chaque SKU est indépendant ¹⁰. Il ne repose pas sur une extrapolation simpliste des séries temporelles ; il calcule des distributions complètes de probabilité pour la demande qui tiennent compte des promotions, des ruptures de stock, des décalages saisonniers, etc. ¹¹. En capturant ces facteurs (y compris lorsque la demande a été perdue en raison d’une rupture de stock), Lokad évite le problème classique du garbage-in que l’on rencontre avec la prévision sur des données de vente biaisées.

Un autre domaine dans lequel Lokad excelle est veille concurrentielle et intégration de données externes. La plateforme peut ingérer toute donnée pertinente – par exemple des prix concurrents, le trafic web, voire des calendriers de campagnes marketing – en tant que signaux d’entrée supplémentaires. Ils mentionnent explicitement la capacité d’intégrer « des signaux externes tels que la tarification des concurrents » et des calendriers marketing, et d’expérimenter facilement de nouveaux algorithmes ou signaux d’entrée grâce à la conception programmatique ¹². Dans un sens pratique, si une entreprise de e-commerce dispose, par exemple, de données extraites concernant les prix des concurrents ou sait que le niveau de stock d’un partenaire de marketplace est un indicateur, elle peut l’intégrer dans le modèle de Lokad pour affiner les décisions. C’est bien plus flexible que la plupart des solutions préconfigurées qui ne gèrent peut-être que les données internes. Cela reflète une approche « boîte de verre » : plutôt que de masquer la logique, Lokad vous permet de la personnaliser. Cela dit, l’approche de Lokad requiert un Supply Chain Scientist pour la configuration – ce n’est pas une interface point-and-click pour un novice. Cela peut être perçu comme un inconvénient pour certains ; cependant, le résultat est une solution qui correspond exactement aux spécificités de l’entreprise et peut véritablement automatiser les décisions en fonction des règles uniques de l’entreprise.

Automatisation et autonomie : Lokad est sans doute le planificateur supply chain le plus robotisé de ce groupe. La philosophie est qu’une fois les scripts (la logique) mis en place et validés, le système peut fonctionner quotidiennement (ou en intra-journée) et produire des décisions recommandées sans intervention humaine. De nombreux utilisateurs de Lokad lui font entièrement confiance pour produire des bons de commande et des suggestions de tarification que les planificateurs revoient brièvement, voire exécutent automatiquement. Parce que le système est auto-adaptatif (il réentraîne les prévisions chaque jour avec les données les plus récentes et réoptimise en conséquence), il ne nécessite pas d’ajustement manuel des paramètres. En fait, Lokad critique de manière assez incisive l’habitude de réglages sans fin dans l’industrie – ils soulignent que leur système « ne repose pas sur des méthodes simplistes des séries temporelles » et fonctionne sans réglages manuels constants de la part des utilisateurs ¹⁰. La lourde tâche d’ajustement pour la saisonnalité, les événements et la demande erratique est effectuée par les algorithmes, et non par des planificateurs modifiant les prévisions. Un aspect clé est l’actionnabilité : Lokad fournit des décisions (ou des recommandations actionnables) plutôt que de simples diagnostics. Par exemple, au lieu de simplement signaler qu’un certain article pourrait être en rupture de stock (comme le font certains tableaux de bord « control tower »), il recommandera directement une quantité de commande ou un changement de tarification pour y remédier. Il vise à « recommander des actions correctives plutôt que de simplement afficher une alerte », ce qui est crucial si vous souhaitez une opération autonome ¹³. Dans un environnement e-commerce rapide, un système qui se contente de vous signaler qu’il y a un problème ne suffit pas – vous voulez qu’il vous dise quoi faire à ce sujet, voire qu’il le fasse. Lokad est conçu pour faire cela.

Compte tenu de ces éloges, où devrait-on demeurer sceptique à l’égard de Lokad ? La principale mise en garde est que l’approche de Lokad est hautement personnalisée et technique. Ce n’est pas un SaaS plug-and-play où il suffit de l’activer pour voir immédiatement une interface conviviale 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 existe également une dépendance implicite à l’égard de l’équipe de Lokad (« Supply Chain Scientists ») notamment lors de la configuration initiale – en effet, ils agissent comme une extension de votre équipe pour mettre en œuvre la solution. C’est un modèle différent de, par exemple, l’installation d’un logiciel bien défini. Si un client n’est pas prêt à s’engager dans ce processus collaboratif et intensif en ingénierie, il pourrait rencontrer des difficultés. Cependant, ce modèle est aussi ce qui permet une profondeur d’optimisation. C’est un compromis classique : flexibilité et puissance contre facilité d’utilisation. Lokad optimise clairement en faveur de la puissance et de la flexibilité.

Du point de vue des marketplaces, 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, sur-stocks, pics de demande volatils lors de promotions ou d’effets d’influence, etc. – et elles recourent souvent à l’assemblage d’outils (tableaux de bord BI, scripts Python ad hoc, etc.) pour combler les lacunes laissées par leur ERP ou WMS. Lokad se positionne essentiellement comme la couche spécialisée qui intègre tous ces signaux et fournit un plan quasi-optimal. Ils se distinguent explicitement des outils simplistes proposés par les marketplaces ou ERP, notant que ceux-ci « ne couvrent qu’une fraction » de ce à quoi les entreprises de e-commerce sont confrontées ¹⁴ ¹⁵. Par exemple, une marketplace Amazon pourrait vous fournir une prévision de la demande pour la semaine prochaine – mais elle n’intégrera pas vos coûts de supply chain ni vos stocks multi-entrepôt. La technologie de Lokad est conçue pour gérer chaque signal pertinent jusqu’au niveau SKU, sans dysfonctionner, et sans que les utilisateurs aient à jongler manuellement avec des feuilles de calcul ¹⁶. C’est une proposition de valeur solide si elle est effectivement livrée comme annoncé.

Pour résumer Lokad : Il se classe en tête de notre liste grâce à sa capacité d’optimisation holistique et à sa technologie avancée. Il répond directement au critère d’optimisation conjointe – les stocks, la tarification et bien plus peuvent être optimisés simultanément via sa plateforme programmatique. Il exploite la prévision probabiliste et les moteurs économiques (ils effectuaient des prévisions par quantiles avant que cela ne devienne tendance, comme en témoigne leur succès à la compétition M5 ⁶) et n’hésite pas à aborder des effets complexes tels que la substitution ou les corrélations multi-canaux. Son architecture est scalable et économe, évitant le piège du calcul en mémoire par force brute ³ ⁴. L’automatisation est très élevée, avec un ajustement manuel minimal requis et un accent mis sur la production de décisions, et non simplement sur des insights ¹³. Le scepticisme que l’on pourrait appliquer à Lokad porte moins sur le fonctionnement de la technologie – les preuves suggèrent qu’elle fonctionne – que sur la capacité d’une organisation à adopter une solution aussi axée sur la data science. Il y a également la question de l’expérience à grande échelle ; Lokad est plus petit que certains concurrents, bien qu’il compte des clients remarquables (par exemple, des distributeurs industriels de pièces de rechange, des eTailers de mode, etc., selon leurs études de cas). Compte tenu de tout ce qui précède, Lokad obtient la première place en tant que fournisseur d’optimisation e-commerce véritablement à la pointe de la technologie dans notre étude.

2. RELEX Solutions – Optimisation Retail Propulsée par l’IA (avec réserves)

RELEX Solutions est un fournisseur d’origine finlandaise qui s’est rapidement imposé dans le domaine de la planification retail, souvent mentionné aux côtés des géants hérités en matière de prévision et de 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 réside dans le grocery et le retail (y compris les magasins physiques), mais ils ciblent également activement les acteurs du e-commerce, en mettant en avant leur capacité à planifier à travers des canaux en ligne et hors ligne. Pour les utilisateurs purement e-commerce, la valeur de RELEX réside dans sa planification end-to-end – assurant les bons stocks au bon endroit, au bon prix et avec les promotions adéquates, en utilisant des algorithmes avancés pour réagir aux changements de demande.

RELEX fait largement la promotion de 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 pilotés par l’IA traitent des centaines de facteurs influençant la demande » afin d’améliorer la précision des prévisions ¹⁷. Il souligne même que des données telles que la météo ne représentent pas un seul 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 capter des signaux prédictifs (météo, promotions, jours fériés, tendances sur les réseaux sociaux, etc.) et utiliser le ML pour les corréler aux ventes. L’avantage est que le système peut détecter des schémas complexes (par exemple, comment une vague de chaleur soudaine affecte la demande pour certaines boissons en combinaison avec le fait que ce soit un week-end prolongé). Cependant, le point de vue sceptique est que vanter « des centaines de facteurs » pourrait relever davantage du marketing que d’une amélioration significative. Dans la prévision, au-delà d’un certain point, l’ajout de nouvelles entrées produit des rendements décroissants, voire peut dégrader la précision si le modèle surajuste le bruit. Cela fait également du modèle une boîte noire – il est pratiquement impossible pour un humain de comprendre un modèle qui utilise réellement des centaines de variables. RELEX tente de contrer la problématique de la boîte noire en préconisant une approche « boîte de verre » (la transparence dans l’IA). Ils ont évoqué la fourniture de visibilité sur les prévisions et pas uniquement sur le résultat, permettant ainsi aux planificateurs de voir les moteurs clés. Mais en réalité, un réseau de neurones ou un modèle de gradient boosting avec des centaines de features ne sera pas entièrement interprétable. Les planificateurs devront faire confiance au système. C’est un compromis général avec l’IA/ML : RELEX est du côté de « balancer beaucoup de données sur le problème et laisser les algorithmes en déduire la solution ».

Est-ce que cela donne des résultats ? Les clients de RELEX rapportent souvent une amélioration des prévisions et moins de ruptures de stock, surtout dans des situations promotionnelles et saisonnières où les méthodes traditionnelles peinaient. Par exemple, RELEX intègre les prévisions météorologiques et a revendiqué jusqu’à une réduction de 75 % de l’erreur de prévision pour certains produits sensibles aux conditions météorologiques lors de périodes de météo inhabituelle ¹⁹. Nous prenons de telles affirmations spécifiques avec des pincettes – elles pourraient être choisies au gré des circonstances. Néanmoins, l’approche de RELEX apporte probablement une valeur ajoutée dans la prévision à court terme (« demand sensing ») en ajustant les prévisions en fonction des informations les plus récentes. En essence, leurs modèles de machine learning ajustent en continu la prévision de base avec de nouveaux signaux de données. C’est similaire à ce que certains appellent le demand sensing (utiliser des données quasi en temps réel pour mettre à jour les prévisions à court terme). Dans ses documents, RELEX intègre le demand sensing dans sa prévision globale par ML plutôt que de le traiter comme un module séparé. Ils prônent le « re-forecasting continu et automatisé » à mesure que les situations évoluent.

Du côté de l’optimisation conjointe, dans quelle mesure RELEX couvre-t-il la tarification et l’assortiment en plus des stocks ? Historiquement, RELEX était le plus fort en réapprovisionnement et en allocation (pour garantir que les magasins ou centres de distribution ne soient pas à court). La planification de l’assortiment (décider quels produits aller dans quels magasins ou quels SKUs proposer) faisait également partie de leur offre, tout comme l’optimisation des planogrammes (l’aménagement de l’espace). L’optimisation des prix était une lacune 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 intégrée à 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 que le système pourra recommander la profondeur de remise, le moment optimal, etc., puis les implications sur les stocks sont automatiquement prises en compte. Cela s’oriente certainement vers une optimisation conjointe. Cependant, il n’est pas clair si RELEX optimise vraiment la tarification et les stocks ensemble ou s’il le fait toujours de manière séquentielle (d’abord décider du prix, puis ajuster le flux de stocks). Dans une optimisation conjointe idéale, on tiendrait compte des contraintes de stocks 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 interfonctionnelle – par exemple, son système pourrait remarquer « nous n’avons pas assez de stock dans le DC pour soutenir cette promotion dans tous les magasins » et pourrait le signaler ou l’ajuster. Ils mentionnent l’alignement de la tarification et des promotions avec la supply chain pour garantir que les plans soient exécutables ²². Ainsi, RELEX est conscient de la nécessité de briser les silos.

Une perspective d’initié : l’attrait de RELEX réside dans le fait qu’il regroupe tout (demande, supply, opérations) sur une seule plateforme pour l’utilisateur. Par exemple, les merchandise planners peuvent voir des prévisions et contraintes partagées entre les départements ²². Cela signifie qu’un planificateur peut comprendre l’impact qu’une décision de tarification aura sur la supply chain et inversement. Cette visibilité constitue une nette amélioration par rapport aux outils cloisonnés. Mais la visibilité n’est pas synonyme d’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 reste probablement séquentielle. L’optimisation des prix pourrait fournir un prix idéal, auquel le module de stocks planifierait ensuite. La forte intégration garantit qu’ils ne se contredisent pas, mais cela ne résout pas nécessairement un problème d’optimisation unique visant à maximiser le profit en tenant compte des coûts de stocks simultanément. Réussir cela est complexe et peu de fournisseurs (sauf peut-être Lokad, comme mentionné) l’envisagent explicitement.

Du point de vue de l’architecture technologique, RELEX est assez avancé. Ils ont construit leur propre moteur de base de données en mémoire dès leurs débuts (une base de données colonnes optimisée pour les séries temporelles et les données hiérarchiques) qui leur a permis de calculer rapidement des prévisions pour des milliers de magasins x SKUs. De nombreuses études de cas mentionnent que RELEX a remplacé les feuilles de calcul et les systèmes hérités, et peut immédiatement gérer une granularité de données bien supérieure (par exemple, passer d’une planification hebdomadaire à quotidienne ou d’une planification uniforme à une planification spécifique à chaque magasin). Pour le e-commerce, cela signifie que RELEX peut probablement gérer des prévisions au niveau SKU pour une boutique en ligne mondiale sans problème. Ils disposent de déploiements cloud et peuvent monter en charge. Nous n’avons pas trouvé de plaintes spécifiques concernant le coût de la technologie de RELEX ; au contraire, ils se targuent d’une computation efficace (leurs fondateurs universitaires ont largement optimisé les algorithmes). L’une des choses qu’ils possèdent est un concept de « Live database » en mémoire, qui, s’il est mal configuré, pourrait nécessiter beaucoup de RAM – mais cela reste spéculatif. En général, la scalabilité de RELEX n’a pas constitué un signal d’alarme sur le marché ; ils desservent d’immenses chaînes de supermarchés avec des dizaines de milliers de SKUs et de nombreux magasins, ce qui représente un volume de données analogue ou supérieur à celui de nombreux e-tailers.

Automation 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 éliminant le planificateur. En fait, ils mettent l’accent sur l’ergonomie – par exemple, leur UI, des tableaux de bord configurables et la gestion des exceptions. Le système générera automatiquement des commandes d’achat ou des recommandations de transfert, mais typiquement un planificateur les revoit et les approuve (surtout aux premiers stades d’adoption). RELEX dispose d’un concept d’“exceptions de prévision” où, si la prévision par IA s’écarte trop en raison d’une anomalie, elle le signale. Ils offrent également une capacité de simulation où les planificateurs peuvent voir pourquoi le système suggère quelque chose (du moins en termes généraux, comme “parce qu’il faisait très chaud, nous prévoyons une augmentation de +50%”). Mikko Kärkkäinen a déclaré : “les solutions de premier ordre tirent parti d’une IA pragmatique et de la puissance de calcul pour optimiser les tâches… de manière autonome sans intervention humaine” ²³, et il décrit aussi “la planification au détail autonome qui s’auto-apprend et s’auto-ajuste pour briser les silos” ⁵. Ainsi, du moins en vision, RELEX vise un système largement autonome. Nous restons légèrement sceptiques quant à une autonomie totale ici : les grands détaillants utilisant RELEX disposent quand même d’équipes de planification. Mais ces équipes gèrent probablement désormais par exception, ce qui constitue une forme d’autonomie partielle.

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

Problèmes ou préoccupations connus : Il n’existe pas de cas de “défaillance” publiquement documentés pour RELEX comme il y en a pour certains (pas de gros titres de procès). L’entreprise bénéficie généralement d’une image positive. Cependant, des discussions anonymisées d’initiés mentionnent parfois que la mise en œuvre de RELEX dans des environnements très grands et complexes peut révéler des problèmes. Par exemple, l’intégration des données peut être difficile (garbage in, garbage out – si les données du client sont en désordre, RELEX pourrait générer de mauvais plans, et la faute revient soit à l’outil, soit aux données). De plus, la croissance agressive de RELEX (ils ont intégré de nombreux clients rapidement) signifie que certains clients pourraient ne pas bénéficier du même accompagnement que, par exemple, celui proposé par Lokad. Ce n’est pas une critique du logiciel en soi, mais des résultats concrets : combien de projets RELEX atteignent les KPI promis ? Les fournisseurs aiment citer des améliorations dans le meilleur des cas (“X% de réduction des stocks chez le client Y !”), mais mentionnent rarement des cas où les chiffres ne se matérialisaient pas. Nous soupçonnons que RELEX, comme tous les fournisseurs, a eu quelques projets qui n’ont pas répondu aux attentes, peut-être en raison d’une mauvaise gestion du changement ou du manque de confiance du détaillant dans le système pour agir en conséquence. Lors d’un sommet partenaires, même Blue Yonder a admis que la gestion inefficace du changement et les problèmes de données sont à l’origine de la plupart des échecs de projets ²⁶ – il en va probablement de même pour les implémentations de RELEX.

Un autre aspect noté : RELEX tend à intégrer beaucoup de données externes, incluant des sources telles que Google Trends, des données de localisation mobile pour les prévisions d’affluence, etc. Pour un acteur eCommerce, certaines de ces données (comme l’affluence) sont sans intérêt, mais d’autres (météo, tendances) le sont. On peut se demander : ai-je vraiment besoin de tous ces flux de données ? Pour certaines entreprises en ligne, des modèles simples à partir de l’historique des ventes pourraient être presque aussi efficaces. RELEX vendra certainement l’idée que plus de données produisent de meilleures prévisions. Les résultats du concours M5 (auquel RELEX n’a pas participé publiquement, à notre connaissance) ont montré que des modèles sophistiqués battaient en effet des modèles plus simples, mais souvent avec des marges réduites. Les meilleures méthodes étaient souvent des ensembles composés de nombreux modèles, pas très différents de ce que RELEX pourrait utiliser en interne. Mais il est intéressant de noter qu’une approche pure de machine learning n’a pas catégoriquement écrasé les méthodes traditionnelles dans ces concours – une combinaison de modèles statistiques soigneusement ajustés avait tendance à l’emporter. Ainsi, si nous comparons les affirmations de RELEX à des références comme le concours M5 : nous voyons que la prévision probabiliste est effectivement précieuse (ce qu’ils font), mais nous constatons également qu’il n’existe pas de solution miracle unique parmi les meilleures approches – il s’agit d’une modélisation rigoureuse. En l’absence de publication par RELEX de leur précision sur des ensembles de données standard, nous restons prudents. 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 affirme “nous avons amélioré la précision des prévisions de 30%”, précisez “30% par rapport à quel indicateur et à quelle base de référence ?” De nombreuses fois, les fournisseurs mesurent l’amélioration par rapport à un scénario qui flatte leur outil (par exemple, comparé à des prévisions naïves ou à une mauvaise année). La recommandation de cette étude : exigez de la clarté sur les bases de référence pour toute affirmation de performance.

En résumé, RELEX Solutions se classe parmi les meilleurs fournisseurs car il aborde de manière intégrée les domaines clés (demande, stocks, tarification) et utilise largement des techniques modernes d’IA/ML. Ses points forts incluent une prévision très granulaire prenant en compte d’innombrables facteurs, de solides capacités de promotion et de planification saisonnière, et une plateforme unifiée offrant à toutes les parties prenantes une source unique de vérité. Il coche la case sur la scalabilité (prouvée dans le grand retail), sur la gestion de la cannibalisation (via des modèles de prévision avancés qui considèrent les effets croisés entre produits ²⁷), et sur le marketplace/omni-channel (le système peut planifier pour le online et le offline simultanément et probablement intégrer des données concurrentielles si fournies). RELEX mise également sur l’automatisation, avec des affirmations concernant des modèles auto-ajustants et des décisions autonomes, bien qu’en pratique un certain contrôle par l’utilisateur subsiste. Les principaux inconvénients 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 – ainsi que la nécessité de faire la part entre battage médiatique et réalité dans sa communication. Nous classons RELEX très haut mais avec une réserve : 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 “AI washing” dans l’industrie ; le message de RELEX figure parmi les plus crédibles (puisqu’ils possèdent une technologie réelle sous le capot), mais même les affirmations de Mikko au sujet de “centaines de facteurs” ¹⁷ devraient être vues comme un enthousiasme pour l’IA plutôt qu’une garantie de résultats radicalement meilleurs qu’un concurrent. Dans un contexte eCommerce, RELEX peut certainement faire le travail, il suffit de mesurer ses résultats de manière rigoureuse et de surveiller si toutes ces fonctionnalités sophistiquées sont réellement utilisées dans votre cas ou restent simplement inactives dans le logiciel.

3. Blue Yonder – Legacy Juggernaut Transforming (Claims vs. Reality)

Blue Yonder (anciennement connu sous le nom de JDA Software) est un géant des logiciels de supply chain, avec des décennies d’expérience dans les systèmes de planification pour le commerce de détail et la fabrication. Il propose une suite complète qui couvre la prévision, le réapprovisionnement, la gestion d’entrepôt, le transport, la gestion des effectifs et la tarification (après avoir acquis le spécialiste de la tarification Revionics en 2020). Pour les acteurs eCommerce, Blue Yonder offre des solutions initialement conçues pour de grands détaillants et des entreprises de biens de consommation – pensez-y comme au colosse de l’entreprise dans ce domaine. Toutefois, cet héritage comporte à la fois des forces (fonctionnalité robuste, scalabilité, expertise sectorielle) et d’importantes faiblesses (technologie obsolète dans certaines parties, problèmes d’intégration dus à de multiples acquisitions, et un historique incluant quelques échecs retentissants).

En termes d’optimisation conjointe, le parcours de Blue Yonder est quelque peu mitigé. Ils disposent effectivement des composants pour toutes les parties : par exemple, leur Luminate Demand Edge pour la prévision, Luminate Allocation/Replenishment pour les stocks, et Revionics pour la tarification. Sur le papier, vous pourriez utiliser les trois pour obtenir 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 tenir compte de l’élasticité de la demande (ce qui revient essentiellement à prévoir la demande à différents niveaux de prix). Blue Yonder commercialise assurément l’idée d’une solution de bout en bout, “de la planification à l’exécution” unifiée sous leur plateforme Luminate. En pratique, cependant, plusieurs de ces modules ont évolué séparément et n’ont été rassemblés que récemment. Le moteur d’optimisation des prix Revionics, par exemple, possède sa propre origine et a été intégré après acquisition. Le défi de Blue Yonder consiste à faire en sorte que cela donne l’impression d’une solution cohérente. L’entreprise a reconnu qu’historiquement, sa suite était fragmentée ; en conséquence, en 2023, elle a annoncé une transformation architecturale majeure : passer à un “modèle unique de données et plateforme applicative” sur le cloud Snowflake ²⁸. C’est une affaire de grande envergure – réingénierie de leurs produits pour qu’ils lisent/écrivent tous à 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’“supply chain operating system for the world” dans lequel toutes les applications BY partagent les données de manière fluide ²⁸.

Nous considérons cette vision à la fois prometteuse et problématique. Prometteuse, car si elle est réalisée, elle résoudrait en effet de nombreux casse-têtes d’intégration (fini les interfaces par lots entre la planification de la demande et la tarification, par exemple – ils consulteraient littéralement les mêmes données dans Snowflake). Problématique, car elle est extrêmement ambitieuse et risquée. Même le cabinet de conseil partenaire de Blue Yonder a noté, “Bien que visionnaire, nous pensons que supprimer complètement les intégrations pourrait être trop optimiste pour la plupart des clients.” ²⁹. Les clients ont des données à de nombreux endroits, tout ne sera pas parfaitement contenu dans Snowflake, il faudra donc encore des intégrations sur mesure pour les systèmes non-Blue Yonder ²⁹. En bref, la stratégie de Blue Yonder est un travail en cours – une réponse à son image de “legacy”. Ils ont explicitement déclaré qu’ils n’imposeraient pas des “cliff events” (abandon de l’ancienne technologie du jour au lendemain) mais qu’ils microserviciseront progressivement les modules hérités, permettant aux clients de migrer à leur propre rythme ³⁰ ³¹. Cela signifie qu’actuellement, un client de Blue Yonder pourrait encore utiliser, par exemple, l’ancienne planification de la demande JDA sur site, avec une intégration à Revionics dans le cloud. La plateforme entièrement unifiée pourrait être accessible dans quelques années pour une disponibilité générale. En attendant, l’optimisation conjointe est plus manuelle avec Blue Yonder : vous pourriez utiliser leurs outils en tandem, mais la coordination incombe souvent à l’utilisateur (par exemple, s’assurer que les actions de l’équipe de tarification sont intégrées dans le plan de stocks).

Blue Yonder coche de nombreuses cases technologiques sur le papier : ils intègrent désormais le machine learning dans la prévision (en tirant parti de la technologie de l’entreprise Blue Yonder GmbH qu’ils ont acquise en 2018, spécialisée dans l’IA pour le retail). Ils prétendent utiliser “explainable AI, machine learning, and even generative AI” dans diverses applications ³². Ils disposent certes d’algorithmes avancés pour des domaines tels que l’optimisation du réapprovisionnement, l’allocation, etc., développés au fil des décennies. Mais il faut rester sceptique, car Blue Yonder a également beaucoup de dette technique. Nombre 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.). Ainsi, lorsque Blue Yonder commercialise “cognitive, ML-driven planning”, il faut se demander : s’agit-il vraiment d’une nouvelle technologie ou simplement d’un nouveau positionnement marketing ? Par exemple, leur planification de la demande pourrait désormais utiliser le ML pour estimer l’augmentation des prévisions lors des jours fériés, ce qui est bien, mais l’architecture sous-jacente exploite-t-elle réellement la puissance informatique du cloud actuel, ou est-elle limitée par le fait d’être rétrofitée dans un système hérité ?

Un problème historique concret : Blue Yonder (JDA) a acquis i2 Technologies en 2010. i2 était réputée pour ses solutions axées sur l’optimisation, mais également connue pour ses implémentations ratées par moments. Notamment, après que JDA a racheté i2, Dillard’s (un grand grand magasin) a remporté un procès pour 246M$ alléguant que le logiciel d’i2 n’avait pas tenu ses promesses ³³ ³⁴. Ce fut un énorme revers – en substance, le logiciel et le projet ont échoué de manière si flagrante que le client a obtenu des dommages dépassant 30 fois ce qu’il avait payé pour le logiciel. Cette saga, bien que datant d’il y a 15 ans, souligne que même des fournisseurs très réputés peuvent connaître de sérieux ratés si la technologie promet trop ou n’est pas bien mise en œuvre. Blue Yonder a dû absorber ce coût et en tirer des leçons (on l’espère). Cela souligne pourquoi nous restons sceptiques : les grands fournisseurs peuvent vanter des “world-class products” mais des preuves existent qu’ils ne fonctionnent pas comme annoncé dans certains cas. Chaque fournisseur connaît des échecs ; Blue Yonder, au moins, en a eu un qui a été traîné devant les tribunaux.

À leur crédit, Blue Yonder est devenu plus transparent quant à la gestion des problèmes. Lors de leur sommet partenaires 2023, ils ont ouvertement abordé les “red projects” (implémentations en difficulté) et constaté que les principales causes n’étaient pas les algorithmes en soi, mais “ineffective change management and issues with data migration/integration” ²⁶. Ils ont noté que bien gérer les données et soutenir le client dans l’adaptation des processus étaient essentiels. Cette introspection est positive – cela montre que Blue Yonder n’ignore pas les raisons des échecs de projets. Cela rejoint également le thème de notre analyse globale : souvent, ce n’est pas que les mathématiques soient fausses, mais l’intégration dans le monde réel est difficile. Le fait que Blue Yonder identifie les défis de l’intégration des données est révélateur : cela reflète la complexité de leur suite. Car si leurs modules étaient véritablement intégrés de façon fluide, 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û procéder à une importante réconciliation des données pour exploiter pleinement la suite. La couche de données unifiée de Snowflake vise à remédier à cela, mais, comme dit, il est encore tôt.

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

Prévision de la demande: Blue Yonder Luminate Demand (surtout avec Demand Edge) utilise le machine learning pour intégrer de nombreux facteurs (météo, événements, tarification). Ils se sont également orientés vers des prévisions probabilistes ; au moins supportent-ils l’utilisation d’intervalles de confiance ou de quantiles dans la planification. Un exemple tiré de leur blog : ils n’utilisent pas l’IA pour superposer simplement des facteurs sur une base, mais pour reconstruire la prévision de zéro chaque jour en utilisant les données les plus récentes, tenant compte automatiquement de choses comme les décalages de calendrier, et s’auto-corrigeant à mesure que de nouveaux chiffres réels arrivent ³⁵ ³⁶. Ils affirment que cela élimine la nécessité pour les planificateurs de maintenir des ajustements manuels ou des profils pour la saisonnalité – le modèle les apprend et s’adapte ³⁶. Ceci est tout-à-fait en ligne avec les pratiques de prévision à la pointe de la technologie. L’approche de Blue Yonder ici est théoriquement solide : apprentissage continu, reconnaissance de l’incertitude (ils évoquent le risque de sur/sous-prévision et les compromis de coûts ³⁷), et utilisation du ML pour détecter des relations complexes (comme la manière dont des conditions météorologiques différentes ou des promotions stimulent la demande, sans qu’un humain ne code explicitement ces relations).
Stocks & Réapprovisionnement: Cela a longtemps été un point fort de JDA/Blue Yonder. Ils offrent une optimisation multi-échelons des stocks, c’est-à-dire qu’ils peuvent optimiser les niveaux de stocks dans les DC et centres d’exécution pour le eCommerce, en tenant compte des délais, 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 davantage basés sur des règles/heuristiques ou utilisaient la programmation linéaire pour des problèmes spécifiques. Ils sont probablement maintenant complétés par des prédictions basées sur le ML, mais l’optimisation de base est sans doute un mélange de recherche opérationnelle et de simulation. BY peut certainement gérer une planification de SKU à grande échelle ; de nombreux détaillants figurant au Fortune 500 utilisaient JDA pour le réapprovisionnement en magasin, ce qui est analogue, en termes d’échelle, à un grand entrepôt e-comm approvisionnant les clients.
Assortiment: Blue Yonder dispose d’outils de gestion de catégorie qui aident à décider des assortiments (quel mix de produits dans quels magasins). Pour un acteur purement eCommerce, la planification de l’assortiment pourrait signifier décider quels nouveaux produits mettre en ligne ou retirer. Les outils de BY peuvent utiliser des attributs et des données de performance pour évaluer les changements d’assortiment. Cependant, il s’agit typiquement d’un processus stratégique périodique, et non continu.
Optimisation de prix: Avec l’acquisition de Revionics, Blue Yonder a acquis un moteur robuste d’optimisation de prix largement utilisé dans le retail (notamment dans les chaînes d’épicerie et de marchandises générales) pour fixer les prix de base, les remises promotionnelles et les baisses de prix. Revionics utilise l’IA pour modéliser l’élasticité des prix et même les impacts de la tarification concurrentielle, puis recommande des ajustements de prix qui atteignent des objectifs tels que l’amélioration des marges ou la croissance du chiffre d’affaires, tout en tenant compte des règles de tarification (par exemple, terminer les prix par .99, etc.). Dans le cadre de Blue Yonder, Revionics est désormais connu sous le nom de Luminate Pricing. En théorie, ce moteur, combiné aux prévisions de demande de Blue Yonder, boucle le circuit – 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 propulsée par l’IA”, capable de fonctionner aussi souvent que nécessaire (même en intrajournée pour le e-commerce si désiré).

A big question: Dans quelle mesure ces éléments fonctionnent-ils réellement ensemble aujourd’hui ? Blue Yonder affirme que oui. Par exemple, ils pourraient dire que leur solution de tarification peut intégrer les prévisions de leur solution de demande et en extraire 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 sur mesure, le cycle pourrait ne pas être aussi serré qu’on l’espérait. Réalistiquement, un utilisateur eCommerce de Blue Yonder en 2023 pourrait utiliser l’outil de tarification séparément de l’outil de supply, peut-être avec des mises à jour par lots hebdomadaires de l’élasticité des prévisions. Il s’agit de planification conjointe, mais ce n’est pas le saint Graal de l’optimisation conjointe instantanée.

Concernant les revendications en IA/ML, Blue Yonder souffre parfois d’un excès de mots à la mode en marketing. Ils utilisent des termes comme “cognitif”, “piloté par le machine learning”, etc. Nous devrions vérifier s’il y a du concret. Il existe certaines 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é une compétition précoce de prévision retail en 2014 grâce aux réseaux de neurones). De plus, le portefeuille de brevets de Blue Yonder est important (plus de 400 brevets) ce qui indique beaucoup de R&D ³⁸. Cependant, la quantité de brevets n’égale pas la qualité du produit – cela montre simplement qu’ils ont essayé de nombreuses techniques. La perspective sceptique consiste à 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 présentent quelques-unes, mais souvent les études de cas des fournisseurs sont enjolivées et manquent de clarté sur la référence de base. Blue Yonder affirme des choses comme “un détaillant X a vu une augmentation des profits de Y% grâce à notre tarification” – mais sans contexte, cela reste du marketing.

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

D’un point de vue automatisation, Blue Yonder est aujourd’hui probablement moins automatisé que ne le visent Lokad ou RELEX. De nombreux clients BY utilisent les outils pour générer des recommandations que les planificateurs approuvent ou ajustent ensuite. Blue Yonder met en avant le concept de “supply chain autonome” (notamment depuis son acquisition par Panasonic en 2021, ils évoquent la connexion des données IoT à des décisions automatisées) ⁴¹. Mais il est prudent de dire qu’une grande partie de leur clientèle fonctionne encore en mode hybride : faisant confiance au système pour certaines décisions, et intervenant manuellement pour d’autres. Par exemple, un scénario courant est que le système suggère des commandes, mais un planificateur examine les exceptions (comme avec RELEX). Ou bien le système de tarification propose des ajustements, mais un responsable marchandisation les valide, en rejetant peut-être ceux qui ne correspondent pas à la stratégie de la 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 des données de prix concurrentiels – elle dispose d’une fonctionnalité de réponse concurrentielle et peut intégrer les prix des concurrents pour ajuster les vôtres ⁴². Ainsi, pour le eCommerce, si vous disposez d’un flux de tarification concurrentielle, Revionics peut l’inclure dans son optimisation (par exemple, ne pas fixer un prix supérieur à celui d’un concurrent de plus de X % afin de maintenir votre image de prix, ou égaler le prix le plus bas lorsque nécessaire). C’est un avantage dans l’optimisation conjointe des prix. Sur les marketplaces, Blue Yonder ne dispose pas spécifiquement d’un module de gestion de marketplace comme certains fournisseurs spécifiques au e-comm (tel que les outils de type channel advisor pour Amazon). On peut donc utiliser Blue Yonder pour la planification de base tout en nécessitant un outil séparé pour gérer les tactiques propres aux marketplaces (publicité, buy-box, etc.). Cela dépasse le cadre de Blue Yonder et n’est pas une critique à leur encontre, c’est juste une note indiquant que le eCommerce possède des facettes que ces fournisseurs traditionnels n’abordent pas (Lokad ou RELEX ne couvrent pas non plus les enchères publicitaires, pour être juste).

Étant donné l’ampleur et l’héritage de Blue Yonder, il faut également scruter les contradictions internes dans leur communication. Par exemple, Blue Yonder pourrait vanter une “personnalisation et tarification en temps réel” sur leur plateforme de commerce, alors que leurs solutions de planification fonctionnaient historiquement par cycles batch (planification nocturne, replans hebdomadaires, etc.). Ils se dirigent vers une utilisation plus en temps réel des données (leur partenariat avec Snowflake vise en partie à permettre un partage quasi en temps réel). Mais si un fournisseur affirme “tarification dynamique en temps réel et optimisation des stocks”, demandez-vous : cela signifie-t-il que le système se recalculera continuellement, ou simplement qu’il peut répondre rapidement lorsqu’il est déclenché ? Et avez-vous vraiment besoin du temps réel pour les décisions d’assortiment ? Probablement pas – c’est plus stratégique. Ainsi, une oreille critique remarquera dès que le langage marketing devient incohérent. La communication globale de Blue Yonder tombe parfois dans le piège de promettre tout (de la stratégie à long terme à l’exécution instantanée). Il est judicieux de délimiter quelles fonctions sont véritablement en temps réel (par exemple, leur routage de transport pourrait réagir à une commande en quelques minutes) et lesquelles relèvent intrinsèquement du traitement batch (comme la planification d’assortiment qui est saisonnière).

Préoccupation concernant le coût de Snowflake : Nous devons souligner un point subtil mais important : le fait que Blue Yonder s’appuie sur Snowflake pourrait modifier le modèle de coût pour les clients. Au lieu des licences traditionnelles, les clients pourraient finir par payer pour l’utilisation du cloud (crédits Snowflake) en fonction du volume de données et de la fréquence des requêtes. Si les applications de Blue Yonder effectuent des calculs intensifs sur Snowflake, la facture du client pourrait grimper. C’est analogue à l’ancienne facturation IBM mainframe par MIPS – plus vous l’utilisez, plus vous payez, ce qui peut décourager une utilisation complète du système. Blue Yonder et Snowflake se sont probablement mis d’accord sur une tarification, mais l’utilisateur doit se méfier du “bill shock” si des scénarios de planification s’exécutent très souvent sur de grandes quantités de données. C’est une considération bien réelle car la planification de la supply chain peut être intensivement calculatoire (notamment lors de simulations de scénarios ou de calculs probabilistes). Un processus inefficace sur Snowflake pourrait consommer beaucoup de crédits. Blue Yonder a sans doute réfléchi à ce point (ils doivent faire en sorte que cela fonctionne commercialement), mais c’est quelque chose à prendre en compte. Un modèle de coût mal aligné avec la valeur commerciale (comme facturer en fonction des données traitées plutôt que du résultat) rappelle les écueils des époques précédentes.

En conclusion, Blue Yonder se positionne juste en dessous des solutions purement nouvelles en termes de concrétisation de la vision “next-gen”. Il dispose indéniablement d’une riche fonctionnalité et de nombreux déploiements réussis, mais d’un point de vue sceptique et technique, nous voyons une entreprise en transition. Ils essaient de se moderniser et, ce faisant, ils parlent beaucoup d’IA, d’intégration et d’automatisation. Pourtant, tant que cette transformation ne sera pas entièrement réalisée, les clients devraient se montrer prudents quant aux écarts entre les modules et à l’effort réel requis pour atteindre les résultats promis. L’outil de Blue Yonder peut certainement soutenir les opérations eCommerce (de nombreux grands détaillants avec une activité omni-channel utilisent également BY pour leur côté e-com), et son ampleur est inégalée (aucun des autres fournisseurs n’a une portée aussi étendue, incluant par exemple la logistique). Cependant, si une entreprise eCommerce n’a besoin que d’une optimisation de la demande et de la supply, Blue Yonder pourrait être trop lourd à moins qu’elle n’ait spécifiquement besoin de cette robustesse d’entreprise ou ne l’utilise déjà dans d’autres domaines. Notre étude sceptique trouve les allégations de Blue Yonder d’être à la pointe quelque peu douteuses jusqu’à preuve du contraire – la technologie a du pedigree, mais il leur incombe de montrer que leur logiciel vieux de plusieurs décennies est réellement devenu “AI-first” et unifié. À l’heure actuelle, nous conseillons de considérer Blue Yonder comme une option puissante mais encombrante, que vous choisissez si vous avez besoin d’une solution très étendue et disposez des ressources pour l’implémenter, et peut-être pas comme premier choix si l’agilité et un ROI rapide sont prioritaires.

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

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

Dans un contexte eCommerce, la force de ToolsGroup repose sur sa capacité à gérer un grand nombre de SKU avec une demande erratique, tout en produisant des cibles de stocks optimales. De nombreux e-tailers possèdent des articles de niche (“long tail”) qui se vendent rarement – les modèles probabilistes de ToolsGroup sont naturellement adaptés à la planification pour ces produits (en capturant la nature sporadique de la demande plutôt qu’en en faisant une moyenne incorrecte). Ils gèrent également les lancements de nouveaux produits, la saisonnalité et les promotions via leurs modèles de prévision qui intègrent le machine learning. Par exemple, ils peuvent utiliser des analogies (en trouvant l’historique d’un article similaire) ou une modélisation basée sur des attributs pour prévoir un nouveau SKU.

Alors que ToolsGroup se concentrait historiquement sur les stocks et la demande, ces dernières années, il a reconnu que la tarification, les promotions et l’assortiment sont des volets complémentaires qu’il n’offrait pas. Pour y remédier, ToolsGroup a acquis une entreprise appelée JustEnough en 2018/2019 (JustEnough fit plus tard partie de Mi9 Retail avant d’être vendue à ToolsGroup). Le logiciel de JustEnough couvrait la planification financière des marchandises, la planification de l’assortiment, l’allocation et l’optimisation des markdowns – en d’autres termes, des fonctions de merchandising retail incluant les réductions de prix. Grâce à cette acquisition, ToolsGroup a étendu son champ d’action de la pure supply chain à ce que l’on pourrait qualifier de planification retail. Ils commercialisent désormais une suite intégrée capable de prendre en charge tout, de la planification stratégique à l’exécution, en combinant les 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 anodin. ToolsGroup a travaillé à intégrer des modèles de données (ils mentionnent disposer « du même modèle de données pour la planification tactique et opérationnelle » afin de garantir une seule version de la vérité ⁴⁴). Ils ont même lancé quelque chose baptisé « Real-Time Retail » qui connecte le système de planification de JustEnough avec un Inventory Hub pour obtenir des flux de données quasi en temps réel ⁴⁵ ⁴⁶. L’idée est qu’au fur et à mesure que les ventes se réalisent (ou que les stocks se déplacent), ces événements circulent instantanément dans le système de planification, qui peut replanifier l’allocation ou le réapprovisionnement à la volée. Cela suggère que ToolsGroup cherche à permettre une planification plus dynamique et continue plutôt que des cycles fixes périodiques – un objectif similaire à celui d’autres fournisseurs modernes.

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

En supposant que ToolsGroup ait intégré efficacement JustEnough, un utilisateur de leur système pourrait, par exemple, planifier un assortment par magasin ou par canal en utilisant le module JustEnough, puis faire en sorte que cela alimente les objectifs de stocks dans SO99+, et également planifier le markdown pricing pour les produits en fin de vie à l’aide de leur optimisation. Cela couvre les aspects d’une optimisation conjointe – surtout si les prévisions de demande et les paramètres de stocks tiennent compte du calendrier de markdown prévu. Il s’agit toujours possiblement d’un processus séquentiel (d’abord décider des markdowns, puis observer le résultat sur les stocks) à moins qu’ils n’aient construit un modèle d’optimisation combiné (ce qui est peu probable sur une telle étendue). 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 se trouve dans la prévision probabiliste et l’optimisation du taux de service. Ils affirment depuis des années que les prévisions à chiffre unique 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 dépasse 120, etc. Ensuite, leur optimisation utilise cela pour décider des niveaux de stocks de manière à ce que, disons, dans 95 % des cas la demande puisse être satisfaite ⁴⁹ ⁵⁰. Cette approche gère intrinsèquement l’incertitude et même la cannibalisation dans une certaine mesure (surtout si vous utilisez leur modélisation pour des articles corrélés). Un aspect intéressant : ToolsGroup affirmait souvent que l’utilisation de la prévision probabiliste pouvait prolonger la durée de vie des systèmes ERP de planification hérités (comme SAP APO) en leur fournissant de meilleures informations ¹ ⁵¹. Cela souligne que l’atout différenciateur de ToolsGroup résidait principalement dans les mathématiques de la prévision et des stocks plutôt que dans une interface de planification tout-en-un.

Et qu’en est-il de l’automatisation et de la simplicité d’utilisation ? Selon certains utilisateurs, ToolsGroup était traditionnellement davantage un « moteur back-end » avec une interface quelque peu maladroite. Ils ont depuis amélioré l’interface (nouvelle UI web, etc.). Mais, plus important encore, ils mettent l’accent sur l’automatisation dans la planification. Leurs documents affirment, par exemple, « l’automatisation intégrée réduit la charge de travail de planification jusqu’à 90% » ⁵². Ils citent également souvent des clients obtenant une « réduction de 40-90% de la charge de travail des planificateurs » et une « réduction de 20-30% des stocks » après avoir utilisé ToolsGroup ⁵³ ⁵⁴. Ce sont des chiffres importants. L’affirmation concernant la réduction des stocks est plausible si une entreprise était très inefficace auparavant ou maintenait des tampons excessifs par manque de confiance dans les prévisions. La réduction de la charge de travail des planificateurs implique que le système automatise bien plus de tâches. Cela correspond à ce que nous attendons : un système probabiliste devrait réduire les interventions en situation de crise (puisque vous planifiez pour l’incertitude, moins de surprises se produisent, de sorte que les planificateurs n’ont pas à agir en urgence ni à réallouer manuellement les stocks à la dernière minute). Cependant, un sceptique noterait que la réduction de 90% de la charge de travail est probablement la limite supérieure (peut-être un cas où une entreprise est passée de 10 planificateurs à 1 après implémentation – possible mais atypique). Et 20-30% de réduction des stocks pourrait résulter du fait qu’initialement l’entreprise détenait beaucoup trop de stocks « au cas où ». Dans la supply chain, une fois optimisée, on observe souvent des réductions de 10-15% si la situation était modérément correcte auparavant. Nous soupçonnons donc que les plages annoncées par ToolsGroup ⁵³ représentent des scénarios optimaux. Il est instructif qu’ils les présentent sous forme de plages – cela implique que les résultats varient largement selon le client.

Un atout de ToolsGroup est la stabilité et la spécialisation ciblée. Ils pratiquent l’optimisation de supply chain depuis 30 ans (fondée en 1993). Ils ne sont pas aussi grands que Blue Yonder ni aussi tendance que RELEX, mais ils bénéficient d’une clientèle fidèle et d’une expertise approfondie dans le domaine. Pour une entreprise de eCommerce principalement concernée par la rentabilité des stocks – c’est-à-dire pour éviter trop de ruptures ou de surstocks – la solution de ToolsGroup est très mature. Leur optimisation multi-échelons pourrait particulièrement bénéficier aux e-tailers disposant de plusieurs centres de distribution ou à ceux qui stockent également dans des entrepôts 3PL, etc. Elle permettra de pousser les stocks là où ils sont le plus nécessaires tout en maintenant des tampons centraux réduits.

Cependant, le point faible de ToolsGroup était l’optimisation des prix. L’acquisition de JustEnough leur a apporté une optimisation des markdowns (pour décider des calendriers de remises lors des liquidations). Cela est utile pour le eCommerce avec des produits saisonniers ou de mode. Mais ils manquent encore d’une véritable optimisation de dynamic pricing comme celle proposée par Revionics/Blue Yonder ou certains fournisseurs spécialisés en tarification. L’optimisation des markdowns concerne les prix en fin de vie ou promotionnels. L’optimisation des prix au quotidien (pour la marge ou le positionnement concurrentiel) n’est pas un point fort reconnu de ToolsGroup. Ils peuvent disposer de capacités de base ou faire appel à des partenaires. Cela signifie que, si l’optimisation conjointe des prix et des stocks est une priorité, ToolsGroup pourrait ne pas être aussi performant que Blue Yonder ou RELEX, qui disposent de moteurs de tarification dédiés. ToolsGroup pourrait encore optimiser les stocks en supposant un prix donné, mais il ne vous indiquera pas le meilleur prix à fixer pour maximiser le profit (à l’exception des scénarios de liquidation en fin de vie). C’est une distinction importante : leur « optimisation » est principalement orientée vers l’offre (niveaux de stocks, réapprovisionnement) plutôt que vers la modulation de la demande (tarification, promotion) – malgré l’ajout de quelques outils de modulation de la demande via acquisition.

En termes de stack technologique, ToolsGroup propose désormais une option cloud SaaS et positionne même certaines de ses offres sous des noms branchés comme « Inventory Hub » et « Fulfill.io ». Cela montre qu’ils essaient de se moderniser et peut-être d’attirer un marché plus large, y compris des entreprises de eCommerce 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 limites de performance pour ToolsGroup ; ils ont des références de clients avec des millions de combinaisons SKU-location. Le talon d’Achille de ToolsGroup pourrait être le fait qu’il est perçu comme un « outil d’optimisation » – puissant mais nécessitant une configuration par des experts. Ils ont cherché à simplifier avec davantage de ML préconfiguré. Par exemple, ils intègrent le demand sensing (en utilisant des tendances à court terme pour ajuster les prévisions) et affirment utiliser le machine learning pour identifier quels facteurs influencent le plus la demande ⁵⁵. Ils ont également démystifié, dans leur blog, le mythe selon lequel les prévisions probabilistes ne peuvent pas être ajustées par les humains – précisant qu’elles peuvent intégrer du jugement, mais que les mathématiques tiendront compte historiquement des biais ⁵⁶. Cela reflète une approche équilibrée : ils n’excluent pas totalement l’humain, mais le guident avec de meilleures informations.

Effets de cannibalisation : Le modèle probabiliste de ToolsGroup peut, s’il est configuré, capturer la cannibalisation (par exemple, si vous renseignez une relation de substitution, il peut modéliser des scénarios où, si un article est en rupture, une partie de la demande se déplace vers un autre). Cependant, cela nécessite probablement un effort pour établir les relations ou pour utiliser leur ML afin de regrouper les articles. On ne sait pas à quel point cela est automatique. Mais ToolsGroup a bien insisté dans un blog de 2017 sur la gestion de « long tail, intermittent demand, and more channels », en précisant que ces conditions font défaillir les outils traditionnels et nécessitent des méthodes probabilistes ⁵⁷. Ils mentionnent spécifiquement « more channels to market, with aggregated demand coming from multiple streams » comme un scénario où les prévisions à chiffre unique font défaut, ce qui laisse entendre que leur solution gère mieux le multi-channel ⁵⁷. Ainsi, un e-tailer vendant sur son site web et sur Amazon, par exemple, pourrait utiliser ToolsGroup pour planifier une demande combinée. L’outil produirait une prévision globale et permettrait peut-être d’allouer les stocks par canal de manière optimale (bien que l’allocation par canal soit souvent plus simple lorsque tout est expédié depuis les mêmes centres de distribution, mais dans le cas de pools de stocks séparés, cela a son importance).

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’assortment sont-ils désormais réunis dans une seule interface ou donne-t-on l’impression de passer d’un système à l’autre ? Ils ont travaillé à unifier l’interface, mais des retours d’utilisateurs seraient nécessaires. Ce n’est probablement pas aussi unifié que la plateforme unique développée en interne par RELEX, présumément.

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

Pour résumer l’évaluation de ToolsGroup : il est très performant dans sa niche d’origine (forecasting & stocks) – sans doute le meilleur dans l’optimisation probabiliste des stocks – et s’élargit pour couvrir la tarification et l’assortment, bien que ces nouvelles capacités ne rivalisent peut-être pas encore avec des concurrents spécialisés. ToolsGroup répond à de nombreux critères de pointe :

Prévisions probabilistes ? Oui, ils en ont fait la promotion ⁴⁹ ⁴³.
Optimisation économique ? Implicitement oui pour les stocks (ils optimisent le compromis entre service et coûts), bien que ce ne soit pas aussi explicite sur le plan du profit que chez Lokad. Il s’agit plutôt de « respecter le taux de service avec un minimum de stocks », ce qui est une forme d’optimisation des coûts.
Scalabilité ? Généralement oui, sans signaux d’alarme. Et leur approche est efficace (sans recours à la force brute).
Cannibalisation ? Probablement, via une modélisation avancée, mais ce n’est pas leur principal argument de vente.
Marketplace/compétitivité ? Pas intrinsèquement – cela serait géré en externe ou via des données d’entrée. ToolsGroup ne va pas scruter les prix des concurrents pour vous, ni quoi que ce soit de ce genre.
Automatisation ? Oui, élevée. Une fois configuré, de nombreuses tâches de planification peuvent être automatisées, le système émettant des propositions de commandes que les planificateurs n’ont plus qu’à approuver. Ils vantent d’importantes réductions de charge de travail et moins de biais humains.
Scepticisme quant aux affirmations du fournisseur : Le marketing de ToolsGroup est en réalité assez modéré par rapport à d’autres, hormis ces chiffres d’amélioration que nous avons déjà pris avec précaution. Ils se concentrent sur ce que la technologie accomplit (leurs blogs éducatifs sur la planification probabiliste sont substantiels, et non de simples fioritures). Mais ils se joignent désormais au battage médiatique autour de l’IA, en qualifiant tout « de AI-powered ». Nous notons toutefois qu’ils gardent un pied dans la recherche opérationnelle traditionnelle et un autre dans le ML, ce qui constitue un mélange équilibré.

Un point de donnée externe : Les évaluations des cabinets d’analyse (comme Gartner) placent souvent ToolsGroup en tête pour Supply Chain Planning, mais ils pourraient mentionner que la capacité de ToolsGroup est plus approfondie que large, et que l’UI était historiquement moins moderne. Cela est partiellement résolu maintenant (nouvelle UI, intégration).

Pour un eCommerce pure-player, la décision de se tourner vers ToolsGroup dépendrait probablement de savoir si l’optimisation des stocks est le principal point sensible et s’ils ont besoin d’une solution éprouvée, quelque peu autonome, pour cela. Si oui, ToolsGroup pourrait être un excellent choix, apportant des gains rapides en réduction de stocks et en amélioration du service. Cependant, si l’entreprise eCommerce cherche également à optimiser fortement la tarification ou à adopter des stratégies de markdown omnicanal à la pointe, ToolsGroup pourrait ne pas offrir autant de fonctionnalités qu’un Blue Yonder ou RELEX, ou encore qu’un outil de tarification dédié. Il pourrait être nécessaire de le coupler avec une autre solution de tarification, ce qui apporterait alors des défis d’intégration. (Fait intéressant, ToolsGroup pourrait ne pas s’y opposer – ils coexistaient historiquement avec d’autres, se concentrant sur les stocks tandis qu’un autre système se chargeait de la tarification.)

En conclusion, ToolsGroup se classe comme un fournisseur de suite, techniquement solide et spécialisé devenu multi-solutions. Nous apprécions sa rigueur ingénierique en matière de prévisions et son approche sans détour de l’incertitude (ils ont depuis longtemps réfuté le problème « les prévisions sont toujours fausses » en planifiant avec des probabilités). Nous restons prudents quant à leur expansion récente : si leurs modules retail nouvellement intégrés performent au même niveau que leur cœur de métier. La contradiction interne que nous observons est leur affirmation d’être désormais entièrement intégrés – si des failles apparaissent (comme le besoin d’exporter/importer manuellement des données entre les modules), cela minerait leur argumentaire. Mais, d’après les informations disponibles, ToolsGroup semble offrir une expérience plus unifiée après JustEnough. Ils s’alignent même sur la tendance de l’utilisation des données en temps réel dans la planification, ce qui est remarquable.

Enfin, tout comme nous l’avons fait avec d’autres : examen attentif des affirmations des fournisseurs pour ToolsGroup. Lorsqu’ils disent, par exemple, “90+% de disponibilité produit, 20-30% de stocks en moins, 40-90% de charge de travail réduite” ⁵³ ⁵⁴ – un scepticisme sain consiste à considérer ces résultats comme atteignables mais non garantis. Ces chiffres proviennent probablement de différents clients, chacun atteignant l’un de ces sommets, et non d’un seul client atteignant tous ces niveaux simultanément. Personne ne devrait s’attendre à ce que ses stocks chutent de 30% pendant que le service passe à >90% et que les planificateurs soient réduits de 90% d’un seul coup. La réalité implique habituellement des compromis et une amélioration progressive. La méthodologie de ToolsGroup peut incontestablement conduire à des améliorations significatives, mais nous conseillons de fixer des objectifs réalistes et de mesurer les progrès au fur et à mesure. La bonne nouvelle est que l’accent mis par ToolsGroup sur des résultats mesurables (service %, stocks $$) correspond à une approche axée sur la recherche de la vérité – il est très clair, en regardant ces indicateurs, si cela fonctionne ou non.

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

Chez ces fournisseurs, quelques thèmes communs entre battage médiatique et réalité ont émergé et qu’un décideur eCommerce devrait garder à l’esprit :

Méfiez-vous des mots à la mode : Des termes comme “AI-driven, cognitive, demand sensing, real-time, autonomous” sont lancés à tout-va. Assurez-vous qu’ils soient soutenus par des capacités concrètes. Par exemple, “demand sensing” sonne souvent bien – utiliser les ventes d’hier ou le bruit des réseaux sociaux pour ajuster la prévision d’aujourd’hui – mais en pratique, cela peut seulement ajuster légèrement les chiffres et correspond essentiellement à une prévision à court terme. Des experts de l’industrie ont qualifié le demand sensing de potentiellement “mootware” – quelque chose qui existe, mais n’apporte pas de valeur matérielle au-delà de ce qu’une bonne prévision offre déjà ⁵⁹. Ne vous laissez pas séduire par des concepts de “vaporware” sans preuves. Demandez au fournisseur : qu’est-ce que votre IA fait exactement que mon processus actuel ne peut pas, et pouvez-vous le prouver ? S’il dit “nous considérons 300 facteurs”, interrogez-le pour savoir si ces facteurs font réellement bouger les lignes ou s’ils se contentent de réaliser une belle diapositive.
Référence de base et repères : Établissez toujours une référence claire (par exemple, rotations de stocks de l’année dernière, taux de réalisation, marge brute) et vérifiez si le fournisseur accepte de mesurer l’amélioration par rapport à celle-ci. Beaucoup revendiquent des améliorations en pourcentage qui semblent énormes mais qui sont dénuées de sens sans contexte. Recherchez également toute participation à des repères externes (comme des compétitions de prévision ou des études de cas publiques avec des chiffres précis). La compétition M5 était un tel repère qui faisait la part des choses en matière de prévision – notamment, aucun des grands fournisseurs traditionnels n’y a communiqué de résultats, 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 “tout est désormais sur une seule plateforme”. Souvent, il faut des années pour une véritable intégration. Pendant ce temps, vous pourriez utiliser en pratique des systèmes séparés avec quelques interfaces. Il peut y avoir des coûts cachés lors de la mise en œuvre pour connecter le tout. De plus, deux composants acquis pourraient ne pas partager la même notion de certaines données (par exemple, l’un utilise des intervalles hebdomadaires, l’autre quotidiens, ou des définitions différentes de la hiérarchie des produits). Cela peut conduire à des compromis ou à un désalignement. Il est judicieux de s’entretenir avec des clients de référence sur leur expérience d’intégration de modules.
Structure de coûts : Évaluez non seulement les coûts de licence/abonnement du logiciel, mais aussi les coûts d’exécution (le cas échéant) et l’infrastructure requise. Comme mentionné, une solution s’appuyant sur quelque chose comme Snowflake peut vous répercuter ces frais d’exécution dans le cloud. Ou une solution très gourmande en mémoire pourrait vous obliger à opter pour des instances cloud de haut niveau. Un fournisseur pourrait proposer des frais d’abonnement plus élevés tout en incluant tous les calculs ; un autre pourrait être moins cher, mais vous devrez payer une grosse facture AWS/Azure pour l’informatique nécessaire. Assurez-vous de comparer le coût total de possession. Nous avons mentionné comment le modèle de Snowflake pouvait faire écho aux écueils des mainframes IBM – gardez un œil sur les frais basés sur l’utilisation et exigez de la transparence de la part des fournisseurs utilisant ce modèle.
Chaque fournisseur a des échecs : Il est important de se rappeler que aucun fournisseur ne mettra en avant ses projets ratés, mais ils en ont tous. La mise en œuvre est aussi importante que l’outil. Nous avons vu comment même des fournisseurs de premier plan comme SAP ou i2 (désormais sous Blue Yonder) ont connu des échecs de plusieurs millions de dollars ³⁹ ³³. Souvent, les raisons résident dans des données de mauvaise qualité, des attentes désalignées ou le refus de l’entreprise d’adopter les résultats du système. Lors de l’évaluation, demandez aux fournisseurs comment ils gèrent les projets qui n’atteignent pas leurs objectifs. Ont-ils des exemples (anonymisés) de leçons apprises ? Blue Yonder a fait preuve d’une certaine humilité en reconnaissant les causes communes d’échec ²⁶. Un fournisseur qui déclare “nous avons un taux de succès de 100%” n’est pas réaliste. Insistez pour engager des discussions sur ce qui pourrait mal tourner et comment ils y remédient.
Contradictions entre le temps réel et la profondeur analytique : Comme noté, certaines analyses (comme la planification de l’assortiment à l’échelle du réseau) ne peuvent pas être véritablement en temps réel – elles nécessitent un important traitement des données et des délibérations commerciales. Si un fournisseur revendique à la fois une “réactivité en temps réel” et une “optimisation holistique”, vous devez discerner quelles parties de sa solution correspondent à chacune de ces promesses. Par exemple, ToolsGroup peut mettre à jour les positions de stocks en temps réel, mais son optimisation centrale peut s’exécuter quotidiennement. RELEX peut ingérer des données en quasi-temps réel, mais la planification de certains éléments (comme l’optimisation des prix basée sur AI) pourrait rester un processus par batch durant la nuit. Comprenez la cadence de chaque partie de la solution en fonction des besoins de votre entreprise. Le temps réel est crucial pour l’exécution (comme la mise à jour des stocks disponibles à la promesse ou la tarification dynamique en direct), mais pour les décisions stratégiques, la profondeur et la rigueur priment sur la rapidité.
Intervention humaine vs autonomie : Tous les fournisseurs prétendent offrir un certain niveau d’autonomie, tout en permettant également une intervention humaine. C’est un spectre. La question clé : Le système fonctionne-t-il par défaut en mode non assisté avec uniquement les exceptions signalées, ou requiert-il par défaut un examen par l’utilisateur pour chaque décision ? Pour obtenir de réels gains d’efficacité, vous souhaitez la première option. Un signal d’alerte est si le fournisseur insiste sur le nombre de leviers et d’options de configuration dont dispose l’utilisateur – cela peut indiquer que l’outil nécessite beaucoup de supervision pour obtenir de bons résultats (ce qui contredit la promesse d’automatisation). Idéalement, l’outil devrait s’auto-ajuster ces leviers (comme Blue Yonder éliminant le besoin de définir manuellement des profils saisonniers grâce au ML ³⁶). Faites confiance, mais vérifiez : lors des démonstrations ou des essais, notez combien d’ajustements manuels étaient nécessaires pour que les résultats en démo soient convaincants.
Spécificités AI/ML : Approfondissez les revendications de l’IA du fournisseur. Demandez : Utilisent-ils le machine learning pour la prévision ? Quels algorithmes (s’ils peuvent le préciser) ? Recourent-ils à des bibliothèques open-source (si tout est propriétaire, cela peut être le signe qu’ils ne se sont pas mis à jour avec les dernières techniques ; toutes les solutions AI de pointe intègrent des outils open-source comme TensorFlow/PyTorch ou au moins des algorithmes reconnus) ? Si un fournisseur brandit un “moteur AI propriétaire” sans pouvoir l’expliquer en termes simples, soyez sceptique. Inversement, s’il peut préciser, par exemple, “nous utilisons le gradient boosting pour les prévisions de base et un modèle de reinforcement learning pour la tarification,” cela démontre un investissement concret dans la technologie. Vérifiez également si son équipe a publié ou participé à des forums académiques ou industriels sur ses méthodes – un signe de sérieux.

Enfin, nous soulignons l’importance d’un état d’esprit axé sur la recherche de la vérité : insistez sur les données et les résultats des essais plutôt que sur des promesses tape-à-l’œil. Si possible, réalisez un projet pilote ou une preuve de concept où chaque fournisseur reçoit un sous-ensemble de vos données pour prévoir ou optimiser, et évaluez les résultats de manière quantitative. Par exemple, fournissez deux ans d’historique et laissez-les prévoir la troisième année (pour laquelle vous disposez des chiffres réels) – voyez qui se rapproche le plus ou qui identifie les schémas de demande complexes. Ou demandez-leur d’optimiser un scénario puis de simuler les résultats en termes de coût/taux de service en utilisant votre demande réelle pour valider. Peu de fournisseurs proposeront spontanément un concours, mais les bons le feront souvent, car ils défendent leur science. Lokad, par exemple, s’engage souvent via des projets pilotes. Blue Yonder et RELEX effectuent parfois des phases de “discovery” ressemblant à des projets 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 eCommerce ne manque pas de “miracles AI” auto-proclamés, mais en appliquant un scepticisme profond et en exigeant des preuves techniques, il est possible de filtrer le bruit. Cette étude a révélé que Lokad se distingue par l’innovation technique et la concentration, RELEX par une fonctionnalité retail unifiée (avec un battage médiatique à surveiller), Blue Yonder par l’étendue et l’expérience (dans un contexte de refonte technologique difficile) et ToolsGroup par ses forces en optimisation spécialisée (avec une intégration en progression). Chacun peut offrir des avantages significatifs – pourtant, aucun n’est une panacée prête à l’emploi. La vérité est que l’optimisation réussie découle à la fois du bon outil et d’une stratégie d’implémentation appropriée. Grâce aux perspectives et points de mise en garde exposés ci-dessus, une entreprise eCommerce peut aborder ces fournisseurs en toute lucidité et faire un choix basé sur des faits et un raisonnement solide, et non simplement sur l’attrait marketing.