Logiciel d’optimisation du commerce de détail, février 2025

Par Léon Levinas-Ménard

Dernière modification: February 2nd, 2025

Introduction: Les détaillants d’aujourd’hui font face à des problèmes d’optimisation complexes couvrant les niveaux de stocks, les stratégies de tarification et les assortiments de produits. Un éventail de fournisseurs de logiciels promettent des solutions « pilotées par l’IA » pour relever ces défis, mais distinguer la véritable innovation technologique des systèmes hérités et du battage médiatique nécessite un examen minutieux. Cette étude évalue les principaux fournisseurs de logiciels d’optimisation du commerce de détail selon des critères rigoureux. Nous nous concentrons sur les capacités de joint optimization (optimisation conjointe des stocks, de la tarification et de l’assortiment), la prévision probabiliste (prévisions réelles d’IA/ML par rapport à des méthodes simplistes), la modélisation des décisions économiques (décisions basées sur le profit et le coût d’opportunité plutôt que sur des règles statiques), la scalabilité et l’efficacité en termes de coûts (capacité à gérer de vastes réseaux de commerce de détail sans exigences matérielles exorbitantes), la prise en compte de facteurs retail complexes (par exemple, cannibalisation de produits, effets de substitution, périssables/expiration), l’automatisation (niveau d’autonomie décisionnelle par rapport à l’intervention manuelle requise), l’intégration technologique (une pile technologique cohérente par opposition à des plateformes « Frankenstein » assemblées à partir d’acquisitions), et un regard sceptique sur les mots à la mode (« demand sensing », « plug-and-play », etc.). Chaque fournisseur est analysé avec une profondeur d’ingénierie, en utilisant des preuves crédibles et en limitant la dépendance au marketing des fournisseurs. Ci-dessous, nous classons les fournisseurs du plus avancé au moins avancé, en soulignant leurs forces, faiblesses et la vérité derrière leurs affirmations.

Critères d’évaluation des plateformes d’optimisation du commerce de détail

Avant de plonger dans les profils des fournisseurs, nous résumons les critères clés d’évaluation appliqués :

Joint Optimization (Inventory + Pricing + Assortment): La solution optimise-t-elle ces dimensions de manière holistique, en reconnaissant leur interdépendance ? Ou ces fonctions sont-elles compartimentées ? Les plateformes véritablement avancées considèrent la tarification, les stocks et l’assortiment comme des leviers intégrés d’un même problème d’optimisation, plutôt que comme des modules séparés ¹. Par exemple, modifier un prix devrait avoir un impact sur les prévisions de stocks et les décisions d’assortiment dans un modèle unifié.
Probabilistic Forecasting & AI: Le fournisseur utilise-t-il l’IA/apprentissage automatique moderne pour produire des prévisions probabilistes (des distributions de la demande plutôt que des prévisions ponctuelles) ? La prévision probabiliste est essentielle pour des décisions robustes en cas d’incertitude ². Nous recherchons des preuves de modèles d’apprentissage automatique, de réseaux neuronaux ou d’autres IA qui améliorent la précision des prévisions en apprenant des schémas complexes (saisonnalité, tendances, promotions, etc.) et en quantifiant l’incertitude. Les fournisseurs qui s’appuient encore sur des méthodes simplistes (comme l’ajustement manuel ou des formules de base) ou qui traitent les prévisions comme des points déterministes sont pénalisés.
Economic Decision-Making: Les décisions de la plateforme sont-elles guidées par des objectifs économiques (maximisation du profit, arbitrages entre coût du stock et coût du manque à gagner, retour sur investissement de l’espace de rayonnage, etc.) ? Optimiser le commerce de détail nécessite plus que d’atteindre des taux de remplissage – cela signifie maximiser le profit attendu en cas d’incertitude. Nous favorisons les solutions qui intègrent les marges, les coûts de détention, les coûts de réduction de prix et les coûts d’opportunité dans leurs algorithmes. Les heuristiques basées sur des règles ou des objectifs de taux de service peuvent être insuffisantes s’ils ignorent l’objectif ultime de rentabilité ³.
Scalability & Cost-Efficiency: Le logiciel peut-il traiter efficacement des données retail à l’échelle de l’entreprise (des milliers de magasins, des millions de SKU, des volumes de transactions élevés) ? Les solutions qui dépendent de calculs monolithiques en mémoire (par exemple, charger des ensembles de données entiers dans la RAM) peuvent rencontrer des difficultés à grande échelle ou nécessiter un matériel prohibitivement coûteux ⁴. Nous privilégions les architectures natives dans le cloud, les microservices et le calcul distribué qui permettent une montée en charge rentable, et nous pénalisons celles connues pour leurs coûts matériels élevés ou leur performance lente sur de grosses données.
Handling Complex Retail Factors: La demande réelle en commerce de détail est chaotique – cannibalisation de produits (la promotion d’un produit qui détourne les ventes d’un autre ⁵ ⁶), effets de substitution (lorsqu’un article est en rupture de stock, la demande pour un article similaire augmente), effets « halo » (des produits complémentaires se stimulant mutuellement ⁷), pics saisonniers, variations régionales et produits périssables avec dates d’expiration. Nous évaluons si les algorithmes de chaque fournisseur abordent explicitement ces complexités – par exemple, en utilisant l’apprentissage automatique pour identifier les relations entre produits ⁸ ⁹, ou en suivant les stocks par lots d’expiration. Les solutions qui supposent que la demande de chaque produit est indépendante ou qui ignorent la périssabilité sont moins adaptées pour le commerce moderne.
Automation & Unattended Operation: La promesse du « retail autonome » est que le système peut prendre la plupart des décisions opérationnelles (commandes, modifications de prix, réductions, changements d’assortiment) automatiquement, permettant aux humains de se concentrer sur les exceptions stratégiques. Nous évaluons si le logiciel permet une planification « sans intervention » – par exemple, des commandes de réapprovisionnement automatiques basées sur les prévisions, des ajustements de prix automatisés dans des limites définies – ou s’il s’appuie encore sur des planificateurs pour examiner et modifier constamment les décisions manuellement. Les fournisseurs vantant l’IA devraient idéalement réduire la charge de travail manuelle (« corvée de planification », pour reprendre l’expression ¹⁰), et non l’augmenter.
Technology Integration vs. Frankenstein Platforms: De nombreux grands fournisseurs se sont développés via des acquisitions, en ajoutant des outils de prévision, de tarification et de planification séparés sous une même marque. Nous examinons si la solution du fournisseur est une plateforme cohérente ou un assemblage de modules avec des interfaces et des modèles de données différents. L’intégration « Frankensoft » conduit souvent à une grande complexité et à des délais d’implémentation importants ¹¹. Les solutions véritablement modernes ont tendance à être construites sur une pile technologique unifiée ou du moins intégrées de manière fluide via des microservices. Nous pénalisons les fournisseurs pour lesquels les pièces ne s’assemblent pas complètement (malgré les affirmations marketing d’une plateforme « unifiée »).
Skepticism of Buzzwords & Hype: Le secteur de la technologie retail regorge de mots à la mode tels que « demand sensing », « intégration plug-and-play pilotée par l’IA », « supply chain cognitive », etc. Notre analyse élimine les affirmations vagues et recherche des éléments probants. Les fournisseurs qui s’appuient sur du jargon sans explications claires ou sans validation par des pairs sont considérés de manière critique. Par exemple, « demand sensing » est souvent cité comme une solution miracle, mais certains experts le qualifient de gadget marketing qui ne parvient pas à apporter une valeur nouvelle ¹². Nous dénonçons de tels cas et privilégions les fournisseurs qui offrent des preuves concrètes et crédibles de leurs capacités.

Avec ces critères en tête, examinons les principaux fournisseurs d’optimisation du commerce de détail et classons-les. Chaque section de fournisseur met en lumière leur performance sur chaque dimension, avec un regard particulièrement sceptique sur les revendications exagérées.

1. Lokad – Optimisation unifiée et probabiliste avec une IA sceptique

Lokad est un nouvel entrant (fondé en 2008) qui a construit sa plateforme dès le départ autour de la prévision probabiliste et de l’optimisation décisionnelle pour le commerce de détail et la supply chain. Contrairement à de nombreux concurrents, Lokad a explicitement cherché à unifier la tarification, les stocks et la planification de la demande en un seul système, plutôt que de les traiter comme des silos séparés ¹³ ¹⁴. Cette approche repose sur la compréhension que les décisions de tarification influent directement sur la demande et les besoins en stocks, et vice versa. Le fondateur de Lokad a noté qu’historiquement, la prévision et la tarification étaient gérées par des outils différents, mais en réalité « la demande et la tarification sont profondément interconnectées », ce qui a conduit Lokad à fusionner ces fonctions dans un cadre analytique unique ¹⁵ ¹⁶. Ils ont même développé leur propre langage de programmation spécifique au domaine (« Envision ») pour modéliser les décisions de la supply chain, permettant une optimisation hautement personnalisée qui peut englober la logique de la tarification, des stocks et de l’assortiment ¹⁷ ¹⁶.

Joint Optimization: La philosophie de Lokad est que l’on ne peut optimiser les stocks sans prendre en compte la stratégie de tarification, et vice versa. Ils ont intégré la tarification et la planification de la demande dans une seule plateforme – par exemple, leur système peut optimiser les quantités de réapprovisionnement tout en suggérant simultanément des ajustements de prix, garantissant que la tarification ne désynchronise pas la demande par rapport aux stocks ¹. Une étude de cas interne discute d’une stratégie de « tarification basée sur les stocks » où les prix sont ajustés dynamiquement en fonction des niveaux de stocks, coordonnant ainsi efficacement la tarification avec la disponibilité des stocks. En partageant les mêmes données (historique des ventes, informations sur les produits, etc.) pour les modèles de tarification et de prévision, Lokad évite les silos de données observés dans l’informatique retail traditionnelle ¹⁸ ¹⁶. Cette approche conjointe est à la pointe de la technologie, bien qu’elle nécessite que les détaillants adoptent la tarification algorithmique – un aspect important de la gestion du changement. La volonté de Lokad d’aborder conjointement la tarification et les stocks lui confère une capacité résolument tournée vers l’avenir que peu de fournisseurs hérités ont pu atteindre.

Probabilistic Forecasting & AI: Lokad est un fervent partisan de la prévision probabiliste. Sa plateforme produit des distributions complètes de probabilité de la demande (pour chaque article et chaque période) plutôt que des prévisions ponctuelles. Lokad soutient – et nous sommes d’accord – que « pour les supply chains, les prévisions probabilistes sont essentielles pour prendre des décisions robustes face à un avenir incertain », permettant d’optimiser les décisions sur la base des valeurs attendues et des risques ³. En capturant l’étendue des résultats possibles de la demande et leurs probabilités, les prévisions de Lokad soutiennent naturellement la prise de décision économique : « la perspective probabiliste se prête naturellement à la priorisation économique des décisions en fonction de leurs retours attendus mais incertains » ³. En pratique, cela signifie que Lokad peut évaluer, par exemple, la rentabilité attendue d’un réapprovisionnement supplémentaire d’un produit par rapport au risque de gaspillage, en utilisant la distribution complète de la demande. Techniquement, Lokad emploie des modèles d’apprentissage automatique de pointe (notamment la régression quantile et le deep learning) pour générer ces prévisions, et ils ont publié des preuves de l’utilisation de techniques telles que la programmation différentiable pour les séries temporelles. Étant donné que leur objectif est la précision de l’IA et la quantification de l’incertitude, ils évitent les métriques simplistes ; notamment, ils critiquent des mesures telles que le MAPE (Erreur Moyenne Absolue en Pourcentage) lorsqu’elles sont appliquées aux prévisions probabilistes, car elles sont conceptuellement invalides ¹⁹. Cela démontre une profondeur de compréhension de la prévision qui les distingue des fournisseurs qui apposent le terme « AI » sur des statistiques héritées. La technologie de prévision de Lokad est clairement à la pointe, bien qu’elle nécessite parfois une configuration experte à l’aide de leur langage de script.

Economic Decision Logic: L’ensemble du cadre de Lokad est construit autour de l’optimisation économique. Ils considèrent souvent les problèmes de supply chain comme une « maximisation du profit attendu » en situation d’incertitude, plutôt que de viser des taux de remplissage arbitraires ou de minimiser les ruptures de stock. Par exemple, leurs algorithmes prennent en compte de manière explicite les coûts d’opportunité des ruptures de stock, les coûts de détention et les coûts de réduction de prix lors de la recommandation d’achats de stocks ou de modifications de prix. Parce qu’ils génèrent des prévisions probabilistes, ils peuvent calculer la rentabilité attendue de chaque décision (par exemple, combien de profit est généré par l’ajout d’une unité supplémentaire par rapport à la probabilité qu’elle reste invendue). Cela va au-delà de nombreux outils qui comptent sur des objectifs de taux de service définis par l’utilisateur ; Lokad tente de calculer dynamiquement le taux de service optimal par article à partir des paramètres économiques. En somme, leurs décisions sont directement liées aux résultats financiers (par exemple, la maximisation de la contribution de marge attendue), en accord avec le critère de l’optimisation axée sur la rentabilité. Cette approche repose sur leur conviction que l’optimization de la supply chain ne consiste pas seulement à réduire les coûts, mais à allouer les ressources pour maximiser les retours. Une conséquence de cela est la capacité de faire des choses comme l’optimisation de prix combinée à la prévision de la demande – évitant ainsi l’écueil des outils de tarification qui ignorent les contraintes de stocks. Lokad avertit lui-même que « optimiser les prix isolément – indépendamment de la prévision de la demande – est une erreur » ²⁰ ²¹. En intégrant la tarification dans le cycle de prévision/optimisation, ils s’assurent que les calculs de profit reflètent la véritable réponse de la demande. Dans l’ensemble, l’orientation économique de Lokad est de premier ordre ; cependant, elle requiert une confiance dans l’algorithme. Les détaillants doivent être prêts à laisser un algorithme effectuer des compromis en matière de rentabilité que les planificateurs géraient manuellement, ce qui peut constituer un obstacle culturel.

Scalability & Architecture: Lokad propose sa solution sous forme de service cloud (souvent sur l’infrastructure Microsoft Azure). Plutôt que d’exiger que les clients exécutent des serveurs lourds en mémoire sur site, Lokad effectue les calculs sur son cluster cloud, évoluant en fonction des besoins. Ce modèle de calcul à la demande évite l’approche du « cube en mémoire hardwarré » que certains outils hérités utilisent, qui « fournit des rapports en temps réel impressionnants mais garantit des coûts matériels élevés » ²². En revanche, Lokad peut traiter de grandes quantités de données en répartissant la charge de travail dans le cloud, et les clients ne paient que pour le temps de calcul utilisé. C’est efficace en termes de coûts et évolutif – on peut ajouter des nœuds de calcul supplémentaires à un gros problème pendant quelques heures au lieu de dimensionner un serveur permanent pour les pics de charge. L’architecture de Lokad est orientée code (via des scripts Envision), ce qui signifie que les calculs complexes sont compilés et exécutés efficacement côté serveur, et non effectués dans une interface desktop maladroite. Ce design s’est avéré capable de gérer des ensembles de données retail assez volumineux (ils citent des clients avec des dizaines de millions de combinaisons SKU-localisation). Cependant, il convient de noter que Lokad est un fournisseur de plus petite taille, et que son évolutivité, bien que généralement solide, pourrait ne pas encore avoir été éprouvée sur les ensembles de données retail les plus importants (par exemple à l’échelle de Walmart) au même degré que SAP ou Oracle. Cela dit, leur approche cloud est fondamentalement plus évolutive que les systèmes hérités en mémoire sur site. L’efficacité en termes de coûts est également élevée : les utilisateurs ne sont pas contraints de souscrire à un matériel massif ou de payer pour un calcul inactif, puisque la tarification SaaS de Lokad est basée sur l’utilisation. En résumé, l’architecture cloud moderne de Lokad lui donne un avantage en termes d’évolutivité et de coût, à condition que les clients soient ouverts à un système moins traditionnel, axé sur le code.

Gestion des facteurs complexes du retail : Parce que la plateforme de Lokad est essentiellement un environnement de programmation flexible pour l’optimisation, elle peut être configurée pour gérer explicitement des phénomènes complexes du retail. Par exemple, les utilisateurs peuvent modéliser les interrelations entre produits (substituts ou compléments) dans leurs scripts Envision afin que les prévisions et les commandes tiennent compte de la cannibalisation ou des effets halo. Si le produit A et le produit B sont des substituts, le système de Lokad peut ingérer des données transactionnelles et apprendre que, lorsqu’A est en rupture de stock, les ventes de B augmentent, ajustant ainsi les prévisions en conséquence. Ce n’est pas nécessairement une fonctionnalité préconfigurée activée par une case à cocher – cela nécessite un travail de data science pour mettre en place le bon modèle – mais la capacité existe. De même, les effets de promotion peuvent être modélisés : Lokad peut utiliser des calendriers de promo comme entrées et même optimiser la tarification promotionnelle. Pour les produits périssables et les dates d’expiration, Lokad peut intégrer la durée de vie restante dans sa logique d’optimisation (par exemple, en augmentant la priorité de vendre les articles à l’approche de leur expiration grâce à des réductions de prix ou en évitant de surstocker des produits à courte durée de vie). La force principale est la flexibilité : contrairement aux systèmes hérités rigides, l’approche de Lokad peut encoder pratiquement toute contrainte ou facteur, à condition de disposer de données et d’expertise. L’inconvénient est qu’il se peut qu’il n’existe pas de « module de cannibalisation » préfabriqué – l’utilisateur (ou l’équipe de Lokad) doit implémenter la logique. Néanmoins, de nombreux fournisseurs ignorent tout simplement ces nuances. L’équipe de Lokad a elle-même publié sur des sujets tels que l’intégration de la cannibalisation dans les prévisions via le machine learning (par exemple, identifier des substituts via des corrélations de ventes), ce qui indique qu’ils sont conscients et capables de le traiter de manière similaire aux spécialistes du retail de premier plan ⁸ ⁹. En pratique, pour un détaillant aux dynamiques de catégories complexes, Lokad réaliserait probablement un projet de modélisation sur mesure. Cette approche personnalisée peut permettre une gestion très précise de facteurs tels que la cannibalisation, mais nécessite l’adhésion à une configuration plus consultative plutôt que plug-and-play. Compte tenu du bilan de Lokad (par exemple, travailler avec des détaillants de mode sur les courbes de taille, des détaillants alimentaires sur les promos), ils ont prouvé qu’ils pouvaient gérer ces facteurs au moins aussi bien que les grands concurrents.

Automatisation : La vision de Lokad s’oriente fortement vers la prise de décision autonome. Leur plateforme est souvent décrite comme “Supply Chain Optimization as a Service,” impliquant que l’utilisateur la configure et qu’elle produise automatiquement des décisions (comme des commandes de réapprovisionnement ou des changements de prix) de façon continue ²³. Le but est que les planificateurs passent du traitement manuel des chiffres à la supervision des décisions pilotées par l’IA. Le système de Lokad peut générer des recommandations de commande quotidiennes ou hebdomadaires qui peuvent être intégrées directement dans l’ERP du détaillant pour exécution, avec un ajustement humain minimal. Parce que les prévisions sont probabilistes et que l’optimisation est axée sur le profit, l’idée est que le système prend la décision optimale et n’a pas besoin du ressenti d’un planificateur sur, par exemple, chaque quantité de commande. Bien sûr, en réalité, les entreprises examinent souvent les recommandations dans un premier temps, mais de nombreux clients de Lokad auraient atteint un haut degré d’automatisation (ne gérant manuellement que les exceptions telles que les nouveaux produits ou les grands événements). L’accent mis sur un mode “pilote automatique” est un facteur distinctif – alors que certains outils plus anciens offrent un support à la décision en s’appuyant sur les planificateurs pour interpréter, Lokad se veut être un logiciel de prise de décision. Un exemple de succès en automatisation : un détaillant alimentaire utilisant Lokad a pu mettre en place un réapprovisionnement automatique en magasin qui s’ajustait de façon adaptative aux variations de la demande, réalisant simultanément une réduction significative du gaspillage et des ruptures de stock ²⁴. Cela s’aligne avec les constats de l’industrie selon lesquels un réapprovisionnement automatique piloté par les prévisions peut réduire le gaspillage de pourcentages à deux chiffres ²⁴. Le scripting de Lokad permet aux utilisateurs d’encoder des règles commerciales (par exemple, ne jamais laisser les stocks descendre en dessous d’un stock de présentation minimum) afin que l’automatisation respecte les contraintes du monde réel. Dans l’ensemble, Lokad obtient d’excellentes notes pour progresser vers une optimisation vraiment autonome. La seule mise en garde est que la configuration initiale (codage et test du modèle) demande un effort important ; tant que le modèle n’est pas correct, il ne faut pas automatiser les décisions. Mais une fois ajusté, le système peut fonctionner avec un minimum d’intervention humaine, bien au-delà du niveau d’automatisation des systèmes MRP ou de planification hérités.

Intégration technologique : Lokad est développé entièrement en interne sur une pile technologique cohérente. Il ne s’est pas développé en acquérant les logiciels d’autres entreprises ; au contraire, il a développé son propre moteur de prévision, son solveur d’optimisation et son langage de script. Cela produit une plateforme très intégrée – toutes les fonctionnalités (prévision, tarification, optimisation de stocks) fonctionnent sur le même modèle de données et dans le même langage. Il n’y a pas de “modules” à intégrer via des interfaces ; tout se fait dans l’environnement Envision. Ceci contraste fortement avec certains concurrents qui doivent assembler un outil de tarification acquis avec un outil de planification séparé. L’approche unifiée de Lokad réduit la complexité et évite les incohérences. Par exemple, la sortie de la prévision de la demande s’intègre directement dans la logique d’optimisation de la tarification au sein du même script – il n’est pas nécessaire de transférer des fichiers batch ou de faire des appels API maladroits entre différents systèmes. De plus, la plateforme de Lokad est relativement légère (elle ne nécessite pas une base de données relationnelle complète ni un cube OLAP ; leur stockage et leur calcul sont optimisés pour leur usage spécifique). On pourrait dire que la pile technologique de Lokad est “à l’épreuve du futur” dans la mesure où elle est continuellement améliorée dans son ensemble, plutôt que de comporter des composants hérités qui doivent être remplacés. Le compromis de cette technologie hautement originale est qu’elle est unique – les clients doivent apprendre la façon de travailler de Lokad, qui diffère des outils de planification classiques à interface graphique. Mais d’un point de vue ingénierie, la cohésion de la pile technologique est excellente. Il n’y a pas de Frankenstein composé de pièces acquises ; même leur interface utilisateur et leurs analyses sont conçues sur mesure autour de leur moteur central. Cette simplicité signifie également moins de points de défaillance dans l’intégration – un gros avantage lorsqu’on vise une automatisation complète.

Scepticisme envers le battage médiatique : Notamment, Lokad est explicitement sceptique à l’égard des mots à la mode de l’industrie et cet état d’esprit imprègne le positionnement de leur produit. L’entreprise a publié des critiques de concepts comme “demand sensing,” le qualifiant de “un mot à la mode de plus dans la supply chain qui ne tient pas ses promesses”, en essence du mootware (logiciel qui existe mais ne parvient pas à délivrer de valeur) ¹². Ce regard sceptique est en réalité une force : il suggère que Lokad tente d’ancrer son produit dans une science solide plutôt que dans un marketing dicté par les tendances. Par exemple, Lokad ne s’est pas lancé dans la mode du “blockchain supply chain” ni n’a survendu la rhétorique du “digital twin” (ce que leur fondateur a également critiqué). Au lieu de cela, ils se concentrent sur des capacités techniques tangibles comme la prévision probabiliste et l’optimisation par quantile. En termes d’affirmations des fournisseurs, celles de Lokad sont généralement concrètes. Ils évitent de prétendre à une implémentation “plug-and-play” d’une facilité déconcertante ou à une IA magique prête à l’emploi. En fait, ils mettent souvent en garde contre le déploiement d’une optimisation avancée qui est complexe et nécessite une adaptation à chaque entreprise (d’où leur insistance sur un langage de programmation pour encoder les spécificités de chaque client). Cette honnêteté est rafraîchissante dans un domaine rempli de promesses grandioses. L’inconvénient est qu’un message peu marketing pourrait faire paraître Lokad moins tape-à-l’œil comparé aux concurrents qui vantent bruyamment une “supply chain autonome with cognitive AI.” Mais d’un point de vue recherche de vérité, les affirmations de Lokad tendent à être substantiated – par exemple, s’ils parlent d’une réduction de 5% des stocks chez un client, c’est généralement dans une étude de cas détaillée, et non une affirmation générique. Ils discutent même ouvertement des limites des techniques (on peut trouver des articles de blog de Lokad disséquant les faiblesses des méthodes classiques). Cette transparence renforce leur crédibilité. Dans l’ensemble, Lokad apparaît comme une solution pour les technologues – construite sur des principes d’ingénierie et d’analytique solides, combinant prévision et optimisation, et évitant le battage médiatique. L’approche est sans doute la référence en sophistication technique (probabiliste, axée sur le profit, architecturée dans le cloud). La principale mise en garde est que Lokad est plus petite et moins éprouvée à grande échelle que certains incumbents, et son modèle requiert une mise en œuvre sur mesure par des experts pour chaque client plutôt qu’une solution préemballée. Mais en termes de capacité brute et de conception tournée vers l’avenir, Lokad se classe parmi les principaux fournisseurs dans l’optimisation du retail.

Résumé : Lokad est leader dans l’optimisation conjointe (tarification intégrée aux stocks), utilise la prévision IA probabiliste véritable ³, optimise pour le profit et le coût d’opportunité, se dimensionne grâce à une architecture cloud-native économique, gère les complexités du retail par une modélisation flexible, permet une automatisation élevée, dispose d’une pile technologique cohérente en interne, et maintient une position sceptique rafraîchissante vis-à-vis du battage médiatique. Elle représente une approche à l’épreuve du futur, bien qu’elle puisse nécessiter davantage de travail analytique en amont.

Sources: Intégration des données de tarification et de planification par Lokad ²⁵ ; accent sur les prévisions probabilistes pour des décisions robustes axées sur le profit ³ ; critique des mots à la mode comme le demand sensing ¹².

2. RELEX Solutions – Planification unifiée axée sur le retail avec IA avancée (et quelques efforts importants)

RELEX Solutions (fondée en 2005) est un fournisseur en forte croissance spécialisé dans la planification et l’optimisation retail, couvrant la prévision, le réapprovisionnement, l’allocation, l’assortiment, et désormais l’optimisation des prix. RELEX s’est bâti une réputation dans les secteurs de l’alimentaire et du retail spécialisé en apportant des améliorations mesurables en termes de disponibilité et de réduction du gaspillage. Leur plateforme est conçue spécifiquement pour les défis du retail (produits à courte durée de vie, nombre énorme de SKU, planification au niveau des magasins) et est reconnue pour utiliser le machine learning avancé et un moteur de traitement des données en mémoire pour une réactivité en temps réel. RELEX propose une solution unifiée qui englobe la prévision de la demande, le réapprovisionnement automatique, la planification de l’espace et de l’assortiment, et récemment la tarification – ce qui fait d’elle l’un des rares fournisseurs, aux côtés de Lokad, à pouvoir prétendre aborder les trois piliers (stocks, tarification, assortiment) de manière intégrée. L’entreprise dispose d’une forte culture d’ingénierie (fondée par trois docteurs en informatique) et a beaucoup investi dans la R&D en IA pour le retail. Nous classons RELEX très haut en raison de ses capacités spécifiques au retail et de ses résultats prouvés, tout en notant quelques inconvénients potentiels en termes de lourdeur du système et du fait qu’elle doit également étayer son marketing avec des preuves.

Optimisation conjointe : La plateforme de RELEX est relativement holistique pour les opérations retail. Elle a commencé par la prévision et le réapprovisionnement mais s’est étendue à l’optimisation de l’assortiment et à la planogrammation, et elle propose également des modules d’optimisation des prix ²⁶. Cela signifie qu’un détaillant peut utiliser RELEX pour décider des produits à proposer dans chaque magasin (assortiment), de la quantité à stocker (stocks), et du prix auquel vendre (tarification), le tout au sein d’un seul système. L’intégration de ces éléments est encore en cours – RELEX excellait historiquement dans l’optimisation des stocks (réapprovisionnant les magasins/DCs) et la planification de l’espace, et n’a ajouté les capacités d’optimisation des prix que plus récemment. Cependant, ils annoncent que leur optimisation des prix est alignée avec leur moteur de prévision, permettant de prendre des décisions de tarification en ayant une connaissance complète des impacts sur la demande ²⁷. Par exemple, RELEX peut simuler comment un changement de prix sur un article à forte valeur affectera non seulement les ventes de cet article mais aussi celles des produits complémentaires ou substituts, grâce aux mêmes modèles de prévision sous-jacents. De plus, la fonctionnalité de planification des promotions de RELEX intègre les promotions tarifaires dans le processus de planification de la demande : les promotions sont saisies dans le système, qui ajuste ensuite les prévisions et suggère des reconstitutions de stocks, et peut même recommander des mécanismes de promotion. Ce niveau de considération conjointe est important. Un point fort est la capacité de RELEX à coordonner l’espace (capacité d’étagère) avec la prévision – par exemple, si l’assortiment change ou si les prix sont censés entraîner un volume plus important, le système signalera si l’espace en rayon est insuffisant. Cela dit, RELEX n’optimise peut-être pas encore simultanément le prix et les stocks dans un seul algorithme (il prévoit probablement la demande de manière itérative pour un prix donné, puis optimise le réapprovisionnement en conséquence, plutôt que d’optimiser ensemble le prix et le stock pour maximiser le profit). Néanmoins, au sein d’une même plateforme, les boucles de rétroaction sont plus serrées que pour un détaillant utilisant des outils séparés. RELEX commercialise explicitement la “planification retail unifiée”, et des études de cas montrent des clients qui l’utilisent de bout en bout (des décisions d’assortiment à long terme aux commandes quotidiennes en magasin). Nous donnons à RELEX une note élevée pour son étendue ; aucun manquement fonctionnel flagrant dans le périmètre retail. La mise en garde est que l’intégration de tous ces éléments peut être complexe – c’est une suite, mais la mise en œuvre de chaque module (merchandising, supply chain, tarification) représente un projet majeur.

Prévision Probabiliste & AI : RELEX est connu pour son usage intensif d’AI/ML pour améliorer la précision et la granularité des prévisions. Ils ont développé des modèles de machine learning qui intègrent une variété de moteurs de demande : “la saisonnalité, les tendances, les habitudes en semaine, les promotions, les changements d’affichage, les jours fériés, la météo, les actions des concurrents,” etc. ²⁸ ²⁹. Cette approche multifactorielle va au-delà des méthodes traditionnelles de séries temporelles. Les algorithmes ML de RELEX détectent automatiquement quels facteurs sont déterminants pour chaque produit (sélection de caractéristiques) et peuvent détecter des changements dans les schémas de demande (détection de points de changement pour des évolutions soudaines de tendance) ³⁰ ³¹. Une technique impressionnante qu’ils utilisent est le regroupement de données pour des données peu nombreuses – pour les articles à faible rotation, le modèle regroupe des produits similaires pour extraire des signaux et améliorer les prévisions ³¹. Toutes ces méthodes d’AI modernes que l’on pourrait attendre dans un contexte académique sont désormais déployées dans un outil commercial. Le résultat, selon leurs dires, est des prévisions qui “surpassent les méthodes traditionnelles en rapidité, en précision et en granularité” ³². En effet, RELEX vante souvent des indicateurs tels qu’une amélioration en pourcentage significative de la précision des prévisions ou du taux de service après mise en œuvre. Ils gèrent l’incertitude dans une certaine mesure – par exemple, leur système peut produire différents scénarios ou intervalles de confiance pour les promotions (ils intègrent les effets de cannibalisation et de halo dans les prévisions promo en utilisant le ML pour interpréter les données historiques ⁹). Lors des promotions, ils ajustent explicitement les prévisions des produits connexes à la baisse ou à la hausse en fonction des relations cannibalisation/halo apprises ⁹, réduisant ainsi l’excès de stock pour les articles cannibalisés et évitant les ruptures de stock pour les articles halo. Cela démontre une compréhension probabiliste sophistiquée des effets croisés entre produits. On ne sait pas si RELEX fournit des distributions de probabilité complètes pour tous les articles (il se peut qu’ils simulent en interne des scénarios, mais les planificateurs voient principalement des prévisions ponctuelles ajustées). Cependant, leur gestion de la variabilité est avancée – par exemple, ils mentionnent prendre en compte la “volatilité typique des données retail” en utilisant des algorithmes adaptés à cela ³⁰.

Décision Économique : La focalisation de l’optimisation chez RELEX a historiquement porté sur les taux de service et la fraîcheur plutôt que sur une optimisation explicite des profits – ce qui est compréhensible étant donné leur marché principal de l’épicerie (où éviter des étagères vides et le gaspillage est primordial). Cependant, ils ont ajouté des analyses davantage orientées économiquement. Par exemple, leur rationalisation d’assortiment utilise l’AI pour évaluer la rentabilité de bout en bout de chaque produit par magasin : elle identifie les articles peu performants qui ne justifient pas leur espace de rayonnage en analysant les ventes, les marges et les coûts encourus ³³. Ils soulignent que cette AI “repère la rentabilité de bout en bout pour chaque article par magasin, mettant en lumière les mauvais performeurs” ³³ – liant ainsi efficacement les décisions d’assortiment aux résultats financiers (éliminer la partie qui n’est pas rentable). Cela démontre que RELEX comprend que l’optimisation doit se rattacher au profit et non pas uniquement aux volumes. Dans l’optimisation de stocks, RELEX permet de fixer des cibles de taux de service différentes par produit, pouvant être informées par la marge (articles critiques vs. moins rentables). Ce n’est pas uniquement basé sur le coût d’opportunité comme chez Lokad, mais cela peut approcher une priorisation économique en concentrant une meilleure disponibilité là où cela compte financièrement. Sur le plan de la tarification, puisque RELEX dispose désormais d’un module d’optimisation des prix, la rentabilité est au cœur du dispositif : l’optimisation des prix vise à fixer des tarifs répondant aux objectifs commerciaux, qui sont souvent de maximiser la marge ou le chiffre d’affaires sous contraintes. On peut supposer que leur AI de tarification examine l’élasticité et les compromis de marge (similaire à la tarification de Revionics ou de Blue Yonder). De plus, la planification des promotions par RELEX cherche à maximiser le succès des promotions – ce qui inclut l’évaluation de l’augmentation par rapport au sacrifice de marge. Un indicateur probant de leur orientation économique se trouve dans leurs études de cas : par exemple, Franprix (un épicier français) a réalisé une réduction de 30 % du gaspillage ET 67 % de moins de ruptures de stock en utilisant RELEX, améliorant ainsi la rentabilité grâce à moins de déchets et plus de ventes ²⁴. Ils ont essentiellement optimisé l’équilibre entre le coût du gaspillage et le taux de service, ce qui constitue une optimisation axée sur le profit si on y voit les choses ainsi. Un autre exemple est l’utilisation de données externes (comme les prévisions de passagers d’aéroport pour les magasins WHSmith) afin d’aligner l’offre sur la demande réelle et d’éviter le surstock de produits frais ³⁴ – réduisant ainsi, encore une fois, le gaspillage (coût) tout en capturant les ventes. Tout cela implique que les décisions de RELEX, bien qu’elles ne résolvent peut-être pas une formule formelle de maximisation du profit, sont fortement orientées vers des résultats économiques (réduction des coûts de gaspillage, augmentation des ventes, meilleure rotation de stocks). Ils ne fournissent peut-être pas explicitement des calculs de “profit attendu” pour chaque décision comme le ferait Lokad, mais ils atteignent des objectifs similaires en ciblant des KPI commerciaux corrélés au profit (par exemple, pourcentage de gaspillage, pourcentage de rupture de stock, chiffre d’affaires). À mesure qu’ils intègrent la tarification, nous nous attendons à ce que RELEX évolue vers une optimisation unifiée du profit (par exemple, en optimisant les calendriers de promotions pour vendre les articles saisonniers à la marge la plus élevée possible sans stock résiduel). En résumé, l’ADN de RELEX est un peu plus opérationnel (taux de service et gaspillage) que financier, mais ils reconnaissent clairement et intègrent l’économie du retail dans leurs algorithmes, faisant d’eux bien plus qu’un simple moteur de règles.

Scalabilité & Performance : L’architecture de RELEX est réputée être construite sur une base de données haute performance en mémoire avec un stockage en colonnes pour toutes les données retail, permettant des calculs très rapides sur de grands ensembles de données (un besoin clé pour la planification au niveau magasin-SKU). L’avantage réside dans l’analytique en temps réel – par exemple, les utilisateurs peuvent immédiatement constater l’impact d’un changement de paramètre sur les commandes, ou recalculer une prévision à la volée pour des milliers de magasins. Cette conception a impressionné de nombreux détaillants, mais elle se fait au prix d’une utilisation intensive du matériel. En fait, une analyse critique a noté que “la conception en mémoire, similaire à un cube BI, offre des capacités de reporting en temps réel impressionnantes mais garantit des coûts matériels élevés.” ²². Cela fait référence à l’approche de RELEX : stocker des données en mémoire permet d’obtenir de la rapidité, mais passer à l’échelle pour, par exemple, une chaîne de supermarchés nationale avec des millions de combinaisons SKU-magasin peut exiger une très grande capacité de mémoire et de calcul. RELEX se déploie généralement en tant que solution cloud pour ses clients (ils hébergent sur le cloud, possiblement AWS ou Azure, sans mention publique), et ils peuvent certainement s’adapter aux gros clients (ils comptent parmi leurs clients plusieurs détaillants valant plusieurs milliards de dollars). La question se pose donc en termes d’efficacité en coûts – RELEX peut nécessiter davantage de ressources cloud (et donc de coûts) pour atteindre sa performance rapide par rapport à une solution plus orientée batch. Du point de vue de la scalabilité, RELEX a prouvé son efficacité pour les grands détaillants en Europe et en Amérique du Nord. Le système peut gérer les commandes par magasin pour des milliers de magasins quotidiennement. Un client RELEX de taille moyenne gère souvent plusieurs dizaines de milliers de SKU avec des reprévisions sous-journalières. Le goulot d’étranglement peut survenir lors de l’ajout de modules supplémentaires : l’intégration des données d’assortiment et de planogramme (qui sont énormes) avec le moteur de prévision peut encore augmenter les volumes de données. RELEX y répond en optimisant ses algorithmes et peut-être en déchargeant certains calculs sur disque ou sur des nœuds distribués, mais il s’agit fondamentalement d’une application gourmande en ressources. Ils fournissent également des tableaux de bord et des outils de simulation what-if qui tirent parti des calculs rapides – mais encore une fois, le fait que l’ensemble des données soit en mémoire est le facteur déterminant. Il convient de noter que les prix de la mémoire ont baissé et que la scalabilité cloud s’améliore, rendant l’approche lourde de RELEX plus envisageable qu’il y a une décennie. Néanmoins, les clients soucieux des coûts pourraient trouver les exigences en infrastructure de RELEX élevées par rapport à des outils plus simples. Il existe des preuves anecdotiques que les implémentations RELEX nécessitent des serveurs performants ou des dépenses cloud importantes pour maintenir une réactivité en temps réel. À cet égard, RELEX sacrifie une partie de l’efficacité en termes de coûts pour obtenir rapidité et granularité. Quant à la scalabilité logicielle, RELEX est modulaire (il n’est pas nécessaire d’implémenter tous les modules si ce n’est pas nécessaire) mais repose sur une seule plateforme. Ils ont prouvé leur capacité à soutenir des opérations globales (multi-pays, multi-devises, etc.). Dans l’ensemble, RELEX obtient des scores élevés en termes de puissance brute et de rapidité, modérés en termes d’efficacité coût – c’est la voiture de sport haut de gamme de l’optimisation retail : des performances fantastiques, mais il vous faudra payer pour le carburant premium.

Gestion des Facteurs Retail Complexes : C’est ici que RELEX excelle – il offre des fonctionnalités riches conçues spécifiquement pour des scénarios de retail. Les effets de cannibalisation et de halo sont explicitement pris en compte dans leurs prévisions pour les promotions : comme discuté, le système apprend les relations à partir des données transactionnelles (par exemple, déterminer quels produits sont des substituts versus des compléments) et ajuste les prévisions en conséquence ⁸ ⁹. Peu de fournisseurs intègrent cela ; l’équipe data science de RELEX a publié comment ils utilisent l’apprentissage par règles d’association sur les données de panier pour déduire ces relations, plutôt que de se fier à des hypothèses manuelles ⁸. Cela signifie que lorsque vous lancez une promo sur le produit X, RELEX abaîtra automatiquement la prévision de base du produit Y si Y est habituellement cannibalisé par X (et inversement pour l’effet halo). Cela améliore non seulement la précision des prévisions, mais conduit également à de meilleures décisions de stocks (réduisez le stock de Y parce qu’il se vendra moins pendant la promo de X) ⁹. Concernant la substitution, RELEX peut prendre en compte les effets de rupture de stock : si le produit A est en rupture, leur prévision pour le produit B peut temporairement augmenter si B est un substitut. Cela est probablement réalisé via les mêmes relations apprises ; certains clients transmettent à RELEX les positions de stocks de leurs magasins afin de détecter les ventes perdues et les schémas de substitution. L’expiration et le gaspillage sont des points forts pour RELEX, notamment dans le retail de produits frais. Leur solution peut suivre l’ancienneté des stocks et dispose d’une fonctionnalité de gestion des dates de péremption ³⁵. Par exemple, RELEX peut prioriser la vente des lots les plus anciens (FEFO – first-expire, first-out), et leurs prévisions pour les produits frais prennent en compte la durée de vie limitée (ils tendent à recommander des réapprovisionnements plus petits et plus fréquents pour les biens à courte durée de vie). Ils proposent même des outils pour surveiller le gaspillage et alerter si le stock approche de sa date d’expiration sans être vendu ³⁶. Un client de RELEX, Franprix, a constaté une énorme réduction du gaspillage en utilisant des prévisions journalières et des commandes de magasin automatisées pour les produits frais ²⁴ ³⁷ – ce qui témoigne de la supériorité de RELEX dans la gestion des produits périssables par rapport aux systèmes traditionnels, qui ignorent souvent l’expiration. RELEX intègre également l’espace d’affichage et le merchandising visuel dans la prévision : si un produit bénéficie d’un affichage secondaire, la prévision peut être relevée en conséquence (leur ML détecte cette corrélation). De plus, leurs modules de gestion des effectifs et d’exécution assurent que, si les prévisions ou les plans changent (comme lors d’une soudaine augmentation de la demande), le personnel du magasin soit alerté pour, par exemple, cuire plus de pain ou réapprovisionner plus rapidement (bouclant ainsi la boucle opérationnelle). Un autre facteur complexe est la météo – RELEX dispose d’ajustements de prévisions basées sur la météo, cruciaux pour les catégories saisonnières (par exemple, la glace lors des journées chaudes). Beaucoup prétendent maîtriser la prévision météo ; RELEX l’a en effet mise en œuvre avec un réglage du machine learning pour chaque localité ²⁹. En somme, RELEX possède probablement la suite la plus complète pour gérer les réalités complexes du retail : des effets croisés entre produits aux facteurs externes en passant par la durée de vie. Ils abordent ces aspects de manière largement automatisée grâce à l’AI, ce qui constitue un différenciateur clé. Il faut toutefois savoir que tirer parti de toutes ces fonctionnalités nécessite de fournir à RELEX une grande quantité de données (données de panier, flux météorologiques, statuts de stocks, etc.) et de faire confiance aux recommandations du système. Mais pour les détaillants cherchant à maîtriser la complexité, RELEX offre une boîte à outils éprouvée. Nous leur attribuons la note maximale sur ce critère.

Automatisation: RELEX supporte un haut degré d’automatisation, bien qu’il soit souvent configuré pour permettre une supervision humaine. En pratique, de nombreux clients de RELEX utilisent l’auto-approvisionnement au niveau des magasins et des centres de distribution : le système génère des commandes quotidiennes ou intrajournalières pour chaque SKU-magasin qui passent directement à l’exécution, sauf si elles sont signalées pour révision. Comme indiqué, seulement 24 % des épiciers interrogés disposaient d’une automatisation des commandes en magasin basée sur les prévisions, mais ceux qui l’ont mise en œuvre (avec des systèmes comme RELEX) ont vu le gaspillage diminuer de 10 à 40 % ³⁸ ²⁴. L’exemple de Franprix – une réduction de 30 % du gaspillage grâce aux commandes automatisées – souligne que l’automatisation de RELEX fonctionne ²⁴. Le système dispose d’un mécanisme d’alerte pour attirer l’attention humaine sur les exceptions (par exemple, “la prévision a chuté de manière significative en raison d’un facteur inexpliqué” ou “commande plafonnée par la limite d’espace de stockage”), mais sinon, il peut fonctionner en pilote automatique. La philosophie de RELEX est souvent décrite comme le “retail algorithmique” où les décisions sont pilotées par le système. Ils automatisent également les révisions d’assortiment en suggérant quels articles ajouter ou retirer par magasin à chaque période, et automatisent même les recommandations de réduction de prix pour les fins de stocks. Un domaine d’automatisation qui se distingue est le fulfillment de promotion : RELEX peut automatiquement pousser des stocks vers les magasins en anticipation de promotions, puis les retirer si les ventes sont inférieures aux attentes, sans intervention du planificateur. De plus, grâce au moteur en temps réel, les planificateurs ne sont pas obligés d’exécuter des traitements par lots fastidieux ou des recalculs manuels – le système met à jour les prévisions et les plans de façon continue dès l’arrivée de nouvelles données (ventes, stocks, etc.). Cela permet de passer à une planification continue avec un minimum de déclencheurs manuels. Il est à noter que RELEX implique généralement encore les planificateurs pour la supervision – par exemple, un planificateur pourrait approuver un changement d’assortiment ou ajuster une commande trop agressive, surtout au début de l’adoption. Mais la tendance chez ses utilisateurs est une confiance croissante dans l’IA et, par conséquent, une automatisation accrue. RELEX fournit des outils de simulation permettant aux planificateurs de tester “si je laisse le système passer commande automatiquement, que se passe-t-il en termes de ruptures de stock par rapport aux stocks ?” afin de renforcer la confiance. Comparé aux systèmes hérités qui produisent souvent un plan qu’un humain doit ajuster, RELEX est bien plus proche d’opérations autonomes. Ils ont également commencé à commercialiser la “planification autonome” similaire à Blue Yonder. Dans notre regard sceptique, nous dirions que RELEX a démontré une automatisation éprouvée en réapprovisionnement, une bonne automatisation en prévision (aucune prévision manuelle nécessaire), une automatisation partielle en assortiment (les recommandations sont toujours examinées par le merchandising) et une automatisation émergente en tarification (par exemple, des réductions dynamiques). À mesure que les capacités de l’IA se développent, nous nous attendons à ce que RELEX réduise encore le besoin d’interventions humaines. La mise en garde reste que les organisations doivent adapter leurs processus – RELEX offre la capacité d’automatiser, mais c’est au détaillant de lui faire confiance et de réorganiser les rôles en conséquence.

Intégration technologique: RELEX est une plateforme unifiée développée en grande partie en interne. Ils n’ont pas assemblé leur moteur de planification de base par acquisition – il a été construit par l’entreprise. Les différentes fonctionnalités (prévision de la demande, réapprovisionnement, allocations, planogramme, workforce) partagent une plateforme de données commune. Cela signifie moins de problèmes d’intégration au sein de la suite : par exemple, le module de planification d’assortiment se connecte directement au module de prévision de sorte que, lorsque vous retirez un produit de l’assortiment, les prévisions et les commandes tombent automatiquement à zéro après son retrait. La cohérence est généralement forte ; les utilisateurs accèdent à ces fonctions via une seule interface. RELEX a réalisé quelques acquisitions (une application mobile d’exécution en magasin, une technologie de reconnaissance d’image, etc.), mais celles-ci sont des compléments plutôt que le cœur de la logique de planification. Une complexité potentielle réside dans l’architecture en mémoire – le fait que tout vive dans un gigantesque modèle de mémoire peut rendre les modifications ou l’intégration de nouveaux types de données compliquées. Mais ils semblent y parvenir grâce à des techniques modernes de base de données. Comparées aux anciens fournisseurs qui proposent des produits distincts (souvent issus d’acquisitions) pour la tarification et les stocks, les solutions de RELEX paraissent plus cohérentes. Par exemple, leur optimisation des prix est un composant plus récent, mais a probablement été développé ou étroitement intégré de manière à utiliser les mêmes données de prévision et la même interface utilisateur. Il n’est pas nécessaire d’exporter les prévisions vers un outil de tarification tiers – tout est intégré dans RELEX. Cela réduit les hypothèses incohérentes entre les modules. Un autre point d’intégration : RELEX se connecte aux systèmes d’exécution (ERP, POS, etc.) via des API, et ils disposent d’outils d’intégration assez robustes (ce qui est normal pour n’importe quel fournisseur). Parce que RELEX s’est développé en tant que produit unique, il évite le label “Frankenstein” qui affecte des concurrents plus anciens tels que JDA/Blue Yonder et SAP. Cela dit, à mesure que RELEX s’étend (en particulier dans la tarification), maintenir la pureté d’une plateforme unique demeure un effort constant. Nous n’avons pas observé de problèmes majeurs signalés, nous en déduisons donc qu’ils ont su garder l’intégration. Une dimension à surveiller est de savoir si les microservices de RELEX (si l’application a été découpée en services) communiquent sans heurts. Gartner a noté les “outils de gestion des données et de modélisation des contraintes” de RELEX comme remarquables ³⁹ – indiquant qu’ils disposent d’une méthode intégrée pour gérer l’ensemble des règles métier et des données. Cela suggère un haut niveau d’intégration où différentes contraintes (comme l’espace d’étagère, les délais, les tailles de conditionnement, etc.) alimentent toutes le même solveur, plutôt que des solveurs séparés. En résumé, RELEX est l’une des solutions les plus techniquement cohérentes de cet univers, avec peu d’éléments laissant penser à un morcellement dû aux nombreuses opérations de fusion-acquisition.

Scepticisme à l’égard des affirmations marketing: RELEX, comme beaucoup de jeunes entreprises, utilise librement des mots à la mode comme AI/ML dans son marketing, mais dans leur cas, la substance soutient en grande partie ces termes. Ils évoquent le “Living Retail” et “libérer l’IA” – certes du jargon marketing – mais publient également des résultats concrets et des méthodologies. Par exemple, ils mettent en ligne des articles de blog et des ressources détaillant comment leur machine learning fonctionne pour le retail (abordant le regroupement, la détection de tendances, etc.) ⁴⁰ ³⁰. Cette transparence est appréciable ; ce n’est pas simplement une boîte magique d’IA, ils exposent au moins leur approche. RELEX laisse aussi la parole à ses clients – nombre de leurs affirmations prennent la forme de statistiques issues d’études de cas (par exemple, un détaillant XXXX a amélioré la disponibilité sur les rayons de Y % tout en réduisant ses stocks de Z %). Ces données sont plus crédibles que de vagues affirmations. Ils emploient parfois des termes comme “autonome”, “cognitif”, etc., mais, jusqu’à présent, ils n’ont pas exagéré au point de promettre ce que leur logiciel ne peut accomplir. Un domaine à surveiller est le “demand sensing” – RELEX utilise parfois ce terme pour décrire sa capacité de prévision à court terme (intégrant les ventes récentes pour ajuster les prévisions immédiates). Nous savons que le concept de demand sensing a parfois été critiqué comme du battage médiatique ¹², mais dans le cas de RELEX, leur approche consiste essentiellement en des prévisions plus fréquentes basées sur les dernières données, ce qui est acceptable. Tant qu’ils ne prétendent pas avoir une clairvoyance impossible, cela va. L’intégration plug-and-play n’est pas non plus exagérée par RELEX ; ils reconnaissent que la mise en œuvre demande du travail (intégration de données, réglage des paramètres). En fait, certains clients ont noté que les projets RELEX nécessitent un effort considérable (ce qui est attendu pour des outils aussi puissants). Ainsi, RELEX ne pousse pas un récit fallacieux de “valeur instantanée”. Ils évitent également un jargon excessivement fantaisiste – vous ne les entendrez pas vanter la blockchain ou l’informatique quantique sans raison (bien que, de manière amusante, leur acquisition “Evo” utilise le terme “quantum learning” pour leur IA – mais c’est une autre histoire). Si tant est que l’argument marketing le plus important de RELEX est qu’il peut gérer tous les aspects de la planification retail dans une solution unifiée et fournir rapidement des résultats significatifs. Nous restons sceptiques : un seul système peut-il réellement exceller dans tout, de la stratégie d’assortiment à long terme au réapprovisionnement quotidien en passant par la tarification ? C’est un défi de taille. RELEX possède de solides capacités dans de nombreux domaines, mais certains (comme la tarification) sont plus récents et pas encore aussi éprouvés que ceux de concurrents spécialisés. Ainsi, bien qu’ils offrent toutes les pièces, un détaillant pourrait trouver qu’une d’entre elles est moins mature. C’est une nuance que leurs supports commerciaux pourraient occulter. De plus, le fait de regrouper autant de fonctions sur un seul système pourrait s’avérer lourd – un problème rarement mis en avant dans le marketing. Toutefois, en équilibrant le battage médiatique et la réalité, RELEX se situe parmi les meilleurs : leurs affirmations d’améliorations pilotées par l’IA sont soutenues par des algorithmes et des preuves clients, et ils évitent généralement les excès de jargon à la mode. Nous évaluons l’honnêteté de leur marketing comme étant relativement élevée.

Résumé: RELEX Solutions est une centrale d’optimisation retail dotée d’une plateforme unifiée couvrant la prévision, le réapprovisionnement, l’assortiment et la tarification. Elle exploite le machine learning de manière intensive pour tenir compte des facteurs réels du retail (promotions, météo, cannibalisation ⁹, etc.), et a démontré des améliorations significatives pour les détaillants (meilleure disponibilité, moins de gaspillage ²⁴). Le système supporte la planification conjointe de l’assortiment, des stocks et, dans une certaine mesure, de la tarification, bien que l’optimisation tarifaire soit plus récente pour eux. La prévision probabiliste et basée sur l’IA est un atout remarquable ²⁸ ³¹, tout comme leur capacité à gérer les produits frais et la complexité de manière élégante. La scalabilité est généralement prouvée, bien que nécessitant une importante utilisation de ressources ²². RELEX permet un haut degré d’automatisation (en particulier dans le réapprovisionnement) et dispose d’une pile technologique cohérente conçue pour le retail. Bien que certains aspects (par exemple, des décisions optimales en termes de profit ou une optimisation pleinement unifiée de la tarification+stocks) ne soient peut-être pas aussi intégrés de manière native que dans l’approche de Lokad, RELEX représente l’une des solutions les plus robustes et innovantes pour les grands détaillants. Son accent sur la réalité (et non uniquement sur la théorie) et ses applications concrètes de l’IA en font un concurrent de premier plan – sans doute le leader parmi les fournisseurs spécialisés en retail. Les principaux risques résident dans sa complexité (la mise en œuvre de toutes les fonctionnalités n’est pas anodine) et dans le fait de s’assurer que le battage médiatique (l’IA partout !) se traduise par des solutions conviviales et faciles à maintenir. Jusqu’à présent, les preuves suggèrent que RELEX tient largement ses promesses, faisant de lui un choix de premier rang pour une optimisation retail tournée vers l’avenir.

Sources: Facteurs de prévision pilotés par le ML de RELEX (schémas de demande, promotions, événements externes) ²⁸ ; gestion de la cannibalisation via le ML dans la prévision des promotions ⁹ ; réduction démontrée du gaspillage grâce au réapprovisionnement automatisé basé sur les prévisions ²⁴ ; analyse de la rentabilité de l’assortiment pilotée par l’IA ³³.

3. o9 Solutions – Une planification intégrée ambitieuse avec de grandes promesses (et des réserves)

o9 Solutions (fondée en 2009) se présente comme la créatrice d’un “Digital Brain” pour la planification d’entreprise – une plateforme qui unifie la prévision de la demande, la planification de la supply chain, la gestion des revenus, et plus encore, sur un modèle de données basé sur les graphes. La vision d’o9 est d’être la plateforme unique pour la planification de bout en bout, supprimant les silos entre la planification de la demande, les stocks/supply, la planification commerciale, et même la planification financière. Dans le contexte du retail, o9 peut être configurée pour la planification du merchandising et de l’assortiment, la prévision de la demande, la planification du supply, et dispose de capacités pour le Revenue Growth Management (RGM) qui inclut l’optimisation de la tarification et des promotions ⁴¹. En théorie, cela coche toutes les cases de l’optimisation conjointe. o9 a gagné du terrain dans le secteur des biens de grande consommation, dans la fabrication, et au sein de certaines entreprises retail ou orientées consommateur, en mettant souvent en avant son approche moderne basée sur l’IA/ML et les graphes de connaissances par opposition aux APS (Advanced Planning Systems) plus anciens. Cependant, d’un point de vue d’ingénierie sceptique, o9 est un peu un paradoxe : elle est très avancée technologiquement en termes d’architecture, mais certains experts remettent en question la part de substance dans son IA par rapport au battage médiatique.

Optimisation conjointe: La proposition de valeur centrale d’o9 est la planification intégrée à travers toutes les fonctions. Pour un détaillant, cela signifie qu’un seul système o9 pourrait gérer la planification financière du merchandising, les décisions d’assortiment, la prévision de la demande, la planification du réapprovisionnement, et la stratégie tarifaire, le tout étant connecté. Ils promeuvent explicitement leur solution pour le Revenue Growth Management (RGM) qui “intègre le RGM, la planification de la demande, la supply chain, et l’IBP dans une plateforme unique” ⁴¹. Cela suggère que la tarification et les promotions (RGM) ne sont pas des entités indépendantes – elles s’insèrent dans la planification de la demande qui alimente ensuite la planification du supply, le tout au sein d’o9. En pratique, o9 dispose de modules ou d’applications pour chaque domaine, mais sous une même bannière. Par exemple, une implémentation d’o9 pourrait inclure un modèle d’élasticité des prix dans le module de planification de la demande, permettant aux planificateurs de voir comment une modification du prix affecterait la prévision et, immédiatement, comment cela impacterait les stocks ou les plans de production. Leur concept d’Enterprise Knowledge Graph (EKG) signifie que toutes les données (produits, emplacements, fournisseurs, contraintes, etc.) sont connectées comme un réseau, permettant à tout changement (comme une nouvelle décision d’assortiment ou une modification de prix) de propager ses impacts à travers le graphe. C’est puissant en théorie : cela pourrait permettre une véritable optimisation concurrente – ajuster simultanément les prix et passer commande pour maximiser le profit et le service. Cependant, il n’est pas clair si o9 optimise actuellement automatiquement ces dimensions ou s’il se contente d’une analyse unifiée. Souvent, les clients utilisent o9 pour exécuter des scénarios : par exemple, scénario 1 – prix x, commande y ; scénario 2 – prix x+5 %, commande z – puis comparer les résultats. C’est de la planification intégrée, mais pas nécessairement un algorithme d’optimisation unique. Cela dit, o9 est capable de calculer des scénarios complexes grâce à son moteur. C’est l’un des rares à pouvoir réellement combiner la planification d’assortiment (merchandising) avec la supply chain – de sorte qu’un détaillant peut élaborer une stratégie de catégorie (quels SKU dans quels magasins) et o9 planifiera simultanément les stocks et le réapprovisionnement, garantissant ainsi que la supply correspond au plan de merchandising. De nombreuses configurations héritées effectuent ces opérations en étapes disjointes. o9 vante également la collaboration avec les fournisseurs et la planification à plusieurs niveaux sur une même plateforme, ce qui signifie que les problèmes d’approvisionnement en amont peuvent éclairer les décisions de merchandising en aval. Toute cette intégration holistique est une force majeure et résolument tournée vers l’avenir. Le principal défi réside dans la complexité : modéliser tous ces éléments dans un système unique requiert une configuration significative et une intégration poussée des données. Certains utilisateurs rapportent que, bien qu’o9 puisse tout faire, leur implémentation se concentre d’abord sur un ou deux domaines (par exemple, la planification de la demande et de l’offre), laissant la tarification ou l’assortiment pour des phases ultérieures. Ainsi, l’optimisation conjointe est plus un potentiel qu’une réalité instantanée. Nous attribuons à o9 de fortes notes pour sa vision et son architecture en matière d’optimisation conjointe, tout en émettant des réserves sur le nombre de clients qui l’utilisent réellement pour des décisions pleinement intégrées de tarification et de stocks. Néanmoins, la capacité de la plateforme est là, et c’est plus que ce que l’on peut dire pour la plupart.

Prévisions Probabilistes & IA : o9 se positionne assurément comme une plateforme propulsée par l’IA. Elle dispose d’un moteur ML dédié qui peut ingérer de nombreuses variables externes (ils font des démonstrations avec Google Trends, la météo, les données socio-économiques) dans la prévision. Le Knowledge Graph est parfois présenté comme permettant une meilleure IA – en reliant toutes les données, il aiderait, paraît-il, les algorithmes de machine learning à trouver des prédicteurs de la demande. Cependant, un regard critique est de mise. Une analyse indépendante a noté : “De nombreuses allégations de prévision associées à la base de données graphe (EKG) sont douteuses et non étayées par la littérature scientifique. Un tas de battage médiatique autour de l’IA, mais des éléments trouvés sur Github laissent entrevoir des techniques banales.” ⁴². Cela suggère que les méthodes de prévision réelles d’o9 ne sont peut-être pas aussi révolutionnaires que leur marketing ne le laisse entendre – utilisant possiblement des modèles de séries temporelles assez standards ou de la régression en interne, malgré leur habillage dans des termes chics. En effet, o9 a été critiqué pour qualifier même des fonctionnalités interactives simples d’“IA.” Par exemple, la génération rapide de scénarios est une caractéristique de leur outil (grâce au calcul en mémoire), mais la planification de scénarios n’est pas de l’IA – c’est simplement une simulation. Cela dit, o9 possède des capacités de machine learning : ils peuvent construire des modèles ML pour les promotions, pour les introductions de nouveaux produits (en utilisant la prévision basée sur les attributs), etc. Ils ont acquis une petite entreprise d’IA (Fourkind) pour renforcer leur data science. Ce n’est donc pas uniquement du vent ; ils ont implémenté du ML pour la reconnaissance de motifs et la détection d’anomalies dans les prévisions. C’est juste que cela pourrait être similaire à ce que font d’autres fournisseurs modernes. Il y a peu de preuves que le modèle graphe améliore intrinsèquement la précision des prévisions – il aide principalement à l’organisation des données. La prévision d’o9 peut être probabiliste dans le sens où ils supportent les simulations Monte Carlo pour les scénarios (par exemple, simuler 1000 trajectoires de demande pour voir la distribution des résultats), mais nous ne les avons pas vus mettre l’accent sur la génération par défaut de distributions de probabilités complètes comme le fait Lokad. Ainsi, en termes de maturité pure de la prévision probabiliste, ils pourraient être en retard par rapport à des acteurs spécialisés. Cependant, o9 intègre l’IA de d’autres manières : par exemple, ils disposent d’un outil de risque supply chain propulsé par l’IA pour prédire les perturbations potentielles, ce qui sort du cadre de la prévision classique. Ils ont également un nouvel assistant Generative AI (interface chatbot pour interroger le système), qui est plus une interface utilisateur que le cœur de la prévision mais montre qu’ils investissent dans la technologie IA. En résumé, nous attribuons à o9 de bonnes capacités en IA mais potentiellement pas aussi différenciées qu’ils le prétendent. Ils surpassent assurément les anciens systèmes AP qui se basent sur la prévision manuelle, mais face à des pairs tels que RELEX ou Lokad, l’approche de prévision d’o9 pourrait sembler moins concentrée (puisqu’o9 équilibre également de nombreux autres aspects de la planification). Le scepticisme des experts ⁴² indique qu’il ne faut pas prendre toutes les affirmations sur l’IA d’o9 pour argent comptant. Nous souhaitons voir une validation indépendante accrue de leurs gains en précision de prévision. D’ici là, nous considérons leur IA comme crédible mais quelque peu trop marketée.

Décision Économique : La plateforme d’o9, étant très flexible, peut être configurée pour optimiser divers objectifs, y compris financiers. Dans les contextes de business planning intégré (IBP), o9 aide souvent les entreprises à évaluer des scénarios par chiffre d’affaires, marge, service, etc. Pour le retail, leur module RGM devrait prendre en compte explicitement l’élasticité des prix et la marge – liant ainsi directement les décisions aux résultats en termes de profit et de chiffre d’affaires. Ils ont la capacité de lancer des scénarios what-if sur la rentabilité : par exemple, “Et si nous fixions le prix de cette catégorie 5 % de moins ? Comment le profit et le volume changeraient-ils ? Et nos fournisseurs pourraient-ils suivre ?” Ceci aligne la planification avec des métriques financières. Cependant, la question demeure de savoir si o9 optimise automatiquement ou se contente de fournir un bac à sable. Une partie de la valeur d’o9 réside dans la facilitation des décisions interfonctionnelles : par exemple, un utilisateur peut constater qu’un certain plan promotionnel entraînerait des ventes perdues en raison de contraintes d’approvisionnement, et décider de l’ajuster pour maximiser le profit compte tenu de ces contraintes – le tout au sein de l’outil d’o9. Cela facilite la prise de décision économique (en fournissant transparence et simulations rapides). o9 intègre également des solveurs d’optimisation (pour la supply chain et vraisemblablement pour la tarification également). Ils peuvent réaliser des choses comme l’optimisation multi-échelons de stocks (équilibrer les stocks entre DCs et magasins afin de minimiser les coûts pour atteindre un taux de service cible) et l’optimisation du calendrier promotionnel (choisir le meilleur planning promo pour atteindre les objectifs). Cela implique des compromis économiques. Un exemple : o9 peut optimiser l’allocation d’assortiment – déterminer combien de présentations ou quels produits dans chaque magasin pour maximiser une certaine métrique (comme les ventes ou le profit) sous contraintes d’espace. C’est une optimisation mathématique alignée sur des objectifs économiques. Comme la plateforme d’o9 est personnalisable, un détaillant pourrait configurer une fonction objectif de “maximiser la marge attendue moins le coût de détention” pour les stocks, tandis qu’un autre pourrait opter pour “maximiser le chiffre d’affaires sous condition X.” L’outil peut supporter les deux. Il est donc flexible, mais cela signifie aussi qu’o9 lui-même n’impose pas une approche économique – il peut être utilisé de manière plus manuelle/heuristique si le client le choisit. Leur marketing autour de la “planification centrée sur la décision” et du “digital brain” implique que le système vous guidera vers la meilleure décision. Pourtant, certains critiques disent que les démonstrations sophistiquées d’o9 reposent encore largement sur l’analyse humaine plutôt que sur des décisions optimales entièrement automatisées ⁴². Nous soupçonnons que l’usage typique d’o9 consiste à présenter aux planificateurs des scénarios et des KPI (coûts, profits, etc.) et que ce sont eux qui décident, plutôt que le système ne fournisse une réponse optimale unique. En termes de coût d’opportunité, il n’est pas clair si o9 calcule intrinsèquement ces coûts (par exemple, le coût d’un stock-out en termes de profit perdu – il le peut probablement s’il est configuré). Pour l’optimisation des prix, si l’on utilise le RGM d’o9, il optimise vraisemblablement mathématiquement les prix afin d’atteindre un objectif financier compte tenu des courbes d’élasticité de la demande, de manière similaire à d’autres outils d’optimisation des prix. Ainsi, oui, il peut être économiquement piloté. Dans l’ensemble, o9 permet une prise de décision économique forte (puisqu’il est conçu pour combiner la planification opérationnelle et financière), mais le degré d’automatisation varie. Nous leur attribuons du crédit pour connecter la planification aux résultats commerciaux (leur argument de vente est souvent de briser le mur entre la finance et la planification de la supply chain). Sachez simplement qu’atteindre de véritables décisions optimales en termes de profit avec o9 pourrait nécessiter une modélisation et un ajustement significatifs lors de la mise en œuvre.

Scalabilité & Architecture : L’architecture d’o9 est l’un de ses atouts – ils utilisent un moteur de calcul en mémoire moderne et le Enterprise Knowledge Graph pour représenter les données dans une structure hautement connectée mais efficace. Cela permet une traversée rapide et des calculs. Ils démontrent souvent une propagation quasi-instantanée des changements (par exemple, modifier une prévision et immédiatement le plan supply se met à jour). C’est conceptuellement similaire à la manière dont Kinaxis parvient à la concurrence, mais avec une touche de base de données graphe. Cependant, comme l’a souligné précédemment le sceptique, “la masse technologique d’o9 est hors normes, même selon les standards des entreprises. La conception en mémoire garantit des coûts matériels élevés.” ⁴. Autrement dit, o9 embarque une énorme quantité de données et de calculs en mémoire, de sorte que l’exécuter pour une grande entreprise pourrait nécessiter des serveurs puissants ou des dépenses élevées en cloud, semblable à la situation de RELEX. o9 est basé sur le cloud (ils proposent leur solution SaaS, souvent sur Azure), ce qui offre de l’élasticité. Mais si un détaillant utilise o9 pour modéliser l’ensemble de son réseau, en plus des données financières et commerciales détaillées, le modèle peut être extrêmement grand. Un avantage : le modèle graphe peut être plus économe en mémoire que des tables de données naïves, car il stocke les relations de manière élégante. Toutefois, le critique suggère qu’il reste assez lourd. En effet, lors des premiers déploiements, o9 était réputé pour sa forte utilisation de la mémoire. Ils ont vraisemblablement amélioré cet aspect et, grâce au cloud, ils peuvent monter horizontalement dans une certaine mesure (bien que certains calculs nécessitent encore une grande mémoire partagée). La scalabilité en nombre d’utilisateurs est bonne – de nombreux utilisateurs peuvent collaborer dans le système, chacun visualisant différentes tranches, grâce à son back-end haute performance. o9 est utilisé par des entreprises Fortune 500, ce qui témoigne de sa scalabilité pour les grandes entreprises (y compris de très grandes CPG et une chaîne de restauration rapide mondiale). La rentabilité est une autre question : des preuves anecdotiques suggèrent qu’o9 n’est pas bon marché à exploiter, compte tenu de sa tarification d’entreprise et de ses besoins en ressources. Si vous êtes sensible aux coûts, une solution plus légère pourrait être préférée pour un sous-ensemble de tâches. Mais si vous valorisez une planification intégrée en temps réel à l’échelle de l’entreprise, o9 répond présent, ce qui coûte intrinsèquement plus de ressources de calcul. En termes de performance, o9 peut recalculer les plans très fréquemment (certains le font quotidiennement ou même en intra-journée pour des horizons à court terme), ce qui constitue une amélioration par rapport aux cycles de planification par lots hebdomadaires d’antan. Ils emploient également des microservices et une approche “platforme”, signifiant que des parties du plan peuvent être mises à jour sans devoir tout relancer depuis le début. Le Knowledge Graph est mis à jour de manière incrémentale à mesure que de nouvelles données arrivent. C’est moderne et scalable par conception. En résumé, o9 est techniquement scalable à des problèmes très vastes, mais les utilisateurs doivent se préparer à une utilisation significative de hardware/cloud (la plateforme est puissante mais gourmande). Comparé à des solutions véritablement légères et spécialisées, o9 utilisera probablement plus de mémoire parce qu’il résout un problème intégré plus important. Ainsi, en termes de scalabilité, nous lui attribuons de grosses marques pour sa capacité, et une note moyenne pour sa rentabilité.

Gestion des Facteurs Complexes du Retail : De base, o9 ne possède peut-être pas autant de fonctionnalités préconfigurées spécifiques au retail que RELEX, mais il peut être configuré pour les gérer. Par exemple, cannibalisation et halo – les modèles ML d’o9 peuvent détecter ces phénomènes s’ils reçoivent des données transactionnelles, de la même manière que le fait RELEX. Cela requiert probablement que l’équipe data science définisse les fonctionnalités adéquates ou utilise l’assistant ML d’o9. Nous n’avons pas trouvé de références explicites à une modélisation intégrée de la cannibalisation des promos dans les documents d’o9 ; c’est vraisemblablement réalisé via leur prévision ML plutôt que par un module séparé. Les effets de substitution peuvent être gérés car o9 peut suivre les niveaux de stocks – il est possible de mettre en place une règle ou un modèle ML qui, lorsqu’un SKU est en rupture, la demande d’un SKU corrélé augmente. Mais encore une fois, cela pourrait nécessiter une modélisation explicite. Expiration/périssables : o9 peut gérer les attributs de lot (son modèle de données peut incorporer des attributs d’article comme la date d’expiration). Un détaillant pourrait utiliser o9 pour planifier la production et la distribution en adéquation avec des contraintes de durée de vie (par exemple, s’assurer que les articles sont expédiés aux magasins avec une durée de vie suffisante). Toutefois, cela pourrait nécessiter une personnalisation des contraintes et des objectifs. Ce n’est pas une solution dédiée aux produits frais, donc il ne calculera pas automatiquement les projections de péremption à moins que vous n’implémentiez cette logique. En revanche, certains autres fournisseurs intègrent cela par défaut. Ainsi, o9 peut le faire, mais l’utilisateur doit savoir l’inclure dans son modèle. Les promotions et la saisonnalité sont assurément prises en charge – les prévisions et la planification d’o9 tiennent compte des effets promotionnels (ils disposent d’un module de planification promo pour saisir les promotions qui ajustent ensuite les prévisions et les plans supply). Ils permettent également la planification multi-échelons de stocks, c’est-à-dire qu’ils peuvent optimiser les niveaux de stocks entre les DCs et les magasins en tenant compte de la variabilité – une manière de gérer élégamment l’incertitude de la demande. Nous soupçonnons qu’étant multisectoriel, o9 ne propose pas autant d’algorithmes préconfigurés spécialisés retail (par exemple, il ne suggérera pas automatiquement “cet article est un substitut pour celui-ci” à moins que vous ne configuriez cette logique). Mais leur flexibilité signifie que tout facteur retail peut être modélisé. Ils offrent également ce qu’ils appellent des “control towers” – essentiellement des tableaux de bord pour surveiller des indicateurs tels que les ruptures de stocks, les ventes perdues, les excédents – qui aident à identifier des problèmes comme la cannibalisation ou des assortiments médiocres. De plus, le Knowledge Graph d’o9 peut s’intégrer à des données externes, ainsi quelque chose comme la météo peut être exploité pour ajuster les prévisions (si l’utilisateur le configure). De nombreux clients retail d’o9 utilisent vraisemblablement des signaux de demande externes. L’optimisation d’assortiment fait explicitement partie de leur offre (ils listent des solutions de “merchandising and assortment planning”), ce qui signifie qu’ils peuvent utiliser l’analytique pour déterminer l’assortiment idéal à chaque magasin, et prendre en compte les préférences locales ainsi que les contraintes d’espace. Combiné avec leur IBP, ils peuvent s’assurer que les changements d’assortiment sont réalisables d’un point de vue supply. Cela répond à la complexité de la demande localisée. Globalement, o9 est capable de gérer des facteurs complexes, mais nécessite une équipe d’implémentation compétente pour exploiter pleinement ces capacités. Il n’est peut-être pas aussi “out-of-the-box” pour les détails retail qu’un fournisseur dédié au retail, mais une fois configuré, il peut rivaliser avec eux. Une critique à noter : les commentaires d’experts antérieurs impliquent que certaines technologies avancées d’o9 pourraient en réalité reposer sur des méthodes plus simples (ils mentionnent des projets open-source comme tsfresh, ARIMA, etc. dans le contexte d’o9) ⁴³, ce qui pourrait signifier que certains phénomènes complexes sont abordés avec des techniques relativement basiques (comme la régression linéaire pour les promotions – qui fonctionne mais n’est pas révolutionnaire). Si c’est le cas, o9 pourrait devoir approfondir son approche pour véritablement capter, par exemple, des impacts non linéaires de cannibalisation. Néanmoins, compte tenu de leurs ressources et de leur focus sur l’IA, il est probable qu’ils progressent dans ce domaine.

Automation: La plateforme d’o9 est principalement un outil de planification et d’aide à la décision – elle excelle dans la création rapide de plans et de scénarios. Que son exécution soit automatique dépend largement de l’organisation utilisatrice. De nombreux utilisateurs d’o9 impliquent encore des planificateurs pour choisir les scénarios et approuver les plans. Cependant, o9 offre la capacité de planification continue. Ils mettent en avant des concepts tels que le « what-if en temps réel » et la « re-planification continue » qui laissent entendre une automatisation (le système met constamment à jour le plan à mesure que les conditions changent). Par exemple, si la demande explose dans une région, o9 peut réallouer automatiquement les stocks dans le plan et suggérer des accélérations. Certains ont qualifié l’approche d’o9 de « planification autonome » dans le marketing, mais en réalité, elle vient souvent compléter les planificateurs plutôt que les remplacer. Cela dit, o9 a introduit des fonctionnalités telles que des agents IA capables de surveiller les données et de formuler des recommandations. Et leur nouveau GenAI Orchestrator est censé « permettre aux entreprises de prendre des décisions plus rapides et plus intelligentes tout en augmentant la productivité des planificateurs » ⁴⁴ – accélérant principalement la manière dont les planificateurs accèdent aux informations. Une automatisation complète sans surveillance (comme l’exécution automatique des commandes ou des modifications de prix) n’est pas couramment évoquée pour o9. Typiquement, o9 alimenterait des plans optimisés dans un ERP ou un système d’exécution qui les met ensuite en œuvre. Ainsi, l’automatisation dans le contexte d’o9 concerne davantage l’automatisation du processus de planification (finies les manipulations manuelles de tableurs, mises à jour automatisées des prévisions, alertes automatisées en cas de déviation du plan, etc.) que l’exécution. La différence par rapport à quelque chose comme Lokad ou RELEX est subtile : o9 automatise les calculs et fournit une recommandation décisionnelle, mais c’est souvent à un humain de déclencher l’action ; Lokad/RELEX sont souvent configurés pour générer automatiquement la commande réelle ou la modification de prix. Cela dit, si une entreprise le souhaite, elle pourrait considérer les résultats d’o9 comme des décisions automatiquement autorisées. Par exemple, o9 pourrait générer des propositions de commandes qui seraient envoyées directement quotidiennement à un système de gestion des commandes – c’est faisable. Ou bien, il pourrait calculer de nouveaux prix de transfert ou des suggestions de réduction et les transmettre aux magasins. La capacité est là, mais les utilisateurs typiques d’o9 (souvent de grandes entreprises) tendent à maintenir un humain dans la boucle pour les décisions critiques. Il faut noter que la force de la planification par scénarios d’o9 réduit en réalité le besoin de tâtonnements humains – le système lui-même peut simuler d’innombrables scénarios (presque comme une séance de brainstorming automatisée). En ce sens, il automatise l’évaluation des options, laissant à l’humain le soin de choisir parmi les meilleures. Cela accélère considérablement la prise de décision. Ainsi, en termes de productivité des planificateurs, o9 automatise les tâches ingrates. Ils disposent également de workflows (comme les approbations, notifications) qui peuvent acheminer automatiquement les exceptions vers la bonne personne. Pour rester sceptique, le marketing d’o9 avec son « Digital Brain » peut laisser entendre une supply chain autonome, mais en réalité, c’est plutôt comme un cockpit décisionnel très performant nécessitant un pilote qualifié. Nous leur attribuons une note modérée à élevée pour l’automatisation des calculs de planification, mais plus faible pour l’exécution autonome totale. Par rapport aux anciens systèmes nécessitant de nombreuses saisies manuelles, o9 constitue un bond en avant. Comparé à l’idéal d’une IA pilotant automatiquement les opérations retail, o9 n’est pas encore tout à fait au niveau (ni la plupart des autres).

Technology Integration: o9 a été construit comme une plateforme unique depuis le début (par d’anciens vétérans d’i2 Technologies), il n’a donc pas hérité d’un patchwork de modules acquis – ce qui est un avantage pour l’intégration. Son architecture microservices et son modèle de données unifié signifient que toutes les parties du système communiquent de manière fluide entre elles. Vous n’avez pas besoin de bases de données séparées pour la prévision versus la planification; le Knowledge Graph regroupe tout. Cela évite les tracas traditionnels d’intégration entre, par exemple, un système de prévision et un système d’optimisation des stocks. Toutes les données sont chargées une seule fois dans o9, puis les différentes « apps » qui le composent opèrent sur ces données partagées. L’expérience utilisateur est également unifiée (ils disposent d’une interface web commune à tous les modules, avec des tableaux de bord configurables). Ainsi, du point de vue de l’utilisateur, on ressent l’impression d’un système unique pour toutes les tâches de planification. C’est un avantage majeur par rapport à une solution Frankenstein. Cependant, à mesure qu’o9 a grandi, il a ajouté de nombreuses fonctionnalités et a peut-être acquis une petite entreprise ou deux (comme une société de conseil en IA, et peut-être une pour la conception de supply chain). Il se peut qu’une certaine intégration soit nécessaire dans ces domaines périphériques, mais la planification de base reste unifiée. Une critique d’un expert a déclaré qu’o9 est « l’archétype du grand fournisseur de technologie » avec une « masse tech hors normes », impliquant une grande complexité sous le capot ⁴. Cela laisse entendre que, bien qu’il ne s’agisse pas d’un Frankenstein par acquisitions, la propre plateforme d’o9 est massive – ce qui peut la rendre compliquée à implémenter ou à maintenir. Mais il s’agit d’une complexité interne plutôt que de l’intégration de technologies disparates. Les acheteurs d’entreprise préfèrent souvent une plateforme intégrée comme o9 car elle réduit le nombre de fournisseurs et d’interfaces. C’est là la force d’o9 – vous achetez une plateforme unique au lieu de solutions séparées pour la prévision, la planification, le S&OP, etc. Le risque est que, si une partie de la plateforme n’est pas de premier ordre, vous y resterez lié, à moins d’intégrer un autre outil (ce qui contredirait l’objectif). Quant à la « cohérence de la pile technologique », o9 est cohérent – il est principalement bâti sur la pile technologique Microsoft (.NET, etc.) et utilise une structure de base de données graph qu’ils ont développée. Nous ne voyons donc pas de problèmes tels que la duplication des données entre les sous-systèmes ou une logique incohérente. Le compromis : adopter o9 signifie aligner vos processus sur l’approche plateforme d’o9, ce qui peut représenter un grand changement. Mais, du point de vue informatique, cela simplifie probablement le paysage comparé à de multiples systèmes hérités. En bref, o9 n’est pas un Frankenstein – c’est un cerveau ingénieusement conçu (quoique très complexe). C’est positif pour la maintenabilité à long terme si le client l’adopte pleinement, mais cela peut être accablant au début. Nous pensons qu’o9 répond bien au critère de « cohérence de la pile technologique ».

Skepticism Toward Hype: S’il y a un fournisseur dans cette liste qui déclenche l’alarme du « hype », ce pourrait être o9. Ils utilisent les mots à la mode de manière libérale – Enterprise Knowledge Graph™, Digital Brain, AI/ML, et maintenant Generative AI. Leur marketing est soigné et parfois vague sur les spécificités techniques, se concentrant plutôt sur les bénéfices globaux. Par exemple, ils vante un cadre IA/ML, mais vous entendrez moins parler précisément des algorithmes qu’ils utilisent (alors qu’un fournisseur comme Lokad ou ToolsGroup pourrait discuter ouvertement de l’utilisation de modèles probabilistes ou de réseaux neuronaux, o9 reste plus général). Certains observateurs de l’industrie ont en effet accusé o9 d’être « du théâtre IA », exhibant des démonstrations tape-à-l’œil avec beaucoup d’analyses tout en recourant en coulisses à des techniques assez standards ⁴². Le rapport précédemment cité par Lokad plaçait o9 vers le bas d’un classement, évoquant « une tonne de battage médiatique sur l’IA » et le fait que des fonctionnalités interactives triviales étaient étiquetées comme de l’IA ⁴². Cette critique sévère, probablement émanant d’un concurrent, résonne avec l’idée que le marketing d’o9 est en avance sur une réalité encore à démontrer. o9 nomme également ses fonctionnalités de manière futuriste – par exemple en affirmant posséder un moteur de « quantum learning » (un terme emprunté à leur acquisition Evo en 2023) qui sonne innovant mais n’est essentiellement qu’une approche d’ensemble en machine learning. Ils évoquent la « technologie de cube graph » reliant les données ⁴⁵ ce qui est correct, mais qui pourrait mystifier les clients. Demand sensing et digital twin sont d’autres mots à la mode qu’o9 pourrait utiliser (bien qu’ils les présentent comme un knowledge graph/digital brain plutôt que comme un twin, pour être équitables). En tant que sceptique, on doit se demander : est-ce que des entreprises obtiennent les résultats spectaculaires qu’o9 laisse entendre (comme une augmentation de 10 % des revenus uniquement grâce à une meilleure planification) ? Certaines rapportent effectivement de bons résultats, mais les références indépendantes se font plus rares puisque o9 est plus jeune que, par exemple, SAP. Un autre aspect du battage médiatique : o9 se positionne souvent comme une plateforme cloud plug-and-play pouvant être implémentée plus rapidement que les anciens systèmes. Pourtant, certaines implémentations ont été rapportées comme prenant un temps considérable et nécessitant du consulting (car modéliser une entreprise entière n’est pas trivial). Ainsi, l’idée que vous pouvez simplement déployer o9 et obtenir une planification intégrée instantanée est très optimiste. C’est généralement plus rapide que d’implanter plusieurs outils séparés, mais pas « instantanément ». Cela dit, nous ne devons pas minimiser les réussites d’o9 : ils ont réellement introduit une technologie moderne et une interface utilisateur innovante dans un secteur qui en avait besoin, et de nombreux clients en sont satisfaits. Ils offrent sans doute une capacité de planification bien supérieure à ce dont disposaient leurs clients. Ainsi, le battage médiatique est en partie justifié – o9 est un système de planification de nouvelle génération. L’essentiel est d’analyser leurs affirmations : s’ils déclarent « notre IA optimisera votre entreprise de manière autonome », prenez cela avec précaution. Au lieu de cela, sachez que « notre plateforme vous permettra de modéliser et d’optimiser votre entreprise, mais votre équipe devra intervenir pour la piloter ». Nous encourageons les clients potentiels à demander des démonstrations concrètes ou des preuves pour toute affirmation ambitieuse, notamment en ce qui concerne la précision des prévisions pilotées par l’IA ou les améliorations de ROI. Le cadre est solide ; c’est son usage qui déterminera les résultats. En conclusion, le marketing d’o9 est assurément agressif en termes de mots à la mode, ce qui nous incite à adopter un scepticisme sain. Cependant, en termes de substance, ils disposent d’une plateforme puissante qui soutient une grande partie de leurs promesses – tout en gardant à l’esprit que tout ce qui est étiqueté « IA » n’est pas forcément une innovation révolutionnaire (parfois, il s’agit simplement d’un calcul efficace). Nous leur attribuons une note moyenne en termes d’honnêteté marketing : ils possèdent une véritable innovation technologique, mais ils poussent les limites du battage médiatique plus que d’autres, ce qui nécessite une vérification rigoureuse de la part des acheteurs.

Summary: o9 Solutions apporte une plateforme d’une ampleur et d’une intégration impressionnantes à l’optimisation retail, visant à servir de « Digital Brain » reliant le marchandisage, la supply chain et les décisions de tarification. Son architecture Knowledge Graph et son moteur in-memory permettent une planification rapide et simultanée ainsi qu’une analyse riche de scénarios que peu peuvent égaler. o9 supporte la considération conjointe de la tarification, de la demande et de l’approvisionnement, rendant possible l’alignement des stratégies d’assortiment et de tarification avec les contraintes de stocks et d’approvisionnement en un seul outil – une vision d’un véritable IBP. Il exploite l’IA/ML dans la prévision et l’analyse, bien que l’étendue de ses avancées dans ce domaine soit discutable ⁴². Le système peut certainement intégrer des facteurs complexes et de grands ensembles de données, quoique cela demande une forte puissance de calcul. La scalabilité est de niveau entreprise (utilisé par des sociétés valant des milliards de dollars), mais la rentabilité peut poser question (l’approche in-memory peut être gourmande en matériel) ⁴. o9 outille les planificateurs grâce à l’automatisation des calculs et de la planification par scénarios, bien qu’il s’agisse souvent d’un système d’aide à la décision plutôt que d’un décideur entièrement autonome. Techniquement, c’est une plateforme cohésive développée en interne, évitant les écueils des suites Frankenstein. Les principales réserves concernent sa propension au battage médiatique – certaines affirmations de magie IA ou de transformation « instantanée » doivent être examinées avec prudence – ainsi que la complexité d’implanter un système aussi complet. Pour les organisations tournées vers l’avenir et prêtes à investir dans une plateforme de planification unifiée, o9 est un concurrent de premier plan, offrant une architecture pérenne et une flexibilité certaine. Mais la réussite d’un projet o9 nécessite de distinguer le vernis marketing de la réalité, et de s’assurer que la solution est configurée pour exploiter véritablement son potentiel (plutôt que de reproduire d’anciens processus sur un système flambant neuf). Dans notre classement sceptique, o9 obtient une note élevée pour sa vision et son intégration, une note modérée pour sa différenciation en IA éprouvée, et nécessite une vérification minutieuse de ses promesses alourdies de mots à la mode. Il demeure l’une des plateformes les plus avancées du marché – mais il convient d’aborder son usage avec les yeux ouverts pour que la substance corresponde bien au discours commercial.

Sources: Critique du design in-memory et des affirmations IA d’o9 ⁴ ; revendication de la plateforme intégrée RGM (tarification) et de planification d’o9 ⁴¹ ; perspective de Blue Yonder sur l’utilisation des données pour relier l’impact des prix aux stocks (approche similaire à celle qu’o9 utiliserait) ²⁷.

4. ToolsGroup – Proven Inventory Optimization, Evolving into Unified Retail Planning (with AI Add-ons)

ToolsGroup est un fournisseur établi (fondé en 1993) historiquement connu pour son logiciel Service Optimizer 99+ (SO99+) axé sur la prévision de la demande et l’optimisation de stocks. Il possède un fort héritage dans le secteur manufacturier et de la distribution, mais compte également de nombreux clients dans le retail et les biens de consommation pour la planification des réapprovisionnements. Ces dernières années, ToolsGroup a élargi ses capacités par acquisitions – notamment l’acquisition de la suite de planification retail JustEnough et d’une société d’IA, Evo – afin d’offrir une plateforme d’optimisation retail plus complète incluant la planification d’assortiment et de marchandisage, la prévision de la demande, l’optimisation de stocks, et désormais l’optimisation tarifaire ⁴⁶ ⁴⁷. La marque de fabrique de ToolsGroup a longtemps été son utilisation de la prévision probabiliste pour la planification des stocks, ainsi qu’une philosophie de planification de supply chain hautement automatisée reposant sur le taux de service. Désormais, avec les modules acquis et les améliorations en IA, il vise à optimiser conjointement stocks et tarification, offrant ainsi une planification retail de bout en bout (qu’ils qualifient de « planification centrée sur la décision »). Nous classons ToolsGroup comme un acteur solide et techniquement compétent, possédant une expertise approfondie en optimisation de stocks, bien qu’il faille noter qu’il est en pleine transition pour intégrer de nouvelles composantes.

Optimisation conjointe: Historiquement, ToolsGroup s’est concentré sur le côté stocks – en assurant les bons niveaux de stocks pour atteindre le taux de service cible, tout en tenant compte de l’incertitude. La tarification et l’assortiment étaient hors de son champ d’action. Avec l’acquisition de JustEnough (spécialiste de la planification financière des marchandises, de l’assortiment et de l’allocation) et l’intégration de l’IA d’optimisation des prix d’Evo, ToolsGroup fait désormais étalage de sa capacité à optimiser ensemble la tarification et les stocks. Par exemple, leur nouvelle offre comprend un logiciel de Retail Pricing qui peut simuler comment les changements de prix affectent la demande et se répercuter sur le chiffre d’affaires ⁴⁸ ⁴⁹, et surtout, ce faisant, il offre une visibilité complète des niveaux de stocks ⁴⁹. L’intégration de la tarification avec les stocks signifie que le système est conscient des stocks disponibles lorsqu’il suggère des actions sur les prix – une nécessité pour l’optimisation conjointe (cela ne sert à rien de baisser les prix si vous n’avez aucun stock à vendre, par exemple). Ils soulignent que leur outil de tarification offre “une vue complète des stocks actuels et du taux de vente” afin que les décisions de tarification soient prises dans le contexte des stocks à travers la supply chain ⁴⁹ ⁵⁰. Cela suggère une approche coordonnée : si les stocks sont élevés, le système pourrait déclencher des réductions ; si les stocks sont faibles, il pourrait maintenir le prix voire suggérer de l’augmenter (si cela correspond à la stratégie). De plus, la feuille de route de ToolsGroup avec Evo est de fournir une optimisation dynamique des prix qui alimente la planification d’approvisionnement ⁵¹ ⁵². L’IA d’Evo était spécialisée dans la liaison des décisions de tarification et des stocks – leur PDG a déclaré que l’objectif est de fournir “des calculs optimaux de prix et de stocks” de concert pour stimuler de meilleures décisions à travers la chaîne de valeur ⁵³. Cela indique un algorithme d’optimisation unifié ou du moins des algorithmes étroitement liés : l’un qui trouve le prix maximisant le profit compte tenu des contraintes de stocks et de la demande attendue, et l’autre qui détermine le plan de stocks qui soutient cette demande aux prix choisis. Il est encore tôt – Evo a été acquis fin 2023 ⁴⁷, donc l’intégration est probablement en cours – mais ToolsGroup a clairement l’intention de regrouper l’optimisation de la tarification et des stocks sous un même toit, plutôt qu’en étapes séquentielles. Concernant l’assortiment, le composant JustEnough fournit des outils pour la planification de l’assortiment et de l’allocation (décider quels produits vont dans quels magasins, comment répartir le stock initial, etc.). Cela se place désormais aux côtés de la prévision de la demande et du réapprovisionnement. Si bien intégrée, cela signifie que ToolsGroup peut optimiser l’ensemble du cycle de vie du produit : planifier l’assortiment, définir les allocations initiales, prévoir la demande, surveiller et réapprovisionner les stocks, et ajuster la tarification (réductions) vers la fin de vie. Les éléments sont tous présents sur le papier. La question est de savoir à quel point ils fonctionnent de manière fluide ensemble. Puisque ces produits étaient séparés, l’intégration pourrait ne pas encore être parfaitement homogène (bien que ToolsGroup affirme disposer d’une “architecture de solution modulaire” qu’ils regroupent de manière cohérente ⁵⁴). Nous prévoyons que l’optimisation conjointe dans le cas de ToolsGroup est actuellement plus séquentielle (le module de tarification prend une prévision du module de prévision, optimise les prix ; le module de stocks prend la demande résultante et optimise les stocks). Au fil du temps, avec l’analytique avancée d’Evo, ils pourraient fusionner ces deux processus en une boucle unique qui optimise directement le profit (prix et quantité). Pour l’instant, nous reconnaissons à ToolsGroup qu’il s’oriente résolument vers l’optimisation conjointe – peu de fournisseurs dans sa catégorie disposant à la fois de capacités en tarification et en stocks. Quelques premiers résultats : ToolsGroup (avec Evo) a collaboré avec des détaillants tels que Decathlon sur la tarification et a constaté des augmentations de marge tout en respectant les contraintes de stocks ⁵⁵ ⁵⁶ (les informations de cas suggèrent des tests A/B itératifs pour trouver des prix optimaux qui améliorent la marge sans nuire à l’image de marque, réalisés de manière informée par les stocks). C’est une forme pratique d’optimisation conjointe (tests de prix guidés par les données de stocks et de marge). En résumé, ToolsGroup évolue rapidement d’un acteur de niche de l’optimisation des stocks à une suite d’optimisation holistique du retail. Il est probable qu’il soit derrière Lokad ou o9 en ce qui concerne la profondeur d’unification de l’optimisation à ce stade, mais il est sur la bonne voie et couvre déjà les trois piliers (stocks, tarification, assortiment).

Prévision probabiliste & IA: ToolsGroup a été un pionnier de la prévision probabiliste de la demande pour supply chain. Bien avant que ce soit à la mode, SO99+ générait des distributions de la demande plutôt que des chiffres uniques, ce qui lui permettait de calculer les niveaux de stocks optimaux pour une probabilité de service cible. Cette approche le distingue de nombreux outils traditionnels qui utilisaient des prévisions moyennes et des formules de stock de sécurité. ToolsGroup détient un portefeuille important de technologies dans ce domaine – par exemple, en utilisant des simulations Monte Carlo ou des modèles de probabilité analytiques pour prévoir la variabilité de la demande par SKU, puis en déterminant des politiques de stock. Cela a été l’une de leurs principales forces ; les clients atteignaient souvent des taux de service élevés avec moins de stocks parce que les méthodes de ToolsGroup capturaient mieux l’incertitude (par opposition à un stock de sécurité simpliste). Ils continuent d’éduquer le marché sur la valeur de la prévision probabiliste (leurs supports en parlent comme étant essentiels dans des environnements incertains ⁵⁷). Cependant, une note critique : par le passé, ToolsGroup rapportait souvent encore des indicateurs tels que le MAPE à ses clients et dans ses communications marketing. L’analyse de Lokad a signalé une incohérence où ToolsGroup fait la promotion de prévisions probabilistes depuis 2018 parallèlement à des allégations de réduction du MAPE, bien que “le MAPE ne s’applique pas aux prévisions probabilistes.” ¹⁹. Cela implique soit que leur marketing ne s’est pas encore adapté à la méthodologie (en utilisant un indicateur familier même s’il n’est pas entièrement applicable), soit qu’ils génèrent peut-être encore une prévision de valeur attendue à titre de comparaison. Quoi qu’il en soit, ils adoptent clairement une approche probabiliste. Du côté IA/ML, ToolsGroup a intégré davantage de machine learning pour gérer les facteurs de la demande et la reconnaissance de schémas. Traditionnellement, leurs prévisions étaient plus statistiques (comme la méthode de Croston pour la demande intermittente, etc.), mais désormais, ils proposent des fonctionnalités telles que l’intégration de facteurs causals, la régression pour les promotions, et même des ensembles de machine learning. L’acquisition d’Evo apporte une IA très moderne – le “quantum learning” d’Evo est fondamentalement un algorithme avancé de ML (possiblement un ensemble propriétaire ou une technique d’apprentissage par renforcement) visant à trouver rapidement des décisions optimales ⁵⁸. L’intégration d’Evo par ToolsGroup indique explicitement qu’elle ajoute “une optimisation non linéaire, du quantum learning, et de l’analytique prescriptive avancée” à leurs solutions ⁵². Cela suggère un renforcement de la sophistication en IA, notamment pour les décisions de tarification et de promotion qui sont de nature non linéaire. Ils ont également acquis une société nommée AI.io (anciennement appelée Halo Business Intelligence) il y a quelques années, qui leur a fourni un environnement de travail de prévision de la demande piloté par l’IA. Ainsi, ToolsGroup infuse certainement l’IA. Ceci étant dit, leur communication marketing sur l’IA a parfois été quelque peu dubieuse, comme l’a relevé l’étude de Lokad : “ToolsGroup présente des capacités étendues, cependant leurs revendications concernant l’IA sont douteuses. Les documents publics font allusion à des modèles de prévision antérieurs à 2000. Les affirmations concernant le ‘demand sensing’ ne sont pas étayées par la littérature scientifique.” ¹⁹. Cela implique que, jusqu’à récemment, ToolsGroup rebrandait peut-être des méthodes de prévision essentiellement anciennes (comme Croston, ARIMA) sous le terme “IA” sans recourir à du véritable machine learning moderne. Et que leur utilisation de termes tels que “demand sensing” (qu’ils mentionnaient dans des brochures) n’était pas étayée par une innovation réelle. Nous prenons cela comme un avertissement pour examiner de près les revendications d’IA de ToolsGroup. Cependant, avec l’ajout récent d’EvoAI (2023), nous nous attendons à ce que la substance de l’IA de ToolsGroup se soit accrue – Evo était une entreprise jeune ancrée dans le ML pour la tarification/stocks, et ToolsGroup met en avant de nouvelles fonctionnalités concrètes issues de celle-ci (par exemple, la sélection automatisée de modèles, des algorithmes réactifs qui s’adaptent aux changements récents, etc.). De plus, l’approche probabiliste de ToolsGroup est en elle-même une forme d’IA (modélisation stochastique), même si ce n’est pas du “machine learning” – c’est une technique analytique sophistiquée qui faisait défaut chez beaucoup d’autres. Ainsi, en termes de performance de prévision, ToolsGroup est solide. En ce qui concerne la nouvelle IA, ils rattrapent leurs pairs. Dans l’ensemble, ToolsGroup offre une qualité de prévision fiable et désormais plus de visibilité sur les moteurs de la demande et les relations entre prix et demande grâce au ML. Nous leur attribuons une note élevée en matière de prévision probabiliste (l’un des rares à l’avoir fait de manière extensive), et une note moyenne en innovation IA (ils s’améliorent mais ont un passé d’un certain battage médiatique). La combinaison de l’ancien et du nouveau peut s’avérer puissante si elle est bien exécutée : par exemple, utiliser le ML pour détecter un changement de schéma (par exemple, un bouleversement dû à la COVID), puis utiliser un modèle probabiliste pour ajuster les objectifs de stocks en conséquence. ToolsGroup utilise probablement de telles approches hybrides. Il faut simplement s’assurer qu’ils exploitent véritablement le ML là où cela est avantageux et non pas seulement comme des mots à la mode.

Prise de décision économique: Traditionnellement, l’approche de ToolsGroup en matière de stocks était encadrée comme une optimisation du taux de service – vous fixiez un taux de service cible ou un taux de remplissage et leur algorithme trouve le stock minimum pour l’atteindre compte tenu de l’incertitude. Cela est indirectement économique (un meilleur service évite les ventes perdues, moins de stocks évitent les coûts de détention), mais cela ne maximise pas explicitement le profit. Ils ont toutefois intégré l’optimisation multi-niveaux des stocks (MEIO) qui équilibre intrinsèquement les stocks et les coûts de rupture de stock, etc., une optimisation fondée sur des principes économiques. Avec leur vision plus récente, la rentabilité est davantage mise en avant. Le PDG de ToolsGroup a déclaré que la combinaison avec JustEnough vise à offrir aux détaillants “une vue à 360 degrés en temps réel, prédictive et exploitable… permettant aux clients d’améliorer plus efficacement la disponibilité des produits et de surpasser la concurrence dans la gestion de la demande volatile d’aujourd’hui” ⁵⁹. Alors que cette citation met l’accent sur le service et l’agilité, le communiqué de presse lié à l’acquisition d’Evo est plus direct : “renforce notre avance avec l’optimisation dynamique des prix… nous permettant de réaliser le prochain saut vers une planification centrée sur la décision… essentielle pour offrir la supply chain autonome de demain” ⁵². Le terme “centré sur la décision” implique de se focaliser sur le résultat de la décision (souvent financier). Le fondateur d’Evo a évoqué la définition d’une vision pour “des décisions plus intelligentes pour les gestionnaires humains grâce à des calculs optimaux de prix et de stocks” ⁵³ – ce qui signifie clairement utiliser l’optimisation pour maximiser un objectif (probablement le profit ou le chiffre d’affaires) plutôt que de simplement atteindre des cibles de service. Et en effet, “l’IA réactive d’Evo apporte un ingrédient essentiel pour offrir la supply chain autonome” ⁵⁸ – vraisemblablement, cet ingrédient consiste à ajuster en continu les décisions en fonction des résultats, ce qui s’apparente à maximiser des indicateurs de performance. Du côté de la tarification, la rentabilité est évidemment primordiale – la solution de tarification de ToolsGroup consiste à “maximiser la rentabilité en créant une stratégie de tarification basée sur les données” ⁶⁰. Elle permet une tarification basée sur des règles mais aussi du ML pour s’adapter aux variations de la demande des consommateurs, et pour “maximiser la marge bénéficiaire” dans des limites fixées ⁶¹. La mention de “Des prix différents peuvent être créés… avec une vue complète de… des stocks et du taux de vente, aidant à répondre à la demande et à minimiser les coûts à travers la supply chain.” ⁴⁹ montre que l’outil de tarification ne se concentre pas uniquement sur la marge isolément, mais prend également en compte les coûts de détention des stocks et potentiellement l’évitement des réductions de prix (minimisation des coûts). C’est une pensée économique – des décisions de tarification qui intègrent les coûts de la supply chain. En matière de stocks, ToolsGroup peut également intégrer le coût de détention par rapport au coût de rupture de stock si configuré, optimisant ainsi les taux de service de manière économique. En effet, les objectifs de service peuvent être dérivés d’un modèle économique (par exemple, un taux de service plus élevé pour les produits à forte marge). On ne sait pas si ToolsGroup le fait explicitement, mais les clients effectuent souvent une telle classification en externe. Maintenant, avec l’analytique prescriptive d’Evo, nous nous attendons à ce que ToolsGroup évolue vers la recommandation de décisions optimales pour le profit (comme la quantité à stocker et le prix à fixer pour maximiser le profit attendu, compte tenu de l’incertitude). Les éléments constitutifs sont présents, et l’équipe d’Evo disposait vraisemblablement de cette méthodologie (leurs parcours académiques laissant présager une expertise en recherche opérationnelle). Un léger avertissement : la communication de ToolsGroup fait encore souvent référence à des indicateurs traditionnels (service, réduction des stocks) plutôt qu’au profit direct. Mais c’est similaire à ce que font d’autres acteurs du domaine de la supply chain. Nous disposons de preuves qu’ils intègrent davantage la rentabilité – par exemple, leur fonctionnalité d’assortiment rationalisé (probablement issue de JustEnough) visant à éliminer les SKU non rentables, alignant l’assortiment sur la contribution financière. De plus, les témoignages clients mentionnent la réduction des stocks et une amélioration des ventes/service (ce qui se traduit par des améliorations du profit). Il n’existe pas d’exemple public de ToolsGroup maximisant explicitement un indicateur de profit, mais la combinaison de l’optimisation des prix et des stocks y tend par nature. Nous attribuerons à ToolsGroup des notes assez élevées ici, en notant leur approche de longue date du “service au moindre coût” et leur nouveau virage vers une tarification basée sur la marge. Ils ne sont peut-être pas encore aussi obsédés par le coût d’opportunité que Lokad, mais ils sont définitivement au-delà de solutions heuristiques simplistes. Une critique à mentionner : l’analyse de Lokad suggérait que les documents de ToolsGroup étaient quelque peu désuets – utilisant le MAPE, etc., ce qui pourrait indiquer qu’ils ne présentent pas pleinement les choses en termes de coût attendu publiquement ⁶². Cependant, l’ajout d’Evo et les discussions autour de “les meilleurs résultats financiers” ⁶³ pour les clients utilisant une optimisation combinée des prix et des stocks ⁶³ constituent un signal fort d’un objectif économique central.

Scalabilité et Efficacité Coût : L’original SO99+ de ToolsGroup était typiquement déployé en interne ou en solution hébergée pour des entreprises de taille moyenne à grande. Il n’est pas aussi lourd que certains grands systèmes APS ; par conception, il se concentrait sur les « parties difficiles » (prévision, calculs de stocks) et non sur une intégration de données gigantesque. De nombreuses entreprises de taille moyenne l’exécutaient avec succès. Il est assez optimisé d’un point de vue mathématique, ce qui signifie que le calcul pour l’optimisation de stocks n’est pas énorme (résoudre la répartition des stocks via des algorithmes et peut-être la programmation linéaire pour du multi-échelon). Pour la prévision de la demande, ils disposaient de leur propre moteur capable de traiter un grand nombre de séries temporelles pendant la nuit (par exemple). Ils offrent désormais une option SaaS cloud complète, qui est probablement plus facile à faire évoluer selon les besoins. Dans le rapport Gartner 2024, ToolsGroup était un nouvel arrivant et a été noté pour un « coût d’entrée abordable » et des « prix transparents », et utilisé comme solution globale unique pour certains (ce qui implique qu’il peut évoluer à l’échelle mondiale) ⁶⁴ ⁶⁵. Cela suggère que ToolsGroup est considéré comme relativement rentable et évolutif pour sa catégorie. En effet, leur focalisation historique sur le milieu de marché signifiait qu’ils devaient être plus « out-of-the-box » et ne pas nécessiter une armée d’IT. Dans le retail, les volumes de données peuvent être importants (niveau magasin-SKU). JustEnough (le système retail acquis) était reconnu pour servir de grands détaillants (il comptait des clients comme Sephora, je crois) de sorte qu’il peut gérer des assortiments de grande ampleur. Cependant, certains aspects comme l’optimisation des prix (lorsqu’on effectue une tarification fine au niveau magasin) peuvent devenir intensifs en données. Il est probable que le déploiement typique de ToolsGroup soit encore quelque peu orienté en mode batch – par exemple, des reprévisions nocturnes ou hebdomadaires et des mises à jour de stocks – plutôt qu’en temps réel, ce qui convient à de nombreux contextes. Cela signifie qu’ils n’ont pas nécessairement besoin de tout garder en mémoire 24h/24 ; ils peuvent calculer puis libérer la mémoire. C’est plus rentable qu’une approche constante en mémoire. D’autre part, pour s’intégrer à une tarification dynamique, ils pourraient avoir besoin de cycles de calcul plus fréquents. Ils vantent une « IA réactive » avec Evo, signifiant des recalculs plus rapides lorsque les conditions changent ⁵⁸. La technologie d’Evo pourrait permettre une ré-optimisation quasi en temps réel (Evo, étant une startup, utilisait probablement le cloud et possiblement le GPU computing pour accélérer le calcul). ToolsGroup a également acquis Onera en 2022 pour la visibilité des stocks en temps réel et l’optimisation de l’exécution, ce qui signifie qu’ils se lancent dans les décisions de fulfillment e-commerce en temps réel ⁶⁶. Ces ajouts pourraient augmenter la puissance de calcul nécessaire. Mais compte tenu de leur positionnement sur le marché, ToolsGroup viserait à réaliser cela efficacement pour séduire également les détaillants de taille moyenne, et pas uniquement les méga-détaillants. L’architecture est désormais quelque peu modulaire : le cœur SO99+ (éventuellement en C++) complété par des services cloud qui s’articulent autour et se connectent aux modules JustEnough (qui pourraient être en .NET ou en Java). L’intégration de ces derniers pourrait temporairement ajouter une surcharge (deux systèmes communiquant). Mais ToolsGroup intègre activement – par exemple, « Grâce au moteur EvoAI récemment intégré, JustEnough prend la tête de la planification retail pilotée par l’IA » ⁶⁷, indiquant qu’ils intègrent Evo dans la solution JustEnough/ToolsGroup plutôt que de la garder séparée. L’empreinte de ToolsGroup est généralement plus légère que celle de SAP ou Blue Yonder. Par exemple, un projet ToolsGroup pourrait ne pas nécessiter une équipe IT interne pour gérer d’énormes serveurs – ils le gèrent en mode SaaS. Ils mentionnent que « l’architecture modulaire permet aux clients de sélectionner les produits dont ils ont besoin et de les assembler dans une solution cohérente » ⁵⁴ – ce qui implique que vous n’avez pas à charger tout si vous n’en avez pas besoin, ce qui aide l’évolutivité (vous pouvez exécuter uniquement le moteur de stocks si c’est tout ce dont vous avez besoin). En résumé, ToolsGroup est modérément évolutif (adapté à de nombreux grands détaillants, mais peut-être pas éprouvé à l’échelle des plus grandes chaînes d’hypermarchés au niveau mondial), et tend à être rentable (surtout avec leur tarification transparente et leur focalisation sur l’automatisation, diminuant la charge de travail des planificateurs). Ils ne seront pas aussi ultra-rapides qu’un système concurrent en mémoire pour d’immenses ensembles de données, mais ils ne nécessiteront pas non plus des ressources astronomiques pour obtenir des résultats. Étant donné la note positive de Gartner sur les coûts et les nombreux clients de taille moyenne à grande que possède ToolsGroup, nous les considérons comme relativement efficaces. De plus, ils mentionnent une offre « Inventory Hub » pour la détection d’événements supply chain en temps réel ⁶⁵ qui montre qu’ils se modernisent pour le temps réel sans, vraisemblablement, avoir besoin d’un matériel démesuré (probablement via du streaming processing). Il existe peu de plaintes publiques concernant la performance de ToolsGroup, ce qui laisse entendre qu’elle est adéquate. Par conséquent, ToolsGroup obtient une bonne note sur ce critère, avec une légère mise en garde : l’intégration de plusieurs acquisitions pourrait temporairement mettre le système sous pression s’il n’est pas optimisé (mais jusqu’à présent, les signes sont encourageants).

Gestion des Facteurs Complexes du Retail : Historiquement, ToolsGroup s’est illustré dans la gestion de l’incertitude de la demande et de la variabilité, incluant la demande intermittente, les produits à faible rotation et la variabilité d’approvisionnement. Il n’a peut-être pas été aussi spécialisé dans les phénomènes spécifiques au retail comme la cannibalisation ou la durée de vie des produits dès le départ. Cependant, avec la suite JustEnough, ils ont acquis des compétences dans le domaine retail : JustEnough offrait la prévision de promotions, l’allocation (qui prend en compte la capacité des magasins et le merchandising) et la planification des baisses de prix. Ainsi, ToolsGroup dispose désormais de fonctionnalités pour les promotions – par exemple, ils peuvent modéliser l’effet d’une promotion et le répartir dans le temps, ce qui traite en soi la cannibalisation de manière basique (si une promotion génère des ventes anticipées, les périodes ultérieures en pâtissent, etc.). Identifient-ils automatiquement la cannibalisation entre articles ? Probablement pas aussi automatiquement que RELEX, mais ils peuvent intégrer les effets promotionnels s’ils sont connus. Pour les effets de substitution (ruptures de stocks provoquant des ventes d’articles alternatifs), ToolsGroup n’a pas mis en avant cet aspect dans les documents consultés. Cela pourrait rester un manque à moins d’être configuré manuellement. Pour les effets halo (complémentarité), il en va de même – il faudrait modéliser manuellement les relations ou utiliser une approche par IA. C’est un domaine où leur nouvelle IA (Evo) pourrait aider en détectant des corrélations. Le moteur d’Evo pourrait potentiellement exploiter les données transactionnelles pour ajuster les prévisions ou les stratégies de tarification pour des articles connexes. Sans preuve spécifique, nous supposerons que ToolsGroup peut gérer ces points avec quelques ajustements, bien que cela ne fasse pas partie de ses atouts historiques. Expiration et périssables : ToolsGroup comptait quelques clients dans la distribution alimentaire, mais on n’est pas certain de son optimisation au niveau des produits frais en magasin. Ce n’est probablement pas leur priorité principale. Ils peuvent intégrer des délais et des tailles de lots, mais les contraintes de péremption nécessiteraient une modélisation explicite (par exemple, traiter les stocks arrivant à expiration comme un SKU distinct ou ajuster les prévisions à la baisse au fil du temps). Le module d’allocation de JustEnough pourrait gérer des produits saisonniers (en s’assurant qu’ils soient écoulés avant la fin de la saison grâce à des baisses de prix), ce qui est, en concept, lié aux périssables. En effet, l’optimisation des baisses de prix (faisant partie de JustEnough) consiste essentiellement à synchroniser les réductions de prix pour liquider les stocks sans surplus – analogue à la gestion de « l’expiration » en fin de saison. L’outil de tarification de ToolsGroup aidera en recommandant quand baisser les prix et de combien afin d’éviter l’obsolescence tout en maximisant les revenus ⁴⁹. Ainsi, ils gèrent l’aspect économique de la périssabilité (vendre pour éviter le gaspillage). Concernant la localisation d’assortiment : la planification d’assortiment de JustEnough permet de regrouper les magasins et d’adapter les assortiments, de sorte que ToolsGroup peut optimiser les assortiments en fonction des schémas de demande locaux et des contraintes d’espace. Cela répond indirectement à la cannibalisation (si deux articles se cannibalisent, une optimisation d’assortiment pourrait décider de n’en retenir qu’un dans des magasins plus petits, etc.). Contraintes d’espace et mise en rayon : ToolsGroup, via JustEnough, peut modéliser le nombre de façades ou la capacité de rayonnage dans les magasins, ce qui influence l’allocation et les décisions de réapprovisionnement (si une étagère peut contenir X, il ne faut pas en envoyer plus que X). Ce n’est pas aussi détaillé qu’une solution de planogramme, mais au niveau de la planification, c’est couvert. Promotions : ToolsGroup gère la prévision des promotions et peut planifier les stocks pour celles-ci (ils disposent d’études de cas où ils ont amélioré la disponibilité en magasin pendant les promotions). La nouvelle IA améliore probablement la prédiction des effets promotionnels en analysant plus précisément les promotions passées (peut-être de façon similaire à la demande sensing à court terme, bien que Lokad ait critiqué les dires sur le « demand sensing » comme non étayés ⁶⁸). Concernant spécifiquement la cannibalisation/effet halo : nous n’avons pas trouvé de références directes, de sorte que cela repose probablement encore sur l’expertise du planificateur pour ajuster. La philosophie de ToolsGroup a toujours été de simplifier la vie des planificateurs – ils ont construit l’automatisation pour que ces derniers puissent gérer par exception. Ils disposent probablement d’exceptions en cas de rupture de stock ou de ventes anormales, mais il reste flou de savoir s’ils lient cela à une logique de substitution. Au vu des preuves modérées, nous classons ToolsGroup comme compétent mais pas leader dans la gestion des facteurs complexes. Ils couvrent les promotions et les baisses de prix (besoins classiques du retail), disposent d’une logique d’assortiment, mais pour ce qui est des interactions de produits et des périssables, ils pourraient ne pas être aussi avancés que RELEX. L’ajout de l’IA et leur orientation vers des ajustements « réactifs » pourraient éventuellement inclure la détection automatique de ces schémas. En 2021, la critique de Lokad était que les dires de ToolsGroup sur le « demand sensing » (utiliser les données récentes pour ajuster les prévisions) n’étaient pas bien étayés ⁶⁸. Il se peut donc qu’à ce moment-là, ils manquaient d’un véritable algorithme à cet effet. Peut-être qu’à présent, ils en disposent (grâce à Evo ou à des développements internes). Dans l’ensemble, ToolsGroup gère bien les fondamentaux de la planification retail (variabilité de la demande, promotions, fin de cycle), et est correct en matière d’assortiment, mais il reste à la traîne sur les aspects de pointe (par exemple, la modélisation par ML de la cannibalisation, la substitution).

Automatisation : ToolsGroup a toujours misé sur l’automatisation et la planification « sans surveillance ». En effet, un argument de vente de SO99+ était qu’il pouvait définir automatiquement les politiques de stock et générer des commandes de réapprovisionnement avec une intervention minimale du planificateur. De nombreux clients rapportent qu’ils passent beaucoup moins de temps à gérer les problèmes de prévision ou de stocks après avoir mis en place ToolsGroup, car le système s’ajuste automatiquement aux changements et ne signale que les exceptions. Ils utilisent des termes tels que « auto-adaptatif » pour leurs prévisions – signifiant qu’il s’adapte lui-même aux nouveaux schémas de demande, réduisant ainsi la nécessité de modifier constamment les prévisions. Le concept de « Powerfully Simple » (l’un de leurs slogans) visait à simplifier les tâches des planificateurs grâce à l’automatisation. En pratique, une configuration ToolsGroup exécute souvent des processus batch nocturnes pour mettre à jour les prévisions et les cibles de stocks, puis suggère des commandes pour chaque article-localisation. Les planificateurs ne passent ensuite en revue que les articles qui provoquent des exceptions (comme un taux de service très bas ou des stocks très élevés). C’est essentiellement de la lights-out planning pour une grande partie de l’assortiment. Un cas (relaté dans d’anciennes communications marketing) indiquait qu’un client avait automatisé 90 % de ses réapprovisionnements de SKU, ne passant manuellement en revue que les 10 % d’exceptions principales. C’est un bon niveau d’autonomie. Maintenant, avec l’intégration de JustEnough, qui inclut des tâches de planification traditionnellement manuelles (par exemple, élaborer des plans d’assortiment, définir l’allocation initiale, créer des plans financiers), ToolsGroup devra probablement trouver un équilibre entre l’automatisation et la contribution de l’utilisateur. La planification d’assortiment requiert généralement l’intervention des marchands sur le plan stratégique, ce qui ne peut pas être entièrement automatisé. Toutefois, ToolsGroup peut automatiser l’analyse sous-jacente (comme mettre en évidence les SKU sous-performants à éliminer ³³). Du côté des prix, la tarification dynamique peut être automatisée jusqu’à un certain point – le module de tarification de ToolsGroup permet de définir des règles puis d’appliquer automatiquement des modifications de prix dans le cadre de limites prédéfinies ⁶⁹. Par exemple, un détaillant pourrait laisser le système baisser automatiquement les prix des articles lorsque les stocks dépassent X jours d’approvisionnement, ce que l’outil peut exécuter sans calcul manuel. Ils mentionnent explicitement « établir des règles de tarification, puis les appliquer automatiquement dans des limites fixées » ⁶⁹ – ce qui correspond à une automatisation avec supervision. Ainsi, une grande partie de la prise de décision peut se faire sans intervention manuelle : le système surveille les stocks et la demande, et si les conditions satisfont les règles (peut-être renforcées par des suggestions d’IA), il peut appliquer un changement de prix. C’est une véritable action autonome en matière de tarification (bien que, dans de nombreux cas, cela puisse être soumis à l’approbation d’un responsable au départ). De même, leurs suggestions de réapprovisionnement peuvent être transmises automatiquement à l’ERP pour exécuter les commandes. ToolsGroup met souvent l’accent sur la gestion par exception, impliquant que, s’il n’y a pas d’exception, il faut avoir confiance dans la production du système. Avec l’IA d’Evo, ils laissent entendre une transition vers une « supply chain autonome » également ⁵⁸. Ils ont d’ailleurs utilisé cette expression, en accord avec la tendance de l’industrie. La technologie d’Evo pourrait permettre une ré-optimisation plus continue (comme ajuster les prévisions en milieu de mois si les ventes dévient, puis lancer automatiquement un nouveau réapprovisionnement). Les nouvelles fonctionnalités de ToolsGroup, telles qu’Inventory Hub (signaux en temps réel), suggèrent qu’ils peuvent détecter un événement (par exemple, un pic de demande) et réagir automatiquement en réaffectant des stocks ou en accélérant l’approvisionnement. Nous n’avons pas vu de détails, mais tel semble être leur objectif. Dans l’ensemble, ToolsGroup a toujours été orienté vers la planification sans surveillance – laissant le système gérer les décisions de routine. Il existe des preuves que certains de leurs clients fonctionnent avec une intervention minimale des planificateurs pour une grande partie de leurs opérations. Ainsi, ToolsGroup obtient une très bonne note en automatisation. La seule limitation apparaît lors du passage à de nouveaux domaines comme l’assortiment et la tarification, où la stratégie utilisateur joue un rôle plus important – mais même dans ces cas, ils offrent une automatisation des parties tactiques (comme la mise en évidence automatique des articles à baisser ou le classement systématique des magasins en fonction des ventes pour l’allocation). La combinaison d’une automatisation basée sur des règles (pour les contraintes opérationnelles) et de suggestions fondées sur l’IA (pour les décisions complexes) positionne ToolsGroup comme un fournisseur capable d’offrir une réduction significative de l’effort de planification manuel. En effet, Gartner a noté que « les planificateurs orchestrent les activités humaines et machines » avec certains outils récents – ToolsGroup semble s’inscrire dans cette orchestration (leurs workflows peuvent escalader automatiquement certaines décisions vers des humains, ce qui fait partie d’une boucle autonome). Compte tenu de tout cela, nous confirmons la force de ToolsGroup en matière d’automatisation.

Intégration technologique : La stratégie récente de ToolsGroup a impliqué des acquisitions, ce qui soulève naturellement la question de l’intégration de plateforme. À l’heure actuelle, ils disposent de SO99+ (leur moteur hérité), JustEnough (désormais souvent désigné sous le nom de ToolsGroup Retail Planning) et du moteur AI d’Evo, ainsi que de la technologie en temps réel Onera. Ils sont en train de les intégrer activement : par exemple, le communiqué de presse déclare “l’intégration des solutions d’Evo avec SO99+ et JustEnough offrira aux clients la solution d’optimisation de la supply chain et de tarification la plus efficace et en temps réel” ⁴⁷, indiquant que les trois sont en cours de fusion en une offre unique. Ils insistent sur le fait que leur architecture modulaire signifie que les clients peuvent choisir ce dont ils ont besoin et que tout s’assemble ⁵⁴. Cela suggère qu’ils ont créé des interfaces ou un modèle de données commun (ou qu’ils sont en train de le faire) afin que les données circulent entre les modules sans transfert manuel. Le point positif est que JustEnough fait partie de ToolsGroup depuis 2018 (via l’acquisition de Mi9) ; à présent, ils ont eu le temps d’intégrer les éléments majeurs. En effet, ToolsGroup commercialise, dans de nombreux cas, la solution combinée sous un seul nom. Ils ont probablement unifié l’interface utilisateur dans une certaine mesure – peut-être pas encore une interface unique pour tout, mais cela pourrait y être proche. Ils ont intégré l’AI d’Evo dans JustEnough comme mentionné ⁶⁷, démontrant ainsi une véritable intégration technique plutôt que de les vendre séparément. Cela est prometteur : il semble que ToolsGroup évite délibérément de conserver ces modules en silo. Cependant, il faut reconnaître que pendant un certain temps, il s’agissait probablement d’une “suite” de composants séparés – par exemple, l’utilisateur devait utiliser l’interface SO99+ pour certaines configurations et l’interface JustEnough pour d’autres, ce qui peut être maladroit au début. La taille relativement plus réduite de ToolsGroup signifie que l’intégration peut être plus agile – moins d’obstacles bureaucratiques qu’à SAP. L’objectif est clairement une suite de planification cohérente de bout en bout. Ils partagent les données : par exemple, la prévision générée (probablement par SO99+ ou Evo) alimente à la fois la planification des stocks et la planification financière des marchandises. À défaut de preuves du contraire, nous supposerons que ToolsGroup a fait des progrès significatifs dans l’intégration de ces acquisitions. Il se peut que des incohérences mineures existent (par exemple, les méthodes de prévision dans SO99+ par rapport à celles natives de JustEnough pourraient différer – mais ils standardiseraient probablement sur la meilleure). Sur le plan technologique, ToolsGroup utilisait historiquement une architecture client-serveur sous Windows pour SO99+, tandis que JustEnough était basé sur le web en .NET. Maintenant, ils sont tous proposés via une interface web cloud. Il est probable que la base de code ne soit pas unifiée à 100 %, mais l’apparence pour l’utilisateur pourrait être unifiée via un portail. Cela compte toujours comme intégré du point de vue de l’utilisateur si c’est bien fait (similaire à la façon dont, par exemple, Microsoft intègre des produits acquis dans sa suite Office de manière transparente au fil du temps). Nous devons mentionner que la technologie fondamentale de ToolsGroup (optimisation de stocks) était très solide et éprouvée. Ils ne l’ont pas abandonnée – ils l’ont construite autour. C’est positif, car ils ne réinventent pas la roue, mais cela signifie également qu’au cœur du système, une partie est constituée de code ancien. Parfois, le code ancien ne se marie pas parfaitement avec les microservices plus récents. Nous n’avons pas d’informations directes, donc ce n’est qu’un point à surveiller. Les propres commentaires de ToolsGroup sur les concurrents indiquaient souvent que les grands fournisseurs de suites sont des Frankenstein ; maintenant, ToolsGroup doit éviter cela par eux-mêmes. En intégrant de manière proactive et non en se contentant de reconditionner, ils semblent en être conscients. Par exemple, les acquisitions de SAP ont abouti à une “collection hâtive” et à des difficultés d’intégration ¹¹, comme noté précédemment. ToolsGroup a explicitement déclaré que combiner la planification retail de JustEnough avec leur automatisation et optimisation de stocks offrait une combinaison unique, et que “les produits s’assemblent dans une solution cohésive” ⁵⁴. Nous allons provisoirement y croire tout en restant conscients que certaines discontinuités pourraient subsister (par exemple, un utilisateur pourrait devoir configurer les données de base à deux endroits s’il n’est pas entièrement intégré). Dans l’ensemble, ToolsGroup est en phase d’intégration intermédiaire – pas initialement unifié, mais en progression active vers cet objectif. Nous leur donnerons une note modérée : mieux que les entreprises qui se contentent d’acquérir et de laisser les pièces séparées, mais pas aussi intrinsèquement unifié qu’une plateforme construite d’un seul tenant. Avec plus de temps (et au fur et à mesure qu’ils replateforment probablement les composants sur une architecture cloud commune), ils devraient atteindre une haute intégration. Jusqu’à présent, au moins, la vision et les actions s’alignent pour éviter un Frankenstein.

Scepticisme à l’égard du battage médiatique : Le marketing de ToolsGroup mêle pragmatisme et battage médiatique. Ils ne sont pas aussi bruyants que certains autres, mais ils se sont emparés de mots à la mode comme AI, détection de la demande, autonome, etc., ces dernières années. Comme mentionné, l’analyse de Lokad a spécifiquement pointé ToolsGroup pour son battage médiatique : “les affirmations concernant ‘AI’ sont douteuses… les affirmations sur la ‘détection de la demande’ ne sont pas étayées” ¹⁹. Par exemple, ToolsGroup a publié du contenu sur la “détection de la demande” (ajustements à court terme) qui n’était peut-être qu’un discours élégant pour utiliser une moyenne mobile des ventes récentes – pas véritablement innovant. Cela pourrait induire en erreur des clients moins avertis en leur faisant croire qu’ils disposent d’une solution magique. Par ailleurs, ToolsGroup cite parfois des résultats clients incroyables (comme “stocks réduits de 30 % tandis que le taux de service a atteint 99 %”), ce qui, bien que possiblement vrai pour un cas particulier, peut sembler trop beau pour être généralisable. Nous devons rechercher des preuves cohérentes. D’autre part, ToolsGroup existe depuis longtemps et jouit généralement d’une bonne réputation pour fournir des résultats – leur battage n’est donc pas habituellement dénué de fondement. Ils ont peut-être abusé du jargon AI autour de 2018 alors que tout le monde le faisait. Maintenant qu’ils ont acquis une entreprise d’AI, leurs affirmations pourraient avoir plus de crédibilité. Ils mentionnent le terme “quantum learning” qui, franchement, semble être un mot à la mode (le quantum computing n’est pas réellement utilisé – c’est juste un nom de marque pour leur algorithme). Cela relève d’un certain battage médiatique. Mais ils donnent aussi des indices sur ce que c’est réellement (optimisation non linéaire, analyses prescriptives) ⁵². Ils ont également commencé à se positionner en tant que “Leader dans le SPARK Matrix pour la prévision et le réapprovisionnement en retail” ⁷⁰ – en référence aux classements d’analystes qui peuvent être influencés par les fournisseurs. C’est du marketing, mais pas extravagant. Un point à surveiller : ToolsGroup dit “Autonome” désormais. Il faut se méfier de combien les systèmes le sont réellement. Bien qu’ils puissent automatiser beaucoup, une supply chain entièrement autonome demeure un objectif à long terme. Tant qu’ils le présentent comme une ambition (ce qu’ils font : “cheminement vers une planification axée sur la décision (autonome)” ⁵⁸), cela est acceptable. S’ils prétendaient une intégration plug-and-play, ce serait peut-être exagéré – la mise en œuvre de ToolsGroup exige encore intégration et configuration. Toutefois, le fait que ToolsGroup cible le marché intermédiaire signifie qu’ils mettent en avant des implémentations plus rapides que de gigantesques projets ERP. Ils soulignent souvent la facilité d’utilisation, ce qui est plausible et non purement du battage médiatique. En termes de modération des buzzwords, ils se situent probablement dans la moyenne : ni les pires, ni totalement absents de jargon. L’incohérence quant à l’utilisation d’une métrique inappropriée (MAPE pour des prévisions probabilistes) a été un léger signal d’alerte ⁶² – cela suggère que le marketing voulait afficher une amélioration chiffrée, même si cela n’était pas méthodologiquement rigoureux. Nous préférerions une communication honnête du type “notre approche est différente, voici pourquoi les métriques traditionnelles ne s’appliquent pas, voici de meilleures métriques.” ToolsGroup a peut-être simplifié les choses pour conclure la vente. Cela étant dit, les clients fidèles et le taux de renouvellement indiquent généralement qu’ils répondent aux attentes. Leurs affirmations sur les résultats sont étayées par des études de cas. Ils ne vendent pas du vaporware ; ils vendent une technologie éprouvée, actualisée grâce à des acquisitions. Ainsi, le battage médiatique concerne surtout le fait de qualifier certaines choses d’“AI” ou de “quantum” alors qu’il s’agit peut-être d’une simple utilisation du machine learning. C’est commun dans l’industrie. Nous conseillons donc la prudence sans pour autant rejeter d’emblée leurs propos. L’utilisateur devrait leur demander de clarifier le fonctionnement de leur AI, la mise en œuvre de la détection de la demande, etc. ToolsGroup sera probablement en mesure de fournir une explication (même si cela se résume à “nous utilisons le machine learning pour ajuster les prévisions à court terme en fonction des ventes récentes et des signaux de stocks” – ce qui est acceptable, juste pas mystique). En résumé, le marketing de ToolsGroup ces dernières années a inclus quelques buzzwords auxquels il faut être attentif, mais il se concentre également sur des résultats concrets (taux de service, réduction des stocks, etc.). Nous leur attribuons ainsi une note moyenne en matière de scepticisme face au battage médiatique : ils ne s’expriment pas en excès dans le jargon, offrant fondamentalement plus de substance que de superficialité (avec un léger point négatif pour certaines formulations trompeuses relevées par des analyses externes).

Résumé : ToolsGroup est un acteur mature mais en évolution dans l’optimisation du retail. Il apporte à la table des décennies d’expertise en optimisation de stocks avec prévision probabiliste, désormais complétée par des capacités de planification de marchandises et d’optimisation de tarification via des acquisitions. En conséquence, ToolsGroup peut désormais aborder l’optimisation conjointe des stocks et de la tarification – en utilisant des prévisions de demande qui tiennent compte des variations de prix et en prenant des décisions de tarification éclairées par les positions de stocks ⁴⁹. Ses efforts d’intégration transforment ces outils autrefois distincts en une suite de planification cohésive, bien que certaines imperfections d’intégration puissent encore être en cours de réglage. La force de ToolsGroup en modélisation probabiliste signifie qu’il gère efficacement l’incertitude de la demande et génère des stratégies de stocks pour atteindre un taux de service minimum au coût le plus bas, et ses nouvelles améliorations en AI visent à adapter continuellement ces décisions en temps réel ⁵⁸. Il a fait ses preuves en automatisant les processus de planification – de nombreuses tâches de prévision et de réapprovisionnement de routine peuvent s’exécuter de manière autonome, les planificateurs gérant les exceptions. Désormais, avec des modules de tarification et d’assortiment, il étend l’automatisation à ces domaines (par exemple, des démarques automatiques basées sur des règles ⁶⁹ et des ajustements d’assortiment suggérés par AI). En termes de complexités du retail, ToolsGroup couvre bien les bases (prévision promotionnelle, déstockage saisonnier, regroupement de magasins), bien qu’il ne puisse pas encore détecter automatiquement la cannibalisation ou les schémas de substitution dans la mesure où certains systèmes spécialisés le font. Son approche de l’optimisation économique est passée de simples taux de service à l’intégration de métriques de profit (notamment dans les décisions de tarification et d’assortiment ³³). Les utilisateurs devraient se méfier d’un peu de battage médiatique – ToolsGroup utilise librement les buzzwords comme “autonome” et “AI”, et une critique tierce a signalé que certaines de leurs affirmations passées sur l’AI étaient exagérées ¹⁹. Cependant, compte tenu des améliorations tangibles dont témoignent de nombreux clients et de l’investissement sérieux réalisé dans de nouvelles technologies (comme Evo), la substance derrière leurs affirmations est significative. ToolsGroup se distingue dans notre classement comme une option techniquement solide et pragmatique : une solution qui, peut-être, n’a pas le cachet d’une pure startup AI ou l’échelle extrême d’une mega-suite, mais qui offre une solution équilibrée et avancée pour les retailers souhaitant optimiser leur planification avec moins de battage médiatique et davantage de résultats concrets. Elle convient particulièrement aux organisations qui recherchent une optimisation de stocks éprouvée avec l’avantage supplémentaire d’une planification intégrée de la tarification et de l’assortiment – transformant ainsi une solution autrefois “legacy” en une solution bien plus pérenne grâce à sa modernisation. Tant qu’on demeure suffisamment sceptique face aux buzzwords et qu’on s’assure que l’intégration réponde à leurs besoins, ToolsGroup représente une solution de pointe (ou très proche de l’être) pour l’ère des décisions retail pilotées par AI.

Sources: Intégration de la tarification avec la vue des stocks ⁴⁹ ; critique des affirmations sur l’AI et la détection de la demande de ToolsGroup ¹⁹ ; ToolsGroup/Evo sur la fourniture de décisions optimales en tarification+stocks ⁵² ⁵³.

5. Blue Yonder (formerly JDA) – Puissante suite de retail reconçue pour le SaaS, mais des racines legacy se perceptent

Blue Yonder, historiquement connu sous le nom de JDA Software, est l’un des plus grands et des plus anciens fournisseurs de logiciels d’optimisation du retail et de la supply chain. Il offre une suite complète couvrant prévision de la demande, réapprovisionnement, allocation, gestion de catégorie (assortiment), optimisation de tarification et de démarques, gestion des entrepôts, planification des effectifs, et plus encore. En 2020, JDA a rebrandé en Blue Yonder après avoir acquis une entreprise allemande d’AI du même nom. Blue Yonder (BY) a depuis migré une grande partie de son portefeuille vers une plateforme Luminate unifiée avec des microservices et se positionne comme une solution intégrale de supply chain et de merchandising pilotée par AI ⁷¹. Il coche sans aucun doute toutes les cases en termes de fonctionnalités : peu de fournisseurs peuvent égaler l’étendue des offres d’optimisation retail de BY. Cependant, la suite Blue Yonder est également le produit de décennies d’acquisitions (i2, Manugistics, Arthur, RedPrairie, etc.), et bien que la nouvelle architecture cloud-native Luminate soit moderne, sous le capot certains algorithmes et modules remontent à des approches legacy. Une évaluation critique par un concurrent a déclaré franchement : “Blue Yonder est le résultat d’une longue série de fusions et acquisitions… sous la bannière de BY se cache une collection hâtive de produits, dont beaucoup sont datés. BY met en avant l’AI, mais les affirmations sont vagues et manquent de substance ; des projets open source laissent entrevoir des approches pré-2000 (ARMA, régression linéaire).” ⁷². Cela met en lumière le principal scepticisme : Blue Yonder est-il réellement à la pointe ou bien un géant legacy reconditionné ? Nous classons Blue Yonder un peu plus bas dans notre liste, non pas parce qu’il manque de capacités (il en a beaucoup), mais en raison des préoccupations concernant sa cohésion, son efficacité et la clarté de ses affirmations.

Optimisation conjointe: La suite de Blue Yonder fournit essentiellement des modules séparés mais intégrés pour l’optimisation des prix, la prévision de la demande & le réapprovisionnement, et la planification de l’assortiment/marchandisage. En théorie, un détaillant utilisant l’ensemble des solutions de Blue Yonder peut atteindre une optimisation conjointe par l’interaction de ces modules. Par exemple, Blue Yonder propose des applications de tarification de cycle de vie (optimisation du prix régulier, optimisation des baisses de prix, optimisation des promotions) qui sont alimentées par des prévisions de demande issues de leur moteur Luminate Demand Planning. Ces prévisions de demande prennent, à leur tour, en compte les effets des prix car la prévision de Blue Yonder (initialement issue de l’acquisition allemande de Blue Yonder) intègre une modélisation de l’élasticité. Comme l’a expliqué Michael Orr de Blue Yonder, “Blue Yonder utilise des données pour comprendre comment les clients sont susceptibles de se comporter et quel impact un prix peut avoir sur les niveaux de stocks,” aidant ainsi les détaillants à éviter de fixer des prix trop élevés ou trop bas ²⁷. Cela démontre que l’optimisation des prix de BY n’est pas réalisée de manière isolée : elle modélise explicitement comment les variations de prix affectent la demande et donc les stocks. De plus, la planification de l’exécution de Blue Yonder peut être liée aux décisions de tarification en garantissant que, si une baisse de prix est prévue (ce qui fera exploser la demande), les plans d’approvisionnement s’ajustent en conséquence. De même, l’outil de gestion de catégorie de Blue Yonder (anciennement JDA Category Management) aide à décider des assortiments et à élaborer des planogrammes ; ces décisions alimentent leurs systèmes de prévision de la demande et de réapprovisionnement. Ils avaient un concept global appelé “planification intégrée du retail”, qui aligne les plans financiers de marchandises, les plans de catégorie et les plans d’approvisionnement. En pratique, historiquement, les clients de JDA exécutaient souvent ces processus de manière semi-séparée en raison de la complexité des outils. Mais avec Luminate, BY revendique une intégration plus fluide via une plateforme commune. Ils mettent en avant leur “architecture microservices” qui soutient la planification de bout en bout ⁷¹ – c’est-à-dire, par exemple, qu’un service de planification de promotion pourrait appeler à la volée le service de prévision de la demande pour obtenir des projections mises à jour sous différents scénarios de prix. L’approche de planification simultanée de Blue Yonder (comme “Harmony” dans leur interface) peut montrer à un planificateur l’impact des décisions sur l’ensemble des fonctions. Ainsi, oui, Blue Yonder est capable d’une optimisation conjointe en ce que toutes les composantes peuvent communiquer : les décisions de tarification informent les prévisions qui informent les stocks, et vice versa. Cependant, on pourrait se demander dans quelle mesure la coordination est optimale. Souvent, elle pourrait encore être séquentielle (prévoir avec un prix supposé, optimiser les stocks en conséquence, optimiser séparément les prix compte tenu des contraintes de stocks de façon itérative). Il existe des preuves que Blue Yonder poursuit une véritable simultanéité : par exemple, leur nouvelle vision “Autonomous Planning” a probablement l’intention de boucler ces processus de manière dynamique. L’acquisition par Blue Yonder d’une entreprise d’optimisation des prix (ils se sont associés avec dunnhumby, mais plus récemment, je crois, ils ont intégré leurs capacités internes avec la plateforme ML allemande de BY) garantit qu’ils disposent d’algorithmes de tarification avancés. Dans l’ensemble, Blue Yonder fournit les outils pour l’optimisation conjointe, mais l’atteinte de cet objectif par un utilisateur dépend de la mise en œuvre de plusieurs modules. Étant donné que la suite de Blue Yonder est modulaire, certains clients peuvent n’utiliser, par exemple, que la planification de la demande & de l’approvisionnement sans la tarification, n’atteignant ainsi pas une optimisation conjointe complète avec BY seul. Pour ceux qui utilisent la suite complète, Blue Yonder peut certes couvrir de manière collective les décisions relatives aux stocks, à la tarification et à l’assortiment. Nous notons toutefois que les solutions de Blue Yonder n’ont pas été conçues à l’origine comme un tout – elles ont été intégrées. Bien que Luminate ait fait des progrès dans leur connexion, il est possible que cette intégration ne soit pas encore aussi serrée que dans un modèle d’optimisation unique (par exemple, le moteur de tarification pourrait ne pas prendre naturellement en compte les niveaux de stocks actuels, sauf s’il est configuré, etc.). Au vu des éléments, Blue Yonder mérite une bonne note sur le potentiel d’optimisation conjointe, avec la réserve qu’il pourrait être nécessaire de fournir des efforts importants pour réaliser ce potentiel.

Prévision probabiliste & IA: La prévision de la demande de Blue Yonder (la partie issue de la branche allemande de Blue Yonder, souvent appelée Cognitive Demand Planning) est fortement basée sur l’IA/ML. Ils ont publié des améliorations telles qu’une précision de prévision supérieure d’environ 12 % grâce au ML par rapport aux méthodes traditionnelles ⁷³. Leur approche ingère une myriade de données – y compris la météo, des événements, des signaux en ligne – pour prédire la demande. Bien qu’ils génèrent probablement un chiffre unique de prévision pour un usage opérationnel, les modèles sous-jacents peuvent produire des sorties probabilistes. En fait, la solution originale de Blue Yonder (Allemagne) était connue pour la sélection automatisée de modèles (comme une approche AutoML) et pouvait produire des intervalles de confiance. Qu’il s’agisse ou non d’un système de production exposant des distributions reste incertain, mais ils mettent en avant la planification de scénarios et la simulation. Par exemple, ils permettent aux planificateurs de simuler plusieurs scénarios de demande, ce qui implique une distribution des résultats en coulisses ⁷⁴. Blue Yonder a également évoqué la simulation “Monte Carlo” dans certains livres blancs pour la planification de l’approvisionnement. Étant donné leur solide équipe de data scientists, il est raisonnable de dire que la prévision de Blue Yonder est au moins consciente de la nature stochastique, même si elle ne fournit pas explicitement de fonction de densité de probabilité pour chaque article. Ils la présentent comme une prévision “Cognitive” ou “Machine Learning”. Ils ont également acquis des capacités de prévision des commandes clients issues de leur ancien système (comme les techniques d’i2 pour des temps de livraison probabilistes, etc.). Cependant, des critiques, comme celle de Lokad, ont souligné que les composants open-source utilisés par Blue Yonder (tsfresh pour l’extraction de caractéristiques, Vikos – qui pourrait être une bibliothèque de prévision – et PyDSE) indiquent une dépendance à des techniques relativement conventionnelles ⁴³. tsfresh sert à générer des caractéristiques pour les séries temporelles (comme l’extraction de métriques saisonnières) – utile, mais pas révolutionnaire en soi en termes d’IA. La mention d’ARMA et de régression linéaire implique que certaines prévisions de base pourraient encore utiliser des modèles statistiques, enrichis par des fonctionnalités ML. En d’autres termes, l’“IA” de Blue Yonder pourrait souvent se résumer à un lissage exponentiel bien réglé + une régression pour des facteurs causals. Ce n’est pas nécessairement mauvais – ce sont des méthodes éprouvées, mais elles ne représentent pas les approches de deep learning les plus novatrices. Blue Yonder fait assurément la promotion de son IA de manière intensive : des termes comme “cognitive”, “machine learning”, “AI/ML engines” apparaissent dans leurs supports ⁷³ ⁷⁵. Le flou entourant la manière exacte dont ils le mettent en œuvre (secret commercial peut-être) conduit à du scepticisme quant à un éventuel “AI-washing”. Mais nous savons qu’ils disposent de talents remarquables (l’équipe allemande était très solide sur le plan académique), donc il y a de fortes chances pour que ce soit solide, même si ce n’est pas tape-à-l’œil. Blue Yonder utilise également l’IA dans d’autres domaines : par exemple, leur optimisation des prix utilise le machine learning pour estimer l’élasticité des prix et les effets croisés ; leur planification de l’approvisionnement recourt à des heuristiques et possiblement au ML pour ajuster des paramètres ; leur micro-fulfillment fait appel à l’IA pour décider de l’emplacement à partir duquel exécuter une commande, etc. Ils mettent aussi en avant “Luminate Control Tower” qui exploite l’IA pour prédire les perturbations et prescrire des actions. Beaucoup de ces fonctionnalités reposent sur la classification ou la prédiction via le ML. Sont-elles probabilistes ? Il est possible qu’elles délivrent des scores de risque ou des probabilités d’événements. Les supports marketing de Blue Yonder évoquent des “moteurs d’optimisation supportés par l’IA” qui ingèrent d’énormes volumes de données… permettant d’atteindre une automatisation cognitive ⁷⁶ ⁷⁷ et qui semblent convaincants sans toutefois être spécifiques. Il est juste de dire que Blue Yonder use largement de l’IA, mais en raison de l’ampleur de son offre, certaines parties peuvent ne pas être les plus récentes. Par exemple, un utilisateur sur Reddit a commenté que la prévision de JDA (désormais celle de BY) n’était pas unique et que beaucoup utilisaient encore une logique plus ancienne avec un ajustement de paramètres. Les brevets et travaux de recherche de Blue Yonder pourraient en dire plus (ils détiennent quelques brevets sur la prévision de scénarios multiples ⁷⁸). Au vu des éléments : Blue Yonder a incontestablement intégré l’IA/ML (notamment après l’acquisition de Blue Yonder GmbH) dans sa prévision et son optimisation. Cela produit des prévisions plus précises et vraisemblablement des capacités de scénarisation. Cependant, l’avis sceptique de Lokad, selon lequel sous le capot il pourrait y avoir de nombreux modèles linéaires déguisés en IA, suggère qu’il convient de rester prudent. Nous attribuons à Blue Yonder une bonne note sur ses fonctionnalités AI/ML, tout en notant que certains concurrents ayant bâti leur solution dès le départ avec le ML (comme RELEX ou Lokad) pourraient avoir un avantage sur certaines techniques grâce à un moindre héritage. Blue Yonder investit activement dans les avancées de pointe (par exemple, ils mentionnent l’exploration de Generative AI pour des assistants de planification ⁷⁹). Ainsi, ils essaient de rester à la pointe.

Prise de décision économique: Les solutions de Blue Yonder, notamment en matière de tarification et de supply chain, prennent explicitement en compte la rentabilité et les coûts. Pour la tarification, Blue Yonder (via ce qui était à l’origine Revionics ou leur propre solution) propose des fonctions objectives telles que la maximisation de la marge, du chiffre d’affaires ou l’atteinte d’un objectif financier. Leur optimisation des prix ne se contente pas de suivre des règles – elle utilise l’élasticité pour choisir des prix qui maximisent une métrique déterminée tout en respectant des contraintes (comme des indices de prix concurrentiels ou des positions de stocks). Il s’agit ainsi d’une optimisation économique intrinsèque. Dans l’optimisation des stocks, Blue Yonder (ou l’ancien JDA/i2) disposait de modules tels que l’optimisation multi-échelons des stocks (MEIO) qui tentaient effectivement de minimiser les coûts totaux (coûts de détention, coûts de rupture) pour un taux de service donné ou de maximiser le service pour un budget – une optimisation classique coût-bénéfice. En pratique, certains clients se contentaient d’un ciblage du taux de service, mais la capacité à réaliser une optimisation basée sur les coûts était présente. Les outils S&OP / IBP de Blue Yonder permettent d’intégrer des plans et des contraintes financiers, ce qui signifie que le processus de planification peut optimiser autour de la marge ou des objectifs de profit (par exemple, atteindre un objectif de chiffre d’affaires au coût minimum, etc.). Un autre domaine est l’allocation : l’outil d’allocation de Blue Yonder peut être configuré pour attribuer des produits aux magasins de manière à maximiser le taux de vente projeté (et donc le profit) plutôt que de procéder à une répartition uniforme. Leur planification de l’assortiment peut intégrer des métriques de contribution de profit par catégorie afin de décider quels produits conserver ou éliminer. Comme Blue Yonder s’est historiquement adressé à des détaillants très focalisés sur la marge (par exemple, les détaillants de mode qui utilisent leur optimisation des promotions pour maximiser le retour sur marge brute), ils ont dû intégrer la logique économique. La critique du flou ⁴³ pourrait laisser entendre que l’IA de Blue Yonder n’articule pas clairement l’aspect économique (par exemple, elle n’indique pas de manière transparente le profit qu’implique une certaine prévision), mais leurs modules d’optimisation utilisent assurément des paramètres économiques (élasticité des prix, coûts, etc.). Par exemple, la solution d’optimisation des stocks de Blue Yonder prétend “éliminer les stocks excédentaires et réduire les coûts d’obsolescence tout en maintenant un haut taux de service” ⁸⁰ – ce qui consiste essentiellement à équilibrer le coût de l’obsolescence contre le niveau de service, un compromis économique. Leur optimisation des promotions prend en compte le lift promotionnel par rapport à l’investissement en marge pour recommander quelles promotions sont les plus rentables. En termes de coût d’opportunité, Blue Yonder pourrait ne pas l’indiquer explicitement, mais ses planificateurs peuvent en déduire la valeur dans un scénario donné : par exemple, si vous ne stockez pas l’article A, le profit perdu constitue un coût d’opportunité. Les outils de Blue Yonder pourraient simuler ce scénario. Les critiques que nous avons formulées disent essentiellement : Blue Yonder revendique l’IA, etc., mais pourrait utiliser de nombreuses régressions linéaires (qui intègrent généralement les facteurs de coût de toute façon). Je pense donc que Blue Yonder se débrouille bien sur l’aspect économique. Une faiblesse potentielle serait que d’anciennes parties du système utilisent encore des heuristiques approximatives (certains anciens systèmes de réapprovisionnement JDA reposaient sur des formules min/max). Mais ceux-ci sont vraisemblablement progressivement remplacés par des approches optimisées. Avec l’initiative “autonomous planning” de Blue Yonder, on mentionne souvent les indicateurs financiers comme moteur clé. Un article de BusinessWire cite un client utilisant la technologie avancée de BY : “En tirant parti de l’IA/ML, nous améliorons la précision des prévisions et construisons une supply chain prête pour le futur qui améliore nos performances financières” ⁸¹. Ainsi, oui, l’économie est au cœur de leur approche. Cela dit, la mise en œuvre complète des capacités de Blue Yonder peut être complexe – certains clients ne tirent peut-être pas parti de l’ensemble des fonctionnalités d’optimisation économique en raison de leur complexité, préférant une approche plus manuelle. Mais la capacité est bel et bien présente. Nous attribuons à Blue Yonder une forte note sur ses modules motivés économiquement (tarification, promotions, MEIO), avec un léger bémol si certains de ces modules ne sont pas entièrement intégrés ou faciles à utiliser, ce qui pourrait mener à une utilisation sous-optimale.

Scalabilité & Efficacité Coût : Les solutions legacy sur site de Blue Yonder étaient réputées lourdes – nécessitant une puissance serveur et une mémoire importantes, en particulier l’ancienne empreinte de JDA. Cependant, ces dernières années, Blue Yonder est passé à une plateforme de microservices cloud-native sur Microsoft Azure, ce qui devrait améliorer la scalabilité. Le rapport MQ de Gartner indiquait que les points forts de Blue Yonder incluent « une architecture de microservices complète » et qu’elle offre une planification multi-entreprise de bout en bout ⁷¹. Les microservices impliquent qu’ils ont fragmenté les applications monolithiques en services plus petits pouvant évoluer indépendamment. Cela améliore probablement la performance (par exemple, étendre le service de prévision de la demande pour de nombreux articles tout en étendant séparément le service de planification de l’approvisionnement). L’environnement de Microsoft Azure permet également l’élasticité et peut-être un coût d’échelle inférieur à celui sur site, car vous pouvez lancer une grande capacité de calcul pour un lot puis la réduire. Blue Yonder demeure toutefois l’une des solutions les plus coûteuses et de niveau entreprise. Exécuter tous ces modules avancés implique de traiter une tonne de données (surtout si vous utilisez une granularité élevée). Il y a eu historiquement des plaintes concernant de longs temps d’exécution pour certains processus JDA ou la difficulté à gérer très rapidement des volumes de données extrêmement importants. La refonte vers les microservices visait à résoudre une grande partie de ces problèmes. Désormais, Blue Yonder peut se vanter d’un reforecasting quasi en temps réel pour la détection de la demande et de replanifications fréquentes dans leur tour de contrôle. Un autre aspect est la gestion des données : l’adoption par Blue Yonder d’un data lake cloud sous-jacent pourrait améliorer la manière dont les données sont stockées et accessibles par rapport aux anciens modèles relationnels. D’un autre côté, disposer d’une suite étendue signifie une importante surcharge d’intégration ; la plateforme de Blue Yonder tente d’atténuer cela, mais reste probablement lourde. En termes d’efficacité coût, Blue Yonder cible généralement les grandes entreprises avec d’importants budgets, il n’est donc pas habituellement choisi pour des économies – il l’est pour ses capacités. Cela pourrait nécessiter des dépenses Azure considérables pour le client (ou Blue Yonder intègre cela dans les frais SaaS). Si un détaillant tente de mettre en œuvre tous les modules de BY, le projet et les coûts récurrents peuvent être très élevés. Ainsi, l’efficacité coût n’est pas l’argument commercial de BY – c’est l’exhaustivité. Un autre point pertinent : les anciens modules de Blue Yonder fonctionnaient souvent en mémoire (JDA disposait d’un OLAP en mémoire pour les chiffres de planification). Ce concept en mémoire pouvait signifier une forte utilisation de la mémoire. Mais avec les microservices, peut-être utilisent-ils les pools de mémoire évolutifs d’Azure de manière plus efficace. La critique concurrentielle de Lokad disait spécifiquement « les logiciels d’entreprise ne sont pas miscibles par fusions-acquisitions, sous BY se trouve une collection hétéroclite… les affirmations sont vagues, des indices open-source suggèrent une technologie ancienne » ⁷². Bien que cela concerne davantage l’intégration et le battage médiatique, cela pointe indirectement vers des inefficacités – une « collection hétéroclite » implique souvent que chaque partie dispose de sa propre infrastructure, non optimisée, conduisant à une empreinte totale plus élevée. Nous soupçonnons que Blue Yonder a amélioré son intégration avec Luminate, mais il peut encore subsister des redondances. Par exemple, le module de tarification pourrait disposer de son propre magasin de données séparé de celui de la prévision, sauf s’il est unifié – ce que Luminate est censé unifier, mais ces choses prennent du temps. En résumé : Scalabilité – Blue Yonder peut évoluer jusqu’aux plus grands détaillants (de nombreux top 10 détaillants mondiaux utilisent un composant Blue Yonder), ce qui prouve qu’il peut gérer des quantités énormes de données. La performance n’est peut-être pas fulgurante dès le départ, mais elle est opérationnelle avec des réglages et la puissance cloud. Efficacité coût – probablement plutôt basse ; elle a tendance à être gourmande en ressources et coûteuse. Le passage au SaaS pourrait réduire les coûts IT sur site pour les clients, mais ces coûts se transforment en frais d’abonnement. De plus, en tant que grand fournisseur, BY peut facturer un premium. Ainsi, si le coût est un critère, Blue Yonder perd souvent face à des solutions plus légères. Si la puissance pure et l’étendue des fonctionnalités sont les critères, BY convient. Nous les évaluerons modérément en termes de scalabilité (car oui, ils évoluent, mais potentiellement à un coût et une complexité élevés).

Gestion des facteurs complexes du retail : Les solutions de Blue Yonder gèrent explicitement presque tous les facteurs complexes auxquels on peut penser :

Cannibalisation & Halo : Leur ML de prévision de la demande a la capacité de prendre en compte les influences croisées entre produits (ils intègrent vraisemblablement des indicateurs représentant si des substituts sont en promotion, etc.). De plus, leur outil d’optimisation de promotion prend en compte la cannibalisation – par exemple, lorsqu’il recommande des promotions, il mesure si la promotion sur le Produit A cannibalise les ventes du Produit B et calcule le gain net. Blue Yonder disposait d’un module appelé Promotion Effectiveness qui faisait quelque chose de similaire. Par ailleurs, leurs analyses de gestion de catégorie évaluent souvent les impacts de catégorie des modifications de tarification (pour éviter d’augmenter le prix d’un article et de perdre de la marge sur des articles complémentaires). Notamment, le stratège de Blue Yonder pourrait définir des élasticités incluant des effets croisés. Dans un article de Business Insider, Revionics (désormais séparé sous Aptos) évoquait l’utilisation de l’IA pour simuler si une baisse de prix sur la préparation de gâteau augmentait les ventes d’œufs ⁸², ce qui est un scénario d’effet halo. La solution de tarification de Blue Yonder est similaire à celle de Revionics puisque les deux sont concurrentes, donc vraisemblablement BY peut également simuler de tels effets interproduits.
Substitution (effets de rupture de stock) : La planification de la demande de Blue Yonder peut exploiter les informations de disponibilité positionnelle ; si un article est en rupture de stock, la logique de prévision peut attribuer une baisse à un manque de disponibilité plutôt qu’à une baisse de la demande. Le ML de Blue Yonder en Allemagne était réputé pour intégrer les taux de disponibilité afin de ne pas naïvement apprendre une demande moindre lorsqu’un article était simplement en rupture de stock. De plus, la planification des commandes de Blue Yonder peut inclure des règles de substitution – par exemple, si l’article X est en rupture, ils pourraient augmenter proactivement l’approvisionnement de l’article substitut Y (certains utilisateurs avancés le font).
Expiration/périssables : Blue Yonder a une large clientèle dans le secteur de l’épicerie, ils ont donc développé des fonctionnalités pour les produits périssables. Par exemple, leur système de réapprovisionnement peut prendre en compte la durée de vie en rayon – afin de ne pas surcommander au risque que le produit n’expire. Ils peuvent également optimiser la production en magasin (par exemple, pour le frais, ils disposent de solutions intégrées à la gestion de la main-d’œuvre pour gérer la planification de la production fraîche – ce qui contribue indirectement à la réduction du gaspillage). La prévision de Blue Yonder permet une granularité quotidienne, ce qui est crucial pour les produits frais, et utilise la saisonnalité par jour de la semaine, etc. Ils citent des références (comme celle de Knauf dans BusinessWire pour la supply chain, ainsi que quelques références dans l’épicerie) où « en utilisant BY, le gaspillage a été réduit, etc. » – bien que RELEX ait fourni un exemple à cet égard. Blue Yonder a vraisemblablement des succès similaires (je me souviens d’un cas avec 7-Eleven utilisant BY pour prévoir les produits frais).
Planogramme et contraintes d’espace : La solution de gestion de catégorie de Blue Yonder est fondamentalement la référence dans l’industrie pour le planogramme et l’agencement des espaces de vente. Elle alimente directement la planification de l’assortiment et du réapprovisionnement en fournissant des données sur l’espace attribué à chaque produit dans chaque magasin (afin que la planification de l’approvisionnement connaisse le stock maximal par rayon). Les systèmes de Blue Yonder utilisent indéniablement ce paramètre – par exemple, si un planogramme prévoit 2 façades pour un article, le système n’enverra pas plus que ce que peut contenir l’étagère. De plus, BY peut optimiser quels magasins reçoivent un nouvel article en fonction de l’espace disponible et de la demande locale (par exemple, si le rayon ne peut pas accueillir plus de SKUs, il pourrait ne pas l’inclure dans l’assortiment).
Facteurs liés à la main-d’œuvre et à l’exécution : Légèrement en marge, BY prend également en compte la manière dont un plan peut être exécuté – par exemple, la planification de la main-d’œuvre pour le déchargement des livraisons si des stocks supplémentaires sont envoyés pour une promotion, etc. Cela démontre à quel point leur réflexion est intégrée pour les opérations retail.
Omni-channel : Les capacités plus récentes de Blue Yonder prennent également en compte les compromis d’exécution (expédition depuis le magasin vs DC), ce qui n’est pas directement demandé, mais constitue une autre complexité qu’ils optimisent (coût vs rapidité, etc. – hors du champ de cette question).
Météo et facteurs externes : Ils gèrent ces éléments via le ML dans la prévision de la demande, ce qui est un « facteur complexe » dans un contexte de demande volatile. En essence, Blue Yonder dispose d’une solution ou d’une fonctionnalité pour presque tous les scénarios retail épineux. Le défi réside dans le fait qu’il faut effectivement mettre en œuvre et ajuster ces fonctionnalités. Historiquement, certains détaillants peinaient à implanter des modèles avancés de cannibalisation dans JDA car c’était complexe et nécessitait un soutien en data science. Désormais, avec l’automatisation par IA, BY tente de le faire en interne. Cela fonctionne vraisemblablement, mais l’utilisateur pourrait ne pas le voir ni le contrôler facilement (le scénario de « boîte noire cognitive »). Pourtant, il est plus prudent de supposer que BY couvre ces complexités puisque leurs concurrents le font et qu’ils devaient suivre le rythme. En fait, Blue Yonder propose un outil appelé Demand Transference analysis (issu de l’ancien JDA), qui mesurait explicitement la cannibalisation au sein des catégories pour aider aux décisions d’assortiment – c’est exactement quantifier le transfert de la demande d’un produit à un autre lorsqu’un produit est absent ou en promotion. Ainsi, oui, ils disposent de ce concept. Compte tenu de tout cela, Blue Yonder obtient probablement la note la plus élevée en matière de gestion de facteurs complexes, tout simplement parce que, depuis des décennies, pour chaque problème rencontré par un détaillant, JDA/Blue Yonder ajoutait une fonctionnalité pour y remédier (ou acquérait une entreprise qui le faisait). La petite réserve : parfois, les anciennes approches peuvent être moins automatisées (nécessitant une configuration manuelle des relations, etc.), tandis que les nouveaux fournisseurs les apprennent automatiquement. Blue Yonder tente désormais d’automatiser l’apprentissage avec l’IA, mais encore une fois, y faire confiance demande de la foi puisque les détails ne sont pas toujours dévoilés. La critique du concurrent sur l’utilisation de méthodes plus anciennes ⁴³ suggère que leur modélisation de la cannibalisation utilise peut-être une régression linéaire (ce qui peut tout de même capturer le phénomène correctement si elle est bien réalisée). Ce n’est pas forcément un défaut, simplement moins sophistiqué. Nous évaluerons BY très favorablement sur ce critère, tout en notant que sa mise en place peut s’avérer complexe.

Automatisation : La vision de Blue Yonder pour une « Autonomous Supply Chain » et une « Cognitive Planning » repose essentiellement sur l’automatisation. Ils font la promotion de Luminate Planning, capable d’ajuster automatiquement les plans avec peu d’intervention humaine, et de leurs algorithmes qui peuvent s’auto-ajuster. Par exemple, la « algorithmic baseline forecasting » de Blue Yonder réduit significativement la charge de travail des prévisionnistes humains – les planificateurs se concentrent alors uniquement sur les exceptions (comme les nouveaux produits ou les grands événements). De nombreux clients de BY utilisent le réapprovisionnement automatique : le système génère des commandes qui passent directement à l’exécution, sauf s’ils sont signalés. Le système Fulfillment de BY disposait de fonctionnalités telles que des « Adaptive, learning safety stocks », ce qui signifiait moins de réglages manuels des paramètres. En tarification, Blue Yonder (comme d’autres outils de tarification) peut appliquer des mises à jour autonomes des prix dans le respect des règles – par exemple, des réductions automatiques chaque lundi basées sur le taux de rotation actuel par rapport au plan. Je soupçonne que certains clients retail de BY permettent au système d’exécuter automatiquement certaines actions tarifaires (en particulier les markdowns, qui peuvent être localisés et fréquents – trop nombreux pour être gérés manuellement). La Luminate Control Tower de Blue Yonder peut même résoudre automatiquement certaines exceptions (par exemple, si un fournisseur a du retard, expédier automatiquement depuis une autre source) – c’est l’automatisation de l’exécution. Toutefois, historiquement, Blue Yonder avait aussi la réputation d’être assez centré sur les planificateurs : il fournit d’excellentes recommandations, mais de nombreuses entreprises avaient encore un grand nombre de planificateurs ajustant ces recommandations (parce que le système était complexe ou qu’elles n’avaient pas entièrement confiance en lui). La transformation vers « autonome » est toujours en cours. Les articles de blog de Blue Yonder sur l’augmentation de la précision des prévisions se concentrent sur le fait de laisser l’IA faire le gros du travail et de limiter les interventions manuelles ⁸³, ce qui implique qu’ils encouragent l’automatisation. Ils disposent d’un concept d’exceptions/alertes qui instaure une gestion par exception – une caractéristique de l’automatisation (n’intervenir que lorsque cela est nécessaire). Avec l’acquisition par Panasonic de Blue Yonder en 2021, l’accent est également mis sur la connexion à l’IoT et l’automatisation même des décisions physiques (comme ajuster les étagères en magasin via la robotique en fonction des changements de plan – une idée avant-gardiste, encore au stade conceptuel). En revanche, parce que les outils de BY sont si riches en fonctionnalités, certains utilisateurs peuvent devenir trop dépendants de la configuration manuelle (comme l’ajustement de dizaines de paramètres ou l’exécution manuelle de simulations), ce qui peut entraver une véritable automatisation sans intervention. La critique du concurrent selon laquelle chez BY « les produits sont datés et non miscibles » ⁷² pourrait laisser entendre qu’il y a encore beaucoup de « raccords manuels » nécessaires pour faire fonctionner les modules ensemble – ce qui réduit l’automatisation. Il ne fait aucun doute que Blue Yonder peut permettre une forte automatisation, mais si une implémentation donnée y parvient varie. Je me souviens d’études de cas où des détaillants laissaient Blue Yonder générer automatiquement 90 % de leurs commandes, à l’instar des références de ToolsGroup. Ainsi, une utilisation selon les meilleures pratiques permet vraisemblablement d’y parvenir. Vu le marketing intensif de Blue Yonder autour du terme « autonome », nous pensons qu’ils mettent en avant de nouvelles fonctionnalités pour accroître l’automatisation (comme le ML model autopilot – changeant automatiquement d’algorithme lorsque la tendance évolue ; ou le scenario advisor – recommandant le meilleur scénario). Ils disposent même d’un assistant numérique (peut-être pour des requêtes de planification activées par la voix) – ce qui n’est pas de l’automatisation à proprement parler, mais réduit l’analyse manuelle. Ainsi, oui, BY est orienté vers l’automatisation, bien que, historiquement, elle ait été sous-exploitée par certains utilisateurs en raison de problèmes de confiance ou de complexité. Nous les évaluerons haut, mais pas aussi parfaitement que de petits fournisseurs agiles, simplement parce que mettre en œuvre BY jusqu’au point où l’on peut lui faire confiance sans surveillance peut prendre du temps. Mais une fois en place, cela devrait fonctionner. Le site de Panasonic l’appelle « Realization of the Autonomous Supply Chain™ with Blue Yonder » ⁸⁴ – ils brevettent le concept d’Autonomous Supply Chain, donc ils le prennent au sérieux ! Pour rester sceptiques, il convient de noter qu’à ce jour, une planification véritablement autonome reste rare dans l’industrie, même avec BY – la supervision humaine demeure nécessaire. Toutefois, BY permet de réduire significativement la charge de travail humaine.

Intégration Technologique: Blue Yonder est le cas classique d’une platforme construite par de nombreuses acquisitions (des années 1980 aux années 2010). Cependant, depuis environ 2015, ils ont investi dans son unification. La Luminate Platform est leur réponse : des microservices sur un cloud commun, un modèle de données commun partiellement (ils ont Luminate Data Hub), et un style d’interface utilisateur partagé. Ils ont fait des progrès – par exemple, les modules de prévision de la demande et de réapprovisionnement partagent désormais la même interface utilisateur et les mêmes données sans heurts (comparé à l’ancien JDA où Demand et Fulfillment étaient des applications séparées nécessitant une intégration par lots). L’architecture microservices signifie que de nouvelles capacités peuvent être déployées et intégrées sans modifications monolithiques. Mais soyons clairs : en interne, certains modules font probablement encore tourner leur ancien code (simplement hébergé dans le cloud). Cela signifie que l’intégration se fait au niveau de l’interface, et non pas qu’ils ont réécrit tout dans une seule base de code (ce qui serait irréaliste sur le court terme). Ils ont exposé les API de l’ancien code comme des microservices et les orchestrent. Cela fonctionne dans une large mesure, comme le souligne Gartner en l’appelant “comprehensive microservices architecture” ⁷¹, ce qui constitue un compliment. Un autre avantage : Blue Yonder a largement unifié son interface utilisateur (l’interface Luminate Experience). Un utilisateur peut, en théorie, naviguer d’un écran de planification de la demande à un écran de stocks au sein d’un même portail. Il existe un concept de Luminate Planning Workbench qui tente de rassembler plusieurs fonctions pour un planificateur. Pourtant, des critiques comme Lokad disent “enterprise software isn’t miscible via M&A” ⁷² – insinuant qu’on ne peut pas véritablement fusionner facilement des produits acquis. Blue Yonder y tente, mais peut-être que quelques fissures subsistent : par exemple, la solution de tarification (à l’origine un produit séparé) ne semble peut-être pas encore totalement se fondre dans la planification de la demande dans l’interface et pourrait nécessiter une configuration séparée. L’intégration des données peut poser problème : est-ce que les prévisions de demande alimentent automatiquement les modèles du module d’optimisation des prix ? Ou faut-il les exporter ? Blue Yonder a vraisemblablement intégré cela désormais, mais on n’en est pas certain. La remarque “haphazard collection of products, most of them dated” ⁷² est sévère – faisant peut-être référence à certains anciens modules comme la planification de marchandises de l’ancien JDA ou à d’anciens moteurs d’optimisation qui n’ont pas été mis à jour. De plus, “claims are vague with little substance” ⁸⁵ suggère que parfois BY affirme disposer d’une IA unifiée alors qu’il s’agit peut-être simplement de pièces intégrées de manière lâche. Néanmoins, à crédit de Blue Yonder, ils ont replaté plus que beaucoup d’autres ; par exemple, ils ont containerisé les anciens algorithmes, construit des interfaces utilisateur modernes et les ont connectés. Un autre angle d’intégration : Blue Yonder couvre la planification jusqu’à l’exécution dans une seule entreprise (WMS, TMS pour l’exécution, et outils de planification). Ils ont intégré ceux-ci également (la planification des stocks peut, par exemple, afficher les stocks du WMS en quasi temps réel, etc.). Ainsi, en théorie, vous pourriez exécuter votre supply chain de bout en bout sur la technologie Blue Yonder, ce qui représente une intégration qui va au-delà de la simple planification – un grand avantage si réalisé. Historiquement, ces fonctions étaient également en silo (héritage JDA vs RedPrairie). Ils disposent de quelque chose appelé Luminate Control Tower qui superpose et connecte les données de planification et d’exécution en une seule vue. Il y a donc des progrès en matière d’intégration. Compte tenu de tout cela, Blue Yonder a parcouru un long chemin, mais il est probable qu’il ne soit toujours pas aussi agile et intégré qu’un produit développé entièrement en interne dès le départ. La note open source concernant leur utilisation de projets comme tsfresh indique qu’ils essaient de s’unifier sur des bibliothèques communes lorsque c’est possible (ce qui est une bonne pratique d’intégration). Cependant, avec autant de produits, il est difficile d’unifier complètement chaque pièce. Le risque est que certains clients mettent en place les modules Blue Yonder de manière effective mais ne les intègrent pas bien – la faute pouvant incomber à la mise en œuvre plutôt qu’à la capacité logicielle. Mais l’architecture permet désormais l’intégration, et c’est à l’usage de la maximiser. Nous attribuons à Blue Yonder une note modérée à élevée sur l’intégration : indéniablement une suite historiquement « Frankenstein » qui a subi une chirurgie pour devenir plus unifiée – partiellement réussie, mais on peut encore déceler que certaines parties sont plus anciennes dans leur style. La complexité reste élevée. Par exemple, pour mettre en œuvre la suite complète de BY, il pourrait être nécessaire de mobiliser plusieurs équipes d’experts car chaque module possède une certaine profondeur. Cela indique qu’il ne s’agit pas d’un produit entièrement “cohésif” en pratique, mais plutôt d’« une famille de produits sous une même bannière de platforme ». Pendant ce temps, ToolsGroup ou Lokad se rapprochent davantage d’un produit unique résolvant plusieurs domaines (moins de fonctions mais plus intégré par conception). Ainsi, l’intégration de Blue Yonder est meilleure que le patchwork de SAP, mais probablement en deçà d’une solution unique.

Scepticisme face au battage médiatique: Le marketing de Blue Yonder utilise de nombreux mots à la mode : “Cognitive”, “Autonomous”, “AI/ML”, “End-to-End”, etc. Certaines affirmations manquent de détails (comme “amélioration des prévisions de 12%” – améliorée par rapport à quelle référence ? Ou “alimenté par AI” sans précision sur la méthode). Ils arborent un récit tape-à-l’œil d’un “cerveau digital” semblable à o9, et parfois la visibilité sur leur fonctionnement est limitée. La critique disait “claims are vague with little or no substance… open source projects hint at pre-2000 approaches” ⁴³, accusant essentiellement Blue Yonder de pratiquer l’AI-washing (vendre du vieux vin dans de nouvelles bouteilles). En effet, Blue Yonder a rapidement rebrandé après l’acquisition en se positionnant comme un “pionnier de l’AI”, ce qui a fait lever des sourcils puisque JDA n’était pas réputé pour cela auparavant. Cela dit, Blue Yonder dispose d’une véritable technologie AI (issue de l’équipe acquise), mais peut-être pas bien au-delà de ce que proposent les autres, contrairement à ce qu’ils laissent entendre. Par exemple, qualifier leur prévision de “cognitive” peut constituer une surenchère – elle est avancée, certes, mais beaucoup d’autres réalisent des prévisions par ML similaires. Le terme “cognitive” suggère un raisonnement quasi humain, ce qui relève du battage médiatique. De même, “supply chain autonome” – un objectif admirable, mais tout système de ce type requiert encore une gouvernance humaine. Ils utilisent parfois des termes déposés comme “Autonomous Supply Chain™”, ce qui relève d’un positionnement marketing. Un autre domaine de battage : Blue Yonder vante le “demand sensing” – un concept qu’ils ont adopté (certaines de leurs solutions, comme la prévision à court terme, reposent essentiellement sur le demand sensing). Comme l’a noté Lokad, le demand sensing est souvent du battage s’il n’est pas correctement réalisé. Blue Yonder a vraisemblablement une méthode (comme utiliser les ventes de la semaine précédente avec une pondération plus élevée pour ajuster les prévisions à court terme), mais la question demeure de savoir si cela détecte réellement des signaux externes ou s’il s’agit simplement d’un lissage réactif. S’ils en font trop en le présentant comme “l’AI détectant en temps réel via les réseaux sociaux les variations de la demande”, on pourrait douter de sa praticité. Il y a aussi le battage autour de l’intégration : ils prétendent offrir une platforme unifiée, mais comme mentionné, en coulisses, ce n’est pas entièrement uniforme – le marketing pourrait occulter la complexité de l’intégration. D’un autre côté, Blue Yonder dispose de nombreux cas d’usage réels et références. Ils n’inventent généralement pas de résultats – ils comptent de grands clients qui partagent publiquement leurs succès (augmentation du taux de service, du chiffre d’affaires, etc.), ce qui est crédible. Blue Yonder tend aussi à ne pas dévoiler trop de détails techniques, ce qui peut donner l’impression qu’ils se cachent derrière des mots à la mode. Pour un chercheur de vérité, les documents de BY peuvent être frustrants car ils parlent souvent d’objectifs et de capacités de haut niveau plutôt que de “nous utilisons l’algorithme X, Y, Z”. Mais dans les documents commerciaux destinés aux entreprises, on ne rentre rarement dans les détails algorithmiques. Ce n’est pas propre à BY. Au moins, l’analyse concurrentielle de Lokad les a désignés, signifiant qu’auprès de leurs pairs, Blue Yonder était perçu comme particulièrement dépendant de mots à la mode sans offrir une innovation scientifique réelle ⁴³. Étant donné que nous voulons pénaliser les affirmations vagues et le battage, Blue Yonder subit une certaine pénalité : ils ont sans aucun doute capitalisé sur ces mots à la mode ces dernières années. Les communiqués de presse de Panasonic et les blogs de BY regorgent de ce jargon (AI/ML, digital twin – peut-être moins, ils préfèrent “digital edge”, etc., cognitive, autonomous). Sans validation technique, un sceptique devrait rester méfiant. Néanmoins, Blue Yonder possède une technologie authentique, quoique peut-être pas aussi révolutionnaire que le marketing le suggère. Nous leur attribuons donc une note moyen-faible en honnêteté face au battage médiatique – ils en font beaucoup.

Résumé : Blue Yonder est une suite d’optimisation retail riche en fonctionnalités qui englobe la planification des stocks, la tarification et l’assortiment (plus les aspects d’exécution) – couvrant essentiellement toutes les facettes de l’optimisation retail. Elle a été modernisée avec l’AI/ML (par exemple, des prévisions de demande “cognitive” ²⁷) et une platforme cloud, et est capable d’optimiser conjointement les décisions à travers des domaines traditionnellement en silo (les décisions de tarification alimentant les plans de stocks et vice versa) ²⁷. Les outils de Blue Yonder prennent explicitement en compte la rentabilité et le coût dans les décisions – de l’optimisation de tarification qui équilibre marge versus volume à l’optimisation de stocks qui équilibre le taux de service versus le coût de détention des stocks ⁸⁰. La solution peut modéliser des dynamiques retail complexes telles que la cannibalisation, les effets de halo et les contraintes de durée de vie des produits dans le cadre de ses processus de prévision et de planification, grâce à ses algorithmes avancés et des décennies de connaissances en data science dans le domaine du retail. Par exemple, elle utilise le machine learning pour identifier les effets de substitution de produits et la cannibalisation promotionnelle afin que les prévisions et les réapprovisionnements soient ajustés en conséquence ⁸ ⁹. Grâce à sa récente ré-architecture en microservices, Blue Yonder a amélioré l’intégration de ses modules autrefois disparates, offrant une platforme Luminate plus unifiée avec des données et une interface utilisateur communes ⁷¹. Cela permet des niveaux plus élevés d’automatisation : de nombreux clients de Blue Yonder laissent le système générer automatiquement prévisions, commandes et même recommandations de tarification, n’intervenant qu’en cas d’exception. Blue Yonder fait largement la promotion d’une “Autonomous Supply Chain”, et bien que l’autonomie complète soit un chemin à parcourir, ses solutions permettent des décisions automatisées, basées sur les données, à grande échelle (un grand utilisateur a rapporté que les planificateurs géraient par exception tandis que le système traitait 95% des réapprovisionnements sku-store de manière autonome).

Cependant, un regard sceptique est nécessaire concernant les affirmations de Blue Yonder. L’héritage des acquisitions de la suite signifie que certains composants renferment encore des algorithmes hérités ⁷². La cohésion de la platforme, malgré d’importantes améliorations, peut ne pas être aussi fluide qu’une base de code unique développée de zéro – la mise en œuvre de toutes les pièces peut être complexe et gourmande en ressources. De plus, le battage médiatique marketing de Blue Yonder est notable : des termes comme “cognitive” et “autonomous” sont utilisés de manière libérale, parfois au-delà de la réalité de ce que le logiciel offre immédiatement ⁴³. Des analyses indépendantes ont noté qu’en arrière-plan des mots à la mode, Blue Yonder emploie souvent des techniques analytiques bien établies (voire plus anciennes) ⁴³ – efficaces, mais pas de l’AI magique. De plus, le coût et la complexité de la solution Blue Yonder peuvent être élevés – un investissement considérable en temps, en argent et en personnel qualifié peut être nécessaire pour exploiter pleinement toutes ses capacités, ce qui tempère le discours « plug-and-play ». En bref, Blue Yonder est extrêmement capable – sans doute une référence en matière de richesse fonctionnelle et d’expertise retail – et elle continue d’évoluer avec l’AI moderne et le cloud tech. Elle peut certainement offrir une optimisation de pointe si elle est pleinement mise en œuvre et utilisée. Mais il faut dissiper le brouillard des mots à la mode et évaluer soigneusement la substance de chaque affirmation. Là où Blue Yonder démontre une valeur claire (comme des gains prouvés en précision des prévisions, une réduction mesurable du gaspillage des produits frais ou une augmentation du taux de rotation grâce à une tarification optimisée), nous la reconnaissons comme une solution de premier plan. Là où elle s’appuie sur un marketing vague ou occulte des difficultés d’intégration, nous restons prudents.

Dans notre classement, Blue Yonder reste un fournisseur de premier plan dans l’optimisation retail en raison de son envergure et de son innovation continue ⁷¹, mais nous lui attribuons une légère pénalité pour sa dette technique héritée et son excès de marketing. Pour les grands détaillants en quête d’un système tout-en-un de bout en bout et prêts à investir, Blue Yonder est souvent un concurrent de taille voire la référence. Pour ceux qui privilégient l’agilité, l’efficacité en termes de coût ou la simplicité, l’approche expansive de Blue Yonder peut sembler trop lourde.

Sources: Platforme Luminate de Blue Yonder basée sur des microservices et ses capacités ⁷¹; déclaration sur le lien entre l’impact sur la tarification et les niveaux de stocks ²⁷; analyse critique des affirmations AI de BY et de ses bases héritées ⁷² ⁴³.

6. SAP (SAP IBP & Retail) – Suite historique modernisée, toujours à la traîne (Alerte sur le bagage hérité)

SAP, un titan des logiciels d’entreprise, offre des capacités d’optimisation retail à travers son SAP Integrated Business Planning (IBP) pour la supply chain et la suite SAP for Retail (qui inclut des outils de planification de marchandises et de tarification issus d’acquisitions passées). Les solutions de SAP couvrent la prévision de la demande, la planification des stocks et de la supply chain, la planification de l’assortiment et financière des marchandises, et l’optimisation des promotions. Au cours de la dernière décennie, SAP est passé de son ancien APO (Advanced Planner & Optimizer) et d’autres modules retail hérités à une nouvelle platforme IBP basée sur le cloud. Cependant, les offres de SAP demeurent quelque peu fragmentées entre l’IBP axé sur la supply chain et le CAR (Customer Activity Repository) axé sur le retail ainsi que les applications Retail. Comme les critères d’évaluation mettent l’accent sur l’évitement des approches héritées et d’une intégration « Frankenstein », SAP est souvent cité comme un exemple de ces défis. Une évaluation franche en 2021 notait : “SAP (1972) acquired SAF, KXEN, SmartOps… these apps sit on top of in-house tech (F&R, APO, HANA). Enterprise software isn’t miscible through M&A, and under SAP lies a haphazard collection of products. Complexity is high and the very best integrators – plus a few years – will be needed to achieve success.” ¹¹. Ceci souligne la difficulté de SAP : de nombreuses pièces intégrées de manière lâche, nécessitant un effort d’implémentation important. Nous classons la capacité d’optimisation retail de SAP plus bas dans notre classement en raison de cette complexité héritée et de son rythme plus lent d’innovation en AI, malgré le fait qu’elle soit fonctionnellement complète sur le papier.

Optimisation conjointe: Les modules de SAP fonctionnaient historiquement de manière isolée : par exemple, SAP Demand Forecasting (part of F&R) produisait des prévisions qui alimentaient séparément SAP Pricing (from the acquired Khimetrics) et SAP Assortment Planning (issu d’un autre composant). Ces dernières années, SAP a tenté d’unifier la planification dans IBP – mais IBP couvre principalement la demande, les stocks et la planification d’approvisionnement. La tarification et l’assortiment se situent en dehors d’IBP, dans d’autres solutions spécifiques au retail. Cela signifie que la véritable optimisation conjointe (stocks + tarification + assortiment réunis) n’est pas le point fort de SAP out of the box. Il pourrait être nécessaire de connecter IBP avec, par exemple, SAP Markdown Optimization (qui était un produit distinct) de manière personnalisée. Des tentatives ont été faites : par exemple, SAP’s Unified Demand Forecast (part of CAR) était censé fournir une prévision unique pour tous les systèmes en aval (comme le réapprovisionnement et la tarification). Si mis en place, cela permet au moins d’aligner la tarification et les stocks sur le même signal de demande. Mais une véritable prise de décision conjointe – comme intégrer les coûts de stocks dans l’optimisation de la tarification – nécessite probablement une intégration sur mesure. SAP dispose d’une solution SAP Retail Optimization (l’ancien Khimetrics) pour la tarification qui peut prendre en compte les contraintes de stocks pour les remises (ainsi, dans ce cas limité, elle optimise conjointement la tarification des déstockages avec les stocks disponibles). De plus, les systèmes de marchandisage de SAP relient de manière lâche les plans de vente aux plans d’approvisionnement. Dans l’ensemble, l’architecture de SAP n’optimise pas ces éléments de manière holistique par essence ; au contraire, elle transmet la sortie de l’un comme entrée de l’autre. Par exemple, IBP pourrait générer un plan d’approvisionnement en se basant sur une stratégie de tarification présumée ; si la tarification change ensuite, un planificateur devrait mettre à jour les scénarios IBP. Ce n’est pas un retour automatique. SAP IBP évolue avec des fonctionnalités telles que “Integrated Financial Planning” qui lient les résultats financiers aux plans d’approvisionnement (un peu d’optimisation conjointe, du moins en équilibrant coûts et revenus). Mais comparé aux fournisseurs plus récents, SAP est en retard en termes d’intégration fluide entre les fonctions. La critique sur la complexité ¹¹ suggère que même faire communiquer correctement tous les éléments de SAP représente un projet d’envergure. Ainsi, nous évaluons SAP peu favorablement sur l’optimisation conjointe. Cela peut être réalisé, mais cela nécessite “the very best integrators – plus a few years” ⁸⁶ (citation directe) – ce qui n’est pas un éloge retentissant.

Prévision probabiliste et IA: SAP IBP inclut un module pour “Demand” qui offre des analyses prédictives et même une intégration du ML (ils permettent d’utiliser SAP Analytics Cloud ou des bibliothèques ML externes pour produire des prévisions qui alimentent IBP). SAP a également acquis KXEN en 2013, un outil de data mining, vraisemblablement pour intégrer le ML à divers endroits. Mais la prévision native de SAP dans IBP suit en grande partie la tradition APO (modèles statistiques tels que lissage exponentiel, Croston, etc.). Ils ont introduit le “Demand Sensing” dans IBP, un algorithme (issu de l’acquisition de SmartOps) qui utilise les tendances récentes à court terme pour ajuster les prévisions immédiates – une approche que certains considèrent comme une moyenne mobile pondérée glorifiée. C’est utile, mais ce n’est pas une révolution complète de l’IA. SAP intègre désormais davantage de ML – par exemple, ils utilisent le machine learning pour la prévision de lancement de nouveaux produits (en associant des schémas similaires de produits). Ils disposent également d’un moteur d’optimisation (issu de SmartOps) pour la gestion des stocks à plusieurs niveaux (qui était plus stochastique). Dans l’ensemble, l’innovation de SAP en matière d’IA pour la planification a pris du retard par rapport aux spécialistes. Dans les MQ de planification supply chain, Gartner note souvent que le ML intégré d’IBP est limité par rapport aux autres. Ils se reposent sur des partenaires ou sur leur plateforme Data Intelligence pour le ML avancé. Pour l’optimisation de la tarification, l’outil de SAP (issu de Khimetrics) utilisait des algorithmes sophistiqués (un peu de ML pour l’élasticité, etc.), mais cet outil n’a pas fait l’objet de mises à jour majeures récemment et pourrait ne pas être étroitement intégré. On murmure que SAP pourrait mettre fin à certains de ces outils ou les remplacer par un nouveau service basé sur l’IA – sans certitude, mais rien de marquant. Comme le disait la critique, SAP a dû jongler avec de nombreux éléments prédictifs acquis (SAF assurait les prévisions, SmartOps l’optimisation des stocks, KXEN le ML générique). Il est probable qu’ils n’aient pas été pleinement intégrés dans un moteur d’IA cohérent. La prévision probabiliste spécifiquement : le F&R basé sur SAF de SAP générait des distributions pour les délais et utilisait des taux de service pour déterminer les stocks de sécurité (donc une approche quelque peu probabiliste), mais je ne pense pas que SAP IBP produise intrinsèquement des distributions de probabilité complètes pour la demande ; il se concentre sur un chiffre unique et un chiffre ajusté par le “sensing”. Il est possible qu’ils fournissent quelques intervalles de confiance. En termes de battage médiatique, SAP utilise des mots à la mode comme “predictive analytics” et “machine learning” mais l’IA réellement livrée a été modeste. Nous évaluons SAP relativement bas en matière de prévision avancée par IA – il couvre bien les bases (ils étaient réputés pour des prévisions robustes, quoique traditionnelles), mais ne sont pas leaders en prévision probabiliste ou en ML. Ils essaient de rattraper leur retard en permettant l’intégration d’IA externe. Pendant ce temps, certains clients de SAP pourraient exporter des données pour exécuter du ML sous Python, puis réimporter les résultats – ce qui indique que le système natif de SAP pourrait être insuffisant. En résumé, les prévisions et la planification de SAP utilisent un peu d’IA, mais il s’agit principalement d’une approche conservatrice, basée sur des statistiques avec des fonctionnalités de ML incrémentales.

Prise de décision économique: Les outils de planification de SAP étaient historiquement pilotés par des indicateurs plutôt que par une optimisation intrinsèque du profit. APO vous permettait de définir des cibles de taux de service ou de minimiser les coûts dans la planification d’approvisionnement, mais pas de maximiser directement le profit. Les solutions de tarification au détail de SAP (comme Markdown Optimization) étaient incontestablement économiques – elles optimisaient la marge ou l’augmentation de revenu provenant des promotions. Ce sont des solutions d’optimisation mathématique qui maximisent un objectif (avec des contraintes telles que les stocks ou le budget). Ainsi, en tarification, SAP possédait une force en optimisation économique (Khimetrics fut un pionnier dans les algorithmes d’optimisation des prix au détail). En stocks, le MEIO de SAP (SmartOps) visait à minimiser le coût total pour un objectif de service donné – encore une approche économique, même si limitée par le service. SAP IBP intègre “Inventory Optimization” en tant que module, qui utilise vraisemblablement ce moteur SmartOps pour équilibrer le coût des stocks par rapport au service. Ainsi, cet élément est intrinsèquement axé sur le profit et les coûts. La planification de l’assortiment dans SAP, souvent réalisée via SAP Merchandise Planning, est généralement plus heuristique (les planificateurs simulent les résultats financiers, mais il ne s’agit pas d’un algorithme choisissant quels SKU éliminer en fonction du ROI, même s’il peut signaler des SKU à faible profit pour aider à la prise de décision). De manière générale, SAP permet de suivre des indicateurs financiers – par exemple, IBP peut afficher les revenus projetés et les marges dans les plans, mais l’utilisateur doit souvent décider des compromis plutôt que le système n’optimise automatiquement. Il existe SAP Profit Optimization dans certains contextes (peut-être dans leur outil de conception supply chain ou dans un scénario S&OP), mais ce n’est pas très évoqué. Parce que SAP s’adresse aux planificateurs qui prennent des décisions, il s’agit souvent d’un outil de simulation plutôt que d’un auto-optimiseur. Cela dit, leurs sous-outils de tarification et de stocks effectuent bel et bien une optimisation en coulisses. Nous leur attribuons ainsi une note moyenne : ils ne sont pas aussi axés sur le profit de manière fluide que l’approche nouvelle de Lokad ou de ToolsGroup, mais ils couvrent bien les compromis de coûts. Un bon indicateur : la nouvelle fonctionnalité d’IBP de SAP, les calculs du “Return on Inventory Investment”, aide à établir des priorités. Mais s’il se contente de calculer et d’afficher le ROI au lieu qu’un algorithme maximize effectivement le ROI, c’est différent. Compte tenu de la complexité, de nombreux clients SAP l’utilisent de manière basée sur des règles (comme atteindre des objectifs de taux de remplissage, budgétiser des sommes OTB pour l’assortiment en fonction du jugement du planificateur). Ce n’est donc pas le summum de l’optimalité décisionnelle, mais c’est performant lorsqu’il est configuré. La critique qualifiant leurs acquisitions d’applications “predictive supply chain” implique que SAP disposait des éléments pour intégrer une analyse prédictive coût-bénéfice, mais l’intégration a pris du retard ¹¹. Nous penchons pour dire que SAP est à la traîne en matière d’optimisation automatique du profit.

Scalabilité & Efficacité économique: Le point fort de SAP a toujours été l’informatique en mémoire intensive – SAP HANA est une base de données en mémoire qui soutient IBP et d’autres applications. Elle est très rapide pour certaines tâches, mais extrêmement gourmande en mémoire et coûteuse. De nombreuses entreprises trouvent les solutions SAP onéreuses à faire évoluer car il faut de grandes capacités mémoire sur HANA. Par exemple, SAP IBP exige que toutes les données de planification soient en mémoire HANA pour effectuer des calculs rapidement, ce qui peut être onéreux pour les grands détaillants (des téraoctets de mémoire). Cela correspond au souhait d’éviter les solutions gourmandes en RAM dans nos critères. En effet, une analyse disait d’un fournisseur (Relex) de manière similaire, “in-memory design gives great speed but guarantees high hardware costs” ²² – c’est exactement l’approche de SAP aussi. Ainsi, l’efficacité économique est discutable ; l’approche de SAP produit souvent une réponse rapide mais avec un coût d’infrastructure élevé (à moins de décharger une partie sur un stockage moins cher, ce qui entraîne alors une perte de vitesse). L’offre cloud de SAP tente de pallier cela en gérant l’arrière-plan sur leur HANA Cloud et en facturant un abonnement, mais en réalité, le coût est répercuté via l’abonnement. Historiquement, la mise en œuvre de SAP APO ou F&R était relativement scalable puisqu’elle pouvait gérer d’énormes volumes (les grandes entreprises mondiales l’utilisaient), mais nécessitait parfois des traitements batch nocturnes ou une simplification pour respecter les fenêtres temporelles. IBP sur HANA améliore significativement les temps de calcul (certains cycles d’exécution prennent quelques minutes au lieu d’heures en APO). Ainsi, la scalabilité en termes de performance est améliorée, mais en termes de volume de données, elle est limitée par le budget mémoire. SAP convient aux grandes entreprises (certaines des plus grandes l’utilisent), mais ces projets nécessitaient souvent un matériel sérieux et un réglage fin. Donc oui, SAP gère de grandes quantités de données, mais pas de manière aussi rentable que des solutions cloud distribuées peut-être. Quant à l’efficacité économique, SAP est réputé pour être une solution coûteuse dans l’ensemble (licences, infrastructure, coûts d’intégrateurs). Le passage MQ ⁸⁶ concernant “the very best integrators plus years needed” indique également que sa mise en œuvre est coûteuse en temps et en ressources humaines. Si l’on mesure la pure efficacité de calcul, HANA est performant mais onéreux (très cher par Go de RAM). De plus, certains modules SAP, comme celui de la tarification, avaient des moteurs séparés qui pouvaient ne pas être très scalables (l’ancien Khimetrics fonctionnait sur Oracle DB et avait des limitations quant à la taille des problèmes d’optimisation). On n’en sait pas plus pour aujourd’hui. Au vu de tout cela, nous évaluons SAP comme faible en efficacité économique et modéré en scalabilité (il peut gérer un grand volume, mais à un coût élevé et avec une complexité importante, ce qui est exactement ce que nos critères souhaitent pénaliser). Il illustre essentiellement le « coût computationnel excessif » à éviter si possible.

Gestion des facteurs complexes du retail: Les solutions retail de SAP prennent en charge un certain nombre de complexités :

Cannibalisation/Halo: Les prévisions de SAP (notamment via CAR Unified Demand Forecast) pouvaient intégrer des facteurs causals, y compris les promotions de produits connexes, etc., mais historiquement, SAP était moins performant à cet égard. La méthode SAF était principalement centrée sur un produit unique. Ils disposaient d’un module appelé SAP Promotion Management for Retail qui pouvait estimer l’augmentation et la cannibalisation à l’aide de certains modèles. De plus, l’optimisation des markdowns de SAP prenait en compte les effets entre articles (peut-être au niveau des catégories). Mais honnêtement, SAP n’était pas réputé pour des prévisions de promotion de premier ordre – de nombreux détaillants utilisaient des solutions tierces ou procédaient manuellement. Il est possible que KXEN ait été destiné à aider à détecter des corrélations (comme l’utilisation du ML pour identifier des motifs de cannibalisation). Il est incertain de savoir dans quelle mesure cela a été bien intégré.
Substitution: SAP F&R disposait d’une fonctionnalité permettant de prendre en compte les substitutions (si un article était en rupture, suggérer des propositions de substitution ?). De plus, dans l’analyse des ventes perdues, il pouvait tenir compte du fait qu’une vente soit récupérée par un autre produit. Mais on ne sait pas si cela est disponible en standard ou s’il faut le personnaliser. La logique MRP de SAP (dans l’ERP) ne gérait pas la substitution par défaut dans la planification, cela relevait davantage d’un exercice analytique.
Produits périssables: SAP disposait de F&R (Forecasting & Replenishment) spécialement conçu pour l’épicerie avec gestion de la durée de conservation. Il permettait de définir des règles pour éviter d’envoyer plus de produits que ce qui pouvait être vendu avant expiration et de suivre l’ancienneté des stocks. De nombreux détaillants utilisaient SAP F&R pour les produits frais et en observaient des améliorations. IBP ne dispose peut-être pas encore de toute cette logique pour les produits frais en standard, mais possiblement via SAP’s CAR Fresh Inventory ou une solution similaire. SAP propose également une extension pour la « planification de la durée de conservation » dans PP/DS. Ainsi, dans une certaine mesure, il prend en compte les contraintes d’expiration dans la planification d’approvisionnement.
Espace/assortiment: L’outil de planification d’assortiment de SAP prend en compte, à un niveau global, les contraintes d’espace en magasin (comme le nombre maximum de catégories). Ce n’est pas aussi intégré que le lien planogramme de Blue Yonder. Cependant, ils intègrent des données de planogramme dans CAR afin de s’assurer que les commandes en magasin ne dépassent pas la capacité des étagères, en tant que règle. Cela n’est peut-être pas entièrement automatisé, mais c’est possible. Ils disposaient d’une intégration entre SAP F&R et les données de planogramme (via SAP’s Landscape Management). Ainsi, une certaine considération des contraintes d’espace dans les commandes est prise en compte.
Prévision de promotions: Le CAR de SAP inclut un modèle “Demand Influencing Factor” dans lequel les promotions, jours fériés, etc., sont pris en compte dans la prévision via des régressions ou le ML. Ainsi, les promotions sont anticipées avec un effet positif. De nombreux clients de SAP utilisent cette fonctionnalité (avec des succès variables).
Facteurs externes (météo, etc.) : Grâce à KXEN ou désormais SAP Analytics Cloud Predictive, ils permettent d’inclure ces variables. Des implémentations ont été réalisées dans lesquelles la météo influençait les commandes de produits saisonniers en utilisant les outils SAP, bien que ce ne soit pas en mode plug-and-play. En résumé, SAP peut gérer ces aspects, mais cela nécessite souvent de personnaliser les modèles statistiques ou d’utiliser leurs nouveaux services prédictifs. Ce n’est pas aussi « out-of-box » que chez certains fournisseurs spécialisés. La critique qualifiant l’ensemble des solutions SAP de “haphazard” suggère un manque de synergie – par exemple, la fonction de prévision de promotion ne s’alimente pas de manière fluide dans le réapprovisionnement, nécessitant ainsi une intégration complémentaire. SAP IBP étant relativement nouveau, certaines fonctionnalités avancées ne sont pas encore mûres ; par exemple, il offrait des prévisions de base et n’a commencé qu’à intégrer récemment (2022+) du “demand sensing” piloté par le ML ou des signaux de demande externes. Je classerais SAP comme moyen sur les facteurs complexes – il possède des capacités, mais ce n’est pas aussi avancé ou automatique que chez d’autres. Par exemple, un détaillant pourrait devoir configurer manuellement comment une promotion sur le produit A réduit la demande pour le produit B dans le système SAP, alors que RELEX pourrait l’apprendre automatiquement. De plus, leur documentation n’a pas autant mis en avant la solution de cannibalisation ; certains clients pourraient s’appuyer sur des outils externes pour cela (par exemple, utiliser SAP HANA pour exécuter un ML personnalisé afin de détecter la cannibalisation, puis réimporter les ajustements). Je leur pénalise donc légèrement sur ce point.

Automation: La philosophie de SAP a traditionnellement été davantage axée sur le « support à la planification » que sur une « planification entièrement automatique ». Ils exigent souvent que les planificateurs exécutent des travaux par lots et examinent les résultats. Par exemple, SAP APO était un outil très interactif où les planificateurs devaient fréquemment lancer des prévisions, exécuter des optimisations, etc. SAP IBP a amélioré une partie de l’automatisation grâce aux alertes et aux plannings, mais il s’agit tout de même généralement d’un outil de cycle de planification, et non d’un système de pilotage continu automatique. De nombreux clients SAP disposent encore de grandes équipes de planification réalisant des analyses what-if dans des tableurs IBP. Dans le retail, les solutions de SAP telles que Merchandise Planning et Assortment sont essentiellement des outils de planification manuelle (similaires à Excel, mais intégrés). Elles ne sont pas automatisées – elles nécessitent que les planificateurs fixent des objectifs et sélectionnent des assortiments. L’optimisation des prix peut être automatisée dans une certaine mesure (l’algorithme fournit des recommandations de prix, mais généralement un analyste des prix les examine et les approuve dans SAP). Le réapprovisionnement dans SAP (soit via F&R, soit via ERP MRP) était automatisé pour générer des propositions de commandes, lesquelles pouvaient ensuite être automatiquement converties en bons de commande si elles respectaient les tolérances ; c’était une pratique courante. Ainsi, le réapprovisionnement en magasin pouvait se faire sans intervention – de nombreux détaillants alimentaires le faisaient avec SAP F&R ou avec CAR/Unified Demand Forecast accompagné de la création automatique de commandes dans S/4. C’est un point fort – SAP peut automatiser le réapprovisionnement assez efficacement, une fois configuré (comme tout système décent). Là où ils manquent, c’est peut-être dans la révision automatique des plans à la volée par le machine learning – ils dépendent encore de cycles par lots (quotidiens ou hebdomadaires). Ils disposent d’alertes d’exception pour signaler si les ventes dévient, de sorte qu’un planificateur puisse ajuster manuellement rapidement (semi-automatisé). IBP a introduit des fonctionnalités telles que les « prévisions auto-réglantes » (le système choisit automatiquement le meilleur modèle, sans nécessiter de sélection manuelle). C’est une automatisation basique. Le marketing de SAP autour du « demand sensing » implique une automatisation plus fréquente des mises à jour de prévisions avec les dernières données, ce qui est partiellement automatisé. Mais par rapport à d’autres, SAP ne promeut pas une approche totalement autonome ; il s’agit plutôt de soutenir l’efficacité des planificateurs. Le besoin important d’intégrateurs suggère qu’il ne s’agit pas d’un simple mode pilote automatique à activer. Je classerais donc SAP moins bien en termes d’automatisation. Sa mise en œuvre est souvent lourde et nécessite encore une supervision manuelle importante. De nombreux processus restent dirigés par les planificateurs (avec les calculs du système en appui). Ils n’atteignent probablement donc pas l’objectif du « pleinement sans surveillance ».

Technology Integration: L’histoire de SAP est en effet celle d’acquisitions accumulées sur une technologie de base :

Ils possédaient leur propre APO (pour supply chain) et un Forecasting & Replenishment (F&R) interne pour le retail, distincts.
Ensuite, ils ont acquis SAF (pour les prévisions de la demande), SmartOps (optimisation des stocks), et les ont en partie intégrés dans APO ou IBP.
Ils ont acquis Khimetrics (optimisation des prix) et Retek (systèmes de merchandising) intégrés dans le stack Retail de SAP.
KXEN (ML) a été intégré dans leurs offres d’analyse.
Le tout reposant sur HANA ou ECC. C’est exactement le « Frankenstein ». L’approche de SAP pour intégrer ces éléments : dans IBP, ils ont reconstruit les fonctions d’APO sur HANA et ajouté la logique SmartOps pour les stocks et possiblement quelques idées SAF pour la demande. Mais au départ, IBP manquait de fonctionnalités (certains disent que les prévisions du premier IBP étaient plus simples que celles de l’ancien APO ou de SAF, et ils ont depuis rattrapé leur retard). Du côté retail de SAP : certaines choses ont été fusionnées dans CAR (Customer Activity Repository), qui se veut être une plateforme unifiée pour les données de la demande et certaines analyses (comme la prévision unifiée de la demande, la gestion des promotions). CAR était destiné à intégrer les transactions en magasin avec la planification – une bonne démarche d’intégration. Cependant, historiquement, CAR et IBP ne communiquaient pas de manière fluide (ils sont en train de remédier à cela désormais avec des API). Le principal problème de SAP réside dans le fait de disposer de deux plateformes parallèles (IBP pour la supply chain et CAR pour la planification retail en magasin). Il y a un chevauchement et des conflits potentiels, bien qu’ils aient positionné IBP pour les responsables de la supply chain et CAR pour ceux du merchandising. L’intégration entre la tarification, l’assortiment et la planification d’approvisionnement dans SAP repose souvent sur une intégration via l’ERP central (par exemple, en transmettant les prévisions à l’ERP, qui alimente ensuite un autre module – ce n’est pas un moteur unique). La critique ¹¹ l’exprime clairement : « ces applications reposent sur une technologie interne… sous la bannière SAP se retrouve un assemblage hétéroclite… la complexité est élevée, nécessitant des intégrateurs de pointe et des années pour atteindre le succès. » Cela résume bien les problèmes d’intégration – ils sont réparables avec les meilleurs consultants, mais ne sont pas élégamment intégrés dès la sortie de la boîte. De nombreux clients retail de SAP se plaignent de systèmes multiples qui dupliquent les données (par exemple, l’élasticité des prix peut être calculée dans leur outil de tarification et prise en compte séparément dans l’outil de prévision, sans lien). La solution apportée par SAP a été de centraliser tout sur la base de données HANA afin qu’au moins les données puissent être partagées facilement au niveau de la DB, et de développer des scénarios d’intégration en utilisant SAP Cloud Platform ou CPI. Néanmoins, cela représente du travail. Étant donné que SAP vend une suite complète (ERP, planification, exécution), en théorie, elle devrait être profondément intégrée. En pratique, les différents modules sont venus à des moments différents et ont été assemblés. L’intégration de SAP n’est pas aussi aboutie que celle des microservices de Blue Yonder ou même de la suite modulaire de ToolsGroup. Cela nécessite souvent des projets sur mesure pour aligner les flux de données. Donc, oui, SAP se classe clairement dans la catégorie « Frankenstein » dans une certaine mesure (ils l’ont au moins reconnu et ont tenté d’unifier via HANA et CAR, mais cela n’est pas totalement résolu selon les experts). Ainsi, en matière d’intégration technologique, nous attribuons à SAP une note faible. La citation même de notre source résume par l’avis d’experts leurs difficultés d’intégration ¹¹. Il est révélateur de constater que même SAP a dû s’associer à des intégrateurs tels qu’Accenture ou EY pour mettre en œuvre leurs solutions de planification avec succès.

Skepticism Toward Hype: SAP ne fait pas la promotion de l’IA de manière aussi flamboyante que certains autres, mais ils utilisent des buzzwords dans leur marketing (ils parlent de « embedded ML », de « demand sensing », de « digital twin of supply chain », etc.). Beaucoup dans l’industrie se montrent sceptiques quant aux affirmations de SAP, car parfois les fonctionnalités ne sont pas aussi mûres qu’annoncé initialement (par exemple, le premier IBP manquait de certaines capacités promises, qui ont été livrées ultérieurement). De plus, SAP présente souvent une vision de « planning intégré de bout en bout » qui semble excellente, mais nombreux sont ceux qui savent que la réalité se traduit par plusieurs modules devant être intégrés avec un effort considérable. Il y a donc un fossé. Le marketing de SAP autour d’IBP met en avant le « déploiement rapide » (puisque c’est le cloud) et des tableaux de bord « conviviaux » – ce qui est partiellement vrai, mais le déploiement d’IBP peut tout de même prendre un an ou plus dans des cas complexes. En matière d’IA, SAP tend à ne pas trop outrepasser ses offres réelles – ils admettent lorsqu’ils dépendent de partenaires pour des analyses avancées. Ironiquement, SAP pourrait être plus conservateur en termes de promotion que les petits fournisseurs. Leur communication repose davantage sur des affirmations d’intégration (comme « Integrated Business Planning » qui laisse entendre une intégration totale, alors qu’en réalité, cela ne couvre que la planification de la supply chain, et non la planification retail dans son ensemble). Un autre exemple : le « Demand-Driven Replenishment » de SAP – un buzzword autour de la méthodologie DDMRP qu’ils promeuvent, que certains considèrent davantage comme une tendance que comme une solution éprouvée en toutes circonstances. Ils ont sauté dans le train en marche. De même, des termes comme « Digital Supply Chain » sont beaucoup évoqués dans le marketing de SAP. Compte tenu de la taille de SAP, le discours promotionnel est peut-être moins exagéré par ton, mais ils présentent assurément leur solution comme une offre unique et pérenne, tandis que les critiques la jugent complexe et en partie démodée. Ainsi, d’un point de vue sceptique, nous mettons en garde contre le fait que de nombreux avantages promis par SAP n’aboutissent qu’avec une personnalisation étendue ou pourraient ne pas être aussi automatiques qu’impliqué. L’étude indépendante a attribué à SAP une note moyenne parmi les fournisseurs et a explicitement pointé du doigt le patchwork issu des fusions-acquisitions ainsi que la complexité ¹¹. Cela revient essentiellement à dire « ne croyez pas que tout soit parfaitement intégré ; c’est assez désordonné à l’intérieur. » Il est donc juste de pénaliser sur l’alignement avec le battage médiatique. Nous dirons que SAP est assez transparent auprès des grands clients en indiquant qu’une forte mise en œuvre est nécessaire – pas forcément avec un battage tape-à-l’œil, mais leur marketing occulte l’ampleur de l’effort requis pour obtenir un bon fonctionnement. Ainsi, un scepticisme modéré quant au battage médiatique s’impose – pas aussi truffé de buzzwords que o9 ou Blue Yonder, mais toujours avec de nombreuses affirmations optimistes qui requièrent une mise en cohérence avec la réalité.

Summary: Les offres d’optimisation retail de SAP sont globalement complètes sur le papier mais souffrent d’être un patchwork hérité qui n’a pas complètement évolué vers l’ère moderne pilotée par l’IA. La plateforme SAP IBP et les modules retail associés peuvent certes traiter stocks, tarification et assortiment – mais pas de manière véritablement unifiée, en optimisation conjointe. L’optimisation conjointe est limitée par des outils compartimentés : par exemple, la planification de la demande et le réapprovisionnement se font dans IBP ou F&R, tandis que la tarification et la planification de l’assortiment s’opèrent dans des modules SAP séparés, avec uniquement un transfert de données par lots entre eux. SAP ne dispose pas d’un moteur unique capable d’optimiser simultanément les stocks et les prix (ces décisions sont coordonnées par des personnes et des processus plutôt que par un algorithme unique).

SAP emploie l’IA/ML par paliers – par exemple, des algorithmes de « demand sensing » pour ajuster les prévisions à court terme, ou le machine learning pour les prévisions de nouveaux produits – mais une grande partie de ses prévisions reste ancrée dans des méthodes traditionnelles et des règles définies par l’utilisateur ¹¹. Il est révélateur que SAP ait dû acquérir des sociétés spécialisées (SAF, SmartOps) pour renforcer APO, et même aujourd’hui, la prévision probabiliste et le ML avancé ne sont pas intégrés de manière native comme chez certains concurrents. La planification chez SAP produit généralement des prévisions à valeur unique et s’appuie sur des planificateurs de scénarios pour évaluer l’incertitude, plutôt que de fournir des distributions de probabilité complètes de la demande (bien que l’optimisation des stocks prenne en compte la variabilité via le taux de service ou le calcul des stocks de sécurité). En termes d’optimisation économique, les outils de SAP peuvent être configurés pour optimiser certains résultats financiers (leur optimisation de markdown maximise la marge, l’optimisation des stocks minimise le coût pour un taux de service cible, etc.), mais il s’agit généralement d’optimisations spécifiques à un module plutôt que d’une maximisation globale du profit de l’ensemble de l’opération retail.

Un problème majeur avec l’ensemble des solutions de SAP est celui de la scalabilité vs. coût. SAP s’appuie fortement sur sa base de données HANA en mémoire. Bien que cela permette des calculs rapides sur de grands ensembles de données (permettant, par exemple, des prévisions très détaillées par magasin et SKU en quasi temps réel), cela *« garantit des coûts matériels élevés » ²² et peut s’avérer coûteux à mettre à l’échelle. SAP IBP est connu pour fonctionner de manière optimale sur HANA avec une allocation mémoire importante, ce qui peut être excessif (et trop onéreux) pour certaines tâches. Cela contredit le critère d’efficacité en termes de coûts ; l’approche de SAP peut gérer l’échelle d’entreprise, mais pas sans une infrastructure et des licences onéreuses.

En ce qui concerne les facteurs complexes du retail (cannibalisation, substitution, détérioration, etc.), SAP dispose de capacités, mais celles-ci nécessitent souvent une configuration substantielle et ne sont pas aussi prêtes à l’emploi que certaines solutions plus récentes. Par exemple, SAP peut modéliser des promotions et même certains effets de cannibalisation en utilisant ses analyses du Customer Activity Repository (CAR) ou en configurant des élasticités croisées dans son outil de tarification, mais ces relations ne se découvrent pas automatiquement – elles reposent généralement sur des analystes pour fournir leurs hypothèses ou sur des analyses séparées en dehors de la planification centrale. De même, SAP F&R pouvait prendre en compte la durée de vie des produits périssables et limiter les commandes en conséquence, mais la mise en place de la planification des produits frais dans SAP a historiquement été difficile et parfois moins sophistiquée que des outils spécialisés (certains détaillants se sont tournés vers des solutions sur mesure pour le frais).

Automation dans la planification retail de SAP est relativement faible. SAP fournit des moteurs de planification, mais le processus de planification est souvent piloté par l’utilisateur : les planificateurs définissent les paramètres, lancent les prévisions, examinent les exceptions, et valident les commandes ou les prix. Il existe des calculs automatisés (par exemple, le système génère des propositions de commande ou des prix optimisés), mais un fonctionnement en continu sans surveillance est rarement atteint sans une supervision humaine importante. Il faut investir dans la mise en place de workflows automatisés (et même dans ce cas, de nombreux utilisateurs de SAP gardent des humains dans la boucle en raison de problèmes de confiance ou de la complexité du système). Essentiellement, les outils de SAP sont souvent décrits comme des systèmes de support à la décision plutôt que de prise de décision.

Enfin, l’intégration technologique est un point sensible. La solution d’optimisation retail de SAP est en effet une « collection hétéroclite » issue de multiples acquisitions superposées à son ERP central ¹¹. Malgré des initiatives telles que SAP IBP (conçu pour unifier la planification de supply chain sur une plateforme unique) et SAP CAR (destiné à unifier les données transactionnelles retail et l’analytique), la réalité est que les outils de stocks, de tarification et d’assortiment de SAP ne fonctionnent pas naturellement comme un tout. Obtenir un flux de données harmonieux nécessite un travail d’intégration conséquent (souvent réalisé par des intégrateurs SAP expérimentés sur de longs projets) ⁸⁶. Même dans ce cas, les utilisateurs peuvent se retrouver avec plusieurs interfaces et une duplication des données. Cette architecture disjointe est exactement le scénario « Frankenstein » dont il faut se méfier – une solution qui est techniquement capable de tout mais qui donne l’impression d’être plusieurs systèmes assemblés, ce qui entraîne une grande complexité et des coûts de maintenance élevés.

Skepticism est justifié lorsqu’on évalue les affirmations de SAP. SAP positionne souvent IBP et sa suite retail comme une « solution intégrée de bout en bout », mais les experts notent que « les logiciels d’entreprise ne fusionnent pas aisément via des fusions et acquisitions » ¹¹ – ce qui laisse entendre que l’intégration de SAP ne répond pas entièrement à cette vision. De plus, des buzzwords tels que « real-time », « predictive » et « demand sensing » parsèment le marketing de SAP, et pourtant de nombreux utilisateurs constatent que tirer une véritable valeur de ces fonctionnalités demande un effort considérable et une personnalisation poussée. En somme, les capacités d’optimisation retail de SAP sont larges mais pas profondes dans certains domaines modernes, et fiables mais pas élégantes. Elles représentent davantage une approche héritée d’entreprise : puissantes en termes de portée et capables de monter en charge dans de grands environnements, mais massives, coûteuses et complexes – nécessitant souvent une forte capacité humaine et IT pour obtenir des résultats ⁸⁶.

Pour les détaillants déjà fortement investis dans l’écosystème de SAP, ces outils peuvent être rendus opérationnels et bénéficier d’une intégration ERP transparente. Cependant, ils peuvent paraître une génération en retard par rapport à l’état de l’art véritable en optimisation retail holistique et pilotée par l’IA. Nous classons SAP parmi les moins performants en raison de ces facteurs – il illustre de nombreux écueils que cette étude vise à mettre en lumière (technologie héritée, défis d’intégration, TCO élevé, et marketing qui peut trop valoriser la facilité d’utilisation).

Sources: Critique de la complexité de produit accumulée par SAP et des défis d’intégration ¹¹; comparaison de haut niveau indiquant que les conceptions en mémoire (comme celle de SAP) troquent performance contre coût matériel ²².

(Les autres fournisseurs et analyses peuvent se poursuivre de manière similaire, en se concentrant sur les concurrents tournés vers l’avenir et en pénalisant ceux qui dépendent lourdement des acquisitions ou des mots à la mode. Pour faire court, nous concluons ici les évaluations détaillées.)

Résumé du classement des fournisseurs:

Lokad – Excelle dans l’optimisation unifiée et probabiliste; hautement innovant, avec peu de battage médiatique ²⁵ ³.
RELEX Solutions – Plateforme native au commerce de détail dotée d’un solide apprentissage automatique et d’une planification intégrée; modélisation avancée des promotions/cannibalisation ⁹.
o9 Solutions – Planification intégrée visionnaire “Digital Brain” avec une portée étendue, mais prudence quant à l’IA revendiquée par rapport à la mise en œuvre réelle ⁴.
ToolsGroup – Optimiseur de stocks éprouvé en évolution vers une suite complète de commerce de détail; bonne automatisation, bien que l’intégration de nouvelles acquisitions soit en cours actuellement ¹⁹ ⁵².
Blue Yonder – Suite complète de commerce de détail réinventée avec l’IA; extrêmement riche en fonctionnalités, mais encore quelque peu héritée sous le capot ⁷².
SAP (IBP & Retail) – Acteur puissant et historique avec une large couverture; entravé par une complexité héritée et une agilité moindre, nécessitant une intégration lourde ¹¹.

Chaque fournisseur apporte des forces et des faiblesses telles que détaillées ci-dessus. En résumé, ceux comme Lokad et RELEX qui mettent en avant une véritable optimisation conjointe, des prévisions probabilistes et une pile technologique repartant de zéro ²⁵ ³ se distinguent comme étant à l’épreuve du temps et alignés avec nos critères. D’autres, en particulier les grandes suites héritées, ont dû adapter des techniques modernes et peuvent fournir des résultats, mais pas sans le poids d’une architecture ancienne et parfois des affirmations marketing non étayées ⁷². Les utilisateurs devraient peser ces compromis avec un regard sceptique et orienté ingénierie pour choisir la solution qui répond réellement à leurs besoins sans le vernis du battage médiatique.